|
| ||
| Views: 1,609,096 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-21-24 09:25 AM |
| Guest: | ||
| 0 users reading RSA Questions | 1 bot |
| Main - Reverse-engineering - RSA Questions | Hide post layouts | New reply |
| nocash |
| ||
|
Normal user Level: 20 Posts: 12/77 EXP: 38995 Next: 3444 Since: 10-09-15 Last post: 2097 days ago Last view: 2013 days ago |
Some RSA questions...
1) Does somebody have some source code example for decrypting the RSA signatures in DSi cart headers? I guess any open source RSA implementations could do that, when calling the correct functions with correct parameters. 2) The DSi BIOS has two different subfunctions for RSA decryption functions (either one of them used, depending on bit0 of the first byte of the RSA key). Is that something common in RSA world? And what is it good for? Are that two different RSA variants, or is just some kind of optimization for faster processing of "even/odd" keys? 3) The DSi's encrypted RSA data is always 80h bytes in size. But the size of the decrypted output is variable (from what I've seen, it's always (?) 7Fh bytes; whereas those 7Fh bytes are usually mainly consisting of padding bytes). What is that variable length good for? Are there cases where it could be bigger or smaller than 7Fh? And is it something that can be freely assigned at encryption time, or is it just some "dirt effect" where the compressor is "randomly" assigning different lengths depending on the input? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 37/77 EXP: 38995 Next: 3444 Since: 10-09-15 Last post: 2097 days ago Last view: 2013 days ago |
About the 3rd question: That stuff seems to be defined in RFC 2313:
A block type BT, a padding string PS, and the data D shall be
As far as I understand, the leading 00h is intended to avoid overflows on large interger maths, the BT block type is always 01h on DSi, the following PS padding consists of FFh's on DSi (as defined for BT=01h), padding does then end with the trailing 00h, then followed by the actual data (usually a 14h-byte SHA1 value on DSi).
formatted into an octet string EB, the encryption block. EB = 00 || BT || PS || 00 || D . The DSi BIOS decrypt function doesn't return the leading 00h, but internally RSA seems to work as if the 00h would be there. So, to make an unencrypted 80h-byte signature, one could just follow that notation (ie. adding a leading 00h to the 7Fh-byte signature). Or am I missing something, and that wouldn't be the optimal format for unencrypted signatures? Plans for next no$gba version are supporting unencrypted signatures in that fashion - so that people could create "authentic" DSi homebrew games or system files that are compatible with the original firmware. One would still need Nintendo's private key to get that files working in real hardware, but in an emulator one could just hook the BIOS RSA functions (ie. detecting if the signature contains the unencrypted "00 || BT || PS || 00" values, and if so, just copy the signature as-is instead of trying to decrypt it). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 43/77 EXP: 38995 Next: 3444 Since: 10-09-15 Last post: 2097 days ago Last view: 2013 days ago |
About the 1st question: Somebody pointed me on this https://github.com/mborisov1/rsa_embedded - it's less than 200 lines of code - and it contains everything needed to decrypt RSA signatures!
That's about a million times simplier than trying to understand polarssl source code, or trying to disassemble the DSi bios functions. I've ported it to ASM, and it's actually working for the DSi signatures. When changing two things: The .h files defines MPI_NUMBER_SIZE=128, counted in 16bit units (ie. 256 bytes), for the DSi that must be changed to half of that size. The source/dest/key values must be little-endian, whilst the DSi does have them stored in big-endian. And the parameters for the "mpi_powm65537" function are then "m=source/dest buffer", and "n=key". |
| Main - Reverse-engineering - RSA Questions | Hide post layouts | New reply |
|
Page rendered in 0.020 seconds. (2048KB of memory used) MySQL - queries: 27, rows: 66/66, time: 0.009 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |