Just a question on code, im debugging your launcher.dat with my emu and I find the swi 0x7b, what does it do?
Has anyone been running into stability problems for payloads >=16KB?
My code will only work about 1/2 the time if it's larger than 16KB.
Why the mystery ? show him the way
Mystery ? i called the friggin function sudo, everyone and their mother should know what it does.
Why the mystery ? show him the way
sorry, I have no idea
Just a question on code, im debugging your launcher.dat with my emu and I find the swi 0x7b, what does it do?
Here is a NOT SO SUBTLE clue
undocumented on 3dbrew ( by the_powers_that_be )
http://3dbrew.org/wiki/SVC
static inline void sudo(void *addr)
{
register void *_r0 asm ("r0") = addr;
asm volatile ( "SVC 0x7B" : : "r"(_r0) );
}
http://lmgtfy.com/?q="swi"+"svc"+"arm"
Mystery ? i called the friggin function sudo, everyone and their mother should know what it does.
Mystery ? i called the friggin function sudo, everyone and their mother should know what it does.
[/spoiler]Let me try and have another shot at my response. I was going to ignore the following post
but seagal112 right after that (the very next post) confused me.
I thought I had been clear-ish.
originally,
My re-edited response with Kane49 's comment
I would like to say publicly that Kane49 was the source of the code but since I wasn't sure if he was the original author and didn't know if he would want the attribution(or perhaps unwanted attention) and I didn't credit him like I should have.
btw Kane49 did you ever have a chance to examine the code tied to SVC 0x7A ?
DisableExecuteNever(unsigned int Addr, unsigned int Size) (Stubbed for regular kernel beginning with 2.0.0-2)
It looks like it might be interesting but I don't know - never seen it.
Could one not extract the original code, pre-stub, and replace the stub in a new firmware loaded through NAND redirection to test this function's actual intended result?supervisor call 0x7A does nothing but return a fatal error, not implemented, not supported result code.
supervisor call 0x7A does nothing but return a fatal error, not implemented, not supported result code.
Could one not extract the original code, pre-stub, and replace the stub in a new firmware loaded through NAND redirection to test this function's actual intended result?
btw Kane49 did you ever have a chance to examine the code tied to SVC 0x7A ?
DisableExecuteNever(unsigned int Addr, unsigned int Size) (Stubbed for regular kernel beginning with 2.0.0-2)
It looks like it might be interesting but I don't know - never seen it.
No actually, everyone is left guessing. Does the 3DS has a superuser and and an environment with user privileges? Is there a subset of sys calls that require elevated privileges? The function name only vaguely alludes to something, doesn't actually explain anything.
Really amazing! Will you share the source code?Hi!
Its time for another little demo of gb emulation.
This time I'm using heig-boy code instead of giibii, the result is a more faster emulator , and 512 ks roms working
Tried zelda and works ok, but of course: no saving, no fun.
Here is an example for download, with free game : Hungry are the dead. It really worth the play, but better on a real gbc or a gbc color emu
https://dl.dropboxusercontent.com/u/72398546/3dsgbemu_hungryarethedead.rar
And this is the game included
http://pdroms.de/files/gameboy/hungry-are-the-dead-31-10-2000
Enjoy!
If you dont know the question its unlikely the answer will help you
Yeah thats a problem, the best way is to load a binary into memory during the rop chain and simply run that.
I have an example in the archive i posted, that includes a whole mini filesystem but changing that should be easy
But not even re-implementing the SVC 0x7A but analyzing what the original code looked like in 1.0.0-0 and 1.1.0-1 that was called by 0x7A .
And out of curiosity, has anyone tried NAND redirection to an older firmware? And does it work?
Though it works loading a binary into FCRAM and running it with the ARM9 processor is incredibly slow. I have a feeling the instruction cache wasn't designed to work when loading from FCRAM.
For now just using the internal fopen/fread I'm loading a larger ARM9 payload. 8090000-080FF000 should be a pretty safe region to use for what I'm doing.
SVC 0x7A was stubed starting with 2.0.0-2. Since this is a 4.X exploit we don't easily have dumps for older firmware data. It's possible to get them but there's not too much motivation to look at older code.
Firmware redirection to older firmwares should be possible but the hard part would be getting the old firmware in the first place setup correctly. I'm not sure why you'd want that though.