STM32 + Gotek floppy emulator

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32 + Gotek floppy emulator

Postby RogerClark » Thu Mar 02, 2017 10:43 pm

Andy

I think you're right. Using alternative firmware is probably the only viable solution

victor_pv
Posts: 945
Joined: Mon Apr 27, 2015 12:12 pm

Re: STM32 + Gotek floppy emulator

Postby victor_pv » Thu Mar 02, 2017 11:36 pm

RogerClark wrote:Victor, I like the idea of dumping the code simply by uploading and running from ram, but I suspect that STM would have thought of that possibility.
You may find you cant upload to RAM at all with read protection enabled.



Roger I was able to upload to RAM successfully. You can also write to flash at least from code running in the MCU, without removing the read protection. That's how the stlinks can update themselves, but be read protected. They dont remove the read protection, just write. Read and write protection are separate, and write protection can be disabled without affecting read protection.
I am not sure if STLink will allow you to write to flash when read protected, may not, but I think that's the tool blocking it, not a limitation on the MCU.

I could upload to RAM, and read back from ram without issues, but I had some something wrong cause my code was crashing, but I didn't spend much time checking what was it. May have placed the vector table in the wrong place or something like that.
I'll give it another shot when I have time to see what I get. I tried it in an RCT MCU, with 64KB of RAM, so there was enough for code, heap and stack.
May not be feasible in one with 20KB, but I think a basic sketch that just dumps to USART without too much fancy stuff would fit in there too.

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32 + Gotek floppy emulator

Postby RogerClark » Fri Mar 03, 2017 1:11 am

Hi Victor

OK. Thats interesting.

I presume you uploaded to RAM using STLink or perhaps BMP using GDB ? Or with the Serial bootloader ?

Can you change the PC to that the processor will execute from RAM, I thought some of those debugging features were disabled when the device is read protected.

Re: Erasing a page in flash when read protected

I see what you mean. Yes. STLink must do that, as it can update its self when read protected. But like you said, you may not be able to erase a page of flash from SWD if read protected


BTW. The hack for reading back the nRF51 is to run GDB, clear all the registers. Set the PC to a random address in flash.
Single step.
Look at the contents of the registers.
If the instruction that was executed when you single stepped was an instruction which uses one of the registers as the address for the a read from memory, you end up with the contents of 0x000000000 in one of the registers, and since the reset vector and start vector are commonly known values, it doesnt take long to single step the code multiple times until you find a value of PC which will read from memory

But, this doesn't appear to work on the STM32, as they seem to have locked this down, and I think single stepping may be disabled by read protection

If you can upload to RAM and jump to RAM and run, then as long as RAM instructions can read from Flash, the system would be wide open, even if you couldnt set up a uart etc, because you could simply copy 1k chunks of flash into the RAM and read out the chunks one by one in GDB

BTW. GDB is scriptable.

However, I just have my doubts about whether STM have not already considered all of these ways that people may try to read out the code and I suspect they are all locked down e.g RAM instructions may not be allowed to read flash locations, or perhaps you can't set the PC or perhaps you can't run.

victor_pv
Posts: 945
Joined: Mon Apr 27, 2015 12:12 pm

Re: STM32 + Gotek floppy emulator

Postby victor_pv » Fri Mar 03, 2017 4:38 am

All that is possible. I know it allows reading and writing to RAM, and the MCU would try to run from RAM with the right levels in the boot pins, I could see the PC changing, but then would crash and enter a loop.
I don't think I enabled read protection for the test, but I may have, and then the crashing may have been due to the protection.
I need to try again and confirm. I was just curious about that, not that I really needed to read anything from a protected device.

User avatar
Pito
Posts: 609
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32 + Gotek floppy emulator

Postby Pito » Fri Mar 03, 2017 8:16 am

RogerClark wrote:The STM32 has strong firmware readback protection to stop counterfeiter reading the firmware binary file and putting it into their cloned products.

How they (cloners) did read back the stlink's sw??

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32 + Gotek floppy emulator

Postby RogerClark » Fri Mar 03, 2017 9:42 am

The Stlink binary was hacked using by intercepting the update binary not by reading back the binary within the STM32 in the stlink

There is a long blog post (sorry I don't have the link to hand), which described how the PC (exe) updater was hacked, so that a decrypted version of the binary could be extracted from its ram while the exe was being run in a debugger.
STM made the mistake of not doing end to end encryption. Instead they used an encrypted binary, which is downloaded to the exe, and then decrypted to RAM before being re-encrypted before being sent via USB to the STLink.
If they had done all the decryption inside the STlink the hack would not have been possible.

victor_pv
Posts: 945
Joined: Mon Apr 27, 2015 12:12 pm

Re: STM32 + Gotek floppy emulator

Postby victor_pv » Fri Mar 03, 2017 5:11 pm

RogerClark wrote:The Stlink binary was hacked using by intercepting the update binary not by reading back the binary within the STM32 in the stlink

There is a long blog post (sorry I don't have the link to hand), which described how the PC (exe) updater was hacked, so that a decrypted version of the binary could be extracted from its ram while the exe was being run in a debugger.
STM made the mistake of not doing end to end encryption. Instead they used an encrypted binary, which is downloaded to the exe, and then decrypted to RAM before being re-encrypted before being sent via USB to the STLink.
If they had done all the decryption inside the STlink the hack would not have been possible.


There was another way someone did, he was able to replace the bins in the updater, so his code would be updated to the stlink (using the stlink bootloader), and then he dumped the bootloader code.

User avatar
Pito
Posts: 609
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: STM32 + Gotek floppy emulator

Postby Pito » Fri Mar 03, 2017 6:56 pm

Here is my hypothesis:
"The ability to upload a new binary into the mcu's flash memory always allows the reading the content of the mcu's flash memory"
:)

User avatar
BennehBoy
Posts: 384
Joined: Thu Jan 05, 2017 8:21 pm
Location: Yorkshire
Contact:

Re: STM32 + Gotek floppy emulator

Postby BennehBoy » Fri Mar 03, 2017 7:56 pm

I don't think the OP is coming back, but it's still an interesting thread.

I was looking at one of these devices to put into an Amiga - it seems pretty simple to flash them with different firmware from what I've seen, and the firmware is 'obtainable'.
-------------------------------------
https://github.com/BennehBoy

User avatar
RogerClark
Posts: 5466
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32 + Gotek floppy emulator

Postby RogerClark » Fri Mar 03, 2017 8:32 pm

Yep.

This has turned into a technical discussion on Read Protection and reverse engineering, which is still on topic as far as I am concerned.

Re:modifying the bins

I think you may be referring to the reverse engineering and decryption of the Java based updater.

I am not sure if the binaries that can be extracted from that updater are the entire binary, or just the "application" code, rather than bootloader and application.

I did briefly mess around with the updater and try renaming the binaries so that it uploads a different binary to the Stlink, but it wasnt that useful, as it would not update a dongle to be the version with USB mass storage and UART because the updater checks the flash size and the dongles only are technically only 64k, ( in reality they are 128k)
hence the updater thinks the flash is too small.

BTW. i know someone hacked the java bytecode to allow lager uploads, but they didnt post the hacked java file, only a description of how they did it.


Return to “STLink”

Who is online

Users browsing this forum: No registered users and 1 guest