As per the subject. Here’s the procedure I concocted:
-
Downloaded MC3000_Firmware_Update__V1.18.exe from the SkyRC website;
-
Submitted it at https://virustotal.com/ (which is IME does a good quick-analysis of EXE files, malware or not); at the analysis screen, selected the “DETAILS” tab and noted the following:
TrID Generic CIL Executable (.NET, Mono, etc.) (67.7%)→ Indicates the EXE was written inDot.Net
Manifest Resource
[...]
UpgradeFirmware.loader.hex→ These look very interesting
UpgradeFirmware.rom.hex→ Ditto. -
Googled for a good
Dot.Netdecompiler, found this: GitHub - dnSpy/dnSpy: .NET debugger and assembly editor; downloaded dnSpy-net-win32.zip from the ‘Releases’ section, copied and extracted it into the Desktop of a Win10 machine, then entered the resulted directory and executeddnSpy.exe, and used it to open the above-mentionedMC3000_Firmware_Update__V1.18.exe -
Used the program’s search function to look for “UpgradeFirmware.rom.hex”, then clicked on it in the results, and then in the window that opened (which showed apparently very healthy HEX file contents), and used + and then pasted the results in a Notepad window, saving the result as “UpgradeFirmware.rom.hex.txt”; then using Windows File Manager, renamed the file to remove the “.txt” extension, resulting in a “UpgradeFirmware.rom.hex” file.
-
Repeated 3) above for “UpgradeFirmware.loader.hex”.
-
Used HEX2BIN to transform convert both .HEXes to the corresponding .BINs, producing UpgradeFirmware.loader.bin and UpgradeFirmware.rom.bin; HEX2BIN produced the following output, respectivelly:
5a) UpgradeFirmware.rom.hex:
Allocate_Memory_and_Rewind:
Lowest address: 08004000
-> According to [1], this MCU's [3] flash starts at 08000000; so this HEX skips the first 0x4000 (16K) bytes, which is probably reserved space for the other HEX below);
[1] https://community.st.com/t5/stm32-mcus-products/stm32f4-memory-organization/m-p/480785/highlight/true#M166839
Highest address: 0801A95B
Starting address: 08004000
Max Length: 92508
Binary file start = 08004000
Records start = 08004000
Highest address = 0801A95B
Pad Byte = FF
5b) UpgradeFirmware.loader.hex:
Allocate_Memory_and_Rewind:
Lowest address: 00000000
Highest address: 0000B20F
Starting address: 00000000
Max Length: 45584
-> This seems too large for a mere (boot)loader... and when added to the 92508 bytes
of the main code above, exceeds the 128KB flash capacity of this MCU. When considered
along with [2] below, this seems to indicate this file is some kind of "red herring"
and not actually part of the firmware update process.
Binary file start = 00000000
Records start = 00000000
Highest address = 0000B20F
Pad Byte = FF
-
Opened both .BIN files with a binary hex editor/visualizer and had a look around looking for strings etc:
UpgradeFirmware.rom.binseemed very promising, in fact I could locate a lot of messages I’m used to see in the charger’s display during normal operations. [2] As perUpgradeFirmware.loader.bin, its ‘excess size’ noted above could perhaps be explained by the large areas filled with FFs (which HEX2BIN identified above as the “Pad Byte”), but these areas are smack in the middle of the image; other things didn’t look as good, eg the message “.S.I.L.I.C.O.N. .L.A.B.O.R.A.T.O.R.I.E.S.8.C.8.0.5.1.F.3.x.x. .D.e.v.e.l.o.p.m.e.n.t. .B.o.a.r.d” (the “.” are non-ASCII bytes, indicating the message is coded in an one-char-per-16bit-word manner, possibly UNICODE), but anyway some googling brought this up: C8051F380DK C8051 8-bit MCU Development Kit - Silicon Labs; this seems totally off the mark, being a development kit for a 8051-compatible MCU, which is a totally different beast than the [3] STM32-compatible STM32F103RBT6 clone that reportedly powers this charger.
I dont believe this charger would have two different MCUs, specially not a separate one just for booting, so more and more I’m starting to think that this “loader.hex” file is some kind of red herring or leftover from some other project. -
Then I tried the disassembly/decompiling tools that I could find/borrow (specially IDA Pro 7.0 and 7.3, at a friend’s computer that actually has licenses for them) but wasn’t able to make further progress. I got the impression that IDA is not actually very appropriate for ARM MCU image disassembly/decompiling – but this could be because these were old versions, from 2017 or so. Unfortunately I didn’t have access to any other versions, or other tools.
As I’m totally inexperienced with the STM32 architecture and even more with this specific MCU, and moreover reverse engineering is not really my forté (I’m much better at compiling than de-compiling 
), I will end this here, at least for now, and hope that someone more experienced and knowledgeable than me in these matters can pick the torch 
up and continue ahead.
Anyone wanting the HEX files and not willing to go to all the rigmarole above, I can supply the ones I extracted – please contact me over PMs as I’m not posting them here to avoid cluttering our beautiful forum with large-ish files that will probably not be of interest to most people.
but definitely following this effort 
