Hello,

have anyone tried any reverse engineering/cracking on this?

Are there any tools or documentation?

thank you

http://www.blackberry.net/developers

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

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 ;-)

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).

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 :-(

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:

I've also invited Hex to participate in this thread, so let's see if he joins the discussion.

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.

This is "berry" interesting

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.

Thank you. We look forward to your contributions.

Regards,

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?

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

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?

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...

This also sounds like valuable information:

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

i've sent the source code to fritzFS

Ok, guys, here it goes ...

Thx hexxx

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:

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.

Good to have that confirmed about the simulator, thanks!

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

More information is usually better than less information.

Regards,

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.

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.

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?

I felt stuck for half year. Now i'm just sick and tired of reversing it.

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?

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

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?

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/

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

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.

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.

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.

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

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.

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?

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.

Thank you for a VERY informative first post and welcome aboard.

Regards,

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

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.

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

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.

Extremely cool! We're indeed looking forward to the upcoming tool(s) and info! Great work!

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 ?

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?

Literals deobfuscation you can find in the source code that i've attached on the first page of this topic.

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

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

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.

LOL

Update of our template
http://drbolsen.wordpress.com/2007/02/01/update-of-cod-template/

cheers

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.

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

Thanks for the info, I'll include it here in the thread for archival purposes.



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?

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

Br

Check this guys

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

Cheers

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.

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

This works now.



Thanks

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

Coddec released

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

drbolsen

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!

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

dELTA, no worries mate More stuff`s coming ...

Look, this RCE library looks awesome. I love it

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?

from drbolsen.wordpress.com:



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

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!

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")

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.

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!)