I´m new here and I am not sure if ST-link can solve my problem as I don’t 100 % understand the function. I will try explaining what I want to do. I recently bought two x Gotek floppy emulator from China from two different sellers. The hardware is 100 % identical, but the firmware is different.
I would like to use be able to copy or duplicate the firmware content from one of the devices and overwrite the other, so they have identical firmware.
Gotek floppy emulator uses Cortex-m3 stm32f105RBT6 and I think both are with read-out protection enabled as I’m forced to “erase” before I can read.
Can this ST-link device solve my devices or do I need to look in another direction?
Extracting the firmware from inside the chip is not an option for hobbyists, and is basically uneconomic for virtually anyone else.
If the board is obsolete, your best bet is to approach the manufacturer and see if they will see you the binary firmware file.
Extracting the firmware from inside the chip is not an option for hobbyists, and is basically uneconomic for virtually anyone else.
If the board is obsolete, your best bet is to approach the manufacturer and see if they will see you the binary firmware file.
You may find you cant upload to RAM at all with read protection enabled.
I am not sure if you can even upload to empty pages of flash with read protection enabled.It may be possible via swd but not by the bootloaoder.
Also, I dont think you can alter the registers e.g. the PC when read protection is enabled, in fact most SWD functions are disabled.
The trick where you change the PC address, works on some chips, including the Nordic nRF51822, but I tried it on the STM32 a few months ago, and it does not work.
Actually, what I tried was setting the PC and then single stepping in the debugger, and I know that does not work. But I cant recall if you can set the PC and then perhaps run from that location.
I guess if you manage to install some code that dumps the flash via serial, and put it in the top page of flash, ( if its possible to write to that area of flash), you may be able to get the code to crash and execute the dumping code, but it seems unlikely.
… and here …. -> https://cortexamigafloppydrive.wordpress.com/
I think you’re right. Using alternative firmware is probably the only viable solution
You may find you cant upload to RAM at all with read protection enabled.
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.
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.
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 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.
“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”
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’.
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.
I put my obsolete AVR code on git along with some code for MIDI driver interfaces
https://github.com/sheepdoll/AVRMIDIHardwareASM.git
It may be of interest for others to see two different takes on code that runs on the same hardware. The first attempt was to create code that was based on the user manual documentation specifications. Namely the SYSEX dumps. ATMDI88.ASM was the result. When the successor to the creator of the board got ill then passed away I found the online updater code posted as shareware http://midiator.millsnovelty.com/Software/index.html
As I use this hardware in production, I took over some of the support on this product. Not sure how long the above website will be active. The current maintainer is of advanced age with family and personal medical issues. I found in a local surplus store the remaining stock of programmable Roms. I inherited the remaining hardware to complete in case the existing production units fail. So far no critical systems have failed. (or else they have been upgraded to newer hardware) When Arduino happened;. Now one can build an equivalent device for the cost of a single starter kit. The legacy 68HC11 chips alone can individually cost as much as an Ardino starter kit or Raspberry pi.
As there is/was updater code released online, I was able to dump the .S file then dump the update section (which uses MIDI SYSEX messages.) This was done with a windows 98 machine, which I no longer have. This resulted in the port from 68HC11 inside the git as OctetAvr.asm.
Now to the topic of this thread The floppy disk emulator. My MIDI floppy player was designed to interface to the OCTET UM0. This was not an emulator, although I considered coding one. Interesting enough to change a Hardware floppy disk assembly to work with these MIDI players one has to set the straps on the FDA the same as an AMIGA.
As noted I inherited the first 8051 based MIDI file sequencer hardware with no driver software. I was hired to write it from scratch. The hardware used the SMSC37C38 floppy disk controller that was used in most PC floppy disk cards and laptops. I started with the POSIX driver code and had to simulate the DMA using the chip register mode. In theory the chip could run in NON DMA mode. In contacting the manufacture they claimed that I and the people who could not write the software that I inherited were the only ones that wanted to use this chip register mode. That there was a silicon bug.
As I did get it to work on the AVR I think that there was not really a silicon bug (Or I worked around it.) By the time I got it working (10 years ago) floppies were obsolete. I sold about 5 units to recover costs. Still have the better part of a tray of the controller SMSC37C38 chips and AT90S8515 processors with like a 0247 date code. Yes 47th week of 2002. These are first generations AVR and have a speed grate of 4 MHz! I also have the 128KB SRAM chips, which could be useful If I could figure how to interface them. I am pretty sure there is no market for adding a floppy disk drive to a F103 or F104, although it would probably be trivial using the on board support for DMA mapped devices.
What most folks want is the other way make old hardware see a flash drive as a floppy. There are two ways then to emulate floppies on embedded systems. One is to emulate the analog timing and motor step control. The other would be to replace the SMSC37C38 which is a register device that works similar to the way the poplar hx8257 LCD drivers work. In either case one is mapping the storage space by cylinder track head addresses. Where the fun begins is dealing with FAT12 non bit aligned FAT entries as well as sparse sectors which jump tracks, so one has to buffer the track and write things in Fat order rather than file order. Anyone want a SPI based Floppy interface for Arduino? I think I may have some interesting Retro hardware for my sadly neglected blog. The Floppy disk Shield 
At least with floppy disk emulation one does not have to worry about badCRCs and misaligned tracks.
None of this is new. Back in the early days of Hard drives and the Apple ][ computer there was a company called Corvus, which made Hard drives. When the Apple /// and the //e came out. They made a parallel port connected drive. My first hard drive was one of these. All of 18 megabytes. When it was connected to the Apple ][ Dos system it would look like a stack of floppy disks. Each with it’s own drive letter. On the apple /// one could have the whole drive partitioned as apple had the 5MB ‘profile drive’ (later used on the Mac and Lisa) In my spare time I wrote the proDos driver. As usual by the time I got it to work, Corvus was bankrupt. I did use that 18MB drive on my Mac by converting it to SCSI. A lot of storage space for 1987. I upgraded the HDA a number of times keeping the old case, Till SCIS became obsolete. I do still have on black foam, the Apple ][ driver rom with it’s glass window, wonder if the Apple ][ code is still programmed. My code is long lost unless it is somewhere on the stack of Apple //e floppy disk images stored on a CD rom somewhere in my backup drawer.
(ie decapsulate the chip package and erase the flash cell holding the read security bit).So for highest security you need special chips with countermeasures built into the silicon.
Attacks for example:
http://www.cl.cam.ac.uk/~sps32/NCL_2011.pdf
Today you can simply measure the mcu’s Vdd current with a digital oscope-like tool and you will extract the keys within minutes.
And here – just listen to your notebook’s noise and get the keys
https://www.youtube.com/watch?v=DU-HruI7Q30
How they (cloners) did read back the stlink’s sw??
How they (cloners) did read back the stlink’s sw??
A few years back this encryption was hacked. The issue was that every time the document was saved it generated a new key that was stored in the plain text part of the code. Since only the key changes when the file was saved the breakers could see what encryption was used. The result analysis was that if they had not changed the key so often the pattern would be harder to detect.
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’.
I’m knew to this MB. I’m interested in a boot loader for these with the STM32105 chips.
I’m mostly interested in emulating floppies for things that are obsolete. My worst case is
machine that uses 32 hard sectored 8 inch floppies. I’d sent a message to the fellow in France
that sells various emulators for a number of more common vintage machines
but he doesn’t seem interested in my problem.
I’ve only played with the Arduino a little. I wrote a simple pong game to play on one
of those tiny oled displays. I also wrote code to make a pendulum clock calibrator.
This was done in C that I’m not that versed in.
I’ve looked at the source code for one of the boot loaders when I was thinking of making
it so I could write to flash without the write protect bit getting in the way.
I never finish that as I was making small ( smaller ) 6530 to 6532 adapters for the KIM-1
computer. I’d also written diagnostic code for the board to run on a board that would
plug onto the expansion connector and take over from the onboard ROM.
My first code was to do a RAM test without using an RAM( tricky on a 6502 with only 4 registers ).
It sounds like this board is the right place to be when I have questions.
Dwight
[dwight – Fri Aug 04, 2017 3:32 am] –
Hi
I’m knew to this MB. I’m interested in a boot loader for these with the STM32105 chips.
This may work on the F105.
https://github.com/rogerclarkmelbourne/ … bootloader
Its written for the 103 but I’m pretty sure it runs on the 101
BTW. Do you really mean the STM32F105 or do you mean the F103 as there aren’t may F105 boards that I’m aware of
search in store finds it
srp
was cheap. It is intended to be a floppy emulator for music keyboards.
A fellow in France has written emulators to run on it for most clasic
computer, like TRS80 and Atari 800s.
I’ve got kind of odd ball stuff in mind. He is more into licensing his
code. It is not much incentive to write code for a machine that, to
my knowledge, there are only 5 in existence.
I expect to be writing much of it in assembly but I’d like to write the
first level of code in C and then rewrite the needed parts in assembly
where speed is more critical. Writing signals out to look like a floppy is
the easy side. Sampling MFM data on the fly and encoding it in an
efficient data form is a little more tricky.
The Gotek board was design to work as a floppy. As the famous last
words, all it needs it the software.
Dwight
USB port that the STM32F103s have. Is that going to be an issue?
Dwight
However, they only released the new version for the F1 in the last few weeks and don’t support many boards yet.
https://www.aisec.fraunhofer.de/en/Firm … ction.html
