Homebrew Official [Download] Decrypt9 - Open Source Decryption Tools (WIP)

[Asia81]

Dumping tickets would be very useful :3

 

[Melon__Bread]

dumping tickets

If you could figure this out, you would be my hero.
No more: dumping nand -> making fat16 xorpads -> decrypting nand -> mounting decrypted nand -> copying ticket

 

[d0k3]

If you could figure this out, you would be my hero.
No more: dumping nand -> making fat16 xorpads -> decrypting nand -> mounting decrypted nand -> copying ticket

Wait, what tools are you currently using to decrypt & mount the NAND? As for porting rxTools functionality, no idea if it is possible yet, but I'll be sure to at least try.

 

[d0k3]

@Shadowtrance: I took a look at the Decrypt9 source code on GitHub. Now the complete Brahma source code is included in an additional folder called "Decrypt9", I see. And you actually run make in the "root dir" of your project, then "cd Decrypt9" and run make again. And somehow, magically this includes the .bin from first make into an all-in-one 3DSX file. I think that could all be done in one Makefile, but then you seem to be already much more capable in Makefiles then I am .

Could you tell me where the .bin from the first make is included in the second one? And, in theory, could I just replace the Decrypt9 source code by something, and it would be run via Brahma as well?

EDIT: I see, the .bin somewhere gets converted to a .h file (I'd still like to know where!). I think I could make a more beautiful "Brahma from .h file loader". The source code you adapted still contains a lot of unneccessary stuff. Anyways, I'll do a push request for that soon.

 

[Shadowtrance]

Yeah i changed it up so that it's only a single .3dsx and .smdh file now, just for neatness i guess instead of having bin files everywhere.
The only changes made to brahma were... main.c and brahma.c and obviously the makefile to reflect the name, icon etc instead of being brahma.

main.c
https://github.com/Shadowtrance/Decrypt9/blob/bootstrap-mod/Decrypt9/source/main.c#L45
https://github.com/Shadowtrance/Decrypt9/blob/bootstrap-mod/Decrypt9/source/main.c#L65
https://www.diffchecker.com/u1styute

brahma.c
https://github.com/Shadowtrance/Decrypt9/blob/bootstrap-mod/Decrypt9/source/brahma.c#L13
https://github.com/Shadowtrance/Decrypt9/blob/bootstrap-mod/Decrypt9/source/brahma.c#L262
https://www.diffchecker.com/cmpncgtn

And yeah there's no doubt a lot of unnecessary stuff there than has to be removed, i just haven't done it.

 

[Melon__Bread]

Wait, what tools are you currently using to decrypt & mount the NAND? As for porting rxTools functionality, no idea if it is possible yet, but I'll be sure to at least try.

I use 3DSFAT16tool.py to decrypt
Fuse via Linux to mount (although I hear if you just rename the decrypted nand with a .iso file extension you should be able to mount it with any iso mounting tools)

 

[d0k3]

I use 3DSFAT16tool.py to decrypt
Fuse via Linux to mount (although I hear if you just rename the decrypted nand with a .iso file extension you should be able to mount it with any iso mounting tools)

Okay, that does in fact sound tedious. But, you know, if you let the 3DS do the decryption (if it has to be done all-at-once), it will take a lot longer than on PC.

--------------------- MERGED ---------------------------

@Shadowtrance: Is this already taken care of?

ARM9 payload must consist of valid ARM9 executable code and will be
mapped to physical address 0x23F00000 during run-time. Its code should begin
with a branch instruction at offset 0 and a 'placeholder' for a u32
variable at offset 4, which will be filled by Brahma with a backup of
the original ARM9 entry point of the FIRM header during runtime.

I noticed something odd about the colours of your background (sometimes they seem to be different than on the run before), and not taking care of the above might be responsible. No idea on how to fix now, though. It might also be cared for with stub.ld... no idea .

 

[Shadowtrance]

Shadowtrance Is this already taken care of?
I noticed something odd about the colours of your background (sometimes they seem to be different than on the run before), and not taking care of the above might be responsible. No idea on how to fix now, though. It might also be cared for with stub.ld... no idea .

Erm... i dunno. Too tired to look at anything right now. As for the colours, they don't seem any different to me, and anyway the background is always black except the rectangles which are purple.

 

[d0k3]

Erm... i dunno. Too tired to look at anything right now. As for the colours, they don't seem any different to me, and anyway the background is always black except the rectangles which are purple.

Yeah, that's the problem. For me they have been green at one time, and I also had other colors. No need to rush this, but we may look into that later. I don't think that's taken care of, though, at least not via the stub.ld, cause you hacen't changed anything in that compared to Archshifts build.

 

[Shadowtrance]

Well at one point they WERE green if i remember right but i changed it or maybe my tired brain isn't remembering right. I haven't noticed any issues though i don't think. You're free to do what you like though, i can't stop you haha it is open source afterall. Got no problem looking at changes or whatever.
Think i should go to sleep before i faceplant my keyboard...

 

[Melon__Bread]

Okay, that does in fact sound tedious. But, you know, if you let the 3DS do the decryption (if it has to be done all-at-once), it will take a lot longer than on PC.

Call me silly, but how would I do that on my N3DS?

 

[d0k3]

Call me silly, but how would I do that on my N3DS?

You'd do that on N3DS if there was a way to successfully port rxTools functionality .

Well at one point they WERE green if i remember right but i changed it or maybe my tired brain isn't remembering right. I haven't noticed any issues though i don't think. You're free to do what you like though, i can't stop you haha it is open source afterall. Got no problem looking at changes or whatever.
Think i should go to sleep before i faceplant my keyboard...

Alright, I guess you really need some sleep . Anyways, I don't think there's an issue with the offset mentioned on patois' Github. You're using the exact same stub.ld and stub.specs patois provides in his examples himself.

 

[d0k3]

On the matter of porting rxTools functionality into this. I tried compiling rxTool with the brahma loader, just replacing some relevant files and crossing fingers. It could have worked, as rxTools shares a lot of code with Decrypt9, but of course it crashed into oblivion . Now, rxTools can obviously not be simply compiled for Ninjhax, but our version of Decrypt9 can. So, what I'm going to do now is trying to port rxTools functionality, piece by piece, into the Decrypt9 source code. it might work and it might not, but there is a certain chance of success.

@Shadowtrance:
The question is, how to continue with the Decrypt9 project. If I manage to port a lot (all?) of rxTools functionality, being a fork of some other project (which Shadowtrances Decrypt9 is) wouldn't do it justice anymore, and it should also have a different name then. I can think of two ways to go about that:

1. Use the Decrypt9 source code in the state it is now, but start a new project right away.
2. Start by improving / adapting the Decrypt9 source code and send pull requests. I'd start by getting rid of all the compiler warnings, then see how roxas75' utility functions (for drawing, file system access, etc...) are different (=provide more functionality) and port that over (but only if it can't break anything and if it is in fact better). Then, once I start actually adding more functionality, I'd start a new project.
3. ???

I'd prefer option 2, but that means you may get a lot of pull requests in the next days / weeks. Also, you'd need to fix up / test your new design. I like it, but there may be some problems. It could be only me, but I could swear the colors have changed several times with my various compiles (without me actually changing anything for that). An elaborate guess would be that you somewhere write into an area you shouldn't have written to (ie. wrote beyond the end of an array, to NULL, ....). Also, console output doesn't look good right now.

 

[Shadowtrance]

The question is, how to continue with the Decrypt9 project. If I manage to port a lot (all?) of rxTools functionality, being a fork of some other project (which Shadowtrances Decrypt9 is) wouldn't do it justice anymore, and it should also have a different name then. I can think of two ways to go about that:

1. Use the Decrypt9 source code in the state it is now, but start a new project right away.
2. Start by improving / adapting the Decrypt9 source code and send pull requests. I'd start by getting rid of all the compiler warnings, then see how roxas75' utility functions (for drawing, file system access, etc...) are different (=provide more functionality) and port that over (but only if it can't break anything and if it is in fact better). Then, once I start actually adding more functionality, I'd start a new project.
3. ???

I'd prefer option 2, but that means you may get a lot of pull requests in the next days / weeks. Also, you'd need to fix up / test your new design. I like it, but there may be some problems. It could be only me, but I could swear the colors have changed several times with my various compiles (without me actually changing anything for that). An elaborate guess would be that you somewhere write into an area you shouldn't have written to (ie. wrote beyond the end of an array, to NULL, ....). Also, console output doesn't look good right now.

Option 2 works i guess. I made a new branch (rxD9) for that so as to leave others (master, bootstrap-MOD) intact as they are.

 

[d0k3]

Option 2 works i guess. I made a new branch (rxD9) for that so as to leave others (master, bootstrap-MOD) intact as they are.

I just sent you a new pull request (for the bootstrap-mod branch, as all changes are relevant for that). Not as big as the last one, but there is some stuff for you to revise. I should have fixed some problems with the new UI, however the problem that I spoke of persists. To show you what I mean, I made a "screenshot":

That's compiled from my most recent code, and it was the same with your most recent state. Some offset is obviously wrong. I understand it looks differently for you, though. So, are you perhaps a O3DS user? Any other reason you could think of?

Anyways, as for rxD9, I'm still a bit unsure on how to proceed. Maybe I'll make a completely new menu / console system for that. I like the name, though!

 

[Shadowtrance]

Wow that's strange indeed. Doesn't look like that on my screens.
I have both a new3ds (small one) and old3ds xl and it doesn't do that on either.

 

[d0k3]

Wow that's strange indeed. Doesn't look like that on my screens.
I have both a new3ds (small one) and old3ds xl and it doesn't do that on either.

It may be due to me using a newer version of ctrulib (in fact, the newest one). Don't know yet. Which one are you using?

 

[Shadowtrance]

I'm using a reasonably recent ctrulib so i don't think that's it. Plus the D9 bin doesn't use ctrulib, only the brahma loader does.

 

[d0k3]

I'm using a reasonably recent ctrulib so i don't think that's it. Plus the D9 bin doesn't use ctrulib, only the brahma loader does.

Anyways, could you perhaps compile & release a new one once your through with most recent pull request (there is some output stuff fixed, so it is justified I guess)?

BTW, are you online all the time?

 

[Shadowtrance]

Anyways, could you perhaps compile & release a new one once your through with most recent pull request (there is some output stuff fixed, so it is justified I guess)?

BTW, are you online all the time?

Yeah will do in a while, once i get something to eat and relax for a bit.
And yeah I'm online a fair bit, well pretty much all the time I'm awake I'm at the computer.