How to add new language to ARM firmware

Question

I have piece of firmware (download from here) and I need to get access to its filesystem.

Here is the output of a binwalk scan:

root@kali:~/Desktop/E1200YDXNB1_OLAANB1# binwalk --dd=".*" ps.bin
DECIMAL       HEXADECIMAL     DESCRIPTION
108542        0x1A7FE         Unix path: /source/base/src/doidleonpage.c
172162        0x2A082         Unix path: /source/efs/src/efs_item.c
215976        0x34BA8         Unix path: /Layer1/source/c/datacnfproc.c
309012        0x4B714         Unix path: /Layer1/source/c/systeminfo.c
747043        0xB6623         MySQL ISAM index file Version 4
763097        0xBA4D9         Minix filesystem, V1, little endian, 4 zones
763641        0xBA6F9         Minix filesystem, V1, little endian, 8192 zones
796248        0xC2658         MySQL ISAM compressed data file Version 2
801115        0xC395B         MySQL MISAM index file Version 3
819081        0xC7F89         MySQL MISAM compressed data file Version 9
821756        0xC89FC         MySQL MISAM index file Version 7
825421        0xC984D         MySQL MISAM index file Version 5
842282        0xCDA2A         MySQL ISAM index file Version 10
864884        0xD3274         Unix path: /source/src/c/sci_mem.c
870088        0xD46C8         Unix path: /source/src/c/threadx_os.c
882552        0xD7778         Unix path: /source/src/c/sci_log.c
887232        0xD89C0         Unix path: /source/src/c/threadx_appmem.c
1350524       0x149B7C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2244000       0x223DA0        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2246600       0x2247C8        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2251808       0x225C20        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2254368       0x226620        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2256964       0x227044        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2259516       0x227A3C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2262096       0x228450        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2266940       0x22973C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2269388       0x22A0CC        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2271928       0x22AAB8        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
2274460       0x22B49C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3425084       0x34433C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3535408       0x35F230        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3535448       0x35F258        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3535488       0x35F280        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3536360       0x35F5E8        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3555612       0x36411C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3814428       0x3A341C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes
3818348       0x3A436C        LZMA compressed data, properties: 0x5A, dictionary size: 16777216 bytes, uncompressed size: 4096 bytes

As you can see, there are two files that binwalk detects as a Minix filesystem.

However, when i tried to mount these files like this mount -t minix BA6F9 test/ it results in an error:

wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error

My question is how can I mount or extract this filesystem?

I edited the question with more details about my project:

My goal is to add Hebrew language to this firmware.

So, I found a tool that can edit the strings to Hebrew language, but I still have two problems with that.

First, the font of this firmware doesn’t support Hebrew letters.

and second, Hebrew language is RTL language, so I need to edit the settings of this language to RTL.

about the font, I found in the firmware a path that mention to font files in directory called font, and the files is with extension .lib (e.g. english_font.lib). I have another firmware, of very similar phone, Samsung b110e (same CPU) that contains Hebrew language.

My question is if there is a option to copy the font from this firmware to my firmware.

And about the RTL, I don’t know exactly what I need to edit, but I guess, that is in a xml file.

Thanks for your help.

Answer 1

The first region identified as Minix fs is only several hundreds of bytes long, the second one less than 3 kB (if we assume the subsequent identification of data as MySQL data to be correct) and the contents at the second location don't really look like a fs image to me. So I think it's safe to assume that binwalk incorrectly identified these.

Looking at some of the strings contained in the firmware image, it seems that this is using the ThreadX RTOS (several file names mention this) on ARM (there are strings indicating SVC and FIQ, which are ARM exception/interrupt methods). AFAIK, ThreadX only supports some sort of FAT file system out of the box.

So, do not blindly trust tools such as binwalk. Most of the tools only rely on identifying "magic numbers", i.e. sequences of bytes that can also occur randomly, so a number of false positives is to be expected.

(Thanks for updating information about the hardware)

On a feature phone like this, the firmware is often simply one big binary blog linked together, so probably there is no file system which would make it easier to modify contents.

The E1200Y uses a Spreadtrum SC6500 SoC, which according to the silicon manufacturer is a ARM9EJ-S Core (running at 208 MHz) - the string "SC6500" also shows up several times in the firmware image. As usual for this sort of ICs, documentation is not available.

If you want to start reverse engineering the code, here are some hints to get you started.

Taking a closer look at the firmware image, the first 32 bytes look like valid reset and exception vectors. On "regular" (i.e. non-Cortex-M) ARM processors, these do not contain vectors, but instructions to update the PC to a new value - essentially, some sort of jump instruction.

00000000  18 f0 9f e5 18 f0 9f e5  18 f0 9f e5 18 f0 9f e5
00000010  18 f0 9f e5 18 f0 9f e5  18 f0 9f e5 18 f0 9f e5

This is in little endian byte order, each group of four bytes "18 f0 9f e5" is the opcode for a LDR instruction (disassembled with the online disassembler):

00000000  18 f0 9f e5  ldr pc, [pc, #24]

The PC on ARM always points to the current instruction +8, so PC+24 = 0 (current PC at reset) + 8 + 24 (offset in the instruction) = 32 = 0x20. At offset 0x20, you can find the address of the reset routine (the vectors are described in this post):

00000020  30 6c 0a 00

So, at reset the CPU will execute code at address 0x000a6c30. However, disassembling the code at this offset in the firmware dump you uploaded does not yield code that looks very sensible.

Regular 32-bit ARM code is identifiable by looking at the most significant 4 bits of each 32-bit opcode. For most instructions, these should contain 0xe, since the 4 MSBs are used for predicated execution (i.e., execution of an instruction depending on the current values of the CPU flags). 0xe is the predicate for "always", which should be the case for most instructions.

So you have to dig deeper here. It seems some sensible-looking startup code is at offset 0x00096c30 in the file - 0x10000 bytes (64 kB) below the reset vector address (code addresses shown here as would be seen by the CPU, subtract 0x10000 to find the bytes in the firmware image):

000a6c30  60 c1 1f e5  ldr ip, [pc, #-352]   ; 0x000a6ad8
000a6c34  00 c0 9c e5  ldr ip, [ip]
000a6c38  ff a0 a0 e3  mov sl, #255          ; 0xff
000a6c3c  0a c0 0c e0  and ip, ip, sl
000a6c40  6c b1 1f e5  ldr fp, [pc, #-364]   ; 0x000a6adc
000a6c44  00 b0 9b e5  ldr fp, [fp]
000a6c48  dc a0 9f e5  ldr sl, [pc, #220]       ;0x000a6d2c
000a6c4c  0a b0 0b e0  and fp, fp, sl
000a6c50  78 a1 1f e5  ldr sl, [pc, #-376]   ; 0x000a6ae0
000a6c54  00 a0 9a e5  ldr sl, [sl]
000a6c58  00 b0 8a e5  str fp, [sl]
000a6c5c  80 b1 1f e5  ldr fp, [pc, #-384]   ; 0x000a6ae4
000a6c60  00 a0 9b e5  ldr sl, [fp]
000a6c64  00 b0 9a e5  ldr fp, [sl]
000a6c68  02 01 1b e3  tst fp, #-2147483648  ; 0x80000000
000a6c6c  fc ff ff 1a  bne 0x000a6c64
...

From here on, you will obviously need good knowledge of ARM assembler and of the specific hardware used in the SC6500 (the last three disassembled instructions above look like a polling loop waiting for some I/O condition to occur). So it looks like you are onto quite a big endeavour here...