11.0 NATIVE_FIRM lacks most patches about cakesforeverywan HOT 27 CLOSED

This is the original open source CFW - back in June 2015, things were done differently. I don't know how Aurora got the idea to search for patterns, but it's relatively new (4 months old).

However, offsets relative to different addresses (relative to 0x00..., relative to beggining of firmware file, relative to beggining of section to patch, etc) would be kind of nice. Let's leave it to the next version, shall we :P ?

from cakesforeverywan.

Fixed in 68432b5

from cakesforeverywan.

Thanks for your contribution. Now I just need to verify o3ds offsets.

from cakesforeverywan.

@chaoskagami that's quite odd - apparently the ARM9 section was changed in the latest FIRM, so It's quite odd that old offsets still work fine. Not complaining, but it's strange

http://3dbrew.org/wiki/11.0.0-33#NATIVE_FIRM

from cakesforeverywan.

P.S. We should have a patch that brings back svcBackdoor.

from cakesforeverywan.

I'm...honored by the commit access, but I also have no clue what to do with it. I guess I'll start by cherry-picking the various 11.0 fixes. I promise not to do anything insane.

@Wolfvak I thought it strange too. Trust me. I've double and triple checked. For whatever reason, all of the offsets are unchanged. on n3ds. I have no clue why. I can only assume everything was shuffled around in a way that kept the offsets identical.

I have no clue how to go about bringing back svcBackdoor at the moment. That's probably going to involve a disassembly of the newer arm11 kernel and the old arm11 kernel.

from cakesforeverywan.

I guess the original issue was fixed, now onto patches...

from cakesforeverywan.

I cherry-picked the fixes to master. Nightly cakes is now mostly functional again for n3ds users, but there's quite a bit that needs to be done...ugh. Yep, onto patches...

I'm updating the first post with a checklist.

Also, I'll be unable to do much today - I'm going to visit my grandmother.

from cakesforeverywan.

@chaoskagami:

but I also have no clue what to do with it

You don't have to do anything with it. I don't expect anything. It's just to make it easier for you to contribute, if you feel like it (if anything goes wrong, rewriting history with git is easy anyway).
I'll fix o3ds soon™, if nobody else beats me to it.

from cakesforeverywan.

I'm glad to help when I can. I'll only use it when needed - like with this debacle - cakes is your project, not mine. :)

You'll probably beat me at least to fixing o3ds. I may be caught up for a few days or so, and I don't have an o3ds to test it.

Do you think we need another stable release once all the patches are fixed as well as svcbackdoor? Not every issue is tackled yet, but the new firm put a bit of a wrench in usage, since it now requires a firmware hunt.

We may also want to get 3ds_injector in somehow just to kill the ASLR and anti-oothax/anti-ninjhax, since it's proving problematic.

On May 10, 2016 5:00:06 PM EDT, mid-kid [email protected] wrote:

@chaoskagami:

but I also have no clue what to do with it

You don't have to do anything with it. I don't expect anything. It's
just to make it easier for you to contribute, if you feel like it.
I'll fix o3ds soon™, if nobody else beats me to it.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#53 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

from cakesforeverywan.

Alright, I got something working by analyzing TuxSH's code and comparing old FIRMs with this one.
svcBackdoor works (doesn't crash RetroArch on boot now) but it's severely untested and o3DS only.
I only tested it with a prepatched FIRM, since I can't sifnature patches to work properly for some reason.

The patch is currently in my icing repo https://github.com/Wolfvak/icing/commit/789c107a63996f54fdd493169ad56bf284f40d31 but I'll bring it here once it's 'Stable Enough(tm)' and has n3DS support.

For now, I'll check it off the list in the first message.

from cakesforeverywan.

@chaoskagami:

but the new firm put a bit of a wrench in usage, since it now requires a firmware hunt.

Really? Firmware 11.0 works fine for me with a 9.6 NATIVE_FIRM. Is it different on n3ds?

from cakesforeverywan.

Oh no, 11.0 is fine with a 10.4 native. I meant the 11.0 firmware.bin, not 11.0 firmware as a whole, sorry.

from cakesforeverywan.

Oh, okay. In any case, I've removed a lot of issues from the next release goal, as it'll take ages for a new stable if all that has to be done. The only issues which have a release goal right now are the most pressing issues before I can declare it stable enough for regular use.

from cakesforeverywan.

My god. I'm a stupid retard. I actually generated all the n3ds patches against the 10.4 firmware yesterday. It was strange, alright. Excuse me while I untick the checkboxes, reset those commits out of the repo and fix my idiocy.

Also, unless I'm really dumb (maybe), the sha256 of decrypted 1F has changed.

from cakesforeverywan.

I think I should probably exit from here, since I'm apparently dumb enough that I made that mistake. God, I'm mad at myself right now.

from cakesforeverywan.

Don't worry - I've been there as well :P

I won't be able to work for a couple of days on this, sorry.

from cakesforeverywan.

On that topic, I'm going to PR a change to icing. I rewrote the patch as assembly. Will you be able to test that?

from cakesforeverywan.

In about 8 hours

from cakesforeverywan.

S' fine. I'm going to be busy all day, so whatever. The actual output shouldn't change in the slightest. Should be just a bit more readable now. :P

BTW, any reason you're doing unaligned and not writing the 0xFF compared to TuxSH's code?

from cakesforeverywan.

I don't know much about Cakes's patching system, but since nothing broke in Luma3DS, you should be able to run the patch code "manually" (i.e. with a hex editor) and find the offsets this way.

from cakesforeverywan.

Hmm... that could be a better solution. Let Luma run over a 11.0 FIRM, dump the patched section 0 and compare it to a vanilla one... thanks @TuxSH!
Originally I did it manually, and both offsets were obtained by comparing 10.4 to 11.0 section 0's svcTable

I've had trouble trying to dump sections previously, so I must've dismissed it before even having the idea...

from cakesforeverywan.

You can use standalone_patcher to test patches as well, so you don't need to necessarily be on a 3DS to compare for correctness.

You know, out of curiousity @mid-kid - is there any specific reason offsets in patches are based on physical memory layout versus relative to the firmware? Relative offsets would be much easier to work with.

from cakesforeverywan.

@chaoskagami:
Originally, due to linking the code at a specific position. I just kept it like that afterwards. Tbh, I quite like it this way. You're supposed to load the firm partitions at the correct address in IDA anyway.

from cakesforeverywan.

Except IDA costs a lot of money, and I'm not a pirate, so I'm using radare2/objdump for this stuff.

Anyways, I understand the reasoning behind it. It's just slightly inconvenient.

I may implement a flag in patissier to convert relative offsets.

from cakesforeverywan.

@chaoskagami:
I applaud you for using radare, seriously, it's cool. I just haven't taken the time to learn to use it properly yet. I do know, however, that it's got a plugin that can read the FIRM partitions properly. It should be able to handle displaying the physical address (except for the process9 physical address. It could be extended to do so, however).

from cakesforeverywan.

Didn't know there was a plugin for that. Neat. Probably need to recompile it, I'm about two plus months behind on commits, because it's not something I use very often.

Yeah, radare is definitely cool. A lot of people aren't even aware it exists, which is sad.

from cakesforeverywan.