Hacking Is possible to downgrade the 3ds with this method?

  • Thread starter Thread starter Mazamin
  • Start date Start date
  • Views Views 4,485
  • Replies Replies 31

Mazamin

Well-Known Member
Member
Joined
Sep 4, 2014
Messages
1,904
Solutions
1
Reaction score
882
Trophies
2
XP
3,827
Country
Italy
Can someone explain me if these steps working?

Requirements
2 3ds (A and B)
Hard mod
9.2 or lower firmware on 3ds B
Computer

1 dump A's nand
2 make xorpads of B
3 update B to the firmware version of A
4 dump B's nand
5 decrypt firm and fat16 of B with the xorpads
6 xorpad A's firm with decrypted firm (obtained on 3ds B) in order to obtain xorpad of A's firm
7 do the same with the fat16
Now we have A's xorpads
8 encrypt the decrypted firm with A's xorpad
9 do the same for fat16
10 inject them in the nand dump of A
11 write the obtained nand dump in A

I don't know if it works as I don't have 2 3ds and I don't have an hard mod
 
I think the problem is you can't make an xorpad on A unless A is exploitable. The two consoles have unique encryption keys.
No, I make xorpads of B when it's 9.2 and then update it
I obtain xorpads of A by xorpadding encrypted firm with decrypted firm
 
But A and B won't be unique even if they were both decrypted.
Why do you think this?
If I update B to the fwver of A they will be the same.
Only secure info will change probably, for the settings you can just format the consoles
 
Why do you think this?
If I update B to the fwver of A they will be the same.
Only secure info will change probably, for the settings you can just format the consoles
Because there will probably be differences in the file system, like unique IDs and the serial number. Nintendo might also have logging that does not get deleted with a format, and the update history and packages between the two consoles may differ.
 
Because there will probably be differences in the file system, like unique IDs and the serial number. Nintendo might also have logging that does not get deleted with a format, and the update history and packages between the two consoles may differ.
Probably you're right but I want a reply from a dev/hacker
 
@Dr.Crygor 07 I basically had this same theory too, but it seems that the filesystem might not be identical. I feel like it still shouldn't be dismissed, but if you could get access to a decrypted title, that could be downgraded to exploit (like MSET or Spider) it might work. I feel that you'd also need to restore a few patched exploits, like gspwn, and rohax
 
@Dr.Crygor 07 I basically had this same theory too, but it seems that the filesystem might not be identical. I feel like it still shouldn't be dismissed, but if you could get access to a decrypted title, that could be downgraded to exploit (like MSET or Spider) it might work. I feel that you'd also need to restore a few patched exploits, like gspwn, and rohax
The exploits are in system applets, so is quicker to make a full downgrade
 
There are some files that can't be used on a different console. The contents of the dbs folder is encrypted using console unique keys. Movable.sed in private folder would need modification before it can be used on a different console. So you'll only get a brick if you try and move a different console's firmware to another.
 
There are some files that can't be used on a different console. The contents of the dbs folder is encrypted using console unique keys. Movable.sed in private folder would need modification before it can be used on a different console. So you'll only get a brick if you try and move a different console's firmware to another.
Ok, mine was only a try
 
Differences in the NAND data won't let you gen a xorpad on A.
(Even if they're both identical I'm still not sure).
 
If you knew the location of an applet, you could make an xorpad for that applet against a fully decrypted one, and then use that same xorpad to encrypt a lower version
 
i had a toy about with it a while back, while yeah you can technically make xorpads for specific regions like NATIVE_FIRM etc, for actual partitions where the data changes you would have to do a lot of work mapping out exact offsets for specific files to see if you can correlate any across multiple systems, but not even factoring in filesystem offset differences you would also have filesize differences which would most likely need to be adjusted manually in the file allocation table

basically if you get lucky and you have 2 systems that happen to have the same offsets for all essential files required for a downgrade (feasible i guess) it would still involve quite a bit of manual work fixing the fat16 table manually

basically i wanted to look into it a while back but it would probably require the studying of several different decrypted nands of matching region/FW version to get a sense of if there is any usable pattern for the file structure across consoles, as for my test simply downgrading native_firm i just ended up with a black screen on boot.......tbh there may be some major flaw im overlooking like the title.db being signed after installing stuff or something along those lines......without lots of decrypted nand dumps to study you would be pissing in the wind

it certainly wouldnt be as easy as decrypt console A nand and xor against consoles B's nand to get the xorpad to decrypt console B's nand, sure certain area's would actually be decrypted, but anything that didn't line up perfect would end up a garbled mess
 
Last edited by gamesquest1,
i had a toy about with it a while back, while yeah you can technically make xorpads for specific regions like NATIVE_FIRM etc, for actual partitions where the data changes you would have to do a lot of work mapping out exact offsets for specific files to see if you can correlate any across multiple systems, but not even factoring in filesystem offset differences you would also have filesize differences which would most likely need to be adjusted manually in the file allocation table

basically if you get lucky and you have 2 systems that happen to have the same offsets for all essential files required for a downgrade (feasible i guess) it would still involve quite a bit of manual work fixing the fat16 table manually

basically i wanted to look into it a while back but it would probably require the studying of several different decrypted nands of matching region/FW version to get a sense of if there is any usable pattern for the file structure across consoles, as for my test simply downgrading native_firm i just ended up with a black screen on boot.......tbh there may be some major flaw im overlooking like the title.db being signed after installing stuff or something along those lines......without lots of decrypted nand dumps to study you would be pissing in the wind

it certainly wouldnt be as easy as decrypt console A nand and xor against consoles B's nand to get the xorpad to decrypt console B's nand, sure certain area's would actually be decrypted, but anything that didn't line up perfect would end up a garbled mess
So theorically this is possible but requires a lot of work.
For me it's a good purpose and if this work will be done by a good dev this will be wonderful.
 

Site & Scene News

Popular threads in this forum