-
It's my usual thing to have a look into any firmware I'am running on devices in my workshop, My RD6012 is no exception.
After being burned before when updating a device with a locked down bootloader only to get a brick at the end with no OEM support. This time around i dumped the bootloader first.
Sadly the first method used only gives me insight into how the bootloader works , pretty standard, uses the same decrypt at write method the MKS robin and OM127 devices use that I have documented elsewhere.
Once i fully understand the crypt function I will post a open source bootloader that can support factory firmware, I have already done so for other devices so this is clean room code so to speak for all but the key (crypt function).
I have posted this separate to the actual rd60xx firmware page as thats all based around factory function and is not open source.
when looking at the file please understand the dump method does not yet dump all the data , you will see 0xffff in many places, only when i can encrypt a dump routine into the f/w update system can i then dump all the code complete.
Looking at the code so far i have identified two methods to do this, a buffer overflow attack on the UART update system or reversing the encryption/decryption routine and creating a trojan f/w to just dump the flash.
darkspr1te
-
Update file format
AES128 encrypted file :-
0x0-0x3f = Header info - file size - version number
0x40-End of file = Encrypted bin file
Header break down
Byte
0x0-0x3 file size (little endian) (eg 0x0c 0xab 0x01 0x00 = 0x1abc0 file size) - bootloader does fail if receives incorrect amount then will revert to bootloader loop, reset will jump to broken f/w
0x4 Version number in hex (eg. 0x88 = 133dec)
0x5-0x3f
?Key 1 location 0x3f008
Key 2 location 0x3f808
NB: last 4 bytes are incorrect due to extraction method in use atm.
[0x3f008 = 57 11 16 00 67 5B B8 00 C8 23 CB 15 07 00 00 20
0x3f808 = 65 F3 F6 0B 04 6A D7 C2 92 0E 88 9B 07 00 00 20
AES256 key located at 0x52EC +32
SBOXCode: [Select]
static const uint8_t sbox[256] = {
//0 1 2 3 4 5 6 7 8 9 A B C D E F
0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5, 0x30, 0x01, 0x67, 0x2b, 0xfe, 0xd7, 0xab, 0x76,
0xca, 0x82, 0xc9, 0x7d, 0xfa, 0x59, 0x47, 0xf0, 0xad, 0xd4, 0xa2, 0xaf, 0x9c, 0xa4, 0x72, 0xc0,
0xb7, 0xfd, 0x93, 0x26, 0x36, 0x3f, 0xf7, 0xcc, 0x34, 0xa5, 0xe5, 0xf1, 0x71, 0xd8, 0x31, 0x15,
0x04, 0xc7, 0x23, 0xc3, 0x18, 0x96, 0x05, 0x9a, 0x07, 0x12, 0x80, 0xe2, 0xeb, 0x27, 0xb2, 0x75,
0x09, 0x83, 0x2c, 0x1a, 0x1b, 0x6e, 0x5a, 0xa0, 0x52, 0x3b, 0xd6, 0xb3, 0x29, 0xe3, 0x2f, 0x84,
0x53, 0xd1, 0x00, 0xed, 0x20, 0xfc, 0xb1, 0x5b, 0x6a, 0xcb, 0xbe, 0x39, 0x4a, 0x4c, 0x58, 0xcf,
0xd0, 0xef, 0xaa, 0xfb, 0x43, 0x4d, 0x33, 0x85, 0x45, 0xf9, 0x02, 0x7f, 0x50, 0x3c, 0x9f, 0xa8,
0x51, 0xa3, 0x40, 0x8f, 0x92, 0x9d, 0x38, 0xf5, 0xbc, 0xb6, 0xda, 0x21, 0x10, 0xff, 0xf3, 0xd2,
0xcd, 0x0c, 0x13, 0xec, 0x5f, 0x97, 0x44, 0x17, 0xc4, 0xa7, 0x7e, 0x3d, 0x64, 0x5d, 0x19, 0x73,
0x60, 0x81, 0x4f, 0xdc, 0x22, 0x2a, 0x90, 0x88, 0x46, 0xee, 0xb8, 0x14, 0xde, 0x5e, 0x0b, 0xdb,
0xe0, 0x32, 0x3a, 0x0a, 0x49, 0x06, 0x24, 0x5c, 0xc2, 0xd3, 0xac, 0x62, 0x91, 0x95, 0xe4, 0x79,
0xe7, 0xc8, 0x37, 0x6d, 0x8d, 0xd5, 0x4e, 0xa9, 0x6c, 0x56, 0xf4, 0xea, 0x65, 0x7a, 0xae, 0x08,
0xba, 0x78, 0x25, 0x2e, 0x1c, 0xa6, 0xb4, 0xc6, 0xe8, 0xdd, 0x74, 0x1f, 0x4b, 0xbd, 0x8b, 0x8a,
0x70, 0x3e, 0xb5, 0x66, 0x48, 0x03, 0xf6, 0x0e, 0x61, 0x35, 0x57, 0xb9, 0x86, 0xc1, 0x1d, 0x9e,
0xe1, 0xf8, 0x98, 0x11, 0x69, 0xd9, 0x8e, 0x94, 0x9b, 0x1e, 0x87, 0xe9, 0xce, 0x55, 0x28, 0xdf,
0x8c, 0xa1, 0x89, 0x0d, 0xbf, 0xe6, 0x42, 0x68, 0x41, 0x99, 0x2d, 0x0f, 0xb0, 0x54, 0xbb, 0x16 }; -
I've brute forced the missing 4 bytes of both keys (took 16 bytes at+0x90 (the repeating vector table piece) from custom fw release, match criteria: bytes at 3, 7, B, F are 08) - no matches. Either the keys are wrong or AES is tweaked somehow.
Btw, the dump method you are using works a bit better (reading initial SP and PC) when run from addr 0 (where the 08000000 is aliased).
Update: the algo is AES256 indeed and the correct key is at +52EC in the dump (38 12 55 64...). -
And bingo was his name-O.
You hit the nail on the head, I think the other sector of data is maybe factory settings or similar.
image below shows I managed to encrypt 0x00 by 16 and it matches known data. now i can encrypt my dumping code and dump the entire bootloader without issue.
many thanks for your input there, I think i was not seeing the wood for the tree's and overlooking that call, now that i've gone through it with fresh eyes (i had my covid jab and a reaction so forced few days away from my screen) I can see it's the aes 256 decrypter with default SBOX (thats what I used to encrypt)
I will have some tools up soon.
darkspr1te
-
That particular AES implementation in the bootloader is not obvious, it is optimized for flash size and generates tables in RAM. The decrypt function does CBC xors, but they zeroize IVs for each decrypt_block() call so it is plain ECB at the end. Python decryptor (requires pycryptodomex package):Code: [Select]
from sys import argv, exit
from Cryptodome.Cipher import AES
fwkey = b'\x38\x12\x55\x64...\xF7\x3A\x63\x8C'
if len(argv)!=3:
exit("Usage: "+argv[0]+" <infile> <outfile>")
open(argv[2], 'wb').write(AES.new(fwkey, AES.MODE_ECB).decrypt(open(argv[1], 'rb').read())) -
a quick an dirty linux tool to encrypt and decrypt, encrypt option has addition option of adding a default header for trying out your own bin files,
as they say, WIP
usage:-
decrypt:
./fwcrypt -d infile outfile
encrypt:
./fwcrypt -e infile outfile
encrypt with def header:
./fwcrypt -eh infile outfile
darksrp1te
-
More progress now ,
I am able to run my code on the device and dump all data.
a few new findings
the flash offset 0x3f000 and 0xf3f800 are calibrations/versions/lcd types etc and few other bytes like debug mode (does not lock flash)
if any wish to dump their bootloader I can provide a bin file to flash using the factory tool, once dumped you reflash factory firmware for normal function.
darkspr1te
-
I Have further progress now and have a build/test environment almost ready to publish.
from there I will port OpenDPS to the device ,
darkspr1te
-
Hello All,
This is the first test code I'am publishing for the RD60xx based units
https://github.com/darkspr1te/RD60xx_Test_code
This code is currently set to flash at 0x800000 so do not use unless you already have full flash backup.
Those that wish to backup the flash let me know and I will post a program to do so.
This is very early test code and only reads the ADC's for temps and voltage input/battery.
I still have much more work to do to either port opendps or start a new project, yet undecided.
if you wish to use this code on a unit via the bootloader then please be patient. i am currently working on that but wished to release for now.
#edit#
Keyboard, lcd, ADC volts in/battery in working
am working now on power control side via the stm8 chip . more to follow.
darkspr1te
-
New windows tool for encrypting and decrypting RD6012/RD6006 binaries
*BUG*
*fixed - file size seem to increase, I have not yet tracked that issue down yet.
darkspr1te
-
Newer version V0.9
Mainly bug fixes, readability and command line parsing issues
creates a binary matched file with V1.33 and V1.34 binaries. If you remove the header then recreate the file with correct version number
e.gCode: [Select]to keep headerusing V1.33 decrypted with no header with result in a exact match between the two files.
./rdcrypt.exe -d RD60121_V1.33.bin hdr_decoded.bin
to strip the header
./rdcrypt.exe -ds RD60121_V1.33.bin no_hdr_decoded.bin
to encode with new header
./rdcrypt.exe -e 133 no_hdr_dec.bin encV133.bin
-
Why there wont be a v1
I've published enough tools to write your own code, from the git arduino to the codec , others have written the upload tools to match.
I have on purpose missed preproducing the code & "code" of the main authors of software , yes i know it can be "reproduced in rev-engines" but that still takes work.
My set of tools if for those that want to start a new fork of "Tool X" , copy and paste at will.
if Unisoft was to ask me my opinion, i would say "crowd fund 'unisoft' 20,000 US dollar for work I've done so far" and i rekon he would exceed that amount for work deserved and then it would be worth releasing his core code.
so no , i wont release the core operation code yet, I dont feel a need to, bring up code is enough to start making you own tool. Its what people wanted.
with this in mind, this will be this post's last OP post.
darkspr1te, over and out.
-
hi dear darkspr1te
if mcu stm32 Spoiled or burned in rd6012 can change with new one empty mcu with your bootloader it work again if program it with programmer
and serial number is in flash or in mcu
thank you -
if you replace MCU use this flash file first then it will accept factory files ,
https://www.eevblog.com/forum/microcontrollers/rd60xx-mcu-controlled-power-units/?action=dlattach;attach=1240227
darkspr1te
-
hi dear darkspr1te
Bootloader v1.10 will work, only with version RD6012
What about the version RD6006??
Respectfully -
Checked RD60xx_Test_code it works fine
An excellent program for repairing a damaged device.
RD60012-Bootloader-v1.10.bin.zip doesn't work for RD6006
Or I'm not doing it right, what are your recommendations, how can you help.
It is a pity for the damaged device, which does not work only because of the lack of a program -
Quote from github "Okay, I'll be glad to any of your advice.
I'm more of an electronics engineer than a programmer.
)
But I still understand something, and I can continue work"
Dont worry, iam here to help you learn and understand.
Stored on the flash at address 0x3f800 and again later in the flash are the calibration values, lcd type and more.
Now this a very long short but i am attaching a corrupt bootloader and firmware which you will need to write to the device then overwrite the bootloader only. I have used the word currupt but the data we need is in a area not damaged (both copies) , i have personally used this file to recover my unit first time i made a mistake and erased the device.
Now it's possible you may have a late 6006 which came with a different lcd (same as 6012 late model) which we found did not work with v1.0/v1.1 bootloaders , there is no way around that other than begging a user to upload my bootloader dump code to their 6006 and capture the serial output .
anyway, we have options not limited to me actually finishing writing the open bootloader (urr it's like 70% done)
I currently dont have my dev machine up and running as i recently replaced my system and i wanted to do fresh install, so while i have more files we can use I can't access them currently. this is just one i pulled from my private github
darkspr1te
-
Ok, I'll try what I can do.
No, I'll wait when you finish working on the open bootloader.
I hope you don't delay the completion of the project for a long time
-
Yes, you're right, I flashed your dump and after pressing the enter button, I see it.
The display no longer works.
Buttons are responsive and have sound.
-
I will wait when you finish the open bootloader
Until I see no other way -
Please try the open firmware found here
https://mega.nz/file/A0dlVSaT#3Wc6wyPuW6K_5-RMleEDPWttEHcBZ-9vXgbdZhTBLEU
the two firmwares that may be for your unit areQuoteRD60062_V1.37.1g.bin (RD6006)
RD60065_V1.40.1g.bin (RD6006P)
it may be some time before i finish the open bootloader as i have many projects on the go and I also need more info from working units and users with working units tend not to want to play with unknown code. Unless they nuts like me
darkspr1te
-
Sorry, i almost forgot he further info for that mega link,
https://www.eevblog.com/forum/profile/?u=682208;area=showposts;start=25
it's the whole thread on custom firmware, i've not read it of late but there may be some info in there on the two lcd types, i will try and get up to speed myself as i can.
darkspr1te
-
Thanks darkspr1te
for the provided information.
I will try firmware suggestion
And I will look for ways to solve the problem.
I'm also an electronics freak, and I go crazy in my own way.