Program crash

[dyn!o]

Please read my whole post before commenting.

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

Well, actually you said that "DEC ECX [...] can't crash or cause a special operation [...] since it can". So you told that DEC ECX can crash. Since I know nobody who would use the word "crash" for flag modification (and it wouldn't make any sence), a crash always causes an exception. So there is no need for you to use the word "exception", since you already said it.

It's nice that you try to tell me that DEC instructions change the flags and that Hardlock uses a driver, but that's common knowledge. It's also nice to talk about the "what can" and the "what cannot" in cracking. But it's pointless since we all know. So lets stop philosophy.

So tell me, how can a driver/thread/process react on the flags change at 00403EE7 without using any "middle" instructions (like you call them)? The only way would be exceptions (single-stepping, breakpoint, page fault, ...). And this way is using "middle" instructions.

BTW. what do you want to tell me with 00403ECE? Are you unaware that this kind of instructions (effective "NOPs") are used to align the next procedure to the next address boundary in memory?

[dyn!o]

DEC ECX alone can't crash anything - that is obvious after the first day of assembler learning. If you still talk about some exception (why you are using this word?) then I have to leave you with this idea because there is no way to raise an exception by executing DEC opcode alone.

After "exception" theory (virtual?) you come with another idea: a crash and immediately inform us: "a crash always causes an exception". No comments. I won't "analyze" all your words to save forum disk space.

Are you unaware that this kind of instructions (effective "NOPs") are used to align the next procedure to the next address boundary in memory?

Oh no... again... Where I am talking about NOPs? I wrote: "This range contains ExitThread API, which smells like being connected with the protection." so where do you see any NOPs point? I pointed ExitThread API and you talk about some fancy NOPs vision, why?

It's nice that you try to tell me that DEC instructions change the flags and that Hardlock uses a driver, but that's common knowledge.

Strange. You tell such a sentence and next ask "...how is that possible?". Have you heard about synchronizing role of drivers? (not Hardlock)

tell me, how can a driver/thread/process react on the flags change at 00403EE7 without using any "middle" instructions (like you call them)? The only way would be exceptions (single-stepping, breakpoint, page fault, ...). And this way is using "middle" instructions.

Read the fragment below so I hope you will get it. By "middle" instructions I don't mean the system (like threads/interrupts, etc.) but code range. I mean this order:

flow = (DEC ECX [n]...DEC ECX [n-1])

this range will modify the flags but neverthless of the fact that it does not contains any instructions between DEC ECX it can be fully controlled (e.g. by an interpreter). Since Mahmut didn't trace all the next code, after ntdll.dll, that theory is the only possible which comes to my head. Why don't you propose your one?

Back to the subject.
Have you heard about metamorph engines based on code interpreters? I suppose no (then join IEEE) because you wouldn't ask all over the same question. Imagine a fragment of virus code which is executed as the engine to generate new code/data. Now imagine an anti-virus scanner with heuristic scanning ability. It can deal with polymorph layers, sometimes even partly with metamorph but how it will deal with the code which executes itself and logs all the affects (not results) of execution flow? All instructions are the same, so for AV engine it is not possible to 100% detect such a mutation (because it should have the ability of foreign code execution - so far no scanner features it). DEC ECX example is a very good one and please don't ask me why or just PM me to skip making this thread a tragedy.

What is possible when we talk about 00x403EE7 is controlling the flow execution of this address (e.g. like byte code interpreters do). It can be performed on different ways (ring0/ring3). If you want to read about it then I suggest VM/byte code interpreters books or PM me.

Regards.

I will make it short since this thread is already a tragedy (sorry MAHMUT).

• You stated that "DEC ECX" can crash something. This is why I asked you to explain that.
• "MOV EAX, EAX" is an effective "NOP". It does nothing expect modifying EIP. No procedure starts at 00403ECE, it starts at 00403ED0.
• You started with your "middle" instructions. When you put two "DEC ECX" right after each other but put a breakpoint on execution on the second one, "middle" instructions will get executed.
• We have no interpreter here. When I use an interpreter which formats your hard disc when it encounters 0x49 ("DEC ECX") than of course this "bytecode" can do anything. But it is no longer a "DEC ECX" in this context.
  

[dyn!o]

I am glad we switched from "you said.. I said...".

"You stated that "DEC ECX" can crash something. This is why I asked you to explain that."
I hope I did it.

""MOV EAX, EAX" is an effective "NOP". It does nothing expect modifying EIP. No procedure starts at 00403ECE, it starts at 00403ED0."
Right, but I didn't say it does something and didn't say it starts here. Opcodes like LEA EAX, EAX (TeLock trick) can crash some ring3 debuggers and that is why I said it smells like be related to protection and pointed ExitThread API (I am suggesting that this place (API call) may be connected with some protection routine).

"You started with your "middle" instructions. When you put two "DEC ECX" right after each other but put a breakpoint on execution on the second one, "middle" instructions will get executed."
Right again but we missed the topic. I was trying to show that a flow of "DEC ECX" opcode will modify flags. You may know that but not everyone.

"We have no interpreter here. When I use an interpreter which formats your hard disc when it encounters 0x49 ("DEC ECX") than of course this "bytecode" can do anything. But it is no longer a "DEC ECX" in this context."
And it's first time we are talking about the same theory (I hope). I didn't mean strict byte code interpreter (or PCODE or VMs) but the idea of logging or controlling the affects, not results.

This problem (crash) is a really interesting one and since we don't have this file in our hand it will require a serious OS knowledge from Mahmut to reveal the reason of crash on his own.

Regards.

[LaDidi]

Keep cool !....
When I said a DEC ECX couldn't crash, I only wanted to be sure that's it's the true address and not the next one.
Maybe we all can wait for the dump or more info on this proggy.
Sure, we all want to continue to progress.

Regards

Please, not sure it will be interesting for everybody to see : "I can impress you cause I know more than you" ...

I had some trobles at work.
I must first read carefully all the post, and will answer to all of your posts.
Sorry again, and thanks for helping me
MAHMUT