Hacking Old 3ds XL Blackscreen, Luma and Godmode9 open

[AngelBelmont]

Hello there,

Been having a problem with my 3ds for quite some time, it doesnt boot to the Home Screen like normal. At first i thought it was totally bricked, however, i can access both the Luma Rosalina Menu from the static black screen, the godmode9 menu on boot by pressing start and the Luma config menu by pressing select on boot, no issues there.

I've did a ctrtransfer, updated the Luma to the latest version, took out the SD card and tried to boot from the console after installing Luma to it, nothing has worked.

Is there any way that the Internat System Files got corrupted or something? And is there a way to replace those? Or any other solution? Thanks

 

[AngelBelmont]

this error is fine, simply press B and the script will go on

How about this one?

 

[XLuma]

How about this one?

View attachment 339215

keep going, this is because it checks for the old luma config, which is not a .ini instead of a .bin

 

[AngelBelmont]

keep going, this is because it checks for the old luma config, which is not a .ini instead of a .bin

No luck, i did whole process, and the only difference is that now i can't access the rosalina menu from the black screen after powering on

 

[Sypherone]

If you dont have a Nand backup (its not possible to use from another 3DS), already cleared the extradata, reinstalled/updated boot9strap, did a CTRTransfer. The CTRTransfer (Decrypt9 Type) was the last chance. So iam out of my knowlage.

 

[XLuma]

Yeah, the system may as well be a paperweight. My system is also fucked for no real reason, and I'm out of option. No idea what broke it in the first place, just like here. Sorry man

 

[Kwyjor]

open the sha file in a hex editor like hxd, and *add* an extra 00 byte at the end of the file. this method expects the signature to be exactly 33 bytes instead of 32, so adding an extra byte that is zeroed out works and wont mess with the signature at all

That's not what I said! This is a U region CTRNAND, so the byte has to be 01! That's the way the script is written! (Yes, it makes no sense to store that data in the signature file and the script shouldn't have been written that way, but here we are.)

I don't know if that's what's causing the error, but I'd say it's a distinct possibility!

 

[XLuma]

That's not what I said! This is a U region CTRNAND, so the byte has to be 01! That's the way the script is written! (Yes, it makes no sense to store that data in the signature file and the script shouldn't have been written that way, but here we are.)

I don't know if that's what's causing the error, but I'd say it's a distinct possibility!

not really, its just a signature (which is 32 bytes long). anything after that is just filler, and wont matter in the actual verification of the nand image

 

[Kwyjor]

not really, its just a signature (which is 32 bytes long).

I agree that normally it should be just a signature, but why else do you think the script would look for something that's exactly 33 bytes long?

I already posted parts of the script myself, and while I admit I could be wrong, it very much appears that it is identifying the region using that last byte. If you have an alternative interpretation for the script, I'd like to hear it.

(The definitive proof would be in the hash files for the 11.5 CTRNAND for which the guide was initially written.)

 

[AngelBelmont]

That's not what I said! This is a U region CTRNAND, so the byte has to be 01! That's the way the script is written! (Yes, it makes no sense to store that data in the signature file and the script shouldn't have been written that way, but here we are.)

I don't know if that's what's causing the error, but I'd say it's a distinct possibility!

Well, i'll try again writing 01 in the code then

 

[XLuma]

I agree that normally it should be just a signature, but why else do you think the script would look for something that's exactly 33 bytes long?

I already posted parts of the script myself, and while I admit I could be wrong, it very much appears that it is identifying the region using that last byte. If you have an alternative interpretation for the script, I'd like to hear it.

(The definitive proof would be in the hash files for the 11.5 CTRNAND for which the guide was initially written.)

byte was removed after some revisions of the signature creation functions in those programs/scripts, so this script using it is actually an edge case. You may be right it could be used in region detection, but it still does not matter here, because the region here is still valid with his system and verification passed

 

[AngelBelmont]

I agree that normally it should be just a signature, but why else do you think the script would look for something that's exactly 33 bytes long?

I already posted parts of the script myself, and while I admit I could be wrong, it very much appears that it is identifying the region using that last byte. If you have an alternative interpretation for the script, I'd like to hear it.

(The definitive proof would be in the hash files for the 11.5 CTRNAND for which the guide was initially written.)

I added the 01 to the code and now the Wifi LED that stopped turning on after i did CTRtransfer D9 with the 00 script, turns back on again.

I'm reading the guide more thoroughly to see if can find something else that might be relevant:

Shouldnt there be 2 subdirectorys in the data folder? There is only this one

Post automatically merged: Nov 22, 2022

What is this?

 

[Kwyjor]

Shouldnt there be 2 subdirectorys in the data folder? There is only this one

You're going to have to be a lot more precise about what data folder you are referring to. Do you mean the "Nintendo 3DS" folder?

What is this?

Is that something you're now seeing on your 3DS..? Details are always helpful.

Anyway, the vast majority of the time people see that error, it is because they are trying to use an old version of Luma on newer firmware versions – either because there's an old version of Luma on the SD card, or an old version of Luma on the NAND. Are you sure you have the latest version of Luma (boot.firm) ?

(Conceivably that error can occur for other reasons, but an outdated Luma is usually what does it.)

 

[AngelBelmont]

You're going to have to be a lot more precise about what data folder you are referring to.


Is that something you're now seeing on your 3DS..? Details are always helpful.

Anyway, the vast majority of the time people see that error, it is because they are trying to use an old version of Luma on newer firmware versions – either because there's an old version of Luma on the SD card, or an old version of Luma on the NAND. Are you sure you have the latest version of Luma (boot.firm) ?

(Conceivably that error can occur for other reasons, but an outdated Luma is usually what does it.)

Yeah i was tickering with older Luma versions, i thought that the problem could have been the fact that i didnt really update my 3ds firmware in fear that some update by Nintendo could have bricked it since i had a CFW... By checking the forums i can see that the opposite is what is encouraged, to update the system no matter what.

I thought that since my firmware has to be a bit older, maybe the fact that is was running the latest Luma was the problem. Nothing come from that so i reinstalled the files for Luma 11 once again

Post automatically merged: Nov 22, 2022

FIXED

What was the problem? It was a hardware problem, the camera ribbon seems to be faulty, on when its faulty AND connected we get that black screen of death.

The Solution: open up your console and disconnect the camera ribbon from the board (the ribbon pointed in the image)

 

[XLuma]

Yeah i was tickering with older Luma versions, i thought that the problem could have been the fact that i didnt really update my 3ds firmware in fear that some update by Nintendo could have bricked it since i had a CFW... By checking the forums i can see that the opposite is what is encouraged, to update the system no matter what.

I thought that since my firmware has to be a bit older, maybe the fact that is was running the latest Luma was the problem. Nothing come from that so i reinstalled the files for Luma 11 once again

Post automatically merged: Nov 22, 2022

FIXED

View attachment 339319

What was the problem? It was a hardware problem, the camera ribbon seems to be faulty, on when its faulty AND connected we get that black screen of death.

The Solution: open up your console and disconnect the camera ribbon from the board (the ribbon pointed in the image)

View attachment 339320

so the camera ribbon is the problem all along ? interesting

 

[Kwyjor]

What was the problem? It was a hardware problem, the camera ribbon seems to be faulty, on when its faulty AND connected we get that black screen of death.

Congratulations. I am suitably impressed. Was there anything in particular that inspired you to check the camera cable?

(It does come up occasionally. Maybe it'd be nice if there was some kind of .firm payload that could be used for such diagnostics.)

 

[AngelBelmont]

Congratulations. I am suitably impressed. Was there anything in particular that inspired you to check the camera cable?

(It does come up occasionally. Maybe it'd be nice if there was some kind of .firm payload that could be used for such diagnostics.)

I remembered watching a video some time ago talking about the Wifi Card being a problem if its connection was faulty, so i started looking for that video and found this other video:



His problem was not 1 to 1 as mine, however i noted his solution and opened the 3ds. First i tried to disconnect and reconnect the Wifi card, and when that didnt do anything, i disconnected the camera ribbon and the thing just booted up when i turned it on.