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

  • Thread starter Thread starter chaoskagami
  • Start date Start date
  • Views Views 287,450
  • Replies Replies 2,153
  • Likes Likes 60
Nope, because I can extract a specific file from the ZIP or extract it all. I could split them myself when I upload it to the server, but I would rather not tamper with the files. When/If I implement the SHA512 checks, it would mean I'd have to recalculate them every time. Or use a server script to do so.

Sent from my Nokia 3310 using Tapatalk

Can you list the contents of the zip? If so, you could extract the folders one by one and exclude /corbenik/locale. Otherwise, I'm going to have to say LPP+ is broken and doesn't even wrap zlib correctly, never mind the 302 incapability.
 
Can you list the contents of the zip? If so, you could extract the folders one by one and exclude /corbenik/locale. Otherwise, I'm going to have to say LPP+ is broken and doesn't even wrap zlib correctly, never mind the 302 incapability.
Afaik, the only zip functions are extractZip and extractFromZip.

Sent from my Nokia 3310 using Tapatalk
 
Afaik, the only zip functions are extractZip and extractFromZip.

Ugh. This may be an unpopular decision - but LPP+ is utterly broken if those are the only two functions it has.

I won't and can't make any further effort to cater to broken software.

Sorry. :unsure:
 
  • Like
Reactions: Joel16
Ugh. This may be an unpopular decision - but LPP+ is utterly broken if those are the only two functions it has.

I won't and can't make any further effort to cater to broken software.

Sorry. :unsure:
Oh well. Should I split the files myself? I'd rather not tamper with them, but it would improve the update time significantly.

Sent from my Nokia 3310 using Tapatalk
 
Oh well. Should I split the files myself? I'd rather not tamper with them, but it would improve the update time significantly.

Sent from my Nokia 3310 using Tapatalk

I'd rather you not for the sake of my sanity.

The reason the sha512sums are done is to ensure the zips are as intended on the github releases. I'll have to start GPG signing zip files at this rate. :/
 
I'd rather you not for the sake of my sanity.

The reason the sha512sums are done is to ensure the zips are as intended on the github releases. I'll have to start GPG signing zip files at this rate. :/
They wouldn't be on GitHub though x.x
:confused:

I'd upload the split versions to the server.

I'd rather keep them in their original state though. Oh well, I suppose time isn't an issue when updating Corbenik. For me, at least.

Gn8

Sent from my Nokia 3310 using Tapatalk
 
They wouldn't be on GitHub though x.x
:confused:

I'd upload the split versions to the server.

I'd rather keep them in their original state though. Oh well, I suppose time isn't an issue when updating Corbenik. For me, at least.

Gn8

Right, but someone could fetch the zip off your server and check it against the sha512 from github, and they should be identical. It's to prevent the contents of the zip from changing (which would break the signature.) The idea is to prevent in-the-middle tampering.

Night, sleep well. :P
 
Right, but someone could fetch the zip off your server and check it against the sha512 from github, and they should be identical. It's to prevent the contents of the zip from changing (which would break the signature.) The idea is to prevent in-the-middle tampering.

Night, sleep well. :P
That is true. Welp. Guess there is no helping it, I'll use the official file.

Sent from my Nokia 3310 using Tapatalk
 
Some of the events work though. I never used the original Mystery Machine so Idk if it is a Corbenik problem.
Original mystery machine gives you always Bulbasaur if you enter a wrong code and yes it also happens to give him out over the internet
So i don't think it's a corbenik issue
 
Is just me or builds I do from git are ~600KiB big? I just did a git pull and updating submodules because of the latest commit, then built it. When I checked later, the arm9loaderhax.bin and corbenik.bin were ~600KiB big in contrast to my last build (3635db4) before (was about 105KiB.) I have no idea what could have caused it or why. Glancing the last 4 commits give me nothing that could be the cause, then again my C is so bad that I probably missed something.
 
Is just me or builds I do from git are ~600KiB big? I just did a git pull and updating submodules because of the latest commit, then built it. When I checked later, the arm9loaderhax.bin and corbenik.bin were ~600KiB big in contrast to my last build (3635db4) before (was about 105KiB.) I have no idea what could have caused it or why. Glancing the last 4 commits give me nothing that could be the cause, then again my C is so bad that I probably missed something.
My programming is really rusty but isn't this part in source/std/draw.c
uint8_t top_bg[TOP_SIZE];
uint8_t bottom_bg[BOTTOM_SIZE];
statically allocating screen size buffers? That would explain it.
 
Last edited by Kirtai,
/home/mario/3ds/corbenik/external/loader/source/loader.c:129:5: error: unknown type name 'CodeSetInfo'
CodeSetInfo codesetinfo;

Would anyone know why?
I think this is due to using an out of date ctrulib.

When I hit that error I moved my old ctrulib out of the way, build and installed the latest from https://github.com/smealum/ctrulib and it worked fine.
 
I think this is due to using an out of date ctrulib.

When I hit that error I moved my old ctrulib out of the way, build and installed the latest from https://github.com/smealum/ctrulib and it worked fine.
yep, I updated ctrulib, but hadn't tried compiling this ever since, and I updated ctrulib so I could compile another app. Oh well, it works now. :D
 
My programming is really rusty but isn't this part in source/std/draw.c

statically allocating screen size buffers? That would explain it.

Yeah, that's why. One of the things I have to do is switch over to using FCRAM for that stuff. All the static allocations are making the bss section unreasonably large.

To be precise, my arm9loaderhax.bin output is 631906 bytes.

EDIT: Git is now 109554 bytes after moving the buffers to FCRAM.
 
Last edited by chaoskagami,
  • Like
Reactions: gnmmarechal
Wouldn't expect any. Not much has changed.
plz don't be scared

332961530eae48f9b23bae4d99a5f60f.png


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

plz don't be scared

332961530eae48f9b23bae4d99a5f60f.png
fak, I repeated part of the sentence. need to fix that
 
  • Like
Reactions: The Catboy

Site & Scene News

Popular threads in this forum