- Joined
- Jul 7, 2010
- Messages
- 3,964
- Trophies
- 2
- Location
- /dev/random
- Website
- www.gudenau.net
- XP
- 6,049
- Country
Hehe... some days ago I thought _they_ ( GateWay themselves ) could possibly ( probably ) do that themselves with a FPGA update.
1. The GW cartridge starts in OOT or CN clone mode; that is, it acts as an original CN or OOT game cartridge ( including the gateway exploit fitted in its savegame slots ) and you can load it.
2. The FPGA in the GW cartridge waits for some "magic" request ( which could be any trigger like asking for an specific sector a given times in a row or something more hardcore like using some developer specific functionality... ).
3. When this "magic" trigger arrives, it simulates a cartridge swap and enters normal GW cartridge mode ( the mode we have all been seeing till now ).
Problems with this:
- Big issue or practical issue: the need for a way to update the cartridge FPGA. It would require an already exploited scenario ( old 3ds, original OOT or CN in new 3ds,... ). But, maaaybe, they already included a secret way of updating the FPGA by direct microSD read when the cartridge is inserted in any 3ds and just prowered on ( I mean, like in lots of devices, you put a "update.bin" in the microSD and it always checks for that file just after booting and being powered by the 3ds ).
- Legal issue and not that big: legal issue of including the original OOT or CN cartridge content ( maybe saveable by reading the rom file from the microSD card as it is done now for the backups. Maybe name it STARTUP.3DS or put it in another parition in the microSD or... whatever )
Does all this make sense guys/gals ?
I doubt this is possible.
Do you think that if it was possible gateway wouldn't have done it this way instead of releasing an exploit that requires additional hardware even if they said that there won't be any need of additional hardware?
Why not?
Do you think that if it was possible gateway wouldn't have done it this way instead of releasing an exploit that requires additional hardware even if they said that there won't be any need of additional hardware?
because i doubt the gateway card has all the required bits n bobs to imitate a retail cart.
If it did, they'd probably have just been a sky instead of having all the emunand and what not from the start.
i was originally thinking they would go for something like this....im thinking this is what the huge delay was probably for (looking into it time), im sure they would of at least looked into the possibility, might just be that its not wired up in a way that can function as a retail cart....could also be that its going to take a while to get it ready and this is their cartless solution plan, but its taking longer than expected to get it all set up
jimskeet2002:
Do you think that if it was possible gateway wouldn't have done it this way instead of releasing an exploit that requires additional hardware even if they said that there won't be any need of additional hardware?
nollog:
because i doubt the gateway card has all the required bits n bobs to imitate a retail cart.
If it did, they'd probably have just been a sky instead of having all the emunand and what not from the start.
For me it would still be the logical step, I mean, they are working in something like this but, meanwhile and by now they give us the possibility to launch the GW mode by using a real OOT or CN cart. They keep working on having the GW cart simulate a real OOT or CN in the future but this step they have ( OOT and CN based exploit launching ) is needed. It is like a first milestone in their roadmap, the second milestone is getting rid of an original OOT or CN by adding the initial boot mode for their GW cart, the mode where the cart does raw reading of an OOT or CN rom from the microSD. There's that milestone 0 though, which they should have implemented in some previous firmware and the one that new GW carts should be shipping with from some time ago, the autonomous ( read: that does not require an exploit scenario ) update system where the cart detects, reads and applies an FPGA update from the microSD.
EDIT: It would make a lot of sense that they actually have that initial milestone 0 in place. For mass producing GW carts, it may be easier to have an autonomous update system than using some other method like SPI or something...
I don't see this being a reason, for them this "simulate initial original cart" mode is only a necessary step for their stuff afterwards. Also, I don't know the technical requirements and the limitations of their FPGA, but an IP for reading FAT32/exFAT seems way more complex and resource ( as in logic gates needed ) hungry than the 3ds cartridge protocol. I am speculating here and I may be wrong if there's cartridge-side crypto or others, but I doubt so.
We have no idea why gateway does what it does but the fact is, there's a chip in the gw card that can be programmed to do the same thing a sky3ds can (minus the physical button). Gateway can theoretically be programmed to operate in two modes.
Yes fat32 eould be worse than raw io, but not by to much. Then of course the 3ds files that get dumped are still encrypted.
The FPGA update process. Look it up. ;-)
Yep, this is how it used to work.This implies that the actual GW Red card can be flashed to give the exact same function the Sky3DS cart has. Nothing else needed/no changes to any of the card whatsoever?
The FPGA update process. Look it up. ;-)
I feel that may not be possable... But you should have the retail cart in the first place.That milestone 0 I spoke about, the autonomous update process, would require file reading from the microSD ( which they already have for normal rom loading ) and working on its own. Maybe blinking the led while flashing and turning it on or off when finished, or changing color...