Noob Question on Debugging DLL

[psgama]

Kind of a Noob question, as I haven't run into this before.

I have a dotNet application that loads some licensing commands through a regular VB6 DLL that was not written in DotNet. How can I break on calls to this DLL to see what manipulation is being performed on the data being passed through to it with ollydbg?

[tonyweb]

Maybe I miss something but, usually you just have to load the .NET application in Olly and "wait" for the DLL to be loaded.

Once it's loaded (you could use "load library" event notification), just put breakpoints in VB6 DLL code section.

Regards,
Tony

[psgama]

OK, thank you. Maybe I'm just doing something wrong. My application seems to keep crashing when I load it in ollydbg 2.0, it is a dot net application, and seems to hang just before loading the framework application. I'll remove all my plugins and try starting fresh. Maybe one of them is causing my issue.

[Syoma]

Use IDA Pro, load .dll then put your program at start program in Process options.
Start and enjoy.

[TechLord]

Originally Posted by psgama

...
... How can I break on calls to this DLL to see what manipulation is being performed on the data being passed through to it with ollydbg?

1. "Search for all intermodular calls" in Olly would help (Under Search For, after right-clicking in th eolly main window) . There, look for all calls in to the dll that you want. And put BP as necessary.

OR

2. Go to Debug Events in Olly Debugging Options and configure it to "Break on new module" .
It will break whenever a dll is loaded, in this case....

3. For .Net it is better to use Reflector, though you stated that the dll is in VB6.
Have you tried using VB Decompiler to decompile the VB6 dll ?

These are all good starting points.

[b30wulf]

https://github.com/0xd4d/dnSpy/releases
Give ti a try, it will surprise you...

[TechLord]

Thank you Beowulf for the suggestion..

I have intentionally not suggested dnSpy as it sometimes crashes when VB6 executables are involved.
On the other hand, Reflector is rather "mature" in the sense that it has been around for quite a while...

The approach I would suggest here would be to DECOMIPLE the VB6 dll with the VB Decompiler (available on this forum), identify the important areas of interest in the decompiled code, and then note down the RVAs of those portions, so that you can again identify them in the debugger, at runtime.

Place BP on those VAs and then check them out.

Another approach would be to change the "characteristics" of the dll to that of an EXE file and then load and debug it in olly.

Do remember that VB6 uses a"runtime" and hence DIRECTLY debugging it is rather messy, as you would getting a lot of "VM-like code of the runtime...

So, its BEST to DECOMPILE it first using the VB Decompiler before embarking on your quest ...

Good Luck

[Naides]

[QUOTE=. . . in ollydbg 2.0, it is a dot net application . . .[/QUOTE]

For starters use Olly 1.10. Olly 2.0 is OK, but is (and likely will be forever) alpha.

I have used Olly 1.1 in similar situations, and seems to go without problem.

[psgama]

Thank you for all the responses! Olly 1.1 is what I commonly use, but I was under the impression it didn't support debugging of .net applications. I apparently was wrong. Breaking on loading of dlls got me into the code section I needed to be in! And the program doesn't hang like it was in only 2.0. And thank you for all the advice and recommendations. making progress now.

[psgama]

Once again, thank you all for your help. I can't believe it was as easy as just loading in Ollydbg and breaking on DLL load. Doh! Anyway, I was able to get the information I needed from the DLL to enable the features I was looking for! Thank you all for your advice.

[0xd4d]

Originally Posted by TechLord

I have intentionally not suggested dnSpy as it sometimes crashes when VB6 executables are involved.

Do you have a file that causes the crash? dnSpy opens .NET files, and VB6 isn't a .NET language.

[TechLord]

Originally Posted by 0xd4d

Do you have a file that causes the crash? dnSpy opens .NET files, and VB6 isn't a .NET language.

Sorry man, the VB6 was a typo. Obviously I know it i snot .Net and hence had suggested a decompiler instead.

dnSpy is very good except that when "mixed" projects, involving managed and unmanaged code are involved, it sometimes crashes or hangs.

Will try to send specific code segments later. Even in those cases, the crashes are caused due to the obfuscators used or the anti-debug "tricks" rather than a "problem" with dnSpy itself.

GREAT JOB man , with the dnSpy prog !

[Jasi2169]

Dnspy cant debug all .NET programs for example some obfuscated with ezobfuscator when u try to start debugging it immediatley popup saying program crash while debugging

So as techlord said it is for sure anti-debug techniques by obfuscators not dnspy problem

@psgama
If it is .net then i always use net reflector and de4dot for unpack it first ,oftenly i dont use olly on dot net apps my opinion
Once i get the code then reflexil to save patch .net .exe or .dll whatever
Regards
Jasi2169

[Naides]

@Jasi2169:

psgama is in the not all that unusual situation in which the main program is .NET, but the .dll, where the action seems to be, is NOT.

Olly will not trace the .NET code, at least not directly, but once the main program calls the interesting .dll functions, you can place BP and trace typical assembly code in olly, and you are in business. . .

[Jasi2169]

ooes Naides i guess i miss understood anyway i got you what you trynna say
he can check the call after pausing or use Button "E" in olly shows all