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
- No one is chatting at the moment.
-
@
Psionic Roshambo:
I wonder if they could get CPUs to run that hot then use the heat to power a steam turbine to power the CPUs.... -
-
@
Psionic Roshambo:
It's not the movies or games downloads that I would worry about, like breaking into networks, downloading encrypted things, spying on network traffic. I have seen so many "Top Secret" seals on files when I was a kid
-
@
Psionic Roshambo:
I was obsessed with finding UFOs, a surprising amount of US files where stashed on computers in other countries, China back in the early 90s omg sooo much
-
@
BigOnYa:
Yea that crazy, I've never tried hack into anything, I just pirate, and my ISP have send me 3-4 letters, so had to VPN it -
@
Psionic Roshambo:
Ship to ship communication software for the Navy although without access to the encrypting chips it was mostly useless
-
@
Psionic Roshambo:
I bet now a 4090 could probably crack it? Hmmm maybe not even back then I'm pretty sure they where using like 1024 bit encryption
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
I remember one time I downloaded like a 500MB ISO file on 56K and that literally took like 2 days
-
-
-
-
-
-
-
-
