I apologize in advance if this topic has been addressed before. I DID search back in this board as well as with google before posting the question, and, perhaps due to poor choice of search keys, I came empty handed.

I am trying to dissasemble some exe files from an app called Radmin.
When I try to load it into W32dasm 8.93, the Dassmblr crashes. It crashes immediately, before it has even tried to preprocess or process the jumps. I vaguely recall either a tut or a posting in this board describing an anti Ddasm trick based on the size or characteristics of the segments in the PE header.
May anybody be so kind as to point me to the right posting or document or give me some light about this anti Wdasm trick?

Note: IDA does disassemble the proggie without protest, but I am in the lower part of the learning curve using that tool.

Thanks in advance

There are (sadly) quite a lot of 'tricks' to make W32Dasm crash.

The section characterisics one is actually rather simple. I don't recall the exact meaning of each bit flag atm, but changing the section characteristics for the code section (the one your OEP is located in) to something like E0000020 or E0000060 should help you to overcome this one...(but I don't think this trick is used in your app either, as it usually doesn't make W32Dasm crash, instead of making it refuse to disasm anything at all).

Here are some other quite common ones (taken from Bengaly):

1. Infinite Jumps (EBFE) <= make w32dasm to crash
2. Big Resource size <= make W32dasm to stop respond
3. Inline Calls: Call [Call xxx] makes W32dasm to loose data
4. Unreachable Jumps.


As for IDA, I'm suffering a lack of experience on it, too.
But as you might have noticed, IDA is the way to go for pros...

If you check out the AntiCrack sticky from Kayaker in the Newbie Forum you will find a section in the articles on anti-disassembly and anti-debugging with answers to your questions.

For example, here's a post from ?ferret:

most use a couple of jumps at the beginning that are never actually executed in the proggy...a loop solely intended to f**k up w32dasm.

400000 JMP 401000
401000 JMP 400000

or somehin like that...

this keeps the disassembler busy processing jump references til it run out of RAM and locks.....

pretty smart thinkin, but ez to defeat after u figure it out.....if u run across a proggy that does this, open it up in a hexeditor and nop those jumps (they aren't executed anyway)

?ferret

There are others. Try also "anti-disassembler" in google. I got 27 references in several languages.

Regards.

Hi naides,

Try a clean w32dasm.which is not patched.just my tw0 c3nts

Thanks to your sugestions I made real progress with this app.

As I said before Wdasm crashes quite early in the process, so infinite jump loops, unreachable jumps or calls did not seem to be the problem. The bulk of the code is not packed.
The size of the segments was not unreasonable.
The key to the trick appears to be unconventional names in the .rsc section, which ckrashed Wdasm when it tried to locate them. Simply deleting the .rsc section allows Wdasm to work.

Kayaker had described a similar problem in a posting around sept 2000, which is available in the www.anticrack.de site

Actually, the protection is quite interesting, I needed a solid dead listing to be able to follow the license key validation. Doing it by Sice tracing is a sure way to a nut house.