Bypass signature requirement for COD files

July 31, 2007

Actually it didn’t work as we had expected. We still cannot bypass signature control, but results, in fact, quite interesting.

After many unsuccessful experiments and reviews of both – SignatureTool and rapc , we decided to try another approach – net_rim_api. Our assumption was that any API call should be mapped to particular function prototype in net_rim_api library. If we can learn how it was done then the next step would be to create our own “prototypes” of system functions and try to bypass needs for application signing. Our assumption was “almost” correct. Why “almost” I’ll explain later.

What we did, we used information dumped from cod files, namely – class names and methods definitions, to create prototype java files. An example:

// ##########################################
// Decompiled by : coddec
// Module : XXXXXXXXXXXXXX.cod
// Module version : 4.2.1.89
// #########################################
package net.rim.vm;

public class Process
{

native public int getLastIdleCounter();
}

The trick is just simple to declare a function as native. Then the file was compiled using standard java compilator. The resulting class file was slightly corrected by JavaBite tool to remove constructor code, but I am not quite sure that it was strictly required. Anyway you are free to experiment.

Next step is to add our class file to ne_rim_api.jar file. This task is very-very simple. We used 7-Zip to accomplish that.

Well, that’s it. If in your project you call getLastIdleCounter(), rapc will compile your project without any signature warning. Why was it cool ? getLastIdleCounter() is just an example, using the same approach is possible to call system functions not using protected RIM API.

Unfortunately, it only worked on emulator. There was additional signature requirement we weren’t aware of. Signer ID for this one is 33 and it appears as “Secure API” in the error message. We couldn’t find any useful information regarding that, but it seems it is related to so called “Secure Device” flag and it works the same way as firewall rule – “Deny All”.

If it would be possible to turn the flag off … We are trying to figure out how …

By the way, the public key for Signer ID ( 33 ) is the same for all devices and BB emulator, it begins with 0x8F A7 61 CA 6E B6 94 5E 28 86 … the length is 128 bytes (1024 bits). It is physically located in rim*.sif file.

Another possibility would be replace this key with own public key, but it would be necessary to re-sign all system libraries using own private key as well. And we are not quite sure if it would be possible to patch sfi file at all as it might be signed too.


History of COD format

July 31, 2007

For those interested in COD format, a patent publication from RIM revealing some ideas behind its creation – 20060020932 .


Small tool to dump signatures from COD file

May 29, 2007

It is a small tool we use to dump signatures from COD file. The signatures table starts right after data segment end and each signature record has a very simple structure:

typedef struc {

ushort sign_type;

ushort sign_length ;

char signer_id [4] ;

byte signature [sign_length – 4] ;

} SIGNATUREENTRY

Download 2 java files Hex.java and Program.java , put them in the same folder, compile and run

Usage:

getsignatures <filename1.cod> [.. <filenameZ.cod>]

Output looks like:

File : net_rim_cldc.cod | version is: 78
Codesize = 53308
Datasize = 27972
| Type = 1 | Length = 132 | signerid = RRTT | sig_start = 81332 | sig_end = 81460
50 ad 66 4d 75 2f d1 54 43 01 9c bb fd b7 a1 ab
35 32 cb 7e 42 80 7a 7a d7 39 eb 9d 2e f4 08 cd
53 95 48 60 b9 f0 ac 27 7c bf cd 8e 3f 20 d9 fe
29 94 95 68 8e 41 ac 6a 82 66 c5 8b 44 c3 07 a9
59 8c da 04 89 6a 03 51 3c 8a 9e 5c 1e c1 32 05
a2 96 58 7a 73 c6 b9 59 74 4b a4 08 2d 4c ce 1e
2d dd 5d f1 5a a0 93 1b e6 5b 8c 87 9b 6c f1 9c
20 51 06 db fd 00 fc ca fc 01 28 b3 52 76 82 e8

Cheers


Blackberry internal folders layout

May 16, 2007

/applications/

/dev/

/system/

/system/samples/

/system/fonts/

/appdata/

/appdata/rim/

/home/

/home/user/

/home/user/pictures/

/home/user/ringtones/

/home/user/video/

/home/user/settings/

/tmp/

/samples/

/samples/pictures/

From Browser it could be called by using file://store/ prefix , but I cannot check it as my Browser service is disabled at the moment. Can somebody with working Browser check this link:

file://store/samples/pictures/Leaf.jpg ?


Update of COD Template

February 1, 2007

 Here is the latest release of our COD template. We stopped any active development of it because it is pointless since we found another way to get inside of .cod files and it is required a lot of effort as well.

We will probably use it as a documentation tool but there is no guarantee.

Cheers


How it looks like …

January 30, 2007

Just an example of our work:

// Decompiled by coddec #################################
// Information ###########################################

package net.rim.device.api.io.http;

abstract public class AuthScheme extends java.lang.Object

{
protected java.util.Hashtable _parms;

public void setParameter (net.rim.device.api.io.http.AuthScheme param0, java.lang.String param1, java.lang.String param2)

{
enter_narrow
aload_0_getfield
aload_1
aload_2
invokevirtual java.util.Hashtable.put( java.util.Hashtable, java.lang.Object, java.lang.Object )
pop
return
}

…….

}

Here is the same class and method processed by “built-in” disassembler:

Code Section
routines 54036
net.rim.device.api.io.http.AuthScheme.setParameter( net.rim.device.api.io.http.AuthScheme, java.lang.String, java.lang.String ) 0
returns: 31486
prototype: 34014
codesize= 13
(11)
IsPublic
attributes= 1
setParameter 10072
numstackmaps=0
locals=3
parms=3
stack=3
nlps= 63
net.rim.device.api.io.http.AuthScheme.setParameter( net.rim.device.api.io.http.AuthScheme, java.lang.String, java.lang.String )
enter_narrow 221
aload_0_getfield 103
.field_ 0
aload_1 64
aload_2 65
invokevirtual 1
java.util.Hashtable.put( java.util.Hashtable, java.lang.Object, java.lang.Object )-1
parmcount= 3
pop 205
return 31


Progress update

January 25, 2007

Just a brief update of our progress. The project has got a working name “coddec” which is from “cod decompiler”. So far coddec does the following things:

– Restores a full folders structure similar to the original jar file

– Decompiles classes, fields, methods headers. There is an issue with fields having default value. We actually couldn’t map a default value to a corresponded field. At the moment we have no solution for this problem.

– Methods bodies are disassembled only, not decompiled. The reason for that is that RIM uses own opcodes which are totally different from the standard jvm opcodes. But a good news is that we know how to resolve this issue. The only inconvenience we would need an additional time to write a conversation module.

Cheers