Split ROM decryption

[gudenau]

I would like it if you could decrypt split 3DS rom files.

For the moment I will work on this, but if someone beats me to it I will be OK.

[d0k3]

Providing this functionality would require a 'wrapper' FileRead() function that processes multiple split parts as one file. A 'wrapper' FileWrite() function would be required, too. This is not simple to do at all and one would have to be extra careful not to break anything else in the process.

So, is this really useful? Afaik, there is no rom so far > 2GB, meaning that the split feature is not required at all (roms of exactly 2GB can be trimmed by one byte). Also, the only piece of hardware / software that really supports these splitted roms at this time is GW (again, as far as I know), and GW doesn't really like fully decrypted roms.

[gudenau]

Xeno is 4GB. I am aware that this can break stuff in weird and wonderful ways, I will try to be careful.

[d0k3]

I just saw, the true limit is at 4GB for FAT32... so Xenogear Chronicles could still be decrypted even now if it is trimmed by at least one byte. Don't know if it's really worth the effort, but if you intend to do a pull request keep the changes as minimal and as separate to the existing code as possible.

Oh well, and I just see I might have chosen 32 bit variables for filesizes in some places. You might need to take care of that, too.

... and as a general hint, changes should only be required to fs.c. Maybe some minimal stuff elsewhere, but that's it.

[gudenau]

That is the idea, I am planning on just checking the extension; if it is
split use a diffrent method to decrypt it.
On Feb 2, 2016 5:22 AM, "d0k3" notifications@github.com wrote:

I just saw, the true limit is at 4GB for FAT32... so Xenogear Chronicles
could still be decrypted even now if it is trimmed by at least one byte.
Don't know if it's really worth the effort, but if you intend to do a pull
request keep the changes as minimal and as separate to the existing code as
possible.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[einstein95]

There's 24 games that use a 4GB cart, you can see which by going to http://3dsdb.com/ and searching for 32768

[d0k3]

Still, as I said, trimming these files by just one byte will enable current Decrypt9 to process these files on FAT32, while enabling split rom decryption might break things.

[d0k3]

@gudenau @einstein95 is there still any interest in this? Otherwise I'd close it.

[tetsuo55]

Do we know if that 1 byte always contains garbage or padded data?
Could it be that we are losing data by trimming it?

For accurate dumping of 3ds carts we would have to be sure.
One simple option could be to keep on dumping after the limit is reached into a 2nd file.

Merging the files would have to be done on pc by the dumper.

[d0k3]

D9 checks if that byte contains data or not. This was never the case, is very improbable, and will most likely never happen.

[g6672D]

It's actually losing 512 bytes, also whereabouts does it check that the truncated part is just padding?

https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/game.c#L1983

Assuming it isn't losing actual data, can the program at least print a warning that it will need to be fixed before hashing?

[d0k3]

You could have looked just a little bit above:
https://github.com/d0k3/Decrypt9WIP/blob/master/source/decryptor/game.c#L1982

Research on 3dbrew (topic: NCSD) if you want to know why this works. I agree that a quick debug output about removing the last sector makes sense.

[g6672D]

Doesn't that just tell you the space is unpartitioned and not what's actually stored in the cartridge? Yes those regions should be 0xFF but the whole point of doing full cartridge is on the vague chance that it's not.

[d0k3]

Well...

We've only got a handful of cartridges with 4GB size. None of these contain any data beyound the actual used space (actually there is not a single known case with 'hidden' data on any 3DS cartridge). Split dumps would be major annoyance - for me, to implement, and for the user to handle. Also, if you absolutely need split dumps, you can use uncart or GW software.

Besides - you would be better off writing some application that actually searches for that 'hidden' data if that's what you'd be after.

[g6672D]

No problem. I'll attempt to hack my own check into decrypt9, that'll be enough for me. Thanks for adding the warning message and for your input.