4dsdev
Views: 1,598,986 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 10-07-24 08:02 PM
Guest:

Main - Posts by Syphurith

Pages: 1 2 3
Syphurith
Posted on 10-26-15 02:03 PM, in Is there any way to unpack system CIAs ? (rev. 3 of 10-26-15 02:05 PM) Link | #576
I'm quite noob here but i'd like to try to answer this.
I found no way to directly decrypt the system CIAs that get from Ninty's CDN. Even with decrypted title keys the decrypted content still seems encrypted/a mess.
The only way for me now, is to install the CIA, to the EmuNand, then decrypt and dump those System Apps with RxTools.

Once it is dumped, you could see lots of .app files in your SD card root.
Just look for the title id you'd like to see, it should be fully decrypted, and just with ctrtool or whatever you could unpack it.

Maybe with a later release of rxTools it would allow users to just decrypt and dump several ones that users asked and written in a text file.
If there is any way to fully decrypt the contents i'd be quite happy to see it.

Syphurith
Posted on 10-29-15 11:18 AM, in Decompressed code.bin & 3DS Command Header? (rev. 2 of 10-29-15 03:00 PM) Link | #600
Sorry if I posted in a wrong section of this forum. What i faced may be a little noobish. So this is more like discussion than released information.

I think all those Command Headers of services in 3dbrew should be legit, however i had not ever found part of any Header value in those decompressed code.bin of those system modules. Maybe the service module is placed when being initialized? These seems to be an initializer included in very beginning of code.bin.

And? let me show you a little tool.
I've written a little tool to recognize those NCCHs from a section file provided. Mostly it was made for the section NATIVE_FIRM_ARM11_1FF00000 of decrypted FIRM from 9.8.0J. With it i got those NCCHs of fs, loader, pm, pxi, sm. You could compile it with "gcc -O3" if you want. C Source of This tool URL
How to get the section? Well still you could do it manually.. with hex editors, following offsets ctrtool tells you.
BTW i had not ever successfully loaded any NCCH just with the ctr_ldr.py..

Syphurith
Posted on 10-29-15 12:49 PM, in Injecting other apps over Health & Safety? (rev. 4 of 10-29-15 12:56 PM) Link | #601
I wrote a tool to replace the encrypted parts of original file to decrypted one.
Comparison between original H&S, and FBI injection, with those decrypted NCCHs:
Romfs, Exheader, Exefs: Mismatch. Inside Exefs: code.bin is touched. It seems little was not changed..
Here you can get the tool: DecryptedReplacer. Source code included

DecryptedReplacer.exe 00000002.app exefs.bin decrypted_exefs.bin exheader.bin decrypted_exheader.bin romfs.bin decrypted_romfs.bin
It would produce a "00000002.app.decrypted" for this example. Just load it with ctrtool to extract the content.
Note this tool can also let you replace those decrypted parts to encrypted ones.
Hope this tool could help you.However i don't know how to generate a injectable version of anything yet.
Maybe you can inject one that Size just smaller than the xorpad? You see most contents are touched. Exactly, FBI's exefs is bigger than H&S.

Syphurith
Posted on 10-29-15 02:39 PM, in Injecting other apps over Health & Safety? (rev. 11 of 10-29-15 04:20 PM) Link | #603
The .app content is indeed a CXI. Cause we would need to repack the exefs and CXI, i think 3dstool is better for it. However i don't know how to create a valid TMD file..
Here are some steps provided.. Note: Old method with DecryptedReplacer is now in spoiler.

1.Unpack Old CXI. NCSD Header is saved in this step.

3dstool -xvtf cxi 00000002.app.decrypted --header ncchheader.bin --exh exh.bin --plain plain.bin --exefs exefs.bin --romfs romfs.bin
This decrypted CXI is needed, you can use DecryptedReplacer to replace the encrypted contents to decrypted ones.
Or Just try unpack the encrypted one with 3dstool.
3dstool -xvtf cxi 00000002.app --header ncchheader.bin --exh exh.bin --plain plain.bin --exefs exefs.bin --romfs romfs.bin --exh-xor 0004001000020300.Main.exheader.xorpad --exefs-xor 0004001000020300.Main.exefs_norm.xorpad --romfs-xor 0004001000020300.Main.romfs.xorpad
EDIT: Figured out the logo.bcma.lz isn't actually needed when repacking.

2.Unpack Old Exefs. Indeed you might done this in the step above with a specified argument. Not for 3dstool.
3dstool -xvtfu exefs exefs.bin --header exefsheader.bin --exefs-dir exefs

3.Now overwrite the contents, including romfs.bin, code.bin, and exheader.bin.

4.Rebuild the Exefs. If you don't have the header, take it from original exefs.bin, 0x0-0x200 bytes.
3dstool -t exefs -c --exefs-dir exefs -f exefs.bin --header exefsheader.bin
Note: 3dstool need icon.icn, banner.bnr inside the exefs folder.


5.Repack it as a CXI. If romfs=0KB, just remove that "--romfs romfs.bin".
3dstool -cvtf cxi 0.cxi --header ncchheader.bin --exh exh.bin --plain plain.bin --exefs exefs.bin --romfs romfs.bin
From here to step 7, you can do so with only one command, with extra parameters. See step 5b
Well really you can take banner.bnr as banner.bin, icon.icn as icon.bin.

6.Now Xor your binaries to encrypt. Just use those xorpads with padxorer to encrypt. Don't mind that "decrypted_" prefix.

7.Since you have a decrypted CXI "0.cxi" now, you could use the DecryptedReplacer to replace those decrypted parts to encrypted ones. Yes see the post above.
DecryptedReplacer.exe 0.cxi exefs.bin decrypted_exefs.bin exh.bin decrypted_exh.bin romfs.bin decrypted_romfs.bin
Then you could have an encrypted CXI "0.cxi.decrypted". I said please don't mind the "decrypted" text.

5b.Repack it, also apply the xorpads.
3dstool -cvtf cxi 1.cxi --header ncchheader.bin --exh exh.bin --plain plain.bin --exefs exefs.bin --romfs romfs.bin --exh-xor 0004001000020300.Main.exheader.xorpad --exefs-xor 0004001000020300.Main.exefs_norm.xorpad --romfs-xor 0004001000020300.Main.romfs.xorpad
Yes, note the CXI "1.cxi" is now encrypted. And that is actually the same file by DecryptedReplacer.

Now? what blocks me from going further is the TMD. I don't know how to generate it properly.
I've compared several TMDs, and tried to gain one from makerom then unpack, however still no success.

Syphurith
Posted on 10-29-15 02:59 PM, in Decompressed code.bin & 3DS Command Header? (rev. 2 of 10-29-15 03:02 PM) Link | #604
Posted by plutoo
I use the following I made a while back to extract them:
https://github.com/plutooo/ctr/commit/52d7df6b7cc7896c31dc1cf767fe47df1827ed7d

Thanks for that. However i didn't know and already made a tool to extract those NCCHs from the section....
Any thoughts about the command header? It's quite weird for me.

Syphurith
Posted on 10-29-15 03:10 PM, in Decompressed code.bin & 3DS Command Header? (rev. 3 of 10-29-15 03:13 PM) Link | #606
Posted by plutoo
They were there last time I checked. Some modules are compiled to Thumb code instead of ARM, and those will not have the command-header values precalculated in the code. Instead they will call the unoptimized function to generate those dynamically.

Then would there be some precalculated ones in other modules? I've tried cfg from 9.8 just minutes ago, and no such command header is found.. Maybe I'm silly?
Whatever thanks for your patience answering me the question.Would try use a decrypted cfg from 4.1..

Syphurith
Posted on 10-29-15 03:33 PM, in Decompressed code.bin & 3DS Command Header? Link | #608
Posted by plutoo
Yeah, and if there are no marshalled parameters by the kernel, the command header is not checked at all (that would be a useless check anyway, from a security pov).

Mind you tell me which system version of those system titles was checked, when those command header could be found? I've checked 4.1 cfg minutes ago, and I seemed to load it wrongly. Hex search produced no result of 0x00010082 inside its code.bin.
However when checking 9.8 cfg there is quite a bulk of Thumb in its beginning.. Maybe I've searched a wrong module..

Syphurith
Posted on 10-29-15 03:42 PM, in Decompressed code.bin & 3DS Command Header? Link | #610
Posted by plutoo
Yeah, probably. Most of them are actually ARM, shouldn't be too difficult to find one..

Then I would forget checking those inside Thumb modules.
Oh so still i would have to use the outdated sig file or read myself.
My question is solved totally, much thanks. Have a good day.

Syphurith
Posted on 10-29-15 07:15 PM, in Injecting other apps over Health & Safety? (rev. 3 of 11-02-15 09:14 AM) Link | #611
Finally got the HASH update to work. However it seems I built a wrong APP file..
Working TMD Hash Updator Source code included. At least it could pass RxTools verification.
There is already an updated version of it on the next page, so this link is removed.
Calculation: URL from gbatemp.net
Of what is the TMD content info hash a hash? I presume they also need to be updated, not only the TMD content hash.
There are 3 hashs,
first (0xB14) hashes the content (app file),
second (0x208) hashes the content table (0xB04 - 0xB33)
third (0x1E4) hashes the content index table (0x204 - 0xB03)
All simple sha256.

And 0xB0C, the content length should be updated too. - If the length was touched.

Syphurith
Posted on 10-30-15 05:03 AM, in Is there any way to unpack system CIAs ? Link | #615
Posted by Mrrraou
Actually, I found that Decrypt9 has an option to decrypt CIAs, and it worked.
Just use the latest version of Decrypt9 and put the CIA in a folder "D9decrypt" on your SD card, then start Decrypt9, there is an option to decrypt CIAs.

Thank you for that. I had to admit Decrypt9 is better option for decrypting things..
So next time i could try it when don't want to install the CIA.

Syphurith
Posted on 10-30-15 05:05 AM, in Injecting other apps over Health & Safety? (rev. 2 of 10-30-15 05:07 AM) Link | #616
I'm glad to see you have already know how to build the TMD..
Posted by d0k3
What would help me a lot would the H&S app files for various FW versions, so that I can compare them to Rikus FBI inject files. Any idea how I can get them?

Do you mean that where to get precompiled and ready-for-use app and tmd files for injection? If so you can just take a look at rxTools release package, there is /tools/fbi_inject// app and tmd in it. Most of those should be correctly created.
But i wonder how exactly to build a valid .app file. I've tried to replace the exefs (so banner, icon, logo would be changed also), and repacked and re-encrypted it back. However once i tapped it in EmuNand, it just show a black screen and poped out an error. I should have some faults while creating the CXI..
Hope you can get a valid tool, either for Decrypt9, or for PC.

Syphurith
Posted on 10-30-15 10:15 AM, in Injecting other apps over Health & Safety? (rev. 9 of 10-31-15 04:14 AM) Link | #619
Posted by d0k3
I'm pretty sure we'll get this to work :). I already knew about the valid inject files from the rxTools archive. What I'm searching for is the original, untouched H&S app & tmd, best for multiple regions/version. I can't get it from my own system, cause there are no valid injects available for N3DS.

Oh now I understood. I would upload a H&S app from my decrypted NAND, from 9.8 and 4.1, JPN.
Could i post those links? I mean it might be illegal? Note that the xorpads for different versions are different - cause different names.

Oh yes, anyway, I've packaged it. 2050 (9.8) and 1024(4.1) included. Password for that zip file is its filename, NO extension, NO spaces. Here it goes! Link removed. Please tell me once you get this file, and let it purge it off. Banned from 3dsdev, i can not deliver you the link more secured.
I think you should read all those content of this single post carefully. Thanks. Hope it helps you, even a little.

Syphurith
Posted on 10-30-15 11:35 AM, in Certain apps crash on launch; problem is persistent across NAND images. Link | #620
I second the post by nopy. The NAND chip of your new 3ds is a MLC one, which holds 2 bits in a cell. MLC has a typical write lifespan as 10K times for every cell, however this is for MicroN produced ones, Check here for typical times. Not only your flashing would cost its write cycles, the normal use of your console, when writing files, would cost some too. So, I doubt what stored in your NAND has already been broken.
To check it is or not, just get your NAND Fat xorpad to decrypt both images, the "working" one you flash which was dumped when it was working at last, and the "current" one you dumped after flash the "working" one. Decrypt both images with xorpad, and extract the "titles" folder to be compared, you can use the tool WinMerge2011 for such comparison.
If you don't care about totally brick it, or it confirmed your NAND chip is worn out, you might want to try replace the chip yourself. If so, good luck - the chip is just around where you connect the pins, not hard to be found, and please notice you better get a same chip of product id.

Syphurith
Posted on 10-30-15 04:05 PM, in Decompressed code.bin & 3DS Command Header? (rev. 2 of 10-30-15 04:12 PM) Link | #623
Posted by plutoo
==Snip==

Sorry to disturb you again, but .... I've found a title hidden in FIRM, which is called PROCESS9, Titleid 0004013000003000.
This is found in the SAFE_MODE FIRM, also 5 modules of their SAFE_MODE edition is found.
Now this is the new link of the tool.. Here it goes If you'd like to play with it..
Eh.. Sorry this might already be known to you all, since Process9 is described on Page "FIRM" on 3dbrew.

Syphurith
Posted on 10-31-15 04:41 AM, in Injecting other apps over Health & Safety? (rev. 12 of 10-31-15 05:32 AM) Link | #628
Posted by d0k3
Alright, thanks a ton! Got it, so you can remove it. Which single post do you mean? I'll look over the files and will see what I can say about them later!

Well i was hoping for your getting the file, and now link is removed.
Posted by d0k3
--Snip--

Wait a minute for me to inject it in.. Confirmed to be 1.3.8. However minor version isn't known. This inject app git version: 876adcfcadda127be7dc292c5f21c07bcb11cd48, 1.3.8 release on May 3rd, 2015. code.bin matches. Compared FBI.cia to fbi_inject.app.... And you're right, exheader is nearly same from fbi. code.bin the exactly same. banner.bin and icon.bin are same as original H&S, while romfs is empty.

The generated inject app and tmd for 2050 JPN O3DS, is exactly the same file from rxTools..
Wait WTF? the app file and rxtools one are the same, and xorpads are all the same, however those code.bin lengths mismatch!
Loaded the code.bin into ida, and it shows all data.. Confused.. However it works.. lol.
Problem solved, due to wrong behavior of ctrtool. Once used 3dstool to unpack the file, the code.bin matches the one from rxTools fbi_inject.app.
Anyway, forget about it.. Just use 3dstool when ctrtool goes wrong.

Eh.. Maybe the exe contains some interesting things too, cause it request a tmd.

Syphurith
Posted on 10-31-15 03:41 PM, in Injecting other apps over Health & Safety? (rev. 3 of 10-31-15 03:43 PM) Link | #631
Posted by profi200
Don't link or share copyrighted content here.

Sorry and won't happen again.
Extra: It seems i am blocked/banned on 3dsdev, might be the cause of supporting rxTools. However this stops me from sending it to him more easily/securely..
Posted by d0k3
--Snip--

Quite happy to see you figured out the details. Eh let me check it myself again..
Compared material : the decrypted exheader of FBI.app and fbi_inject/Riku-Generated-edition, and H&S. fbi_inject.app from rxTools and the Riku generated one are exactly the same (hashed). FBI.app is extracted from the FBI.cia with ctrtool, from FBI 1.3.8 release.
To be short, I would just show you what is modified from normal FBI exheader, that is adjusted to H&S one. Style: Addr + Length.
Note: This might be a minimum requirement..
0x000 + 0x8 , 0x00C + 0x4 , 0x1C8 + 0x4 , 0x1CC + 0x4 , 0x200 + 0x8 , 0x248 + 0x1 , 0x600 + 0x8 , 0x648 + 0x1
So, i could overwrite inject app exheader, by 0x0 + 0x16, 0x1C8 + 0x8, 0x200 + 0x8, 0x248 + 0x1, 0x600 + 0x8, 0x648 + 0x1 in short.
Extra: Well i would recommend for a binary comparison by some script next time for such jobs..
And, yes we should try combined system access first..

Syphurith
Posted on 10-31-15 03:58 PM, in Injecting other apps over Health & Safety? (rev. 2 of 10-31-15 03:59 PM) Link | #632
Posted by d0k3
--Snip--

Eh.. I get a purely legal way for you to get those .app file next time. You don't need to install them!

1. Get your Decrypt9 compiled and set up.
2. Get the packed cia version of the title via 3dnus.
3. Place those encrypted ones into your sdmc:/D9Decrypt.
4. Use decrypt9 to decrypt the cia! with a deep method.
5. Use ctrtool to extract those contents from the decrypted cia. You can extract the TMD too.
6. Note that the 0000 part of the contents might be a NCCH.
7. Now as you've get the decrypted NCCH, and TMD. Jobs done.
Yes so it could be done in this way.. Haven't check extracted ones against the decrypted normal ones..
I don't care about this any more. Since you can check it yourself if you wish.
You can get those EUR/USA/KOR/CHN ones. Well older title might be found in that ISO site.
Thanks for this guy in this post for this, i don't know that could before. Hope the progress goes smoothly.

Syphurith
Posted on 11-01-15 03:22 PM, in Injecting other apps over Health & Safety? (rev. 3 of 11-01-15 03:33 PM) Link | #639
Posted by d0k3
--Snip--
I guess CTRtool & Makerom will be able to do a lot of that stuff, and for the remainder, a small program I'll code we'll do. I didn't get your fix TMD code to work, though. Any more ideas?

Your plan sounds good. Well I doubt what if the injected app have romfs.... And the actual sizes of exefs differ - at least of FBI and H&S.
What the Fix TMD posted is just for hashing, and content size update. It get the size of the .app, set it to update, and re-calculate those 3 hashes. I think you'd already know how to calculate the hashes. When i was trying to build a injectable file, I forgot to compare the other files, so i didn't find that difference of exheader.
Eh for ctrtool.. yes all okey, but please try 3dstool if extraction went wrong - i've experienced such thing.
Well nothing now. Except i wonder the size could really affect that much.
Hope your customized build of any other app could be. FBI is written in C++, and built with citrus/aemstro/ctrcommon/picasso/libctru, and i doubt if latest version could fit in the size. Checked - not much bigger than original H&S. It might fit..
Also to note that, you might want to try to inject a version into your N3DS. Once you plan to do so, please have you NAND backup and Nand Xorpad with you. Good luck.

Syphurith
Posted on 11-01-15 04:20 PM, in Injecting other apps over Health & Safety? Link | #641
Posted by d0k3
Continuing from here... If we had a tool (or two) that could inject ExeFS, RomFS and ExtHeader into an existing CXI (while also taking care of the hashes/offsets/sizes in the NCCH header AND touching the rest as little as possible), I think the rest would be manageable. Is there anything such as this?

For this purpose, you might try DecryptedReplacer (or dd?). Its theory is quite plain, and it only replace the same sized content from A to B. Just padding all those binaries size first, all parts should be smaller than original. You would still have to create a valid tmd and exheader and hashes.
I was thinking of using 3dstool/ctrtool/makerom to do its unpack/repack. And after that all we need to do might be to recreate the exheader and tmd.
Well indeed 3dstool is best for NCCH/CXI. However i didn't tested the other files it generated, that the ncchheader.bin. It could always generate a valid CXI if proper material is given, cause the tool is invented for tranlation purpose. Yes, not always the exefs.bin and romfs.bin could be the same for them..

Syphurith
Posted on 11-02-15 04:20 AM, in Injecting other apps over Health & Safety? Link | #647
Posted by d0k3
--Snip--

3dstool supports reading a decrypted file without xorpad, or reading an encrypted one with xorpad. When with xorpad, please remember to use those --XX-xor arguments.

Eh, the TMD fixer is written by myself. Since the zip file contains its source code, you might want to simply take a look of it. All it does is quite simple, to recalculate those SHA-256 hashes. Note: the previous post contains the link to its source. But not in the package when i harmed the rules.
I compiled it in MSYS2 - mingw64 mode, with my win 8.1 x64 PC. If you really can't get it compiled, you may want to write one yourself. Below is all what it does.

1.Read original TMD file. To make it easier, it loads the whole file into memory.
2.Read repacked APP file. Yes still loaded the whole, indeed it could be done better with sha2_file. The file size and the hash is needed, and the size may be get from fstat calls. Notice the size stored in what an order.
3.Update TMD: 0x0B14 + 0x32 : app hash. 0x0B0C + 0x8 : app size. The third part of TMD is updated.
4.Sha2: 0x0B04 + 0x30.. Update TMD: 0x0208 + 0x32 : hash of this third part. Second part done.
5.Sha2: 0x0204 + 0x900.. Update TMD: 0x01e4 + 0x32 : the hash of the second part.
Still i don't know exactly why it can't compile. Could you show me your compilation log?

An updated version of FixTmd: Here it is. It would accept other APP and TMD names, see its output. Source included.
Pages: 1 2 3

Main - Posts by Syphurith

Page rendered in 0.059 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 99/99, time: 0.009 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.