Program crash

i hope this time i'll solve my problem (with a little help from my friends)...

Well, I am quite desperate. I found many instructions how to
remove hardlock dongle with dongle (run program, dump to disk, resolve 4 unresolved, fix the dump,
and change the entry point). Well, i did everything like described but
the program crashes after a splashscreen. The code looks like this:

00403ECB C2 0C00 RETN 0C
00403ECE 8BC0 MOV EAX,EAX
00403ED0 50 PUSH EAX
00403ED1 E8 0AD4FFFF CALL <JMP.&kernel32.ExitThread>
00403ED6 C3 RETN
00403ED7 90 NOP
00403ED8 8B10 MOV EDX,DWORD PTR DS:[EAX]
00403EDA 85D2 TEST EDX,EDX
00403EDC 74 1C JE SHORT batch_ci.00403EFA
00403EDE C700 00000000 MOV DWORD PTR DS:[EAX],0
00403EE4 8B4A F8 MOV ECX,DWORD PTR DS:[EDX-8]
00403EE7 49 DEC ECX --------HERE IT CRASHES SUDDENLY AND GOES TO NTDLl
00403EE8 7C 10 JL SHORT batch_ci.00403EFA
00403EEA F0:FF4A F8 LOCK DEC DWORD PTR DS:[EDX-8]
00403EEE 75 0A JNZ SHORT batch_ci.00403EFA
00403EF0 50 PUSH EAX
00403EF1 8D42 F8 LEA EAX,DWORD PTR DS:[EDX-8]
00403EF4 E8 A3E8FFFF CALL batch_ci.0040279C
00403EF9 58 POP EAX
00403EFA C3 RETN

Thank you people

[dyn!o]

The only advice which comes to my head is that you should check all the flags (except carry) during the "proper" execution (with dongle) and "cracked" (without dongle). Of course I am assuming you did not miss the crash address (decrement opcode result modifies flags only).

You should notice the difference and, eventually, fix this place.

Good luck,
dyn!o

Please, could you post a link to your application, because it sounds very strange to me that a register's modification could crash an application ?

So I'm interrested in peeking an eye on it.
thanx.

[LaDidi]

a DEC ECX couldn't crash an application !...
Have you check the dump ?
Are you sure your application isn't multi-threaded and there's a watchdog which verify this part of code ?
Regards

[dyn!o]

LaDidi: with all respect my friend... don't say things you ain't sure.

DEC ECX in your opinion can't crash or cause a special operation? How much would you bet on it? I hope not much since it can. It can perform many other wild things. I suggest you to read about viruses with advanced metamorph engines. Anyway, that's not important in *this* case but think again:

it's Hardlock, so it uses hardlock.sys (and maybe haspnt.sys) drivers. You still don't see the possibility of flags (decrement result) controlling?

Mahmut: make sure you completely removed hardlock.sys/haspnt.sys communication (you can run the software and check active drivers, or just remove the drivers).

Regards.

@dyn!o:
According to the Intel and AMD manuals, the DEC instruction can cause several exceptions, but only when working with memory addresses. There are no defined exceptions when working with registers.

Please can you give us an example how a "DEC reg8/reg16/reg32" instruction can cause any exception or do anything else than decrementing (or incrementing when a register underflow occurs) the register? (and please don't come with breakpoints or the trap flag since they are no result of the DEC instruction as such)

[gabri3l]

Does the program actually crash when executing the DEC instruction or after the MOV instruction? it may be that the MOV instruction is trying to access a nonexistent memory address. When you get to the MOV instruction, check the value of EDX-8 and see if that value is a valid memory location. Just a thought, I may be way off.

[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

Hello, here am i finally...

Sorry again for waiting.

Like I promised, I will answer to all of your questions. I am sorry
that you have talked so much about "if DEC ECX" could crash my application.
I dissasembled the dumped file again, and it really crashes at this address.
Olly said at this point access violation when reading 5A4550F0-use shift+ F7 ...

I don't know where to start. I must admit, i didn't
understand all of your posts, cause i am still a newby. I will answer to those who
i understand, and to others later, when i read more about stuff they wrote about.
I start whit who first replied, Dyno.

I followed your advice: I oppened 2 Olly's (1 dumped file, another
original with hardlock). After 1 hour of tracing (F7 or F8) and looking every register
at every code place, and ofcourse also the flags, I didn't knew what's my name. I was
very tired, and my pancakes were overbaken.
Your next advice, was to remove the drivers, what i did and nothing happened.

To Gabri3L:
The program crashes after executing mov. I checked EDX value, 5A455100, and it didn't exist
in the memory!!!
Anyway, I had to clear up my mind. After looking the new bourne's supremacy i had more energy.
LaDidi, i followed your instruction and looked if my application had a watchdog (i hope i
understand it right). I don't understand whats multithreaded, bud i saw some PEID plugin, KRYPTO ANALIZER.
I was stoned when i checked my dump!!! Check the attachment!!
I could not upload the attachment, so here are the cryptos.
BASE 64 table (referenced at 2 places)
BLOWFISH (ref. at one place)
CRC32 (2 places)
List of primes (long), (1 time)
PI fraction (NIMBUS/BLOWFISH) (1 time)
SHA1/RIPEMD-160 (init) (1 time)

I got an idea. I changed one bit in the original (not dumped file) and same happened (closing after a splashscreen, the same like my dumped file!!).

The only crypto i heard of is CRC32. I had an idea. I checked another 3 files of this application (they weren't protected with hardlock envelope, no .protect section). But they had also the CRC32 checksum algorithm.
I changed at many places some bytes, and the application still runs perfectly!!. Conclusion: it's not CRC32 who's crashing my dump.

Because i don't know very much about another type of cryptos, i am asking you to help me. I am looking for infos about these cryptos. Do you know which could crash my dump?
It would be great for some cool links.
Regards, MAHMUT