|
From: Tor L. <tm...@ik...> - 2009-04-13 11:31:30
|
> Thanks for your help, I think program running under Windows (such as .NET > program) often need to be tainted for further program analysis or bug > detection. I think you are misguided here when generalizing .NET applications and traditional Windows applications. After all, .NET applications (as long as we are talking about ones that contain only managed code and not tons of unsafe (native) code) are safe, by definition, from many types of errors. Just like Java code. > Unfortunately, I find little binary-level instrumented tools > which can achieves the goal. Is there anybody knows it? BoundsChecker, Purify, etc. There are lots of tools. They cost money, though, but many of them are worth their price. (And many, presumably, nowadays also support .NET, although surely internally the mechanisms they use for that are very different from the ones used for traditional machine code). > BTW, CIL is a very efficient and robust tools for instrumenting the program > with source code available. Huh? CIL is not a tool, it means "Common Intermediate Language", i.e. it is the "bytecode" that managed .NET assemblies consist of. (Apparently the term "CIL" can mean either the actual binary bytecode, or its (one-to-one) "human-readable" textual representation, which I find a bit confusing. Or maybe I misunderstand something.) > But it seems that it can not instrument the binary code, right? What "it"? And what "binary code", the .NET CIL "bytecode" or x86 machine code? Obviously very different tools are used to manipulate CIL and machine code. To inspect and instrument CIL code one would most naturally write such a tool in .NET itself and use functionality provided by classes in the System.Reflection and System.Reflection.Emit namespaces. To instrument machine code, something like Valgrind, Purify, Dynamo/RIO etc would be used. --tml |