It seems like you could use a mashup of Relector and a Debugger to be able to debug any .NET app WITHOUT having the source code at all. Is this possible? Has anyone seen this before?
views:
1613answers:
8
+3
A:
I tried this a long time ago without success. Reflector has improved alot since then so I imagine it may be possible today.
It's actually kind of scary if you think about it. Someone could decompile your app and have the full code, then modify it and distribute their own version of it. All without being open source. But then again that's why "they" created obfuscators.
Chris Pietschmann
2008-09-20 04:55:51
It's also why they created EULAs.
TraumaPony
2008-09-20 05:10:15
+2
A:
I can't find the link but somebody did use the reflector source to compile a debug version of the 1.1 framework the could step through. I tried with the 2.0 framework and found too many errors to make it worth my while.
If you would like to try this start with a plugin like FileDisassembler. In my brief experience with this I found that there were some errors to fix but not to bad.
With a small-medium size library this method should be very doable.
Brownie
2008-09-20 05:05:32
Given that there is quite a few native C implementations in the NET Framework I find this *very unlikely*.
stephbu
2008-09-20 06:57:34
I am not suggesting that you could step into the C implementations but if you recompile the .NET source there is no reason you couldn't step into the code that calls the native code.
Brownie
2008-09-29 05:44:30
A:
It's possible but not really practical in larger more complex applications, especially when lots of the more recent structures like lambdas and initializers have been used (you get a whole bunch of variable names containing dollar signs like CS$4$0000 that have to be fixed manually). Even simple switch statements can cause some very ugly spaghetti code full of goto statements in Reflector.
I've had a lot more luck decomiling to MSIL and recompiling in debug mode. You can then put break points in the IL files and use all the usual debugger features in VS. MSIL looks a little scary at first but you get the hang of it pretty quickly.
This excellent article explains how to do it: http://www.codeproject.com/KB/dotnet/Debug_Framework_Classes.aspx
Nathan Baulch
2008-09-20 05:08:59
+1
A:
No, you need the symbol file (.PDB) file that belongs to the application you are trying to debug.
Reflector allows you to go from IL to readable .NET code but it maintains meaning only not the exact code as written by the developer. So even if you had the PDB and the source from Reflector it wouldn't match up for debugging.
I suppose you could use the source output from reflector to create a .NET project and generate your own version of the assembly you want to debug. That is ussually a real pain though and in the case of the .NET framework Microsoft publishes the debugging information for use by anyone who is interested.
I remember at one point there was a plugin for debugging in Reflector but I could never get it to work.
Configuring Visual Studio to Debug .NET Framework Source Code
MSDN: PDB Files
spoon16
2008-09-20 05:22:11
A:
I've seen it and done it before. I used it to show my boss that our app wasn't as protected as he thought it was. Took a DLL, got the source code, and bam -- he practically had a heart attack.
There are scenarios where .Net Reflector breaks down, but it is hard to do so -- I know because I've actively tried. The good obfuscators will make the code so unmanageable / unreadable (like overloading the "a" function to do a ton of different thigns based on the parameters) that seeing the source does you no good, but you can still debug -- good luck figuring out what is going on.
torial
2008-09-20 06:38:57
+4
A:
The Deblector plug-in for Reflector allows you to debug straight from Reflector.
Alex Lyman
2008-09-20 07:18:32
A:
Maybe one day this will be possible :) http://www.simple-talk.com/community/blogs/bart/archive/2009/03/23/72559.aspx
Alex Davies
2009-06-30 08:49:00