Hardware PSA: Gateway Is Making More Bricks

[Wekker]

I am just waiting for gateway users to get their cart bricked because they have sctwo+ launcher in their sd card. Screw gatebutt!

 

[funnystory]

People call it Brickway as a joke just like how they say 9.6+ will come soon™ if you have a real card you won't brick it's that simple and Sky does not affect their business at all Sky3DS is for those unfortunate souls who are stuck on 9.3+ and have not choice but to buy it.

I don't know if I would say they are unfortunate,at least they are given an option to play backups. If only the xbox one had an option to play backups.....

 

[Xenon Hacks]

I don't know if I would say they are unfortunate,at least they are given an option to play backups. If only the xbox one had an option to play backups.....

One can only dream

 

[Foxi4]

install wii files on a vwii you brick it ,,, reason being , installing files designed for another piece of hardware... gateway are protecting their asset.. fair play to them. If people want to stand on the shoulders of giants they better have good balance.

Poor analogy, the Wii and the Wii U are different systems. What you're saying would make sense if 3DS users installed a DS firmware on their machine - that's not what's happening.

 

[Deleted User]

And they shouldn't have, because guess what? Cloners fixed that too. How do I know that? Because they've done it before and yet we're having this conversation about the DSTwo+. The launcher will get "propered" again, there's just a couple more broken 3DS'es out there. Their "drastic" method isn't helping.

There's already 2 plugin "fixes" that really didn't fix the bricks. Where have I seen that before? Oh right, with 3DSLink. And guess what, 3DSLink is as dead as a doornail

 

[pwsincd]

fair comment , but the sentiment is true.

 

[Foxi4]

There's already 2 plugin "fixes" that really didn't fix the bricks. Where have I seen that before? Oh right, with 3DSLink. And guess what, 3DSLink is as dead as a doornail

Due to hardware differences between the cartridges, not the magical bricking code. The 3DS Link could've been obsoleted if it just froze using the same trigger the bricking code uses with no bricks whatsoever, it's not being updated because it's different hardware-wise and cannot be updated to work. We'll just have to agree to disagree, it seems.

 

[Deleted User]

If Supercard or clones all developed their own Launcher.dat there would not be an issue with bricking. This issue would simply not exist.

Therefore, Supercard and clones are the root cause of the bricking. QED

And now, by us discussing these events in great detail, the plebs will hopefully wake up and stay away from the BrickTwo+

 

[Foxi4]

If Supercard or clones all developed their own Launcher.dat there would not be an issue with bricking. This issue would simply not exist. Therefore, Supercard and clones are the root cause of the bricking. QED

You seem do misunderstand the definition of "root" - the root of the issue is that the bricking method exists, there would be no bricks if the method wasn't there. The fact that other manufacturers use the Gateway launcher unfairly is the extension of that root.

 

[gamesquest1]

Due to hardware differences between the cartridges, not the magical bricking code. The 3DS Link could've been obsoleted if it just froze using the same trigger the bricking code uses with no bricks whatsoever, it's not being updated because it's different hardware-wise and cannot be updated to work. We'll just have to agree to disagree, it seems.

nope there was only 1 thing that the original clones couldn't technically pull off and that was CARD2 saves (and even then they could have simply added .cia support to bypass that hardware shortfall), everything else was purely 3DS SW side and easily compatible with their card, the reason why they were dead and buried was that everyone lost faith in their abilities, but not just the R4 clone card loss of faith i.e oh i will have to buy a new revision, but SHIT these guys are f**king idiots and my system will end up bricked while they try repeatedly to try get the FW working.....and it obviously transcended to DSTwo+ as soon as people seen GW emulation, the general reaction was "well these guys screwed up" before the card was even released,everyone knew exactly what was going to happen

 

[Foxi4]

nope there was only 1 thing that the original clones couldn't technically pull off and that was CARD2 saves (and even then they could have simply added .cia support to bypass that hardware shortfall), everything else was purely 3DS SW side and easily compatible with their card, the reason why they were dead and buried was that everyone lost faith in their abilities, but not just the R4 clone card loss of faith i.e oh i will have to buy a new revision, but SHIT these guys are f**king idiots and my system will end up bricked while they try repeatedly to try get the FW working.....and it obviously transcended to DSTwo+ as soon as people seen GW emulation, the general reaction was "well these guys screwed up" before the card was even released,everyone knew exactly what was going to happen

Pretty sure that the trigger for the brick was how the SPI was handled. Clones reported SPI issues which then triggered the bricking code at random.

 

[gamesquest1]

Pretty sure that the trigger for the brick was how the SPI was handled.

nope the original trigger was the fact they modified the launcher, DSTwo thought they would be immune by not modifying the launcher and walking through the front door to avoid the brick code (which in itself proves they were aware of it).......stupidly not thinking "wait there as soon as we release GW will just add a extra check on the front door and we will be back to square 1"

no doubt months of RE'ing spend trying to clone rather than staring their own launcher from scratch, it defies logic unless the simply had no clue how to code for the 3DS, which again would be pretty bad for a flashcard team

 

[pwsincd]

did gateway design some code to work on their hardware. Yes
did others copy their work and try to profit .. yes
did gateway protect their asset ... yes
can you blame gateway ... not at alll..... they designed code for their benefit only...

its not that hard to understand you know.

 

[Deleted User]

@Bortz You scared to do that DSTWO+ review yet?

I hope you realise you have a responsibility to educate the people here.
So when users want an honest review about the 3DS functionality, then the real possibility of bricking should be mentioned.

With this, the argument "we didn't know it can brick" will hopefully be solved

 

[Foxi4]

nope the original trigger was the fact they modified the launcher, DSTwo thought they would be immune by not modifying the launcher and walking through the front door to avoid the brick code (which in itself proves they were aware of it).......stupidly not thinking "wait there as soon as we release GW will just add a extra check on the front door and we will be back to square 1"

As far as I remember, and I've read a lot of info on this back in the day, modifying the Launcher would (obviously) change checksums. If checksums didn't match in the launcher, it would begin testing how the SPI works and if the protocol failed, it would run the bricking code at random intervals. That being said, I may very well be remembering the chain of events poorly.

Launcher checks its own integrity -> If integrity check fails, check SPI -> If SPI fails, enable Russian Rulette -> If you lose the spin, your NAND gets borked

 

[gamesquest1]

As far as I remember, and I've read a lot of info on this back in the day, modifying the Launcher would (obviously) change checksums. If checksums didn't match in the launcher, it would begin testing how the SPI works and if the protocol failed, it would run the bricking code at random intervals. That being said, I may very well be remembering the chain of events poorly.

Launcher checks its own integrity -> If integrity check fails, check SPI -> If SPI fails, enable Russian Rulette -> If you lose the spin, your NAND gets borked

well regardless, as there never was a full breakdown of the brick code, a lot of hearsay and speculation and vague "its random, sometimes it will sometimes it wont"....."it based on any file with the letter L on your SD card", "its based on time stamps", i dont think there was ever a 100% confirmed cause....oh and the bricks on GW cards would suggest otherwise as i never had any issues with SPI errors on my main GW card but still managed to trigger the brick code on 2.0b2,im pretty sure it was just 2 stages of checksums in the launcher which then ran the "brick code" itself (which involved the russian roulette stage), the bug in B2 was that diagnostics would also "test" the brick code .....yep brick code works, have a nice day

 

[Deleted User]

As far as I remember, and I've read a lot of info on this back in the day, modifying the Launcher would (obviously) change checksums. If checksums didn't match in the launcher, it would begin testing how the SPI works and if the protocol failed, it would run the bricking code at random intervals. That being said, I may very well be remembering the chain of events poorly.

Launcher checks its own integrity -> If integrity check fails, check SPI -> If SPI fails, enable Russian Rulette -> If you lose the spin, your NAND gets borked

The launcher had multiple integrity checks, like so:
If hash check 1 failed -> hang
If hash check 2 failed -> enable russian roulette (and maybe use SPI check too, I don't know, I am just remembering what devs said about the hash checks)

If the first check failed, it would simply hang in an infinite loop. The first check was a safeguard against a corrupted Launcher file, so it would not brick on accident.

If the first hash check was succesful, but the second one was not, that meant you tampered with the Launcher file in a very particular way

 

[hundshamer]

I ran the SPI test, and SCDS2+ passes all tests.

 

[Foxi4]

well regardless, as there never was a full breakdown of the brick code, a lot of hearsay and speculation and vague "its random, sometimes it will sometimes it wont"....."it based on any file with the letter L on your SD card", "its based on time stamps", i dont think there was ever a 100% confirmed cause....oh and the bricks on GW cards would suggest otherwise as i never had any issues with SPI errors on my main GW card but still managed to trigger the brick code on 2.0b2,im pretty sure it was just 2 stages of checksums in the launcher which then ran the "brick code" itself, the bug in B2 was that diagnostics would also "test" the brick code

You're right - I guess we'll never know unless we see the source code. Either way, I disagree with this kind of implementation, it's highly aggressive DRM and if Gateway wants to protect their code, they should use methods that do not harm end-users - that's all I'm saying.

 

[Deleted User]

Gateway wants to protect their profits. Big difference