Hacking 3DS rom dump info

[Pong20302000]

Now ,guys,guys wait a second...

if trimming removes fucntionnality i hope you rot in hell !!!
For now the hole 3ds roms are 148 7z packed.
If trimming removes 30-40 Gb im all for it ,if not ,well ill see as one of various ''Mess with Original Backup'' LOL.

@Pong : expect a huge pack ill made will all icons ,High res covers for the 3ds (around 200 mb).
For a feature rom manager with high res cover (maybe??),cause i dont know about you guys but we reached 2013 (56K modem and dinosaurs are long gone) and my eyes hurts trying to read 3ds back or front covers.

@Ris312
Where have i seen this pseudo? an impression of Deja vu .

Rom trimming doesnt remove functionality
but on a flashcard that cant auto do some items (e.g. cards that use RGF's Kernel) you cannot expect a trimmed rom to work because the ID has changed
and i prefer not to trim roms as it eliminates the point of it being a 1:1 backup (im just fussy with preserving data tho)

a huge pack would be good and a manager
but i don't know how to make such things but the database does allow for the XML do be downloaded to could have a manager that can load the download from the database, but the manager would have to have its own downloadable database for new games etc

i wouldnt ask Ris312 that question because the answer is against site rules

 

[abdelmajidtolba]

Im down for it as long as a coder know knows his way around coding.
I was checking gametdb and had eye cancer trying to read wii disc id or 3d covers.
The idea came to me when trying to organize my roms i wanted a good readable cover cause 320 pix pictures are from the past.
BTW pong,do you know Touffu ? the god of japanese games cover
the dude has like thousands of Hires jap covers .

 

[PsyBlade]

but on a flashcard that cant auto do some items (e.g. cards that use RGF's Kernel) you cannot expect a trimmed rom to work because the ID has changed
and i prefer not to trim roms as it eliminates the point of it being a 1:1 backup (im just fussy with preserving data tho)

uhm...

-flashcarts can't do shit with 3ds roms anyway
-the ID isn't changed at all
-the only thing changes/removed are tailing 0xFFs (that's actually checked during trimming)
-untriming is produces a 100% identical file
-any future program/flashcart that can actually play 3ds roms can trivially make the it appear untrimmed dynamically*


@abdelmajidtolba:
the code is a python script, its meant to be saved as a file and be executed by the python interpreter
it was meant more as a proof of concept/example to be included somewhere else
I can polish it a bit and provide .exe versions if there is need, but I don't think that's the best way



*: in the read function, if the read it beyond the actual file size but still belog the original size (stored in the header) simply return 0xFFs
this is much simpler than eg dynamically reading from a compressed file that wont even be smaller

 

[Pong20302000]

Im down for it as long as a coder know knows his way around coding.
I was checking gametdb and had eye cancer trying to read wii disc id or 3d covers.
The idea came to me when trying to organize my roms i wanted a good readable cover cause 320 pix pictures are from the past.
BTW pong,do you know Touffu ? the god of japanese games cover
the dude has like thousands of Hires jap covers .

no i do not know him, havnt heard of him either lol

uhm...

-flashcarts can't do shit with 3ds roms anyway
-the ID isn't changed at all
-the only thing changes/removed are tailing 0xFFs (that's actually checked during trimming)
-untriming is produces a 100% identical file
-any future program/flashcart that can actually play 3ds roms can trivially make the it appear untrimmed dynamically*

i was on about DS roms and there trimming
the AP removal relies on crc32 numbers so trimming on majority of cards = AP problems

i understand what you mean about 3DS roms and how they would play
but who is not to say about what checks the console can make
the 3DS (im 99.9% certain) checks the card and makes sure all the data, including the fat is there, doesn't mean a hack cant change this but obviously left in the dark about the hack. but obviously for emulators the feature to add the fat for a check would be passable.
but the check is the reason the 3DS team cant have every 3DS rom on there flashcard as each chip is checked for max size & game size for the 3DS (so you would need a re-flashable chip for every card size and a switch between them or being all separate carts which is Big $ so wouldnt be cost affective for cart makers)

 

[Tattorack]

and yes guys
Super Street Fighter IV - 3D Edition 16384 Mbit

HUGE!!!!!!!

and also dead or alive is HUGE!!!

but all legit

info is now all complete

I wonder if there are flash big enough for those games!!
The biggest Micro SanDisk I know of is 128GB.
Some N3DS games are 128GB! And since there is always minimum 1GB missing on a MSD card of that size I'm wondering how is anybody going to play those games!? (should the N3DS finally get hacked..........)

 

[porkiewpyne]

I wonder if there are flash big enough for those games!!
The biggest Micro SanDisk I know of is 128GB.
Some N3DS games are 128GB! And since there is always minimum 1GB missing on a MSD card of that size I'm wondering how is anybody going to play those games!? (should the N3DS finally get hacked..........)

B(yte) =/= b(it)

Afaik, the biggest 3DS rom dump is 32 Gb which is ~ 4GB.

 

[Tattorack]

B(yte) =/= b(it)

Afaik, the biggest 3DS rom dump is 32 Gb which is ~ 4GB.

I knew that already, but I looked at the list of existing games on Wiki (was a while back though) and some of them were 128 GB

 

[porkiewpyne]

I knew that already, but I looked at the list of existing games on Wiki (was a while back though) and some of them were 128 GB

That's odd? What game is that? 32Gb is the biggest listed on DS-Scene. LOL

 

[Pong20302000]

I knew that already, but I looked at the list of existing games on Wiki (was a while back though) and some of them were 128 GB

biggest games are 4GB, which is 32Gb
quite confusing but dont worry too much
but again micro SD storage wont come into it

due to the fact they will need to be flashed chips which would have to be done on a PC

 

[FearItSelf23]

I knew that already, but I looked at the list of existing games on Wiki (was a while back though) and some of them were 128 GB

No 3DS game will ever be 128 Gigabytes. Don't be ridiculous.

 

[andibad]

I knew that already, but I looked at the list of existing games on Wiki (was a while back though) and some of them were 128 GB

huh, yeah i know maybe is confused you about Gigabit (IEC Bit unit), GigaByte (Traditional Byte unit) and Gibibyte (IEC Byte Unit)

if is GigaBit, 16 GB? until now biggest size of 3ds games is 4 GByte.
is ridiculous if is 128 GB.

 

[Thorhian]

biggest games are 4GB, which is 32Gb
quite confusing but dont worry too much
but again micro SD storage wont come into it

due to the fact they will need to be flashed chips which would have to be done on a PC

Well, Not for too long, Ninty has already said that they will offer up to 8GB in the future.

 

[Pong20302000]

Well, Not for too long, Ninty has already said that they will offer up to 8GB in the future.

ive never seen such a message. have you got any info on the net to back it up
the only 4GB/32Gb games so far are
Resident Evil - Revelations & Metal Gear Solid 3D - Snake Eater
i cant really see them going that much larger than 4GB but only time will tell

 

[Cyan]

They said they will support up to 8GB on launch.
Not that it will be the limit in future.
I don't remember where I've read it either. (I think it was on their official website, showing specs of the console)

Developers only made up to 4GB games so far, but I think if they wanted they could use 8GB cartridges.

edit:
I can find only info on SDHC 8GB on nintendo websites :/
no mention to 3DS cartridge 8GB size.

 

[FearItSelf23]

8GB maybe hell even up to 16GB games could be possible, pretty unlikely though on that hardware as nothing on the 3DS would really benefit from that much, but 128 Gigabytes is not only unlikely it simply won't happen and not only because no game would need that much.

 

[abdelmajidtolba]

@cyan
i also read it somewhere and even saw one of nintendo's 8 gb prototype card in a pic somewhere.
i guess its nice to see that nintendo didnt do the microsoft's mistake (DL dvd instead of hdvd) by allocating more space for later use.
u never know in the dev world.

@psy and pong
thanks for the insight

@guys

we have alot of devs here ,havent we found anything about 3ds dumping tools ? i mean cmon.... i know release teams are good but read earlier in this thread that one of the teams had no history with any dumping involving hardware.

@Tattorack
Stop trolling ,you should know before anyone else about Bit Byte thingy cause youre french.

 

[Thorhian]

They said they will support up to 8GB on launch.
Not that it will be the limit in future.
I don't remember where I've read it either. (I think it was on their official website, showing specs of the console)

Developers only made up to 4GB games so far, but I think if they wanted they could use 8GB cartridges.

edit:
I can find only info on SDHC 8GB on nintendo websites :/
no mention to 3DS cartridge 8GB size.

I believe it was during one of their presentations, maybe at the e3 it was revealed. It was QUITE a while ago.

Update: Here's one source: http://www.nintendoworldreport.com/news/24569
But yeah, if a dev could pull the strings for an epic game release (Super Smash Brothers anyone?) this could potentially end up happening. It might end up like the Wii and dual layer discs, it but will happen eventually. Of course, it could end up to be popular, especially since 8GB of flash mem is actually pretty compared to what it used to be in the past. So Pong, you will most likely see >4GB game in the future.

 

[PsyBlade]

a short demo how to do checksums on trimmed files

it calcs the sha1 and md5 of
-the actual file as it currently is
-the checksum it would have after you trim it
-the checksum it would have after you trim and untrim it (which matches the checksum of the untrimmed rom)

rom checkers can eg use the 3rd to find roms in their database regardless of its trimming status

#!/usr/bin/env python2
# -*- coding: utf-8 -*-
 
import sys, io, struct
import hashlib
 
print "checksuming {}".format(sys.argv[1])
rom = io.open(sys.argv[1], "rb")
rom.seek(0x100)
assert rom.read(4).decode("ascii") == "NCSD"
fullsize = struct.unpack("<I",rom.read(4))[0] << 9
rom.seek(0x300)
trimsize = struct.unpack("<I",rom.read(4))[0]
rom.seek(0)
md5 = hashlib.md5()
sha1 = hashlib.sha1()
while rom.tell() < trimsize:
    data = rom.read1(min(1<<16,trimsize-rom.tell()))
    md5.update(data)
    sha1.update(data)
omd5=md5.copy()
osha1=sha1.copy()
for data in rom:
    omd5.update(data)
    osha1.update(data)
rom.close()
print "current MD5    : {}".format(omd5.hexdigest())
print "current SHA1  : {}".format(osha1.hexdigest())
print "trimmed MD5    : {}".format(md5.hexdigest())
print "trimmed SHA1  : {}".format(sha1.hexdigest())
md5.update("\xff"*(fullsize-trimsize))
sha1.update("\xff"*(fullsize-trimsize))
print "untrimmed MD5  : {}".format(md5.hexdigest())
print "untrimmed SHA1 : {}".format(sha1.hexdigest())

 

[abdelmajidtolba]

it calcs the sha1 and md5 of
-the actual file as it currently is
-the checksum it would have after you trim it
-the checksum it would have after you trim and untrim it (which matches the checksum of the untrimmed rom)

rom checkers can eg use the 3rd to find roms in their database regardless of its trimming status

if we can restore a file crc,sha1 and such ,then why the hell our guys in the wii world wont do it?
im thinking (actually talking out of my ass) of a huge file used to unscramble wii games.

I dont know about you guys but wheres our buddy from Venom team? i miss their 5 roms releases every 2 weeks.
Cause since they stopped ,contrast guys doesnt feel pressured and only releases big Hits .
not much but ...
Luigis.Mansion.2.EUR.3DS-CONTRAST
Monster.Hunter.3.Ultimate.EUR.3DS-CONTRAST

Back to our bets shall we?
will we get a hack before the 300'th Rom? the tension is building
5bucks

 

[PsyBlade]

if we can restore a file crc,sha1 and such ,then why the hell our guys in the wii world wont do it?

the pattern used to fill up the unneeded portions of 3DS roms is 0xff, 0xff, 0xff, ... until full
thats easy to restore

the pattern used for wii games is more complicated, it might even be random
and the filler data resulting from it is afaik different for every game
afaik no one has figured out a way to recreate it
that means once you deleted it, its gome