Has the Nintendo 3DS been hacked?

  • Thread starter Thread starter Costello
  • Start date Start date
  • Views Views 98,653
  • Replies Replies 332
  • Likes Likes 17
This may mean a lot of things but not neccessarily a full hack. It may just be a POC of some sort that won't be useful to end users in a while. Still interesting and I look forward to the day I won't need to carry around a box with all my 3DS games.

Back when I didn't have my 3DS updated, it disallowed me to play Mario Kart online as I had to update the system.
(A long while back, may have changed since then)
That might be because of the 1.1 update fixing serious glitches in a couple levels. Other than that I don't think that has been required for any game.
 
  • Like
Reactions: nukeboy95
only 1 pic will not say it is hacked
for now i don`t trust is.it could be fake(hope not)
it only give ppl false hope
I disagree, Yellows8 has been in the Nintendo hacking scene forever and many people like me think that he wouldn't ruin his reputation. I'm assuming you think it's too good to be true.
 
pRwkh.png

iirc that for the buff overflow exploit to start running the code
I apologize for double posting but can you translate this into English?
 
I apologize for double posting but can you translate this into English?
It's a register, an ID number under which you can find the Run function, which has two arguments - KProcess, which is of type Handle (no idea what that is, but judging from the "Handle" type I'm going to guess it's some kind of a system process or something CPU-related. In any case, it's some kind of a system object) and *buf of type unsigned int, which is a pointer (signified by the *) to a place in memory, it's supposed to direct you to the main() thread, which is the main function of any program. Treat it like a computer science equivalent of a house address - that's where your function is stored.

hex is kinda like code
Hex are just numbers in the hexadecimal positional number system.

Any clarification you could offer on the KProcess object, SifJar?
 
Any clarification you could offer on the KProcess object, SifJar?
Not really. I don't know much about it.

If I had to guess, I'd say a KProcess is a Kernel Process i.e. a piece of kernel code. I'd have to do some reading to verify that or know anymore.
 
Not really. I don't know much about it.

If I had to guess, I'd say a KProcess is a Kernel Process i.e. a piece of kernel code. I'd have to do some reading to verify that or know anymore.
Sounds plausible given the "K" in the name, yeah.
 
Also, the fact that it requires the Handle of a KProcess suggests that parameter is a reference to an already loaded KProcess (not a new one). A "handle" is a reference to a piece of code (or other resource) loaded in memory. From Wikipedia:

In computer programming, a handle is an abstract reference to a resource. Handles are used when application software references blocks of memory or objects managed by another system, such as a database or an operating system.

In other words, when a KProcess is first loaded, the kernel will assign it a "handle". This "handle" allows other piece of code to refer to that KProcess.
 
Also, the fact that it requires the Handle of a KProcess suggests that parameter is a reference to an already loaded KProcess (not a new one). A "handle" is a reference to a piece of code (or other resource) loaded in memory.
Pretty much what I wanted to say, but dressed up in more clear wording. :P
 
cpus in asm "os environment" tend to work under "threads", this could be an instance of code running in -A- buffer,reg,etc , while, at the same time another piece of code would be running somewhere in -B- buffer,reg,etc.

Every thread has a "thread priority", without it, the CPU wouldn't know which one to start with, and it would basically take up physical area it shouldn't and cause kernel panic if another instance takes up that very physical area. In fact a TLB-of-some-sort is required to store such data in some scenarios

also, you wouldn't be able to create sub-threads tied to a main thread.
 
To be clear and build upon what everyone else has said, (I'll try to keep this simple and not write a book in this post)

What's on that page are system calls. Most programs run with the processor in user mode and there's just some things that they're not allowed to do so it runs a system call to ask the OS to do it for it and the processor temporarily switches to supervisor mode and follows the instructions of the OS (OS means operating system. Windows, for example, is an operating system.). The first 256 bytes (up to 0xFF) of memory store addresses for the starting instruction of each these system calls (The little number at the beginning of each on that list .. in this case 0x12) so the processor knows where to look to start one when a program asks for one. The stuff in parenthesis after the system call's name on that list is information that the program has to leave behind for the system call to know what to do. In this case it wants to get another process running so it has to tell it which process (the handle called KProcess) and a place in memory where some more information is stored about it (unsigned int *buf). Right at that place in memory (buf+0) there's a number telling it what the process's priority is and four memory locations later (buf+4) is a number telling how big the stack for that process is. (the stack is where most of the information is kept that a program keeps track of while it's running.)
 

Site & Scene News

Popular threads in this forum