You are viewing our Forum Archives. To view or take place in current topics click here.
Retail Hypervisor?
Posted:

Retail Hypervisor?Posted:

SpoofyMods
  • Challenger
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
Does anyone have a 16203 retail hypervisor? It can be non-reversed or reversed.

Please Private Message me as i am needing it. I will contact back some point tomorrow as i am off to bed in 30 minutes.
#2. Posted:
XeMario
  • Junior Member
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
[ Register or Signin to view external links. ] . mediafire. com/download/xp6jhiqd4tl32r7/HV_16203.bin (Remove Spaces)
#3. Posted:
SpoofyMods
  • Challenger
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
XeMario wrote [ Register or Signin to view external links. ] . mediafire. com/download/xp6jhiqd4tl32r7/HV_16203.bin (Remove Spaces)


See if this is a working one and the actual one.
#4. Posted:
-Peacee
  • Prospect
Status: Offline
Joined: Feb 01, 201014Year Member
Posts: 667
Reputation Power: 28
Status: Offline
Joined: Feb 01, 201014Year Member
Posts: 667
Reputation Power: 28
If someone had a Retail HV There would be a online method. No ones going to give it to you. This will give you a push in the right direction.
int DoChallenge(BYTE * response, BYTE * HVSalt)
{
    // Open retail hv
    HANDLE hHV = CreateFile("Hdd:\\HV_16203.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hHV == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find retail HV!\n" );
        return -1;
    }
    // Read into memory
    DWORD noBytesRead;
    BYTE * pHV = (BYTE*)XPhysicalAlloc( 0x40000, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hHV, pHV, 0x40000, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hHV);
 
    // Open cpu key of current kv
    HANDLE hCPUKey = CreateFile("Hdd:\\CPU_KEY.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hCPUKey == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find CPU_KEY.bin!\n" );
        return -1;
    }
 
    // Read into memory
    BYTE * pCpuKey = (BYTE*)XPhysicalAlloc( 0x10, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hCPUKey, pCpuKey, 0x10, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hCPUKey);
 
    // Copy stuff from HV
    *(QWORD*)(response + 0x28) = *(QWORD*)pHV;
    *(QWORD*)(response + 0x30) = *(QWORD*)(pHV + 0x10);
    *(DWORD*)(response + 0x38) = *(DWORD*)(pHV + 0x30);
    *(DWORD*)(response + 0x3C) = *(DWORD*)(pHV + 0x74);
 
    *(QWORD*)(response + 0x40) = 0x0000000200000000LL;
    *(QWORD*)(response + 0x48) = 0x0000010000000000LL;
 
    // Initialise SHA1
    XECRYPT_SHA_STATE sha;
    XeCryptShaInit(&sha);
 
    // SHA1 - HV salt
    XeCryptShaUpdate( &sha, HVSalt, 0x10 );
 
    // SHA1 - HV 0x34 -> 0x74
    XeCryptShaUpdate( &sha, pHV + 0x34, 0x40 );
 
    // SHA1 - HV 0x78 -> 0x10000
    XeCryptShaUpdate( &sha, pHV + 0x78, 0xFF88 );
 
    // SHA1 - HV 0x100C0 -> 0x100F0
    XeCryptShaUpdate( &sha, pHV + 0x100C0, 0x30 );
 
    // SHA1 - HV 0x100F0 -> 0x10100
    XeCryptShaUpdate( &sha, pHV + 0x100F0, 0x10 );
 
    // SHA1 - HV 0x10350 -> 0x16060
    XeCryptShaUpdate( &sha, pHV + 0x10350, 0x5D10 );
 
    // SHA1 - HV 0x16C40 -> 0x20000
    XeCryptShaUpdate( &sha, pHV + 0x16C40, 0x93C0 );
 
    // SHA1 - HV 0x20000 -> 0x2FFFC
    XeCryptShaUpdate( &sha, pHV + 0x20000, 0xFFFC );
 
    // SHA1 - HV 0x30000 -> 0x3FFFC
    XeCryptShaUpdate( &sha, pHV + 0x30000, 0xFFFC );
 
    // Copy hash to response + 0x50
    XeCryptShaFinal( &sha, response + 0x50, 0x14 );
 
    // Hash CPU key to repsonse + 0x64
    XeCryptSha( pCpuKey, 0x10, 0, 0, 0, 0, response + 0x64, 0x14 );
 
    // Copy more stuff from HV
    memcpy( response + 0xA0, pHV + 0x10040, 0x80 );
 
    XPhysicalFree(pHV);
    XPhysicalFree(pCpuKey);
 
    return 0;
}

and
HV 0x04 -> 0x08 - this is written to in CD after CF verification but just before loading
AND just before jumping to reset vector in HV

HV 0x14 -> 0x18 - this is also written to in CD
^ I think this is valid, jtag val stored in CF

HV 0x74 -> 0x78 - written to during HvxKeysInitialize

HV 0x10000 -> 0x1032E - partly hashed (0x100C0 -> 0x10100), looks like more hashes:

0x100C0 is an SHA1 of the below (loaded as QWORDS except 0x2, hashed as QWORDS):
0x80000200 00033100, 0x80000200 00030000, 0x80000200 00060700, 0x80000200 00060840,
0x80000200 00061060, 0x80000200 00050000, 0x80000200 00050008, 0x80000200 00050070,
0x00000000 00000002

0x100D0 is an SHA1 of the below (loaded as DWORDS except 0x2, hashed as QWORDS):
0x80000200 D0000018, 0x80000200 D0000050, 0x80000200 D0000054, 0x80000200 D0000010,
0x80000200 D0108010, 0x80000200 D0108014, 0x80000200 D0108068, 0x80000200 D0110010,
0x80000200 D0110014, 0x80000200 D0110068, 0x80000200 D0138010, 0x80000200 D0138068,
0x80000200 D0148010, 0x80000200 D0148068, 0x80000200 D0148010, 0x80000200 D0148068,
0x80000200 D0100010, 0x80000200 D0100068, 0x80000200 D0140010, 0x80000200 D0140014,
0x80000200 D0140068, 0x80000200 D0150010, 0x80000200 D0150068, 0x80000200 D0010010,
0x80000200 D0121040, 0x80000200 D0129040, 0x80000200 D0121044, 0x80000200 D0129044,
0x80000200 D0108060, 0x80000200 D0110060, 0x80000200 D0108080, 0x80000200 D0110080,
0x00000000 00000002

0x100E0 is an SHA1 of the below (hashed as QWORDS):
XeCryptShaUpdate( &sha, HRMOR ( 0x10000000000 ), 0x8 ); // definately valid
XeCryptShaUpdate( &sha, LPCR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, MSR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, HID1 ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, 0x0000000000003F4B, 0x8 ); // definately valid

0x100F0 is an SHA1 of the below (from sub_1C78):
0x80000200 00010002, 0x3FE bytes
0x80000200 00010412, 0x16A bytes
0x80000200 000105B2, 0x24E bytes
0x80000200 00010800, 0x400 bytes
0x80000200 00010C00, 0x400 bytes
^ That is the CB, which is handled in 1BL. Maybe more so later on, but definately 1BL.
IN FACT, when 1BL is finished with that memory, it nulls most of it, so maybe it's used elsewhere...

HV 0x10040 -> 0x100C0 - needs checking, gets copied to buffer, seems to change each time

// everything below looks fine, the data the hmac hashes hash is the same as retail....
HV 0x10EA8 -> 0x10EC7 - gets hashed:

0x10EA8 -> 0x10EB7 - hmacsha1 hash of 0x10CE8, length 0x10 using the key at 0x18
0x10EB8 -> 0x10EC7 - hmacsha1 hash of 0x10CD8, length 0x10 using the key at 0x18

HV 0x54 -> 0x64 - hmacsha1 hash of 0x10BA8, length 0x10 using the key at 0x18

Credit to XOR on 7S for all this.
#5. Posted:
XeMario
  • Junior Member
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
-Peacee wrote If someone had a Retail HV There would be a online method. No ones going to give it to you. This will give you a push in the right direction.
int DoChallenge(BYTE * response, BYTE * HVSalt)
{
    // Open retail hv
    HANDLE hHV = CreateFile("Hdd:\\HV_16203.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hHV == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find retail HV!\n" );
        return -1;
    }
    // Read into memory
    DWORD noBytesRead;
    BYTE * pHV = (BYTE*)XPhysicalAlloc( 0x40000, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hHV, pHV, 0x40000, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hHV);
 
    // Open cpu key of current kv
    HANDLE hCPUKey = CreateFile("Hdd:\\CPU_KEY.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hCPUKey == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find CPU_KEY.bin!\n" );
        return -1;
    }
 
    // Read into memory
    BYTE * pCpuKey = (BYTE*)XPhysicalAlloc( 0x10, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hCPUKey, pCpuKey, 0x10, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hCPUKey);
 
    // Copy stuff from HV
    *(QWORD*)(response + 0x28) = *(QWORD*)pHV;
    *(QWORD*)(response + 0x30) = *(QWORD*)(pHV + 0x10);
    *(DWORD*)(response + 0x38) = *(DWORD*)(pHV + 0x30);
    *(DWORD*)(response + 0x3C) = *(DWORD*)(pHV + 0x74);
 
    *(QWORD*)(response + 0x40) = 0x0000000200000000LL;
    *(QWORD*)(response + 0x48) = 0x0000010000000000LL;
 
    // Initialise SHA1
    XECRYPT_SHA_STATE sha;
    XeCryptShaInit(&sha);
 
    // SHA1 - HV salt
    XeCryptShaUpdate( &sha, HVSalt, 0x10 );
 
    // SHA1 - HV 0x34 -> 0x74
    XeCryptShaUpdate( &sha, pHV + 0x34, 0x40 );
 
    // SHA1 - HV 0x78 -> 0x10000
    XeCryptShaUpdate( &sha, pHV + 0x78, 0xFF88 );
 
    // SHA1 - HV 0x100C0 -> 0x100F0
    XeCryptShaUpdate( &sha, pHV + 0x100C0, 0x30 );
 
    // SHA1 - HV 0x100F0 -> 0x10100
    XeCryptShaUpdate( &sha, pHV + 0x100F0, 0x10 );
 
    // SHA1 - HV 0x10350 -> 0x16060
    XeCryptShaUpdate( &sha, pHV + 0x10350, 0x5D10 );
 
    // SHA1 - HV 0x16C40 -> 0x20000
    XeCryptShaUpdate( &sha, pHV + 0x16C40, 0x93C0 );
 
    // SHA1 - HV 0x20000 -> 0x2FFFC
    XeCryptShaUpdate( &sha, pHV + 0x20000, 0xFFFC );
 
    // SHA1 - HV 0x30000 -> 0x3FFFC
    XeCryptShaUpdate( &sha, pHV + 0x30000, 0xFFFC );
 
    // Copy hash to response + 0x50
    XeCryptShaFinal( &sha, response + 0x50, 0x14 );
 
    // Hash CPU key to repsonse + 0x64
    XeCryptSha( pCpuKey, 0x10, 0, 0, 0, 0, response + 0x64, 0x14 );
 
    // Copy more stuff from HV
    memcpy( response + 0xA0, pHV + 0x10040, 0x80 );
 
    XPhysicalFree(pHV);
    XPhysicalFree(pCpuKey);
 
    return 0;
}

and
HV 0x04 -> 0x08 - this is written to in CD after CF verification but just before loading
AND just before jumping to reset vector in HV

HV 0x14 -> 0x18 - this is also written to in CD
^ I think this is valid, jtag val stored in CF

HV 0x74 -> 0x78 - written to during HvxKeysInitialize

HV 0x10000 -> 0x1032E - partly hashed (0x100C0 -> 0x10100), looks like more hashes:

0x100C0 is an SHA1 of the below (loaded as QWORDS except 0x2, hashed as QWORDS):
0x80000200 00033100, 0x80000200 00030000, 0x80000200 00060700, 0x80000200 00060840,
0x80000200 00061060, 0x80000200 00050000, 0x80000200 00050008, 0x80000200 00050070,
0x00000000 00000002

0x100D0 is an SHA1 of the below (loaded as DWORDS except 0x2, hashed as QWORDS):
0x80000200 D0000018, 0x80000200 D0000050, 0x80000200 D0000054, 0x80000200 D0000010,
0x80000200 D0108010, 0x80000200 D0108014, 0x80000200 D0108068, 0x80000200 D0110010,
0x80000200 D0110014, 0x80000200 D0110068, 0x80000200 D0138010, 0x80000200 D0138068,
0x80000200 D0148010, 0x80000200 D0148068, 0x80000200 D0148010, 0x80000200 D0148068,
0x80000200 D0100010, 0x80000200 D0100068, 0x80000200 D0140010, 0x80000200 D0140014,
0x80000200 D0140068, 0x80000200 D0150010, 0x80000200 D0150068, 0x80000200 D0010010,
0x80000200 D0121040, 0x80000200 D0129040, 0x80000200 D0121044, 0x80000200 D0129044,
0x80000200 D0108060, 0x80000200 D0110060, 0x80000200 D0108080, 0x80000200 D0110080,
0x00000000 00000002

0x100E0 is an SHA1 of the below (hashed as QWORDS):
XeCryptShaUpdate( &sha, HRMOR ( 0x10000000000 ), 0x8 ); // definately valid
XeCryptShaUpdate( &sha, LPCR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, MSR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, HID1 ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, 0x0000000000003F4B, 0x8 ); // definately valid

0x100F0 is an SHA1 of the below (from sub_1C78):
0x80000200 00010002, 0x3FE bytes
0x80000200 00010412, 0x16A bytes
0x80000200 000105B2, 0x24E bytes
0x80000200 00010800, 0x400 bytes
0x80000200 00010C00, 0x400 bytes
^ That is the CB, which is handled in 1BL. Maybe more so later on, but definately 1BL.
IN FACT, when 1BL is finished with that memory, it nulls most of it, so maybe it's used elsewhere...

HV 0x10040 -> 0x100C0 - needs checking, gets copied to buffer, seems to change each time

// everything below looks fine, the data the hmac hashes hash is the same as retail....
HV 0x10EA8 -> 0x10EC7 - gets hashed:

0x10EA8 -> 0x10EB7 - hmacsha1 hash of 0x10CE8, length 0x10 using the key at 0x18
0x10EB8 -> 0x10EC7 - hmacsha1 hash of 0x10CD8, length 0x10 using the key at 0x18

HV 0x54 -> 0x64 - hmacsha1 hash of 0x10BA8, length 0x10 using the key at 0x18

Credit to XOR on 7S for all this.
It shouldn't be that difficult to reverse the changes made by XeBuild
#6. Posted:
-Peacee
  • Prospect
Status: Offline
Joined: Feb 01, 201014Year Member
Posts: 667
Reputation Power: 28
Status: Offline
Joined: Feb 01, 201014Year Member
Posts: 667
Reputation Power: 28
XeMario wrote
-Peacee wrote If someone had a Retail HV There would be a online method. No ones going to give it to you. This will give you a push in the right direction.
int DoChallenge(BYTE * response, BYTE * HVSalt)
{
    // Open retail hv
    HANDLE hHV = CreateFile("Hdd:\\HV_16203.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hHV == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find retail HV!\n" );
        return -1;
    }
    // Read into memory
    DWORD noBytesRead;
    BYTE * pHV = (BYTE*)XPhysicalAlloc( 0x40000, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hHV, pHV, 0x40000, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hHV);
 
    // Open cpu key of current kv
    HANDLE hCPUKey = CreateFile("Hdd:\\CPU_KEY.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hCPUKey == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find CPU_KEY.bin!\n" );
        return -1;
    }
 
    // Read into memory
    BYTE * pCpuKey = (BYTE*)XPhysicalAlloc( 0x10, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hCPUKey, pCpuKey, 0x10, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hCPUKey);
 
    // Copy stuff from HV
    *(QWORD*)(response + 0x28) = *(QWORD*)pHV;
    *(QWORD*)(response + 0x30) = *(QWORD*)(pHV + 0x10);
    *(DWORD*)(response + 0x38) = *(DWORD*)(pHV + 0x30);
    *(DWORD*)(response + 0x3C) = *(DWORD*)(pHV + 0x74);
 
    *(QWORD*)(response + 0x40) = 0x0000000200000000LL;
    *(QWORD*)(response + 0x48) = 0x0000010000000000LL;
 
    // Initialise SHA1
    XECRYPT_SHA_STATE sha;
    XeCryptShaInit(&sha);
 
    // SHA1 - HV salt
    XeCryptShaUpdate( &sha, HVSalt, 0x10 );
 
    // SHA1 - HV 0x34 -> 0x74
    XeCryptShaUpdate( &sha, pHV + 0x34, 0x40 );
 
    // SHA1 - HV 0x78 -> 0x10000
    XeCryptShaUpdate( &sha, pHV + 0x78, 0xFF88 );
 
    // SHA1 - HV 0x100C0 -> 0x100F0
    XeCryptShaUpdate( &sha, pHV + 0x100C0, 0x30 );
 
    // SHA1 - HV 0x100F0 -> 0x10100
    XeCryptShaUpdate( &sha, pHV + 0x100F0, 0x10 );
 
    // SHA1 - HV 0x10350 -> 0x16060
    XeCryptShaUpdate( &sha, pHV + 0x10350, 0x5D10 );
 
    // SHA1 - HV 0x16C40 -> 0x20000
    XeCryptShaUpdate( &sha, pHV + 0x16C40, 0x93C0 );
 
    // SHA1 - HV 0x20000 -> 0x2FFFC
    XeCryptShaUpdate( &sha, pHV + 0x20000, 0xFFFC );
 
    // SHA1 - HV 0x30000 -> 0x3FFFC
    XeCryptShaUpdate( &sha, pHV + 0x30000, 0xFFFC );
 
    // Copy hash to response + 0x50
    XeCryptShaFinal( &sha, response + 0x50, 0x14 );
 
    // Hash CPU key to repsonse + 0x64
    XeCryptSha( pCpuKey, 0x10, 0, 0, 0, 0, response + 0x64, 0x14 );
 
    // Copy more stuff from HV
    memcpy( response + 0xA0, pHV + 0x10040, 0x80 );
 
    XPhysicalFree(pHV);
    XPhysicalFree(pCpuKey);
 
    return 0;
}

and
HV 0x04 -> 0x08 - this is written to in CD after CF verification but just before loading
AND just before jumping to reset vector in HV

HV 0x14 -> 0x18 - this is also written to in CD
^ I think this is valid, jtag val stored in CF

HV 0x74 -> 0x78 - written to during HvxKeysInitialize

HV 0x10000 -> 0x1032E - partly hashed (0x100C0 -> 0x10100), looks like more hashes:

0x100C0 is an SHA1 of the below (loaded as QWORDS except 0x2, hashed as QWORDS):
0x80000200 00033100, 0x80000200 00030000, 0x80000200 00060700, 0x80000200 00060840,
0x80000200 00061060, 0x80000200 00050000, 0x80000200 00050008, 0x80000200 00050070,
0x00000000 00000002

0x100D0 is an SHA1 of the below (loaded as DWORDS except 0x2, hashed as QWORDS):
0x80000200 D0000018, 0x80000200 D0000050, 0x80000200 D0000054, 0x80000200 D0000010,
0x80000200 D0108010, 0x80000200 D0108014, 0x80000200 D0108068, 0x80000200 D0110010,
0x80000200 D0110014, 0x80000200 D0110068, 0x80000200 D0138010, 0x80000200 D0138068,
0x80000200 D0148010, 0x80000200 D0148068, 0x80000200 D0148010, 0x80000200 D0148068,
0x80000200 D0100010, 0x80000200 D0100068, 0x80000200 D0140010, 0x80000200 D0140014,
0x80000200 D0140068, 0x80000200 D0150010, 0x80000200 D0150068, 0x80000200 D0010010,
0x80000200 D0121040, 0x80000200 D0129040, 0x80000200 D0121044, 0x80000200 D0129044,
0x80000200 D0108060, 0x80000200 D0110060, 0x80000200 D0108080, 0x80000200 D0110080,
0x00000000 00000002

0x100E0 is an SHA1 of the below (hashed as QWORDS):
XeCryptShaUpdate( &sha, HRMOR ( 0x10000000000 ), 0x8 ); // definately valid
XeCryptShaUpdate( &sha, LPCR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, MSR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, HID1 ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, 0x0000000000003F4B, 0x8 ); // definately valid

0x100F0 is an SHA1 of the below (from sub_1C78):
0x80000200 00010002, 0x3FE bytes
0x80000200 00010412, 0x16A bytes
0x80000200 000105B2, 0x24E bytes
0x80000200 00010800, 0x400 bytes
0x80000200 00010C00, 0x400 bytes
^ That is the CB, which is handled in 1BL. Maybe more so later on, but definately 1BL.
IN FACT, when 1BL is finished with that memory, it nulls most of it, so maybe it's used elsewhere...

HV 0x10040 -> 0x100C0 - needs checking, gets copied to buffer, seems to change each time

// everything below looks fine, the data the hmac hashes hash is the same as retail....
HV 0x10EA8 -> 0x10EC7 - gets hashed:

0x10EA8 -> 0x10EB7 - hmacsha1 hash of 0x10CE8, length 0x10 using the key at 0x18
0x10EB8 -> 0x10EC7 - hmacsha1 hash of 0x10CD8, length 0x10 using the key at 0x18

HV 0x54 -> 0x64 - hmacsha1 hash of 0x10BA8, length 0x10 using the key at 0x18

Credit to XOR on 7S for all this.
It shouldn't be that difficult to reverse the changes made by XeBuild

It's obvious you know nothing about getting online. Just reversing the changes Xebuild makes won't make it pass, and you most likely dumped that earlier HV with Dwacks tool. It stores a payload on Hv that you have to get rid of aswell. You need a Live state Retail HV. Look through the challenge data and see where the responses are coming from then go look into it and see how you can correct it.
#7. Posted:
XeMario
  • Junior Member
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
-Peacee wrote
XeMario wrote
-Peacee wrote If someone had a Retail HV There would be a online method. No ones going to give it to you. This will give you a push in the right direction.
int DoChallenge(BYTE * response, BYTE * HVSalt)
{
    // Open retail hv
    HANDLE hHV = CreateFile("Hdd:\\HV_16203.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hHV == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find retail HV!\n" );
        return -1;
    }
    // Read into memory
    DWORD noBytesRead;
    BYTE * pHV = (BYTE*)XPhysicalAlloc( 0x40000, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hHV, pHV, 0x40000, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hHV);
 
    // Open cpu key of current kv
    HANDLE hCPUKey = CreateFile("Hdd:\\CPU_KEY.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hCPUKey == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find CPU_KEY.bin!\n" );
        return -1;
    }
 
    // Read into memory
    BYTE * pCpuKey = (BYTE*)XPhysicalAlloc( 0x10, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hCPUKey, pCpuKey, 0x10, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hCPUKey);
 
    // Copy stuff from HV
    *(QWORD*)(response + 0x28) = *(QWORD*)pHV;
    *(QWORD*)(response + 0x30) = *(QWORD*)(pHV + 0x10);
    *(DWORD*)(response + 0x38) = *(DWORD*)(pHV + 0x30);
    *(DWORD*)(response + 0x3C) = *(DWORD*)(pHV + 0x74);
 
    *(QWORD*)(response + 0x40) = 0x0000000200000000LL;
    *(QWORD*)(response + 0x48) = 0x0000010000000000LL;
 
    // Initialise SHA1
    XECRYPT_SHA_STATE sha;
    XeCryptShaInit(&sha);
 
    // SHA1 - HV salt
    XeCryptShaUpdate( &sha, HVSalt, 0x10 );
 
    // SHA1 - HV 0x34 -> 0x74
    XeCryptShaUpdate( &sha, pHV + 0x34, 0x40 );
 
    // SHA1 - HV 0x78 -> 0x10000
    XeCryptShaUpdate( &sha, pHV + 0x78, 0xFF88 );
 
    // SHA1 - HV 0x100C0 -> 0x100F0
    XeCryptShaUpdate( &sha, pHV + 0x100C0, 0x30 );
 
    // SHA1 - HV 0x100F0 -> 0x10100
    XeCryptShaUpdate( &sha, pHV + 0x100F0, 0x10 );
 
    // SHA1 - HV 0x10350 -> 0x16060
    XeCryptShaUpdate( &sha, pHV + 0x10350, 0x5D10 );
 
    // SHA1 - HV 0x16C40 -> 0x20000
    XeCryptShaUpdate( &sha, pHV + 0x16C40, 0x93C0 );
 
    // SHA1 - HV 0x20000 -> 0x2FFFC
    XeCryptShaUpdate( &sha, pHV + 0x20000, 0xFFFC );
 
    // SHA1 - HV 0x30000 -> 0x3FFFC
    XeCryptShaUpdate( &sha, pHV + 0x30000, 0xFFFC );
 
    // Copy hash to response + 0x50
    XeCryptShaFinal( &sha, response + 0x50, 0x14 );
 
    // Hash CPU key to repsonse + 0x64
    XeCryptSha( pCpuKey, 0x10, 0, 0, 0, 0, response + 0x64, 0x14 );
 
    // Copy more stuff from HV
    memcpy( response + 0xA0, pHV + 0x10040, 0x80 );
 
    XPhysicalFree(pHV);
    XPhysicalFree(pCpuKey);
 
    return 0;
}

and
HV 0x04 -> 0x08 - this is written to in CD after CF verification but just before loading
AND just before jumping to reset vector in HV

HV 0x14 -> 0x18 - this is also written to in CD
^ I think this is valid, jtag val stored in CF

HV 0x74 -> 0x78 - written to during HvxKeysInitialize

HV 0x10000 -> 0x1032E - partly hashed (0x100C0 -> 0x10100), looks like more hashes:

0x100C0 is an SHA1 of the below (loaded as QWORDS except 0x2, hashed as QWORDS):
0x80000200 00033100, 0x80000200 00030000, 0x80000200 00060700, 0x80000200 00060840,
0x80000200 00061060, 0x80000200 00050000, 0x80000200 00050008, 0x80000200 00050070,
0x00000000 00000002

0x100D0 is an SHA1 of the below (loaded as DWORDS except 0x2, hashed as QWORDS):
0x80000200 D0000018, 0x80000200 D0000050, 0x80000200 D0000054, 0x80000200 D0000010,
0x80000200 D0108010, 0x80000200 D0108014, 0x80000200 D0108068, 0x80000200 D0110010,
0x80000200 D0110014, 0x80000200 D0110068, 0x80000200 D0138010, 0x80000200 D0138068,
0x80000200 D0148010, 0x80000200 D0148068, 0x80000200 D0148010, 0x80000200 D0148068,
0x80000200 D0100010, 0x80000200 D0100068, 0x80000200 D0140010, 0x80000200 D0140014,
0x80000200 D0140068, 0x80000200 D0150010, 0x80000200 D0150068, 0x80000200 D0010010,
0x80000200 D0121040, 0x80000200 D0129040, 0x80000200 D0121044, 0x80000200 D0129044,
0x80000200 D0108060, 0x80000200 D0110060, 0x80000200 D0108080, 0x80000200 D0110080,
0x00000000 00000002

0x100E0 is an SHA1 of the below (hashed as QWORDS):
XeCryptShaUpdate( &sha, HRMOR ( 0x10000000000 ), 0x8 ); // definately valid
XeCryptShaUpdate( &sha, LPCR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, MSR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, HID1 ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, 0x0000000000003F4B, 0x8 ); // definately valid

0x100F0 is an SHA1 of the below (from sub_1C78):
0x80000200 00010002, 0x3FE bytes
0x80000200 00010412, 0x16A bytes
0x80000200 000105B2, 0x24E bytes
0x80000200 00010800, 0x400 bytes
0x80000200 00010C00, 0x400 bytes
^ That is the CB, which is handled in 1BL. Maybe more so later on, but definately 1BL.
IN FACT, when 1BL is finished with that memory, it nulls most of it, so maybe it's used elsewhere...

HV 0x10040 -> 0x100C0 - needs checking, gets copied to buffer, seems to change each time

// everything below looks fine, the data the hmac hashes hash is the same as retail....
HV 0x10EA8 -> 0x10EC7 - gets hashed:

0x10EA8 -> 0x10EB7 - hmacsha1 hash of 0x10CE8, length 0x10 using the key at 0x18
0x10EB8 -> 0x10EC7 - hmacsha1 hash of 0x10CD8, length 0x10 using the key at 0x18

HV 0x54 -> 0x64 - hmacsha1 hash of 0x10BA8, length 0x10 using the key at 0x18

Credit to XOR on 7S for all this.
It shouldn't be that difficult to reverse the changes made by XeBuild

It's obvious you know nothing about getting online. Just reversing the changes Xebuild makes won't make it pass, and you most likely dumped that earlier HV with Dwacks tool. It stores a payload on Hv that you have to get rid of aswell. You need a Live state Retail HV. Look through the challenge data and see where the responses are coming from then go look into it and see how you can correct it.
Yah I don't really know much so thanks for the info
#8. Posted:
SpoofyMods
  • Challenger
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
-Peacee wrote If someone had a Retail HV There would be a online method. No ones going to give it to you. This will give you a push in the right direction.
int DoChallenge(BYTE * response, BYTE * HVSalt)
{
    // Open retail hv
    HANDLE hHV = CreateFile("Hdd:\\HV_16203.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hHV == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find retail HV!\n" );
        return -1;
    }
    // Read into memory
    DWORD noBytesRead;
    BYTE * pHV = (BYTE*)XPhysicalAlloc( 0x40000, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hHV, pHV, 0x40000, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hHV);
 
    // Open cpu key of current kv
    HANDLE hCPUKey = CreateFile("Hdd:\\CPU_KEY.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hCPUKey == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find CPU_KEY.bin!\n" );
        return -1;
    }
 
    // Read into memory
    BYTE * pCpuKey = (BYTE*)XPhysicalAlloc( 0x10, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hCPUKey, pCpuKey, 0x10, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hCPUKey);
 
    // Copy stuff from HV
    *(QWORD*)(response + 0x28) = *(QWORD*)pHV;
    *(QWORD*)(response + 0x30) = *(QWORD*)(pHV + 0x10);
    *(DWORD*)(response + 0x38) = *(DWORD*)(pHV + 0x30);
    *(DWORD*)(response + 0x3C) = *(DWORD*)(pHV + 0x74);
 
    *(QWORD*)(response + 0x40) = 0x0000000200000000LL;
    *(QWORD*)(response + 0x48) = 0x0000010000000000LL;
 
    // Initialise SHA1
    XECRYPT_SHA_STATE sha;
    XeCryptShaInit(&sha);
 
    // SHA1 - HV salt
    XeCryptShaUpdate( &sha, HVSalt, 0x10 );
 
    // SHA1 - HV 0x34 -> 0x74
    XeCryptShaUpdate( &sha, pHV + 0x34, 0x40 );
 
    // SHA1 - HV 0x78 -> 0x10000
    XeCryptShaUpdate( &sha, pHV + 0x78, 0xFF88 );
 
    // SHA1 - HV 0x100C0 -> 0x100F0
    XeCryptShaUpdate( &sha, pHV + 0x100C0, 0x30 );
 
    // SHA1 - HV 0x100F0 -> 0x10100
    XeCryptShaUpdate( &sha, pHV + 0x100F0, 0x10 );
 
    // SHA1 - HV 0x10350 -> 0x16060
    XeCryptShaUpdate( &sha, pHV + 0x10350, 0x5D10 );
 
    // SHA1 - HV 0x16C40 -> 0x20000
    XeCryptShaUpdate( &sha, pHV + 0x16C40, 0x93C0 );
 
    // SHA1 - HV 0x20000 -> 0x2FFFC
    XeCryptShaUpdate( &sha, pHV + 0x20000, 0xFFFC );
 
    // SHA1 - HV 0x30000 -> 0x3FFFC
    XeCryptShaUpdate( &sha, pHV + 0x30000, 0xFFFC );
 
    // Copy hash to response + 0x50
    XeCryptShaFinal( &sha, response + 0x50, 0x14 );
 
    // Hash CPU key to repsonse + 0x64
    XeCryptSha( pCpuKey, 0x10, 0, 0, 0, 0, response + 0x64, 0x14 );
 
    // Copy more stuff from HV
    memcpy( response + 0xA0, pHV + 0x10040, 0x80 );
 
    XPhysicalFree(pHV);
    XPhysicalFree(pCpuKey);
 
    return 0;
}

and
HV 0x04 -> 0x08 - this is written to in CD after CF verification but just before loading
AND just before jumping to reset vector in HV

HV 0x14 -> 0x18 - this is also written to in CD
^ I think this is valid, jtag val stored in CF

HV 0x74 -> 0x78 - written to during HvxKeysInitialize

HV 0x10000 -> 0x1032E - partly hashed (0x100C0 -> 0x10100), looks like more hashes:

0x100C0 is an SHA1 of the below (loaded as QWORDS except 0x2, hashed as QWORDS):
0x80000200 00033100, 0x80000200 00030000, 0x80000200 00060700, 0x80000200 00060840,
0x80000200 00061060, 0x80000200 00050000, 0x80000200 00050008, 0x80000200 00050070,
0x00000000 00000002

0x100D0 is an SHA1 of the below (loaded as DWORDS except 0x2, hashed as QWORDS):
0x80000200 D0000018, 0x80000200 D0000050, 0x80000200 D0000054, 0x80000200 D0000010,
0x80000200 D0108010, 0x80000200 D0108014, 0x80000200 D0108068, 0x80000200 D0110010,
0x80000200 D0110014, 0x80000200 D0110068, 0x80000200 D0138010, 0x80000200 D0138068,
0x80000200 D0148010, 0x80000200 D0148068, 0x80000200 D0148010, 0x80000200 D0148068,
0x80000200 D0100010, 0x80000200 D0100068, 0x80000200 D0140010, 0x80000200 D0140014,
0x80000200 D0140068, 0x80000200 D0150010, 0x80000200 D0150068, 0x80000200 D0010010,
0x80000200 D0121040, 0x80000200 D0129040, 0x80000200 D0121044, 0x80000200 D0129044,
0x80000200 D0108060, 0x80000200 D0110060, 0x80000200 D0108080, 0x80000200 D0110080,
0x00000000 00000002

0x100E0 is an SHA1 of the below (hashed as QWORDS):
XeCryptShaUpdate( &sha, HRMOR ( 0x10000000000 ), 0x8 ); // definately valid
XeCryptShaUpdate( &sha, LPCR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, MSR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, HID1 ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, 0x0000000000003F4B, 0x8 ); // definately valid

0x100F0 is an SHA1 of the below (from sub_1C78):
0x80000200 00010002, 0x3FE bytes
0x80000200 00010412, 0x16A bytes
0x80000200 000105B2, 0x24E bytes
0x80000200 00010800, 0x400 bytes
0x80000200 00010C00, 0x400 bytes
^ That is the CB, which is handled in 1BL. Maybe more so later on, but definately 1BL.
IN FACT, when 1BL is finished with that memory, it nulls most of it, so maybe it's used elsewhere...

HV 0x10040 -> 0x100C0 - needs checking, gets copied to buffer, seems to change each time

// everything below looks fine, the data the hmac hashes hash is the same as retail....
HV 0x10EA8 -> 0x10EC7 - gets hashed:

0x10EA8 -> 0x10EB7 - hmacsha1 hash of 0x10CE8, length 0x10 using the key at 0x18
0x10EB8 -> 0x10EC7 - hmacsha1 hash of 0x10CD8, length 0x10 using the key at 0x18

HV 0x54 -> 0x64 - hmacsha1 hash of 0x10BA8, length 0x10 using the key at 0x18

Credit to XOR on 7S for all this.


Thanks for this, going to take a look at this later on tonight after work.
#9. Posted:
cpp_modder
  • Resident Elite
Status: Offline
Joined: Aug 20, 201211Year Member
Posts: 256
Reputation Power: 9
Status: Offline
Joined: Aug 20, 201211Year Member
Posts: 256
Reputation Power: 9
-Peacee wrote
XeMario wrote
-Peacee wrote If someone had a Retail HV There would be a online method. No ones going to give it to you. This will give you a push in the right direction.
int DoChallenge(BYTE * response, BYTE * HVSalt)
{
    // Open retail hv
    HANDLE hHV = CreateFile("Hdd:\\HV_16203.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hHV == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find retail HV!\n" );
        return -1;
    }
    // Read into memory
    DWORD noBytesRead;
    BYTE * pHV = (BYTE*)XPhysicalAlloc( 0x40000, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hHV, pHV, 0x40000, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hHV);
 
    // Open cpu key of current kv
    HANDLE hCPUKey = CreateFile("Hdd:\\CPU_KEY.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hCPUKey == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find CPU_KEY.bin!\n" );
        return -1;
    }
 
    // Read into memory
    BYTE * pCpuKey = (BYTE*)XPhysicalAlloc( 0x10, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hCPUKey, pCpuKey, 0x10, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hCPUKey);
 
    // Copy stuff from HV
    *(QWORD*)(response + 0x28) = *(QWORD*)pHV;
    *(QWORD*)(response + 0x30) = *(QWORD*)(pHV + 0x10);
    *(DWORD*)(response + 0x38) = *(DWORD*)(pHV + 0x30);
    *(DWORD*)(response + 0x3C) = *(DWORD*)(pHV + 0x74);
 
    *(QWORD*)(response + 0x40) = 0x0000000200000000LL;
    *(QWORD*)(response + 0x48) = 0x0000010000000000LL;
 
    // Initialise SHA1
    XECRYPT_SHA_STATE sha;
    XeCryptShaInit(&sha);
 
    // SHA1 - HV salt
    XeCryptShaUpdate( &sha, HVSalt, 0x10 );
 
    // SHA1 - HV 0x34 -> 0x74
    XeCryptShaUpdate( &sha, pHV + 0x34, 0x40 );
 
    // SHA1 - HV 0x78 -> 0x10000
    XeCryptShaUpdate( &sha, pHV + 0x78, 0xFF88 );
 
    // SHA1 - HV 0x100C0 -> 0x100F0
    XeCryptShaUpdate( &sha, pHV + 0x100C0, 0x30 );
 
    // SHA1 - HV 0x100F0 -> 0x10100
    XeCryptShaUpdate( &sha, pHV + 0x100F0, 0x10 );
 
    // SHA1 - HV 0x10350 -> 0x16060
    XeCryptShaUpdate( &sha, pHV + 0x10350, 0x5D10 );
 
    // SHA1 - HV 0x16C40 -> 0x20000
    XeCryptShaUpdate( &sha, pHV + 0x16C40, 0x93C0 );
 
    // SHA1 - HV 0x20000 -> 0x2FFFC
    XeCryptShaUpdate( &sha, pHV + 0x20000, 0xFFFC );
 
    // SHA1 - HV 0x30000 -> 0x3FFFC
    XeCryptShaUpdate( &sha, pHV + 0x30000, 0xFFFC );
 
    // Copy hash to response + 0x50
    XeCryptShaFinal( &sha, response + 0x50, 0x14 );
 
    // Hash CPU key to repsonse + 0x64
    XeCryptSha( pCpuKey, 0x10, 0, 0, 0, 0, response + 0x64, 0x14 );
 
    // Copy more stuff from HV
    memcpy( response + 0xA0, pHV + 0x10040, 0x80 );
 
    XPhysicalFree(pHV);
    XPhysicalFree(pCpuKey);
 
    return 0;
}

and
HV 0x04 -> 0x08 - this is written to in CD after CF verification but just before loading
AND just before jumping to reset vector in HV

HV 0x14 -> 0x18 - this is also written to in CD
^ I think this is valid, jtag val stored in CF

HV 0x74 -> 0x78 - written to during HvxKeysInitialize

HV 0x10000 -> 0x1032E - partly hashed (0x100C0 -> 0x10100), looks like more hashes:

0x100C0 is an SHA1 of the below (loaded as QWORDS except 0x2, hashed as QWORDS):
0x80000200 00033100, 0x80000200 00030000, 0x80000200 00060700, 0x80000200 00060840,
0x80000200 00061060, 0x80000200 00050000, 0x80000200 00050008, 0x80000200 00050070,
0x00000000 00000002

0x100D0 is an SHA1 of the below (loaded as DWORDS except 0x2, hashed as QWORDS):
0x80000200 D0000018, 0x80000200 D0000050, 0x80000200 D0000054, 0x80000200 D0000010,
0x80000200 D0108010, 0x80000200 D0108014, 0x80000200 D0108068, 0x80000200 D0110010,
0x80000200 D0110014, 0x80000200 D0110068, 0x80000200 D0138010, 0x80000200 D0138068,
0x80000200 D0148010, 0x80000200 D0148068, 0x80000200 D0148010, 0x80000200 D0148068,
0x80000200 D0100010, 0x80000200 D0100068, 0x80000200 D0140010, 0x80000200 D0140014,
0x80000200 D0140068, 0x80000200 D0150010, 0x80000200 D0150068, 0x80000200 D0010010,
0x80000200 D0121040, 0x80000200 D0129040, 0x80000200 D0121044, 0x80000200 D0129044,
0x80000200 D0108060, 0x80000200 D0110060, 0x80000200 D0108080, 0x80000200 D0110080,
0x00000000 00000002

0x100E0 is an SHA1 of the below (hashed as QWORDS):
XeCryptShaUpdate( &sha, HRMOR ( 0x10000000000 ), 0x8 ); // definately valid
XeCryptShaUpdate( &sha, LPCR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, MSR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, HID1 ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, 0x0000000000003F4B, 0x8 ); // definately valid

0x100F0 is an SHA1 of the below (from sub_1C78):
0x80000200 00010002, 0x3FE bytes
0x80000200 00010412, 0x16A bytes
0x80000200 000105B2, 0x24E bytes
0x80000200 00010800, 0x400 bytes
0x80000200 00010C00, 0x400 bytes
^ That is the CB, which is handled in 1BL. Maybe more so later on, but definately 1BL.
IN FACT, when 1BL is finished with that memory, it nulls most of it, so maybe it's used elsewhere...

HV 0x10040 -> 0x100C0 - needs checking, gets copied to buffer, seems to change each time

// everything below looks fine, the data the hmac hashes hash is the same as retail....
HV 0x10EA8 -> 0x10EC7 - gets hashed:

0x10EA8 -> 0x10EB7 - hmacsha1 hash of 0x10CE8, length 0x10 using the key at 0x18
0x10EB8 -> 0x10EC7 - hmacsha1 hash of 0x10CD8, length 0x10 using the key at 0x18

HV 0x54 -> 0x64 - hmacsha1 hash of 0x10BA8, length 0x10 using the key at 0x18

Credit to XOR on 7S for all this.
It shouldn't be that difficult to reverse the changes made by XeBuild

It's obvious you know nothing about getting online. Just reversing the changes Xebuild makes won't make it pass, and you most likely dumped that earlier HV with Dwacks tool. It stores a payload on Hv that you have to get rid of aswell. You need a Live state Retail HV. Look through the challenge data and see where the responses are coming from then go look into it and see how you can correct it.


you do realise no-one on here is going to understand any of that.... i think some of them don't even know the extention to use or how to boot it :trollin:
#10. Posted:
-Peacee
  • Prospect
Status: Offline
Joined: Feb 01, 201014Year Member
Posts: 667
Reputation Power: 28
Status: Offline
Joined: Feb 01, 201014Year Member
Posts: 667
Reputation Power: 28
cpp_modder wrote
-Peacee wrote
XeMario wrote
-Peacee wrote If someone had a Retail HV There would be a online method. No ones going to give it to you. This will give you a push in the right direction.
int DoChallenge(BYTE * response, BYTE * HVSalt)
{
    // Open retail hv
    HANDLE hHV = CreateFile("Hdd:\\HV_16203.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hHV == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find retail HV!\n" );
        return -1;
    }
    // Read into memory
    DWORD noBytesRead;
    BYTE * pHV = (BYTE*)XPhysicalAlloc( 0x40000, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hHV, pHV, 0x40000, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hHV);
 
    // Open cpu key of current kv
    HANDLE hCPUKey = CreateFile("Hdd:\\CPU_KEY.bin", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hCPUKey == INVALID_HANDLE_VALUE)
    {
        DbgPrint( "Couldn't find CPU_KEY.bin!\n" );
        return -1;
    }
 
    // Read into memory
    BYTE * pCpuKey = (BYTE*)XPhysicalAlloc( 0x10, MAXULONG_PTR, NULL, PAGE_READWRITE );
    ReadFile( hCPUKey, pCpuKey, 0x10, &noBytesRead, NULL );
 
    // Close
    CloseHandle(hCPUKey);
 
    // Copy stuff from HV
    *(QWORD*)(response + 0x28) = *(QWORD*)pHV;
    *(QWORD*)(response + 0x30) = *(QWORD*)(pHV + 0x10);
    *(DWORD*)(response + 0x38) = *(DWORD*)(pHV + 0x30);
    *(DWORD*)(response + 0x3C) = *(DWORD*)(pHV + 0x74);
 
    *(QWORD*)(response + 0x40) = 0x0000000200000000LL;
    *(QWORD*)(response + 0x48) = 0x0000010000000000LL;
 
    // Initialise SHA1
    XECRYPT_SHA_STATE sha;
    XeCryptShaInit(&sha);
 
    // SHA1 - HV salt
    XeCryptShaUpdate( &sha, HVSalt, 0x10 );
 
    // SHA1 - HV 0x34 -> 0x74
    XeCryptShaUpdate( &sha, pHV + 0x34, 0x40 );
 
    // SHA1 - HV 0x78 -> 0x10000
    XeCryptShaUpdate( &sha, pHV + 0x78, 0xFF88 );
 
    // SHA1 - HV 0x100C0 -> 0x100F0
    XeCryptShaUpdate( &sha, pHV + 0x100C0, 0x30 );
 
    // SHA1 - HV 0x100F0 -> 0x10100
    XeCryptShaUpdate( &sha, pHV + 0x100F0, 0x10 );
 
    // SHA1 - HV 0x10350 -> 0x16060
    XeCryptShaUpdate( &sha, pHV + 0x10350, 0x5D10 );
 
    // SHA1 - HV 0x16C40 -> 0x20000
    XeCryptShaUpdate( &sha, pHV + 0x16C40, 0x93C0 );
 
    // SHA1 - HV 0x20000 -> 0x2FFFC
    XeCryptShaUpdate( &sha, pHV + 0x20000, 0xFFFC );
 
    // SHA1 - HV 0x30000 -> 0x3FFFC
    XeCryptShaUpdate( &sha, pHV + 0x30000, 0xFFFC );
 
    // Copy hash to response + 0x50
    XeCryptShaFinal( &sha, response + 0x50, 0x14 );
 
    // Hash CPU key to repsonse + 0x64
    XeCryptSha( pCpuKey, 0x10, 0, 0, 0, 0, response + 0x64, 0x14 );
 
    // Copy more stuff from HV
    memcpy( response + 0xA0, pHV + 0x10040, 0x80 );
 
    XPhysicalFree(pHV);
    XPhysicalFree(pCpuKey);
 
    return 0;
}

and
HV 0x04 -> 0x08 - this is written to in CD after CF verification but just before loading
AND just before jumping to reset vector in HV

HV 0x14 -> 0x18 - this is also written to in CD
^ I think this is valid, jtag val stored in CF

HV 0x74 -> 0x78 - written to during HvxKeysInitialize

HV 0x10000 -> 0x1032E - partly hashed (0x100C0 -> 0x10100), looks like more hashes:

0x100C0 is an SHA1 of the below (loaded as QWORDS except 0x2, hashed as QWORDS):
0x80000200 00033100, 0x80000200 00030000, 0x80000200 00060700, 0x80000200 00060840,
0x80000200 00061060, 0x80000200 00050000, 0x80000200 00050008, 0x80000200 00050070,
0x00000000 00000002

0x100D0 is an SHA1 of the below (loaded as DWORDS except 0x2, hashed as QWORDS):
0x80000200 D0000018, 0x80000200 D0000050, 0x80000200 D0000054, 0x80000200 D0000010,
0x80000200 D0108010, 0x80000200 D0108014, 0x80000200 D0108068, 0x80000200 D0110010,
0x80000200 D0110014, 0x80000200 D0110068, 0x80000200 D0138010, 0x80000200 D0138068,
0x80000200 D0148010, 0x80000200 D0148068, 0x80000200 D0148010, 0x80000200 D0148068,
0x80000200 D0100010, 0x80000200 D0100068, 0x80000200 D0140010, 0x80000200 D0140014,
0x80000200 D0140068, 0x80000200 D0150010, 0x80000200 D0150068, 0x80000200 D0010010,
0x80000200 D0121040, 0x80000200 D0129040, 0x80000200 D0121044, 0x80000200 D0129044,
0x80000200 D0108060, 0x80000200 D0110060, 0x80000200 D0108080, 0x80000200 D0110080,
0x00000000 00000002

0x100E0 is an SHA1 of the below (hashed as QWORDS):
XeCryptShaUpdate( &sha, HRMOR ( 0x10000000000 ), 0x8 ); // definately valid
XeCryptShaUpdate( &sha, LPCR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, MSR ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, HID1 ( not sure yet ), 0x8 );
XeCryptShaUpdate( &sha, 0x0000000000003F4B, 0x8 ); // definately valid

0x100F0 is an SHA1 of the below (from sub_1C78):
0x80000200 00010002, 0x3FE bytes
0x80000200 00010412, 0x16A bytes
0x80000200 000105B2, 0x24E bytes
0x80000200 00010800, 0x400 bytes
0x80000200 00010C00, 0x400 bytes
^ That is the CB, which is handled in 1BL. Maybe more so later on, but definately 1BL.
IN FACT, when 1BL is finished with that memory, it nulls most of it, so maybe it's used elsewhere...

HV 0x10040 -> 0x100C0 - needs checking, gets copied to buffer, seems to change each time

// everything below looks fine, the data the hmac hashes hash is the same as retail....
HV 0x10EA8 -> 0x10EC7 - gets hashed:

0x10EA8 -> 0x10EB7 - hmacsha1 hash of 0x10CE8, length 0x10 using the key at 0x18
0x10EB8 -> 0x10EC7 - hmacsha1 hash of 0x10CD8, length 0x10 using the key at 0x18

HV 0x54 -> 0x64 - hmacsha1 hash of 0x10BA8, length 0x10 using the key at 0x18

Credit to XOR on 7S for all this.
It shouldn't be that difficult to reverse the changes made by XeBuild

It's obvious you know nothing about getting online. Just reversing the changes Xebuild makes won't make it pass, and you most likely dumped that earlier HV with Dwacks tool. It stores a payload on Hv that you have to get rid of aswell. You need a Live state Retail HV. Look through the challenge data and see where the responses are coming from then go look into it and see how you can correct it.


you do realise no-one on here is going to understand any of that.... i think some of them don't even know the extention to use or how to boot it :trollin:

I know D: I bet half these people dot even know how to look at the HV lul.
Jump to:
You are viewing our Forum Archives. To view or take place in current topics click here.