[h2]Introduction.[/h2] This section was getting drowned in threads with lots of misuse of terms so we thought it best to have a little thread detailing ideas, methods, concepts and the like used by hackers when hacking devices. There will almost certainly be mistakes both technical and otherwise, some omissions of important concepts as well as more than few weakly worded phrases or phrases open to misinterpretation. Naturally the aim is for this not to happen but there is a tendency to skip around as things remind you of other things or you realise there is a need to add some to another section and this can lead to sentences/ideas trailing off as the writing process causes you to jump around- it is kind of like http://xkcd.com/214/ except for writing sections. The thread is updated from time to time and if you feel an addition might be nice then do say so. If you have a theory on how to hack the 3ds then http://gbatemp.net/threads/3ds-hacking-ideas-post-your-ideas-here.345977/ is the better place to post it. Before continuing with the thread a note to releasers of hacks- if it was not already clear then there is a reason you might be reading this impossibly basic thread so we highly suggest you take on board some of the ideas from http://marcansoft.com/blog/2011/01/safe-hacking/ if you are going to release anything. Just as few plans survive contact with the enemy your hacks will get twisted in some seemingly impossible ways once they come into contact with the general public. Though there is now a short section on the current approach(es) to 3ds hacking this thread is not intended to be a news source for things 3ds hacking related or even somewhere to see what still needs to be done on the 3ds. It is more of an academic discussion on hacking methods and not a "how to/what to do to hack the 3DS". Equally there are vast tracts of computing theory missed out (computer architecture for one and pointers for another to say nothing of cryptography largely being skimmed over) and a general lack of worked examples or even that many links to real examples. To that end I do not doubt there will be many walking away with more questions than answers, hopefully those questions are deeper questions about hacking or computing/electronics/engineering in general though. Fitting with a "this is not a how to" theme it will be said again that many of the terms being defined/explained are of likely of no great use to 3ds hacking. All the methods will likely have had attention from hackers over the course of things but as they were being thrown around, often without too much clue as to their meaning, they are going to be defined as part of this exercise. Q)Will the following make you a hacker? A) Do not be silly- beyond something quasi philosophical it is near impossible to cover everything in depth. Q) Where can I learn more? A) You are on the internet- there is probably no better place to do it. Countless sites are dedicated to it but for brief overviews the so called security conferences and hacking conferences provide great places to start and for several years now they have been recorded and put online. Defcon and C3 congress (each conference is named for the number it is- the conference held in December 2012 being being "29c3") are probably the biggest but others like shmoocon, NOTACON, nexthope, google tech talks, TED (not a security conference- more of a general science conference) and Nuit Du Hack to name but a few more (do a search for just the name of the conference and then click the video tab of your chosen search engine, alternatively start here). As a rule of thumb a hacker is interested in anything and everything- from psychology to chemistry and from theoretical physics to the latest "changelog" of a programming language. Naturally there is an electronics and programming focus but as with general science most of the good stuff comes where once separate areas are smashed together. Programming skills are nice to have but what get called hacking skills do not tend to get taught at the same time as more traditional programming. The bonus for places like this is those people that get taught traditional programming then tend to make these devices and in doing so make mistakes for would be hackers to exploit. Hacking So hacking then, there are many definitions but here we are using the one the reads something like "When you buy a device it comes with the ability to do a few things and has an intended method of operation, one usually defined by the manufacturer. A hacker is a person that sets out allow them to do things other than this". Typically this means unintended interaction with low level files (or facilitating easier access/manipulation of them) or running your own chosen code. There are hundreds of possible avenues to both and degrees of success. There is something of an ethical minefield regarding hacking with many would be hackers having all sorts of things they would rather not do or are willing to do. GBAtemp is rather liberal in such regards and short of malicious code, hacking of online services (equally do not be surprised if few offer you help getting back online after you lose access), to an extent the sale of hacking services and hacking accounts of others we usually allow whatever* which has a habit of placing us at odds with many of those (or at least their public persona- what happens behind closed doors is interesting to say the least) that have traditionally provided the initial/most complete hacks for consoles. More often than not they find themselves with different ethics here. You are left to you own devices to choose where you sit and although you are free to debate your chosen position know that it rarely achieves all that much. If you want an example of such a thing see the debate over the timing of disclosure of security holes and related things- it has raged for many years now with no end in sight. People adding more powerful speakers, LEDS to various things, turbo buttons, remapping of buttons, reworking the hardware, case and whatever else to whatever end is still hacking but not necessarily what we are going to be covering here. If necessary it will be added in. Equally we love ROM hacking here at GBAtemp and even if our more general hacking credentials/status can be called into question it can not be said we are not a hub for DS and Wii game hacks. This sort of thing tends to come somewhat down the line and while it uses some of the techniques and methods listed below, indeed it often refines them greatly, as well as more low level hackers using similar methods (reverse engineering the banner format plus animations for a console for instance- classic ROM hacking, likewise figuring out the save file protection- another classic ROM hacking/cheat making method) it is something of a late stage hack and will not be covered as much; it is covered in extensive detail elsewhere on the forums if nothing else. As of January 2014 the 3ds game keys have not been leaked so the only work has been done on demos, with data that leaks via network communications and the usual line audio rips and video grabs (some capture card hardware is available for the 3ds). Some hackers that have code execution have done more but they are holding back on methods until they can be employed more generally. *one seemingly odd choice (especially given the hackers that might claim a dislike of GBAtemp have no such qualms) is that as a rule we do not allow keys to be posted. Unless the developers made a bad mistake in their actual keys (they chose 0000000 for instance) or something else bad/notable from a cryptography standpoint they serve no real purpose to the conversation and are usually easily found and implemented by those that need them. They might be legal according to your reading of the relevant statutes and case law (remember this is the internet which is a jurisdictional nightmare at the best of times) but the time and effort required to take on a throwaway case is better spent on other things; armchair versions aside GBAtemp has no legal representation on hand and see also the common phrase along the lines of "in such cases the only people to win are the lawyers". A minor exception for things like save game keys can exist (save games arguably fall under user data) and if you want to give away your own keys (devices often have their own keys for various reasons) you are probably free to do that as well, though given such keys can be used to allow (and cause the console manufacturer to subsequently deny) access to online services and more it is not necessarily the best idea. "We need ? from the ? scene" It is rarely a good idea to compare entire console hacking methodologies and persons hacking in them. Comparing attack techniques at basic levels can be OK or even a good thing in the case of closely related systems (given hardware still provides a lot of what we call backwards compatibility it is still common enough) although it is advised you know what you are talking about. Comparing people or saying things like we need person X from scene (or section of) Y is often a fairly quick way to make you appear clueless for much like everything else there are varying skill sets within hacking and different devices usually vary greatly (for the simple example of the skills think how many hacking sites have you visited that were using more or less out of the box themes or crude web design despite showcasing major skills in another area). Things set to come up are Terms related to hacking Cryptography Hardware attacks Software attacks Network attacks Goals for hacking a device Some links http://gbatemp.net/index.php?showtopic=271...t=0&start=0 http://gbatemp.net/index.php?showtopic=105493 http://gbatemp.net/t204149-psp-hacking?st=...p;#entry2541305 http://gbatemp.net/index.php?showtopic=284510 A talk on the 360 and the security concepts- old but good. DVD issues aside it could possibly be said in the end the 360 has the best security of this generation. The talk on the PS3 security model and how it failed. http://www.youtube.com/watch?v=5E0DkoQjCmI...15C99CBC9D387E2 An older video on the wii security and how it failed (first part in a series). http://hackmii.com/has many more notes on some of the more recent developments (especially http://hackmii.com/2010/01/the-stm-release-exploit/. http://www.dailymotion.com/video/xdsqmy_pc...du-h_videogames (some general hacking) Know that for every term here there has been an attack technique using them at some level in years past. Again not all are necessarily useful for hacking any of the devices we are presently concerned with. Terms Binaries Two main terms here (those wishing to understand the counting method otherwise known as base two see hexadecimal as it feeds from it) depending on the system you are dealing with. The GBA and to a lesser extent things like the wii and PS3 which have coprocessors for various tasks that run self contained pieces of code have one giant blob of code that for most intents and purposes can not be reduced any further. In systems like the DS and those with a more transparent file system (that is to say you can explode the file into various sub files that are not directly related to the code that is run) the binary is the file or section thereof that houses code for running, the binary files themselves might still contain other data though (certainly on the DS the binaries have been seen on many occasions to house in game text). These can be extended in various ways during runtime- the DS uses an overlay (a section of memory to drop code into), your PC probably uses a dynamically linked library (DLL in windows, unix based systems tend to opt for something like http://www.yolinux.com/TUTORIALS/LibraryAr...AndDynamic.html) and there a few other methods employed by various programming languages that are usually somewhere in between those or tweaks on them. In hacking, at least initially, we tend to use an existing piece of code to load another so accessing these is a top priority, modern hacking methods like Return Oriented Programming aka ROP (more on that later) make use of these in interesting ways so it is definitely a priority. Memory ROM, "sram", RAM, "NAND", "NOR" ROM- for the most part and certainly it is usually intended to be as such (thinking of older consoles that had tapes you could write over) the code you can run on a device usually comes are read only memory. This being said for historical reasons code that comes from a digital piece of optical media is usually referred to as an iso even if it too is read only (see the term CD ROM). You "dump" a ROM or "rip" an ISO from their original storage medium although a ROM rip or iso rip can be a dump/rip with parts cut out for space reasons (although with space readily available and/or extensive use of cryptography such methods are not all that common for console games these days). SRAM is a type of memory typically used in saves although some can take it to mean memory used for saves, other popular methods in the past include EEPROM and Flash which all have their little quirks (here is a link for some GBA saves and what goes http://www.pocketheaven.com/ph/wiki/index....title=GBA_Saves). Historically it has been useful to know how to dump and restore as the saves are used by the games to change things and a specially crafted save can exploit bugs in the save loading code (which you should remember is usually made by the game developer who is always up against the clock- "if it works for storing the save data then ship it" being the usual motto here). NAND is a type of flash memory used just about everywhere there is removable memory (memory cards, USB drives and more) and probably the main one these days (the other of historical note and increasing modern note is NOR memory which is quite fast compared to NAND and as such found use among devices designed to run GBA code). In modern systems NAND is usually used to store at least the basics of the upgradable dashboard/kernel and some lower level stuff. Access to this is also useful as you can analyse it for clues to how the system works or indeed the whole thing. There are also attacks that make use of the fact NAND tends not to erase things but keep shifting around the data- the wii had some of the early production code sampled from it and the 360 has the uncrippling method for units hit in the 2009 banwave. It has also led to a couple of seemingly opposing viewpoints from a forensics standpoint. http://www.theregister.co.uk/2011/03/01/se...g_flash_drives/ http://www.theregister.co.uk/2011/02/21/fl..._erasing_peril/ On the more hacking related front there has been something of an interesting clock/power attack that stops things from being written properly (it takes several pulses to write data/be sure of it) although this has not seen too many real world uses yet. Hex(adecimal)- quantum computers and analogue computers (rare these days) aside all computers use binary signals (usually referred to as on and off or 1 and 0) which stack up to form hexadecimal. You can change anything in hexadecimal but it can get extremely, often pointlessly, hard to do as such so people abstract this to higher levels. This applies throughout computing and is what for the most part provides hackers at least with the information they need to get into a system. This has been covered many times and in many ways is not all that useful once you start getting further into hacking. Still it is probably still a fundamental of hacking and knowing it will certainly help http://www.plantation-productions.c...Windows/HTML/DataRepresentationa3.html#999092 being a start. Debugging/buses Hardware designs are expensive to rework so once a design is made then it tends to stick (not to mention subtle things like induction related issues if you run a communication line under a noisy component that a hasty respin might cause). Equally field testing, factory testing/programming and post failure testing is useful to have so ports are kept around around to see what goes on inside the system. This often provides an in for hackers as well who would otherwise have to latch onto pins, traces or worse parts of a ball grid array. There are a great many debugging and communications buses and subtle variations with them with the two big ones in recent times being JTAG (used in many hacks- most notably the 360 homebrew method usually known as JTAG hack but more accurately known as the SMC hack), SPI (seen on some of the "360 slim" DVD drives) and I2C (used by the wii remote's extension port as well as the 360 reset glitch attack) although this is less of a debugging method. hypervisor or on occasion virtual machine (they are different, if related, concepts) All modern systems have these in various ways (even the original DS can be argued to have such a method for the GBA mode) and the DS is no exception. These are pieces of code that load up and act as intermediaries between different levels of a system- getting code to run at one level does not necessarily mean it will do anything useful (see things like being able to run the PS3 blu ray java- nowhere near the power of the PS3 proper though or indeed getting at the heart of the PS3). They are not always for security- some are for backwards compatibility, some are for code simplification and/or portability between systems but security is certainly a big use for them. Trying to punch a hole through them is tricky (unless of course they are not necessarily designed for security) but can be worth a try. They can even come in the form of a sort of hardware based hypervisor- to some extents the PS3/cell chip has them and the wii can be considered as such with the ARM IOS modules. You might see the discussion framed as the difference between userland homebrew/exploits and kernel level homebrew/exploits. Counter hacking measures- These come in a great many forms although consoles and more general purpose computers have slightly differing methods (most consoles have not so much as heard of heuristics beyond simple lockups/resets if something goes "drastically wrong" where on the PC it is the order of the day for all high end security models these days). Some of the methods to be detailed will have their countermeasures elaborated upon. patents, system layouts and hardware/component schematics. Useful to have as it helps find places to latch on to for attacking purposes- contrary to popular belief patents do actually contain a great deal of information which can be useful to hackers (printers often use custom protocols and methods which are often covered by (and detailed at some level in) patents and related media). As the hacker does not necessarily have to abide by patents (them mainly being for people who want to build other devices or depending on where you are in the world methods of doing business or making software for sale in one form or another) they can take the information and run with it. System layouts for reasons hinted at in the debugging methods section are useful. Component schematics are useful as the components run the system and the system usually brushes up against the limits of the components (a last minute change of processor in the original xbox led to an exploit because of a slight difference- it is unavailable at present but wayback machine link has some details on it). On the 3ds front http://www.isuppli.com/PublishingImages/Press Releases/Nintendo_3DS_PCB-Top.JPG http://www.isuppli.com/PublishingImages/Press Releases/Nintendo_3DS_PCB-Bottom.JPG Main article isuppli teardown See all those gold coloured dots with no components on them- those are pads presumably leading to various parts of the 3DS. More is definitely better or at least has a better chance of containing something really useful. It is far from always the case but sometimes these ports can turn something into debug mode as well- arguably the original DS with flashme has something like this (short SL1 pads), the early wii drives had mods via the serial port, some of the GC stuff as well (indeed it is what triggered part of the wii drive hacks) and the JTAG hack for the 360 is named for the very method it uses or more in depth the RT63 resistor being removed to prevent fuses blowing in the 360 CPU (fuses blow signalling the 360 should not be running anything lower than the fuses say thus preventing downgrading). patches In their simplest form these are files used by various tools to make changes to another file. These are usually made to make smaller files to distribute and to hopefully dodge any copyright issues as the only data that should be contained is the data from the would be hacker (see the note in the next sentence though). There are many types* of patch format (for now at least scroll down on http://gbatemp.net/t73394-gbatemp-rom-hack...t&p=1221059) but the big thing to watch out for is encryption which has a habit of changing the entire file as used by a system so a patch might inadvertently contain copyrighted code (this is why many hacks get released as installers). *data might be shifted and then overwritten, some earlier and more established patching methods like IPS did not feature such abilities and as such have a habit of falling over when you try them on more modern systems and program layouts. fuzzing If you have an attack there might be other slightly similar ones using slight variations in the attack method (if the name of one character can be extended to cause a crash/exploit there is a good chance another one will work as well- the bad defender only patches the initial attack and leaves it at that which is something hackers are all too keen to demonstrate the folly of). Such things along with code refactoring (a fancy way of saying code cleanups and minor rewrites to allow it to extend a bit) are sometimes* why earlier hardware revisions and earlier software versions produce the hacks and why downgrading is often an aim of a hacker (knowing this Microsoft effectively made it impossible to downgrade on the 360). *most of the rest of the time being the console makers finding out how they exploits work and fixing them. Yes it can be useful to try and analyse changes in updates as well- they might be caught not by hackers but the makers of the devices and kept secret from the public changelog but for a hacker such changes are interesting. On that line of thought sometimes extra features added later provide exploits or make existing ones easier- they might not be created by the people who first made (and presumably understand) the security system or forget something important. A fairly well known example might be the debian SSL bug a few years back where someone changed something to remove a compiler warning and thus prevented the cryptography from working properly- http://www.theregister.co.uk/2008/05/16/debian_openssl_flaw/. Hardware attacks In many ways these went away for a while but with highly programmable chips (stuff from pic and atmel as well as higher level stuff http://hackaday.com/2011/02/01/what-develo...t-board-to-use/) and new/fast scopes and debuggers as well as improved software coding techniques (read safer languages able to run well enough on fast systems to handle lower level stuff as well as quality of automated checking) they have once again become standard weapons in the hacker arsenal. Debugging part 2 As you have hopefully now found a few points to latch on to they might feature methods useful to a hacker. A common one is to read out or inject code. This presentation covers JTAG quite well and in far more detail than is viable here Superclocking Most modern processors only work when a clock pulse arrives at a certain pin (or maybe internally), changing the rate of these pulses can help facilitate attacks. Here you find the clock pulse for a chip and increase it (or the whole system on some occasions) which can lead to it skipping instructions (for instance those that might lock it down or set flags to that effect) or other interesting things. http://www.its.caltech.edu/~costis/sgb_hack/ being an example of such a hack. (super)Underclocking Here instead of going fast you go slow which can lead to a race condition (a race condition is where two pieces of code (or routines of one) are running and if one completes before another but needs the data from another to carry on can lead to crashing or other interesting behaviour. As coding against this attack is quite difficult (indeed you might already have had to code to prevent one from happening on normal operations)- it could come at any time and checking all the time makes code quite large (again it could come at any time so you effectively need to check all the time) and it only recently returned to the fore it becomes a useful attack. A crude version of this is when people use a capacitor on a clock/signal line to effectively slow it (the capacitor makes the voltage pulse which can be a clock pulse last longer hence underclocking) although this is not the only use for a capacitor in such situations. More classically the original xbox hotswap softmod method worked on a related manner by having the hard drive removed and fiddled with before the drive was sent a "lock it down" signal after it was initially unlocked for a short period during boot. Voltage attacks The main ones are raise high and hold low type attacks. Similar to the clock attacks above if a component or sometimes a line is held low for a while it can effectively lead to the component being off at a crucial time or it not getting the "lock yourself down" message as it thinks it is all 00s. Voltage high attacks can be similar as keeping a line high also leads to a message not getting through or on occasion the extra voltage causes the device to act outside normal parameters (this is often as risky as it sounds- in actual hacking the main use here is probably some of the early console lockout chips for unlicensed games were fried with high voltages). Some people have toyed with the middle ground/forbidden zone voltages as well for similar purposes although those can get a bit more complex as it gets into the hidden/weak signals realm. Some of the xbox 360 DVD attacks (certainly the likes of the pin lift/MRA hack for liteons and some aspects of the pogo ma thoin) use these sorts of methods and they are employed elsewhere all the time. The PSP with the pandora battery uses a similar method- by desoldering the EEPROM (or enough legs of it) you make it return 00 (or have the battery think it is 00) which then allowed recovery type modes (or at least triggered the sequence leading to it). Power analysis attacks and timing attacks A fairly new class of attack or at least one seeing something of a resurgence usually aimed at very high end cryptography. Timing is very important for some of the attacks mentioned in this thread but timing attacks are actually something else. Together or even apart they use very precise measurements of the power usage at a given time and the timings it takes for something to be done (think what happens when you have a remainder in long division and how it looks to someone observing you from across the room- computers can have similar problems) to try and infer what is going on inside the black box of a system. The following has some more on power analysis attacks. One of the early 360 homebrew (as opposed to hacked DVD drive) attacks had a timing attack component http://beta.ivc.no/wiki/index.php/Xbox_360_Timing_Attack. Side channel attacks A broad term for some of the attacks mentioned here (although often referring mainly to the power and timing attacks). They are a hot topic right now in cryptography as they have felled many high end security systems that from a software perspective were considered reasonably secure. Decapping There is a phrase along the lines of "there are no secrets in hardware" and at present at least it is true. When dealing with systems that are custom enough that existing hardware specs do not cut it and we want to bypass security or we are in need to hardware designs to mimic hardware for emulation ( http://decap.mameworld.info/ and the likes of http://blog.akkit.org/2010/05/30/project-chip-decapping/) To figure out secrets Do interesting things like http://www.theregister.co.uk/2010/02/17/infineon_tpm_crack/) or even to emulate everything from the transistors up . unpotting Some devices will come covered in epoxy (a process sometimes known as potting) ostensibly to try and prevent someone from latching onto the hardware. Assuming the hardware developers have not been kind enough to leave you a nice set of debug ports heading right to said pins (such a thing has happened on more than one occasion- big companies with multiple developers for a single board often making this sort of mistake) or BGA balls you get to play with fun chemicals to remove the epoxy or scratch away at traces. http://kevtris.org/Projects/votraxpss/unpot.html Such things are of little concern to most hackers playing in hardware but trying to get the end user to do such a thing poses a greater problem. Ram access/ram writing Does what it says on the tin- the ram houses the data for the game usually including the code and hopefully some of the system menu and the like. Changing this allows you to change what happens. Action replay/gamesharks and most cheating methods tend to do exactly this (game genies altered roms as they came from the cart and some action replays/gamesharks like the commercial devices for the original xbox (we have since seen lots of "trainers" that do operate on the memory) are little more than specially hacked saves with maximum money, lives, ammo, levels unlocked and the like). Replay attacks Often an aim of/part of a good ram writing hack- here you get to restore a state in system and try another attack method or key. Useful if the time taken to reset and try again by normal means takes a long time where you can otherwise restore memory in seconds. Software attacks For many the ultimate aim of a hack is not to need custom hardware, this is not always the case but software attacks usually provide a springboard for them. Although code analysis on all sides has improved over the years making aspects of code hacking harder no hacking is worth attempting without knowing a few things here. computer languages Of more interest these days- earlier in times work happened in assembler (just quickly assembler is the language of the machine you are using right there and then- it is different in effect for all machines although machines of the same type tend to be related closely enough, short of actual 1s and 0s it is as close to the hardware as you get and everything is ultimately reduced to it) and later (nowadays it is fairly standard) something like C or maybe C++ (this being said being able to recognise what a given C function looks like in assembler and being able to work with such things is valuable skill for a hacker). C and C++ are notoriously easy to make a mistake in that leads to an exploit (the wii fakesigning/trucha bug was born of not using a suitable compare/check function for the binary data but using one aimed at ASCII text instead http://debugmo.de/2008/03/thank-you-datel/) with other more interesting attacks as you head further into it. Some games and aspects of the system can use considerably higher level languages though (puzzle quest on the DS even uses an odd "compiled" form of lua) which can provide attacks against their virtual machines (or outright work around what Nintendo aims to do with checks on the binaries). Likewise some systems run cut down operating systems which you can generate attacks from if they have known attacks on them. Equally trying to find a bug in the web browser or image reader or something like that is also useful (not least of all because many image readers run in the menu which usually have higher levels of access than games/normal code). jumps Do what they say- if the code encounters one it jumps to the next section and carries on running code. If you can make the jump to somewhere you control you then get to run your own code- the original passme exploited this by having the DS jump to some code on the GBA cart which we controlled and was still accessible in DS mode. An interesting newish attack started out with attempts to defeat ASLR (address space layout randomisation- a technique used on windows computers with related methods on a couple of others to try and stop things from being in a guessable or known place in memory) on computers being known as the JIT spray (even if it is randomised you put enough attack code in the memory can get the program to jump to it and your code will run) but has been used in a couple of simple hacks against embedded systems where flooding the memory with jump commands aimed at a portion you might control or more likely are guessing at saves having to hope your attack makes it start at the right place. Equally some jumps are known as conditional jumps- they only do something if certain conditions are met. It is usually associated with anti piracy bypass methods but changing jumps to jump (or indeed not) where they were conditional before is useful. No execute/executable memory In unix type computers you can have files be read, be written to and be executed. You can pick any combination of the three of those. The execute part is the big one here as it allows code to be run on the CPU rather than just read as a text file or something (this is also a problem with scripting languages and certain programming techniques). The 3ds said to have something like this that keeps much of the save code, the game data and more away from the code that is executing or indeed will not allow the CPU to run code on that portion of memory. Memory attacks Memory and other things have many interesting features for the would be hacker. "buffer overflow" http://www.ustream.tv/recorded/5167328 has a great deal on these. The classical buffer overflow, which the video above considerably narrows the definition of, revolves around finding something that reads data from somewhere else into memory of some form and ultimately having it overwrite beyond what it intended to/should have with the aim being the overwritten stuff to be your code or at least a jump to it. Memory dumps "bit bang, reveals" Much like ram access in hardware above if you can get the software to dump the contents of memory they can be analysed. Even better is when code is running it is not usually protected as well as it might be on a disc or on some embedded memory (NAND). bit bang is a slang term used by some people referring to a method that dumps memory or some results piece by piece usually over a somewhat slower port or method. Before PS3 hacking took off in a big way with the jailbreaks and results of the work of fail0verflow and others there was a PS3 attack that revealed unencrypted parts of the otherwise encrypted hard drive. The original tweezers hack for the wii that netted the public key stemmed from a similar attack (memory that should have been cleared was not) and depending on how you look at it some of the HD-DVD work along with a few attacks rely on snatching a key from ram when it was there being used although this is less of a reveal (still valuable though). If you want to get further into this ROP - return oriented programming A relatively new type of hack and one aimed at systems built to handle classical buffer overflow attacks (covered above). It is what the present 3ds hacks all use (though in practice they are all variations on the same exploit). It relies on the idea that if you are going to block code from executing then by using the existing code you might be (read almost certainly will be) able to piece together a running program, from the videos below the idea of a ransom note being made from random snippets of text but here for code. Such snippets that are used are usually called gadgets hence terms like "ROP gadgets" and when you string a bunch of ROP gadgets together you get a ROP chain. As gateway naturally want sell their devices they do not want others using the hack leading to terms like "reverse [engineer] the ROP chain". http://www.youtube.com/watch?v=w5xq8at0cXM Save games in hacking On the save format http://3dbrew.org/wiki/Savegames Some existing work for the DSi, probably a fair good springboard for this. http://dsibrew.org/wiki/DSiWare_VulnList Save file encryption can be twofold- one you have the signing and possible encryption that the 3ds hardware presumably does to all saves (the wii does it and the dsi does it for DSi code at least if you see some of the early hacks) although it seems Nintendo regressed and used a badly implemented version of XOR. This is hardware specific and traditionally happens with a per console key* although here it seems to be a per game key. Nothing stopping Nintendo from having multiple levels either (the PS3 and to some extents the wii provide good examples here) and/or having parts hashed. *not much of a problem if you can share saves with your friends or otherwise transfer them if you can resign just one game- you can often "ban" or blacklist saves made with certain keys with microsoft and the earlier days of the 360 providing a good example, on the 360 nowadays people tend to strip identifying code from it. On the other hand there is the developer encryption, checksums/hashing or possibly signing- this is the one that save hackers traditionally bypass or mess around with, but any would be console hacker will probably have to do this as well. This can and has been seen to be anything; Nintendo might have provided a basic method in the 3ds SDK to do it and often they are very weak from a cryptographic standpoint (simple bytesums even) but we have seen developers use their own (custom or off the shelf) for years now. When doing the simple change to narrow down locations of game data method you usually see the minor changes in location, time and your chosen thing to change along with the save's new hash value. Such protections need not across the whole file (or a significant portion) either and it can be something like have a mirrored and inverted value. Typically it is cheat makers that have to deal with this all the time but they are very simple things to do in terms of resource cost so saves are certainly not immune; this means save hackers, savestate hackers and cheat makers often feed from each other (the savestate hack derives usually from a cheat and then the game will take the data from the memory (as now provided from a savestate hack) and make it into an entirely valid save for you, vice versa a save might be nice and simple with simple checks which allows you to inject whatever values you like into the memory with the game happily sorting any counter cheat methods for you, in doing so this tends to light them up like a Christmas tree). In practice some parts of the game can and do fall outside these "protections" though- in theory it only has to be the signature itself (you can not take the signature of the signature if you have not calculated it yet- if you can predict it your method is far far too weak to be useful) but in practice other things can fall outside it. Leaving theory aside for the moment consider that sometimes it is beneficial (mainly as you do not have to decrypt it to read it) to say have a value for the names (character or user name), location, play time, gold count and whatever else you see on the "select your save to load" screen stored unchecked along with the hash/signature value and this can be the exception for both sides of save protection. Exploitable errors here are ideal as it means you do not have to deal with much if anything on the save protection front. A great example here is some of the early wii region free hacks, here parts of the header which included a measure of region checking (not all of it but some) and they went unsigned which ultimately allowed for some games to be run in regions they were not intended for (even to the point where mod chips could be programmed to allow for this) Another would be the shader/king kong hack on the 360- here the code intended for the shader memory fell outside signing which helped with the exploit. Once again memory corruption is the order of the day and this guy explains things here very well: http://www.ustream.tv/recorded/5167328 Ignoring the lessons of the video above for a moment the general idea is buffer overflows require that the read commands use something like a stop when you get a 00 or some stop command (a similar effect was used for the false signatures/trucha bug for the wii and kind of similar thing was used at some lower levels of the 360 hacks- king kong and the like). The hacker then comes along and removes the 00 and the game just keeps reading code (hopefully into the memory and even better hopefully overwriting the actual game code- your new instruction loads eventually and bam you have yourself your own code running on the system (there are various tweaks and sometimes you might want to take out the stack, sometimes you might want to just change a pointer, sometimes you might want to wipe out a flag or set one and there are loads of other nice things you might want to do but the idea is the same) This is OK if you do not have hostile code but if you are up against hackers you have to consider it hostile and code defensively- some developers have trouble doing this (such things are not necessarily taught in coding school, tend to mainly be seen in people that have trained themselves to think this way and you are not usually hired by game developers for your defensive coding prowess rather than your abilities to say animate sprites or generate 3d physics models) and as save data is more or less left up to developers who are on a deadline and maybe not skilled in countering hackers it usually provides an easy in. There are various counters Nintendo could have done like the 360 which encrypts the entire memory with a new key generated at every boot so you can not just write good code to the memory, though we said not all developers do code defensively continued language development, code checking and compilers can afford a small measure of it and various consoles have a so called hypervisor that, if you code it for such a thing, should allow code to run but not trouble the higher system functions- the wii, the 360 and the PS3 all have a measure of this but they have varying levels of effectiveness. Other things that might be useful are characters the game has no idea about (if your game say uses ascii then actual characters ASCII technically run from 20 to 7f but before and after that are other possibilities- this is not quite as useful as it once was but still worth knowing about. For a somewhat esoteric application of the ideas here seen in the following video, here a combination of glitches and in game actions are used to overwrite a portion of game code in Pokemon yellow and run a user program all without the help of any external hardware recovery code, prototypes and developer code/systems. These sorts of things naturally have very low levels of access to a system for various reasons and if we can get some of these many things can be inferred from them. While nice these sorts of things tend to appear later on in a system lifetime. Methods to restore broken systems are useful, for instance see things like the pandora battery on the PSP or IOS16 /wii backup disc on the wii (although Nintendo did not help matters with their lax updates) and what they did for hacking their respective consoles. Countless console SDKs and dev units throughout history have provided nice options for would be hackers as they are usually based on the same hardware, running essentially the same software (often from the same source just with a few flags changes here and there*) and may even have really nice debug options. *said few changes for developer units often mean they have fewer restrictions which allow you to refine you hacks on them and then start to worry about executing them. Network attacks There are a great many attacks and things focusing on networks A nice overview of those sort of attacks For a more general overview of web based errors and attacks http://search.theregister.co.uk/?author=Jeff Williams has some nice stuff. Originally it was supposed that not much would be for the 3DS using conventional network attacks beyond bonus features and redirecting DNS. This is still true but owing to Nintendo seemingly not understanding a lot of what are now common and well known networking concepts there have been a few things of note. Network stacks (the code used to interact with the network) are cheap or free and quite good so attacks against them might not be that useful (historically there have been a fair few attacks on things like this- see things like "ping of death"). Attacks on higher level aspects (thinking game level protocols rather than some of the programming type attacks mentioned in the video just linked) on the other hand are more likely. Overview of the three network attacks done so far. 1) Streetpass faking. Streetpass is a function of 3ds that you can share miis and other things if you were close to another 3ds. Later Nintendo added the option to pass by certain wifi hotspots and the next person to do the same would also get a streetpass hit. These wifi hotspots did not use any custom code and instead sent the wifi mac address of the hotspot to Nintendo's servers (the mac address should be unique for every network card/point) which would then know to send the relevant data back. As mac addresses as changeable in software (though most had to use a computer/hackable phone/other custom code running device and make their own hotspot as home routers tend not to have this function) it is then easy enough to make it appear as though you are at the same hotspot -- IP addresses can change every few hours so they can not really use them. Said hits also have measurable in game effects now where before it was just a few minigames and some pretty pictures so it is more useful than just a few hits these days. 2)Since stopped by an update (which is required for online thus stopping pretty much everything there). i) Pokemon decryption. It was noted that Pokemon sent its trade data including the stats of the pokemon over wifi all completely unencrypted. It was used to help regulate trades, figure out the "shiny" values for a trainer to enable them to get shiny pokemon and similar things. People did attempt to try replay and injection attacks but nobody ever managed to do successfully anything as far as we know. ii) As well as stats in trades they also sent pokemon team/move selections over wifi (data usually hidden from your opponent) and also completely unencrypted. 3)Pokemon cloning. Much like the original GB cloning trick it seems if you stop communications before a certain point then one vanishes into the ether and The hypothetical 4) would be when pokemon bank gets released (it was was released in Japan but then stopped) which allows people to import their pokemon from older games. With said games and systems being completely hacked it then allowed hacked pokemon to be imported, there are checks in place to stop some impossible to create pokemon but supposedly they were not the most stringent. DNS Domain name system- your computer is contactable (or the router at least) at an IP address but as addresses are hard to remember and prone to change we have domain names. There are root domain name servers and a whole list of them (root, some government, some ISP, some local ISP, some third party- openDNS, your router might have one, there might be one on your network (usually corporate, filters or high end home networks)) right up to your device that you are using (see flushdns commands of things like ipconfig and ifconfig). Hijacking the DNS is an attack used by many but on consoles it is mainly used for two things- changing the location of update servers and changing the location of online saves/bonus content (pokemon had things like this). The original broadband adapter homebrew method for the gamecube did however use an attack with a method like this though modern hardware/software/security design probably still rules something like it out for the 3ds. routing Similar to DNS attacks earlier these tend to be the result of a proper firewall- every packet has an intended destination and a routing attack can redirect things here. Similar idea to a DNS attack but not quite as useful if DNS attacks are an option. There are some ways of changing packets sent around as well. port sniffing A Hollywood staple ( http://nmap.org/movies.html, nmap is also the go to port scanner for most people) and probably of no real use here- as well as a destination most network communications have a port they are intended for. There are a bunch of known/intended uses for ports ( http://www.freesoft.org/CIE/RFC/1700/4.htm) as well as a load of free ones but these sorts of attacks are far more useful against more general purpose computers which you can then focus attacks on (say port 21 is open then that might be a FTP server- some FTP servers have bugs in them that allow access or people often stick with default passwords). packet injection Wireless communications can come from anywhere and say anything. If you have an exploited host (quite easy to do with general wireless, less so for application/hardware specific stuff although the original wifime did a fairly good job) you can send whatever you like and even if the underlying network stack is good the application level (which might even be a better thing to attack) might fall under the same problems as saves (developer built and not protected as well as they might be). Chances of this happening are although it is possible it is unlikely, it was considered for the original DS ( http://www.pineight.com/ds/pass/) but we got flashme and other methods for those that needed it so it was not explored much. To do this it does often require if not custom then not just any network hardware (typically ralink or atheros hardware being the choice things as they have nice injection/raw modes and open source drivers that allow things to be fiddled with easily). Cryptography (often shortened to crypto) This is a hugely complex subject, the main book we suggest you pick up if you are interested is Applied Cryptography by Bruce Schneier (ISBN-10: 0471117099 and ISBN-13: 978-0471117094) although there are several other means to learning about this sort of thing. It is a common occurrence in electronics and computing today so it is worth knowing about. Hashing If you counted all the words, the numbers of each character and certain other aspects of this post you can send that somewhat smaller data to others and they would have a clue if it was changed. It is surely not much of stretch then to see how you can then use hashes to see if your data has been changed (remember for all it might represent it is still a long line of 1's and 0's). Obviously you can just recalculate a hash so unless the original hash is buried deep in hardware (if you have a custom CPU it is quite often found in here) or otherwise verified it is not much good to stick a hash somewhere of some data and call it secure. Popular hashing methods include CRC32, MD5 and SHA1. They are also commonly used in save games to make sure they have not been tampered with and here they frequently do use simple hashes which can just be recalculated and so fail to provide much in the way of protection (a trait of games (ab)used by many authors of save editors over the years). They are also often used in password verification by storing the hash of a password (although doing it properly can be tricky- see rainbow tables) rather than the password itself and risk having it simply read from your storage. Hashing has several requirements if it wants to be considered good which are very similar to random number generators- it must be unpredictable (it is not reasonable to generate a message for a given hash) each tiny change in the message must cause big changes in the overall hash each combination must be able to happen each combination must be equally likely- this is usually read as finding two messages with the same hash is not likely or more accurately finding messages with the same hash more times than is likely for the size of the hash should not happen- almost by definition if you have data longer than your hash it will match the hash of something else even for a good method but a good method will only see this happen by chance (rather than desire) or if the attacker has a very very large amount of computing power). You can forge a hash usually by changing parts of junk data or some otherwise useless data (occasionally you might change parts of the actual data you can afford to change) to try and match hashes. Assuming your hashing method has no weaknesses (an example of a weakness being something like the first 2 bytes are always 0000) for newer methods this requires an awful lot of work and computing power though so it is not necessarily viable- this leads to various hashes being graded by how useful they are at detecting/"preventing" corruption, tampering and how useful they are in verification (CRC32 being considered useless for anything but corruption, MD5 being seriously frowned upon for anything but corruption and SHA1 is having a successor written as we speak although still considered viable for most). A twist on this comes from the data recovery world (most likely familiar to you from RAID hard disk methods or PAR2 files if you transfer files around (especially on usenet)) which are a kind of hash/sample of the data that can be used to reconstruct broken portions. Sometimes NAND has this sort of thing onboard. Signing A halfway house between encryption mentioned below and hashing. This takes a hash but does it using more encryption based methods (like using keys) to generate a hash but only one that someone who has the (private) key can hope to replicate. Quite often though for various reasons involving speed and security (several reasons but the biggest is that a lot of data is very similar- headers and the like) a list of hashes will instead be signed (changing the data should change the hash which then breaks signing) with HMAC being an example of popular implementation of such a method. This is normally the stumbling block of the would be hacker for without unsigned code you have nothing, if the system is well built you might not be able to fake signing or indeed get the keys to do it, you can not trick your way past the system and you can not inject whatever you like and have something happen. Though many hacks end up being multi layered attacks that co opt hundreds of parts of the system the main question to ask is "does it defeat the signing?". If it does not defeat signing (and is not an attempt to run 1:1 identical code) then you can almost always dismiss it. Encryption The aim of encryption is to take a message and change it so it is unreadable except by those that have the required key. It is related in many ways to signing above but usually works across the whole message or a part you want protected. You can nest/stack encryption methods on top of each other if you want too (although most consoles prefer to layer signing methods instead for files and maybe encrypt a few key files further). Related to this as far as the would be hacker is concerned is compression- it often makes the resulting code look a bit encrypted as well (well not necessarily but hold on for a second) but more importantly provides a barrier to having it instantly readable. Relaxed laws, continued research and increased computational power means encryption is quite good and extensively used these days in consoles and other embedded devices with most failings usually coming because the device maker failed to implement it properly. private key vs public key cryptography/Symmetric-key vs asymmetric-key There are broadly speaking two main types of crypto- Symmetric-key and asymmetric-key (there are ways to blur lines here but generally speaking the terms private and symmetric match up along with the other two). Private/symmetric-key has one key to both encode and decode and all parties/sides need to know it (the technical term usually being called "shared secret") to do anything useful. Public/asymmetric-key crypto has one to encode and one to decode (some implementations might include another key to unlock a false piece of data- see "plausible deniability"). There are two things you can do- Most consoles encrypt data at the factory and have the machines in the field decode it- this means you keep the private key in the factory locked down very tight (Sony screwed up here by putting various private keys for the PSP in every PS3). The other option used more in online transactions (although it gets a bit more complex as it is used to start things off) is you give the encoding key to anybody that asks and they can encode whatever they like (typically a key or some data that needs sending) which they can then transmit. Only the person with the decoding key can then read this data. In some cases having the public key is useful and it is certainly a goal of any hack as it enables further research but simply having it does not mean you have homebrew- it only worked that way on the wii because Nintendo also messed up the checks badly enough that you could brute force (detailed below)/"fakesign" the files quickly using the public key to check you got it to a point that was useful for the hack. The question then becomes "Why not always use public/asymmetric-key?" to which the reply is for reasons of speed and required resources. You can mix and match though- your online bank probably uses public key to start with and the client generates a shared key for that session which is doubly nice as it can prevent there from being a lot of public key encrypted data to analyse. http://gbatemp.net/t272917-general-stuff-about-keys-and-such has some stuff relevant to this cryptography discussion in general. "security by obscurity" Something of a derisory term (for good reason) in the security community. It refers to people using custom/proprietary protection methods as opposed to known and well documented/tested ones- as mentioned elsewhere there are ways you can very quickly reduce your security from all the time and energy in the universe to crack to "it will take longer to type it up and post it online". Custom/proprietary protection methods have a very long history of very big holes being found in them and the things they attempt to provide protection for being blown wide open as a result. However depending on your chosen position having an unknown method can be useful as it means the people attacking have to figure it out first before attacking your system (this is not usually that troublesome and for the other reasons mentioned it is rarely a good idea). Salting If you have a frequent section or somewhat known message adding a salt to the data you are about to hash will change the resulting hash (remember small changes should make big changes to the resulting hash for a good hashing method) which is useful against some attacks. Rose back to prominence as rainbow tables (a near complete list of messages for/up to a given length and the hashes they produce- great for bypassing passwords) became viable as a result of increasing disk space a few years back. It takes proper implementation though- using the same salt for all your device/site might then simply mean someone generates a new rainbow table using the salt so the best one is to pick a different one for every new piece of data/user (and to try and make it unable to be guessed). Equally hashing the data, then hashing the hash and hashing that new hash (and so on) can provide a measure of security. Brute force This is trying every viable "password" until you get the right one or on the other side of things trying many minor changes until you get a matching hash/signature (your hash is probably smaller than the data you are hashing- it will then have to match for two different messages aka a experience a collision), it has been used successfully in some older systems with weak cryptography (export laws and generally weak computers mean a lot of older stuff is weak compared to today) as well as some embedded systems (thinking mobile phones) but you will generally be laughed at if you suggest it and do not provide extensive reasoning as to why it is viable in this case (by and large it is not useful to do on the 3DS). Holes in cryptography. Cryptography is based on maths and much like most other areas of maths there are simple tricks for some things (often which you want to avoid for cryptography). The 3ds has already seen this is the XOR protection applied to saves and maybe roms themselves that in theory at least with a properly implemented XOR on a good message can never be broken by anything. In practice Nintendo had left enough of the data as 0000000000...... (a common padding method to fill up a chip that might be bigger than your data) that the key effectively gave itself away by means of this (XOR is a fundamental of so called boolean logic where if one and only one of the two inputs to circuit (we will not be covering multiple inputs here- the encryption does not use it anyway) is high the output is high where if none of both are high then the output is 0)- against a string of 00000 you then give away the key or hopefully enough of it to help out with the rest (equally for many forms of cryptography trying to encrypt or do an operation on a string of 00's is a very bad idea as it has a nasty habit of giving your key or other secret things away). There are several other problems with XOR but it is quick, "easy" to work with and computationally cheap so people still use it, it often forms parts of greater levels of encryption as well (indeed it is one of the things power analysis attacks mentioned earlier can aim to detect). Various consoles have had various holes in their crypto at some point- the original xbox used a weak method (see that 17 mistakes thing http://web.archive.o...Security_System) and the PS3 rather famously gave away the keys by means of an improper implementation (a video and a couple of other links on the matter back at the start of this post). Sometimes the checks can be bypassed as well leading to the next term Checks You can sign all you like but if you never check it is what you want it to be (in practice this can also mean you mess up the check in some manner) then there is no point. In the past at least developers would only also check data once- when initially loading or installing and Nintendo have been especially guilty of this (the DSi flash carts use this- http://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/ and the Wii hacks make extensive use of this to install custom IOS modules and the like) which is useful if you can change things after the fact. There have been instances in the past where things were checked one or two bytes at a time leading to a situation where the data could be brute forced for those bytes in "real time" (considerably easier than forging the whole thing). Also the first PSP firmwares had a bug where they would check a folder and run another if it had a $ symbol at the start of the folder name- the first was perfectly legit data but the $ being your payload. Another mistake can be seen in the xbox 360 DVD drive attacks- they verify the DVD firmware is the original/official but they leave it to the DVD firmware (which we can control) to do the checking (and for the earlier drives at least used simple checks with known answers or ones easy to generate). Related to this are blacklists- certain things can not be run if they are on this list whitelists- things can only be run if they are on this list. greylists- things might else cause it to be sent for further checks or run in reduced functionality mode It probably falls under greylists, signature analysis or heuristics but if certain conditions are met rather than it having to be like an example it can then flag things (thinking back to "fuzzing" earlier if you say blocked one attack with a blacklist the hacker could turn around and change that one part thus dodging the blacklist). You can also sandbox or run things at lower privilege levels if they are on certain lists. Goals Just some of the goals, there are many more and these largely represent the big steps of which there will be loads of other little things along the way. Chances are most of these will require custom hardware to pull off at first. Some hacks might only need to be done the once where others aim to work most or every time. Memory dump (unencrypted) Whatever is in the memory at various points is good to know about. A dump/snapshot of this allows for some further hacking work. The DSi had these http://hackmii.com/2009/09/dsi-ram-tracing-camera/ There are simple things you can do (invert sections, mirror sections, encrypt sections- basically see any good cheat making guide that deals with how to work around protections), the 360 at least went one step further and encrypted the entire memory with a new key generated at every boot. Memory trace (maybe real time) Like a memory dump mixed with a storage oscilloscope- these note changes at every clock cycle and as such allow you to see what happens as things go on which is more useful than a simple memory shot although as you might imagine these get to be huge very quickly. Not all consoles need them to be hacked but they are nice to play with as you can see what goes. Save dump (and useful save dump). Saves have code in that can be used to inject further code. It seems they were encrypted here but encrypted badly so we have these. These are often encrypted with a per console key although seemingly not here. They often have an additional layer of protection or three put there by developers to prevent save hackers (usually those that would cheat by a modified save) or detect corrupt saves which seems to be troubling people here. Code dump (thinking rom dump) More useful for those that want to run copied games perhaps but also useful for exploits rather than the more scattergun approach taken by simple save hacks. NAND dump The NAND probably contains the system menu and lower level code. Kind of necessary to interact with this to consider a machine "fully" hacked. The 3ds almost certainly has very high levels of protection here though. These are often encrypted with a per console key. User code- levels thereof, methods of choice. We can already run DS code and maybe DSi code. 3ds code is the next step and presumably there is a difference between the game level code and the system menu code (the PSP has such a distinction as do all of the current generation of home consoles). This probably means we need exploits for the 3ds unless we can somehow punch through the DS or DSi hypervisor. We have fairly extensive control and experience with flash carts not to mention a fair legacy there so those might be the methods of choice. Equally there are external storage methods in the likes of the SD card which also provide a method that would be nice (SD cards being readily available from most places and all). It might even be something in between (see stuff like the PS3 jailbreak, the 360 JTAG/SMC hack and wii modchips being able to be constructed from simple or readily available devices). Later on Some of the hardware components- touchscreen protocol, screen protocol and the like would be useful but they are not that necessary at this stage for hacking purposes. If there is a peripheral that would probably be more important (thinking http://ladyada.net/learn/diykinect/). Whether it wants to come first or after a more complete model of the security system is also useful. Note- bitching about how complex/difficult/annoying/unreliable a method is unless you have a proper suggestion to help things out will probably not endear you to anybody so skip it please. Hope this thread is at least somewhat helpful to some people.