|
| ||
| Views: 1,393,881 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 04-19-24 08:30 AM |
| Guest: | ||
| Main - Posts by d0k3 |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 61/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
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 |
| ||
|
Member Normal user Level: 20 Posts: 62/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
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 |
| ||
|
Member Normal user Level: 20 Posts: 63/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 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: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
... I guess this should have gone into the new 'Reverse Engineering' subforum. Any chance this can be moved there? |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 65/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 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! |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 66/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 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: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 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? |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 68/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 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: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 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. |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 70/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
Posted by gudenau I can't help with that, just wanted to say thumbs up for the success of this project. Sounds very interesting! |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 71/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
Maybe this can help you. |
| d0k3 |
| ||
|
Member Normal user Level: 20 Posts: 72/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
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 |
| ||
|
Member Normal user Level: 20 Posts: 73/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
I just noticed that I did this wrong all the time... The DSiWare Exports are found in /Nintendo 3DS/ 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.
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 |
| ||
|
Member Normal user Level: 20 Posts: 74/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
Posted by profi200 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 |
| ||
|
Member Normal user Level: 20 Posts: 75/75 EXP: 36981 Next: 5458 Since: 06-04-15 Last post: 3034 days ago Last view: 2781 days ago |
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! |
| Main - Posts by d0k3 |
|
Page rendered in 0.072 seconds. (2048KB of memory used) MySQL - queries: 22, rows: 89/89, time: 0.020 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
