4dsdev
Views: 614,208 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-24-17 04:54 PM
Guest:

0 users reading Decrypting the NAND title.db / import.db | 1 bot

Main - Homebrew discussion - Decrypting the NAND title.db / import.db New reply


d0k3
Posted on 11-22-15 07:29 PM 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 Link | #760
... I guess this should have gone into the new 'Reverse Engineering' subforum. Any chance this can be moved there?

profi200
Posted on 11-23-15 12:49 PM Link | #761
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.

d0k3
Posted on 11-23-15 01:11 PM (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!

54634564
Posted on 11-23-15 04:47 PM (rev. 3 of 11-23-15 05:01 PM) Link | #764
Posted by profi200
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.

Wow, when did you become admin here profi? Congrats on the promotion!

That's it, d0k3. Might as well just delete your posts, can't discuss this. So saith lord profi200.


On a serious note...I don't think people have looked into these files too extensively. That's the reason you probably won't be getting any answers, not any "moral" stuff.
Hell, yellows8 thought there was extra crypto on the tickets in tickets.db up until late last year(there isn't):
http://3dbrew.org/w/index.php?title=Title_Database&action=historysubmit&diff=9857&oldid=8384

dark_samus
Posted on 11-23-15 05:51 PM Link | #765
Posted by 54634564
Wow, when did you become admin here profi? Congrats on the promotion!

That's it, d0k3. Might as well just delete your posts, can't discuss this. So saith lord profi200.


On a serious note...I don't think people have looked into these files too extensively. That's the reason you probably won't be getting any answers, not any "moral" stuff.
Hell, yellows8 thought there was extra crypto on the tickets in tickets.db up until late last year(there isn't):
http://3dbrew.org/w/index.php?title=Title_Database&action=historysubmit&diff=9857&oldid=8384


The main "moral" dilemma is that some nasty stuff can be done with those files (like bricking a console) ofc this can be done with other methods but it's much easier to do it this way (though in argument to that it would be MUCH easier to just put a blank file there which can already be done so...)

54634564
Posted on 11-23-15 11:09 PM (rev. 6 of 11-23-15 11:19 PM) Link | #767
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.

d0k3
Posted on 11-24-15 04:25 AM (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 (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?

Syphurith
Posted on 11-24-15 02:09 PM Link | #772
Posted by d0k3
Hi

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.

d0k3
Posted on 11-24-15 04:12 PM 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 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.


Main - Homebrew discussion - Decrypting the NAND title.db / import.db New reply

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