Hacking Forgot my serial

  • Thread starter Thread starter player0
  • Start date Start date
  • Views Views 3,070
  • Replies Replies 21

player0

Well-Known Member
Member
Joined
Sep 2, 2006
Messages
203
Reaction score
10
Trophies
1
XP
462
Country
Hi there, I have an old 4.5 3DS XL and swapped the mb to another case. I sold the old case /w new mb few months ago. Today I was fiddling with the eshop settings and realized that to wipe an eshop account, you need your serial at the back/box. Clever you can see my problem now, my serial does not match my mb and eshop denies wiping, which is not the worst.

The worst thing is if I keep on using this machine, what happen if one day the other owner wants to wipe the other machine and because eshop stops the owner from doing so and the owner resorts to seek Nintendo's help. By providing hard evidences of owning a machine with my serial on it, will Nintendo wipe that serial for that owner, but ended up wiping my machine so that next time when I go online, I will find all of my purchases gone? This is my nightmare...

Should I buy another 4.5 machine and do system transfer now?
 
did you register your machine at nintendo,then you could call them maybe aand say the sticker is off and the box thrown away
 
Or you could update to 7.1 through emuNAND and create a NNID. By doing this, the information of the NNID account will be required instead of the serial in order to make any modifications to the eShop account of the system.
 
Or you could update to 7.1 through emuNAND and create a NNID. By doing this, the information of the NNID account will be required instead of the serial in order to make any modifications to the eShop account of the system.

You'd have to use GW2.0b2 which can cause a brick. 2.0b1 can't access the eShop/Miiverse even on the latest FW.
 
You'd have to use GW2.0b2 which can cause a brick. 2.0b1 can't access the eShop/Miiverse even on the latest FW.

Yes, except that the risk is absolutely nothing close to 1/2, but whatever. The OP is the one that's going to decide what to do, just don't make it sound like it's a virus or something. A lot of people are already almost thinking that going to the Gateway site can cause their 3DS to explode -.-

OP, if you decide to use emuNAND to update and create a NNID account, we (or I) can give you instructions to do it without any risk.
 
Can't you just unscrew the back where the battery is hidden, that's how I got mine for one of my old 3ds a long time ago to find out if was an ambassador one.
 
The OP is the one that's going to decide what to do, just don't make it sound like it's a virus or something. A lot of people are already almost thinking that going to the Gateway site can cause their 3DS to explode -.-

It may not be a virus, but it's sure as hell a malicious trojan, programmed for one specific purpose; to brick peoples consoles. I wouldn't want a ticking time bomb like that on my device, no matter how small the chances are of it bricking me.
 
It may not be a virus, but it's sure as hell a malicious trojan, programmed for one specific purpose; to brick peoples consoles. I wouldn't want a ticking time bomb like that on my device, no matter how small the chances are of it bricking me.

I know about the code, and sorry if this bothers you but statements like the one you made are confusing people in a negative way. I understand that users want to joke about the situation but at the end it is affecting the assistance we are giving to unaware users, who also get scared with all this whole speculation.

As I said, the chance of the launcher to cause a damage to the 3DS is extremely low and there are methods to avoid the problem. I would appreciate if others can leave this thread free of speculation and biased opinions passed as facts.
 
Is it at all possible that in the cloners haste they may have inadvertently patched Gateways software to cause the bricks, and there was no malicious intent or code put forth by Gateway? Is there any proof one way or the other, or just a lot of speculation?
 
  • Like
Reactions: escherbach
Is it at all possible that in the cloners haste they may have inadvertently patched Gateways software to cause the bricks, and there was no malicious intent or code put forth by Gateway? Is there any proof one way or the other, or just a lot of speculation?

Neimod already confirmed that the original launcher contains bricking code. Go check his posting history, he even decompiled the exact line of code.
 
guys come on, he is asking if he can recover his serial, dont start a war here about who did what and what needs to be proofed and gateway sucks and r4 sucks etc.etc.etc. please

on topic:
i checked it, and there is a second serial sticker placed under the battery ;) so simple to recover

link:
http://techforums.nintendo.com/message/42919
 
Just checked his history, and I am assuming you are referring to this post: http://gbatemp.net/threads/gw-team-warns-against-modified-launchers.360534/page-8#post-4883749

Which by his own words is a summary of what the code does. Again, WE NEED SOME FUCKING TANGIBLE PROOF, and not merely speculation. No disrespect to Neimod, but he needs to provide further details or provide some solid evidence, otherwise it's just more hearsay.

Go over to the Gateway site or their official forums and do some reading to get your "FUCKING TANGIBLE PROOF".
 
Just checked his history, and I am assuming you are referring to this post: http://gbatemp.net/threads/gw-team-warns-against-modified-launchers.360534/page-8#post-4883749

Which by his own words is a summary of what the code does. Again, WE NEED SOME FUCKING TANGIBLE PROOF, and not merely speculation. No disrespect to Neimod, but he needs to provide further details or provide some solid evidence, otherwise it's just more hearsay.
There won't be tangible proof because the launcher is not just something you can read or post parts of. Unless you want to see some random meaningless binary data. The hackers figured out what it does through loading the launcher and checking the behavior of the 3DS on a hardware level.
 
Just checked his history, and I am assuming you are referring to this post: http://gbatemp.net/threads/gw-team-warns-against-modified-launchers.360534/page-8#post-4883749

Which by his own words is a summary of what the code does. Again, WE NEED SOME FUCKING TANGIBLE PROOF, and not merely speculation. No disrespect to Neimod, but he needs to provide further details or provide some solid evidence, otherwise it's just more hearsay.

I hold Neimods opinion in pretty high regard, since he was the one who literally created the entire 3ds modding scene thanks to his 4.5 exploit discovery,
Secondly, if it looks like a duck and it walks like a duck, then guess what? It is a duck. You're asking for proof that will never come, since well never have complete access to the source code. But what we can do is decompile bits of it, observe its behavior, and then come to an educated assumption based on that. That's how SCIENCE works. Why do you think it's called the big bang "theory"? Or the "theory" of evolution? Because scientists may not have 100% proof, but after a lot of research and scientific observation, they've come to an educated conclusion. Same case here. We know what the code does, many talented people have confirmed it. We don't need to see the exact source code to know that.
 
If this is the code you are talking about :
Code:
if(<low 4bits u32 output from random-number-generator are zero> && <checksum over arm9 code is invalid>)
brick();

That looks nothing like decompiled instruction sets. That sir is something that is completely made up and put in to syntax which looks something like C.

This is the problem when people who take a few computer theory units in highschool or college think they understand enough to pass judgement about the legitimacy of a claim just because they saw a piece of code that looks sorta, kinda legit.

That piece of code is something that that Neimod made up because he feels it might be in the Gateway launcher somewhere in a sort if nebulous way.

The fact that his post sites that the bricks started happening at the same time because the randomization algorithm used the date as a seed is also a complete tip off that he is just guessing and has not found any such code in any definitive way.

Any novice programmer straight out of vocational school will tell you that standard randomization is based on a time stamp which at minimum takes into account the millisecond at which the randomization instruction set is seeded. This makes the date when the bricks started happening have no correlation with any randomization algorithms. The only scenario in which this could happen is if Gateway went completely out of their way to make randomization functions from scratch that took ONLY the current date as a seed. This is, in all seriousness, a ludicrous proposition.

The most likely scenario is that Neimod took a quick look at the compiled code, saw instructions that looked like checksums in memory, saw instructions that wrote stuff on to NAND and then jumped to a conclusion based solely on his initiall impression. A conclusion that was probably heavily influenced by personal confirmation bias.

The fact that he made the observation about a day after people started reporting the bricking issue, lends credence to the likelihood of this happening.

Analyzing instruction sets in compiled code is an extremely involved and time consuming process. The odds that someone could spot exactly the piece of code responsible for a particular function in the spare time he has within a day of the first few reports is a pretty damn nearly unbelievable feat.
 
  • Like
Reactions: escherbach
If this is the code you are talking about :


That looks nothing like decompiled instruction sets. That sir is something that is completely made up and put in to syntax which looks something like C.

This is the problem when people who take a few computer theory units in highschool or college think they understand enough to pass judgement about the legitimacy of a claim just because they saw a piece of code that looks sorta, kinda legit.

That piece of code is something that that Neimod made up because he feels it might be in the Gateway launcher somewhere in a sort if nebulous way.

The fact that his post sites that the bricks started happening at the same time because the randomization algorithm used the date as a seed is also a complete tip off that he is just guessing and has not found any such code in any definitive way.

Any novice programmer straight out of vocational school will tell you that standard randomization is based on a time stamp which at minimum takes into account the millisecond at which the randomization instruction set is seeded. This makes the date when the bricks started happening have no correlation with any randomization algorithms. The only scenario in which this could happen is if Gateway went completely out of their way to make randomization functions from scratch that took ONLY the current date as a seed. This is, in all seriousness, a ludicrous proposition.

The most likely scenario is that Neimod took a quick look at the compiled code, saw instructions that looked like checksums in memory, saw instructions that wrote stuff on to NAND and then jumped to a conclusion based solely on his initiall impression. A conclusion that was probably heavily influenced by personal confirmation bias.

The fact that he made the observation about a day after people started reporting the bricking issue, lends credence to the likelihood of this happening.

Analyzing instruction sets in compiled code is an extremely involved and time consuming process. The odds that someone could spot exactly the piece of code responsible for a particular function in the spare time he has within a day of the first few reports is a pretty damn nearly unbelievable feat.

EXACTLY.

I've already pointed out that testing the low 4 bits are zero would mean the brick routine is called witha 1/16 chance - which would mean EVERY CLONE with updated firmware is likely bricked after 16 executions of the code - so by now that would mean close to 100% - and we don't see that.

That is supposing the rand number is seeded by system datetime - we don't know because this "neimod code" (posted by profi200) is too vague - it has been suggestd that launcher.dat modification date is the seed - that would mean the clone vendors have a 1 in 16 chance of delivering brick code to their users - BUT once delivered it would activate 100%of the time - and the cloners surely tested the card ONE TIME.

So I'm calling neimod, profi200 et al FUD spreaders

http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
 
  • Like
Reactions: Crass

Site & Scene News

Popular threads in this forum