Homebrew Is the OTP SHA256 hash console specific?

  • Thread starter Thread starter mashers
  • Start date Start date
  • Views Views 4,183
  • Replies Replies 29

mashers

Stubborn ape
Member
Joined
Jun 10, 2015
Messages
3,837
Reaction score
5,181
Trophies
0
Age
43
Location
Kongo Jungle
XP
5,139
Country
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?
 
^ what he said.
Also, since it's the same software (arm9loader) I don't see why it wouldn't be in the same area on all versions of the console.
 
The otp is console specific so the hash should be too I guess.

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.
It is 256 bit :)
 
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.
 
Last edited by capito27,
  • Like
Reactions: Mrrraou and ketal
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.
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?
 
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 ^^'
 
  • Like
Reactions: Mrrraou
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 ^^'
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 :p
 
you do know that what you are asking are the stats indeed, "...unlikely to the point..", just saying
 
I need to know in practical terms not numerical, hence not the stats.
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
 
Last edited by capito27,
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)
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 :P
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.
 
  • Like
Reactions: Quantumcat
If the size of the hash is smaller than the size of the OTP, then the pigeon hole principle demands the hash is NOT unique.

However, I believe that it would still make an acceptable recovery option for a 3DS.
 

Site & Scene News

Popular threads in this forum