You are viewing our Forum Archives. To view or take place in current topics click here.
#21. Posted:
Status: Offline
Joined: May 10, 20149Year Member
Posts: 16
Reputation Power: 0
Status: Offline
Joined: May 10, 20149Year Member
Posts: 16
Reputation Power: 0
Thank you, but this won't help the leeches.
- 0useful
- 0not useful
#22. Posted:
Status: Offline
Joined: Oct 03, 201310Year Member
Posts: 1,409
Reputation Power: 64
Here's an example of the first challenge hash. This is pretty much what code should look like when you want to generate a hash.
Like I said in the post, you will notice that XeCryptShaInit pretty much calls the start of the hashing, XeCryptShaUpdate does the hashing and XeCryptShaFinal stores what it hashed in the Response at 0xEC with a length of 0x14 (whole row if you're looking in HxD). If you're still confused about XeCryptSha, here's some comments that come straight from XeCrypt.h.
// SHA
//
// These functions implement the SHA-1 one-way hash algorithm. The result of the hash of
// any number of bytes is a digest of 20 bytes.
//
// XeCryptShaInit initializes an XECRYPT_SHA_STATE structure.
//
// Next, for each block of bytes that are to be hashed, call XeCryptShaUpdate. There is
// no limit to the size of the block, and it doesn't matter how the blocks are divided.
//
// Finally, call XeCryptShaFinal to compute the digest. Note that after calling this
// function the digest is available in the "state". The cbOut parameter can be less
// than 20 if only a prefix of the resulting digest is needed. It can be zero if the
// resulting digest will be read directly from the state structure.
//
// For convenience, all of these operations are combined by a single call to XeCryptSha
Now, the main reason people include a chal_resp.bin file with their local files is because the 2nd hash doesn't need to be generated every time. The rest of the hashes have to. I have the option in my XEX to either use a response file, generate it or if I want, I can copy the hex info for the 2nd hash that was stored in the response file and just place it in the correct address. The challenges may seem confusing to most, but just keep going and you will understand it. I was confused as hell when I was learning about the challenges, but I looked at how other sources worked and reversed more and it all came clear.
XeCryptShaInit(&SHA);
XeCryptShaUpdate(&SHA, (BYTE*)Salt, 0x10);
XeCryptShaUpdate(&SHA, HV + 0x34, 0x40);
XeCryptShaUpdate(&SHA, HV + 0x78, 0xF88);
XeCryptShaUpdate(&SHA, HV + 0x100C0, 0x40);
XeCryptShaUpdate(&SHA, HV + 0x10350, 0xDF0);
XeCryptShaUpdate(&SHA, HV + 0x16D20, 0x2E0);
XeCryptShaUpdate(&SHA, HV + 0x20000, 0xFFC);
XeCryptShaUpdate(&SHA, HV + 0x30000, 0xFFC);
XeCryptShaFinal(&SHA, Response + 0xEC, 0x14);
Like I said in the post, you will notice that XeCryptShaInit pretty much calls the start of the hashing, XeCryptShaUpdate does the hashing and XeCryptShaFinal stores what it hashed in the Response at 0xEC with a length of 0x14 (whole row if you're looking in HxD). If you're still confused about XeCryptSha, here's some comments that come straight from XeCrypt.h.
// SHA
//
// These functions implement the SHA-1 one-way hash algorithm. The result of the hash of
// any number of bytes is a digest of 20 bytes.
//
// XeCryptShaInit initializes an XECRYPT_SHA_STATE structure.
//
// Next, for each block of bytes that are to be hashed, call XeCryptShaUpdate. There is
// no limit to the size of the block, and it doesn't matter how the blocks are divided.
//
// Finally, call XeCryptShaFinal to compute the digest. Note that after calling this
// function the digest is available in the "state". The cbOut parameter can be less
// than 20 if only a prefix of the resulting digest is needed. It can be zero if the
// resulting digest will be read directly from the state structure.
//
// For convenience, all of these operations are combined by a single call to XeCryptSha
Now, the main reason people include a chal_resp.bin file with their local files is because the 2nd hash doesn't need to be generated every time. The rest of the hashes have to. I have the option in my XEX to either use a response file, generate it or if I want, I can copy the hex info for the 2nd hash that was stored in the response file and just place it in the correct address. The challenges may seem confusing to most, but just keep going and you will understand it. I was confused as hell when I was learning about the challenges, but I looked at how other sources worked and reversed more and it all came clear.
- 2useful
- 0not useful
#23. Posted:
Status: Offline
Joined: Feb 18, 201212Year Member
Posts: 773
Reputation Power: 32
I agree, I don't include the challenges with my plugin. I just use the one that is send to my console. Now the third hash in the challenge stays the same but is different for each console because its a SHA-1 hash of their console's KV CPU key.
Im sure you already know this, this is not aimed toward you it's aimed toward TTG members who are researching this, but the only reason why the first gets generated each boot is because it includes the HVSalt which is different every time you turn on the console.
Im sure you already know this, this is not aimed toward you it's aimed toward TTG members who are researching this, but the only reason why the first gets generated each boot is because it includes the HVSalt which is different every time you turn on the console.
- 1useful
- 0not useful
#24. Posted:
Status: Offline
Joined: Jun 20, 20149Year Member
Posts: 3
Reputation Power: 0
Nice post! I just got done with my plugin!
- 0useful
- 0not useful
You are viewing our Forum Archives. To view or take place in current topics click here.