Fascinating write-up! I originally hacked my o3ds with OoT & rxTools a few years back, had no idea what I was doing then. Re-installed cfw a few months back with 3ds.guide & it was much simpler -- but still had no idea what I was doing lol.
As far as a "general" understanding goes, I think this post explains it pretty well. But I do have one question regarding sighax:
As it was described in the post, I don't exactly understand how the "brute force" comes into play as described here --
Sorry if my noob understanding is flawed, but this is how it's parsed in my mind:
Forgive my lack of understanding... I'd really like to understand the mechanics as it's fascinating
As far as a "general" understanding goes, I think this post explains it pretty well. But I do have one question regarding sighax:
As it was described in the post, I don't exactly understand how the "brute force" comes into play as described here --
Think about this: You can move the pointer wherever you want thanks to the 0d value, and you also brute force a signature (given enough computational power) which when decrypted with the public key will give you your desired layout of all the bytes. What can we do with these two facts?
Sorry if my noob understanding is flawed, but this is how it's parsed in my mind:
- Set the inner block size
- Hackers set this to the beginning of the actual calculated hash (instead of the correct hash)
- The parser then jumps to the area immediately outside the signature
- It treats these bytes as input for generating a new calculated hash
- That region outside the signature is overwritten with this new calculated hash
- Then it jumps back? (is it GOTO assembly style?) to the actual calculated hash designated at the start
- It compares the designated region with the region outside the actual signature
- This will pass, because this region
...will contain the hash of the current state of the NAND header
Forgive my lack of understanding... I'd really like to understand the mechanics as it's fascinating