I am using OllyDbg 1.10c to debug some Basic .NET code but everytime it analyzes the code it actually executes and runs the code in question.

I can pause the program and check the stacks, etc. but this is not good if I need to debug early on in the code.

Any ideas how this can be worked around until Olly is updated to recognize .NET code better?

You should use Windbg with the SOS (Son of strike) extension, in the SDK .net. Ollydbg can only show 'jitterised' instructions in a native format and the 'real cpu' stack.

As the .Net code is compiled on the fly, the SOS extension can help you to watch the .net stack and other CLI stuff.

Take a look at the SDK .net tools (ildasm, DbgClr,....), there are more adapted tools than ollydbg for this kind of thing.

I have never really been a WinDBG fan but sometimes it is necessary so thanks for this info.

For those among us who may be interested I found this interesting page concerning WinDBG and SOS:

_http://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/default.aspx

Does anyone know if Olly will support .NET code in the future?

I found it interesting that programs compiled in 'weird' languages such as Visual Basic's PCode format and .NET are hard to attack, obviously because disassemblers/debuggers etc can only go to work on 'normal' x86 code.

Armed with this in mind, I created an 'interpreted assembly language' ... basically you just create an assembly language 'script', which can be as simple as something like this:
mov eax, 1
ret
But it doesnt compile to normal x86 opcodes. Instead, it compiles to my own custom format, which can only be read by my own interpreter. So while crackers could use their debuggers to disassemble the part of the program that interprets and executes the assembly script (which is obviously normal x86 code), it'd be quite difficult for them to analyse the actual interpreted assembly script which is the part they'd need to patch - not the interpreter.

I'd appreciate both positive and negative constructive feedback on this idea, cheers.

Well, .net code is now using obsfucators, they kinda "emulate" the code at runtime

you can just decompile the code (like salamander decompiler) and you'll see what you need

the only visible part of the code when you disasm it, are the variables (other than strings)