If you could figure this out, you would be my hero.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
I use 3DSFAT16tool.py to decryptWait, 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.
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.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)
https://github.com/patois/Brahma said: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.
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.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 .
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.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.
Call me silly, but how would I do that on my N3DS?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.
You'd do that on N3DS if there was a way to successfully port rxTools functionality .Call me silly, but how would I do that on my N3DS?
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.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...
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.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:
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.
- Use the Decrypt9 source code in the state it is now, but start a new project right away.
- 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.
- ???
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":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.
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?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.
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)?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.
Yeah will do in a while, once i get something to eat and relax for a bit.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?