VIIPlus Loader USB traffic firmware upgrade
So I could not leave it without looking into the USB data sent from the VIIPlus loader 
I have used USB Analyzer to grab the USB traffic to and from the interface and are now
able to decrypt and see what it is.
First are standard Hex-V2 commands and this one is to ask for the AES key to be used for USB encryption.
Code:
01 0A 01 01 04 0A 01 00 00 24 00 00 00 2B
Usually this key is generated by random but the VIIPlus firmware uses same key for every session which is:
Code:
0000 : 48 2B BE 19 9B B7 DD 11 05 CE 16 07 CC AB 42 EF
0010 : 2E B5 8C B6 C7 5D 27 3B F1 8A 79 26 DB F1 FF D1
(Thank you who every you are. This makes ting a bit more easy
)
The AES-IV used will be received in the encrypted data and is then looked up from a table of 16 different values.
Code:
01 15 01 01 04 15 F7 F7 70729A342B6F25A948E5D49320D88014 F3
Here AES-IV index 8 is used taken from the 0xF7 byte (1+(0xF7&0x0F))
And last byte 0xF3 is the xor checksum and should give the result 0xFF or 0x00.
I will from now only show the decrypted AES data which is of more interest.
The AES encrypted command above will decrypt to:
Code:
0000 : 08 FB 00 01 01 43
and 0x08FB is VIIPlus Hex-V2 commands and is not used by RT.
The command to be executed by the firmware here is 0x43 and will return some number which I don't know what is yet.
0x42 is used to ask for firmware version:
Code:
-> 0000 : 08 FB 00 01 01 42
<- 0000 : 08 FC 00 0A 0A 42 00 30 31 2E 30 33 2E 30 32 | .....B.01.03.02
and 0x56 is the tell the interface to start the bootloader.
Code:
-> 0000 : 08 FB 00 05 05 56
<- 0000 : 08 FC 00 08 08 56 00 00 00 00 00 00 00
VIIPlus will now ask for the UID's MD5 0xCA padded using the 0X53 command:
Code:
-> 0000 : 08 FB 00 02 02 53 CA
<- 0000 : 08 FC 00 12 12 53 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
for so to start sending the firmware itself using the 0x51 command
Code:
-> 0000 : 08 FB 05 05 DC 51 00 00 00 00 xx xx xx ......
The size of this packet is 0xDC bytes so there is a lot of data.
The 0x05 indicates that the firmware should expect 5 of these packets and the
combined size will be 1280 bytes.
After this you will see only a chuck of 4 which will give a total size of 1024
When the bootloader have received 32k it will start flashing it to the STM.
And this loop will continue until full firmware upgrade is sent.
Now there is a good reason for why the first block is 1280 bytes and these
extra 256 bytes is split in two 128 bytes packets.
In my previous post I mention that the OTP data is RSA encrypted and that I
found three 1024 bit's RSA keys present in the BL. For OTP only key 2 was used
and now key 1 and key 3 is used to decrypt these two 128 bytes blocks.
When decrypted they look like this:
Code:
0000 : 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ................
0010 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ................
0020 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF | ................
0030 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 | ................
0040 : 55 53 45 52 2D 41 50 50 xx xx xx xx xx xx xx xx | USER-APP.7w....|
0050 : xx xx xx xx xx xx xx xx 00 00 00 00 00 00 00 00 | C...~...........
0060 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0070 : 00 00 00 00 00 00 00 00 00 01 04 00 00 00 00 00 | ................
0000 : 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF 00 | ................
0010 : 55 53 45 52 2D 41 50 50 30 31 2E 30 33 2E 30 32 | USER-APP01.03.02
0020 : aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa | ...C..X...\.@@..
0030 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0040 : bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb | .&..n....>....P)
0050 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0060 : 00 00 04 00 00 00 04 00 00 00 02 08 EF 0C 00 00 | ................
0070 : 34 66 9F 45 2B ED 71 22 00 00 00 00 00 00 00 00 | 4f.E+.q"........
The first packet contains the UID's MD5 0xCA padded (removed) and the next
packet contains firmware version and some info about the image itself.
(The two 128 bits keys? is removed coz I don't know what they are used for)
We can see the size 0x40000 and where it should be stored 0x08020000.
At offset 0x70 you can find the 8 bytes used as the TEA-IV for decrypting
the rest of the firmware.
The TEA-Key to decrypt is found in the decrypted OTP data and is:
TEA-FW-Key: 9022B8F09C30028A6833EE824792F340
TEA-FW-IV : 34669F452BED7122
Decrypt 32k 0x8000 bytes and then restart with same IV.
TEA-CBC can be found in my previous post(s)
The iv is the same in all of my upgrades and also the same from upgrades I received from test users.
So I guess the like hard coded values 
Now. Can we make a custom firmware?
Yes I think we can. The RSA private key is located in the VIIPlus tool and will
take some time to find.
But we could use and already existing RSA block and add our custom firmware to it?
I believe the 0xEF0C is some checksum so will have to take that into consideration.
A custom firmware could be used to extract OTP data and also read out the 1024 bit's value from the LKT4106
It could also fix up some of the interfaces that users have issues with? (device is blocked etc)
Bookmarks