|
| ||
| Views: 1,609,354 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-21-24 06:02 PM |
| Guest: | ||
| 0 users reading Decrypting the NAND title.db / import.db | 1 bot |
| Main - Homebrew discussion - Decrypting the NAND title.db / import.db | Hide post layouts | New reply |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 63/75 EXP: 38196 Next: 4243 Since: 06-04-15 Last post: 3251 days ago Last view: 2998 days ago |
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 |
| ||
|
Member Normal user Level: 20 Posts: 64/75 EXP: 38196 Next: 4243 Since: 06-04-15 Last post: 3251 days ago Last view: 2998 days ago |
... I guess this should have gone into the new 'Reverse Engineering' subforum. Any chance this can be moved there? |
| profi200 |
| ||
|
Member Who knows? Level: 19 Posts: 40/70 EXP: 34508 Next: 1269 Since: 05-21-15 From: Germany Last post: 2993 days ago Last view: 2861 days ago |
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 |
| ||
|
Member Normal user Level: 20 Posts: 65/75 EXP: 38196 Next: 4243 Since: 06-04-15 Last post: 3251 days ago Last view: 2998 days ago |
Posted by profi200 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 |
| ||
|
Newcomer Normal user Level: 7 Posts: 3/7 EXP: 1063 Next: 385 Since: 11-14-15 Last post: 3074 days ago Last view: 2964 days ago |
Posted by profi200 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 |
| ||
|
Newcomer Normal user Level: 7 Posts: 4/8 EXP: 1330 Next: 118 Since: 06-02-15 Last post: 2996 days ago Last view: 2796 days ago |
Posted by 54634564 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 |
| ||
|
Newcomer Normal user Level: 7 Posts: 4/7 EXP: 1063 Next: 385 Since: 11-14-15 Last post: 3074 days ago Last view: 2964 days ago |
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: https://i.imgur.com/RdklqTF.png Top is from decrypted NAND, bottom encrypted. 0xB0E00 is at 0x4E00 into my ticket.db. |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 66/75 EXP: 38196 Next: 4243 Since: 06-04-15 Last post: 3251 days ago Last view: 2998 days ago |
Posted by 54634564 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 |
| ||
|
Member Normal user Level: 20 Posts: 67/75 EXP: 38196 Next: 4243 Since: 06-04-15 Last post: 3251 days ago Last view: 2998 days ago |
I checked it and you were right. The only difference is that it is zeroes for me, not 0xFF.
![[image]](https://i.imgur.com/e4xHAed.png)
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 |
| ||
|
Member Normal user Level: 18 Posts: 45/59 EXP: 26089 Next: 3808 Since: 10-26-15 Last post: 3234 days ago Last view: 3184 days ago |
Posted by d0k3 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. That's all what i wanna say. Hope you good luck. |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 68/75 EXP: 38196 Next: 4243 Since: 06-04-15 Last post: 3251 days ago Last view: 2998 days ago |
Posted by Syphurith 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 |
| ||
|
Member Normal user Level: 20 Posts: 69/75 EXP: 38196 Next: 4243 Since: 06-04-15 Last post: 3251 days ago Last view: 2998 days ago |
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 | Hide post layouts | New reply |
|
Page rendered in 0.019 seconds. (2048KB of memory used) MySQL - queries: 28, rows: 87/87, time: 0.006 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
