Please read my whole post before commenting.
Quote:
|
how a "DEC reg8/reg16/reg32" instruction can cause any exception
|
where I said the word "exception"?
Did you not notice that execution of the same decrement instruction with the same parameter (one after one - without any "middle" instructions) but different register values modifies flags in different way? Did you not notice that Hardlock must use a driver to check the presence of hardware key?
What is the problem to control
ANY instruction which can behave differently (e.g. flags combination)? Executing the opcode at 00x403EE7, assuming it uses the second process/thread or driver, can be easily controlled (different flag sets depending on the value). That's why I suggested to check the presence of hardlock driver and its communication. Hardlock envelope can be easily removed but that doesn't mean the software don't use own low level communication (after Hardlock layer). Also, if crash occurs at 00x403EE7 then it's obvious that we have three options:
- 00x403EE7 execution (flags) controlled by a driver
- 00x403EE7 execution (flags) controlled by a thread
- 00x403EE7 execution (flags) controlled by a process
Of course I am assuming a proper combination of flags (except
carry). That's clear, especially when you look at 00x403ECE - 00x403ED6. This range contains ExitThread API, which smells like being connected with the protection.
Similar not known tricks are used in the best protections (e.g. LogoCAD Triga, with own hardware key and own software protection, has few very interesting code execution approaches). I am surprised it could exist in Hardlock but who said it cannot?
I believe a cracker should not ask himself:
"what it cannot be?" but
"what it can be?".
Someone has other ideas for this crash instead of telling
what it cannot be? I will get acquainted with a great interest.
Bestr regards,
dyn!o