I loaded my target in Reflector, but it looks like the author used some kind of obfuscation, since there are twelve functions named __abstract distinguished only by the argument types. Reflector also pops up an error box trying to disassemble some of the methods.

Hoping to debug it and just watch what was going on, I tried following zacdac's suggestion here:
http://woodmann.com/forum/showthread.php?t=4459
but ildasm crashes immediately on opening the target, so I haven't been able to get a .IL file.

IDA can load the file, but I've got no experience reading IL bytecode, so I have no idea if it has any trouble with it.

Can IDA create a *.IL file from the exe? If so, how? Can Reflector?

OK, I got the FileDisassembler plugin for Reflector and it dumped the exe to .IL files with no errors. Now my trouble is that the .NET v1.1 SDK doesn't have ilasm! Why would it ship with one but not the other? GRRR.

Has anyone used Ida to debug a .NET app?

I ran the target using Ida, but it crashed after three instructions. I got ilasm.exe off of someone's website, but apparently the .il code generated by FileDebugger was buggy, because ilasm crapped out with

Has anyone got tips for debugging obfuscated VM code?

I've had very good luck with IDA Decompiling .net executables - usually get very readable code - although the decompilation is somewhat buggy - seems to jump around and occaisionally shows the same hex address for different code segments - are you opening it using the .net tab when you invoke file - new? - the problems I've had stem mostly from calls to remote msil's , apparently when a "real programmer" is at work, a good deal of the code is located in a general purpose folder elswhere containing a ton of msil's.

SiGiNT

Mike,

2 things. First, make sure that the version of ILASM.EXE is the same as the version of ILDASM.EXE. You can generally tell by looking at the config file for both with the same first name.

Second, your dll or exe may not have 100% managed code, and possibly due to obfuscation the results can be different. You may try running PEVerify.exe

example:

PEVerify "C:\Program Files\Some directory\Bin\some.dll" /md /il

to see if the code is managed, and if you reassemble the module, the results of running peverify should be identical, although there could be a very slight difference in the size of the assembly.

cheers!

PEVerify fails with