I recently wrote an EScreen code generator app for the BlackBerry that I ... General Blackberry forum
Jester an EScreen Code Generator for BlackBerry devices
I recently wrote an EScreen code generator app for the BlackBerry that I thought I would share. To download it, use your BlackBerry browser to visit: http://www.zensay.com/Jester.jad
I usually follow these steps to unlock my EScreen:
1. Start Jester
2. Open the "Help Me!" screen by typing Alt+Shift+H
3. Note down the Bundle Number (this is the number in parentheses found in the "App Version:")
4. Note down the Uptime in seconds
5. Hold down the menu key and switch back to Jester; enter the Bundle Number, uptime and choose a duration
6. Click Calculate
You will then be able to enter the EScreen code by switching back to the "Help Me!" screen and typing in the code. I have tested this on a Bold 9000 and it works. Ideally, if you keep typing the code without any mistakes, then it is possible to move back and forth between Help Me! and Jester (if you can't remember an eight character hex number). If you make a mistake, then I'd recommend closing both Jester and the Help Me screen and starting again. Post any problems, suggestions for improvements or flames to this thread.
I'd like to acknowledge that the information I used to make this application came from this page: http://pastebin.com/fbf3f591
Follow me on twitter: @chopstick_ | Blog: http://chirashi.zensay.com
You get exactly one guess for where the information in that pastebin came from.
There's a TARDIS eScreen generator floating around that does much the same thing, but it wasn't widely announced or distributed. And, while it's nice to see more than one implementation, beware that you may attract the wrath of Miller Thomson LLP, or another legal firm retained by RIM.
I did a lot of reading on the EScreen prior to actually writing or publishing Jester. If I'm not mistaken, you were one of the first to release the algorithm? I understand that you also had to bring your EScreen code generator site down after RIM sicced their lawyers on you. I hope they will leave me alone, let's see. Did you get this algorithm by reverse engineering net_rim_escreen.cod/net_rim_escreen_app.cod or did you find it another way?
Originally Posted by Thyth
Yes, I reverse engineered net.rim.device.internal.EScreens.EngScreenSecurity class in the escreen_app module. Once I was informed about the eScreen (data required and the length of the codes), I knew almost exactly what I was looking for, so the time between the module decompilation and a working test generator was under an hour -- not counting the considerable time spent building a module decompiler. Prior to my publication of the algorithm, people either used stolen credentials for the official generator, or the MFI/MML tool to generate codes. The contents of the pastebin (not including the sample output and sample generator) are verbatim copied from the generator help/info page I had on my site.
I don't know what legal basis RIM really has to request shutdown (they alleged copyright, which is shaky at best), but given that the algorithm is widely disseminated now, threats were fully counterproductive. The only thing it's really accomplished is poisoned my perception of the company and the platform. Google and the Open Handset Alliance treat developers as assets rather than as threats, so, I'm more than happy to direct my talents toward Android now.
Good luck in not getting sued.
Sorry, but I have to ask; did you write your own decompiler or did you pick up where coddec left off? Either way, I can imagine it was a significant effort; I am trying to recreate my own version of coddec based on the same principles, but with the newer rapc.jar. Also, did you not try to reverse engineer the EScreen unlock algorithm from MFI/MML directly?
I could not agree more regarding the fact that developers are not treated with as much "affection" as Google would. I haven't had the displeasure of dealing with their legal team yet, but can imagine how the process will certainly sour your perception of the company. I can see myself jumping ship at some point in the future as well, but for now, I will stick to digging up as much as I can about the device and OS.
Thanks for taking the time to respond.
I began building the decompiler well before the coddec disassembler was released. I used some of the info published by the coddec group (opcode identities, and the COD templates), on top of reverse engineering rapc.jar that RIM provides. I'm doing something similar with the Dalvik VM right now (already generates reasonable high level source, but with lots of single use temporary variables, and funky control flow representation), but the job is considerably easier than the BlackBerry VM (since the Dalvik VM specifications are open and well documented). Deobfuscating the rapc classes and making meaningful sense out of what was happening took about 18 months; building something similar for Dalvik has taken less than four weeks.
I chose to decompile the COD rather than the MML/MFI tool for two main reasons. I knew that I was dealing with some sort of hash, and unless you've got the equivalent of a doctorate in applied mathematics, you have no business designing cryptography; thus, I knew I would almost certainly be seeing a standardized cryptographic hash algorithm in use. Related to this point: you don't implement a cryptographic algorithm made available as your platform. By decompiling the module, I got (reasonably) high level Java source code, along with library references to the cryptography routines in use. Extracting that sort of information from an x86 binary is considerably more time consuming.
In any case, I haven't worked on my BB decompiler in a year. It was vastly incomplete, and had problems dissecting certain modules (I didn't fully deobfuscate rapc before making use of it as the dissection core). I did learn a few interesting things about the RIM OS when I pointed it at a full OS installation, though. There are a handful of security vulnerabilities.
By carefully doctoring the way a module is generated, it's possible to invoke restricted API (including OS internals) from an unsigned module -- it will validate and pass the security check, but will produce code that will fail those security checks if decompiled and recompiled. There is a reflection API that is not granted for use by third party developers (even if you buy the $20 signing key) -- though you can use the module doctoring trick to build a library COD that gives you unrestricted access to it. Reflection invocation is OS version specific (since it takes a function ordinal, rather than a name), but could still be used to create a really awesome trojan/virus. Finally, things like the media playback (and forthcoming WebKit based rendering engine for the browser) run as native code without any of the JVM protections -- play a doctored media file, and with some exceptional finesse you will be able to escape the JVM and reach the embedded OS.
RIM device (and infrastructure) security is crunchy on the outside, but chewy on the inside. It's going to be interesting to see what happens when the Webkit based browser is released. It will increase the attack surface area considerably, and may provide a way to own a BlackBerry simply by viewing a malicious web page.
this is great. i wish i could use other pin codes as well, so i could gen codes for other phones.
hi mr. zenc
could u provide me the .alx to downloaded from my desktop ?
because io have a severe problem with my wifi and i wanna to try to fix it throug the escreen
hi mr. zenc
can u provid me with the .alx extension cuz my wifi is corrupted and i wanna fix it through the escreen
i have to downloaded from the desktop
so please help