<b>This was posted in another thread called DSi hacking.. i hope this helps</b>
<b>FAST6191 wrote</b>
Right the
back to the basics, also DS flash cart history 101.
I have a more general document about the following in the works but until then:
To build a flash cart you first have to know how the signals between the game cart and DS occur, this can be done in many ways (logic, logging, code injection, some other analysis, reading the hardware specifications*....). Once you have this you can start messing around with things.
*this need not be the same as reading the official SDK, many makers will hide information from their developers for various reasons.
In the case of the original DS there was protection on the DS carts hence your needing an original cart with the passme, the passme allowed the DS to authenticate the cart and then after that it abused the signals. Also there were already well developed GBA carts which could be read in the DS mode so people just jumped the reads to the GBA slot (this was the passme, a later revision of the DS blocked this but left the GBA SRAM accessible leading us to the passme2 which used the SRAM instead).
If you want to learn more about the passme then
<a href="http://nocash.emubase.de/gbatek.htm#dscart...ssmepassthrough" target="_blank">http://nocash.emubase.de/gbatek.htm#dscart...ssmepassthrough</a>
<a href="http://www.dspassme.com/docs.shtml" target="_blank">http://www.dspassme.com/docs.shtml</a>
As an aside along with this came flashme, the DS firmware is located on an unencrypted easily writeable chip; the wifi stuff was actually added on in a patch from Nintendo, many believe this was to avoid licensing the required standards in the event the DS failed (believe it not things were very touch and go for the first year or so). Flashme patched this firmware to, amongst other things, allow code to run from the GBA slot if necessary.
Now flash carts work by taking signals to the game cart and in turn interpreting them to help access the required section of the SD/CF/ms or other memory section and then sending the data back in the format required.
In the case of the GBA carts this meant a fairly radical shift from the existing format the games were hardcoded for and some fairly extensive patching was required for games to run and to save (some games that did not patch properly actually used the game in the passme).
For the record chips for consoles (looking mainly a CD/DVD media), the DVD makers will make their writers only able or unable as the case may be to to read and write certain sections that are then used to detect "official media" or hide date. The chip/hack then works around this and redirects to a section that can be read/written to by conventional hardware.
Some time later the DS encryption was broken (Martin Korth or NO$GBA and gbatek notoriety was the person responsible) and the first nopass was made (no more official game needed to launch code), a few minutes (or so it seemed) later many clones/tweaks were made by every flash cart maker out there.
A little while after that the first DS carts sprang up, they were a bit rough and ready (one even required flashme to dodge the inbuilt encryption) but they were refined.
Flash carts invariably have some onboard logic which allows it to initially boot up when it gets powered, such a piece of code is known as a bootstrap loader. Many cards can not update this in any meaningful way (namely via software) which is the reason we did not just see updates to many cards to simply add SDHC when it became available and more recently updates to allow them to work on the DSi (the DSi updated security to check for things normal carts did not do but flash carts do, I understand a similar method is used for piracy checks in the newer games).
This then loads another loader (some carts use another onboard section, others rely on the presence of the loader on a memory card).
Now to the DSi, as mentioned earlier the main way to get information on the hardware is reverse engineering. For the uninitiated reverse engineering is the act of taking a piece of hardware and applying all manner of techniques to figure out how it works, without the original plans and with a device as complex as the DS there is quite likely to be holes in the reverse engineered specification of the device. If you incorporate these holes into a new design then your device may not function as intended or indeed as was the case with the DSi can be detected (and blocked), there are other methods including whitelisting, blacklisting, greylisting, heuristics (a form of which were used here) based on file name, data within files (either hashing or signature analysis), actions of the device/code but going into that would be getting off track.
As for encryption, if done properly it works and works very well. However doing it properly (either the method can be faulty or the way you implement it can, some nice examples of both in the original xbox <a href="http://www.xbox-linux.org/wiki/17_Mistakes...em#Introduction" target="_blank">http://www.xbox-linux.org/wiki/17_Mistakes...em#Introduction</a> ) can be very difficult as the countless hacks across history have proven.
There are two main types of encryption called symmetric and asymmetric:
Symmetric uses the same key to encode and decode information meaning you have to protect your key very well.
Example, XOR encryption.
Some random data (actually it reads SDAT in ASCII)
0101 0011 0100 0100 0100 0001 0101 0100
XOR encryption, here the key is 8 bit (easily broken by normal methods but it will be used here).
Key used is "BB" (1011 1011). Remember for a “2 pin” XOR the output is only 1 if one of the inputs is 1 (none or both means 0). XOR encryption works in the principle that for every binary digit there are two possibilities meaning very quickly you are dealing with powers 2^1024 or 1.797693134862315907729305190789e+308 combinations for a single 128 byte file).
0101 0011 0100 0100 0100 0001 0101 0100
With XOR encryption
1110 1000 1111 1111 1111 1010 1110 1111
Asymmetric uses two different keys (one to encode and one to decode), it is usually marred by increased resources required (all encryption requires more resources but asymmetric tends to require more).
Example (basic RSA):
<a href="http://mathcircle.berkeley.edu/BMC3/rsa/node4.html" target="_blank">http://mathcircle.berkeley.edu/BMC3/rsa/node4.html</a>
The thing about these is you can give your public key to anyone out there without issue, in theory they can reverse the public key to get the private key but you are protected by maths. In most case this is the difficulty of taking a number and factoring it, RSA uses semiprime numbers for this (two prime* numbers multiplied together)
* for those just joining this maths game then prime numbers are numbers that only have themselves and one as factors (7, a prime, can only be made by multiplying 7 by 1 and 1 by 7). They are unpredictable (there is no pattern in primes) and the only way to test them is to try dividing by every number up to the halfway mark, there is no big list of prime numbers after a given point (any that exist are far behind the numbers being used for encryption).
Also important here is hashing, it works by taking the data and performing a mathematical operation upon it to give a number as an output (ideally it will be unique, unpredictable and unable to be reversed given present methods) the simplest hash is called parity or in normal numbers it is referred to as odd or even. That way if someone sends some something and also says it is odd but the message is even then something has gone wrong. Odd or even is useless for most things though as there are just as many odd numbers as even (failing the unique hash requirement), there are two grades of has as well: cryptographic and non-cryptographic. Simply put the requirements of "ideally it will be unique, unpredictable (you can not find a message and say aha that has a hash of [this] without first calculating it) and unable to be reversed with present methods"
More
<a href="http://unixwiz.net/techtips/iguide-crypto-hashes.html" target="_blank">http://unixwiz.net/techtips/iguide-crypto-hashes.html</a>
<a href="http://www.youdzone.com/signature.html" target="_blank">http://www.youdzone.com/signature.html</a>
The cousin of encryption and hashing is signing (so much so that you can turn any encryption method into a signing method), here the section you want signed is either
* encrypted and then data extracted from the encrypted data although this is rarely used because it has security issues, mainly when implementing it, and resource issues.
A variation on this is used in the GBA and DS carts in the form of the logo, it was thought by having a copyrighted/trademarked logo that it was "legally" safe. In the US a famous case between Sega and Accolade <a href="http://digital-law-online.info/cases/24PQ2D1561.htm" target="_blank">http://digital-law-online.info/cases/24PQ2D1561.htm</a> it was ruled against, Europe is not quite so lucky in many cases (there was something happening in France but I can not find a link right now). Naturally the law is not as simple as this and there are many things for and against it.
* Hashed with a normal hashing method and then the signature is the encryption of the hashes (you can not change the data without changing the hash which then changes the signature).
Again:
<a href="http://www.youdzone.com/signature.html" target="_blank">http://www.youdzone.com/signature.html</a>
You can sign your code (the wii discs: <a href="http://debugmo.de/?p=61" target="_blank">http://debugmo.de/?p=61</a> and <a href="http://hackmii.com/2008/04/keys-keys-keys/" target="_blank">http://hackmii.com/2008/04/keys-keys-keys/</a> ), you can encrypt your memory (the xbox 360: <a href="http://www.youtube.com/watch?v=uxjpmc8ZIxM&fmt=18" target="_blank">http://www.youtube.com/watch?v=uxjpmc8ZIxM&fmt=18</a> (I suggest watching this if you are at all interested in how this hardware hacking stuff works as it covers a lot of ground) ), you can encrypt your drive and other ways of storing inherently "random" data (the PS3 drive: <a href="http://www.haxnetwork.net/2009/03/ps3-hdd-...ypted-tutorial/" target="_blank">http://www.haxnetwork.net/2009/03/ps3-hdd-...ypted-tutorial/</a> )
Re: DSi mode. As many know the DSi has increased hardware capabilities yet retains compatibility with "older" games/hardware. When you emulate something you convert signals from their original form into one your hardware can use, if at some significant level your hardware happens to match the hardware being emulated you can use a thing called a hypervisor to simply pass signals to the appropriate hardware (you can also do minor conversions, the line where something becomes straight up emulation is tricky to define though).
It also doubles as a nice security feature by not allowing access to outside hardware/memory; on the wii the so called tweezer attack allowed the people doing it to use the gamecube hypervisor (we could run custom gamecube code on it) as it was then to shift the memory it could see around the wii's memory. The wii uses a symmetric key that was rather foolishly left in the memory (you should strive to have your keys in the memory for as small a time as possible when dealing with cryptography) which was promptly read and that then allowed further hacks to happen (it allowed more analysis of the internals which were all encrypted with this key, these had bugs which were then exploited).
All the current DSi carts do is emulate an original cart well enough to pass the DSi flash cart checks thus allowing "normal" DS games to run.
I think that just above covers the basics, next time reverse engineering for real.
