Does anyone have it and/or want to share?
It's open source anyways.
It seems that with version 1.3.3 (patched checkrevision for ver-IX86-##.mpq) someone must've messed up the diablo 2 cdkey decoder, because over half those cdkeys are now "invalid" when kd_quick is used. Also I'd like to implement lockdown checkrevision in BNCSUtil. And I hear the entire project has been abandoned. Someone needs to do this, so why not me? :|
post your aim and ill send it to you, i have 1.3.1
my aim is BreW 1337
Quote from: brew on July 30, 2007, 11:12 AM
Someone needs to do this, so why not me? :|
Because the end result would be something scary.
Quote from: betawarz on July 30, 2007, 01:04 PM
Quote from: brew on July 30, 2007, 11:12 AM
Someone needs to do this, so why not me? :|
Because the end result would be something scary.
Is that so.
You should be talking--
int patch_dword(unsigned long AddressToPatch, unsigned long Value) {
unsigned long OldProtect = 0;
if(!VirtualProtect((LPVOID)AddressToPatch, 4, PAGE_EXECUTE_READWRITE, &OldProtect))
return 1;
*(unsigned long*)AddressToPatch = Value;
if(!VirtualProtect((LPVOID)AddressToPatch, 4, OldProtect, &OldProtect))
return 1;
return 0;
}
int patch_word(unsigned long AddressToPatch, WORD Value) {
unsigned long OldProtect = 0;
if(!VirtualProtect((LPVOID)AddressToPatch, 4, PAGE_EXECUTE_READWRITE, &OldProtect))
return 1;
*(WORD*)AddressToPatch = Value;
if(!VirtualProtect((LPVOID)AddressToPatch, 4, OldProtect, &OldProtect))
return 1;
return 0;
}
*ahem*
Maybe I'm missing something (or am just dumb), but warz's code looks 100% OK to me.
Why's it scary?
Quote from: MyndFyre[vL] on August 01, 2007, 08:44 PM
Maybe I'm missing something (or am just dumb), but warz's code looks 100% OK to me.
Why's it scary?
Last time I checked a WORD is 2 bytes, but maybe i'm wrong.... hrm....
Quote from: brew on August 01, 2007, 09:05 PM
Quote from: MyndFyre[vL] on August 01, 2007, 08:44 PM
Maybe I'm missing something (or am just dumb), but warz's code looks 100% OK to me.
Why's it scary?
Last time I checked a WORD is 2 bytes, but maybe i'm wrong.... hrm....
First, I don't know what that makes his code "scary".
Second, a word isn't necessarily 2 bytes, it depends on the system/OS.
Quote from: brew on August 01, 2007, 09:05 PM
Quote from: MyndFyre[vL] on August 01, 2007, 08:44 PM
Maybe I'm missing something (or am just dumb), but warz's code looks 100% OK to me.
Why's it scary?
Last time I checked a WORD is 2 bytes, but maybe i'm wrong.... hrm....
A WORD is 2 bytes. On a 16 bit system. A WORD on any OS running on even really old chips is 4 bytes. WORDs on the new 64bit systems is 8 bytes.
Quote from: rabbit on August 01, 2007, 10:22 PM
Quote from: brew on August 01, 2007, 09:05 PM
Quote from: MyndFyre[vL] on August 01, 2007, 08:44 PM
Maybe I'm missing something (or am just dumb), but warz's code looks 100% OK to me.
Why's it scary?
Last time I checked a WORD is 2 bytes, but maybe i'm wrong.... hrm....
A WORD is 2 bytes. On a 16 bit system. A WORD on any OS running on even really old chips is 4 bytes. WORDs on the new 64bit systems is 8 bytes.
gee, i thought you would have figured out by now. He's unprotecting and patching two more bytes of his data then he wants to... not sure if that has any effect though
First, some clarity. WORD is a Microsoft typedef that dates from the Win16 days. It should have been changed to a 32 bit type when Win32 came along, but Microsoft did not do so. Presumably, this was to accommodate large quantities of code which incorrectly assumed WORD would always be 16 bits. This differs from what rabbit said. Rabbit seems to have taken the view that WORD refers to the machine word, not the Windows typedef. When not capitalized, word refers to a machine word, which is the machine's native operand size. This is 32 bits on an IA32 system, and rises to 64 bits on Itanium.
brew: yes, he changes the permissions on two bytes too many. So what? He only writes to the two bytes he has actual data for. He then fixes the permissions on all four bytes. The only case where you would even notice this is if the patch is positioned such that using a 4 byte range straddles a page boundary, but using a 2 byte range would not. In such a case, an extra page will be briefly turned writable.
The code could be fixed by rewriting it as so:
template <typename T>
static
int patch(UINT_PTR AddressToPatch, T Value) {
unsigned long OldProtect = 0;
if(!VirtualProtect((LPVOID)AddressToPatch, sizeof(Value), PAGE_EXECUTE_READWRITE, &OldProtect))
return 1;
*(T *)AddressToPatch = Value;
if(!VirtualProtect((LPVOID)AddressToPatch, sizeof(Value), OldProtect, &OldProtect))
return 1;
return 0;
}
int patch_dword(UINT_PTR AddressToPatch, UINT32 Value) { return patch(AddressToPatch, Value); }
int patch_word(UINT_PTR AddressToPatch, UINT16 Value) { return patch(AddressToPatch, Value); }