How the fcrt.bin is crypted ?

[deaphroat]

Hello

I know we can decrypt and extract a fcrt.bin from a Nand trinity or Corona but i would like to do by myself. Also know Xebuild and Flash Tool are not open source but if someone know how made this ?

A code like this :

Code:

RC4_KEY RC4Key;
unsigned char Digest[SHA_DIGEST_LENGTH];

m_EncyptedKVData = new unsigned char[0x4000];
m_DecryptedKVData = new unsigned char[0x4000];
unsigned char pKey[16] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };

CalculateHMACSHA( pKey, 0x10, m_EncyptedKVData, 0x10, Digest );
RC4_decrypt( &RC4Key, Digest, &m_EncyptedKVData[16], m_DecryptedKVData  );

There it's  for the keyvault implemented by me from 360_flash_dump_tool_sources_0_88a...

Thanks

[Dwack]

So far with just a quick glance it looks like it is AES using the CPU key as the AES key. Then doing AES cbc for decryption. Also looks like 0x100 into the fcrt.bin is used as the AES IV, with a length of 0x10.

[cory1492]

Something like this would probably work (I haven't tested this iteration, but I did test a previous one this is based on)... keep in mind this data is also signed to the console.

Code:

// feed with 0x4000 byte crypted fcrt.bin and 0x10 byte cpukey
// getBeU32 reads big endian 32bit value from a byte pointer
// the decrypted data in a hex editor still looks crypted when done, verified decrypted fcrt in mem of running console matches
bool decryptFcrt(unsigned char* fcrtdata, unsigned char* cpukey)
{
unsigned long offset = getBeU32(&fcrtdata[0x11c]);

if(offset <= 0x4000) // offset should never be > 0x4000
{
aes_decrypt_ctx aesctx;
SHA_CTX shactx;
unsigned char feed[0x10];
unsigned char sha[0x14];
unsigned char* pData;
unsigned long size = 0x4000 - offset;

memcpy(feed, &fcrtdata[0x100], 0x10);
aes_decrypt_key(cpukey, 16, &aesctx);
aes_cbc_decrypt(&fcrtdata[offset], &fcrtdata[offset], size, feed, &aesctx);

// non-destructive hashing
pData = (unsigned char*)malloc(size);
if(pdata != NULL)
{
memcpy(pData, &fcrtdata[offset], size);

SHA1_Init(&shactx);
SHA1_Update(&shactx, pData, size);
SHA1_Final(sha, &shactx);

free(pData);

if(memcmp(&fcrtdata[0x12C], sha, 0x14) == 0)
{
printf("+fcrt decrypt success");
return TRUE;
}
else
printf("-fcrt decrypt hash check failed");
}
else
printf("-malloc failed");
}
else
printf("-fcrt data offset is greater than expected size");
return FALSE;
}

[deaphroat]

I test your code and i say you it's is ok or not.

Thank you in advance.

I search this for make a little log for the xkey and the hitachi firmware...

I search the "same code" that flash tool use for extract fcrt with the key, that's too ^^

[cory1492]

It's too... what?   

The code there uses the same libs IIRC that flash tool does, it's just C and not C++.

[deaphroat]

You have write "keep in mind this data is also signed to the console."

Me I want extract decrypted fcrt, like flash tool, for the xkey.

If you give me a code in C or C++, is doesn't matter, I can translate a C on C++ ...( if I undestand the code ^^ )

[cory1492]

Yes, the first 0x100 bytes of FCRT.bin is a digital signature, one we do not have the private keys for meaning we cannot modify the data and sign new data for a console. Having the decrypted data and the way to 1:1 encrypt it again does not mean we can make *new* data for people that lost FCRT - so, keep in mind the data is signed, it cannot be transferred between consoles without resigning, and any changes break the digital signature.

The code there to decrypt and verify the decrypted result, is the same as what xbox does to decrypt and verify it apart from the RSA signature. I am not aware of any flash tool that does this (verify the RSA signature) and have not seen any public flash tool that can decrypt fcrt.bin.

[deaphroat]

I have understand....

For the Xkey we dont' need to decrypt the fcrt? extract it from the nand is enough ?

So i search for offset, i extract this and it's done ?

So i have finished ^^

[BestPig]

I have replied to you on my forum.

The fcrt_enc.bin and the fcrt.bin extract by my soft is always the same.
So the fcrt_enc.bin is not deciphered.

360 Flash Tool need the cpu key for extract it for unknown raison but if fcrt_enc.bin work for xkey, you need just an extraction from the original nand .

[hospitaldosgames]

The fcrt.bin contains many interesting information, based on the operation of the xkey, I believe that the key to decrypt the fcrt.bin is DVDkey, I have some experiences, but I know nothing about cryptography, but I think this is the way .

[Dwack]

I have replied to you on my forum.

The fcrt_enc.bin and the fcrt.bin extract by my soft is always the same.
So the fcrt_enc.bin is not deciphered.

360 Flash Tool need the cpu key for extract it for unknown raison but if fcrt_enc.bin work for xkey, you need just an extraction from the original nand .

I guess you missed corys' post. o.O

[TheArtificer]

The body of fwrct.bin is AES-CBC 'crypted using the CPU key and an IV at offset 0x100 (Thanks to you-know-who-you-are). Have a rummage in your favourite Hex editor for start & length of the body

Up until 16D5S there are two types of FW C/R:

Type one: checks the basic FW. We can handle these with a FW dump from any old drive
Type two: checks the basic FW + the customisation data (key, serials, filler crap). We can handle these for 16D4S since dummy.bin contains all that cruft

With the 16D5S there appeared a third type, basically a simplified version of type two

fwcrt.bin is used to generate & verify type two (or three) C/Rs. Since we can't get all the customisation data for 0500/0502/1175 drives we use the fwcrt.bin file (just like we used to use dae.bin to handle AP2.5)

Where the type one C/Rs are stored I don't know (nor do I care much)

<speculation> At the factory the console issues a series of challenges to a brand spanking drive, it then records the responses in fwcrt.bin ... </speculation>

[TheFallen93]

This code is not guaranteed to be complete and/or working and would require other code/libraries to function properly. I reversed a lot of the sata code from the 20xxx kernel + hv, here is some that may be of use to someone idk: http://pastebin.com/RiFxR3fi