Hacking How exactly does Nintendo check regarding 002-0102?

[drfsupercenter]

So I ran into a bit of an interesting dilemma.

I have a NAND modded 3DS XL, and just for the heck of it I wanted to try creating a Japanese emuNAND. I went through all the steps, installed the CIA, etc. Found a SecureInfo_A file on a somewhat infamous sharing site and thought I'd try it to see what happens.

Well, surely enough, playing a Gateway ROM of Pokémon OmegaRuby with my own legit private header, I got the error 002-0102. I don't read Japanese so I shrugged it off and figured something was just screwed up in the process of region-changing.

I put my old emuNAND back, the USA region one that has all of my legit games, and all the sudden that one is banned as well. I even tried updating sysNAND to 9.7, deleting the eShop account and then doing a system format. Popped in my retail copy of OmegaRuby and surely enough, banned.

OK, so here's where it gets interesting. I also own a 2DS, sysNAND on 7.2. I booted it up in rxMode and used that same retail card, and it worked fine. No error code, it connected to the Internet just fine.

So I thought, why not take the SecureInfo_A file from my 2DS and inject it into the 3DS XL? So I flashed it back to 9.2, ran rxTools and injected the file from my 2DS. Then did the same format+update+delete eShop account - I can confirm that the injection worked as I entered my 2DS' serial number which removed the eShop account.

But it's still giving me the banned message and 002-0102. Tried the cartridge in my 2DS again just to make sure somehow that serial didn't get banned, and it still works. Same cartridge, same SecureInfo_A file, but my XL is banned. (Would that have been caused by the Japanese SecureInfo_A I downloaded being blacklisted?)

So I'm curious what else is being looked at when it determines the online bans. It's obviously not the serial number/whatever else is in SecureInfo_A as just transplanting a known good one didn't unban me. It can't be tied to the NAND files either as a system format would have fixed it, same with deleting the eShop account.

What else could it have been? Someone suggested MAC address... any validity to that? I wonder if you could spoof your 3DS' MAC using kernel exploits. (or, just for sanity's sake, I could physically disconnect the wi-fi board from my banned console and transplant another in its place, see what happens)

 

[Adeka]

you got banned using a cia or did I read it wrong?

 

[drfsupercenter]

Not exactly. I simply tried launching OmegaRuby from my Gateway on a system I had fudged to be Japanese. And it was .3dz with my own legit header which works on the 2DS so it's not the Gateway's fault.

 

[Xenon Hacks]

Not exactly. I simply tried launching OmegaRuby from my Gateway on a system I had fudged to be Japanese. And it was .3dz with my own legit header which works on the 2DS so it's not the Gateway's fault.

Download its update from the Eshop using a NNID that should fix the problem

 

[yifan_lu]

Yeah secureinfo isn't really used in online communications. It's mostly done with the ctcert

 

[weiff]

Most bans are done via MAC address in any other situation. This is because the MAC is static, so even if you change the IP of your connection it is still tied to the same MAC for the ban.

However since you are required to use distinct account information to connect it could be tied to that or even that whole "unique console number" ... which is more or less another MAC.

 

[drfsupercenter]

Download its update from the Eshop using a NNID that should fix the problem

It actually didn't let me. I tried downloading the update using the Y button (you know, the new feature in 9.x that lets you download the update without ever opening eShop) and it immediately gave that error. I installed the update myself from a .cia and got the error again.

But here's the thing. Back on the legit USA-region system that I've formatted several times now, it WILL let me download the update from the eShop, it just errors when I try to go online in-game.

Yeah secureinfo isn't really used in online communications. It's mostly done with the ctcert

Interesting. Is that a file that can be extracted from one system and injected into another?

 

[drfsupercenter]

Most bans are done via MAC address in any other situation. This is because the MAC is static, so even if you change the IP of your connection it is still tied to the same MAC for the ban.

You can change the MAC though, depending on what it is. It's actually a writable value, on a PC it's pretty easy, and if you have kernel access you should be able to do it on a console too.

But like I said, if you guys think it is the MAC specifically that gets banned, I can try opening up my black XL, unplugging the wi-fi module and plugging one in from another one of my systems that isn't banned and see what happens.

 

[yifan_lu]

Most bans are done via MAC address in any other situation. This is because the MAC is static, so even if you change the IP of your connection it is still tied to the same MAC for the ban.

However since you are required to use distinct account information to connect it could be tied to that or even that whole "unique console number" ... which is more or less another MAC.

Where's your source for this? I never seen the Mac address used in requests.

 

[Xenon Hacks]

It actually didn't let me. I tried downloading the update using the Y button (you know, the new feature in 9.x that lets you download the update without ever opening eShop) and it immediately gave that error. I installed the update myself from a .cia and got the error again.

But here's the thing. Back on the legit USA-region system that I've formatted several times now, it WILL let me download the update from the eShop, it just errors when I try to go online in-game.



Interesting. Is that a file that can be extracted from one system and injected into another?

Dont use CIA's get it straight from the eShop using firmware spoof or through Emunand it will fix your problem.

 

[Deleted-355425]

You can change the MAC though, depending on what it is. It's actually a writable value, on a PC it's pretty easy, and if you have kernel access you should be able to do it on a console too.

But like I said, if you guys think it is the MAC specifically that gets banned, I can try opening up my black XL, unplugging the wi-fi module and plugging one in from another one of my systems that isn't banned and see what happens.

would be interesting to find out if that works.

 

[drfsupercenter]

Dont use CIA's get it straight from the eShop using firmware spoof or through Emunand it will fix your problem.

Too late for that now. I think the black-listed SecureInfo file did something to the console, either that or it was because I didn't install all the necessary CIAs when region-swapping.

As I've said a few times, I already formatted sysNAND and updated it to 9.7, it's still banned, so the issue of the Japanese fudged emuNAND is a bit old news at this point. I was simply mentioning how I got into the situation to begin with.

 

[gamesquest1]

nope if you read through the "how to make a US small n3DSXL thread" basically there is a embedded ID called the Ctcert, which is what is used to issue bans/lock eshop region etc, there is no way to change the Ctcert, its hardcoded into the console and is console specific, the only way to bypass it is on the fly spoofing which afaik is only possible on the n3DS atm using NTR CFW 2.2 and you again need to have a donor console to spoof it as, this will need to be re-applied every time you want to play online and there is no way to do it permanently.........guess you better hope its just a 15 day ban like some users got

 

[weiff]

Where's your source for this? I never seen the Mac address used in requests.

There are several different security bans that can be levied. I do not know on the specific situation if that data is transmitted, I work closely with a network team for my job and they always track machines across the network with the MAC. So this information is only off industry standard... where it is not widely used, because it is easier to block a whole IP range than several MAC addresses.

Again, as I stated, there are several "machine specific" numbers that could be transmitted for their security checks. They are clearly tracking the specific devise, because we have heard about machines(DS, DSi, 3DS, 2DS) that still remain unusable after resale.

Any effective ban is a complete ban, MAC, IP, and Account. If you really want around all of those you have a enough hoops to jump through.

 

[yifan_lu]

Yeah, I don't think the MAC address is used at all (much like serial number). Everything seems to be done with the ClCert which allows your 3ds to also sign requests verifying that it's from that unit. Everything else can be faked easily.

 

[drfsupercenter]

nope if you read through the "how to make a US small n3DSXL thread" basically there is a embedded ID called the Ctcert, which is what is used to issue bans/lock eshop region etc, there is no way to change the Ctcert, its hardcoded into the console and is console specific, the only way to bypass it is on the fly spoofing which afaik is only possible on the n3DS atm using NTR CFW 2.2 and you again need to have a donor console to spoof it as, this will need to be re-applied every time you want to play online and there is no way to do it permanently.........guess you better hope its just a 15 day ban like some users got

Is it a file on the NAND though? You'd think if you have two identical units (e.g. both 3DS XL) you could decrypt the entire NAND from one and inject it into the other?

 

[gamesquest1]

Is it a file on the NAND though? You'd think if you have two identical units (e.g. both 3DS XL) you could decrypt the entire NAND from one and inject it into the other?

nope its stored in the SoC afaik, so no way of moving/replacing it only way around it would be spoofing via ram hacks

this is all based on yifan's research with the region changing, the files on the nand are primarily just used for verification on the device itself, all the server side stuff is verified via ctcert rather than secure info etc

 

[cearp]

you weren't 'banned', i think. this happened to my friend a few months ago when we were playing with region changing. i think he fixed it but i don't know how

 

[drfsupercenter]

OK, so I can confirm it has nothing to do with MAC addresses. I just opened up both of my XLs (the NAND modded one and my still-under-warranty untouched one, don't tell Nintendo) and swapped the two wi-fi modules. I know it's the right piece as for one the antenna plugs into it and if I turn it on with that detached, the "Internet" part disappears from the top screen and promptly crashes my system if I try to open the browser.

Anyway, swapped them and still get the 002-0102 message. So yeah, it's probably CTCert and not MACs after all.

In theory, couldn't you just system transfer and that would lift the ban? Going to try that next.

 

[drfsupercenter]

you weren't 'banned', i think. this happened to my friend a few months ago when we were playing with region changing. i think he fixed it but i don't know how

I wish that were the case, but I'm back on USA firmware (even restored my NAND image of 4.2.0-9U Gateway downgraded and re-upped it to 9.2) and it still gives me the error. So clearly it persists outside the NAND...