Sorry to give you bad news but Cross checked on a few devices and the sector is not the same across all devices.
One unit of mine has secureinfo_a at address 0xE7C8000 and another one at 0xE738000.
It's not that simple. I don't know how to retrieve the sector from the broken unit if it's even possible at all.
One unit of mine has secureinfo_a at address 0xE7C8000 and another one at 0xE738000.
It's not that simple. I don't know how to retrieve the sector from the broken unit if it's even possible at all.
Last edited by GothicIII,
Are they N3DS/O3DS? Have you modified it before? It should be close enough to another console near the same manufacturing date/model. Since afaik, the 3DS never "defrags" the FAT partition--it shouldn't move. Worst case, there's maybe < 10 different values that could be it and you just have to try them all.
Yeah I wanted to say it too, I'm just damn tired. Of course it's only a fat partition. And yes I manually nnid transferred one of the devices :/ Both are N3DS so the second value should be valid at least for N3DS.
I still have a o3ds which nand is unmodified. I can check it out after work.
@V3N0MBR :Man this is no trivial task to do what yifan_lu suggested. The problem is that if you are not knowledgeable that things will be very messy and it takes too much time and effort to explain this. You definitely need to self study things. All information you need is spread around 3dsbrew.org and you need basic knowledge about (xor) encryption.
I don't want to be the ass but either pay for complicated things to be done or do it yourself (and learn it)
Yifan_lu did the job in thinking and its someone else job to do it
I don't want to be the ass but either pay for complicated things to be done or do it yourself (and learn it)
Yifan_lu did the job in thinking and its someone else job to do it
Last edited by GothicIII,
- Joined
- Jan 11, 2015
- Messages
- 754
- Trophies
- 0
- Age
- 36
- Location
- Makati
- Website
- leerz25.sitesled.com
- XP
- 2,203
- Country
the way I understand what yifanlu said you have to do the following
from your current nand.bin - do a similarity search based on the XOR-ed CHANGED secureinfo_a
you find that offset, once you find it, XOR your ORIGINAL secureinfo_a then replace those bytes in your current backup.
from your current nand.bin - do a similarity search based on the XOR-ed CHANGED secureinfo_a
you find that offset, once you find it, XOR your ORIGINAL secureinfo_a then replace those bytes in your current backup.
I've only messed with region changing a little but I was under the impression that as long as the secureinfo_A was not modified it could be used on any system. The modded ones don't work because the signature is broken.
You should be able to get one from "the site" and inject it into your sysnand. You may have some problems with the eshop because the serial numbers and whatnot don't match but the system should work.
You should be able to get one from "the site" and inject it into your sysnand. You may have some problems with the eshop because the serial numbers and whatnot don't match but the system should work.
It's unlikely that OP's dumps are ONLY changed by that--although that would work as a heuristic for my method. Basically the way that FAT FS works is that it allocates a sector for a file and then writes to it. The process is deterministic which means that 2 3DS that were not modded/modified and near the same manufacturing date should have the file in the same sector. The idea is to find that sector then XOR the modified secureinfo to get the XOR pad for THAT SECTOR. Then you XOR again with the unmodified secureinfo to INJECT into that sector.
OP can't because they don't have an XOR pad. That's the whole crux of the issue.
I helped someone using this exact method. All they had was their secureinfo_A and modified secureinfo_A. I used the offset that decrypt9.log showed to XOR the modified secureinfo_A with the nand I pulled with a hardmod and then XOR'ed with the original secureinfo_A.
