Hacking The confusion needs to be cleared on FPGA updates and clones

Technicmaster0

Well-Known Member
Member
Joined
Oct 22, 2011
Messages
4,404
Trophies
2
Website
www.flashkarten.tk
XP
3,479
Country
Gambia, The
TBH if you don't think they'll take this opportunity to make things easier on themselves and make more money at the same time, you're deluding yourself. They'll simply change names and start producing 1:1 hardware clones of the Gateway. Assuming this update does in fact require changes to the FPGA logic, anyway. And why not? New users will assume it's a completely different team selling carts that do the same thing as the Gateway at half the price, and old clone customers will end up paying R4i the same $80 people pay for the Gateway. That's a win-win for them. Can't expect any honor from any of these teams.
I think that there are not more than 5 flashcard teams.
 

Mr_Pichu

かわいいね!
Member
Joined
Dec 10, 2013
Messages
170
Trophies
0
XP
133
Country
United States
It's quite possible they're all using an ARM soft-core on the FPGA and they'll update the actual program rom from which the soft core's code executes, rather than the actual FPGA's design itself.

Typically in a hardware software co-design, timing sensitive requirements are implemented by digital logic coded into the FPGA, whereas non-timing sensitive functions would be implemented in software, using a softcore processor to accomplish this task.

This is my best guess as to how the FPGA is used here, based on my knowledge as an embedded systems developer.

I agree...

There is FLASH memory in the GW FPGA, but it is only updatable via JTAG according to the specs, it is accessible as ROM by the FPGA logic. I do not believe the version of the chip GW is using has the ARM softcore built-in, but that is not to say they couldn't put their own in there. One of the smallest ARM cores, the Cortex M0, can be implemented in about 12,000 gates.


Nearest I can tell, the GW card is designed to program itself, but I don't know if that means the logic and/or the FLASH.

When the clones were designed, they probably just reverse engineered what they could. Since the GW update feature has never been utilized before, there was no easy way to figure out how this was implemented.

As they say, the proof will be in the pudding. I hope it turns out tasty.
 
  • Like
Reactions: dagro and Coto

cypher007

Well-Known Member
Member
Joined
Jan 2, 2014
Messages
116
Trophies
0
Age
52
XP
301
Country
one reason I can think for not connecting the pins the same as GW cards. is maybe if they had the GW team could detect the clone and either temporarily or permanently brick the cart rather than the console.

if the 2.0 code does only work on the GW card then why do the whole brickgate fiasco? they could have just waited until they released multirom and go na na nan na na. if the 3ds cart market is that tight they have to wreck consoles to keep ahead of the clones things must be bad.
 

higher87

Active Member
Newcomer
Joined
Sep 14, 2013
Messages
31
Trophies
0
Age
37
XP
132
Country
if the 2.0 code does only work on the GW card then why do the whole brickgate fiasco? they could have just waited until they released multirom and go na na nan na na. if the 3ds cart market is that tight they have to wreck consoles to keep ahead of the clones things must be bad.

not really, even assuming that 2.0 could render the carts useless, the clones would just have made another one that's updatable... i dont really approve of the bricking, but they probably did it to scare people from buying clones ever again
 

gamesquest1

Nabnut
Former Staff
Joined
Sep 23, 2013
Messages
15,153
Trophies
2
XP
12,237
Yeah it was probs just a way to send a clear message to the clone users who where like "why would anyone pay more when the clones can steal the work and nothing bad will happen" fact is if the clones can't code their own work, gateway has proven that the users of the clones are susceptible to whatever anti copying code gateway feels like putting in, and even if you think it's safe.....is it?

Although I don't think they ever planned to be caught out, but still the same message was given
 

Gerbilly

Active Member
Newcomer
Joined
Dec 18, 2013
Messages
35
Trophies
0
Age
60
XP
97
Country
Unfortunately (For Gateway and the unintended victims) there is compelling anecdotal evidence that Gateway's 'clone user killer' has killed several of their own users as well. I suspect for many people, especially the more informed users, the message Gateway has sent is that users should be highly skeptical of the safety of any any future Gateway launcher releases. Sure there will be some who will instantly forgive and forget when (if) multi-rom comes out but I guess they will serve as useful guinea pigs.

The scary part about this whole fiasco is that Gateway could have coded a launcher that bricked EVERY users 3ds with almost complete impunity. Nobody knows who or where they are and if they decide that bricking everyone's console is justified then what is going to stop them from doing so?

How can they ever really be trusted in the future?
 

gamesquest1

Nabnut
Former Staff
Joined
Sep 23, 2013
Messages
15,153
Trophies
2
XP
12,237
I think if they wanted to brick every clone user they would of just used a specific date or a certain amount of boots to trigger the brick code, from what I have heard it was fairly low odds but still not the kinda think they should be messing about with, atleast now the experienced devs will know what to look for in future updates to see if the bricking code is present, from what I have read their was 2 triggers that are known, one for failing integrity check and another based on date modified or something, obviously one of them wasn't as bug free as they thought, resulting in gateway users getting bricked too, who knows there may be other checks but I would guess the date code would be the likely culprit for genuine launcher bricks. Personally I don't think there was any need for locking the eMMC, just wiping it is still nasty but it would of achieved the same goal without making the restore so difficult without having to buy even more hardware to fix it or sending it off to be repaired.

Needless to say gateway will of had a knock in faith from their own users with this whole drama, but I don't think they are past redeeming themselves, it was very small numbers in the grand scheme of things, and a repair method has been found, so there will only be a few people who didn't follow the tutorials and decided they didn't need a nand dump that will be left unable to restore at this point
 

Commoner

Well-Known Member
Member
Joined
Dec 21, 2013
Messages
101
Trophies
0
Age
49
XP
130
Country
Unfortunately (For Gateway and the unintended victims) there is compelling anecdotal evidence that Gateway's 'clone user killer' has killed several of their own users as well. I suspect for many people, especially the more informed users, the message Gateway has sent is that users should be highly skeptical of the safety of any any future Gateway launcher releases. Sure there will be some who will instantly forgive and forget when (if) multi-rom comes out but I guess they will serve as useful guinea pigs.

The scary part about this whole fiasco is that Gateway could have coded a launcher that bricked EVERY users 3ds with almost complete impunity. Nobody knows who or where they are and if they decide that bricking everyone's console is justified then what is going to stop them from doing so?

How can they ever really be trusted in the future?

I personally do not believe that there is any definite proof that any code was placed in the Gateway Software that was intended for bricking consoles.

Regardless, assuming you are convinced that said proof has been found, please keep in mind that it was located by basically amateur homebrew hackers within a day of the bricks being reported.

Now take into consideration that any hacker worth his salt will tell you that by far the hardest part of hacking compiled code is finding the segment containing the instructions you wish to remove. Altering the binaries to disable the code is trivial in comparison.

If someone had the ability to locate the instruction set that bricks the 3ds when certain conditions are met within a day of the reports, he should have no trouble at all disabling that code within a few minutes by editing any one of the conditional checks to always return FALSE.

Now consider that to this date, none of the clone companies have been able to release a solution despite their claims that they have a dedicated team of professionals developing the software for their product. And instead of releasing a fix, they have had to resort to advising their customers to download a roll back in firmware which has been poorly disguised as an upgrade.

If you truly believe that multiple homebrew amateur coders have found definite proof of the intentional malicious brick code in Gateways's launcher.dat by locating the exact code, then it only stands to reason that the clone cart teams of software developers are either non-existent or so incompetent or so apathetic about fixing the issue, that they might as well be a bunch of monkeys banging away at a keyboard.

Whatever the case may be, given this scenario, the simple conclusion is that the clone cart users can not rely on the teams behind their clone carts to protect them from any malicious intent Gateway may fancy to inflict upon clone users in future updates.

In such a scenario, what would you rather trust and use? The Gateway Cart an it's team which have been proven more than competent if a bit ethically questionable or the clone carts whose teams have proven to be unable to fix in a month what amateur coders would have been able to do within a day if they so chose to.

Would you rather be safe behind the canons that may on rare occasion accidentally misfire or directly under the sights of those canons, cowering behind the paper facade of empty promises made by the clone manufacturers to protect their valued customers.
 

Claw919

Member
Newcomer
Joined
Dec 10, 2013
Messages
22
Trophies
0
Age
47
XP
104
Country
Canada
I've often wondered what the point was of the brick code if they could just update the FPGA and call it a day.

I mean, the two don't really add up, right? Why go to the trouble of putting brick code in there, when you can just put a token bit of code on the FPGA, check for that, and suddenly all clones are shut out of the updating game? Particularly if your plan / need all along was to update the FPGA to introduce the multi-rom code. That would be a differentiating factor between you and the clones, and you'd just evolve while they stagnated.

I have absolutely no reference for this, and people smarter than me have already pointed to some pretty good reasons why we might think that the clones can't update the way the Gateway cards can, but I imagine the GW team knows that the clones *can*, actually, update the FPGA somehow without needing everyone to shell out for a $20 adapter.

Time will tell. We were supposed to see multi-rom from GW back in Dec (before Christmas, then just after Christmas, before New Year's), then the first days of Jan, now potentially the end of January. Even allowing for normal software development time slips, you have to have a pretty significant setback to go from "a few days out" to well over a month of delays. We're either looking at a problem introducing the functionality, or a renewed focus on anti-clone code. My take, anyway.
 

Ratman9977

Member
Newcomer
Joined
Jan 27, 2014
Messages
10
Trophies
0
XP
86
Country
United States
Gateway can't update the FPGA at all -- it's impossible without a JTAG debugger, which the nintendo 3ds is not. The best they could do -- is if they used a softcore with an external rom containing the code -- is to update that via SPI. In that case, the clones would be able to perform the same action.
 

spinner09

Well-Known Member
OP
Member
Joined
Nov 11, 2013
Messages
140
Trophies
0
Age
46
XP
172
Country
United States
JSON took a lot of time to explain why the clones can't update FGPA, the thread is here:
http://gbatemp.net/threads/3ds-flashcart-clones´s-firmwares.359405/#post-4870962

Well, this is pretty damning. Isn't there any other way to update the FPGA, other than the JTAG inputs? Isn't there some sort of hack/trick to do it (like soldering some wires around the back)? Does GW 2.0 really need an update to continue working, or are they only forcing in the code to kill the clones?
 

Ratman9977

Member
Newcomer
Joined
Jan 27, 2014
Messages
10
Trophies
0
XP
86
Country
United States
Well, this is pretty damning. Isn't there any other way to update the FPGA, other than the JTAG inputs? Isn't there some sort of hack/trick to do it (like soldering some wires around the back)? Does GW 2.0 really need an update to continue working, or are they only forcing in the code to kill the clones?


Gateway can only use those JTAG inputs with an external tool to program the FPGA. The 3DS itself is not a JTAG programmer, therefore the FPGA design cannot be updated on either the Gateway or clones from the 3DS itself.
 

Duo8

Well-Known Member
Member
Joined
Jul 16, 2013
Messages
3,613
Trophies
2
XP
3,008
Country
Vietnam
I've often wondered what the point was of the brick code if they could just update the FPGA and call it a day.

I mean, the two don't really add up, right? Why go to the trouble of putting brick code in there, when you can just put a token bit of code on the FPGA, check for that, and suddenly all clones are shut out of the updating game? Particularly if your plan / need all along was to update the FPGA to introduce the multi-rom code. That would be a differentiating factor between you and the clones, and you'd just evolve while they stagnated.

I have absolutely no reference for this, and people smarter than me have already pointed to some pretty good reasons why we might think that the clones can't update the way the Gateway cards can, but I imagine the GW team knows that the clones *can*, actually, update the FPGA somehow without needing everyone to shell out for a $20 adapter.

Time will tell. We were supposed to see multi-rom from GW back in Dec (before Christmas, then just after Christmas, before New Year's), then the first days of Jan, now potentially the end of January. Even allowing for normal software development time slips, you have to have a pretty significant setback to go from "a few days out" to well over a month of delays. We're either looking at a problem introducing the functionality, or a renewed focus on anti-clone code. My take, anyway.

Because some clone users can live without Multi-ROM. They don't just want to keep clone users out of updates, they want them to be completely unable to use their clone, even if that means bricking their console.
 

spinner09

Well-Known Member
OP
Member
Joined
Nov 11, 2013
Messages
140
Trophies
0
Age
46
XP
172
Country
United States
Gateway can only use those JTAG inputs with an external tool to program the FPGA. The 3DS itself is not a JTAG programmer, therefore the FPGA design cannot be updated on either the Gateway or clones from the 3DS itself.

Correct me if I'm wrong, but can't the 3DS be any type of tool it needs to be, since you have root access to the device (on 4.1-4.5)? The modders could execute any type of code they want, and even turn the 3DS itself into a JTAG programmer if they coded the correct program for it? And if GW knew from the start that the 3DS itself wasn't a JTAG programmer (and could never update the FPGA, as you suggest), why did they go to the trouble of hooking up the JTAG pins to the SLOT1 pins? They were anticipating a future update all along.
Also, if you check the Gateway 3DS website, they mention that the upcoming firmware is a FPGA update. Are they lying?
 

Ratman9977

Member
Newcomer
Joined
Jan 27, 2014
Messages
10
Trophies
0
XP
86
Country
United States
Correct me if I'm wrong, but can't the 3DS be any type of tool it needs to be, since you have root access to the device (on 4.1-4.5)? The modders could execute any type of code they want, and even turn the 3DS itself into a JTAG programmer if they coded the correct program for it? And if GW knew from the start that the 3DS itself wasn't a JTAG programmer (and could never update the FPGA, as you suggest), why did they go to the trouble of hooking up the JTAG pins to the SLOT1 pins? They were anticipating a future update all along.
Also, if you check the Gateway 3DS website, they mention that the upcoming firmware is a FPGA update. Are they lying?


Gateway likely has a 3DS Cart to JTAG adapter they use for debugging/prototyping. The 3DS isn't designed to be a JTAG programmer for Actel devices. When I program Xilinx FPGAs, I use a Xilinx JTAG tool. When I program Altera FPGAs, I use an Altera JTAG tool. You'd use a similar tool for Actel devices.

If they used a soft-core processor with an external program rom, they can update the code in that program rom which would allow for new features. That's what I assume they mean when they mention updating the FPGA.
 

spinner09

Well-Known Member
OP
Member
Joined
Nov 11, 2013
Messages
140
Trophies
0
Age
46
XP
172
Country
United States
Gateway likely has a 3DS Cart to JTAG adapter they use for debugging/prototyping. The 3DS isn't designed to be a JTAG programmer for Actel devices. When I program Xilinx FPGAs, I use a Xilinx JTAG tool. When I program Altera FPGAs, I use an Altera JTAG tool. You'd use a similar tool for Actel devices.

If they used a soft-core processor with an external program rom, they can update the code in that program rom which would allow for new features. That's what I assume they mean when they mention updating the FPGA.

Okay, thanks for the response.
What does "updating the code in that program rom" entail? Just a simple launcher, or blue-cart update? Could it be done with the clones as well, even though they have no JTAG contacts?
And, what about the people earlier in this thread who used the DSTWO as an example of a DS flashcart with an updatable FPGA? How was that cart able to update itself if DS/3DS consoles can't do JTAG programming?
 

Mr_Pichu

かわいいね!
Member
Joined
Dec 10, 2013
Messages
170
Trophies
0
XP
133
Country
United States
one reason I can think for not connecting the pins the same as GW cards. is maybe if they had the GW team could detect the clone and either temporarily or permanently brick the cart rather than the console.
Knowing GW's track record, they would brick, so that is certainly a good reason why the clones might differ in design. Of course they could have just put in a jumper that could enable and disable the update feature in that case.
if the 2.0 code does only work on the GW card then why do the whole brickgate fiasco? they could have just waited until they released multirom and go na na nan na na. if the 3ds cart market is that tight they have to wreck consoles to keep ahead of the clones things must be bad.
This a real good question, I think GW didn't like being cloned down to the software. After all the GW's design and code can run the vast majority of 3DS titles. so I am sure the clones really cut into GW's bottom line. We have heard there was quite a bit of bricking in China.
 

ground

Well-Known Member
Member
Joined
Mar 22, 2007
Messages
907
Trophies
0
XP
572
Country
Netherlands
Knowing GW's track record, they would brick, so that is certainly a good reason why the clones might differ in design. Of course they could have just put in a jumper that could enable and disable the update feature in that case.

This a real good question, I think GW didn't like being cloned down to the software. After all the GW's design and code can run the vast majority of 3DS titles. so I am sure the clones really cut into GW's bottom line. We have heard there was quite a bit of bricking in China.
or it was kind of the update prevention which they were working on, and they left some code inside or something (guess we will never know )
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    S @ salazarcosplay: @Sicklyboy I was reading your post on the lgbtq batman