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

[mashers]

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]

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]

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]

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]

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]

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]

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]

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?

 

[ihaveahax]

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]

as far as I know, SafeA9LHInstaller normally uses the leftover hash when you run it from a9lh. so it should be fine.

Thanks, I'll give it a try!

 

[mashers]

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...

 

[Salamencizer]

Great work with 3DSafe! I'm gonna install it