The purpose of checking those files (LFCS_B, movable, HWCAL0, HWCAL1, SecureInfo) in the [1:] SYSNAND CTRNAND, was to make sure the o3DSXL is using the correct copies so Nintendo doesn't ban that system when you use online services (Nintendo eShop, system updates, game play, theme shop, Internet browser, etc).
Can your o3DSXL boot HOME Menu, or does the prefetch abort error still happens?
You mentioned the o3DSXL went back to being bricked even though you tried the CTRTransfer (Type D9).
In the other thread, ThatOneCookie has a n2DSXL where CTRTransfer(s) weren't fixing his softbrick. The only way we were able to solve and fix his brick was that he sent his NAND images over so I can temporarily use them on my n3DSXL to take a closer look for each file... by mailing his n2DSXL to my house.
Of course, if you were to agree to this idea, it would mean trusting me to safeguard your private data. That choice is up to you.
Last edited by TurdPooCharger,
- Joined
- Jan 21, 2017
- Messages
- 34
- Trophies
- 0
- Location
- La Riche
- Website
- toh-ka.github.io
- XP
- 145
- Country
I'm sorry but I won't send it, the cost of an airiship is too much just for that, but, if you're ok, I would be ok for a discord call where I'll turn on my cam so you can see my 3DS
Posting a follow-up of what happened.
After talking to @PizzaYandere37 in private, he eventually relented to overnight ship his o3DSXL. While the price to mail from France to Florida and back wasn't cheap by any means, he was able to amass payment in a timely fashion.
Debugging his o3DSXL as-is proved unwieldy due to a bulky body case. Safe removal of the case wasn't an option because of it's frail condition... I didn't want to send back his o3DSXL with it broken.
Because I'm a stickler for good form factor when it comes to handheld electronics and to get around this problem, the o3DSXL NAND images [ ctrnand_full.bin, twln.bin, twlp.bin, and essential.exefs ] were dumped and temporarily used on my nephew's o2DS.
After examining the files mentioned from post #13, the causes of the brick became apparent.
What happened to PizzaYandere37's o3DSXL was very unfortunate. There was a prior attempt at region changing the firmware from native (EUR) to (USA). The SecureInfo_A shown in that picture found in [1:] SYSNAND CTRNAND comes from the public CTRTransfer image, 11.5.0-38U_ctrtransfer_o3ds.bin; CW72535537 is not the o3DXL's serial number when compared against the inspect.log from the [2:] SYSNAND TWLN. That means the real & original SecureInfo, LFCS, and movable were lost along the way presumably from failed or incomplete CTRTransfer(s). Only the HWCAL0.DAt and HWCAL1.DAt were intact.
What made matters worse is that GodMode9 never had the chance to properly backup those three files for the essential.exefs. To make the situation even more shitty, the o3DSXL's first [sys|emu|red]nand.bin image backed up when it was first hacked was lost after his old computer died and was sold off last year.
In order to get the o3DSXL in a bootable state, the movable.sed was replaced with another dummy copy but in functional format.
The replacement SecureInfo_A was borrowed from the 11.5.0-38E_ctrtransfer_o3ds.bin edited with the o3DSXL's actual serial number. Although this file is no longer signed where uninstalling custom firmware would brick the o3DSXL, it is hoped that Nintendo doesn't notice anything amiss should those first 0x100 (256) bytes are ever checked.
Lastly, the LocalFriendCodeSeed_B was not replaced in the initial firmware repair.
After updating the firmware to 11.10.0-43E, fixing the TWL system titles, and adding CTRNAND Luma3DS with GodMode9 payload, I took the fixed images from the o2DS, reflashed them back on the o3DSXL, and mailed backed his system.
To get around the issue of not being able to access Nintendo eShop or use other online services,
@PizzaYandere37 was tasked to:
***
I'm glad I got a chance to study this brick as it helped to point out some weaknesses in the current version of the CTRTransfer (Type D9) script. It wouldn't have fixed this brick mainly due to poor handling or distinguishing whether those essential files are valid or good copies. The next planned release of Type D9 will include fixes so bricks like this one won't be a problem to at least allow the 3DS/2DS to boot HOME Menu.
After talking to @PizzaYandere37 in private, he eventually relented to overnight ship his o3DSXL. While the price to mail from France to Florida and back wasn't cheap by any means, he was able to amass payment in a timely fashion.
Debugging his o3DSXL as-is proved unwieldy due to a bulky body case. Safe removal of the case wasn't an option because of it's frail condition... I didn't want to send back his o3DSXL with it broken.
Because I'm a stickler for good form factor when it comes to handheld electronics and to get around this problem, the o3DSXL NAND images [ ctrnand_full.bin, twln.bin, twlp.bin, and essential.exefs ] were dumped and temporarily used on my nephew's o2DS.
After examining the files mentioned from post #13, the causes of the brick became apparent.
What happened to PizzaYandere37's o3DSXL was very unfortunate. There was a prior attempt at region changing the firmware from native (EUR) to (USA). The SecureInfo_A shown in that picture found in [1:] SYSNAND CTRNAND comes from the public CTRTransfer image, 11.5.0-38U_ctrtransfer_o3ds.bin; CW72535537 is not the o3DXL's serial number when compared against the inspect.log from the [2:] SYSNAND TWLN. That means the real & original SecureInfo, LFCS, and movable were lost along the way presumably from failed or incomplete CTRTransfer(s). Only the HWCAL0.DAt and HWCAL1.DAt were intact.
What made matters worse is that GodMode9 never had the chance to properly backup those three files for the essential.exefs. To make the situation even more shitty, the o3DSXL's first [sys|emu|red]nand.bin image backed up when it was first hacked was lost after his old computer died and was sold off last year.
In order to get the o3DSXL in a bootable state, the movable.sed was replaced with another dummy copy but in functional format.
- This file has the size of 0x120 (288) bytes filled with all zeros (00), except for block 0x00-0x03 having the magic header (53 45 45 44 - SEED).
The replacement SecureInfo_A was borrowed from the 11.5.0-38E_ctrtransfer_o3ds.bin edited with the o3DSXL's actual serial number. Although this file is no longer signed where uninstalling custom firmware would brick the o3DSXL, it is hoped that Nintendo doesn't notice anything amiss should those first 0x100 (256) bytes are ever checked.
Lastly, the LocalFriendCodeSeed_B was not replaced in the initial firmware repair.
After updating the firmware to 11.10.0-43E, fixing the TWL system titles, and adding CTRNAND Luma3DS with GodMode9 payload, I took the fixed images from the o2DS, reflashed them back on the o3DSXL, and mailed backed his system.
To get around the issue of not being able to access Nintendo eShop or use other online services,
@PizzaYandere37 was tasked to:
- Create an initial dummy user profile.
- Format System Memory in order to make another dummy user profile.
- This converts the movable.sed to 320 bytes with AES-CMAC.
- (Real Nintendo) System Transfer his o3DS profile over to the o3DSXL.
- The o3DS movable.sed gets sent to the o3DSXL. (ie, given a real/valid movable.sed).
- This links the NNID to the o3DSXL. As far as Nintendo server record is concerned, his o3DSXL should be able to visit Nintendo eShop.
- The o3DS movable.sed gets sent to the o3DSXL. (ie, given a real/valid movable.sed).
- Copy and share the o3DS LocalFriendCodeSeed_B over to the o3DSXL after the System Transfer.
- This allows the o3DSXL to regain access to other online services: game play, Internet.
- However, there's the risk that LFCS_B might get banned/burned if both o3DS and o3DSXL are using it at the same time.
- This allows the o3DSXL to regain access to other online services: game play, Internet.
***
I'm glad I got a chance to study this brick as it helped to point out some weaknesses in the current version of the CTRTransfer (Type D9) script. It wouldn't have fixed this brick mainly due to poor handling or distinguishing whether those essential files are valid or good copies. The next planned release of Type D9 will include fixes so bricks like this one won't be a problem to at least allow the 3DS/2DS to boot HOME Menu.
Last edited by TurdPooCharger,
Well looks like i've got the exact same problems 
or something like it...
i need to get my real SN in secureinfo as its the one from CTRTransfert's file thats being used ?
Anyway its better than having Unknown written everywhere ...
so as of now, i can boot godmode9 , lumaCFG, and only thing I saw from o2DS gui is the Recovery menu , that ultimately booted after CTRTransfert. But I had to get secureinfo fils manually from .bin
As of now, i never saw Luma Boot or that 2DS Boot into home menu at all.
I can send the thing , or provide any files ! Please help me too !
or something like it... i need to get my real SN in secureinfo as its the one from CTRTransfert's file thats being used ?
Anyway its better than having Unknown written everywhere ...
so as of now, i can boot godmode9 , lumaCFG, and only thing I saw from o2DS gui is the Recovery menu , that ultimately booted after CTRTransfert. But I had to get secureinfo fils manually from .bin
As of now, i never saw Luma Boot or that 2DS Boot into home menu at all.
I can send the thing , or provide any files ! Please help me too !
Well looks like i've got the exact same problems
i need to get my real SN in secureinfo as its the one from CTRTransfert's file thats being used ?
Anyway its better than having Unknown written everywhere ...
so as of now, i can boot godmode9 , lumaCFG, and only thing I saw from o2DS gui is the Recovery menu , that ultimately booted after CTRTransfert. But I had to get secureinfo fils manually from .bin
As of now, i never saw Luma Boot or that 2DS Boot into home menu at all.
I can send the thing , or provide any files ! Please help me too !
Damn ! HexEdited SecureInfo_A , removed the SN from the ctrtransfer files, put mine , copied back and BAM ! Home Menu !!!
Well its not that hard wasn't it
See if you still have your real copy of the SecureInfo_A | B.Damn ! HexEdited SecureInfo_A , removed the SN from the ctrtransfer files, put mine , copied back and BAM ! Home Menu !!!
Well its not that hard wasn't it
1A. GodMode9 → [S:] SYSNAND VIRTUAL/essential.exefs → Mount as EXEFS image.
2A. [G:] EXEFS GAME IMAGE/secinfo → Copy to 0:/gm9/out.
2A. [G:] EXEFS GAME IMAGE/secinfo → Copy to 0:/gm9/out.
or
1B. GodMode9 → [S:] SYSNAND VIRTUAL/ctrnand_full.bin → Copy to 0:/gm9/out.
2B. IsoBuster → File → Open Image File → ctrnand_full.bin → FAT [Deleted Files and Folders] → rw/sys/SecureInfo_A | B
2B. IsoBuster → File → Open Image File → ctrnand_full.bin → FAT [Deleted Files and Folders] → rw/sys/SecureInfo_A | B
- Look for the portable version of IsoBuster...
Damn ! HexEdited SecureInfo_A , removed the SN from the ctrtransfer files, put mine , copied back and BAM ! Home Menu !!!
Well its not that hard wasn't it
Sorry, how to edit SecureInfo in the hex editor, I have the same problem, what do I need to modify? Thanks.
- No one is chatting at the moment.
