I have found where the unique_id of the current rp2040 is stored in the original firmware:
0x20025978
$1 = 0x20025978 "\346aA\004\003y\247\071W\003"
(gdb) x/8x $r0
0x20025978: 0xe6 0x61 0x41 0x04 0x03 0x79 0xa7 0x39
and this is the output of micropython:
MPY: soft reboot
e6 61 41 4 3 79 a7 39
MicroPython v1.19.1-841-g3446d440f on
Cross Referenced unique_id example code in ghidra with firmware,found where it is,little this and little that and here we are
(rp2040 was live debuged)
0x20025978
$1 = 0x20025978 "\346aA\004\003y\247\071W\003"
(gdb) x/8x $r0
0x20025978: 0xe6 0x61 0x41 0x04 0x03 0x79 0xa7 0x39
and this is the output of micropython:
MPY: soft reboot
e6 61 41 4 3 79 a7 39
MicroPython v1.19.1-841-g3446d440f on
Cross Referenced unique_id example code in ghidra with firmware,found where it is,little this and little that and here we are
(rp2040 was live debuged)
pin 3 and 4 bud, 1 2 5 6 are connected to ground, so dont bridge any of those to 3 and 4
I've seen this function
Post automatically merged:
if we try to put the keys manually like it says here https://github.com/CTCaer/hekate/issues/559
Post automatically merged:
Post automatically merged:
@Tafty
Last edited by vittorio,
So bridge 3/4 thanks, I'll dig out my lite when I get home and have a play.
Did you just use the fw from this thread?
The sdloader used in this firmware is wrong/bad that’s why it says for Ubuntu. It clears out the keys, that’s why BEK is missing. Someone that understands the firmware better needs to swap out the sdloader code with hwfly or spacecraft sdloader. You cannot patch it with hwfly toolbox because it’s not in the same location
> hekate_keys.ini is not something that hekate actually supports. I don't know what you are talking about.
Also refrain from illegally posting even a single part of the keys.
hekate_keys.ini was used in some shitty closed source cfw packs, because original tx firmware wipes BEK. You should not post thoese keys tho
Does that mean any console that used the original TX firmware without manually backup up first could never be restored to stock?> hekate_keys.ini is not something that hekate actually supports. I don't know what you are talking about.
Also refrain from illegally posting even a single part of the keys.
hekate_keys.ini was used in some shitty closed source cfw packs, because original tx firmware wipes BEK. You should not post thoese keys tho
The keys are stored in bootrom, and normally they will be loaded to keyslot at boot. But TX firmware just wipe keyslot at boot to prevent other CFW to boot(It was their DRM lol), so it is not permanent.
Maybe it will be useful for someone. I trimmed the dump.
Deleted UF2 header. UF2 > BIN.
Added old firmware witch cut UF2 file.
Deleted UF2 header. UF2 > BIN.
Added old firmware witch cut UF2 file.
Don't know how the compiler packs Pico code into .uf2 files, but I couldn't find the HWFLY-NX public key signature (0x69 repeating) in the latest unlocked dump. If the uf2 is uncompressed then this firmware really is using different BCTs, but I guess we can already safely bet on that.
In the meantime, I'm currently writing PIO code to sniff eMMC traffic using an external CLK signal. CMD line is almost done, though I don't know yet how to know when I need to sniff 136 bit packages and when I need to sniff 48bit packages. This protocol is pretty annoying tbh.
I don't think I'll be able to even write a prototype for the glitching part, because I don't have a CPU flex cable to test this whole thing out. I have some MOSFETs (slightly different ones from the one linked here) but they're so damn small that I don't trust myself to solder it on the tiny capacitors on the switch lmao.
In the meantime, I'm currently writing PIO code to sniff eMMC traffic using an external CLK signal. CMD line is almost done, though I don't know yet how to know when I need to sniff 136 bit packages and when I need to sniff 48bit packages. This protocol is pretty annoying tbh.
I don't think I'll be able to even write a prototype for the glitching part, because I don't have a CPU flex cable to test this whole thing out. I have some MOSFETs (slightly different ones from the one linked here) but they're so damn small that I don't trust myself to solder it on the tiny capacitors on the switch lmao.
Probably better to solder some 40AWG enamel magnet wire to the caps and the fets if you don't have super good eyes, steady hands, and/or a microscope.
This is the MCU‘s side. I‘m writing the actual serial connection which originally the FPGA did on the HWFLY. Thank you though.
Similar threads
-
Xdqwerty
what are you looking at?
-
-
-
-
-
-
-
-
-
-
@
CameronCataclysm:
Why no blog posts about Nitendont going after Garry's Mod repos that have been up for a decade or 2? -
-
-
@
Xdqwerty:
Is it safe to update a modded ps3?
Can I play online in pirated games? (with ps3hen either enabled or not) -
-
-
-
-
-
@
Xdqwerty:
@salazarcosplay, I used apollo save tool to activate my ps3 offline so i could play a game that wasnt working
-
S @ salazarcosplay:from what I understood. you load up the piratged game. you the clear the syscalls, then you play
-
-
-
-
-
