Hacking Official Corbenik - Another CFW for advanced users (with bytecode patches!)

[Wolfvak]

I'm just saying it's not at the point where I feel it's worth replacing Luma on my setup.

Damn, people not reading the README/OP/thread posts make me so happy :^)

The README says 'I can't tell you where to get this' because it's Nintendo's intellectual property and not mine to distribute. Even giving links to the firmware files is pushing it. I'd like to keep this project as squeaky clean legally as possible so I can keep developing it, thank you very much.

Although this is true, it still falls under the DMCA exception as part of "security research" ( ͡° ͜ʖ ͡°).

I think than even distributing completely decrypted firmware files is a grey area (and not completely illegal) - one could argue that given a Nintendo 3DS system, one could obtain the decrypted firmware with ease (literally all systems are capable of running D9, given enough resources like hardmod if 11.0)

This is not to say pirated CIAs are OK, since those require a titlekey to be decrypted, and this is obtained illegally. On the other hand, native system titles (like *_FIRM) use the cetk which can be legally obtained from the CDN, as well as the firmware itself, with the only thing between an encrypted and a decrypted firmware is the AES engine and the various undumped keyslots.

 

[chaoskagami]

Damn, people not reading the README/OP/thread posts make me so happy :^)

Really? It's giving me a headache. *Pops Advil*

Although this is true, it still falls under the DMCA exception as part of "security research" ( ͡° ͜ʖ ͡°).

I think than even distributing completely decrypted firmware files is a grey area (and not completely illegal) - one could argue that given a Nintendo 3DS system, one could obtain the decrypted firmware with ease (literally all systems are capable of running D9, given enough resources like hardmod if 11.0)

This is not to say pirated CIAs are OK, since those require a titlekey to be decrypted, and this is obtained illegally. On the other hand, native system titles (like *_FIRM) use the cetk which can be legally obtained from the CDN, as well as the firmware itself, with the only thing between an encrypted and a decrypted firmware is the AES engine and the various undumped keyslots.

Which is exactly why I can't distribute the firmkey. CETK and encrypted firmware are okay, but I'm trying to stay as far from black as possible.

Also, this (https://github.com/chaoskagami/corbenik/issues/9) is a WONDERFULLY helpful bug report. Telling me 'Needs Complete Overhaul' is a great way to start it off - 'Let's be an entitled ass and piss off the dev!' /s

 

[BrokenToasterOven]

Reading it won't fix 'FAILED TO LOAD NATIVE_FIRM' lmao

 

[chaoskagami]

Except that I followed every single thing in it, asked two other security researchers to check I'm not crazy, they followed it, and I asked other's I known who've tried it, and it's still failing.

I think at this point it's more than just the usual 'git gud' tripe, and more along the lines of 'The readme isn't fucking helping anyone'

The 3DS scene has too many rude people, and too much half-assed/dangerous software for me, I think. The guides all contradict each other, people are too scared to share numbers with each other, and half the time the software either bricks your console, doesn't work at all, or has been taken offline, and now we're at the point where everyone's gotta have their own personal CFW, regardless of it works or not.

After 8 different firmware keys, several of my own decrypted, rearranging the files in every possible configuration, and enlisting 2 other people to follow the exact same process, I can say that we're all thoroughly convinced this is vaporware. Nothing, I mean NOTHING fixes the 'FAILED TO LOAD NATIVE_FIRM' shit. I've had enough of the in-joke, or April-Fools that people are playing here, pretending this works, I'm done. Even Luma isn't safe from it. Crippling the ability to play GBA or VC games, crashing the console every time, like, it's just not worth this.

I'd say 'see you later', but I think I'm done here. If you see the n3DS and Freakyforms on eBay in the next 30 mins, that's mine.

If you would tell me what is so wrong with the README instead of insulting the documentation, code, me, and all the other wonderful devs responsible for other CFW like Luma, perhaps I would be able to improve it. You've resorted to name calling and childish "This is fake" behavior.

You've done nothing but complain about how it doesn't work. You've uploaded no logs - the option is there, and I have asked. You offer no actual way for me to debug what is going wrong, whether it is my error or yours. You've insulted me and other devs, and opened pointless issues on my github with no actual debugging information for me to help you with.

It isn't an april fool's joke, nor an in-joke. If you would take a look through the source, you would see it does what it says on the tin can.

Either way, help me help you or go elsewhere. I have no more patience for this, and I WILL report the next inflammatory post.

 

[Selver]

(Total SD Sectors - 1) - NAND size = (62333952 - 1) - 3866624 = 62333951 - 3866624 = 48467327
... The actual correct position is (62333952 - 1) - 4194305.

chaoskagami,

Below, please see both a recommendation for your reverseNAND solution, and a description of why it provides value.

Recommendation:

• Blob := 2**X (with X >= 20, I recommend 24 or more, or 16MiB)
• Round NAND byte size up to Blob multiples
• Ensure partition starts on Blob boundary
• Avoid emuNAND formats with first sector at end of the image...

Why:
Flash media (SD is NAND) has an erase size and preferred write size each multiples of the 512 byte sector size. By aligning reads and writes to the SD media's preferred boundaries, performance can be improved for both READ and WRITE operations.

Thus, if a NAND image is a simple dump from sector 0 .. N, and the SD card uses 4MiB internally as the preferred sizes, it just makes sense to store the first sector at a multiple of 4MiB.

That format that puts the first sector at the end? It only did that to make room for the MBR. Auto-convert those images for your reverseNAND solution, and just align things properly from the start.

The choice of size for Blob is debatable, but 16MiB is not unreasonablem, given today's media erase group sizes.

 

[chaoskagami]

chaoskagami,

Below, please see both a recommendation for your reverseNAND solution, and a description of why it provides value.

Recommendation:

• Blob := 2**X (with X >= 20, I recommend 24 or more, or 16MiB)
• Round NAND byte size up to Blob multiples
• Ensure partition starts on Blob boundary
• Avoid emuNAND formats with first sector at end of the image...

Why:
Flash media (SD is NAND) has an erase size and preferred write size each multiples of the 512 byte sector size. By aligning reads and writes to the SD media's preferred boundaries, performance can be improved for both READ and WRITE operations.

Thus, if a NAND image is a simple dump from sector 0 .. N, and the SD card uses 4MiB internally as the preferred sizes, it just makes sense to store the first sector at a multiple of 4MiB.

That format that puts the first sector at the end? It only did that to make room for the MBR. Auto-convert those images for your reverseNAND solution, and just align things properly from the start.

The choice of size for Blob is debatable, but 16MiB is not unreasonablem, given today's media erase group sizes.

This makes sense in some ways, but the issue is that write boundaries differ from card to card, and the NAND will always be read in 512-byte sectors whether on the SD or actual NAND. This would also differ on every SD, and would be even more complicated to keep track of for people wanting to set it up (with no available userland tools available yet.)

I agree that Gateway/First sector at back is outmoded and should probably be disabled entirely in reverse mode (misdetection being one reason.)

 

[Wolfvak]

Except that I followed every single thing in it, asked two other security researchers to check I'm not crazy, they followed it, and I asked other's I known who've tried it, and it's still failing.

I think at this point it's more than just the usual 'git gud' tripe, and more along the lines of 'The readme isn't fucking helping anyone'

The 3DS scene has too many rude people, and too much half-assed/dangerous software for me, I think. The guides all contradict each other, people are too scared to share numbers with each other, and half the time the software either bricks your console, doesn't work at all, or has been taken offline, and now we're at the point where everyone's gotta have their own personal CFW, regardless of it works or not.

After 8 different firmware keys, several of my own decrypted, rearranging the files in every possible configuration, and enlisting 2 other people to follow the exact same process, I can say that we're all thoroughly convinced this is vaporware. Nothing, I mean NOTHING fixes the 'FAILED TO LOAD NATIVE_FIRM' shit. I've had enough of the in-joke, or April-Fools that people are playing here, pretending this works, I'm done. Even Luma isn't safe from it. Crippling the ability to play GBA or VC games, crashing the console every time, like, it's just not worth this.


I'd say 'see you later', but I think I'm done here. If you see the n3DS and Freakyforms on eBay in the next 30 mins, that's mine.

Huh. The instructions are dead simple: get 3 firmware files, 3 cetk files and 3 firmkeys (if you want support for everything, if you only want NFIRM you need 1 for each). Seeing that you have a N3DS you also need the slot0x11key96.bin file.

Wow, I just resumed the important part of the installation section in the README in two lines.

At this point I'm just gonna assume you're a troll.
Especially after reading "8 different firmware keys, several of my own decrypted" <- firmkeys are unique for each console and firm type. So it's literally impossible for you to obtain 2 different firmkeys for one type of FIRM/console (I'm gonna assume NATIVE_FIRM/N3DS combo), let alone 8 of them.

Also @chaoskagami you're far more experienced in this but my suggestion is to add something like

"If you don't provide logs/detailed info then I won't even reply to you, and if you keep insisting I'll report/block you"

I've had enough of people shitting over software just because they can't follow simple instructions (BA9 is a prime example of this).

EDIT: Also, the "half-assed software" part is an insult to the whole dev scene and you have no solid grounds on such claim - if you want to qoute the exact part where it's "half-assed", please, be my guest.
Until then, fuck off.

 

[chaoskagami]

Huh. The instructions are dead simple: get 3 firmware files, 3 cetk files and 3 firmkeys (if you want support for everything, if you only want NFIRM you need 1 for each). Seeing that you have a N3DS you also need the slot0x11key96.bin file.

Wow, I just resumed the important part of the installation section in the README in two lines.

Exactly my point. I have no clue what's so hard to follow in it.

At this point I'm just gonna assume you're a troll.
Especially after reading "8 different firmware keys, several of my own decrypted" <- firmkeys are unique for each console and firm type. So it's literally impossible for you to obtain 2 different firmkeys for one type of FIRM/console (I'm gonna assume NATIVE_FIRM/N3DS combo), let alone 8 of them.

The only way this could possibly happen is if he's trying to boot an old and unsupported NFIRM from 2.1 or something, where it decrypts it and basically would panic (and no shit that wouldn't work, because nothing supports that either)

I don't buy that he's a software engineer either. He would have looked through the code before calling it vapourware.

Also @chaoskagami you're far more experienced in this but my suggestion is to add something like .
I've had enough of people shitting over software just because they can follow simple instructions (BA9 is a prime example of this).

I feel you. It's already in the FAQ. I'm beginning to think I need to move it to the top in big bold letters. Ugh. I think I underestimated people.

 

[Joel16]

Haha, why do I feel like there are too many kids on this forum though?
And yeah I couldn't agree more with @Wolfvak 's suggestion. You should consider putting this up in the main post chaoskagami senpai.
"Logs or it didn't happen."

Edit:
Oh and in bold or something too.

 

[chaoskagami]

Haha, why do I feel like there are too many kids on this forum though?
And yeah I couldn't agree more with @Wolfvak 's suggestion. You should consider putting this up in the main post chaoskagami senpai.
"Logs or it didn't happen."

Edit:
Oh and in bold or something too.

I'm going to continue a 'Be nice' policy until (and if) this happens again. I did update with some bold stuff near the actual github links, so it's hopefully noticeable. I'll probably regret this, but eh.

 

[The Catboy]

I've been quiet for the past few days. Why? Because I haven't broken anything!
Of course, I was going to test the FIRM0/1 protection, but got busy and didn't! So since I had to stay home sick, I felt like today would be the best day to test it, since I wasn't going to to do anything for several hours.
So I actually tested it on my 2DS, which took several hours of actual testing. But working along side chaoskagami, we were able to do set up and do several tests that were able to confirm that the FIRM0/1 protection do indeed work! Which means, it should always be safe to update your OFW, if a new one is released!

 

[chaoskagami]

I've been quiet for the past few days. Why? Because I haven't broken anything!
Of course, I was going to test the FIRM0/1 protection, but got busy and didn't! So since I had to stay home sick, I felt like today would be the best day to test it, since I wasn't going to to do anything for several hours.
So I actually tested it on my 2DS, which took several hours of actual testing. But working along side chaoskagami, we were able to do set up and do several tests that were able to confirm that the FIRM0/1 protection do indeed work! Which means, it should always be safe to update your OFW, if a new one is released!

This was a very very very important thing to test, and it's difficult to test under normal conditions. But anyways, yes, come next update it should be safe to update normally like every other CFW with FIRM Protection on. I didn't see any reason why it wouldn't work, but better paranoid than bricked. Thanks again.

 

[Februarysn0w]

compiled corbenic custom firmware successfully at windows 10. my computer has installed devkitpro and mingw-w64. so make sure you have installed those SDK.

simple script for compilation.

@echo off
title Sample Script For Corbenik Custom Firmware
echo ************Menu************
echo [0] : Build corbenik cfw
echo [1] : Clean build
echo [2] : exit
set /p NUM="inout number>"
if "%NUM%"=="1" goto 1
if "%NUM%"=="2" goto 2

:0
mingw32-make

:1
mingw32-make clean

:2
exit

 

[Selver]

... the issue is that write boundaries differ from card to card, and the NAND will always be read in 512-byte sectors whether on the SD or actual NAND.
... I agree that Gateway/First sector at back is outmoded and should probably be disabled entirely in reverse mode (misdetection being one reason.)

Hi Chaoskagami,

You are right, the boundaries will differ from card to card. However, they will almost always be in powers of 2. Thus, one SD card may have an erase size of 64KiB, while another would have an erase size of 4MiB, and another would have a 16MiB.

I was clearly tired... the only thing I should have recommended was to start all reverseNAND partitions on a 16MiB boundary.

We agree that all reads will be on 512-byte sector boundaries. What's problematic is writes that could have been on a single erase block, but spanned erase blocks due. I would be surprised if any reasonable FAT FS implementation did not tweak allocation to minimize this (see write amplification, which is related). If you can accept this presumption also, then most writes on the NAND would end up aligned.

One reason GW may have chosen for their "first sector last" trick was to get exactly this benefit. I know folks bash GW, but even a stopped clock is right twice a day.

In the end, I won't push hard for this... reverseNAND is your baby. Just offering some thoughts.

EDIT
In other thoughts, perhaps you should specify a signature at the end of the media... or even a reverse-partition-table at the end of the media... for your reverseNAND designs. Avoids the whole detection problem altogether, and it's simple.


Oh, and well done on this CFW's architecture. the very concept of having a VM for patches... Brilliantly executed. You don't get enough support (regardless of how much you get). Truly, you've done an amazing thing. Well done.

 

[chaoskagami]

EDIT
In other thoughts, perhaps you should specify a signature at the end of the media... or even a reverse-partition-table at the end of the media... for your reverseNAND designs. Avoids the whole detection problem altogether, and it's simple.

That would be a valid solution, but partition tables at the end have never been supported by any OS.

I have an even better idea. Why not just have a specialized container filesystem that is guaranteed contiguous allocation and has large fixed-size files? I could even implement it in a library.

Oh, and well done on this CFW's architecture. the very concept of having a VM for patches... Brilliantly executed. You don't get enough support (regardless of how much you get). Truly, you've done an amazing thing. Well done.

Thanks. I'm more an actual programmer than a hacker, and spent a good deal of time on careful design. Nice to see it's paying off.

 

[Selver]

... partition tables at the end have never been supported by any OS.
... a specialized container filesystem that is guaranteed contiguous allocation and has large fixed-size files? I could even implement it in a library.
... I'm more an actual programmer than a hacker, and spent a good deal of time on careful design. Nice to see it's paying off.

It's because they're not supported at the end that you could put them there. And really, I just used "partition table" as a metaphor. Our ideas (partition table, specialized container FS) are in essence the same, namely:
* Global common starting point to discover other information (last sector)
* That sector lists useful information about finding the other information of value, in this case reverse emuNAND start & length
* Custom solution is better than re-use of partition tables, because you won't be limited to 4 entries for the media...

Oh, and when you mentioned you parse the codes with a proper AST & tokenizer, I got the feeling you had some experience. The code is well structured, variables names makes sense, ... hmmm ... must find something to complain about ... AHA! You fail to use const. Yeah, that's it. Must mean it's vaporware. ;-)

 

[chaoskagami]

It's because they're not supported at the end that you could put them there. And really, I just used "partition table" as a metaphor. Our ideas (partition table, specialized container FS) are in essence the same, namely:
* Global common starting point to discover other information (last sector)
* That sector lists useful information about finding the other information of value, in this case reverse emuNAND start & length
* Custom solution is better than re-use of partition tables, because you won't be limited to 4 entries for the media...

Oh, and when you mentioned you parse the codes with a proper AST & tokenizer, I got the feeling you had some experience. The code is well structured, variables names makes sense, ... hmmm ... must find something to complain about ... AHA! You fail to use const. Yeah, that's it. Must mean it's vaporware. ;-)

I suppose there's really no difference between a DOS label and a four-file filesystem when it comes down to it. A hybrid GPT setup would make organization of multiemunand much simpler, too, and without an actual custom FS. I'll still implement a fs, though. Seems a good idea.

Well, the rewrite of the assembler isn't done yet, and that's going to take a while. The current assembler (bytecode_asm.py) is one gigantic hack that needs to go. Badly. The asm_rewrite branch is further along locally than on git.

But yeah, I do have some experience. Aside from the use of const, apparently (and it's kind of pointless here - being bare-metal and all. I mean, aside from -Werror.)

 

[Arcanuskun]

Tested deleting H&S app on my O3DSXL and went on an update. So far no problem on firm protect for me.

 

[astronautlevel]

Tested deleting H&S app on my O3DSXL and went on an update. So far no problem on firm protect for me.

That doesn't upgrade FIRM anyway iirc. A better test would be to downgrade to an older version then upgrade again. Don't do this if you don't have a hard modded console obviously

 

[a9lh-1user]

I've been quiet for the past few days. Why? Because I haven't broken anything!
Of course, I was going to test the FIRM0/1 protection, but got busy and didn't! So since I had to stay home sick, I felt like today would be the best day to test it, since I wasn't going to to do anything for several hours.
So I actually tested it on my 2DS, which took several hours of actual testing. But working along side chaoskagami, we were able to do set up and do several tests that were able to confirm that the FIRM0/1 protection do indeed work! Which means, it should always be safe to update your OFW, if a new one is released!

Tested by Chaoskagami and Crystal The Glaceon ..... if i read it correctly