Got bored tonight. Decided to write this up.
After a little time with my E71, I found it was lacking something. I felt restricted. Held down a bit. I come from a life of open-ness. I like choice. I have a background of Unix and Linux administration. I wear button down shirts and my pet koala's are gay. I am open to choice!
While S60 is an 'open' platform, it is still locked down. No access to specific folders. No access to ROM and RAM sections. Obfuscated API and system calls. Certificate requirement and platform security. There has to be a way out. Windows Mobile has cookable ROM and single user, the iPhone has a root jailbreak, Sony Ericsson has FW RAM patches. There has to be something for S60...
First let's start with installserver. A small daemon that looks over the installation of compiled packages. It checks integrity, entirety, security and installability. ZoRn and FCA are the main characters who lead in the development of the tools used for exploiting the Symbian platform.
I can only assume with my limited knowledge that the best possible ways of patching installserver would be to either forge the key and certificate of every requested header. Modify the data stream and replace it with a spoofed one. This would make it seem that every file is legit and signed.
Another way would be to jump the exceptions that would stop a package from being installed. The latter being the "easiest" to pull off. Decompile, jump all functions leading to denial, recompile. Done.
Now you have to get your modified file into the protected filesystem. I have no idea how HelloCarbide accomplishes this. Essentially it is a root jail/cage break that allows code to be run at a higher TCB level. Only applications that are signed with a valid certificate with high enough privileges are allowed jump parent folders. A possible stack smash or overflow can achieve this, NOP sled to your code in heap that can now do a priv-escalation and you have full capabilities and can run around with scissors.
Another method is the way that BinPDA and SecMan take; AppTrk which is an on-device debugger can set privileges to an application running in kernel memory. You can install a forged root certificate signed and keyed by BinPDA. Now you can install anything signed with a BinPDA cert.
Moving the patched file is relatively easy once the firmware has been compromised to allow you to access the "private" folders of the filesystem. Now I can access system folders, I can access every built-in application, copy it over to a workstation and run it through a decompiler.I can look at every call in every application. I can fuzz it for further exploitation. But what if I don't want to pooch the device by modifiying a required file that can't be replaced?
Enter ROMPatcher. ROMPatcher works on the principle that code can be directly injected into memory, completely on the fly. Patch a section of memory to point to an empty buffer and then insert your code. When that part of the stack is hit by whichever application you're exploiting, your code gets run. ROMPatcher works this way for files. It will allow you to replace certain sections of a file with your own entry. Let's look at a very simple patch by 'microx256':
No idea what rel is short for, probably replace location. snr is search and replace. These 2 tags differ in the fact that rel can take an address to replace, while snr seems to replace recursively.
Looking at the patch, firstly it's telling ROMPatcher it will be expecting a file, a specific location in that file, a value to replace and the replacing value. ROMPatcher will open c:sysbinToDoPlugin.dll which is responsible for housing the information for the Memo/To-do plugin on the ActiveStandby screen. It will go to offset '00000003' and replace the value of '10' with '00'. It will then go to offset '00000000' and replace '79' with '00'.
Next time this DLL is polled, it will pass the patched information and whatever changes were made will be applied.
Most files require the C2Z patch. This patch moves the contents of the Z: which is uneditible, to section of C: that can be edited. This allows you to redirect file access, instead of an application look for Z:resourceblah.blah it will now look at C:resourceblah.blah that you have access to. This however is not the case in tthe E71. C: seems to take complete precedence over the Z: for some reason. Copy a file from Z: to any directory that does not exist on the C: and forces you to make it - you can make on the fly changes to the file in C: and they are immediately effective.
I currently employ this 'feature' to give blanket permissions to all Java midlets. By replacing the MIDP assumed security policy file with one that indicates that all untrusted applications are to be treated as trusted, you no longer require 'signed' midlets or ones that have specific capabilities. You can now set permissions to any and all java midlets. Excellent.
That's it for now! Any questions or comments, please post them up!