Share This Page

Now that OTP-less A9LH installation is possible, I want to add an alternate override to 3DSafe in case the user never dumped their OTP. I can write the leftover SHA to a file by simply writing 32 bytes from 0x1000A040. I can then load this file back into memory and use memcmp to check if the contents of the file matches the SHA in memory.

The question I have is whether the SHA in memory is console specific, or whether it's possible for two consoles to have the same SHA? Also, is the SHA in the same location no matter what device the user is running on?

If the SHA1 is calculated on 256 bits or less of unique data then I believe the SHA1 is unique. However if it's calculated on more than 256 bits of unique data then there will be more than one set of unique data that hashes to the same value. Finding them is very hard, but they could be out there.

If the SHA1 is calculated on 256 bits or less of unique data then I believe the SHA1 is unique. However if it's calculated on more than 256 bits of unique data then there will be more than one set of unique data that hashes to the same value. Finding them is very hard, but they could be out there.

well, to be pedantic, a hashing function allows (along other things ) a large input to be converted into a smaller output in a supposedly unrecoverable fashion.
since the OTP is 144 bytes long and a sha256 is only 32 bytes long, if every possible OTP was to be tested, you would possibly get hash collisions, so no, one can not say that the sha256 hash generated by a lambda OTP is unique.

well, to be pedantic, a hashing function allows (along other things ) a large input to be converted into a smaller output in a supposedly unrecoverable fashion.
since the OTP is 144 bytes long and a sha256 is only 32 bytes long, if every possible OTP was to be tested, you would possibly get hash collisions, so no, one can not say that the sha256 hash generated by a lambda OTP is unique.

Click to expand...

Is it unlikely enough that they would match for it to be a decent security measure to use the hash to bypass the PIN lock?

how could anyone know ? hashing functions are never exact science, only statistics can somewhat predict the likelihood of that occurring, and i'm not gonna compute that ^^'

Click to expand...

Well, I don't need the stats... just 'really unlikely to the point that somebody who stole a 3DS could drop their own SHA onto the SD card and it would almost definitely not match' or 'it's somewhat possible that somebody could steal a 3DS, put their own SHA on the SD card and get a match to bypass the PIN lock' would do

that doesn't change the fact that i have to compute the stats to tell you in practical terms, as i said, hashing functions are never exact science, you can't really predict that without statistical analysis + empirical data, and as said, i won't do that, since it's borring as hell and annoying to setup for someone else's project

afaik, you can dump the OTP from a9lh, so why not making an OTP copy to SD before setting the pin? Then ask the users to copy it to a safe place and remove it from SD because (insert explaination here)

afaik, you can dump the OTP from a9lh, so why not making an OTP copy to SD before setting the pin? Then ask the users to copy it to a safe place and remove it from SD because (insert explaination here)

Click to expand...

no, that's not how it works, otp is locked by the time a9lh is running

Well, I don't need the stats... just 'really unlikely to the point that somebody who stole a 3DS could drop their own SHA onto the SD card and it would almost definitely not match' or 'it's somewhat possible that somebody could steal a 3DS, put their own SHA on the SD card and get a match to bypass the PIN lock' would do

Click to expand...

Considering a flawless hashing function, given an output size of n and k messages to hash, the probability of a collision is (approximately) k^2/2^(n+1).
The otp is hashed with sha-256. Take a random number of messages, say one billion: collision probability is about 4.3*10^-60.