Page 3 of 5 FirstFirst 12345 LastLast
Results 31 to 45 of 72

Thread: BlackBerry OS

  1. #31
    Hexxx
    Guest
    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.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #32
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    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.
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  3. #33
    drbolsen
    Guest
    dELTA: Yep, mate that one. Or direct link here (for documentation purpose ) http://www.geocities.com/drbolsen/CODTemplate.txt


    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.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  4. #34
    fritzFS
    Guest

    new hope?

    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
    Last edited by fritzFS; December 5th, 2006 at 20:02.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #35
    Hexxx
    Guest
    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.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  6. #36
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    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?
    Attached Images Attached Images
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  7. #37
    fdrake
    Guest

    Post summary -- work so far

    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.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

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

    Regards,
    JMI

  9. #39
    drbolsen
    Guest
    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
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  10. #40
    Hexxx
    Guest
    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.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  11. #41
    Hexxx
    Guest
    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
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  12. #42
    drbolsen
    Guest
    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.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  13. #43
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Extremely cool! We're indeed looking forward to the upcoming tool(s) and info! Great work!
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  14. #44
    drbolsen
    Guest
    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 ?

    Last edited by drbolsen; January 25th, 2007 at 04:39.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  15. #45
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    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?
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •