Hacking 3DS Application Metadata Decoder

[HXC]

Hello people. i'm currently writing a C++ console APP that will decipher the data inside of application metadata files.
these are usually located under a path like this: /SDHC_NAME/3ds/Application/8_DIGIT_HEX_CODE/data/.metadata (the files never have a textual name, just an extension)

some of the information that can be found include:
Title Name
SHA256 Key (for the application)
Issuer
Boot Contents
Access Rights
and loads of other information. i am also working on a rewriter to for these metadata files
(could prove usefiull ** CHANGE THE APPLICATIONS ACCESS RIGHTS**)

i'll post up links when completed. i still have to run some testing with it to make sure it works. however there is no guarantee that the information will be very accurate
as some of the information is limited (Like the chunk info records for instance)

 

[Dingoo-fan 32]

What is this exactly?

 

[DeMoN]

(could prove usefiull ** CHANGE THE APPLICATIONS ACCESS RIGHTS**)

Does this mean what I think it means?

 

[rondoh70]

I would love to know how this is done unless niemod gave you the public key.

 

[HXC]

What is this exactly?

let me explain. the metadata file is a specially formated file that is used to describe a standalone title (like rhythmic retrobits for example) or channel (like nintendo zone) and all of it's installed contents. the file is only generated once, by either the system or the issuer, and could potentially be edited to contain false data or allow additional features (changing specific bytes would allow the application to go into a debug like mode). however certain applications will crash if the metadata file is missing or changed (rhythmic retrobits won't start on my 3ds when i remove the file) i can post up an example file if people want to view it and what not.

 

[3DSGuy]

Hello people. i'm currently writing a C++ console APP that will decipher the data inside of application metadata files.
these are usually located under a path like this: /SDHC_NAME/3ds/Application/8_DIGIT_HEX_CODE/data/.metadata (the files never have a textual name, just an extension)

some of the information that can be found include:
Title Name
SHA256 Key (for the application)
Issuer
Boot Contents
Access Rights
and loads of other information. i am also working on a rewriter to for these metadata files
(could prove usefiull ** CHANGE THE APPLICATIONS ACCESS RIGHTS**)

i'll post up links when completed. i still have to run some testing with it to make sure it works. however there is no guarantee that the information will be very accurate
as some of the information is limited (Like the chunk info records for instance)

Umm... :

1/ that directory structure is completely wrong
2/ all of the data on the SD card is encrypted
3/ Access rights are held in the ExHeader of the encrypted CXI, not the title meta data
4/ There isn't any key in the title meta data
5/ you can't change anything without re-signing

Perhaps you should read up on the TMD format, and the SD card filesystem.

 

[HXC]

Hello people. i'm currently writing a C++ console APP that will decipher the data inside of application metadata files.
these are usually located under a path like this: /SDHC_NAME/3ds/Application/8_DIGIT_HEX_CODE/data/.metadata (the files never have a textual name, just an extension)

some of the information that can be found include:
Title Name
SHA256 Key (for the application)
Issuer
Boot Contents
Access Rights
and loads of other information. i am also working on a rewriter to for these metadata files
(could prove usefiull ** CHANGE THE APPLICATIONS ACCESS RIGHTS**)

i'll post up links when completed. i still have to run some testing with it to make sure it works. however there is no guarantee that the information will be very accurate
as some of the information is limited (Like the chunk info records for instance)

Umm... :

1/ that directory structure is completely wrong
2/ all of the data on the SD card is encrypted
3/ Access rights are held in the ExHeader of the encrypted CXI, not the title meta data
4/ There isn't any key in the title meta data
5/ you can't change anything without re-signing

Perhaps you should read up on the TMD format, and the SD card filesystem.

umm....

according to this: http://3dbrew.org/wiki/Title_metadata

i have been doing my homework, sir. this file is preliminary and will obviously be changed at some point. this program simply return a log of what the TMD might contain. the rewriter comes later. however since you are so keen on this subject then why not either try to help me, or make your own? or at least something else but complain to me about simplistic inaccuracy?

 

[3DSGuy]

Hello people. i'm currently writing a C++ console APP that will decipher the data inside of application metadata files.
these are usually located under a path like this: /SDHC_NAME/3ds/Application/8_DIGIT_HEX_CODE/data/.metadata (the files never have a textual name, just an extension)

some of the information that can be found include:
Title Name
SHA256 Key (for the application)
Issuer
Boot Contents
Access Rights
and loads of other information. i am also working on a rewriter to for these metadata files
(could prove usefiull ** CHANGE THE APPLICATIONS ACCESS RIGHTS**)

i'll post up links when completed. i still have to run some testing with it to make sure it works. however there is no guarantee that the information will be very accurate
as some of the information is limited (Like the chunk info records for instance)

Umm... :

1/ that directory structure is completely wrong
2/ all of the data on the SD card is encrypted
3/ Access rights are held in the ExHeader of the encrypted CXI, not the title meta data
4/ There isn't any key in the title meta data
5/ you can't change anything without re-signing

Perhaps you should read up on the TMD format, and the SD card filesystem.

umm....

according to this: http://3dbrew.org/wiki/Title_metadata

i have been doing my homework, sir. this file is preliminary and will obviously be changed at some point. this program simply return a log of what the TMD might contain. the rewriter comes later. however since you are so keen on this subject then why not either try to help me, or make your own? or at least something else but complain to me about simplistic inaccuracy?

Have you seen 3DSExplorer, it's an open source C# program which can read many 3DS file formats including TMD.

 

[HXC]

Hello people. i'm currently writing a C++ console APP that will decipher the data inside of application metadata files.
these are usually located under a path like this: /SDHC_NAME/3ds/Application/8_DIGIT_HEX_CODE/data/.metadata (the files never have a textual name, just an extension)

some of the information that can be found include:
Title Name
SHA256 Key (for the application)
Issuer
Boot Contents
Access Rights
and loads of other information. i am also working on a rewriter to for these metadata files
(could prove usefiull ** CHANGE THE APPLICATIONS ACCESS RIGHTS**)

i'll post up links when completed. i still have to run some testing with it to make sure it works. however there is no guarantee that the information will be very accurate
as some of the information is limited (Like the chunk info records for instance)

Umm... :

1/ that directory structure is completely wrong
2/ all of the data on the SD card is encrypted
3/ Access rights are held in the ExHeader of the encrypted CXI, not the title meta data
4/ There isn't any key in the title meta data
5/ you can't change anything without re-signing

Perhaps you should read up on the TMD format, and the SD card filesystem.

umm....

according to this: http://3dbrew.org/wiki/Title_metadata

i have been doing my homework, sir. this file is preliminary and will obviously be changed at some point. this program simply return a log of what the TMD might contain. the rewriter comes later. however since you are so keen on this subject then why not either try to help me, or make your own? or at least something else but complain to me about simplistic inaccuracy?

Have you seen 3DSExplorer, it's an open source C# program which can read many 3DS file formats including TMD.

yes, however i run linux. (Fedora 12 to be exact), and that will not run (unless i spend hours installing MONO for C#, or configure WINE to work with dot net, if and IF it would work.)

 

[3DSGuy]

Hello people. i'm currently writing a C++ console APP that will decipher the data inside of application metadata files.
these are usually located under a path like this: /SDHC_NAME/3ds/Application/8_DIGIT_HEX_CODE/data/.metadata (the files never have a textual name, just an extension)

some of the information that can be found include:
Title Name
SHA256 Key (for the application)
Issuer
Boot Contents
Access Rights
and loads of other information. i am also working on a rewriter to for these metadata files
(could prove usefiull ** CHANGE THE APPLICATIONS ACCESS RIGHTS**)

i'll post up links when completed. i still have to run some testing with it to make sure it works. however there is no guarantee that the information will be very accurate
as some of the information is limited (Like the chunk info records for instance)

Umm... :

1/ that directory structure is completely wrong
2/ all of the data on the SD card is encrypted
3/ Access rights are held in the ExHeader of the encrypted CXI, not the title meta data
4/ There isn't any key in the title meta data
5/ you can't change anything without re-signing

Perhaps you should read up on the TMD format, and the SD card filesystem.

umm....

according to this: http://3dbrew.org/wiki/Title_metadata

i have been doing my homework, sir. this file is preliminary and will obviously be changed at some point. this program simply return a log of what the TMD might contain. the rewriter comes later. however since you are so keen on this subject then why not either try to help me, or make your own? or at least something else but complain to me about simplistic inaccuracy?

Have you seen 3DSExplorer, it's an open source C# program which can read many 3DS file formats including TMD.

yes, however i run linux. (Fedora 12 to be exact), and that will not run (unless i spend hours installing MONO for C#, or configure WINE to work with dot net, if and IF it would work.)

Well good luck making a linux version we need more linux tools. There is a ctrtool, that's coded in C if that helps(but again that's for windows). But you should know that a TMD is signed, any editing of TMD files, would require re-signing to make the 3DS accept it. And we don't have the RSA keys to re-sign them. Also how do you plan to introduce modified TMD files to the 3DS.

Also "3/ Access rights are held in the ExHeader of the encrypted CXI, not the title meta data" that is not a simplistic" was not pointing out a simplistic inaccuracy, it's quite important.

 

[zerov25]

Well the thread seems legit and he knows what is talking about so prob. he isn't a troll.

 

[3DSGuy]

Well the thread seems legit and he knows what is talking about so prob. he isn't a troll.

Actually there are quite a lot of inaccuracies in his posts, regarding to the format of TMD. But that doesn't mean someone can't learn, the structure is laid out on 3DBrew and there are two open source programs which can interpret the format.

 

[raulpica]

No, he isn't a troll - the idea behind this is genuine, so no need to ask for EXEs, call him a troll or anything.

He's a dev, he's trying to make a program, and we should applaud him for his dedication instead of trying to smite him.

Thanks.

 

[aalokishere]

is this called bruteforce?....u know about trying everything till we get somewhere?still hope this gets us somewhere and what raulpica said is true

 

[RupeeClock]

is this called bruteforce?....u know about trying everything till we get somewhere?still hope this gets us somewhere and what raulpica said is true

I don't think it's brute-forcing the decryption of something.
Usually in a brute-force attempt you have an application attempting thousands of sequential (or random) keys over and over on an encrypted bit of data.

Such attempts are usually in-vain though because data such as this is encrypted with a key of a very considerable length, I think at least 256 characters.
With current computational power, it would take every computer in the world, longer than the world is thought to have existed, to actually decrypt something of that complexity.

 

[SifJar]

Already done: http://git.daifukkat...f79fc4b;hb=HEAD

EDIT: Although I can't seem to compile it...may be a Windows issue though.
EDIT: Got it to compile, just needed an additional .h file to be included and a library linked.
EDIT: Tested it, seems to work. Using this TMD: http://nus.cdn.c.sho...00000032600/tmd, got this output:

Spoiler

3dstmd (c)2011 Alex Marshall "trap15" 
Signature type: RSA-2048 SHA-256
5F DC 41 FF  D0 04 3D C3   DB 66 96 53  FE 5C C5 D6
16 CF 16 6F  A3 3C BE AA   88 E8 9B A2  C2 33 5C 01
63 2B B5 B7  AD 83 DE 23   44 43 97 08  26 08 AB 0B
11 4B 2F DC  A2 13 79 A2   8C 94 BA 81  86 50 16 F4
BF A7 0D DD  52 2A 62 66   7A 7F AA 09  5A 21 8D 93
3F 13 AC 84  17 1E DF 80   73 0A A8 9B  D6 13 20 04
5E 5B A7 0F  9F 06 E9 05   1D 99 09 31  3D CB EA FC
BA D8 76 44  DD AB B3 47   3B F6 A3 7C  66 A1 7E 60
52 7C 74 32  EE A8 E5 C9   77 CC C8 E5  0F 9F 50 E1
7B 4B 6B 84  75 E7 8C EC   7B B4 7D A3  4F 76 22 AA
76 81 CE 39  96 A6 CB CD   6F 7B 52 38  FC 3C 42 89
ED C9 79 54  58 1A 09 C4   6B A3 0E 92  58 95 A9 04
60 18 24 24  C8 F1 50 63   AF 61 D7 CD  DE 64 77 05
DE 05 29 43  15 17 28 B6   AC 62 31 FF  91 25 42 90
35 14 60 C8  D4 8E 12 18   DA EC 72 E8  B3 16 77 E0
F7 97 AC 2B  57 B8 18 1B   90 18 A1 F9  CA 2F 85 50
Issuer: Root-CA00000003-CP0000000b
TMD version: 1
CA CRL version: 0
Signer CRL version: 0
System version: 00000000-00000000
Title ID: 00040000-00032600
Title type: 0x00000040
Group ID: 0x0000
Access rights: 0x00000000
Title version: 0x0010
Number of contents: 2
Content 0:
Content ID: 0
Hash:
1F 4D FF 95  AF 78 82 6D   21 A4 BC 5B  82 C9 A4 FC
30 D6 7F B7  D7 CE 10 0E   37 F4 22 50  BD 6A B3 2C
Content 1:
Content ID: 2
Hash:
E4 99 3A ED  2F 79 94 6C   FD A4 D1 71  B6 34 DC 2D
82 E7 F2 92  3A C1 EB 90   E8 1E 0A 9B  5D D9 5C 59
Content 2:
Content ID: 0
Hash:
00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00
Boot content: 0x00000001
Banner content: 0x00000000
Banner size: 0x013D8000
Hash:
12 32 40 F0  5A 49 6B C1   A8 9E C4 31  D6 68 36 1A
EC 47 FC 9C  33 0A 63 DB   ED BD 02 E6  E6 4E 4A 02

Should compile without any modification on Linux, just run "gcc 3dstmd.c -o 3dstmd" in a terminal (assuming gcc is installed on your system).

If anyone wants to compile for Windows, make sure you have MinGW installed, then add "#include " (without quotes) after the other #includes in 3dstmd.c and then open a command prompt and run the command "gcc 3dstmd.c -o 3dstmd.exe -l ws2_32". The resultant 3dstmd.exe is then used like this: "3dstmd.exe TMD" (where TMD is the name of the TMD file). There's no real point though, as it's not any real use, and 3DSExplorer can do this anyway, as pointed out earlier in the thread.

EDIT: Actually, there is a small bug in trap15's code. It will display details of an extra content to what there actually is in the title. (e.g. in the above example, there are two contents, content 0 and content 1, but the output also shows content 2, with a hash of all 00s). To fix, it is very simple. Change this line from the function display_tmd():

for(i = 0; i num_contents; i++) {

to this

for(i = 0; i < tmd->num_contents; i++) {

 

[aalokishere]

is this called bruteforce?....u know about trying everything till we get somewhere?still hope this gets us somewhere and what raulpica said is true

I don't think it's brute-forcing the decryption of something.
Usually in a brute-force attempt you have an application attempting thousands of sequential (or random) keys over and over on an encrypted bit of data.

Such attempts are usually in-vain though because data such as this is encrypted with a key of a very considerable length, I think at least 256 characters.
With current computational power, it would take every computer in the world, longer than the world is thought to have existed, to actually decrypt something of that complexity.

i didn't mean the actual decryption part but rather the which file to be decrypted but thanks for the clarification