Hello,
I have 'patched' a handful of trial versions, so far. I thought I would try and improve my skills, so I have a small DOS app that uses a parallel dongle that I thought would be an easy fix. Everytime I attempt to load the exe file in WDasm32, WDasm32 crashes(closes). Any help would be greatly appreciated. Thanks in advance!

Perhaps the app *deliberately* has something funny in it that causes wdasm to crash, as protection. Have you tried another disasm? Search the forum, I seem to recall some posts about this before. Some packers will cause wdasm to behave oddly if you look at the packed exe.

I found UN-PACK 2.3 and it gave me the following info:

--+-- UN-PACK (File Analyzer and Unpacker) v.2.3 freeware (C) 1998-2003 --+--
--+-- Authors: Snow Panther [UG2003] and many others (see unpack-a.com) --+--
* XXX.EXE is DOS executable file (MZ EXE)
* Created 09.03.1999 at 13:58:06. Attribute Archive
* File size 333872 bytes
* Identificator...........: MZ
* Bytes on last page......: $0170 (368)
* All pages in file.......: $022D (557)
* Relocations.............: $170C (5900)
* Paragraphs in header....: $06A0 (1696)
* Minimum memory..........: $0000 (0)
* Maximum memory..........: $FFFF (65535)
* SS:SP...................: $3EE3:$0080
* Checksum................: $0000 (0)
* CS:IP...................: $0000:$0000
* Relocation table adress.: $003E (62)
* Overlay number..........: 0
* Entry point.............: $00006A00 (27136)
* Compiled by Borland C v.?.?
* Executable file extension
* Trust me, I know what I'm doing...


Any help would be greatly appreciated! Thanks in advance!

Whenever one tool crashes, it is always a good strategy to try another one, IDA for example in this case (which is much better anyway)...

Ok, I opened it up in Biew and it didn't crash. I searched in Hexidecimal mode for the error message and it sent me here:


E &l0O
Press any key to continue @ @@r/1 XXAPP security missing - Press any key to retry w/1/ BM.4LG


I then switched to Disassembly View:

000402DB:i42 inc dx
000402DC:i7261 jc file:0004033F =>[3]
000402DE:i636B6D arpl bp,[bp+di+6D]
000402E1:i61 popaw
000402E2:i6E outsb

There's a couple of reasons that come to mind as to why W32DASM would choke on a particular binary. First thing that comes to mind is that it is easily fooled by placing code in "data" sections. Did you check the attributes for all of the sections of the exe? Also I came across this, may or may not be applicable (doubt it but I thought I'd mention it...):

Taken from hxxp://www.woodmann.com/crackz/Tutorials/Protect.htm

Thanks for the tips. I loaded it up in OllyDbg, when I run it, it gets stuck in the bolded area(keeps looping) On line: 5F161D88 in OllyDbg there is an upside down ^, when I copy/pasted, it was gone. I'm really not sure what my next step is. Here's the loop:
5F161D7F B9 5040165F MOV ECX,5F164050

5F161D84 8A01 MOV AL,BYTE PTR DS:[ECX]
5F161D86 A8 04 TEST AL,4
5F161D88 74 04 JE SHORT 5F161D8E
5F161D8A 24 FB AND AL,0FB
5F161D8C 8801 MOV BYTE PTR DS:[ECX],AL
5F161D8E 83C1 0C ADD ECX,0C
5F161D91 81F9 1041165F CMP ECX,5F164110
5F161D97 ^7C EB JL SHORT 5F161D84

5F161D99 C3 RETN

Try changing the JE (h74) to JMP (h76) and the JL to a NOP 90 for both bytes.

SiGiNT

Without giving it too much consideration, that looks more like a decryption loop or a section that modifies the running code on the fly than a "good boy/bad boy" jump, so I don't really see how patching the jump will help the cause. Just my opinion...

At least it will break the loop and allow him to proceed, and if he's very lucky it could be a good boy/ bad boy piece of code - but on that one I tend to agree it's probably not.

SiGiNT

@ ksbrace:

You do know you can automate the tracing of large repetitive code sections with Olly don't you? If not I suggest you read up on that (learning how to use the available functionality in Olly will save you a lot of sanity and wasted effort in the long run) I highly doubt that the code you cited is an infinite loop, it is probably just a loop that executes many, many times, possibly as part of an anti-tracing protection or as mentioned before it might be a decryption loop or part of a self-modifying code routine.

Perhaps you might gain a little bit more clarity by looking at the executable with a more "modern" PE analyzer like PeID. At least then if the program is packed with a well known packer/crypter then you will know what you are dealing with. Then you can take a look at some tutorials and manually unpack the target (if you want to learn something) or maybe just use an unpacking tool (if you just want to get on with things). Alternately you could trace the execution of the program a lot deeper in the debugger of your choice and maybe figure out what is going on for yourself, or with a bit of reading and practice you could probably generate an accurate dead listing of the program with IDA (see http://www.datarescue.com/idabase/unpack_pe/index.htm for a nice little intro to using IDA to disassemble a packed/crypted exe). This might be a more fruitful approach?

@sigint33:

Yes he could break there, but if the code is indeed encrypted and the unpacking routines have not finished executing or this is a section related to self modifying code, he is just looking at goobledygook that will only serve to confuse things further.

Clearing the jump will get him past it, but it will almost certainly bork something. Look at what the code is doing -- it's fetching single bytes of data from DS:[ECX], modifyting them (AND AL,0FB), and then writing them back out. ECX gets bigger by 0C every time, and will break out of the loop when it's >= 5F164110. That value screams that this section is modifying or decrypting code just a bit further down that you're about to execute momentarily. So if you break out before it's done, Bad Things will happen.

Manually tracing through decrypting/self-modifying code is a pain, but it's probably a good idea to do it a few times until you get how that sort of thing works. The first few times it's confusing, but then you realize it's just the same tricks over and over with only a few variations. Then it just gets tedious unless you script it. I'm still learning the ropes, so I haven't gotten around to that myself .

If you've ever read Ender's Game: "Remember, the enemy's gate is DOWN!" . The key is to 1) Use code highlighting that highlites jumps and calls, and 2) when you get to each jump or call, make sure that it's taking you further down the code. If you see a conditional jump that takes you back up, set a breakpoint on the instruction after it, run until it breaks, then remove the breakpoint. If you're being sent back up the code by a CALL or unconditional JMP, you'll just have to go back through the code again. This time watch for any conditional jumps that you didn't take. One of them will send you to another JMP/CALL that breaks you out of loop.

Hey guys,
Thanks for the tips. I was out of town yesterday, but I will give your tips a try and post the results tonight/tomorrow. I dl'd PEid and will give it a try. I'm extremely new to Olly, I have always used W32DASM until this app. Thanks again for your advice!

Excellent advice for both of us - thanks for the description of what the loop might be doing, I didn't consider that it might be accumulating code.

That's why I'm in this topic, to learn!

Thanx,

SiGiNT