4dsdev
Views: 614,049 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-23-17 03:44 PM
Guest:

Main - Posts by d0k3

Pages: 1 2 3 4
d0k3
Posted on 11-15-15 07:26 AM, in Rebuilding a (fully decrypted) CCI with already available tools? Link | #724
I know about all this :). I'm doing this for (a) scientific purposes and (b) to help GW users use Decrypt9 better.

From the Makerom source code - I know it is doing something with the signatures for the development target. And in fact, it should generate valid signatures (again, for the development target only). GW actually won't run zerokey encrypted stuff if the signature doesn't match (it won't run unencrypted stuff at all, and for other types of crypto bad sigs are okay). Homebrew .3DS are typically zerokey encrypted, so they must also have good signatures.

d0k3
Posted on 11-15-15 09:29 AM, in Possible board merge Link | #726
The more the merrier :). I think more users (as long as that doesn't mean noobs galore) are good to keep the discussion alive.

d0k3
Posted on 11-22-15 07:29 PM, in Decrypting the NAND title.db / import.db Link | #759
Recently, I've been trying to write a working parser for title databases (title.db, import.db, maybe even ticket.db). There is an entry for those on 3Dbrew.org:
http://3dbrew.org/wiki/Title_Database

Parsing the title.db and import.db from my N3DS (9.0.0) NAND, I've noticed something strange: Although the files are obviously okay (otherwise my console would be bricked), they look like they are corrupted in several parts. Parsing (as described on 3Dbrew.org) works for some Title Entry and Title Info tables, but for others, I just get garbage.

Now, is it possible that just some parts of the files are encrypted? (I'm not talking about the standard CTRNAND encryption layer, of course). And, how to decrypt them, and how (if we'd rule out statistical analysis) to decide which parts are encrypted and which are not?

Any ideas?


And, btw, can someone clean up the mess jojo61 left? No idea how to report posts on this forum otherwise.

d0k3
Posted on 11-23-15 04:37 AM, in Decrypting the NAND title.db / import.db Link | #760
... I guess this should have gone into the new 'Reverse Engineering' subforum. Any chance this can be moved there?

d0k3
Posted on 11-23-15 01:11 PM, in Decrypting the NAND title.db / import.db (rev. 2 of 11-23-15 01:14 PM) Link | #763
Posted by profi200
Not related to your question but it is silent here because you ask the wrong questions. The en-/decryption stuff was ok but not asking about these db files. It's not in the rules but no one will answer if it get's used for purposes we don't like.

You are welcome to ask other things.

The actual purpose was to identify the correct TMD file for app injection after the CTRNAND was messed up by a GW downgrade. I guess there are some other, more questionable reasons for wanting to completely understanding these dbs. As most users use injecting as an easy start point to be able to install (illegit) CIAs on a CFW, injecting is questionable in itself as well, I guess. Is that the reason behind the silence? Sorry, just trying to understand!

d0k3
Posted on 11-24-15 04:25 AM, in Decrypting the NAND title.db / import.db (rev. 2 of 11-24-15 12:55 PM) Link | #768
Posted by 54634564
d0k3, I just saw your GBAtemp post:
"...The seemingly corrupted parts also happen to be nicely aligned to certain 'round' (ie with zeros at the end) offsets..."

Check those spots in the files on the encrypted NAND, they're probably blocks of 0xFF(never been written to). When you decrypt the NAND, you 'decrypt' these blocks of 0xFF and they end up looking like garbage/encrypted data.


To show an example, see this image: http://i.imgur.com/RdklqTF.png
Top is from decrypted NAND, bottom encrypted.
0xB0E00 is at 0x4E00 into my ticket.db.

Thanks for pointing this out! I'd say this is unlikely, cause these corrupted parts are (for some title.db / import.db) right in the middle of the Title Entries / Title Info Tables (see 3Dbrew.org). I also made sure I'm checking the active DIFF partition (well, actually to be safe I have been checking both most of the time).

I will check later today and write then. If these parts of the file have simply never been written to, I wonder what that could mean - after all these parts are required for the database to be useable at all.


On another note, I've managed to successfully reset the EmuNAND update nag on a test system by simply setting 'Number of used Title Entries' to zero (that's a one byte change in that case) in import.db. There should have been trouble with the IVFC hash tree, I guess, but it seems to have worked without trouble.

d0k3
Posted on 11-24-15 05:59 AM, in Decrypting the NAND title.db / import.db (rev. 4 of 11-24-15 06:13 AM) Link | #769
I checked it and you were right. The only difference is that it is zeroes for me, not 0xFF.
[image]
The offsets, although they don't match, correspond to each other (one in a title.db dump, the other in a full NAND backup).

Now, how can this be? As I said, this is right in the middle of a Title Entry table. When FBI, f.e. lists the apps installed in system, it has to look them up somewhere (ie. the internal 3DS routines have to). I'd have assumed the place that this is looked up in is the title.db. If everything works (ie. the system is actually not broken), that must mean that there is another list of installed titles somewhere in the system, correct?

d0k3
Posted on 11-24-15 04:12 PM, in Decrypting the NAND title.db / import.db Link | #773
Posted by Syphurith
1.There is a "extdata_tool" somewhere. Compiled binary can be found somewhere.
extdata_tool -m IMG -x -i -t -l title.db.out
This can parse the file, but can not manipulate it. So no offline installation..
2.To make things easier, i suggest you do such steps.
A.dump xorpad for those dbs (import, title) on SD card.
B.backup the the dbs. let's say, "clean".
C.install a title, and backup the dbs as "installed".
D.remove the previous title you installed, say "removed".
And xor those dbs from SD with the xorpad. Get all decrypted to compare with WinMerge2011.
Soon you would see what is modified. Yes this is not for NAND, but that is quite similar.
Well i know now if you've ever installed a title, there is record inside import.db, orz.

That's all what i wanna say. Hope you good luck.

Good point! I don't want to edit anything (just need the title.db contents for info), though. I also already wrote my own parser which seems to do a better job than extdata_tool.

I have a suspicion, tough... Both my parser and extdata_tool may have selected the wrong partition. Still unsure. And you might be forced to actually install something to your SysNAND before that file becomes readable.

d0k3
Posted on 11-24-15 05:34 PM, in Decrypting the NAND title.db / import.db Link | #774
Okay, I'm a good step further:
https://github.com/d0k3/titledb-get

This is by no means perfect (and I'm 100% sure it has bugs!), it is a start to get to better understand these databases, though.

BTW, it looks like these title databases are always the same size and the important stuff is always in the same places anyways, so a simple implementation only for title.db shouldn't be too difficult.

d0k3
Posted on 11-27-15 11:54 AM, in Get ARM11 code execution from FIRM_LAUNCH ARM9? Link | #783
Posted by gudenau
I would like to work on a CFW not based on Nintendo's code, but the first part of that (to me anyway) is to get code execution on ARM11 from ARM9 FIRM_LAUNCH. Sure I could make one in ARM9, but that would be limited.

Bonus:
Could I can get all (4 3ds/6 new 3DS) cores at once, not needed at all.

I can't help with that, just wanted to say thumbs up for the success of this project. Sounds very interesting!

d0k3
Posted on 11-29-15 02:51 PM, in Mount nand:/ ? Link | #797
Maybe this can help you.

d0k3
Posted on 12-08-15 09:18 AM, in ZIP3DSFX - barebones ZIP-based SFX extractor (rev. 2 of 12-08-15 09:18 AM) Link | #823
It's time I showed off one of my own projects here, so I'll start with ZIP3DSFX. ZIP3DSFX is a barebones ZIP-based SFX extractor for the 3DS console. It has two main build modes plus multiple configuration options.

SFX Hard Mode: This mode hardcodes the archive.zip into the ZIP3DSFX.3dsx executable. To use this, rename your ZIP archive to 'archive.zip', put it into the data directory and compile with 'make sfx_hard'. This will use the smallest amount of memory and will work anywhere, but the archives content can not be changed without compiling anew.

SFX Stub Mode: This mode creates a SFX stub, the actual archive.zip has to be attached to the end of the ZIP3DSFX.3dsx. Compile this with 'make sfx_stub'. Files are attached (on Windows) via 'copy /b ZIP3DSFX.3dsx + archive.zip myZIP3DSFX.3dsx'. You can simply copy any ZIP archive to the end of the 3DSX to create a new SFX archive, and the resulting .3DSX can (in standard ZIP mode) still be opened in any archiver program on any platform. SFX Stub Mode uses more memory and will not properly work with some loading methods.

The ZIP3DSFX executable can overwrite itself with one of it's contents - I guess this can be useful in several cases. If you want to further customize ZIP3DSFX overwrite behaviour (among other settings) edit config.h inside the include directory. This is untested with large files and archives. Use at your own risk!

Get the source code from GitHub:
https://github.com/d0k3/ZIP3DSFX

ZIP3DSFX contains the MiniZ library, which was written by Rich Geldreich: https://code.google.com/p/miniz/

d0k3
Posted on 12-22-15 01:25 PM, in Decrypting SD DSiWare Exports? (rev. 2 of 12-22-15 01:42 PM) Link | #838
I just noticed that I did this wrong all the time... The DSiWare Exports are found in /Nintendo 3DS///Nintendo DSiWare. Everything else in that // folder is decrypted by a rather simple scheme of AES-CTR with an IV calculated from the path name. Not the DSiWare Exports though:
http://3dbrew.org/wiki/DSiWare_Exports

These use AES-CBC, and the IV for that seems to come from the 'Block Metadata' at the end of each section (if I got that right). Sections are Banner, Header, Footer, Content, and at the start of each section, I have to set the IV to the correct value.
DSiWare exported from 3DS use console-unique keyslots initialized by movable.sed. Each section is encrypted with AES-CBC.

Now, console-unique keyslots... I tried to bruteforce that, but no success so far. I'm also unsure if I can just use the keyY from movable.sed with each and every AES keyslot in the range from 0x10 - 0x40, without any danger of damaging my console.

Any ideas on how to proceed with that?

EDIT: Forgot about that... I'm also unsure about endianness and order. I'd assume it is the same as for everything else on the SD though.

d0k3
Posted on 12-22-15 07:14 PM, in Decrypting SD DSiWare Exports? Link | #840
Posted by profi200
Don't really see the need for this if you just can decrypt twln. The effort to implement this is not worth the gain.
The required AES keyslot is documented on the AES Registers page.

Well, that should be 0x34 then, same as with everything else in that folder. But you're right, at a second look this looks like as much effort as for CIA decryption (the contents themselves also consist of multiple sections), and that was a lot.

d0k3
Posted on 12-28-15 11:39 AM, in Decrypting SD DSiWare Exports? Link | #846
Alright, found it! After recognizing the effort that would have to be put into this, I decided to put this on ice for now. Although an interesting project, this is not even that useful for now. Will see about that later. Thank you!
Pages: 1 2 3 4

Main - Posts by d0k3

Page rendered in 0.021 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 89/89, time: 0.013 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.