Homebrew A9LH Development: When does OTP become available in RAM?

mashers

Stubborn ape
OP
Member
Joined
Jun 10, 2015
Messages
3,837
Trophies
0
Age
39
Location
Kongo Jungle
XP
4,952
Country
My A9LH payload 3DSafe has a built-in version of SafeA9LHInstaller. The problem I'm having is that this version only works when otp.bin is present on the SD card, even though I'm running from within A9LH. The official build of SafeA9LHInstaller can read the OTP from memory. The key part seems to be here:

https://github.com/AuroraWright/SafeA9LHInstaller/blob/master/source/installer.c#L74

If I put some alerts throughout this function in my payload, I find that the OTP_FROM_MEM region is indeed equal to the array of zeros and, thus, empty. This occurs even if I check this very early on in the execution of the payload.

I'm wondering whether it is to be expected in a stage2 payload for the OTP to be present in this region of memory yet, or whether it's only available after jumping to the payload on SD card for some reason.

Thanks in advance!
 

zoogie

playing around in the dsiware
Developer
Joined
Nov 30, 2014
Messages
8,431
Trophies
2
XP
13,893
Country
Micronesia, Federated States of
My A9LH payload 3DSafe has a built-in version of SafeA9LHInstaller. The problem I'm having is that this version only works when otp.bin is present on the SD card, even though I'm running from within A9LH. The official build of SafeA9LHInstaller can read the OTP from memory. The key part seems to be here:

https://github.com/AuroraWright/SafeA9LHInstaller/blob/master/source/installer.c#L74

If I put some alerts throughout this function in my payload, I find that the OTP_FROM_MEM region is indeed equal to the array of zeros and, thus, empty. This occurs even if I check this very early on in the execution of the payload.

I'm wondering whether it is to be expected in a stage2 payload for the OTP to be present in this region of memory yet, or whether it's only available after jumping to the payload on SD card for some reason.

Thanks in advance!
The otp sha256 hash, which is all you need, should be leftover in a certain register if you're booting from a9lh:
https://github.com/AuroraWright/Saf...46bf290469a3476dea46c465/source/crypto.c#L372
 

mashers

Stubborn ape
OP
Member
Joined
Jun 10, 2015
Messages
3,837
Trophies
0
Age
39
Location
Kongo Jungle
XP
4,952
Country
The otp sha256 hash, which is all you need, should be leftover in a certain register if you're booting from a9lh:
https://github.com/AuroraWright/Saf...46bf290469a3476dea46c465/source/crypto.c#L372
I don't understand though. The check for OTP in memory seems to be on line 74 of installer.c as I linked above, as it checks the contents of the memory location at which the OTP is supposed to reside. This check occurs before the call to setupKeyslot0x11(), so I don't see how installer.c#L74 could ever work in that order.
 

mashers

Stubborn ape
OP
Member
Joined
Jun 10, 2015
Messages
3,837
Trophies
0
Age
39
Location
Kongo Jungle
XP
4,952
Country
For now I've implemented a workaround for this. If a valid OTP is found on the SD card, it gets copied to CTRNAND. This OTP is used in my implementation of SA9LHI, so it can at least work without the OTP on the SD card (after the initial copy that is).

I would prefer for it to be read from memory if possible, but for now this seems to work.
 

Ryccardo

watching Thames TV from London
Member
Joined
Feb 13, 2015
Messages
7,406
Trophies
0
Age
27
Location
Imola
XP
6,386
Country
Italy
As far as I know, OTP can still only be directly read on 1.x and 2.x kernels (and A9LH can be considered a romhack of the N3DS kernels); the code you highlighted is what makes direct installation possible without manually dumping it first!
 

mashers

Stubborn ape
OP
Member
Joined
Jun 10, 2015
Messages
3,837
Trophies
0
Age
39
Location
Kongo Jungle
XP
4,952
Country
As far as I know, OTP can still only be directly read on 1.x and 2.x kernels (and A9LH can be considered a romhack of the N3DS kernels); the code you highlighted is what makes direct installation possible without manually dumping it first!
I think it can be directly read in any firmware version as long as you do it from within A9LH.
 

ihaveahax

Well-Known Member
Member
Joined
Apr 20, 2015
Messages
5,996
Trophies
2
XP
7,067
Country
United States
I think it can be directly read in any firmware version as long as you do it from within A9LH.
kernel9loader locks the otp before it jumps to the firmware (and eventually the payload), but it doesn't clear the sha256 hash in the sha registers. only way to get the otp directly is by going to a pre-3.0 firmware.
 

mashers

Stubborn ape
OP
Member
Joined
Jun 10, 2015
Messages
3,837
Trophies
0
Age
39
Location
Kongo Jungle
XP
4,952
Country
kernel9loader locks the otp before it jumps to the firmware (and eventually the payload), but it doesn't clear the sha256 hash in the sha registers. only way to get the otp directly is by going to a pre-3.0 firmware.
Ahh, so tying that in with what @zoogie wrote:
The otp sha256 hash, which is all you need, should be leftover in a certain register if you're booting from a9lh:
https://github.com/AuroraWright/Saf...46bf290469a3476dea46c465/source/crypto.c#L372



... if I rewrite my embedded SafeA9LHInstaller so it checks only for the leftover sha256 hash instead of requiring the actual OTP file (or indeed the OTP in memory) then should that enable SA9LHI to work?
 
  • Like
Reactions: zoogie

ihaveahax

Well-Known Member
Member
Joined
Apr 20, 2015
Messages
5,996
Trophies
2
XP
7,067
Country
United States
Ahh, so tying that in with what @zoogie wrote:




... if I rewrite my embedded SafeA9LHInstaller so it checks only for the leftover sha256 hash instead of requiring the actual OTP file (or indeed the OTP in memory) then should that enable SA9LHI to work?
as far as I know, SafeA9LHInstaller normally uses the leftover hash when you run it from a9lh. so it should be fine.
 

mashers

Stubborn ape
OP
Member
Joined
Jun 10, 2015
Messages
3,837
Trophies
0
Age
39
Location
Kongo Jungle
XP
4,952
Country
Aha! This works:

https://github.com/mashers/3DSafe/b...399c117537cfd/payload_stage2/source/otp.c#L79

Basically I removed the part which compares the OTP in memory to zeroes if attempting to load the OTP [hash] from memory, since we already know this will fail. It also passes whether or not to use the hash from memory to setupKeyslot0x11() in order to use the correct hash location (from file data or from leftover in RAM). Then in my function which runs SA9LHI I did this:

https://github.com/mashers/3DSafe/b...99c117537cfd/payload_stage2/source/otp.c#L138

which either loads the hash from memory or checks for a valid OTP file on disk depending on the situation. Both seem to work. The only concern I have is that if loading the hash from memory, the following is triggered:

https://github.com/mashers/3DSafe/b...99c117537cfd/payload_stage2/source/otp.c#L130

That's why I put a check above it to return true if the location of the check is the hash in memory. I don't know why it fails this check as I am able to successfully install A9LH payloads if I skip it. I'm just slightly worried that this could cause it to mis something important...
 
General chit-chat
Help Users
  • No one is chatting at the moment.
    KenniesNewName @ KenniesNewName: From his auntie's wife side