Acekard 2i running on Nintendo 3DS

  • Thread starter Thread starter Costello
  • Start date Start date
  • Views Views 55,012
  • Replies Replies 101
JPhantom said:
and the reason why nintendo can't check all the roms is the amount of space required to store the checksums right? maybe they'll do that with the next 3ds revision
They DO check the header, ARM7 binary and ARM9 binary of every old DS game (pre-DSi). Newer games are checked in a different method (they are given a string, they have to encrypt it and return it, the DSi checks it, if it encrypts it correctly it lets it boot. Or else the string is encrypted and the cart has to decrypt it).

They just don't seem to check the file system for some reason. Don't really know why. They only check the file systems of games KNOWN to be exploited, and check for the specific exploits used. Don't understand why they couldn't do a checksum of some sort on the whole file system...
 
lolz the Acekard team gets my respect on Facebook
smileipb2.png
 
SifJar said:
JPhantom said:
and the reason why nintendo can't check all the roms is the amount of space required to store the checksums right? maybe they'll do that with the next 3ds revision
They DO check the header, ARM7 binary and ARM9 binary of every old DS game (pre-DSi). Newer games are checked in a different method (they are given a string, they have to encrypt it and return it, the DSi checks it, if it encrypts it correctly it lets it boot. Or else the string is encrypted and the cart has to decrypt it).

They just don't seem to check the file system for some reason. Don't really know why. They only check the file systems of games KNOWN to be exploited, and check for the specific exploits used. Don't understand why they couldn't do a checksum of some sort on the whole file system...

There's not much point in checking the filesystem for a few reasons. First from a security standpoint you only care that signed code is run on your system. The non-executable assets aren't really worth checking in general. As long as you can verify the binary, the other stuff is fluff.

Second, NAND memory isn't cheap. Every kb you're using to store some hash, is a kb you're not using to store actual useful data like your firmware and such. You really want to minimize the amount of this kind of static data as it's expensive to maintain and doesn't provide anything useful other than take up room.

Third taking a hash of the entire filesystem is computationally expensive and might take awhile to run on an extremely large ROM. It might take an extra 10-20 seconds to boot something big which would be a pretty crappy thing.

Fourth every read done on the cart in theory decreases the lifetime on it. If you force the scan of the entire system on every boot it would decrease the lifespan of the cart. Maybe not by much but again you're incurring a loss for what is probably for questionable gains.

Finally, like any security expert will tell you, it's much much harder to cram in a security system after the fact. You're forced into unacceptable compromises because of silly things like 'user experience' and 'backwards compatibility' (Damn those users! Why do they complain about my 25 character passwords with upper/lower/numeric/special characters policy??!?!) . If you design the security from the beginning you can address these things without compromising the system. Otherwise you're asking a security engineer to fill gigantic holes in a dam without draining the dam, and you're only allowed to use bubblegum and spit to fill in the holes.
 
Its kinda suspicious how Nintendo really strengthen the Anti-piracy protection of the 3DS compared to the DSi that blocked all the ds and dsl carts,maybe Nintendo has some dark plan giving them the last laugh [LOL]
 
doyama said:
SifJar said:
JPhantom said:
and the reason why nintendo can't check all the roms is the amount of space required to store the checksums right? maybe they'll do that with the next 3ds revision
They DO check the header, ARM7 binary and ARM9 binary of every old DS game (pre-DSi). Newer games are checked in a different method (they are given a string, they have to encrypt it and return it, the DSi checks it, if it encrypts it correctly it lets it boot. Or else the string is encrypted and the cart has to decrypt it).

They just don't seem to check the file system for some reason. Don't really know why. They only check the file systems of games KNOWN to be exploited, and check for the specific exploits used. Don't understand why they couldn't do a checksum of some sort on the whole file system...

There's not much point in checking the filesystem for a few reasons. First from a security standpoint you only care that signed code is run on your system. The non-executable assets aren't really worth checking in general. As long as you can verify the binary, the other stuff is fluff.

Second, NAND memory isn't cheap. Every kb you're using to store some hash, is a kb you're not using to store actual useful data like your firmware and such. You really want to minimize the amount of this kind of static data as it's expensive to maintain and doesn't provide anything useful other than take up room.

Third taking a hash of the entire filesystem is computationally expensive and might take awhile to run on an extremely large ROM. It might take an extra 10-20 seconds to boot something big which would be a pretty crappy thing.

Fourth every read done on the cart in theory decreases the lifetime on it. If you force the scan of the entire system on every boot it would decrease the lifespan of the cart. Maybe not by much but again you're incurring a loss for what is probably for questionable gains.

Finally, like any security expert will tell you, it's much much harder to cram in a security system after the fact. You're forced into unacceptable compromises because of silly things like 'user experience' and 'backwards compatibility' (Damn those users! Why do they complain about my 25 character passwords with upper/lower/numeric/special characters policy??!?!) . If you design the security from the beginning you can address these things without compromising the system. Otherwise you're asking a security engineer to fill gigantic holes in a dam without draining the dam, and you're only allowed to use bubblegum and spit to fill in the holes.

Thanks for your post, very informative. That all makes sense I guess, never really thought about it much.
 
"Never" isn't the right word. There's just no way right now, and nobody's claimed they're making a way.

And no flash cart has IR, since it's only used for like 5 games total.

If you want DSiware, buy it.
If you want to use a pokewalker or something, buy the game and just deal with having to carry another cart around.
 

Site & Scene News

Popular threads in this forum