Mobile Phone ROM Image and Reverse Engineering Invitation 2005-05-26 Abstract The following webpage contains ROM images from various mobile phone operating systems. Our intention is to motivate other reverse engineers to take a look at the images and to discover other hidden secrets. Other reasons are that it is said to be hard to extract the ROM. Certainly another reason is that Nokia does not release any technical information about the hardware and I find this rather disappointing. (It's my strong believe that when I buy hardware that I should also be allowed to know what's in it and how to use it.)
*** NEWS *** NEWS *** NEWS *** NEWS ***

                       THC and The Nokia Rom Images

In mid july Nokia charged THC with copyright infringement and threatened
with a lawsuit. THC took down to prevent further cost and a
legal disaster.

A month earlier THC discovered significant security flaws in Nokia's
Operating System. To proof it THC published ROM images of 3 phones.
THC did not publish the source code or tools but one thing became
apparent: To extract the ROM images core security features had to be
breached. THC's ability to load kernel modules and gain access to the
core of the OS (including the GSM stack) was something Nokia did not

At the time of the release THC was not aware of any copyright protected
material inside the roms. The question has to be asked if Nokia chosed
the right method by threatening THC with a lawsuit or if an email could
have achieved the same. Was their concern really copyright infringement?
The software in the rom-images could not be used, not be ported and not be
run on any other mobile phone. In addition all software is already available
on every phone. Phones that are given away by the mobile operators for
1 Euro or sometimes even for free. So if everyone has access to the software
anyway what is the point in threatening THC? What was their real intend? We
might never find out. But what we know is that they managed to silence THC
for a month.

If this is professional practice? We do not know. It is certainly the
practice that Nokia chose. We also know that no attempt was made by Nokia
to inquire about the security vulnerability. We also know that Nokia did
not provide any updates for their customers.

Making sure that the hardware we purchase is secure is not a crime.
In fact taking a look at what we buy should be our duty. We should not
trust big corporates who claim in TV advertisements how secure and
safe our data is. We have to test it and proof them wrong whenever we

In fact researchers should demand that manufactures like Nokia must
provide full documentation of their hardware. The buyer becomes the owner
of the mobile phone and thus has the right to know how to program the
hardware. Nokia does not provide any of such information. Free software
or a different operating system can not be used because of limited access
to documentation. This is a classic example of a hardware giant allowing
only his own software to be used. This is what some people would consider
a Monopoly and an abuse of power.

THC is deeply concerned that Nokia did not choose the diplomatic route.
NOKIA 6630 n6630-rom-0x5000000.dmp n6630-rom-0x5000000-info.txt (ROM information dump) n6630-virt-phys-map.txt (list of virtual to physical address mapping) NOKIA n70 n70-rom-0x50000000.dmp n70-rom-0x50000000-info.txt NOKIA N-GAGE ngage-rom-0x50000000.dmp ngage-rom-0x50000000-info.txt ngage-gsmstuff-0x5149D280.dll (gsm stack?) ngage-virt-phys-map.txt SonyEricsson P900 p900-rom-0x50000000.dmp p900-rom-0x50000000-info.txt Where to go from here: - Get the symbian/Nokia SDK. Start with extracting the files from the rom image and load them into IDA (see e32rom.h). Get SDK's from different vendors. Some come with more header files than others and it's best to have a mix of all headers. - Load the ROM into IDA. Check for jumps/calls outside the ROM address space. (hint: to many secrets!) - Write your own kernel module. Map some physical address pages that are currently not mapped. Wuuhhaa. Some quick information: 1) Virtual Memory & MMU system. ARM, 32bit. Binaries are executed directly in ROM (XIP, no relocation to RAM). 1) Page directory contains pointers to 1MB sections or 4k page tables. 2) Virtual address map: +----------------------------+------------------------------------------------+ | 0x0040 0000 - 0x2FFF FFFF : User Data | | 0x3000 0000 - 0x3FFF FFFF : Static data for Java | | 0x4000 0000 - 0x4000 1FFF : Super page + CPU page | | 0x4001 0000 - 0x4001 0FFF : Shadow RAM page temporary address | | 0x4100 0000 - 0x4100 3FFF : Page Directory | | 0x4108 0000 - 0x4108 3FFF : Page table info | | 0x4200 0000 - 0x423F FFFF : Page tables | | 0x5000 0000 - 0x57FF FFFF : ROM image | | 0x5800 0000 - 0x5EFF FFFF : Memory-mapped I/O (danger!) | | 0x5F00 0000 - 0x5FFF FFFF : Video RAM (fun!) | | 0x6000 0000 - 0x7FFF FFFF : RAM | | 0x8000 0000 - 0xXXXX XXXX : Kernel data/bss section | | 0xXXXX XXXX - 0xXXXX XXXX : Reentrant/IRQ/FIQ/Null/Exception kernel stack | | 0xXXXX XXXX - 0xXXXX XXXX : Fixed chunks data for ROM fixed processes (?) | | 0xXXXX XXXX - 0xXXXX XXXX : Kernel server heap and stack | | 0xXXXX XXXX - 0xXXXX XXXX : Home Section / All Processes | | 0xXXXX XXXX - 0xXXXX XXXX : RAM-loaded EXE & DLL code | | 0xFFF0 0000 - 0xFFFE FFFF : Void / Empty | | 0xFFFF 0000 - 0xFFFF FFFF : Vectors (hoho!) | +----------------------------+------------------------------------------------+ Note: Big thanks goes to an anonymous contributor without his help all this would not have been possible. Yours sincerely, The Hackers Choice