Abstract
In this chapter, I’ll cover how you can debug your CIL-based applications. I’ll demonstrate how you can create debug builds of your assemblies, the tools that you can use to debug them, and how to get them running in the debugger.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Reference
And do you really want to do that in CIL?
For more information on getting these symbol files for system executables, see ms-help://MS.NETFrameworkSDK/vsdebug/html/vxtskInstallingDebugSymbols.htm.
While I won’t show any multithreaded assemblies in this chapter, you can prefix most of the cordbg commands with an asterisk (*) to apply them to every thread in the assembly.
Note that if you want to stop the current debugging session, but you don’t want to leave cordbg, enter kill.
Interested readers can download the three volumes of Intel’s Architecture Software Developer’s Manual at http://developenintel.com/design/pentium4/manuals/.
A scenario that’s highly unlikely, but you never know.
Your values will probably be completely different from mine. That’s OK—as I discuss specific register values, just focus on the register label itself and don’t try to compare your results with mine.
You may not have noticed yet, but if you don’t pass in any arguments to BadConsole, you don’t get an exception.
Readers who have done any MTS/COM+ development will be familiar with the technique I’m about to show.
break isn’t limited to in-proc assemblies; it’ll work the same in any kind of assembly.
The debugger will tell you which method the InvalidProgramException happened in, but that’s it.
See Section 21 of Partition II for metadata validation rules. Each CIL opcode in Partition III has a section that discusses the verifiability rules.
This assembly (but not its source code) is included with the book’s downloadable code.
Of course, this is a very contrived case, as there’s no reason to buy such a trivial component, but it’s not the capabilities of the assembly that matter in this case.
You could run PEVerify and tell the company that they released an assembly with two IL errors, but since there’s no way to get a hold of the vendor in this fictitious case, it doesn’t matter (although it helps you to run PEVerify so you can glean more information on BadDivider’s problems).
Whether they reimburse you financially for your heroic efforts is another story.
Full coverage of how obfuscators work is beyond the scope of one chapter. I strongly suggest reading the paper “Java Control Flow Obfuscation,” which can be downloaded at http://www.cs.auckland.ac.nz/research/theses/1998/lowdouglasthesis1998.pdf,for detailed coverage on this topic.
Note that an obfuscator can work at either the source-code or assembly level. I’m only showing the example in C# as it’s easier to follow than CIL.
And, chances are Node’s name would’ve been obfuscated as well, which makes the job of reading the reverse-engineered code much more difficult.
Rights and permissions
Copyright information
© 2002 Jason Bock
About this chapter
Cite this chapter
Bock, J. (2002). Debugging CIL. In: CIL Programming: Under the Hood™ of .NET. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4302-0845-7_5
Download citation
DOI: https://doi.org/10.1007/978-1-4302-0845-7_5
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4302-5156-9
Online ISBN: 978-1-4302-0845-7
eBook Packages: Springer Book Archive