All of the research presented in this paper was done by me and two coworkers who preferred to stay anonymous, I write everything as if I did it by myself for clarity and fluency.
To understand what a Kosher phone is, one must first understand what a feature phone (aka dumb phone) is. A feature phone is a phone that is usually sold for a very cheap price (up to 50$) and it lets the proud owner do the following things:
- Make phone calls
- Send SMS
- Send MMS
- Manage a calendar
- Listen to FM Radio
- Play simple games such as Snake
- Browse the internet over GPRS or 3G using a dis-functional web browser.
- Bluetooth communication
- Play ringtones
- Display ugly images as wallpapers
- Take photos using ~2MPixel camera
- Some utilities such as world clock, unit converter and calc
While recently some devices also include:
- Limited Facebook app
- Twitter app
A Kosher phone would be an adapted feature phone to the “special” needs of a certain community of the Ultra Orthodox Jews. The community in target asked for a phone that is more dumb than the dumb phone, a phone that suffers from complete retardation. The general idea is that they don’t want to be open to the outside world in any way, but they still want a means to communicate between themselves without breaking the strict boundaries they made. They were looking for phones that can only perform the following tasks:
- Make phone calls
- Manage a calendar
- Bluetooth only with headphones
- Play only a strict list of Hasidic ringtones.
- Some utilities such as unit converter and calc
Besides that, they would be extra happy if they could have:
- Jewish calendar
- Prayers time table
A disclaimer: No one forces this phone on them, they choose to have it on their own will. No government or agency is involved in this, and the only mean of force that drive the people to use this kind of phone is the community they live in.
I choose for start a Nokia phone, as they are considered cost effective for hardware quality and stability. From Nokia I got an approval for the project, but no help whatsoever. They said, I’m welcome to do whatever helps me sell their phones, but this target group is too small for them to put any developing time on it. This is how the journey for the Kosher phone has started.
During my journey I had the pleasure of co-developing of 5 generations of the Kosher phone:
- Nokia 1208
- Nokia 2680
- Nokia 2720
- Samsung E1195
- Nokia 208.4
There were a few models in between that didn't get to the final stage either because I failed in making a Kosher firmware for them or because of other reasons that are out of my control.
I won’t describe all of the tricks I've used during the development, because:
- These phones still make a nice income that I would not want anyone to take away.
- Not all of it is mine to share.
However, I think the time has come for me to share some of the knowledge I've collected during this project.
It would be too long to cover all of the phones in a single post, so I will start with just one of them, and just a single part that I find most interesting.
Nokia has quite a few series of phones differ in the firmware structure and firmware protection. The main purposes of the protections are to:
- Make it hard for people to play with Baseband firmware and harm the GSM network
- Protect the SIM-lock feature which locks the phone to sim cards from only one provider (Something that became illegal in some countries such as Italy and Israel).
The series are the following categories:
- DCT1 (Digital Core Technology / Data Cellular Technology)
- DCT3
- DCT4
- DCT4+
- BB5 (Base band 5)
- Asha S40 (AKA xGold 213)
In general the DCT1 works with the old analog networks (Usually refer to as 1G), DCT3, DCT4 and DCT4+ works with GSM (2G). BB5 is sometimes 2G and sometimes 3G (I think). And anything that comes after being 3G compliant. It is important to understand the fact that there are different generations of phones because a way to fiddle with the firmware of a phone from one series would usually work with all of the other phones on the same series, while it won’t work with phones from other series.
I’ll start with the DCT4+ phone, the Nokia 1208. Nowadays there are quite a few people out there who know how to patch DCT4+ firmware, but the solution is still not out in the open. One would have to collect lots of small pieces of information from many forum posts in order to get a full solution… Well, not anymore, because I’m going to present here the solution in all of its glory.
A DCT4+ firmware consists of two parts, a flashable part and a non flashable secured part (probably ROM). The flashable part contains the:
- OS, usually referred to as the MCUSW.
- Strings and localization strings, usually referred to as the PPM
- General purpose file system in a FAT16 format. This part contains configuration files, user files, pictures, ringtones, and more. This is where Nokia pushes the phone provider variations. This part is much less protected. It's usually referred to as the CNT or IMAGE.
All of this data is accessible from the software in one flat memory module, meaning that codes that runs on the device can access almost anything that it know where to locate.
At this point I would focus on the OS part, in an attempt to patch it to make the phone Kosher. The OS contains 99% of the code that operates the phone, that's including the implementation of user interface, menus, web browser, SMS managing, communication and anything else the phone does. The only things that are not part of the OS are the code for performing the flashing, the code for protecting the flash and some of the BaseBand these are all found in the ROM part, beside that only 3ed party apps such as games are located outside of the OS, in the CNT part.
Obtaining the binary is not hard, it’s simply available for download from many websites, and from Nokia servers accessible by the Nokia flashing tool Phoenix or by the NaviFirm+ tool. The MCU part (meaning the OS part) comes in the form of a file with the .mcu or .mcusw (MicroController Unit SoftWare) extension.
It starts with the constant byte 0xA2 that marks the version of the file. The file has quite a simple format. From offset 0xe6 everything that follows is encoded as:
1 Byte: Type (Always 0x14)
1 Dword: Address
3 Bytes: Length
1 Byte: Unknown
1 Byte: Xor checksum
Combining all of the data chunks would give us something that starts at address 0x1000000 with the following data:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 AD 7E B6 1A 1B BE 0B E2 7D 58 6B E4 DB EE 65 14 .~¶..¾.ג}Xkהמe.
00000010 42 30 95 44 99 18 18 38 DB 00 FF FF FF FF FF FF B0•D™..8.
00000020 FF FF FF FF F8 1F 8B 22 50 65 61 4B FF FF FF FF ר.‹"PeaK
00000030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000040 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000050 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000060 FF FF FF FF FF FF FF FF FF FF FF FF F8 C4 AA C3 רִ×ֳ
00000070 85 CF C6 E7 00 04 8A 5F 01 00 01 00 00 00 00 00 ֶֿ...ח..._........
00000080 00 00 00 00 ...
Note that some of the 0xff bytes are just missing data because of the way it is encoded. The first data chunk belongs to address 0x1000000 but it’s just 0x2c bytes long and the next data chunk starts at 0x1000064. The binary that follows byte 0x1000084 is encrypted, and is auto decrypted by hardware. I know that this is done at the hardware level because:
- I can see what bytes are actually sent to the phone during flashing, and
- There are few places in memory such as the bytes from 0x1000000 to 0x1000084 that are not encrypted. After I’ll manage to open the encryption I would find that In some places in the code these bytes are accessed simply by adding 0x8000000 (I’m not missing a zero) to the address, which is a flag to the CPU that says that this data is not encrypted, so don’t decrypt it.
Now an interesting question that comes next is what is the encryption, and how can I reverse it to patch the code. My answer is going to be quite disappointing, I found out what encryption is it by gluing pieces of information that are published on the Internet. If you want to know how the guys on the Internet found what it is, remember that I want to know it too. My guesses are either:
- Someone leaked it from Nokia
- Someone reversed it from the silicon, with a process usually called Silicon Reverse Engineering
- The encryption was implemented in ARM code in the unflashable array (Very unlikely), and that was recovered in a method I would describe later in this post.
- It was reversed mathematically from samples. I think the mechanism has a problem in which some bytes with the same value at the same array and with the same distance from each other might be encrypted into the same value, which can give information that could be used to deduce parts of the mechanism mathematically.
- Or any combination of the options above.
------- UPDATE -------
Apparently the reversing of the encryption and encoding was done by:
- G3gg0 who is also responsible for the amazing tool Trix (http://www.g3gg0.de/wordpress/)
- nok5rev
- And Krisha
More information about how it was done, and the original source code is found on the following link: http://www.gsmfreeboard.com/showthread.php?t=119075&highlight=DCT4Crypter
-----------------------------
That came out not as clear as I expected...
The ROM contains a relatively small amount of code, but as you could probably understand by now, I don’t have this part. The only thing I care about from this code is one function that does the following two things:
- Validating first 1MB of the MCU code.
- If and only if the validation succeeds it activates the BaseBand (Any GSM communication)
Meaning that if something in the first 1MB of the MCU code is patched, the validation found in the ROM would fail and the phone won't communicate with anything. This won’t interrupt anything else at phone so it would keep running, but the user interface would display no signal sign. The validation function in the ROM is invoked from the MCU code, so the function call can be patched out, but again, it would make the phone not a phone as it won’t be able to make any phone calls. It might sounds like this is what the customer is looking for but it’s not, phone calls are still Kosher if they are not done on Sabbath. Note, that Bluetooth communication is still functional, and can be instrumented to become an easy to access debug interface.
Another validation that is found in the MCU code is a common 16bit checksum, that is done less for security reasons, but to check the phone for flashing errors or flash corruption. The right checksum value is found somewhere in the first 0x100 bytes of the MCU. This checksum is easily fixed with any hex editor. If the check fails the phone shows a “Contact Service” message, and shuts down.
At this point I don’t know much about what kind of validation is done on the first 1MB, I just have a few samples of official firmwares that pass the validation. Every sample has a function that residents in that 1MB of code and validates the rest of the code. If that function fails, meaning if I patch something in the code coming after the first 1MB, it immediately reboots the phone. The funny thing is, that the CPU is so slow, that I can actually get a few seconds to play with the phone before the reboot takes place. Again patching out this check equals no signal.
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 AD 7E B6 1B 23 10 03 40 C6 05 E4 01 20 A2 00 00 .~¶.#..@Æ.ä. ¢..
00000010 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF ...........ÿÿÿÿÿ
00000020 FF FF FF FF F8 1F AA 02 50 65 61 4B FF FF FF FF ÿÿÿÿø.ª.PeaKÿÿÿÿ
00000030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000040 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000050 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000060 FF FF FF FF FF FF FF FF FF FF FF FF C0 52 90 D4 ÿÿÿÿÿÿÿÿÿÿÿÿÀR.Ô
00000070 4A E4 5C 8F 00 02 00 00 01 00 01 00 00 00 00 00 Jä\.............
00000080 00 00 00 00 FF FF FF FF FF FF FF FF 01 CE 00 00 ....ÿÿÿÿÿÿÿÿ.Î..
00000090 03 00 00 00 00 04 CC A2 00 04 CC A3 FF FF FF FF ......Ì¢..Ì£ÿÿÿÿ
000000A0 00 00 F1 EF 89 33 EB 2D 1F 09 3B DA C7 C0 3D 9F ..ñï‰3ë-..;ÚÇÀ=Ÿ
000000B0 BB D3 29 98 01 C8 BC B0 06 6E A8 11 0E D1 69 67 »Ó)˜.ȼ°.n¨..Ñig
000000C0 A4 A3 9A A5 BF 7B 27 5A E6 C7 61 2D F7 B8 70 9C ¤£š¥¿{'ZæÇa-÷¸pœ
000000D0 D4 1C 09 96 AF 5B F2 05 20 92 49 DF D5 0B FC DE Ô..–¯[ò. ’IßÕ.üÞ
000000E0 A8 30 B7 39 34 59 13 7D E7 BD 72 3F C7 CF B3 5A ¨0·94Y.}ç½r?ÇϳZ
000000F0 60 2C 5E 7D 63 17 56 C4 9F 6C C5 1A 01 BF B5 CF `,^}c.VÄŸlÅ..¿µÏ
00000100 EA 01 FF BE 00 FE 6A 84 EA 50 20 20 20 20 6A 04 ê.ÿ¾.þj„êP j.
00000110 2D CF 20 20 20 20 6A 01 9D 7C 20 20 20 20 6A 01 -Ï j..| j.
00000120 B3 C8 20 20 20 20 6A 01 A5 C2 20 20 20 20 6A 04 ³È j.¥Â j.
16-bit checksum - “Contact Service” message + Shutdown if it fails.
If changed - I get no signal.
Bytes that I can change as much as I want, probably some version info and public key of something.
Going deeper: To attack this protection I had to reach a better understanding of all of the different integrity checks. I don’t have the binary for the check performed on the first 1MB, so I reversed the check performed on the rest of the binary in an attempt to find some mistake. Using find crypt IDA script I found few implementations of SHA1, MD5 and other hashing functions that could be used and should be used to check binary integrity. I found a function that gets arguments of the type of the hash, starting address, length and returns a digest of that data. Following the xrefs of that function brought me to the following code:
The digesting function is “hashInitUpdateNDigest_j” of course. The SHA1_check_related address had the following data in it:
This is SHA1 digest of other arrays of binary, in chunks of about 0x2b0000 bytes. All of the data from 0x1000100 to 0x1100100 is protected by the ROM. The data from 0x1100100 to 0x13affff digest to EE41347A8C88F02F563BB973040E12338C03AFFA under SHA1. So I guessed that this function is the validation function that uses SHA1 to check the rest of the binary.
Later on in the same function I found the following code:
This function is performing the comparison of the calculated hash to the one in the table, if it mismatches it calls the hashMismatch function and then to the reset function with error code 4.
The hashMismatch function looks as followings:
Meaning it is a call to a function from another library, that is too far to jump using Thumb mode, so ARM mode is used to perform the call.
Therefore what I got is a code that is secured and is well checked by the ROM, which implements SHA1 check on the rest of the code, and when the check fails, it uses the code that it just failed to verify to alert the user that there is a problem with the binary.
See it is located in the 5th MB part of the binary!
From here the solution was as simple as writing a small patch that fixes the “binary mismatch” flag and jumps back to place right after the check.
How could such a fail happen to a big company like Nokia? Well, there are quite a few good explanations for that:
- It could be that they really wanted to give the user some indication about the problem, or that they had to invoke some cleanup function before shut down, and by mistake, the relevant code was in another library that got linked to higher addresses and no one thought about it.
- It is possible that this is a back door someone at Nokia left for himself (Only a speculation, I base it on a gut feeling and nothing else).
- Everything was well checked on Debug build, but when they moved to Release, something went differently in the link and again they didn’t notice it.
Anyhow, this is my preferred approach for patching the flash, although, using this method I can’t patch the first MB directly, only what comes after, good enough for my tasks.
However, if it’s not enough, some guys reversed the 1st MB check for some of the phones and made it public. Though the function they published is only good for some modules, and not for the entire series.
Again the question of how? Well, it’s possible that it was silicon reverse engineering, but there’s rumored to be another method. The idea is that through JTAG debugging, one could single-step through the program and spy on the Instruction Fetch stage of the pipeline in order to recover the instructions from masked-ROM. Replacing those instructions with a NOP before they reach the WriteBack stage of the pipeline would linearize the code and allow the entire ROM to be read by the debugger while the CPU sees it as one long NOP sled. As I’ve not tried this technique myself, I’d appreciate any concrete details on how exactly it might be done.
Anyhow, now that I have a way to patch the firmware, I had lots of patches to make in order to make this phone Kosher. I had to reverse the menu functions entirely, which was quite a pain. I had to reverse the methods for loading strings in order to have a better way to find my arms and legs around this big binary file. Some of the patching was a bit smoother than others. For instance, after removing Internet options from all of the menus I wanted to be extra careful in case I missed a secret menu option, that the Internet won’t work. To disable the internet one might suggest searching for TCP implementation, but that's too much work, and it might harm IPC. One can also suggest searching for things like default gateway and set it to something that would never work, but again this is too much work. What I did was, searching for all the places where the word “GET” all capitals is found in the binary. Luckily I had just one match, and I patched it to “BET”, so from now on, no Internet server would ever answer requests. Moreover,To be on the extra, extra safe side I’ve also patched “POST” to “MOST”, lets see them downloading porn with that.
Other fun parts were making the Bluetooth connect to only audio devices, which took lots of reversing and learning the Bluetooth protocols.
In my next post stay tuned for the file system of the phones and ways to make them misbehave.
POC:
You can see on the video that the firmware was patched, because the code *#0000# for getting the firmware version has been changed to *#0001#. The fact that the phone receives a phone call indicates that I’ve overcome all of the protections.
Python scripts coming soon…
Cheers,
Assaf
