Program crash

[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.