Homebrew ARM9Loader -- Technical Details and Discussion

  • Thread starter Thread starter Selver
  • Start date Start date
  • Views Views 579,893
  • Replies Replies 4,025
  • Likes Likes 42
The fact that i didn't find myself the method to init lcd, neither i have written the code.
So i'd just like to know if the ones who did this would like it to be added to the public a9lh setup, with their credits.
Ah, alright well the creator was mostly bilis/b1|1s, I helped a small bit (with the bottom screen framebuffer, which ended up needing reworking anyways). I'm currently porting (with his help) the init into the stage2 payload along with making some improvements to the installer :)
 
Ah, alright well the creator was mostly bilis/b1|1s, I helped a small bit (with the bottom screen framebuffer, which ended up needing reworking anyways). I'm currently porting (with his help) the init into the stage2 payload along with making some improvements to the installer :)
Chop chop Mr Couldn't Sleep. :P haha
 
Just a lurker popping into say thanks to everyone! I'm still holding off on doing this process but it sounds like the progress we need i
 
so you mean screen init? lcd init? issue will be slove soon? if so, it's amazing work thank you. the homebrew like decrypt9, emunand9 work on without 9.0 firmlaunch?
If I'm wrong please correct me.
 
I was thinking a little bit onto the screen init news. Could we get D9 (or an equivalent tool) loaded at boot time? (Before kernel?)
 
I was thinking a little bit onto the screen init news. Could we get D9 (or an equivalent tool) loaded at boot time? (Before kernel?)
Yes, but loading it that early means (at the moment) it can't decrypt or encrypt.
That means full NAND.bin, but no partition dump/inject or basically anything else, at least until a workaround gets going.
 
  • Like
Reactions: Mrrraou
Yes, but loading it that early means (at the moment) it can't decrypt or encrypt.
That means full NAND.bin, but no partition dump/inject or basically anything else, at least until a workaround gets going.

And even if there's such workaround, messing with sysnand in a9lh runtime sounds scary.
 
Yes, but loading it that early means (at the moment) it can't decrypt or encrypt.
That means full NAND.bin, but no partition dump/inject or basically anything else, at least until a workaround gets going.
if that's because it loads so early that the keys aren't even loaded into the security system yet, shouldn't it be trivial to make an a9lh key dumper? Then a bit more code for d9 to use the dumped keys?
 
And even if there's such workaround, messing with sysnand in a9lh runtime sounds scary.
Just do encrypted CTRNAND backups.

--------------------- MERGED ---------------------------

if that's because it loads so early that the keys aren't even loaded into the security system yet, shouldn't it be trivial to make an a9lh key dumper? Then a bit more code for d9 to use the dumped keys?
A payload could setup the keys.
 
if that's because it loads so early that the keys aren't even loaded into the security system yet, shouldn't it be trivial to make an a9lh key dumper? Then a bit more code for d9 to use the dumped keys?
Theoretically D9 might be able to load a FIRM and get keys, just that it's something it'd have to do that it doesn't right now.
 

Site & Scene News

Popular threads in this forum