Hacking GW Team warns against modified launchers

[Keylogger]

There is a timer in the firmware or what?
2.02b was released 3 weeks ago and every 3ds get brick just now...

 

[mr. fancypants]

There is a timer in the firmware or what?
2.02b was released 3 weeks ago and every 3ds get brick just now...

my thought exactly

 

[Keylogger]

It should explain why GW team is so long to release their final fw then

 

[hiron]

It should explain why GW team is so long to release their final fw then

Explain, how is this related to gw next patch?

 

[WiiUBricker]

Can someone please lock this thread? The discussion about the topic is held in two threads, which is unnecessary.

 

[justinkb]

I'll leave this here:

embarrassing how in the other thread we never got any inkling of proof of this supposed time bomb kill switch stuff, mods allowed spreading of crazy scaremongering rumours without any substantiation whatsoever.

at least we know, if you're gonna hex edit (read: fuck with) binaries like a boss (but without the actual ability) and end up screwing up people's 3DSes, be safe in the knowledge that you can shift the blame to whoever's binary it was and no one will question it!

the closing post was laughable (projecting his own inability?), but hey - at least it's locked now and soon it will be on page 2.

 

[Xzi]

Was going to post this in the other thread right before it got locked:

I read through all 26 pages of what was posted in the closed thread, and I'm still none the clearer on what is and isn't fact. What we have so far is a few people claiming to be big-name 3DS scene coders who say that there is malicious bricking code built into Gateway firmware that can be triggered through modifications. I say "claiming to be" because all they've given us so far is a bit of pseudo-code which anybody could have pulled out their ass. There's no copyright or trademark on Gateway's code in so far as I know, and the business they're in isn't exactly legitimate to begin with. There should be no issue with at least posting the portion of the code that supposedly triggers these bricks.

What is clear is that either Gateway or its clones will benefit from this whole hysteria depending on what information is validated. Naturally, the clone manufacturers don't want to be blamed for bricks, despite the fact that the vast majority of reports on 3DS consoles are coming from 3DSLink/R4i users. It would be in their best interest to pin the issue on Gateway's code, despite the fact that their hardware sales are most likely dead in the water from here on out regardless (unless they can start producing original, safe code of their own). OTOH, as Gateway has the safest hardware/firmware on the market now, they clearly don't want their reputation damaged going forward. They want people to trust that anything coming from Gateway has no chance of harming their consoles.

So I think the best thing for everybody would be for Gateway to jump out in front of this and make a statement one way or the other on their site. Either, "yes, we put code in to prevent competition from using our firmware, we apologize and it will not be present in 2.0 final," or, "no, we did not and would not cause intentional bricking to consoles, the responsibility lies with our competition's poor firmware coding." Whatever the case, the truth will be revealed eventually, so they might as well own up to it now if situational bricking code does exist in Gateway's firmware.

 

[justinkb]

I agree, I'm thinking Gateway will post at least something on their website in the next day. This whole business can't have escaped their attention.

 

[willdunz]

I was going thru an emotional roller coaster when reading that thread. now I don't even know what's going on anymore.

 

[someonewhodied]

-snip-

IIRC someone earlier in this thread (or was it in one of the other ones? keep it all in one thread dammit) found that a corrupted original GW launcher won't load, period, so an original GW loader will never brick your 3ds. The checksum check happens before anything else so you have to modify the loader to accept a different checksum first, before you can even do anything with a modded launcher.

Which means its all on the region free patch (which apparently removed the bricker) or a clone cart's launcher.

 

[frown]

If both the clone launchers and Normatt's region-free mod have lead to consoles becoming bricked in the same exact manner, then there's obviously something fishy going on.
The fact that something causes the eMMC controller to be overwritten, preventing nand backups from being restored is EXTREMELY suspect.

 

[Xzi]

IIRC someone earlier in this thread (or was it in one of the other ones? keep it all in one thread dammit) found that a corrupted original GW launcher won't load, period, so an original GW loader will never brick your 3ds. The checksum check happens before anything else so you have to modify the loader to accept a different checksum first, before you can even do anything with a modded launcher.

Which means its all on the region free patch (which apparently removed the bricker) or a clone cart's launcher.

In other words, there must be several checksums. One at the very beginning of the loader, and one after/during ARM9, system memory, etc. If the people responsible for other firmware releases were smart enough to recode the first checksum, why wouldn't they have done it for all of them? It would have been a simple copy/paste job, no?

In any case, I'm glad to hear that the chances of bricking with official Gateway hardware/firmware are very low, if present at all.

 

[naxil]

stop to talk about, why it happen? how it happen? and start to think HOW TO unbrick the 3ds!!!

 

[bkifft]

stop to talk about, why it happen? how it happen? and start to think HOW TO unbrick the 3ds!!!

k, two ideas:

a) replace the emmc chip. it's a ball grid array package though, o have fun soldering that mofo.

b) buy a new 3DS and a gateway or go legit

that is if you don't want to wait on a solution from the high skilled clone engineers, I'm sure they are already working on something...

 

[kyogre123]

k, two ideas:

a) replace the emmc chip. it's a ball grid array package though, o have fun soldering that mofo.

b) buy a new 3DS and a gateway or go legit

that is if you don't want to wait on a solution from the high skilled clone engineers, I'm sure they are already working on something...

I don't know exactly what's that emmc chip, but if it's reprogrammed via software (thus not being a hardware damage) what's preventing someone to fix it via software? Reprogramming this chip leaves it unusable and unreprogrammable?

 

[McHaggis]

that statement makes very little sense: changing even a single bit in any executable code could potentially cause memory corruption.

I do apologise, I didn't realise you were such an expert. If we're going to get technical, though, memory corruption is not unlike the actual aim of hacking: modifying values in memory to cause unintended behaviour from applications using that memory. Unexpected consequences are certainly possible, but several different modifications to the same file are all causing the same unintended side-effect from memory corruption, which is, according to some users, zeroing out the entire sysNAND. Better yet, this is happening intermittently at different times for different users of these file modifications, which have been working just fine the rest of the time.

And that doesn't make you the slightest bit suspicious? Are you so blinded by loyalty that you're going to bite at everyone who thinks this all smells a bit fishy?

have you done any technical review on this region-free patch? if not, stating it's definitely harmless is a) dishonest and b) unhelpful.

Luckily I am neither of those things, then, because I did not state that it was definitely harmless. I said that it didn't seem possible that it would cause memory corruption, and expanding further on that, Normatt is only modifying the file to apply the same in-memory patches that Gateway use. So yes, if it was tested and it works, and many people have tested it and it works for them, it doesn't seem possible that the problem is caused by memory corruption. But let me ask you this: is it "a) honest and b) helpful" to imply that the Gateway is definitely harmless in this situation? Normally, I'm a fan of innocent until proven guilty, but I think that we should be advising people to stay away from the flash card scene until all this is cleared up. That's probably about as "a) honest and b) helpful" as you can get.

 

[bkifft]

I don't know exactly what's that emmc chip, but if it's reprogrammed via software (thus not being a hardware damage) what's preventing someone to fix it via software? Reprogramming this chip leaves it unusable and unreprogrammable?

Disclaimer: this is just the result some cursory googling, reading tech docs and hearsay from forums and IRC. I'm specialized in software, not hardware and have never worked with eMMC (the type of storage chip used on the 3DS)

As far as i know the brick is caused by setting the memory chip to report its size as 0 bytes and switch it to read only mode.

To fix it using software you'd have to get software running, which seems impossible, as the 3DS doesn't seem to have a pandora battery style (edit: clarification: wouldn't have to be triggered by battery, but it seems the 3DS has no recovery mode which could kick in before NAND loading whatsoever) recovery mode.

The usual hw mod (four wires SD interface) doesn't seem to suffice to reset the chips configuration. If it should suffice the exact command sequence isn't known (yet).

So: unless GW releases instructions on their own how to to reopen the memory chip better don't hold your breath till a fix arrives.

 

[pin]

I have a r4i card so which f/w should I be using to avoid bricking? Cheers

 

[bkifft]

I have a r4i card so which f/w should I be using to avoid bricking? Cheers

3.3b, which happens to be identical to 2.0

 

[Hitsuagaya]

3.3b is the most recent firmware bkifft wants to brick your 3ds. Explain to me how the newest fw wont brick it. -_-"