Homebrew ARM9Loader -- Technical Details and Discussion

  • Thread starter Thread starter Selver
  • Start date Start date
  • Views Views 566,846
  • Replies Replies 4,025
  • Likes Likes 42
Oh... well, if it's taken care of by a9lh already, I'm not sure what the point is then. But I had already posted a vid in case someone wanted to argue about the splash. May as well post it, I guess :P


The point of getting screen init into stage 2 was so that ReiNAND could display a splash image, without having the screen init code (or, you know, any payload could use the screen)
 
Mildly confused here. I have A9LH and AuReiNand installed on my N3DS. I'm using the 10.4 FIRM that was linked here https://gbatemp.net/threads/aureinand-n3ds-o3ds-a9lh.411110/. How can I:

  1. Boot into Decrypt9? I have the A9LH version of Decrypt9 that comes with an arm9loaderhax.bin and a D9A9 folder. What do I do with these?
  2. Boot into sysNAND? Someone said I just needed to hold R, and that seemed to work, but then I wasn't able to run D9 after getting to Homebrew again.
 
Is it possible to add xorpad generation and such features to the a9lh Decrypt9 version? or is this out of the question?
 
Mildly confused here. I have A9LH and AuReiNand installed on my N3DS. I'm using the 10.4 FIRM that was linked here https://gbatemp.net/threads/aureinand-n3ds-o3ds-a9lh.411110/. How can I:

  1. Boot into Decrypt9? I have the A9LH version of Decrypt9 that comes with an arm9loaderhax.bin and a D9A9 folder. What do I do with these?
  2. Boot into sysNAND? Someone said I just needed to hold R, and that seemed to work, but then I wasn't able to run D9 after getting to Homebrew again.
Regular Decrypt9 will not work if your sysnand is over 9.2. You could try holding L to boot with the 9.0 firm.

If you want to boot the A9LH version of Decrypt9 you will have to replace AuReiNands arm9loaderhax.bin with the one for Decrypt9 or use ctrbootloader9.

The D9A9 folder goes to the root of your SD card.
 
Last edited by Bu2d85,
Mildly confused here. I have A9LH and AuReiNand installed on my N3DS. I'm using the 10.4 FIRM that was linked here https://gbatemp.net/threads/aureinand-n3ds-o3ds-a9lh.411110/. How can I:

  1. Boot into Decrypt9? I have the A9LH version of Decrypt9 that comes with an arm9loaderhax.bin and a D9A9 folder. What do I do with these?
  2. Boot into sysNAND? Someone said I just needed to hold R, and that seemed to work, but then I wasn't able to run D9 after getting to Homebrew again.
Hold L instead of R
 
...Continued from Summary of differences from prior *hax (1/2)...

Note: This is a GREATLY simplified view...
  1. Bootrom initializes various keys
  2. Bootrom loads FIRM0 into memory
  3. Bootrom validates FIRM0 crypto signatures
  4. Bootrom branches to loaded FIRM0
  5. FIRM0 is actually a loader for Kernel9 (the ARM9 thread)...
  6. Arm9Loader uses OTP hash plus sector 0x96 contents for further decryption of Kernel9
  7. Arm9Loader branches to properly decrypted Kernel9
  8. System loads lots of stuff
  9. Eventually loads menus / themes / etc. (one hax entry point)
  10. Cartridge launch ... lots of stuff
  11. Cartridge runs game (another hax entry point)
  1. Bootrom initializes various keys
  2. Bootrom loads FIRM0 into memory
  3. Bootrom FAILS to validate FIRM0 crypto signatures
  4. Bootrom loads FIRM1 into memory
  5. Bootrom validates FIRM1 crypto signatures
  6. Bootrom branches to loaded FIRM1
  7. FIRM1 is actually a loader for Kernel9 (the ARM9 thread)...
  8. Arm9Loader uses OTP hash plus sector 0x96 contents for further decryption of Kernel9
    !BUT! because sector 0x96 was modified, the decrypted Kernel9 is corrupt.
  9. The first (few) corrupt instruction(s) of Kernel9 branch into memory that was set from FIRM0, and never overwritten when loading FIRM1
Firm0 (attacker generated code) is loaded into memory:
000000000000000000000000000000xxxxxxxxxxxxxxxxx

Signature mismatch, so firm1 is loaded into memory, but is smaller size so only partially overwrites firm0:
111111111111111111111111110000xxxxxxxxxxxxxxxxx
/ sizeof(firm1) \_______^^^^
\ -sizeof(firm0) /


Corrupt Sector 150 (0x96) causes Kernel9 (after decryption by FIRM1's arm9loader) to branch to the leftover loaded FIRM0 data:
111111111111111111111111110000xxxxxxxxxxxxxxxxx
Branches to here...........^
The description at the top of this thread was based on the premise of overwriting all memory with NOP sleds / BRANCH instructions to the payload.

However, the actual Arm9LoaderHax needed to find a way to change Sector 150 such that the corrupt instructions would decode in a way that branch'd into that tiny region where FIRM0 was loaded, and where FIRM1 would not overwrite that data when it was loaded.

This is a much, much smaller target. How many different iterations needed to be tried to find just the right BRANCH instruction? Almost 4 million iterations -- hint: 0x3BF5F6.

But, once the right key was found to get this "just right" branch, it can be used on any 3DS out there, so long as the OTP_HASH could be found for that 3DS.
 
Last edited by Selver,
So I don't know if to make a new thread about this but since everyone seems to be discussing A9LH here and this is a (potential) bug, I figure this would be a great place to see if anyone else is having this issue.

It seems that A9LH breaks injected GBA saves if launched through emuNAND. The game will say it saves with no issues but upon relaunching it, there will show no saves at all. The FIRMs are patched, it's not the CIA or CFW because this same issue does not happen on my gf's non-A9LH console.

After doing some digging I found this Reddit post recently that seems to confirm my findings: https://www.reddit.com/r/3dshacks/comments/48q6d4/custom_made_gba_cias_dont_save_in_emunand/

Just wanted to know if anyone else is experiencing this (that is actually running A9LH with emuNAND, because it works just fine with A9LH sysNAND per the Reddit thread) and if there's an easy fix. I know it's not top priority or anything but was curious.
 
So I don't know if to make a new thread about this but since everyone seems to be discussing A9LH here and this is a (potential) bug, I figure this would be a great place to see if anyone else is having this issue.

It seems that A9LH breaks injected GBA saves if launched through emuNAND. The game will say it saves with no issues but upon relaunching it, there will show no saves at all. The FIRMs are patched, it's not the CIA or CFW because this same issue does not happen on my gf's non-A9LH console.

After doing some digging I found this Reddit post recently that seems to confirm my findings: https://www.reddit.com/r/3dshacks/comments/48q6d4/custom_made_gba_cias_dont_save_in_emunand/

Just wanted to know if anyone else is experiencing this (that is actually running A9LH with emuNAND, because it works just fine with A9LH sysNAND per the Reddit thread) and if there's an easy fix. I know it's not top priority or anything but was curious.

You need to return to sysNAND after you have finished playing a GBA game for it to finish saving the game.
 
...Continued from Summary of differences from prior *hax (2/3)...

In conclusion, the main differences for Arm9LoaderHax include:
  • 100% boot rate (vs. semi-random failures)
  • Ability to run homebrew kernels (full-hardware access software)
  • Ability to run homebrew
    (Unfortunately, guaranteeing homebrew can be run also enables less ethical uses)
  • No known way to prevent the continued use of A9LHax (can't fix with firmware/software updates)

Who would've thought that the ability to jump to console-unique, non-predictably corrupt code would be such a huge entry point? I certainly learned a lot while trying to understand the scope and severity of this issue.
 
Last edited by Selver,
You need to return to sysNAND after you have finished playing a GBA game for it to finish saving the game.
Ah that makes sense. Sorry, I haven't used GBA injections before A9LH. Thinking about it though, the reason why this didn't crop up before was because with non-A9LH you're returning to sysNAND, however briefly, so it has time to write the save.

I just tried again booting the injected CIA through emuNAND, saving, and returning to sysNAND after shutting down and it works! I guess a quick little reboot after returning to sysNAND isn't too bad, especially with how fast we boot now.

Thanks for the answer.
 
Is it possible to add xorpad generation and such features to the a9lh Decrypt9 version? or is this out of the question?

No. XORPad generation needs FIRM init, which happens AFTER A9LH, so it's not possible for now. Maybe we'll find a workaround, but currently that's not possible.
 
I've seen a few posts about 128GB SD cards taking longer to boot A9LH, is this a regular occurrence, or isolated incidences?

I'm currently using a SanDisk Ultra 32GB micro SD on N3DS with A9LH and it boots in 9 seconds. The plan is to upgrade to a 128GB SanDisk micro SD, would it impact performance significantly?
 

Site & Scene News

Popular threads in this forum