diff -uNr fenris.orig/README fenris/README --- fenris.orig/README Wed May 8 21:01:58 2002 +++ fenris/README Thu May 16 12:45:36 2002 @@ -40,7 +40,7 @@ This program does not automate the process of auditing, and does not favor any particular use. Instead of that, it is intended to be a flexible and universal application that will be a valuable solution for many - advances users. + advanced users. While functional, it is probably not tested sufficiently, there are many issues to fix, several known bugs, some portability issues. It is @@ -83,8 +83,8 @@ playing chess - it is a general analysis of possible states, way too many to be implicitly projected by our conscience, a result of experience, knowledge, some unparalleled capabilities of human brain, and luck. It is - also a subject to false moves and misjudgment. And there is just maybe - few hundreds of excellent players. + also a subject to false moves and misjudgment. And there are maybe just a + few hundred excellent players. As for today, freely and commercially available audit tools both use two opposite approaches. First approach tends to minimize human role by @@ -104,11 +104,11 @@ the development of new computation models, such as quantum computing, or by creating mathematical models that allow us to make such problems non-polynomial - but for now, we are far from this point, and static - analysis is restrained in many very serious ways, even thought many + analysis is restrained in many very serious ways, even though many software suppliers tend to market their products as the ultimate, 100% solutions. Subtle, complex, conditional dynamic errors, such as privilege dropping problems, input-dependent table overflows in C and - many other issues usually cannot be detected without generating + many other issues usually cannot be detected without generating a completely unacceptable number of false positives. This kind of software is highly dependent on coding style, and specific notation or development practices might render them less efficient - for example, automated audit @@ -124,8 +124,8 @@ generating certain predictive statements about the code. While there are very interesting developments in this direction, such as the work of professor Patrick Cousot, it is very difficult to make any detailed, - accurate and abstract enough run-time predictions for a complex source - code that have any immediate value in the analysis of unknown algorithm. + accurate and abstract enough run-time predictions for complex source + code that has any immediate value in the analysis of unknown algorithm. Last but not least, static analysis of sources can be deployed only when the source code is available, which does not have to be the case. This approach @@ -134,20 +134,20 @@ method - but to demonstrate that this much favored approach is not flawless and how much it needs to be accompanied with auxiliary methods. - Second approach to be discussed here is based on a dynamic run-time + The second approach to be discussed here is based on a dynamic run-time program analysis. This method is usually used to provide the user with - an information about actual program execution path, letting him make + information about actual program execution path, letting him make decisions on which path to follow and giving him free will to draw any conclusions and perform all the synthetic reasoning. This method is - applied to live binary executed in real-time and bases on monitoring + applied to a live binary executed in real-time and is based on monitoring syscalls (strace), libcalls (ltrace) or functions (xtrace); in certain cases, breakpoint debuggers, such as gdb, can be used, however it is usually not feasible to use them to perform anything more than in-depth analysis of a very small portion of program functionality. Usually, such analysis provides a very useful information on what is happening, - and this information is provided in uniform, reduced-output form. Careful + and this information is provided in uniform, reduced-output form. A careful auditor can analyze program behavior and find interesting or potentially - dangerous run-time conditions. By monitoring how given application interacts + dangerous run-time conditions. By monitoring how a given application interacts with external world, he (or she) can determine whether some other conditions can be triggered and eventually explore them by examining sources or re-running the program. Advantages are enormous, as such software enables @@ -177,8 +177,8 @@ While not mentioned above, there is also another approach to black-box code - high-level decompiler. However, the complexity of modern compilers makes - it very difficult to develop effective C decompiler or similar utility, - and there are only a few project available to accomplish it, most of them + it very difficult to develop an effective C decompiler or similar utility, + and there are only a few projects available to accomplish it, most of them not able to deal with too complex or optimized code. Finally, there is no guarantee that generated output code will be any help in comprehending the program. For now, this approach remains almost purely theoretical, @@ -191,9 +191,9 @@ compared to other tools, trying to support the auditor and to make his work much more effective. This is accomplished by combining a number of techniques, including partial run-time decompiler, stateful analysis, code - fingerprinting, I/O analysis and high-level visualization layer, run-time + fingerprinting, I/O analysis and high-level visualization layer and run-time code modification capabilities. The goal is to provide a very detailed trace - information, and, at the same time, to provide a data suitable to build a + information, and, at the same time, to provide data suitable to build a model of program behavior more quickly and in more convenient way. Fenris is not supposed to find vulnerabilities or bugs, or to guess @@ -238,13 +238,13 @@ 8617:00 * local object irc_servers:123 (0x80654321) 8617:00 * unknown address 0x40123456 - Fenris output is a descriptive trace of program activity. For larger + Fenris output is a descriptive trace of program activity. For a larger project, this trace might have many megabytes, and, to avoid problems reading it, it should be either delimited to a revelant structural portion of code that is being analyzed right now, or should be transformed in a different model of execution path. One of such trivial transform tools is called 'ragnarok'. It is able to convert first layer - output into graphical html model that summarizes program structure, + output into a graphical html model that summarizes program structure, marks data migration, I/O points, conditional points, and, on request, provides detailed information about single functions. Ragnarok is hardly an integral component of Fenris - it is merely a parser that transforms @@ -256,7 +256,7 @@ a) "program flow": a table, or, in the future, a browsable graph (think of IBM's OpenDX) with horizontal lines (rows) representing functions and vertical lines (columns) representing buffers and I/O - sources (Y axis is time). When function uses one of buffers or + sources (Y axis is time). When a function uses one of the buffers or interacts with I/O source, intersection of this object and function is marked in a way dependent on the nature of this operation. Conditional expressions evaluated during program execution are also marked. Data diff -uNr fenris.orig/doc/README fenris/doc/README --- fenris.orig/doc/README Wed May 8 21:01:58 2002 +++ fenris/doc/README Thu May 16 12:45:36 2002 @@ -40,7 +40,7 @@ This program does not automate the process of auditing, and does not favor any particular use. Instead of that, it is intended to be a flexible and universal application that will be a valuable solution for many - advances users. + advanced users. While functional, it is probably not tested sufficiently, there are many issues to fix, several known bugs, some portability issues. It is @@ -83,8 +83,8 @@ playing chess - it is a general analysis of possible states, way too many to be implicitly projected by our conscience, a result of experience, knowledge, some unparalleled capabilities of human brain, and luck. It is - also a subject to false moves and misjudgment. And there is just maybe - few hundreds of excellent players. + also a subject to false moves and misjudgment. And there are maybe just a + few hundred excellent players. As for today, freely and commercially available audit tools both use two opposite approaches. First approach tends to minimize human role by @@ -104,11 +104,11 @@ the development of new computation models, such as quantum computing, or by creating mathematical models that allow us to make such problems non-polynomial - but for now, we are far from this point, and static - analysis is restrained in many very serious ways, even thought many + analysis is restrained in many very serious ways, even though many software suppliers tend to market their products as the ultimate, 100% solutions. Subtle, complex, conditional dynamic errors, such as privilege dropping problems, input-dependent table overflows in C and - many other issues usually cannot be detected without generating + many other issues usually cannot be detected without generating a completely unacceptable number of false positives. This kind of software is highly dependent on coding style, and specific notation or development practices might render them less efficient - for example, automated audit @@ -124,8 +124,8 @@ generating certain predictive statements about the code. While there are very interesting developments in this direction, such as the work of professor Patrick Cousot, it is very difficult to make any detailed, - accurate and abstract enough run-time predictions for a complex source - code that have any immediate value in the analysis of unknown algorithm. + accurate and abstract enough run-time predictions for complex source + code that has any immediate value in the analysis of unknown algorithm. Last but not least, static analysis of sources can be deployed only when the source code is available, which does not have to be the case. This approach @@ -134,20 +134,20 @@ method - but to demonstrate that this much favored approach is not flawless and how much it needs to be accompanied with auxiliary methods. - Second approach to be discussed here is based on a dynamic run-time + The second approach to be discussed here is based on a dynamic run-time program analysis. This method is usually used to provide the user with - an information about actual program execution path, letting him make + information about actual program execution path, letting him make decisions on which path to follow and giving him free will to draw any conclusions and perform all the synthetic reasoning. This method is - applied to live binary executed in real-time and bases on monitoring + applied to a live binary executed in real-time and is based on monitoring syscalls (strace), libcalls (ltrace) or functions (xtrace); in certain cases, breakpoint debuggers, such as gdb, can be used, however it is usually not feasible to use them to perform anything more than in-depth analysis of a very small portion of program functionality. Usually, such analysis provides a very useful information on what is happening, - and this information is provided in uniform, reduced-output form. Careful + and this information is provided in uniform, reduced-output form. A careful auditor can analyze program behavior and find interesting or potentially - dangerous run-time conditions. By monitoring how given application interacts + dangerous run-time conditions. By monitoring how a given application interacts with external world, he (or she) can determine whether some other conditions can be triggered and eventually explore them by examining sources or re-running the program. Advantages are enormous, as such software enables @@ -177,8 +177,8 @@ While not mentioned above, there is also another approach to black-box code - high-level decompiler. However, the complexity of modern compilers makes - it very difficult to develop effective C decompiler or similar utility, - and there are only a few project available to accomplish it, most of them + it very difficult to develop an effective C decompiler or similar utility, + and there are only a few projects available to accomplish it, most of them not able to deal with too complex or optimized code. Finally, there is no guarantee that generated output code will be any help in comprehending the program. For now, this approach remains almost purely theoretical, @@ -191,9 +191,9 @@ compared to other tools, trying to support the auditor and to make his work much more effective. This is accomplished by combining a number of techniques, including partial run-time decompiler, stateful analysis, code - fingerprinting, I/O analysis and high-level visualization layer, run-time + fingerprinting, I/O analysis and high-level visualization layer and run-time code modification capabilities. The goal is to provide a very detailed trace - information, and, at the same time, to provide a data suitable to build a + information, and, at the same time, to provide data suitable to build a model of program behavior more quickly and in more convenient way. Fenris is not supposed to find vulnerabilities or bugs, or to guess @@ -238,13 +238,13 @@ 8617:00 * local object irc_servers:123 (0x80654321) 8617:00 * unknown address 0x40123456 - Fenris output is a descriptive trace of program activity. For larger + Fenris output is a descriptive trace of program activity. For a larger project, this trace might have many megabytes, and, to avoid problems reading it, it should be either delimited to a revelant structural portion of code that is being analyzed right now, or should be transformed in a different model of execution path. One of such trivial transform tools is called 'ragnarok'. It is able to convert first layer - output into graphical html model that summarizes program structure, + output into a graphical html model that summarizes program structure, marks data migration, I/O points, conditional points, and, on request, provides detailed information about single functions. Ragnarok is hardly an integral component of Fenris - it is merely a parser that transforms @@ -256,7 +256,7 @@ a) "program flow": a table, or, in the future, a browsable graph (think of IBM's OpenDX) with horizontal lines (rows) representing functions and vertical lines (columns) representing buffers and I/O - sources (Y axis is time). When function uses one of buffers or + sources (Y axis is time). When a function uses one of the buffers or interacts with I/O source, intersection of this object and function is marked in a way dependent on the nature of this operation. Conditional expressions evaluated during program execution are also marked. Data