Hacking 3DS Hack: "We hacked it"

  • Thread starter Thread starter michael18
  • Start date Start date
  • Views Views 737,750
  • Replies Replies 2,186
  • Likes Likes 5
Status
Not open for further replies.
Finally something that might be true if this is true it would be the first step for Custom channels like the first 3DS HomeBrew Channel and many more custom channels.I don't want to die in excitement over nothing but only time will tell if this is true or false info.
 
Its not really anything we do "hacks" with just yet. Its only a couple of exploits... But im sure given time we might get somewhere.
 
  • Like
Reactions: eyecat14 and Qtis
I don't think I understand the whole "Why's Nintendo still using ARM!?" question - ARM is one of the best architectures for mobile platforms. As for the similarities with previous hardware, there are actually very little between the DS and the 3DS - you might as well argue that a 3DS is similar to an ARM-based tablet and you're going to be right in many ways. ARM isn't a bad processor choice, it's simple as that.
I just wish they would release the hack so people can make their own homebrew for it atleast ><
People wouldn't be able to make their homebrew even if the hack was released since very little 3DS registers are actually mapped - even the hackers themselves couldn't use the graphics service, so the average programmer wouldn't be able to either. We're at least a year ahead from any useful homebrew - first we need to get to know the hardware.
 
  • Like
Reactions: Qtis
I don't think I understand the whole "Why's Nintendo still using ARM!?" question - ARM is one of the best architectures for mobile platforms. As for the similarities with previous hardware, there are actually very little between the DS and the 3DS - you might as well argue that a 3DS is similar to an ARM-based tablet and you're going to be right in many ways. ARM isn't a bad processor choice, it's simple as that.

People wouldn't be able to make their homebrew even if the hack was released since very little 3DS registers are actually mapped - even the hackers themselves couldn't use the graphics service, so the average programmer wouldn't be able to either. We're at least a year ahead from any useful homebrew - first we need to get to know the hardware.

This is where the decapping comes into play, until there is a homebrew "SDK" so to speak, there is no way that most homebrew devs will be able to do anything.

Also as far as the ARM statement goes, I agree with Foxi4, ARM is absolutely awesome for power efficient computation. If you own a smartphone, you probably have an ARM based SOC in there (there is ONE line of SOCs based on the intel architecture, Medfield, but it isn't widely used). All iDevices have ARM SOCs, as do android tablets and windows phone devices too.

Off-topic, this is post 666 in this thread, this post is the devil
 
  • Like
Reactions: eyecat14
This is where the decapping comes into play, until there is a homebrew "SDK" so to speak, there is no way that most homebrew devs will be able to do anything.
neimod and yellows8 seem to be making some decent progress without decapping. I'm not actually sure if decapping would be extremely useful in this regard; I believe it would mainly give the bootloader etc., which probably doesn't have access to most hardware anyway. I'd guess the bootloader's main job is to load code from NAND (which won't be accessed by decapping), and then code from NAND would then have the code for accessing hardware.

(If you're familiar with the Wii, I'd imagine decapping would only really give boot0, which is basically a small stub to load boot1, which then loads boot2, which then loads IOS, which is what actually has access to all hardware. boot0 wouldn't contain the details required to access, say, video output, because it never needs to do that; IOS is loaded before any video output is shown - this information may be a bit inaccurate, I'm just guessing here, but I think it would be something like this).

On the other hand, decapping should probably give the keys for decrypting titles from the NAND, which could then be reverse engineered to figure out how to access various hardware.

Either way, it would probably be useful, but not necessarily essential/pivotal to 3DS homebrew.
 
I realized I made stupid mistake about the ARM comment. Please refrain from acknowledging it in the future.
 
neimod and yellows8 seem to be making some decent progress without decapping. I'm not actually sure if decapping would be extremely useful in this regard; I believe it would mainly give the bootloader etc., which probably doesn't have access to most hardware anyway. I'd guess the bootloader's main job is to load code from NAND (which won't be accessed by decapping), and then code from NAND would then have the code for accessing hardware.

(If you're familiar with the Wii, I'd imagine decapping would only really give boot0, which is basically a small stub to load boot1, which then loads boot2, which then loads IOS, which is what actually has access to all hardware. boot0 wouldn't contain the details required to access, say, video output, because it never needs to do that; IOS is loaded before any video output is shown - this information may be a bit inaccurate, I'm just guessing here, but I think it would be something like this).

On the other hand, decapping should probably give the keys for decrypting titles from the NAND, which could then be reverse engineered to figure out how to access various hardware.

Either way, it would probably be useful, but not necessarily essential/pivotal to 3DS homebrew.

I never said it was essential, but it still helps understand how the chip actually works which will help for homebrew development. Also, yellows8 and neimod are not average homebrew developers, they're on a whole different level
 
This is kinda related. I'm really curious how one goes about making software for a console that they don't have much official information about. I can take a library like PAlib and work with it but how does one go about figuring out how the hardware works and then creating a compiler for it? Where would one start if they were going to make a library like libnds or PAlib? Can a compiler that compiles code to work on devices with ARM architecture compile code for any device that uses ARM architecture? This is something that I'm just totally in the dark about.
 
This is kinda related. I'm really curious how one goes about making software for a console that they don't have much official information about. I can take a library like PAlib and work with it but how does one go about figuring out how the hardware works and then creating a compiler for it? Where would one start if they were going to make a library like libnds or PAlib? Can a compiler that compiles code to work on devices with ARM architecture compile code for any device that uses ARM architecture? This is something that I'm just totally in the dark about.
Well there's two main options: (i) leaked SDK (not favoured because of the legal implications, but this is the case for original xbox, possibly xbox 360, and at least the early PS3 scene; not sure if PSL1GHT ever became widely spread or not) (ii) reverse engineering (this is the one most of the hackers working on the 3DS will be focusing on).

This essentially boils down to figuring out how official software works with various pieces of hardware, and then writing code to do things in the same ways. For example, there are "registers" in the memory of a console. Writing certain values to certain registers will cause certain things to happen. (http://wiibrew.org/wiki/Hardware/Hollywood_Registers, http://wiibrew.org/wiki/Broadway/Registers - Wii examples). Figuring out what each register does (look at disassembled official software, make a guess, do some tests when you can get execution, confirm/reject guess, repeat) is one step. Another is figuring out the syscalls (http://wiibrew.org/wiki/IOS/Syscalls - again, some Wii examples). These are functions that the system makes available to the game code. These can be utilized by placing certain values on certain registers to use as parameters, and then jumping to a certain location (the location of the syscall). [In the official SDK, there would be a function programmers could use which would do all this for them; for homebrewers, that function needs to be recreated by the hackers making the SDK]

So hackers reverse engineer the registers, syscalls, etc. and write some nice C code to act as a "wrapper" to working with those registers, so that programmers can use functions they're familiar with to code for the 3DS, and then the SDK written by the hackers is used to convert the programmers work into 3DS compatible code.

This is a fairly simplified description (I don't really understand any more than this), but hopefully it will give you some idea of what takes place. (Hopefully what I've said isn't actually wrong in any place, just perhaps a little lacking in detail).
 
Snip? What happened?
I quoted a really long post. Rather than keeping all that text there, I just wrote *snip*. I guess it isn't really necessary since this new XenForo board automatically shortens long quotes but whatever.
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum