You are viewing our Forum Archives. To view or take place in current topics click here.
Retail Hypervisor?
Posted:
Retail Hypervisor?Posted:
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.
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:
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
Status: Offline
Joined: Jun 06, 201310Year Member
Posts: 91
Reputation Power: 3
#3. Posted:
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
Status: Offline
Joined: May 09, 201310Year Member
Posts: 108
Reputation Power: 4
#4. Posted:
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.
and
Credit to XOR on 7S for all this.
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.
- 0useful
- 0not useful
#5. Posted:
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.It shouldn't be that difficult to reverse the changes made by XeBuildint 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.
- 0useful
- 0not useful
#6. Posted:
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.It shouldn't be that difficult to reverse the changes made by XeBuildint 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'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.
- 0useful
- 0not useful
#7. Posted:
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 wroteXeMario 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.It shouldn't be that difficult to reverse the changes made by XeBuildint 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'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.
- 0useful
- 0not useful
#8. Posted:
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.
- 0useful
- 0not useful
#9. Posted:
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 wroteXeMario 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.It shouldn't be that difficult to reverse the changes made by XeBuildint 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'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:
- 0useful
- 0not useful
#10. Posted:
Status: Offline
Joined: Feb 01, 201014Year Member
Posts: 667
Reputation Power: 28
cpp_modder wrote-Peacee wroteXeMario 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.It shouldn't be that difficult to reverse the changes made by XeBuildint 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'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.
- 0useful
- 0not useful
You are viewing our Forum Archives. To view or take place in current topics click here.