Let's call it now the switchroot modchip.
Thank you @rehius to bring us this.
Can't wait to finish my switch lite whit this.
Thank you @rehius to bring us this.
Can't wait to finish my switch lite whit this.
This might be a dumb question, but to me, logically, why don't we just use the uf2 we currently have and just overwrite it with the working one, then resale the uf2 after the fact?
I assume there I'd a technical reason why yhag won't actually work
I assume there I'd a technical reason why yhag won't actually work
CYAN = no glitch reaction
MOSFET must be connected very close, very thick wire, or direct solder
on video - very very long very very thin wire. cannot do 20 Amperes
Okay, after taking some time off I decided to look at this again and realized that they're most definitely fingerprinting (or rather, changing behaviour) based on the flash ID. They call flash_get_unique_id as part of an init callback (I thought this was some random flash func) and then continuously copy the unique ID: (lol I initially missed that mov R2, R4)
Based on this data it writes to memory in a specific pattern which is much more complicated to patch out than a simple check; the easiest way to go about this would be if someone dumped a firmware and a unique ID and then emulated it instruction-by-instruction. At the very least it would be helpful to see what they're doing with the 0x110B0 bytes copied from 0x1000297C to the SRAM base (0x20000000). The only problem I see from this would maybe be navigating the function that looks for the sequence on the CMD pin.
I also realized that they probably exit the XIP flash because it runs off of clk_sys which they're changing, because otherwise the dumped firmware.bin would look strange and I don't think the flash would be able to keep up anyways.
For reference, the initially dumped firmware grabs the unique ID in the init routine at 0x10002608, which gets copied into a 256-byte structure at 0x20025868 in the routine at 0x1000070C. Interestingly, the other .uf2s posted here do something slightly different when copying the unique ID, for some reason.
Other than this, I'm basically stuck until someone does what I suggested or if it turns out that binary blob has easy-to-disassemble ARM code.
Based on this data it writes to memory in a specific pattern which is much more complicated to patch out than a simple check; the easiest way to go about this would be if someone dumped a firmware and a unique ID and then emulated it instruction-by-instruction. At the very least it would be helpful to see what they're doing with the 0x110B0 bytes copied from 0x1000297C to the SRAM base (0x20000000). The only problem I see from this would maybe be navigating the function that looks for the sequence on the CMD pin.
I also realized that they probably exit the XIP flash because it runs off of clk_sys which they're changing, because otherwise the dumped firmware.bin would look strange and I don't think the flash would be able to keep up anyways.
For reference, the initially dumped firmware grabs the unique ID in the init routine at 0x10002608, which gets copied into a 256-byte structure at 0x20025868 in the routine at 0x1000070C. Interestingly, the other .uf2s posted here do something slightly different when copying the unique ID, for some reason.
Other than this, I'm basically stuck until someone does what I suggested or if it turns out that binary blob has easy-to-disassemble ARM code.
If you look at the amount of power you are going to use, you can calculate the wire thickness. For this application you don't need anything more than 25 AWG (0.45mm) - that's more than thick enough, so the 0.7mm wire you are using is fine.
For anyone wanting to reverse engineering this, the focus needs to be on getting both a dump and the unique id of the same working chip. Adding a check to verify the unique id is kindergarten stuff, they wouldn't do that. At minimum they would encrypt the rest of the information using the unique id as a key or part of the key.
hello guys, there is a problem, after breaking the capacitor at 3.3 v, I got a blue screen error, I hope it's from the capacitor, because at the same time, it short-circuited the 2 cables I connected the mosfet, so I hope tegra x1 is not broken.
Similar threads
-
-
-
-
-
-
-
@
xtremegamer:
loving the new zelda, i started a game, it was so fucking good, so i
am waiting on my friend to get home so we can start a new one together -
@
Skelletonike:
I just dislike that they don't let me choose the voices before the game starts. Happened with botw as well, had to change to japanese and restart. -
-
-
-
-
-
-
-
@
Skelletonike:
Just scanned all my zelda amiibos, took a while but didn't get anything that cool, did get the lon lon ranch hylian fabrics though.
-
-
@
K3N1:
@Skelletonike, btw I ran that custom for mgs4 on the deck I'm amazed it got that far in game -
-
-
-
-
-
-
