Soo my current state of information about the HWFLY is the following:
Other than that, I tried to understand the payload and custom BCTs and honestly, I've hit a road block. I see that the custom BCTs use a new public key (0x69 repeating) and that it also set a new "StartBlock" address for bootloader0
In @Mansi 's BOOT0 dump I can see that the StartBlock was set to 0x000000FC (original is as in the documentation 0x00000040), while the payload is written to 0x1F80 so at this point I don't know what happens next lmao
EDIT:
Well, I've found it out. I forgot to remember that the Tegra talks to the eMMC with a blocksize of 16KiB (=16384 bytes) instead of 512byte like the FPGA does. (https://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html)
0x1F80 * 512 byte = 0x3F0000
0xFC * 16384 byte = 0x3F0000
So yeah, Package1 doesn't get loaded, the payload gets loaded instead and after that basically comes Hekate / Whatever you put into the SD.
Does anyone have a clue what the voltage glitch actually mitigates? On Erista models the BCT is not even encrypted, it's just signed with the given public key (0x69 repeating in HWFLY's case), so what's stopping the payload if we don't do a voltage glitch?
- Microcontroller does most if not all of the "smart" stuff, e.g. writing the payload and custom BCTs to the NAND, determining which glitch configuration (offset + pulse width + some sort of delay) to use
- In the training process, it sends out multiple glitch configs (to the FPGA) and receives the eMMC traffic (from the FPGA) after the glitch has been performed, determining whether it was successful or not and if not send a different config and try again
- The FPGA, on the other hand, handles the actual traffic to the eMMC, synchronizing with the CLK and stuff like that..
It sends messages that were given by the microcontroller and listens to traffic between the main CPU and the eMMC, buffering it so the microcontroller can read the last messages - The FPGA obviously also runs the actual glitch based on the given configuration, as far as I understand it really only glitches using this config and doesn't have any kind of algorithm to "find" the best config because the microcontroller does that.
Other than that, I tried to understand the payload and custom BCTs and honestly, I've hit a road block. I see that the custom BCTs use a new public key (0x69 repeating) and that it also set a new "StartBlock" address for bootloader0
In @Mansi 's BOOT0 dump I can see that the StartBlock was set to 0x000000FC (original is as in the documentation 0x00000040), while the payload is written to 0x1F80 so at this point I don't know what happens next lmao
EDIT:
Well, I've found it out. I forgot to remember that the Tegra talks to the eMMC with a blocksize of 16KiB (=16384 bytes) instead of 512byte like the FPGA does. (https://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html)
0x1F80 * 512 byte = 0x3F0000
0xFC * 16384 byte = 0x3F0000
So yeah, Package1 doesn't get loaded, the payload gets loaded instead and after that basically comes Hekate / Whatever you put into the SD.
Does anyone have a clue what the voltage glitch actually mitigates? On Erista models the BCT is not even encrypted, it's just signed with the given public key (0x69 repeating in HWFLY's case), so what's stopping the payload if we don't do a voltage glitch?
Last edited by Piorjade,