Hacking A question about the A9LH payload stages

[mashers]

maybe there is a way to have it display contact info on a incorrect password attempt, so at least anyone who finds it could return it, or if whoever get hold of it tries to sell it then it has contact info

Great idea, and easily done. ShadowNAND added some nice text drawing functions so this could all be added as options along with the PIN itself.

The tricky part is actually going to be reading and writing the files on NAND. I know godmode9 can do it but I'd really rather not have to gut it just to read/write one file...

 

[Halvorsen]

I'm hyped for this!

 

[Selver]

Unfortunately I don't think A9LH has access to the 3DS self-destruct mechanism

It most definitely can cause an MCU brick... it has access to the necessary ports. If you doubt this, try fuzzing the I2C bus.

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

... modifying an A9LH CFW which lives in NAND ... have two payload stages. The basic function of the first seems to be to jump to the second, so I'm unclear on the purpose of having both. ... Any ideas would be gratefully received!

I wonder why. Do they store the entire cfw in FIRM1? Why not just use arbitrarily sized files stored in nand? With well over enough space I wonder why no fully featured nand dwelling cfw exist.

Allow me to recommend, for your background reading pleasure, the following introduction into the hows and whys of Arm9Loader, and the A9LH that it enabled:
Arm9Loader -- Technical Discussion

That should, if not answering all your questions, give you the foundation to piece together why each portion does what it does, when placed into each of FIRM0 and FIRM1.

 

[astronautlevel]

If you doubt this, try fuzzing the I2C bus.

Isn't that how yls8 bricked his 3ds?

 

[Deleted User]

I'm looking in to modifying an A9LH CFW which lives in NAND (e.g. shadowNAND) to add a security feature before booting arm9loaderhax.bin from SD card. My intention here is to create an un-circumventable PIN lock.

I'm looking at the source code for shadowNAND (and indeed the @delebile's arm9loaderhax implementation) and they both have two payload stages. The basic function of the first seems to be to jump to the second, so I'm unclear on the purpose of having both. Furthermore, I'm unsure which of the payloads I should modify to add the features I want.

Any ideas would be gratefully received!

The only purpose of having a second payload is the fact that there is too little space in memory for the first one.
I tried many ways to do everything in one single payload, but it's not actually possible.

 

[mashers]

The only purpose of having a second payload is the fact that there is too little space in memory for the first one.
I tried many ways to do everything in one single payload, but it's not actually possible.

Thank you! So, should I be careful not to add too much to stage2?

 

[astronautlevel]

Thank you! So, should I be careful not to add too much to stage2?

The max size limit for stage2 varies, but I think it can be ~80 kilobytes iirc.

EDIT: ShadowNAND installer lets you use up to 50 kilobyte stage2s, safea9lhinstaller lets you use up to 500 KBs

 

[mashers]

The max size limit for stage2 varies, but I think it can be ~80 kilobytes iirc.

EDIT: ShadowNAND installer lets you use up to 50 kilobyte stage2s, safea9lhinstaller lets you use up to 500 KBs

Thanks! I'm only at 12k, so I think I'm good

 

[Deleted User]

Thank you! So, should I be careful not to add too much to stage2?

On stage 2 you have a good bunch of space, do whatever you prefer there.

 

[Selver]

Isn't that how yls8 bricked his 3ds?

Well, I heard that once, but the only place I find it when I search is your earlier post:

... sending a bad state that causes an irrecoverable MCU brick. ... a fuzzer against the i2c (aka what yls8 did when he got the MCU brick) ...

So, it's possible? But I have no personal knowledge of what yls8 may have done...

 

[astronautlevel]

Well, I heard that once, but the only place I find it when I search is your earlier post:



So, it's possible? But I have no personal knowledge of what yls8 may have done...

Ah, thinking back I think it was Dazzozo who mentioned that (about yls8). It was a while ago, and I sort of forgot, sorry

 

[SimplyFedorable]

just as a word of advice, have some way to unlock your device if you forget the pin. Maybe a absurdly long combination or something. I would hate to install this and come back and try to boot and realize I don't know the pin

 

[mashers]

@delebile @astronautlevel
Hope you don't mind me tagging you. I have a quick question. I've incorporated some bits of GodMode9 into my stage2 payload. The filesize of payload_stage2.bin has gone up to 101k. If I comment out the line which calls the init methods in GodMode9, the filesize goes down to 17k.

Now, the problem I have is that 101k file black screens when I boot it on the 3DS and I have to restore a NAND backup via hardmod. I don't think the problem is with the call to the GodMode9 method itself, since I have delayed its execution until after a keypress as follows:

/*
    DEBUG: Allow skipping past everything for brick protection during development
*/
drawString("Press X to skip 3DSafe, any other button to enter 3DSafe", 10, 10, COLOR_RED);
u32 key = waitInput();
if (key == BUTTON_X) {
    bootPayload(0);
    return;
}
clearScreens();
   
   
   
InitNandCrypto();

With the InitNandCrypto() line uncommented (to get it to include the GodMode9 code), the 3DS black screens even before the "Press X..." message is displayed.

So, my question is: is the payload to big at 101k? I am installing it using the latest SafeA9LHInstaller.

 

[mashers]

Further to the above post, I've managed to include the GodMode9 stuff while keeping the file size to 25k. It turned out that the use of snprintf (for building slot key paths) required the inclusion of stdio.h, which added 75k to the file size. I hard-coded the paths so I could remove snprintf and thus stdio, and it actually boots now with the 25k stage2 payload. The InitNandCrypto() function from GodMode9 which I included returns true so I assume it's working...

 

[Swiftloke]

Well, I heard that once, but the only place I find it when I search is your earlier post:



So, it's possible? But I have no personal knowledge of what yls8 may have done...

Writing a bad LED state to the MCU gives an unrecoverable brick, even with a NAND hardmod. I don't know the details, but it sounds like it bricks the MCU. There's been a discussion on whether it's recoverable with A9LH, and the answers are varied.

 

[astronautlevel]

Writing a bad LED state to the MCU gives an unrecoverable brick, even with a NAND hardmod. I don't know the details, but it sounds like it bricks the MCU. There's been a discussion on whether it's recoverable with A9LH, and the answers are varied.

I revisited this last night, the tl;dr is:

Simply writing a bad notification LED to the MCU doesn't seem to be enough to brick it, but if you actively fuzz against the i2c for the notification LED it can cause a full MCU brick. This isn't recoverable, even with a9lh (or for that matter a MCU hardmod) because the MCU is bricked to a point where it can't be flashed.

 

[Selver]

I revisited this last night, the tl;dr is:
Simply writing a bad notification LED to the MCU doesn't seem to be enough to brick it, but if you actively fuzz against the i2c for the notification LED it can cause a full MCU brick. This isn't recoverable, even with a9lh (or for that matter a MCU hardmod) because the MCU is bricked to a point where it can't be flashed.

Thanks for confirming, this is what I also understood as being already known.

What I wonder is weather the i2c bus is used at the factory to burn the e-fuses. (also means the relevant commands would never be seen in the wild)

I don't suppose anyone logged the i2c bus or tracked down what signals actually caused the MCU brick? (don't post them! too easy to be mis-used!)

Yes, I should probably load an IRC client at some point.... My questions are going down the rabbit hole where only reverse engineers go :-S

 

[astronautlevel]

I don't suppose anyone logged the i2c bus or tracked down what signals actually caused the MCU brick? (don't post them! too easy to be mis-used!)

As far as I know, no one has done this yet. The only person who might have is Dazzozo, but he said that he didn't mess with that in his experiments with the MCU.

Yeah, you should definitely get on #Cakey or #3dsdev sometime. Lots of interesting stuff, you can learn a ton just be being around there.