Tutorial  Updated

How to flash the HWFLY Clone chips

See below for updates.

IF YOU BREAK YOUR BOOT0 PIN. DO NOT DM ME ASKING FOR HELP. THAT'S IT. YOU BREAK THAT PIN AND YOU CANT FLASH. YOUR CHIP IS STUCK WITH WHATEVER HWFLY PUT ON IT


Pre-requisites:




  • Raspberry Pi Zero W
    • You may use another flasher if you desire.
  • Pinout Diagram
  • Modchip Diagram
  • FULL_CHIP_STOCK.bin
  • Modchip Diagram, find the PA9(TX) and the PA10(RX) pins on your modchip, and do the following:
    • Connect GPIO14(TX) on your Raspberry Pi Zero W to the PA10(RX) pin on your modchip.
    • Connect GPIO15(RX) on your Raspberry Pi Zero W to the PA9(TX) pin on your modchip.

  1. Solder a wire to each of the following pinouts on the Raspberry Pi Zero W:
    • 3.3V
    • Ground
    • GPIO 14 (UART TX)
    • GPIO 15 (UART RX)
  2. Do the following to prepare the modchip:
    1. Lift pin 44 (also known as BOOT0).
    2. You will need a way to power the chip, so you need to find two 3.3v points. It can be on a MOSFET, but it will differ based on the revision of the modchip.
    3. Connect Ground on your Raspberry Pi Zero W to the Ground pin on your modchip.
    4. Check the Modchip Diagram, find the PA9(TX) and the PA10(RX) pins on your modchip, and do the following:
      • Connect GPIO14(TX) on your Raspberry Pi Zero W to the PA10(RX) pin on your modchip.
      • Connect GPIO15(RX) on your Raspberry Pi Zero W to the PA9(TX) pin on your modchip.
  3. Boot your Raspberry Pi Zero W and do the following:
    1. In the terminal, type the following command, and press enter:
      Bash:
      sudo nano /boot/config.txt
    2. Add the following line to the end of the file:
      INI:
      dtoverlay=pi3-miniuart-bt
    3. Press CTRL + X to save and exit the editor.
    4. In the terminal, type the following command, and press enter:
      Bash:
      sudo nano /boot/cmdline.txt
    5. Remove the following line from the file:
      INI:
      console=serial0,115200
    6. Press CTRL + X to save and exit the editor.
    7. Restart your Raspberry Pi with this command
      Bash:
      sudo /sbin/reboot
    8. In the terminal, type the following commands, and press enter after each command:

      Bash:
      git clone https://github.com/Pheeeeenom/stm32flash.git
      cd stm32flash
      sudo make install
  4. Now you will flash the modchip.
    Note: This will remove read protection, and the modchip will wipe itself (that is what we want).
    1. In the terminal, type the following command, and press enter:
      Bash:
      stm32flash -k /dev/serial0
    2. Now to flash Spacecraft-NX Version 0.2.0, type the following, and press enter:
      Bash:
      stm32flash -v -w ./FULL_CHIP_STOCK.bin /dev/serial0
  5. Once you're done flashing your modchip, remove the wiring from the modchip, and restore the 3.3v pin on the modchip to its original position.

Please post pictures of your work here to further the identification of the different board revisions!


UPDATE: So it seems like stitching the spacecraft bootloader and firmware together from the repo causes unstable glitching behaviors. For now, consistent glitching behavior works with this bootload/firmware combo.
This is the original file on the OLED variant chip which has 0.2.0 spacecraft. As for glitching, I'll figure it out, give me some time...unless someone else wants to hop in and reverse the differences.

For now, this at least solves the 0.1.0 HWFLY gen 3 issue. More to come.

UPDATE 2: This is only going to work on some HWFLY chips. Older ones use higher protection than the new revisions that seem to use the QFN FPGA.

UPDATE 3: This should fully work on OLED modchips with the QFN FPGA. https://github.com/Pheeeeenom/firmware
 
Last edited by Mena,

Andrey_Egorov

New Member
Newbie
Joined
Jan 13, 2022
Messages
4
Trophies
0
Age
31
XP
24
Country
Russia
Can I just flash a new GB32 with oled fiirmware and replace the one on hwfly lite ?
Hi. I tested different types of chips, orig sx core and hwfly versions with spacecraft v1/v2 on board. I'm not sure fpga is 100% write protected. Perhaps she checks the software version with the software version in gd32. If you transplant gd32 from any of the chips (orig, 0.1.0 sc, 0.2.0 sc), swap them - the chips stop working. I suggested that it might be possible to buy a new gd32, write sc 0.1.0 to it, and after that, try to update the chip to 0.2.0 using sc-nx updater. I have debug discovery boards for stm32, until I figured out how to flash your bin on the controller
 
  • Like
Reactions: BigOnYa

james194zt2

Well-Known Member
Newcomer
Joined
Jan 4, 2022
Messages
57
Trophies
0
Age
42
XP
165
Country
United Kingdom
Hi. I tested different types of chips, orig sx core and hwfly versions with spacecraft v1/v2 on board. I'm not sure fpga is 100% write protected. Perhaps she checks the software version with the software version in gd32. If you transplant gd32 from any of the chips (orig, 0.1.0 sc, 0.2.0 sc), swap them - the chips stop working. I suggested that it might be possible to buy a new gd32, write sc 0.1.0 to it, and after that, try to update the chip to 0.2.0 using sc-nx updater. I have debug discovery boards for stm32, until I figured out how to flash your bin on the controller
I will be really surprised if that FPGA is not fully as write protected as possible, this is the "Achilles heel" of the HWFly, with that cracked there is nothing stopping any of us grabbing an order from PCBWay and making our own boards.

The biggest pain with it is that is a reball job to take it on and off, I was going to do some digging in to that next after I had cracked the STM32 on this board, it looked like several pins are not exposed on the PCB so knowing our luck it is almost guaranteed to be the ones we need to work on it!

Have you got the firmware for the 0.1 HWFly? I asked about an issue I was having over at Spacecrafts site and the dev told me that the 0.1 firmware on these is a heavily modified of Spacecraft 0.1, so a straight dump of the original version from the devs on to a blank STM32 is probably not going to work.

The first step I wanted to try was to flash a brand new STM32 with the original firmware AFTER removing the write protection flags out with the original firmware, then taking it from there really.
 
  • Like
Reactions: leerz

Andrey_Egorov

New Member
Newbie
Joined
Jan 13, 2022
Messages
4
Trophies
0
Age
31
XP
24
Country
Russia
Hi. I tested different types of chips, orig sx core and hwfly versions with spacecraft v1/v2 on board. I'm not sure fpga is 100% write protected. Perhaps she checks the software version with the software version in gd32. If you transplant gd32 from any of the chips (orig, 0.1.0 sc, 0.2.0 sc), swap them - the chips stop working. I suggested that it might be possible to buy a new gd32, write sc 0.1.0 to it, and after that, try to update the chip to 0.2.0 using sc-nx updater. I have debug discovery boards for stm32, until I figured out how to flash your bin on the controller
Well, fpga is unequivocally read-protected, I'm not sure that this necessarily means that it is also write-protected. I don't have a hwfly 0.1 dump, but I have the hwfly v1 core/lite chips, and the hardware to work with stm32 (stlink v2, stm32f4x-discovery)
 

Andrey_Egorov

New Member
Newbie
Joined
Jan 13, 2022
Messages
4
Trophies
0
Age
31
XP
24
Country
Russia
I will be really surprised if that FPGA is not fully as write protected as possible, this is the "Achilles heel" of the HWFly, with that cracked there is nothing stopping any of us grabbing an order from PCBWay and making our own boards.

The biggest pain with it is that is a reball job to take it on and off, I was going to do some digging in to that next after I had cracked the STM32 on this board, it looked like several pins are not exposed on the PCB so knowing our luck it is almost guaranteed to be the ones we need to work on it!

Have you got the firmware for the 0.1 HWFly? I asked about an issue I was having over at Spacecrafts site and the dev told me that the 0.1 firmware on these is a heavily modified of Spacecraft 0.1, so a straight dump of the original version from the devs on to a blank STM32 is probably not going to work.

The first step I wanted to try was to flash a brand new STM32 with the original firmware AFTER removing the write protection flags out with the original firmware, then taking it from there really.
Well, fpga is unequivocally read-protected, I'm not sure that this necessarily means that it is also write-protected. I don't have a hwfly 0.1 dump, but I have the hwfly v1 core/lite chips, and the hardware to work with stm32 (stlink v2, stm32f4x-discovery)
 

james194zt2

Well-Known Member
Newcomer
Joined
Jan 4, 2022
Messages
57
Trophies
0
Age
42
XP
165
Country
United Kingdom
Well, fpga is unequivocally read-protected, I'm not sure that this necessarily means that it is also write-protected. I don't have a hwfly 0.1 dump, but I have the hwfly v1 core/lite chips, and the hardware to work with stm32 (stlink v2, stm32f4x-discovery)

Yes definitely read protected from my understanding, not even looked at it! but my understanding is it is write protected as well hence why it can't learn timings of the specific console. Plus generally read protect forces write protect as well on the NAND side of things.

The issue is the STM32 of a lot of us are level 2 protected so we cant read them over STLink/UART etc... and dump the firmware, never mind write it sadly.
 

Mena

Well-Known Member
OP
Member
Joined
Oct 5, 2020
Messages
148
Trophies
0
Age
29
XP
1,032
Country
United States
Out of interest, has the firmware and bootloader for the 0.1 HWFly core been dumped somehow? Was going to try and dump it over the weekend (GD32 vs ChipWhisper to glitch the level 2 flag), but wondered if we already had it to have a look inside?

I am assuming it is in the BOOT0 file due to the tool to compare if it is 0.1 or 0.2 Spacecraft as well? but is it complete and I am doubting it includes the bootloader even if it is in there.
If you’re going to glitch it, you’ll need to do an invasive hw sanding to access IO2 on QSPI
 

Andrey_Egorov

New Member
Newbie
Joined
Jan 13, 2022
Messages
4
Trophies
0
Age
31
XP
24
Country
Russia
Yes definitely read protected from my understanding, not even looked at it! but my understanding is it is write protected as well hence why it can't learn timings of the specific console. Plus generally read protect forces write protect as well on the NAND side of things.

The issue is the STM32 of a lot of us are level 2 protected so we cant read them over STLink/UART etc... and dump the firmware, never mind write it sadly.
Well, that's why I thought that you can buy a new clean gd32, not blocked, flash it to 0.1.0 sc or hwfly 0.1 (if you can count) and then try to update to 0.2.0 or to the modification that is presented here. But if firmware 0.1 in hwfly and sc 0.1 are different, nothing will probably come of this idea
 

james194zt2

Well-Known Member
Newcomer
Joined
Jan 4, 2022
Messages
57
Trophies
0
Age
42
XP
165
Country
United Kingdom
If you’re going to glitch it, you’ll need to do an invasive hw sanding to access IO2 on QSPI
Possibly, although it looks like you can glitch the GD32 in to level 1, which will re-enable to the SWD interface, then apparently if you attempt a read, you can then glitch the read out command and corrupt it so that you can read out the firmware from what I have been investigating.

I am hoping to use this attack vector to start with without going physical on it, then look at disabling the flags in the bootloader on a blank STM32 before removing and installing this new chip back on my board.

I know it doesn't help people who are struggling with the flashing of the firmware, but I think having all of the firmware versions with the level 2 flag disabled will help an experienced installer, they should be able to whip that GD32 chip and replace with a new chip costing a couple of $ in a matter of minutes instead of these chips just being dumped.

Ideally the key is the FPGA I would love that to get dumped so we can kick all these dodgy clones out of the door, the price point is disgusting and the fact they are purposely crippling them is the icing on the cake to this.
 

james194zt2

Well-Known Member
Newcomer
Joined
Jan 4, 2022
Messages
57
Trophies
0
Age
42
XP
165
Country
United Kingdom
Well, that's why I thought that you can buy a new clean gd32, not blocked, flash it to 0.1.0 sc or hwfly 0.1 (if you can count) and then try to update to 0.2.0 or to the modification that is presented here. But if firmware 0.1 in hwfly and sc 0.1 are different, nothing will probably come of this idea
Yes I was discussing doing similar on here last weekend, that is my plan as well (waiting for the parts to arrive from China still about a week out from arriving), I mean we can try flashing official 0.1 on to it, hopefully it will work but I am not convinced from what I have read on here and the Spacecraft dev issue list.

This is why I really want to start with the base HWFly firmware from the chip with the flag modified then go from there as it should be identical then to what is on there, check it works and it then gives us a good base point of reference.
 

mvmiranda

Well-Known Member
Member
Joined
Oct 29, 2013
Messages
1,457
Trophies
1
Location
Brazil, Sao Paulo
Website
www.gamemod.com.br
XP
1,672
Country
Brazil
View attachment 293507

I'm trying to flash the hwfly lite with RPI and it didn't work.
SWD connection using the GD-programmer / the ST-Link didnt work either. Yes I've lifted pin 44

FYI, as soon as we connect the chip to the RPI, the LED starts blinking purple, red, and off.
Correct!
I forgot mentioning this chip behavior but I have the same here as well!
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    LeoTCK @ LeoTCK: yes for nearly a month i was officially a wanted fugitive, until yesterday when it ended