Hacking Gateway Files succesfully Decrypted

[DSoryu]

its using teh "mset hack" on teh 3DS which is documented on 3DS Brew

maybe you should check there site as its on there front page about the homebrew loader



just dont update any more ;D
id stay on 6.2.0 at least as nintendo will now most likely remove the "mset hack" with the next update

Yep, unless there is something major like miiverse, or maybe the homebrew would make possible to install chanels like on the Wii? Only firm spoff needed... well I think I'am dreaming a lot right there

 

[Foxi4]

*Snip!*

There's no such thing as a "Homebrew Loader" ready yet - the Gateway is capable of pulling off kernel mode by putting an incredibly tiny piece of ARM11 code into the DS/DSi shared section of memory where the settings are stored alongside some random junk to overflow the stack, then once the stack is smashed, the system performs a jump and executes the code in 3DS Mode as if nothing ever happened.

http://gbatemp.net/threads/heres-what-we-know-about-how-gateway-works.352812/

Don't get me wrong - it's kernel mode alright, but it's not a "Homebrew Loader" or anything even remotely close to it - you don't have nearly enough memory to actually make a normal application. For all intents and purposes, you can't even make a "Homebrew Loader" just yet - there are some extra hurdles to jump over.

 

[Pong20302000]

Pong talking out of his butthole as per usual.

There's no such thing as a "Homebrew Loader" ready yet - the Gateway is capable of pulling off kernel mode by putting an incredibly tiny piece of ARM11 code into the DS/DSi shared section of memory where the settings are stored alongside some random junk to overflow the stack, then once the stack is smashed, the system performs a jump and executes the code in 3DS Mode as if nothing ever happened.

http://gbatemp.net/threads/heres-what-we-know-about-how-gateway-works.352812/

Don't get me wrong - it's kernel mode alright, but it's not a "Homebrew Loader" or anything even remotely close to it - you don't have nearly enough memory to actually make a normal application. For all intents and purposes, you can't even make a "Homebrew Loader" just yet - there are some extra hurdles to jump over.

im just passing on what the team say about the homebrew loader

also yesterday in IRC they confirmed Homebrew is possible on 6.X Firmware

[14:34] crediar well doesn't the ds setting exploit still work in the latest version?
[14:34] blasty yes
[14:34] blasty you can run homebrew *right now* on your 6.x consoles
[14:34] brassica oh, so you mean there is hope
[14:34] blasty I don't know what people are waiting for actually
[14:35] signz [21:34:33] <@blasty> you can run homebrew *right now* on your 6.x consoles < just no 3DS mode homebrew, right
[14:35] crediar so what's the holdup just patch the region check then
[14:35] blasty signz: 3ds mode homebrew.
[14:35] bdmon whats the difference between DS and 3DS homebrew anyway ?
[14:35] blasty bootstrap your NVRAM with the exploit, write a ROP payload, off you go.
[14:35] crediar off you go!

 

[Foxi4]

im just passing on what the team say about the homebrew loader

also yesterday in IRC they confirmed Homebrew is possible on 6.X Firmware

Provided the people you spoke to have ways to jump over encryption, signature checks and XN - sure. I'd love to see that though. As long as the "Gateway Loader" supports that with its limited amount of memory, it technically could be done, but I have trouble believing that it'd be as simple as "can be done right now" - there's a lot of stuff that has to be "faked" to cheat the system into thinking that the code is fine to execute. I also don't understand where you inferred the "Homebrew Loader" from, I'm not seeing any "Loader" talk in this conversation, just the word "Homebrew". When I see "Loader" I think of a particular piece of software that handles it, "Homebrew" just means custom code. Miscommunication etc.

 

[KazoWAR]

I heard you like custom code, so i made some custom code to load your custom code.

 

[thatsit]

Provided the people you spoke to have ways to jump over encryption, signature checks and XN - sure. I'd love to see that though. As long as the "Gateway Loader" supports that with its limited amount of memory, it technically could be done, but I have trouble believing that it'd be as simple as "can be done right now" - there's a lot of stuff that has to be "faked" to cheat the system into thinking that the code is fine to execute. I also don't understand where you inferred the "Homebrew Loader" from, I'm not seeing any "Loader" talk in this conversation, just the word "Homebrew". When I see "Loader" I think of a particular piece of software that handles it, "Homebrew" just means custom code. Miscommunication etc.

I'm curious as to why you keep saying that the GW has access to an extremely limited amount of memory; where did you get that from? If it has kernel access and can load custom code why wouldn't they be able to load homebrew?

Also, in the post you previously linked that you seem to be getting all of your information from he says that extensive homebrew is possible in the last paragraph...

 

[Foxi4]

I'm curious as to why you keep saying that the GW has extremely limited memory; where did you get that from? If it has kernel access and can load custom code why wouldn't they be able to load homebrew?

The initial code has to fit within the DS/DSi Mode's NVRAM - that's where the GW loader is loaded and executed from - that's the bottleneck. Custom code from other sources would have to be a valid 3DS binary, aka it'd need to be encrypted and signed unless they found a work-around for that (as I mentioned earlier).

Also, in the post you previously linked that you seem to be getting all of your information from he says that extensive homebrew is possible in the last paragraph...

Define extensive. The system isn't even 100% mapped yet and we're talking about a Homebrew Loader along the lines of the Wii's Homebrew Channel? C'mon.

 

[shakirmoledina]

wow the hype

 

[thatsit]

The initial code has to fit within the DS/DSi Mode's NVRAM - that's where the GW loader is loaded and executed from - that's the bottleneck.

But that isn't even code; it's a ROP chain. It's not executable and homebrew would be quite limited if you had to write it all in ROP. The profile memory is simply a means to gain kernel access.

Custom code from other sources would have to be a valid 3DS binary, aka it'd need to be encrypted and signed unless they found a work-around for that (as I mentioned earlier).

Fine, it's theoretically possible to load homebrew under kernel access. But neither of us can say whether or not they have the ability to load unsigned code. Although they should be able to, at least eventually.

Define extensive. The system isn't even 100% mapped yet and we're talking about a Homebrew Loader along the lines of the Wii's Homebrew Channel? C'mon.

you don't have nearly enough memory to actually make a normal application.

There's a slight difference between a fully functional homebrew channel and loading a single homebrew application.

 

[Foxi4]

But that isn't even code; it's a ROP chain. It's not executable and homebrew would be quite limited if you had to write it all in ROP. The profile memory is simply a means to gain kernel access.

At this point in time, only ROP programming can be used as the chunks of code are recognized as valid (they were "previously checked" so to speak) - the Gateway isn't capable of loading any unsigned code with its launcher. Due to the nature of the exploit used, said code has to be contained within NVRAM. There are other exploits which allow for executing from the SD card as far as I remember but they're not usable for the Gateway.

ROP or not, it's still execution of custom code with the difference that chunks of said code are borrowed from an already loaded binary - I'd say it still counts as "Homebrew".

Fine, it's theoretically possible to load homebrew under kernel access. But neither of us can say whether or not they have the ability to load unsigned code. Although they should be able to, at least eventually.

It's theoretically possible provided the loader will be able to fool the signature and encryption checks of the OS as well as XN of the ARM itself, which is why I find it debatable that it could be done already.

There's a slight difference between a fully functional homebrew channel and loading a single homebrew application.

That's not useful for the average user though, and the way it was said in the conversation implied that it could be. The best we can count on would be a HEN-like solution (not the underlying mechanism of it, just the extent of the functionality). When I'm thinking "Loader", I'm thinking of a user-friendly app with a GUI, not merely a "booter".

Let me clarify. I said what I said because some users may infer that we're on the brink of coding 3DS Mode homebrew just because GW3DS is out. We're not - the GW3DS will not allow us to launch Homebrew anytime soon, that's what I wanted to make clear and I'm only stressing it so much to avoid further questions and a quadrillion of threads related to it. We're getting there ever so slowly, but with the assets available to common, everyday users we're still not able to launch homebrew.

 

[thatsit]

At this point in time, only ROP programming can be used as the chunks of code are recognized as valid (they were "previously checked" so to speak) - the Gateway isn't capable of loading any unsigned code with its launcher. Due to the nature of the exploit used, said code has to be contained within NVRAM. There are other exploits which allow for executing from the SD card as far as I remember but they're not usable for the Gateway.

ROP or not, it's still execution of custom code with the difference that chunks of said code are borrowed from an already loaded binary - I'd say it still counts as "Homebrew".

Well if you're actually considering ROP code homebrew then there still isn't a limit on the amount of memory to write it in. Launcher.dat contains a hell of a lot more ROP commands than what's in the profile and even then most of it is apparently obfuscated. Since ROP isn't executed you can load as much of it as you want.

It's theoretically possible provided the loader will be able to fool the signature and encryption checks of the OS as well as XN of the ARM itself, which is why I find it debatable that it could be done already.

Or you could just disable the signature checks.

That's not useful for the average user though, and the way it was said in the conversation implied that it could be. The best we can count on would be a HEN-like solution (not the underlying mechanism of it, just the extent of the functionality). When I'm thinking "Loader", I'm thinking of a user-friendly app with a GUI, not merely a "booter".

Well they're really just the same thing. If you can boot a program, you can write and boot a gui to do the same thing.

Let me clarify. I said what I said because some users may infer that we're on the brink of coding 3DS Mode homebrew just because GW3DS is out. We're not - the GW3DS will not allow us to launch Homebrew anytime soon, that's what I wanted to make clear and I'm only stressing it so much to avoid further questions and a quadrillion of threads related to it. We're getting there ever so slowly, but with the assets available to common, everyday users we're still not able to launch homebrew.

Well we don't really have any idea what it can and can't do so we probably shouldn't speculate.

 

[Tattorack]

indeed, could kill off the Gateway, and shut down the 3DS scene
great news
considering they havnt released the Region Free or Firmware Spoofing code

Well... with the meat and bones of the gateway card in the open of sorts wouldn't that pull together differant people all with differant ideas on using/developing it?
Sure, ONE card using ONE way and just ONE line of developement could get easily blocked... but if more people start cloning and/or making slight differances to the original wouldn't it make it harder to block all of them?

 

[Foxi4]

Well if you're actually considering ROP code homebrew then there still isn't a limit on the amount of memory to write it in. Launcher.dat contains a hell of a lot more ROP commands than what's in the profile and even then most of it is apparently obfuscated. Since ROP isn't executed you can load as much of it as you want.

That's the thing - you can't. Everything that's to be executed has to be located in the profile area of NVRAM, that's why the loader itself would have to be as tiny as possible. It's the same deal with Dios-Mios - it doesn't support NTFS not because it's awkward to code but because the code has to be confined to a tiny amount of memory located in a very specific place. I may be wrong on this, but judging from what I've read, I don't think I am.

Or you could just disable the signature checks.

We're heading dangerously in the direction of Custom Firmware Chit-chat territory. It's not as simple as flicking a switch, so let's not make it sound like it is.

Well we don't really have any idea what it can and can't do so we probably shouldn't speculate.

Very true, I'm merely stating how things are at this particular moment in time, who knows what the future holds?

 

[thatsit]

That's the thing - you can't. Everything that's to be executed has to be located in the profile area of NVRAM, that's why the loader itself would have to be as tiny as possible. It's the same deal with Dios-Mios - it doesn't support NTFS not because it's awkward to code but because the code has to be confined to a tiny amount of memory located in a very specific place. I may be wrong on this, but judging from what I've read, I don't think I am.

If it can load a file (Launcher.dat) into memory, why is it unreasonable to believe that it could load even more? Even if it was restricted to a specific portion of memory (why can't it just put it on the heap, again?) it could simply continue to write over itself till it was done.

We're heading dangerously in the direction of Custom Firmware Chit-chat territory. It's not as simple as flicking a switch, so let's not make it sound like it is.

fair enough

 

[Arras]

That's the thing - you can't. Everything that's to be executed has to be located in the profile area of NVRAM, that's why the loader itself would have to be as tiny as possible. It's the same deal with Dios-Mios - it doesn't support NTFS not because it's awkward to code but because the code has to be confined to a tiny amount of memory located in a very specific place. I may be wrong on this, but judging from what I've read, I don't think I am.

We're heading dangerously in the direction of Custom Firmware Chit-chat territory. It's not as simple as flicking a switch, so let's not make it sound like it is.


Very true, I'm merely stating how things are at this particular moment in time, who knows what the future holds?

Of course the initial thing has to be small as it has to fit within the DS settings, but I thought Launcher.dat can be any size and it will execute it? Besides, to someone who knows what he is doing, 1MB of ROP calls can probably accomplish a whole lot (at least, I thought launcher.dat was 1MB?)

 

[Foxi4]

If it can load a file (Launcher.dat) into memory, why is it unreasonable to believe that it could load even more? Even if it was restricted to a specific portion of memory (why can't it just put it on the heap, again?) it could simply continue to write over itself till it was done.

Of course the initial thing has to be small as it has to fit within the DS settings, but I thought Launcher.dat can be any size and it will execute it? Besides, to someone who knows what he is doing, 1MB of ROP calls can probably accomplish a whole lot (at least, I thought launcher.dat was 1MB?)

I suppose you are both right, it does seem like a considerable amount of wiggle room.

 

[the_randomizer]

Let's just all agree that there's no definitive answers to our guesses right now and that whatever happens, happens. We don't know how they're going to pull this off, much less homebrew.

 

[bytor]

This is great news for several reasons:

1) It means that there are more people working on getting a cart like this to work on other firmwares
2) It means that bigger players in the industry (such as the guys that do the DSTWO) are going to produce competing carts - competition is a very good thing
3) It means cheaper carts are going to be available

I'm jumping right on the DSTHREE as soon as it becomes available.

 

[the_randomizer]

And that's a good way to look at it; since it's out in the open, more people will be able to work on it, and a working exploit will be more feasible, but it will take a while before it comes to fruition. Still, this also opens up a chance for a homebrew ecosystem to be created, and at long last, we can finally have emulators on the 3DS...among other things At first, yes, I'd be lying if I said I wasn't upset, but, after doing some thinking, I've learned to accept it as it is, as it will only help hacking in the long run.

 

[SolidSnake95]

Maybe I should spend my refund on this gateway when it can play on 6.x firmwares. I'm a firm supporter of 3DS as I already own 5 games(one digital) but I still wouldn't mind playing games for free that don't deserve to have a high cost like OoT 3D, which is just 6 dollars cheaper then what it was when they re-released it 2 years ago -_-