Decryption of updates of one popular cellular modem: Dmitry Sklyarov method

Sometimes you want to look into the firmware code of a device. But apart from the firmware itself, which is encrypted, there is nothing. And how can the reverse with this live? The article discusses the real situation when, using basic knowledge in computer science and logic, we managed to solve an almost hopeless task.

The name of the modem manufacturer is removed, and some file names are specially changed, as I want to focus on the task itself - and on an interesting approach to its solution. By the way, this method does not work in the latest models of modems from this manufacturer. But it is possible that it can be used in other cases.
')

1. Definition of structure

Let's start by defining the firmware file structure. There are three update files of different versions for one modem:

• v2.8_image.bin
• v3.7_image.bin
• v3.7.4_image.bin

At a close look, all three files have inside the structure described by the TLV (Tag-Length-Value) scheme. For example, for v3.7.4_image.bin :



All values ​​are Little-endian, Tag has a length of 16 bits, Length - 32 bits.
At the first level of nesting in the file there is only a tag 0x7240, and the data for it occupies the entire file. At the second level of nesting (inside the tag data 0x7240) the tag 0x0003 (0x0A bytes) is located, then 0x0000 (0x4BDE0E bytes), then the tags 0x0001 and 0x0002 (in the screenshot did not fit). At the third level of nesting (inside the tag data 0x0003) the tag 0x0002 is encapsulated, storing the 4-byte version number of the file 030704FF (if you discard all FF, you get 3.7.4).

The remaining tags located on the second level of nesting (tags 0x0000, 0x0001 and 0x0002) contain descriptions of individual files “packaged” in one image.
For each file, the name (tag 0x0001), flags (tag 0x0002), size (tag 0x0003), a 16-byte value (tag 0x0004) and the actual file data (tag 0x0005) are indicated.

If you disassemble the tags on all three levels of nesting, you get something like this structure:



Thus, you can extract encrypted data for all components from the firmware files ( CPUImage , AutoInstall and WebUI ). As it turned out, the contents of AutoInstall in all three versions of the firmware are the same, the insides of WebUI same for v3.7 and v3.7.4, but differ in v2.8, and the CPUImage is unique for each version.

2. Guesses by algorithms

Tag 0x0004 at the third level of nesting contains a 16-byte data set with high entropy. This hash value is quite possible, and the most popular 128-bit hash is MD5.

If you look at the extracted files, you will notice that in them many bytes at the same offset coincide. Here, for example, the beginning of two files (highlighted differences):



However, if you try to find the same sequence within the same file, there will not be long repeats.

A similar effect occurs when using encryption by superimposing a constant gamut of a very long length. And the most popular encryption algorithm that works this way is RC4.

3. Attack on stream cipher with constant key

If several messages are encrypted using the same key (and therefore the gamma), you can try to uncover fragments of these messages by copying them together. And in those places where there were zero bytes in one of the messages, the plaintext will appear in the other.

Taking the files AutoInstall and WebUI , we get interesting results:

  00000000: EB 3C 90 6D 6B 64 6F 73 66 73 00 00 02 04 01 00 l <ђmkdosfs
 00000010: 02 00 02 F8 0F F8 03 00 20 00 40 00 00 00 00 00 ☻ ☻☼ @
 00000020: 00 00 00 00 00 00 29 29 6E 1F 3B 15 47 43 54 2D 4C) n ▼; §GCT-L
 00000030: 54 45 20 20 20 20 46 41 54 31 32 20 20 20 0E 1F TE FAT12 ♫ ▼
 00000040: BE 5B 7C AC 22 C0 74 0B 56 B4 0E BB 07 00 CD 10 * [| ¬ "At♂Vґ ♫” • H►
 00000050: 5E EB F0 32 E4 CD 16 CD 19 EB FE 54 68 69 73 20 ^ lr2dN▬N ↓ anyThis
 00000060: 69 73 20 6E 6F 74 20 61 20 62 6F 6F 74 61 62 6C is not a bootabl
 00000070: 65 20 64 69 73 6B 2E 20 20 50 6C 65 61 73 65 20 e disk.  Please
 00000080: 69 6E 73 65 72 74 20 61 20 62 6F 6F 74 61 62 6C insert a bootabl
 00000090: 65 20 66 6C 6F 70 70 79 20 61 6E 64 0D 0A 70 72 e floppy and pr
 000000A0: 65 73 73 20 61 6E 79 20 6B 65 79 20 74 6F 20 74 Ess any key to t
 000000B0: 72 79 20 61 67 61 69 6E 20 2E 2E 2E 20 0D 0A 00 ry again ... ♪ ◙
 000000C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ...
 00008800: 02 43 44 30 30 31 01 00 00 20 00 20 00 20 00 20 CD001
 00008810: 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 

4. Getting the start of gamma

Modern cellular modems like to connect to create a virtual CD-ROM from which you can install drivers or related software. Probably the same idea was used here.

However, when the modem is connected to modern operating systems (Windows 7/8, Linux, MacOS X), this CD-ROM either does not appear at all, or is present for only a fraction of a second, after which it disappears. I had to find a 2002 laptop with Windows XP, where when I connected the modem, the CD-ROM also disappeared shortly after it appeared, but it took as long as 5 seconds. During this time, it was possible to have time to read all sectors of a logical volume and get an image of 606 208 == 0x94000 size 606 208 == 0x94000 bytes, which corresponds to the size of the AutoInstall file. And the MD5 value from the read image turned out to be 897279F34B7629801D839A3E18DA0345 , which corresponds to the value of the 0x0004 tag for this file.

Now it remains to XORit the read image with the contents of AutoInstall and get the first 600 kilobytes of gamma. CPUImage this gamma we can decipher the beginnings of the CPUImage and WebUI (having a length of 4 971 976 and 2 093 056 bytes, respectively).

5. FDD Image Reconstruction

If you decrypt the beginning of the WebUI file (the first 606 208 bytes) and fill in the rest with zeros, and interpret everything as a FAT image, the file system structure will be visible and even the contents of some files will be available:

  Name |  Size |  Date | Time
 bru | Folder | 05/31/12 | 22: 17
 cgi-bin | Folder | 05/31/12 | 22: 17
 cors | Folder | 05/31/12 | 22: 17
 css | Folder | 05/31/12 | 22: 17
 eng | Folder | 05/31/12 | 22: 17
 img | Folder | 05/31/12 | 22: 17
 js | Folder | 05/31/12 | 22: 17
 en | Folder | 05/31/12 | 22: 17
 name.html |  2248 | 05/31/12 | 22: 17
 easyXDM.js | 101924 | 05.31.12 | 22: 17
 easyXDM.debug.js | 113900 | 05/31/12 | 22: 17
 easyXDM.min.js |  19863 | 05/31/12 | 22: 17
 easyXDM.Widgets.js |  11134 | 05/31/12 | 22: 17
 easyXDM.Widgets.debug.js |  11134 | 05/31/12 | 22: 17
 easyXDM.Widgets.min.js |  3114 | 05/31/12 | 22: 17
 json2.js |  17382 | 05/31/12 | 22: 17
 easyxdm.swf |  1758 | 05/31/12 | 22: 17
 MIT-license.txt |  1102 | 05/31/12 | 22: 17 

If a browser is connected to the modem, go to the web interface at http://< >/dir , then you will see exactly the same file system, and you can download any file.

Thus, to restore the WebUI disk image, you need to expand the files downloaded via the web interface into the places where they should be in accordance with the data in the boot sector, the FAT table and the directory descriptions. The only difficulty is the “ru” folder at the root. The cluster with the description of files in this folder does not fall into the first 606 208 bytes, and its contents must be recreated manually.

According to the information from the web interface, the following files should be in the “ru” directory:

  Name |  Size |  Date | Time
 Manualupdate.html |  3981 | 05/31/12 | 22: 17
 Index.html |  5327 | 05/31/12 | 22: 17
 Network.html |  3328 | 05/31/12 | 22: 17 

Fortunately, there is a folder in the root “eng”, in which files with the same names and creation dates are located. And to get the correct data for the folder “ru” you just need to fix it:

• the start cluster number of the current directory,
• size of each file
• numbers of starting clusters of each file.

The cluster number of the “ru” directory (0x213) can be obtained from the root directory.
File sizes (3981 == 0xF8D, 5327 == 0x14CF and 3328 == 0xD00, respectively) can be found in the web interface.

The numbers of starting clusters for files will have to be guessed, but this is not very difficult. According to information in the boot sector, each cluster occupies 4 sectors or 2048 bytes. For the “ru” directory, one cluster is enough, for the Manualupdate.html and Network.html — two, and for the Index.html need three clusters. Since clusters are usually allocated sequentially when writing to an empty disk, files will start in clusters 0x214, 0x216 and 0x219, respectively. The recovered data for the “ru” directory will look like this:

  00000000: 2E 20 20 20 20 20 20 20 20 20 20 10 00 00 2C AA.  ►, to
 00000010: BF 40 BF 40 00 00 2C AA BF 40 13 02 00 00 00 00 ┐ @ ┐ @, k┐ @
 00000020: 2E 2E 20 20 20 20 20 20 20 20 20 10 00 00 2C AA .. ►, to
 00000030: BF 40 BF 40 00 00 2C AA BF 40 00 00 00 00 00 00 ┐ @ ┐ @, k┐ @
 00000040: 42 68 00 74 00 6D 00 6C 00 00 00 0F 00 56 FF FF Bh tml V 
 00000050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
 00000060: 01 6D 00 61 00 6E 00 75 00 61 00 0F 00 56 6C 00 manua ☼ Vl
 00000070: 75 00 70 00 64 00 61 00 74 00 00 00 65 00 2E 00 update.
 00000080: 4D 41 4E 55 41 4C 7E 31 48 54 4D 20 00 00 2C AA MANUAL ~ 1HTM,
 00000090: BF 40 BF 40 00 00 2C AA BF 40 14 02 8D 0F 00 00 ┐ @ ┐ @, k┐ @ ¶☻H☼
 000000A0: 41 69 00 6E 00 64 00 65 00 78 00 0F 00 33 2E 00 Ai ndex 3.
 000000B0: 68 00 74 00 6D 00 6C 00 00 00 00 00 FF FF FF FF html 
 000000C0: 49 4E 44 45 58 7E 31 20 48 54 4D 20 00 00 2C AA INDEX ~ 1 HTM, 
 000000D0: BF 40 BF 40 00 00 2C AA BF 40 16 02 CF 14 00 00 ┐ @ ┐ @, ┐ @ ▬☻╧¶
 000000E0: 41 6E 00 65 00 74 00 77 00 6F 00 0F 00 98 72 00 An etwo ☼ Shr
 000000F0: 6B 00 2E 00 68 00 74 00 6D 00 00 00 6C 00 00 00 k.  html
 00000100: 4E 45 54 57 4F 52 7E 31 48 54 4D 20 00 00 2C AA NETWOR ~ 1HTM,
 00000110: BF 40 BF 40 00 00 2C AA BF 40 19 02 00 0D 00 00 ┐ @ ┐ @, k┐ @ ↓ ☻ ♪
 00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Carefully assembling the reconstructed folder “ru” and the contents of all files received from the web interface into a disk image (given that the first cluster corresponds to sector 0x23), we get a plain-text version of the WebUI file, the MD5 value for which coincides with 48D1C3194E45472D28ABFBEB6BBF1CC6 from the update header.

We now have the decrypted AutoInstall and WebUI files, and we know the first 2,093,056 bytes of gamma.

6. Let's look at CPUImage

After we decrypted the first 2 megabytes of CPUImage, it finally makes sense to run the disassembler. After determining the processor command system (ARM Little-Endian), the base address of the download (you need to throw out the first 0x34C bytes of the file) and localization of the location for decrypting updates, you can see the following code:

  ROM: 0008ADD0 loc_8ADD0 
 ROM: 0008ADD0 LDR R1, = byte_2ADC60
 ROM: 0008ADD4 LDRB R2, [R1, R0]
 ROM: 0008ADD8 LDRB R1, [R4]
 ROM: 0008ADDC ADD R0, R0, # 1
 ROM: 0008ADE0 ADD R2, R2, R1
 ROM: 0008ADE4 ADD R2, R2, R6
 ROM: 0008ADE8 AND R6, R2, # 0xFF
 ROM: 0008ADEC LDRB R2, [R10, R6]
 ROM: 0008ADF0 STRB R2, [R4], # 1
 ROM: 0008ADF4 STRB R1, [R10, R6]
 ROM: 0008ADF8 MOV R1, # 0x15
 ROM: 0008ADFC BL sub_27C0EC
 ROM: 0008AE00 SUBS R11, R11, # 1
 ROM: 0008AE04 AND R0, R1, # 0xFF
 ROM: 0008AE08 BNE loc_8ADD0 

This is nothing more than loading the encryption key, located at 0x2ADC60 and having a length of 0x15 bytes, into the RC4 algorithm. However, 0x2ADC60==2'808'928 , that is, the key, is located outside the area for which we know the gamma.

True, we have three versions of updates. Suddenly in v3.7 or v2.8 key in a better place? Alas, in earlier firmware, the key location address will be 0x2AD70C and 0x2A852C , which is also outside the decoded area :(

7. And again XOR

If we interconnect CPUImage from v3.7 and v3.7.4 updates, then at 0x34C + 0x2AD70C == 0x2ADA58 we will find the line "SungKook" James "Shin", which is the same RC4 key, on which all files included in in updates.

It remains to make sure that the gamma at the output of RC4, initialized with this key, coincides with that obtained earlier from AutoInstall and WebUI , and that the MD5 from the decoded CPUImage coincides with the value from the update header.

Now you can begin to analyze the actual firmware, but that's another story.

Author : Dmitry Sklyarov, Head of Application Research, Positive Technologies