Homebrew TWLbf - a tool to brute force DSi Console ID or EMMC CID

[nocash123]

Cool, very nice idea to brute both CID and Console ID. I had believed that it wouldn't be possible to brute one of them without knowing the other one.

EDIT: I should note, this is substantially slower.

Uh, what is slower than what?

apparently you have to set both an encryption *and* decryption key??

Theoretically one could generate both keys at once - the problem might be that most EBC hardware/software libraries don't have separate memory slots for storing both keys.

But, do you really need both encrypt and decrypt? As far as I know, the first 32 bytes of the decrypted eMMC image should be all zeroes, and the encrypted image contains encrypted(IV) and encrypted(IV+1), XORed by the those zeroes.
So I think you could simply ECB decrypt the first 32 bytes, and then check if the first 16 bytes (plus 1) are same as the next 16 bytes. So, you'd only need the decrypt key, but not the encrypt key.

 

[dark_samus3]

Also, to add to the list, just got a 08a22 on a U region cyan DSi

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

Uh, what is slower than what?


Theoretically one could generate both keys at once - the problem might be that most EBC hardware/software libraries don't have separate memory slots for storing both keys.

But, do you really need both encrypt and decrypt? As far as I know, the first 32 bytes of the decrypted eMMC image should be all zeroes, and the encrypted image contains encrypted(IV) and encrypted(IV+1), XORed by the those zeroes.
So I think you could simply ECB decrypt the first 32 bytes, and then check if the first 16 bytes (plus 1) are same as the next 16 bytes. So, you'd only need the decrypt key, but not the encrypt key.

you only get the hash back, so you can't just compare against emmc cid structure, unfortunately. And, if you already know one thing (CID or Console ID) this is much slower.

EDIT: and, yes, that is indeed the problem here, if you set both the encryption and decryption keys, the one that gets set last is the one that ends up as the key for the next operation. I found that out the hard way, haha

EDIT2: also, there is a method to just do two decryptions (decrypt both blocks and compare the results) but they both seem to take the exact same amount of time, even with the key setting

 

[nocash123]

also, there is a method to just do two decryptions (decrypt both blocks and compare the results) but they both seem to take the exact same amount of time, even with the key setting

Yes, that's what I meant. But yeah, compared to the other operations, generating-the-encrypt-key doesn't seem to take too much time, and omitting that step will probably improve the overall speed by a few percents only. Still, it should be at least slightly faster.

if you already know one thing (CID or Console ID) this is much slower.

Ah, okay, now I know what is slower than what...

But I think your idea (using ECB-decrypt) could make the CID-searching code even faster:
JimmyZ's brute loop is currently doing one SHA1 operation, and one AES-CTR-encrypt operation per loop cycle, isn't it?
Actually, that's how I would have implemented it myself, too.
But instead, one could do one AES-ECB-Decrypt operation at program start (using the known Console ID as key), and then, the brute loop would only need SHA1 operations, without any AES stuff in the loop.

---

Btw. and another thing: The barcodes (on the bottom of the console) might be also useful. The problem is that it's unknown if or how they relate to CID or ConsoleID. To solve that, it would be very helpful to find two consoles with similar barcodes. For example, if somebody bought two DSi's on the same day as gifts for the children: check if they do both have similar barcode digits, please!
Then one could check if those consoles are also having similar internal ID's; and which barcode digits affect which ID bits.

 

[dark_samus3]

Yes, that's what I meant. But yeah, compared to the other operations, generating-the-encrypt-key doesn't seem to take too much time, and omitting that step will probably improve the overall speed by a fer percents only. Still, it should be at least slightly faster.


Ah, okay, now I know what is slower than what...

But I think your idea (using ECB-decrypt) could make the CID-searching code even faster:
JimmyZ's brute loop is currently doing one SHA1 operation, and one AES-CTR-encrypt operation per loop cycle, isn't it?
Actually, that's how I would have implemented it myself, too.
But instead, one could do one AES-ECB-Decrypt operation at program start (using the known Console ID as key), and then, the brute loop would only need SHA1 operations, without any AES stuff in the loop.

---

Btw. and another thing: The barcodes (on the bottom of the console) might be also useful. The problem is that it's unknown if or how they relate to CID or ConsoleID. To solve that, it would be very helpful to find two consoles with similar barcodes. For example, if somebody bought two DSi's on the same day as gifts for the children: check if they do both have similar barcode digits, please!
Then one could check if those consoles are also having similar internal ID's; and which barcode digits affect which ID bits.

Yeah, I've implemented a little loop to bruteforce the sha1 hash of the CID, it's pretty fast, and requires no repeated AES operations

        for(u32 i = 0; i < 0xFFFFFFFFu; i++)
        {
            *(u32 *)(emmc_cid + 1) = i;
            if(!(i % 0x10000000))
                printf("%08x\n", i);
            sha1_16(tmp_sha1, emmc_cid);
            if(!memcmp_rev(emmc_sha1, tmp_sha1, 16))
            {
                printf("found cid: ");
                for(int k = 0; k < 16; k++)
                printf("%02x", emmc_cid[k]);
                printf("\n");
                return;
            }
        }

with memcmp_rev being a custom implemented memcmp that compares a normal order thing to a reverse order thing. That actually shaved off 4 seconds per 0x10000000 attempt. Though I suppose you could also just reverse the emmc_sha1 so it can be directly compared as well. (I guess that's the result of programming at 4 am haha) *shrug*

This implementation takes 33 seconds per 0x10000000 values compared on my machine (i7-4700HQ)

 

[JimmyZ]

I thought about that but EMMC CID brute forcing is of little use(If you can get the dump you can get the CID, if you can't get the dump you have nothing to start with) so I didn't bother, and SHA1 takes most of the time in my tests.

 

[nocash123]

eMMC Dump = Hardmod = 4-5 wires = 0.01 cents
Console ID Dump = Export DSi Browser to SD card = 0 cents
CID Dump = LinuxPC, Raspberry, or hackedBiggestLoserCart = couple of dollars

To me, CID dumping looks like the most difficult & expensive step; though that's depending on what hardware/software setup you have at home.
But well, if CID bruting isn't much faster via SHA1 versus SHA1+AES for then it won't matter too much (and I already got my CID anyways, but, back then, without bruting, I had to invest about $5 in hardware/postage).

 

[Oleboy555]

eMMC Dump = Hardmod = 4-5 wires = 0.01 cents
Console ID Dump = Export DSi Browser to SD card = 0 cents
CID Dump = LinuxPC, Raspberry, or hackedBiggestLoserCart = couple of dollars

To me, CID dumping looks like the most difficult & expensive step; though that's depending on what hardware/software setup you have at home.
But well, if CID bruting isn't much faster via SHA1 versus SHA1+AES for then it won't matter too much (and I already got my CID anyways, but, back then, without bruting, I had to invest about $5 in hardware/postage).

i'd say CID is pretty easy and a biggest loser cart costs practically nothing

 

[dark_samus3]

I thought about that but EMMC CID brute forcing is of little use(If you can get the dump you can get the CID, if you can't get the dump you have nothing to start with) so I didn't bother, and SHA1 takes most of the time in my tests.

Really, CID isn't needed, just the hash. Most tools just take in the CID to get the hash, but I modified twltool to just use a hash last night. It worked fine. Really, all that's needed to decrypt anymore is a ConsoleID, since you can just recover the hash by decrypting block 0, use that as the base CTR and go from there

 

[nocash123]

Really, CID isn't needed, just the hash. Most tools just take in the CID to get the hash, but I modified twltool to just use a hash last night. It worked fine. Really, all that's needed to decrypt anymore is a ConsoleID, since you can just recover the hash by decrypting block 0, use that as the base CTR and go from there

Good idea - that should work if you want to encrypt/decrypt eMMC on your own...
But it won't work in emulators, since the emulated software will need the CID to compute the sha1/hash on its own.

 

[dark_samus3]

Good idea - that should work if you want to encrypt/decrypt eMMC on your own...
But it won't work in emulators, since the emulated software will need the CID to compute the sha1/hash on its own.

Yeah, that's about the only thing I can think of that would need it anymore.

EDIT: Hrm, I had an idea, one could decrypt their NAND, then re-encrypt with a different CID, but the same ConsoleID, if they really wanted

 

[nocash123]

one could decrypt their NAND, then re-encrypt with a different CID, but the same ConsoleID, if they really wanted

Sure. And then re-decrypt and re-re-encrypt it with old CID before copying it back to the actual console. Having the real CID is making things a lot easier.
On the other hand, one could use the CID-less approach to install an exploit, and then use the exploit to get the CID directly from the console.

 

[JimmyZ]

I'll implement this, just not now, currently a bit busy with something else.

 

[JimmyZ]

@dark_samus3 I've implemented your method in bfCL:

>bfcl console_id_bcd 08A1522617110121 0000 d38bd9ce89d0f5d94d16747413c6e893 00000000000000000000000000000000 001f 1ced45c75e810bb6b51a5318e0fc5eee 000000000000000000000000000055aa
selected device Capeverde on platform AMD Accelerated Parallel Processing
0.395 seconds for OpenCL compiling
local work size: 256
08a1500000000000
08a1501000000000
08a1502000000000
08a1503000000000
08a1504000000000
08a1505000000000
08a1506000000000
08a1507000000000
08a1508000000000
08a1509000000000
08a1510000000000
08a1511000000000
08a1512000000000
08a1513000000000
08a1514000000000
08a1515000000000
08a1516000000000
08a1517000000000
08a1518000000000
08a1519000000000
08a1520000000000
08a1521000000000
08a1522000000000
got a hit: 08a1522617110121
80.06 seconds, 28.25 M/s

comparing with old method with EMMC CID supplied:

>bfcl console_id_bcd 08A1522617110121 ab6778e02d034d303046504100001500 0000 d38bd9ce89d0f5d94d16747413c6e893 00000000000000000000000000000000
selected device Capeverde on platform AMD Accelerated Parallel Processing
0.232 seconds for OpenCL compiling
local work size: 256
08a1500000000000
08a1501000000000
08a1502000000000
08a1503000000000
08a1504000000000
08a1505000000000
08a1506000000000
08a1507000000000
08a1508000000000
08a1509000000000
08a1510000000000
08a1511000000000
08a1512000000000
08a1513000000000
08a1514000000000
08a1515000000000
08a1516000000000
08a1517000000000
08a1518000000000
08a1519000000000
08a1520000000000
08a1521000000000
08a1522000000000
got a hit: 08a1522617110121
24.59 seconds, 91.97 M/s

I thought the time cost will be doubled, but actually it's tripled, interesting or I did something wrong.

 

[dark_samus3]

@JimmyZ the time cost about tripled for me too. Not sure if decryption just takes longer or something ( I doubt it...)

 

[JimmyZ]

@dark_samus3 I just looked at TWLbf code, it's already using mbedtls as a library, did you use a release source package instead of git head?

 

[JimmyZ]

BTW I'm dropping TWLbf, since EMMC CID brute doesn't require AES anymore, the purpose of having a separated OpenSSL version diminished, CPU based brute functionality will be absorbed into bfCL.

 

[JimmyZ]

Implemented better EMMC CID brute per @dark_samus3's suggestion in bfCL. it has a bigger impact(4x) on bfCL comparing to TWLbf, since GPU doesn't have AESNI.

https://github.com/Jimmy-Z/bfCL/releases/tag/0.4

 

[FFT]

Still looking for ConsoleID and CID of various versions? I would like to provide mine, they are 100% correct.

ConsoleID
08201
DSi XL, E, Dark Brown

08A21
DSi, U, Light Blue

EMMC CID
MY SS SS SS SS 03 4d 30 30 46 50 41 00 00 15 00
DSi XL, E, Dark Brown
DSi, U, Light Blue

I should have also dump from another DSi (E) Red system which had different numbering somewhere... I need to look on my old drive.

 

[Plstic]

so how do I exactly use this? there is no documentation for bfcl.

EDIT: Never mind, I got it working by using the script on the secondpage. Took me like 2 or 3 seconds with all 4 going. Console ID starts with
08202 and is a 25th anniversary dsi xl.

 

[JimmyZ]

Still looking for ConsoleID and CID of various versions? I would like to provide mine, they are 100% correct.

ConsoleID
08201
DSi XL, E, Dark Brown

08A21
DSi, U, Light Blue

EMMC CID
MY SS SS SS SS 03 4d 30 30 46 50 41 00 00 15 00
DSi XL, E, Dark Brown
DSi, U, Light Blue

I should have also dump from another DSi (E) Red system which had different numbering somewhere... I need to look on my old drive.

Thanks.

so how do I exactly use this? there is no documentation for bfcl.

EDIT: Never mind, I got it working by using the script on the secondpage. Took me like 2 or 3 seconds with all 4 going. Console ID starts with
08202 and is a 25th anniversary dsi xl.

bfCL shares the same command line interface with TWLbf, and I quote the OP: "bfCL on the other hand always saturate the best GPU in your system, so you shouldn't run multiple instances".