Log in

View Full Version : BlackBerry OS


fritzFS
November 27th, 2006, 20:19
Hello,

have anyone tried any reverse engineering/cracking on this?

Are there any tools or documentation?

thank you

naides
November 27th, 2006, 20:33
http://www.blackberry.net/developers

IDA should work with this also, but I have not personally tested their debugger/simulator.

fritzFS
November 27th, 2006, 20:44
Thank you, naides,

I've also stumbled across that link little bit earlier so I'm checking it out.

Still, if anyone has any expirience, do not hesitate to answer ;-)

dELTA
November 28th, 2006, 08:52
A google for "blackberry reversing" turns up at least a couple of interesting results, which are probably a good start, and when posting a question like this it would be very appropriate to mention these and other things you might have found while taking a quick look into the subject yourself first (not to mention instead of saying "I already knew about that" when you get a reply).

fritzFS
November 28th, 2006, 10:32
yes, yes, delta, I knew that also!

Ok, information I got so far :

- BlackBerry OS has (modified) Java VM written in ARM
- applications code is stored in .cod file which is not publicly known
(information known so far can be found here : http://drbolsen.wordpress.com/2006/08/11/10/)
- BB code differs pretty much except in simple bytecode from Java's original so comparing them isn't 100% useful
- guy named Hex coded a loader for IDA which loads .cod file and dumps the main structures

Good way would be to download simulator from:
http://www.blackberry.com/developers/downloads/index.shtml
and start tracing from there ...

Anyway, pretty screwed position for anyone who tries to crack BB application :-(

dELTA
November 28th, 2006, 18:22
That's better.

And what makes you screwed? You have a compiler, a simulator, an IDA loader and a guy who obviously knows quite a bit about it and is willing to cooperate with others in exploring it further (i.e. Hex), seems like a pretty damn good start to me.

I also found this note by Hex in another place:

Quote:
.cod is a RIM JVM code format. It’s a modified version of Sun’s Javavirtual Machin. The native code for Blackberry is ARM. Yes there’s a standard way for even decompiling the .cod files. The full version of rapc compiler contains the class the provides such ability. But JDE version of rapc contains only the classes for compilation. Format is propietary. But we can reverse it…
I've also invited Hex to participate in this thread, so let's see if he joins the discussion.

disavowed
November 28th, 2006, 21:09
You may also want to check out http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-FX.pdf
It's the presentation that FX gave at Black Hat on BlackBerry analysis.

LLXX
November 28th, 2006, 22:17
This is "berry" interesting

Hexxx
November 29th, 2006, 04:17
Hello everyone. Ask me the questions and i'll answer.

P.S. I'll upload the IDA loader with source code tomorrow, and post a link here. I've got to release the project at my work. So i just had no time to upload it.

JMI
November 29th, 2006, 04:31
Thank you. We look forward to your contributions.

Regards,

dELTA
November 29th, 2006, 04:33
Hey Hexxx, thanks for dropping by! Sounds great with the IDA loader + source!

And now fritzFS and everyone else, the table is set for you, we have the information above, and one of the world's leading Blackberry reversers is with us here in the thread. Make good use of it, and let the discussion begin.

I'll also start with a simple (and possibly stupid) question for Hexxx: As I quote above, you say that "the full version of rapc compiler contains the class to decompile cod files". Isn't this "full version" of the compiler available somewhere on the net, or is it just company internal to the Blackberry guys?

Hexxx
November 29th, 2006, 05:07
It's not available in the web. I've found the references to the decompiler in rapc.exe. They've left the reference to some "net.rim.tools.decompiler" class in rapc.jar. But there was no such class in rapc.jar.

They will never give such version of rapc into public, because it will allow to crack all their applications

rapc.jar - it's a compiler written in java. All the code is obfuscated.
Rapc can both convert the .class files into .cod and compile .java to .cod

dELTA
November 29th, 2006, 05:51
Ok, thanks for the info! That conversion of class files to cod files that you mention feels quite useful to me for mapping the exchanged opcodes/bytecodes of the cod files vs common java bytecodes, especially if they are just simple substitutions to make the files incompatible with normal java decompilers, right? If just a few opcodes are substituted for other opcodes, a comparative analysis of the class file and corresponding produced cod file would clear this issue up quite quickly I guess?

Also, if the substituted opcodes have the same size as the original java bytecodes, one would even be able to create a patcher that can revert the "coddified" code to normal java bytecode, to be able to make partial use of pure java decompilers I guess, or in the opposite way make it easy to modify existing java decompilers to process the switched opcodes instead. But I guess the substitutions aren't all that simple, or are they?

Have you made any research in this area, i.e. regarding which opcodes are exchanged compared to pure java, and in what way they are exchanged?

Since your loader parses the main cod file structures, I guess you also have quite some knowledge about how much these structures (i.e. everything in the file except the pure bytecode) differ from normal java class files too? Is it a big difference?

Hexxx
November 29th, 2006, 06:19
Not so simple as it seems. Of course i've already compared BB jvm to Sun Jvm. Simple bytecodes such as iload are substituted. But all the call and goto instructions are quite different.

The filesystem in BB is based on a set of databases. When the .cod file is uploaded to device. It is split into several parts: header with code, relocations, data, etc Each part is written to the corresponding database. All that stuff does so called Javaloader.
The header of .cod file is a template, which is filled with record Id's by javaloader after .cod file was split into database records.

So when JVM runs it accesses the databases. Did you ever think why the BB device are poor featured and starting so slow? The database mechanism is so god damn slow.

Returning to JVM. All the call and goto instruction are handling the database requests. So when it needs to call some function from other .cod file. It does another database request...

fritzFS
November 29th, 2006, 14:22
This also sounds like valuable information:

http://drbolsen.wordpress.com/2006/11/29/answering-the-questions/

Hexxx
November 29th, 2006, 15:24
i've sent the source code to fritzFS

fritzFS
November 29th, 2006, 16:57
Ok, guys, here it goes ...

Thx hexxx

dELTA
November 30th, 2006, 06:22
Very nice information Hexxx, and thanks also for the tool! Do you have, or know of, any other specialized tools that might be of assistance when attempting to reverse Blackberry apps?

And nice link fritzFS, I'll include the info here for documenting purposes:

Quote:
COD file is a result of conversion of a normal java application. RIM provides a special tool which allows to do that - rapc.exe. The first thing you can notice about this tool is that it contains two parts - rapc.exe and rapc.jar. The first part seems to be a simple wraper around jar file which looks like a main code repository. But quick look on rapc.jar brings you a bad news - it is obfuscated by RetroGuard (http://www.retrologic.com). Well, nobody expected that it would be easy. But an old trick (http://www.multimedia.cx/pre/re-retroguard.html) with RetroGuard still works fine. The result of deobfuscation is still far away from a normal java source code but it gives us a nice starting point - unique identifiers for functions, variables and constants. The next magic word is Refactoring. It is probably the most boring and in the same time interesting part of the process. At this stage we are looking for any clue inside of the code - memory references, constants, application messages, and etc. Once a clue is found we slowly progress forward from this point trying to trace all usage of discovered constant or function, replacing non-sense identifiers to functional ones. Imagine yorself to be a kind of Sherlock Holmes investigating a difficult case. Lucky for us RIM left a lot of clues inside.

Hexxx
November 30th, 2006, 07:06
The JVM in the device firmware was identical to the that one in the simulator. So reversing the simulator (jvm.dll) instead of reversing the arm code in the firmware is good idea. I can tell about the firmware if you're interested.

dELTA
November 30th, 2006, 07:13
Good to have that confirmed about the simulator, thanks!

And of course we're interested to hear about the firmware!

JMI
November 30th, 2006, 07:17
More information is usually better than less information.

Regards,

Hexxx
November 30th, 2006, 09:21
RimOS is based on AMX. The system messaging system, tasks, memory all was like AMX in 6xxx models. In 7xxx it was changed a bit, then in 8xxx they totaly refactored the code and used the other compiler so the quality of code has changed dramaticaly. The firmware and ramloaders used to update the firmware are digitaly signed. There's no way to hack the signature it's RSA- 2048 based. So, you can't patch it. The firmware updates usually consist of one file with arm code and mutiple .cod and .alx files.
The arm code file for GSM device is placed at path like this:
C:\Program Files\Common Files\Research In Motion\Shared\Loader Files\7100-vesion\GPRS\
There's a file named rimYYYYx.bin
where YYYY - model, x - Generation (g - gsm, i - iden, c - Cdma)
For example:
rim7100g.bin - Firmware for Blackberry 7100, it's a GSM model.

When the device starts it runs bootloader (the device lights the led), then it checks the signature of the firmware, starts the firmware, firmware code setups the hardware and runs the system task. The last task that starts is RIM_TASK it's a JVM task. Then JVM loads all the .cod files checks their validity and starts running the "java" code.

Hexxx
November 30th, 2006, 09:50
Quote:
[Originally Posted by JMI;62763]More information is usually better than less information.

Regards,


Having all the source code of MS Windows doesn't help to write TDI drivers at all

Better to have a little valid information then a lot of invalid.

dELTA
November 30th, 2006, 10:18
Very interesting information Hexxx, thanks again!

C'mon people, aren't there any aspiring Blackberry reversers here who'd like to make use of this excellent source of information while its available, and ask some further questions or discuss some aspects of Blackberry reversing?

And Hexxx, what are you currently working on in the field of Blackberry reversing? Do you feel "stuck" at some point? Are you perhaps even doing something that would benefit from a collaborative effort?

Hexxx
November 30th, 2006, 10:49
I felt stuck for half year. Now i'm just sick and tired of reversing it.

fritzFS
November 30th, 2006, 11:04
dELTA,
if I understood Hexxx correctly, it would be good to reverse the jvm.dll together even though it sounds like a lot of work.

Am I right or is it pointless?

drbolsen
November 30th, 2006, 19:38
Hi guys,

I was afraid that nobody was interested in bb reversing so it is a nice surprise to me to see here a number of people doing the same stuff

dELTA
December 1st, 2006, 06:05
Hey drbolsen, I'm glad you saw my note on your blog, nice to see you! Ok, people, now we have google's both most prominent people on the web reagrding the subject of Blackberry reversing here, so make it count.

So, drbolsen, what's your current view on Blackberry reversing, and interests in it? Are you working actively on some aspects of it at the moment? Something interesting to share or discuss perhaps? Welcome to the board either way, here there are always "a number of people interested in" most reversing subjects, and also many very skillful and bright, so feel free to bring any reversing discussions you like here!

And fritzFS, you are indeed right about that it would be good to reverse the jvm.dll together, care to take the first shot?

fritzFS
December 1st, 2006, 08:53
Ok, couple of questions first:

Did they wrote JVM from the beginning or modified original?
At that time, Sun didn't yet publish Java under GPL so how would they get the original source?

I downloaded Java HotSpot (VM) source and looked at it, it's not easy to understand it right away (1500 C/C++ header and source files, 250 000 lines of code).

Basically, what I'm trying to ask is this:
This JVM.DLL is some kind of stripped version of original and it's only connection to original is that it works on same principle, so it's useless to compare original JVM code with this one since the original is too complex?

I hope someone understood me

Oh, btw, for those who didn't download it yet:
http://download.java.net/openjdk/jdk7/

drbolsen
December 1st, 2006, 10:05
Hey guys, thank you for nice words and a warm welcome.

Well, I am still interested in BB reversing and I am more than happy to share information I have got so far. Two heads are always better than one. I think it worths to say that my participation in this project directly depends on my future workload. Work is work, BB is for fun.

Although I don't think that it would be very dificult task after all. It took around a week to create a script I had published on my blog. Publish it was far bigger problem for me, he-he.

Analysing rapc.jar is not such difficult even with obfuscation and even for me (I am not a java guru at all, lol , but some java stuff I had to learn from books like Java for Dummies ) as RIM left a lot of clues and UI(or log?) messages inside of the code.

I hope that it would be a good start. Check my script it works fine and it gives you idea where to dig at first. Then we can discuss a vector of work and go ahead. What do you think ?

Cheers

Hexxx
December 5th, 2006, 04:02
fritzFS, as i can see they've taken the Sun's VM code reviewed it, and then wrote their own. There are some places that look similiar to Sun.

drbolsen, to make it work we need the java reversers. Not those who can just decompile jar using jad, but people who knows/reversed the core of Java virtual machine. I've stuck on understanding how the machine works. I saw where the opcodes are executed but i couldn't uderstant how it all works together. How the variables are presented? What are the virtual registers that RIM JVM uses? How it manages the classes and methods? There is multitasking under java. It's not a single process runnig on one JVM. There are multiple processes, there is interprocess communication within JVM processes.

dELTA
December 5th, 2006, 11:26
Thanks for your input drbolsen. This "script" you are talking about, is it the template available in the top post on this page:

http://drbolsen.wordpress.com/2006/11/

Or is it something else that I cannot find?


And Hexx, depending on how much is modified between normal Java class files and COD files (as díscussed previously in this thread, and which does not seem to be that much?), will it really be necessary/efficient to reverse the entire BB JVM? Wouldn't it be easier to focus on the parts that differ, and then take the rest of the knowledge from the normal Java VM?

Also, as long as we can patch/modify the code in the COD files, we shouldn't necessarily have to understand the entire inner workings of the BB JVM, or have I missed something important here?

And you (i.e. Hexxx) also ask "What are the virtual registers that RIM JVM uses?". Does it really have registers? The normal Java VM is entirely stack based, without any registers at all, and if all that's modified from normal Java class files to COD files is some goto/call operands, it would seem like they use the exact same model when it comes to this aspect, right? Otherwise there would be much more severe tranformations of code I think.

drbolsen
December 5th, 2006, 18:28
dELTA: Yep, mate that one. Or direct link here (for documentation purpose ) http://www.geocities.com/drbolsen/CODTemplate.txt ("010 Edit Template")


Hexxx Well, I am defenitely not a person you are looking for. So probably it worths to keep looking around for somebody with more knowledge on the subject.

My goal is quite simplier. Try to reverse internal structure of COD file and if it is possible then to find a way to convert COD back to jar/jad by reversing internals of rapc or even reusing functionality of rapc. If it is not possible I am still happy with COD structure documented.

Cheers guys.

fritzFS
December 5th, 2006, 19:59
Guys, I've stumbled across new interesting paper on Java Obfuscation.

http://www.milw0rm.org/papers/117

He seems familiar with Java VM, maybe we can ask him to join this discussion?

subere(at)uncon.org

Update : blackberry-related document http://www.milw0rm.org/papers/119

Hexxx
December 6th, 2006, 04:48
Can't say what will be easier: refactoring the rapc.jar or reversing the jvm.dll. Maybe you're right... After the refactoring the rapc it should be clear how BB jvm is related with sun's. Let's look what's inside rapc.

dELTA
December 7th, 2006, 06:48
Nice and informational Blackberry security article fritzFS! I'm attaching it here, for archival purposes.

Hexxx, sounds exciting that you're going to take a look at rapc!

And drbolsen, you mentioned earlier that you already did some successful analysis of rapc.jar, do you maybe have something interesting to share regarding this already?

fdrake
December 9th, 2006, 19:18
Great to see other people working on this as well. I've been interested in reversing the 'berry for quite a while, but didn't actually start doing anything about it until a few weeks ago.

I'd like to try and summarize all the work that I know of in this area, so that we at least have some kind of baseline, and so some of the misconceptions I undoubtedly hold might get corrected.

Essentially, there are three -- well, for the sake of completeness, make that five -- routes to the Inside Of A Blackberry.

Through the tether: Unsurprisingly, most of the previous work has been done on this route. The tether works as a control channel for the 'berry so reversing the protocol has some legitimate uses, like allowing 3rd party PIMs to synch up. But there are also reasons to think that this control channel can be used for system debug/diagnostic purposes. (Ourpurposes.)

If you look through JavaLoader.exe, the command line utility that comes with the JDE, you can see the remenants of several intriguing commands having to do with firmware, the boot loader, and state patching, that are no longer actually supported. (At least not by the version RIM gives us). Also, the 'berry is based around an Intel processor and Intel flash memory. If you poke around Intel's development kits for these, you'll see that a USB connection is often used to control these chips (as a faster, albeit higher level alternative to a JTAG connection). It seems possible that this may still be supported. (A point also made in Phenolit's presentation.)

The most thorough, 'tho dated, resource comes courtesy of the Cassis project at http://www.off.net/cassis/. They reversed the serial version of the protocol, and newer 'berrys use a USB connection with apparently a slightly different protocol. Fortunatly, another group has made some headway on reversing this, and have made an early version of their "Barry" software available at http://www.netdirect.ca/software/packages/barry/hacking.php.

Next steps:
- Use IDA on JavaLoader.exe to try and find other clues about missing commands.
- See if any of the Intel utilities (eg, USB versions of Jflash and IFMPWIN) can communicate with the berry.
- Good old brute-force: try sending command ID's from 00 to FF and see which ones get a response.


Through COD files: This is the route that has attracted the most interest in this forum, and I think correctly so. If we can translate a COD file into somewhat readable Java source, we should be able to learn a _ton_ about the blackberry's internals.

Heck, just doing a "strings" on something like net_rim_os.cod is mighty interesting, with its indications of the existence of a very close to the metal network logging facility that I'd love to get my hands on. And this route sure seems very feasible. RIM explicitly says that they rely _solely_ on the preverify.exe step for protecting their source, rather than any additional obsufucation. (So no variable names-- not the end of the world.) And as Hexx has pointed out, it's possible to decompile rapc.jar to see how things are put _into_ a .cod file.

At the same time, I do have to admit that it's not as trivial as I expected. I've taken the hello world sample, compiled it, preverified the classes, then 'manually' ran rapc to construct the .cod. But even with Dr. Bolsen's file format template [http://www.geocities.com/drbolsen/CODTemplate.txt], it was not at all obvious where the preverified classes are included in the .cod file. Nor did I see the zip headers that I expected.


Next steps: - Trace a particular class through rapc.exe to see where and how it gets compressed (perhaps using oSpy.)
- Run a large number of classes through preverify.exe in order to automatically construct an opcode mapping (assuming it's 1 to 1)
- Continue reversing rapc.jar

Through Hardware: Anyone who has ever stolen sattellite TV service knows that the JTAG is the path to salvation, and so who am I to argue? It would indeed be wonderfull if we could get access to the JTAG, or even just be able put a logic analyzer on the 'berry's bus.

Surprisingly little work has been done on reversing the blackberry's hardware; the main exceptions are actually the commercial "tear down" shops (eg., http://www.commsdesign.com/printableArticle/?articleID=191902180)

I have opened up my fair share of 'berrys and can point out a few things.
- The main processor is a flip-chip BGA, and trying to get that thing off the mainboard intact (so as to get access to all the PINS), is ... theoretically possible, but not even remotely realistic.
- Most 'berrys do have a bunch of prominent test points accessible next to, or beneath, the SIM card. I have the very vague impression that the GSM phone unlocker community (a subculture in its own right) uses these test points for unlocking the phone, but I may be confused.
- On a 8700g/c, you can see a bunch of lines running from the processor to the off-chip flash. It might be possible to put a logic analyzer on these.


[[ Running out of time, so let me race through the last two, since they are less important anyway... ]]

Through BES: Although we have been focused on the handheld alone, a very big part of the RIM value proposition is the Blackberry Enterprise Server. There is the incoming side (so how BES controls the handhelds), and the outgoing side (how BES talks to RIM via SRP.)

This is where the Phenolit presentation was most interesting. (I'm particularly curious how they managed to do such a throrough job of reversing the SRP protocol.)

It is possible to download a demo of BES, as well as a bunch of BES support tools. I have also been amazed at how much info a BES gives out through SNMP.

Through RF: It would be interesting to monitor what exactly goes over the air to the berry. We know that some special commands exist, most notably, it is possible for a BES admin, or RIM, to send a special command to a blackberry that causes it to essentially self-destruct. (It erases all of memory very thoroughly, using the government approved process of first writing all FFs, then all 00s, for something like 5 passes.) What other commands might exist?


fd.

JMI
December 9th, 2006, 20:16
Thank you for a VERY informative first post and welcome aboard.

Regards,

drbolsen
December 11th, 2006, 21:37
nice post fdrake. Love it.

Just some comments to extend a bit your information.

USB stuff: we did some work in this direction, even we were able to get usb trace by using USB Monitor tool to intercept communication between BB and pc box. A bit surprise but info was in clear text as far as I remember. Considering that a communication link is still a subset of entire BB we prefered to go for java reversing as it may give more results.



JTAG stuff:
considering cost, complication and lack of equipment it seems to be not a very attractive way althouth it may be the last resort in case everything else failed.

RAPC lovely : It seems to me more prominent way to get in. In fact the most (if not all) of cod structures, flags and values are hard coded in rapc.jar. We found that rapc.jar treats cod files as array of bytes with fixed or relative offsets either from begining of file or begining of each of two segements. So information from our template, which is still in a very early stage of development, is organized in the same way. We stopped at class structure because of some personal circumstances required a bit of attention but it is over and we are ready to keep going.

I think a "real decompilation" of cod happens only when we have the entire cod file structure documented and understood. The benefits of this way is that we need only to reverse cod back to class (jar) and then we have a huge set of tools already developed for java reversing.

Additionally answering dELTA to his question I am going to publish decompiled and partitially refactored rapc.jar we used for our work so it may be used as a base for future collective work.

BES stuff: Unfortunatelly we could not get BES to have a look on it. It may be a good start to get an idea how are the policies distributing or internals of RIM network infrastructure working. Although I think there won't be a lot info about internals of BB devices. I think BES server is another level of RIM application model - more infrastructure focused rather loca (physical).

Cheers

Hexxx
December 13th, 2006, 06:07
fdrake, about the hardware. There were Analog devices ARM7 processors in 6xxx and 7xxx devices. And also there was a set of pins under the battery. I think it was JTAG socket. As i remember 8700 has Intel pxa (ARM9) cpu.

Hexxx
December 23rd, 2006, 00:54
As i've said i've compared the BB's JVM to jdk 1.5.0 jrl. But that was a full JVM, not the one used in the devices i.e. not J2ME. But now sun opened the source code for J2ME too!
https://phoneme.dev.java.net/downloads_page.html

drbolsen
January 16th, 2007, 05:46
hey guys!

we did it! http://drbolsen.wordpress.com/2007/01/16/it-is-over-now/

We expect to publish a working proof of concept tool in two-three weeks time. Be in touch.

dELTA
January 16th, 2007, 06:19
Extremely cool! We're indeed looking forward to the upcoming tool(s) and info! Great work!

drbolsen
January 25th, 2007, 04:36
Hi guys,

our progress information http://drbolsen.wordpress.com/2007/01/25/progress-update/

Some technical stuff :

1.RIM uses own opcodes different from standard. Examples:

"jumpspecial_lib"
"enter"
"enter_wide"
"putfield_return"
"putfield_return_wide"
"aload_0_getfield"
"aload_0_getfield_wide"

Does it look familiar for somebody ?

2.All literals are obfuscated. No obfuscation matrix in cod file , but in rapc.jar

3.A list of some classes from net_rim_os.cod

package net\rim\device\internal\synchronization\ota\session

CpTicketHolder.java
DeviceSession.java
IgnoredSession.java
Lock.java
ServerSession.java
Session.java
SessionManager.java
SessionManagerState.java
SyncModeRequests.java
TriggerSyncEvent.java

4. coddec future release would be in a form of a patch to rapc.jar. Yes, most of parsing and decompilation stuff was left inside of rapc.jar by RIM.

We would probably need some help to convert disassembled opcodes to a valid java source code. Is there somebody here has had expirience in that ?


dELTA
January 29th, 2007, 12:44
Again, very interesting to see your nice progress DrBolsen! Even better to hear about your upcoming plans, looking forward to the decompiler!

About turning java opcodes into java source code, wouldn't it be quite efficient to base this process on already-existing java decompilers? Anyone know a good open-source java decompiler for this purpose?

Hexxx
January 30th, 2007, 03:45
Literals deobfuscation you can find in the source code that i've attached on the first page of this topic.

drbolsen
January 30th, 2007, 15:39
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

Hexxx
January 31st, 2007, 04:07
drbolsen, i could implement your decompiler as an IDA processor module if you share the knowledge. It will be much better than inventing another tool.

drbolsen
January 31st, 2007, 08:08
Quote:
[Originally Posted by Hexxx;64074]drbolsen, i could implement your decompiler as an IDA processor module if you share the knowledge. It will be much better than inventing another tool.


Look, when we started our work we were completely confident that our script could do the most of work. But getting more and more inside we realized that it wouldn't be a such trivial task as it seemed at the begining.

As you wrote earlier in this thread RIM used a bunch of tables. That probably wouldn't be a big problem but the links between the tables is a complete mess. There are tables, references tables, classes tables, fields tables , routine tables, type tables, fixup tables of everything mentioned before, etc. and plus these tables are not just only for one class file but for the entire package which may incude hundreds of classes, plus if you are still not convinced there are a size limit for a cod file which splits the cod file to modules so we have even more tables dealing with all relationships and crosslinks between modules. Believe me that we were quite disappointed when we figured that out.

But fortunatelly for us we found another way and I actually think this way is much, much easier and faster then writing anything own, additional benefit of this way - it is almost error free because the guys from RIM already did this work for us So we can save a lot of time on beta-tests ...

Additionally, probably I am wrong but I don't see any value to write a module for IDA. Dealing with bytecodes is a really boring exercise especially when you may have 100% working source code, make any changes you want in it then compile it again. I would probably like an idea to create a tool similar to Javabite to patch a cod file without re-compiling it again to for example change classes or fields attributes, or injecting some arbitrary code in it. But a module for IDA ? Trust me I use IDA quite often and I know it's a great tool but I think for java stuff it is not quite suitable.

By the way our task is not complicated at all. We have written probably only two pages of code to achive our current results. The only obstacle I can see for now it is how add a decompilation module, but even this one is not very complicated considering a number of open-source java decompiliers around.

Cheers

Hexxx
January 31st, 2007, 08:45
Yes, the main aim of having processor module for IDA is to be able to patch the .cod files. By the way there's a source code for java processor module included in IDA SDK. So i think it should be an easy task to make it work with .cod files.

We don't know how much time it will take you to finish the coddec and will you be able to finish it (life is so unpredictable). So it'll be good to have the some kind of basic tool - IDA processor module.

drbolsen
January 31st, 2007, 19:02
Quote:
[Originally Posted by Hexxx;64078]
We don't know how much time it will take you to finish the coddec and will you be able to finish it (life is so unpredictable).


LOL

drbolsen
January 31st, 2007, 19:42
Update of our template
http://drbolsen.wordpress.com/2007/02/01/update-of-cod-template/

cheers

Hexxx
February 1st, 2007, 02:02
Quote:
[Originally Posted by drbolsen;64086]LOL


I saw too many good projects, which were never finished just because the author had suddenly lost the interest in continuing it.
The sourceforge is full of such examples.

drbolsen
February 1st, 2007, 06:42
http://www.geocities.com/drbolsen/opcodes.txt

there is a list of RIMs opcodes, the left column is an actual opcode in decimal format and the right column contains its relative mnemonic.

cheers

dELTA
February 2nd, 2007, 18:06
Thanks for the info, I'll include it here in the thread for archival purposes.

Quote:
OC(dec)Descr
#0 breakpoint
#1 invokevirtual
#2 invokeinterface
#3 invokenonvirtual
#4 invokenonvirtual_lib
#5 invokespecial
#6 invokespecial_lib
#7 invokestatic
#8 invokestatic_lib
#9 iinvokenative
#10 invokenative
#11 linvokenative
#12 jumpspecial
#13 jumpspecial_lib
#14 enter
#15 enter_wide
#16 xenter
#17 xenter_wide
#18 synch
#19 synch_static
#20 clinit_wait
#21 ireturn_bipush
#22 ireturn_sipush
#23 ireturn_iipush
#24 ireturn
#25 ireturn_field
#26 ireturn_field_wide
#27 areturn
#28 areturn_field
#29 areturn_field_wide
#30 lreturn
#31 return
#32 clinit_return
#33 noenter_return
#34 aconst_null
#35 iconst_0
#36 bipush
#37 sipush
#38 iipush
#39 lipush
#40 ldc
#41 unused_29
#42 ldc_unicode
#43 unused_2b
#44 iconst_1
#45 arrayinit
#46 unused_2e
#47 tableswitch
#48 unused_30
#49 iload
#50 iload_wide
#51 aload
#52 aload_wide
#53 lload
#54 lload_wide
#55 iload_0
#56 iload_1
#57 iload_2
#58 iload_3
#59 iload_4
#60 iload_5
#61 iload_6
#62 iload_7
#63 aload_0
#64 aload_1
#65 aload_2
#66 aload_3
#67 aload_4
#68 aload_5
#69 aload_6
#70 aload_7
#71 istore
#72 istore_wide
#73 astore
#74 astore_wide
#75 lstore
#76 lstore_wide
#77 istore_0
#78 istore_1
#79 istore_2
#80 istore_3
#81 istore_4
#82 istore_5
#83 istore_6
#84 istore_7
#85 astore_0
#86 astore_1
#87 astore_2
#88 astore_3
#89 astore_4
#90 astore_5
#91 astore_6
#92 astore_7
#93 putfield_return
#94 putfield_return_wide
#95 putfield
#96 putfield_wide
#97 lputfield
#98 lputfield_wide
#99 getfield
#100 getfield_wide
#101 lgetfield
#102 lgetfield_wide
#103 aload_0_getfield
#104 aload_0_getfield_wide
#105 putstatic
#106 putstatic_lib
#107 lputstatic
#108 lputstatic_lib
#109 getstatic
#110 getstatic_lib
#111 lgetstatic
#112 lgetstatic_lib
#113 i2b
#114 i2s
#115 i2c
#116 i2l
#117 l2i
#118 ineg
#119 lneg
#120 iinc
#121 iinc_wide
#122 iadd
#123 ladd
#124 isub
#125 lsub
#126 imul
#127 lmul
#128 idiv
#129 ldiv
#130 irem
#131 lrem
#132 iand
#133 land
#134 ior
#135 lor
#136 ixor
#137 lxor
#138 ishl
#139 lshl
#140 ishr
#141 lshr
#142 iushr
#143 lushr
#144 lcmp
#145 if_icmpeq
#146 if_acmpeq
#147 ifeq
#148 if_icmpne
#149 if_acmpne
#150 ifne
#151 if_icmpgt
#152 ifgt
#153 if_icmpge
#154 ifge
#155 if_icmplt
#156 iflt
#157 if_icmple
#158 ifle
#159 ifnull
#160 ifnonnull
#161 goto
#162 goto_w
#163 lookupswitch_short
#164 lookupswitch
#165 newarray
#166 multianewarray
#167 arraylength
#168 newarray_object
#169 newarray_object_lib
#170 multianewarray_object
#171 multianewarray_object_lib
#172 baload
#173 saload
#174 caload
#175 iaload
#176 aaload
#177 laload
#178 bastore
#179 castore
#180 sastore
#181 iastore
#182 aastore
#183 lastore
#184 new
#185 new_lib
#186 clinit
#187 clinit_lib
#188 athrow
#189 instanceof_array
#190 checkcast_array
#191 instanceof
#192 instanceof_lib
#193 checkcast
#194 checkcast_lib
#195 checkcastbranch
#196 checkcastbranch_lib
#197 checkcastbranch_array
#198 instanceof_arrayobject
#199 instanceof_arrayobject_lib
#200 checkcast_arrayobject
#201 checkcast_arrayobject_lib
#202 monitorenter
#203 monitorexit
#204 nop
#205 pop
#206 pop2
#207 dup
#208 dup2
#209 dup_x1
#210 dup_x2
#211 dup2_x1
#212 dup2_x2
#213 swap
#214 unused_d6
#215 isreal
#216 op01xx
#217 stringlength
#218 stringaload
#219 invokestaticqc
#220 invokestaticqc_lib
#221 enter_narrow
#222 invokevirtual_short
#223 ldc_nullstr
#224 unused_e0
#225 unused_e1
#226 unused_e2
#227 unused_e3
#228 unused_e4
#229 unused_e5
#230 unused_e6
#231 unused_e7
#232 unused_e8
#233 unused_e9
#234 unused_ea
#235 unused_eb
#236 unused_ec
#237 unused_ed
#238 unused_ee
#239 unused_ef
#240 unused_f0
#241 unused_f1
#242 unused_f2
#243 unused_f3
#244 unused_f4
#245 unused_f5
#246 unused_f6
#247 unused_f7
#248 unused_f8
#249 unused_f9
#250 halt
#251 threaddeath
#252 unused_fc
#253 unused_fd
#254 unused_fe
#255 unused_ff
#256 fadd
#257 dadd
#258 fsub
#259 dsub
#260 fmul
#261 dmul
#262 fdiv
#263 ddiv
#264 frem
#265 drem
#266 fneg
#267 dneg
#268 i2f
#269 i2d
#270 l2f
#271 l2d
#272 f2i
#273 f2l
#274 f2d
#275 d2i
#276 d2l
#277 d2f
#278 fcmpl
#279 fcmpg
#280 dcmpl
#281 dcmpg
#282 stringarrayinit
#283


Btw, drbolsen, will you release your full information (and source code?) at the same time as the coddec tool, so that other good Blackberry reversers like Hexxx can build upon it further?

.:hack3r2k:.
February 24th, 2007, 08:37
Quote:
[Originally Posted by drbolsen;64092]http://www.geocities.com/drbolsen/opcodes.txt

there is a list of RIMs opcodes, the left column is an actual opcode in decimal format and the right column contains its relative mnemonic.

cheers


Well name ur price. I need it for private uses. Use PM

Br

drbolsen
March 29th, 2007, 08:47
Check this guys

http://drbolsen.wordpress.com/2007/03/29/headers-from-8700-v410284_p200120-package/

Cheers

JPsor
March 30th, 2007, 23:58
http://drbolsen.wordpress.com/2006/12/12/quick-winner/

DrBolsen,

I'm having trouble compiling the source you posted.

I've seen the decompiled(JAD) version of the net.rim.tools.a.a from rapc.jar.

When I try compiling the code, javac complains "package net.rim does not exist".

No complaint about rapc.jar(with net.rim.tools.a.a.a).

The command line I'm using is:
javac -cp .\;rapc.jar;..\lib\net_rim_api.jar Program.java

Program.java holding the code from your blog. Rapc.jar is in the current directory with Program.java.

It must be something simple. I'd appreciate any help with this.

drbolsen
April 1st, 2007, 22:00
Try to use this code instead

///////////////////////////////////////////////
// net.rim.* works fine in X-Develop Pro but causes error message
// when compile with javac

import net.rim.tools.a.a.*;

import java.io.*;

public class Program

{

public static void main(String[] args)

{

net.rim.tools.a.a.a(args);

}

}

save it as Program.java then compile using

javac -classpath rapc.jar; Program.java

run

java -classpath rapc.jar; Program <args>

I assume that rapc.jar is located in the same folder as Program.java

I have checked on my comp it works.

Hope that helps

JPsor
April 3rd, 2007, 02:23
Quote:
[Originally Posted by drbolsen;64751]Try to use this code instead

///////////////////////////////////////////////
// net.rim.* works fine in X-Develop Pro but causes error message
// when compile with javac


This works now.

Quote:
I have checked on my comp it works.

Hope that helps


Thanks

randyman
July 11th, 2007, 00:17
Have you guys made any progress since the last post? It's a shame to see such a great thread die.

Keep it going!

-randyman

drbolsen
July 14th, 2008, 05:45
Coddec released

hxxp://drbolsen.wordpress.com/2008/07/14/coddec-released

drbolsen

Shub-nigurrath
July 15th, 2008, 03:57
really interesting contribution mate.
Little OT for the rest of you: I would love to receive a tutorial on this platform for our coming ARTeam's eZine.. contact me if you are interested. Any contribution is welcome!

dELTA
July 16th, 2008, 05:00
Very nice work drbolsen, and thanks for the heads up too!

CRCETL:
http://www.woodmann.com/collaborative/tools/Coddec


Also, some of the other tools/resources referenced in this thread:

http://www.woodmann.com/collaborative/tools/RIMJava

http://www.woodmann.com/collaborative/tools/COD_File_Analysis_Template

drbolsen
July 16th, 2008, 06:35
dELTA, no worries mate More stuff`s coming ...

Look, this RCE library looks awesome. I love it

dELTA
July 16th, 2008, 07:07
Hey drbolsen, I'm glad you like the Collaborative RCE Tool Library. Please feel free to update coddec in it yourself if you want, and submit your future tools to it too.

Sounds great with more stuff coming anyway.

One question, why are some classes named so strangely in the coddec source, with only one-letter names? Is the source obfuscated, or decompiled from obfuscated class files? It makes it much harder to follow anyway. I spoke to Hexxx, and he is still interested in the possibility of using this knowledge to create an IDA processor module for Blackberry/COD, but he was also a bit puzzled by this hard to follow naming convention?

drbolsen
July 16th, 2008, 23:52
Quote:
[Originally Posted by dELTA;75899]
One question, why are some classes named so strangely in the coddec source, with only one-letter names? Is the source obfuscated, or decompiled from obfuscated class files? It makes it much harder to follow anyway. I spoke to Hexxx, and he is still interested in the possibility of using this knowledge to create an IDA processor module for Blackberry/COD, but he was also a bit puzzled by this hard to follow naming convention?



from drbolsen.wordpress.com:

Quote:

Well, it is not actual coddec we use “in-house” but a very first working version of it.


if you recall from my earlier posts here or on our blog we could de-obfuscate and rebuild the original rapc which "surprise-surprise" had a working parser and analyzer of cod files inside. We extended this version by using knowledge we had acquired reviewing RIMOS so the released tools is actually the result of all this work.

Internally we use more advanced version of the tool - it has more capabilities, it can decompile cod files, and etc. But the core - parsing and analysis - remains the same. At the moment we don't have any plans to release the extended version.

Regarding some funky classes - most of the important classes have been restored so what's been left unresolved either non-important or compiler-related as rapc's primary purpose was to compile java code to cod files, not to decompile them

Whatever you are planning to do - start with coddec.java first, follow the application flow and it will guide you through the important cod structures.

Regarding HEX's work, it is good if he wants do something in this direction and he has time to do so , however personally I am a bit skeptical about that. Anyway all cod structures can be found in /net/rim/tools/complier/codfile folder so if HEX's planning to keep building this IDA loader then this is the right place to start with.

drbolsen

ia!
September 10th, 2008, 03:17
On another forum (pinstack.com) I read the following:

Recent versions of the blackberry loader utility - loader.exe, allow you to dump the nonvolatile store of the blackberry when launched from the command line:
loader.exe /dump fileName The loader will start up in console mode and create a raw dump of the flash filesystem.

---
This works as posted. When I launched loader from the default directory,

c:\program files\common files\research in motion\apploader\loader /dump whoKnew.dmp

a new console window popped up (instead of the usual gui) with a few interesting status messages during the dump creation and -

whoKnew.dmp was created in apploader
Dump-(yyyy-mm-dd).log was created in temp.

The dump log indicated that the dumpfile was requested to be encrypted and captured sector-by-sector, request/response results. I had to set up verbose logging in registry to get to this level of specificity - HKCU\Software\Research In Motion\BlackBerry\Loader CPFLogLevel DWord 0x6 as was suggested in the pinstack post (subsequently edited out).

It turns out that the loader console responds to ^q/^s flow control commands, so its sure behaving as a serial console.

whoKnew,
-ia!

berryable
October 2nd, 2008, 15:22
if you have an app in mind, i can attain valid serials for numerous bb apps.

cheers,
http://berryable.wordpress.com ("http://berryable.wordpress.com")

myraddin
October 15th, 2008, 02:03
Has anyone had luck (knowledge ) compiling coddec ?

I cannot get past that 'deliberately' left bug in net.rim.tools.compiler.codfile.DataSection:590

Anyone has a clue?

chadwik66
December 1st, 2008, 17:30
Quote:
[Originally Posted by myraddin;77378]Has anyone had luck (knowledge ) compiling coddec ?

I cannot get past that 'deliberately' left bug in net.rim.tools.compiler.codfile.DataSection:590

Anyone has a clue?


I've only been able to get this code to compile using X-Develop. NetBeans and eclipse don't seem to work.

ia!
December 26th, 2008, 02:36
The guy who "shared" the howto code on BB reversing will not post any more on this topic anywhere. Some of us have worked very hard to bolster the security model, while others have intended to break the security for personal gain.

If he is also responsible for leaking the MFI multiloader code, his is in very hot water with the authorities. So the casual reader should not take his lack of response personally.

-ia! (information assurance!)