Advantages of Code Analysis Techniques

dynamic analysis n.w
1 / 23
Embed
Share

Discover the benefits of static and dynamic code analysis methods in software development. Learn how each approach helps to identify issues, improve code quality, and enhance overall security throughout the development lifecycle.

  • Code analysis
  • Software development
  • Static analysis
  • Dynamic analysis
  • Security

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Dynamic analysis

  2. The main advantage of static analysis is that it finds issues with the code before it is ready for integration and further testing. The problems are found at the exact location where they occur amazing, no? Weaknesses are found earlier in the development life cycle, reducing the cost to fix. Tools can sometimes be used by testing (non dev) staff

  3. but: can take a lot of time, especially when done manually tools produce false positives & negatives. need some level of technical understanding tools can provide a false sense of security that everything was found. the rules, and nothing but the rules, it s all about the rules

  4. Dynamic analysis while it is running

  5. + looks in runtime environment, which can matter don t necessarily need to have source can cut false negative from static tools can compliment static analysis

  6. + detects dependencies that are not possible to detect in static analysis.. Can collect temporal information. Deals with real input data

  7. - - Automated tools provide a false sense of security that everything is being addressed. Does not provide full coverage, only the path through the code which happens for the set of user input used Automated tools produce false positives and false negatives. only as good as the rules they are using more difficult to trace the vulnerability back to the exact location in the code

  8. Warning! Dynamic Analysis of malware means running the malware! It sounds obvious, but remember it can put your system and network at risk execute malware on virtual machines or dedicated systems in isolated networks ( air gapped , virtual settings, or similar)

  9. you will only test the code through which the execution path flows need to run it with sufficient test inputs to cover most possible outputs. have sufficient code coverage aim to exercise all pathways through the code, hit the ones that are actually used at least. make the run real , including timing, playback if possible

  10. Types of dynamic analysis: Code coverage computation Memory corruption Fault localization Concurrency errors Performance analysis and more

  11. Types of da: Code coverage computation gprof and gcov gprof gnu profiler shows how much time your code spends and where need to compile in supporting code (-pg -g) and run under control (gprof)

  12. gcov gnu coverage program man page: profiling tool to help discover where your optimization efforts will best affect your code. You can also use gcov assess which parts of your code use the greatest amount of computing time. gcov along with the other profiling tool, gprof gprof, to

  13. Gprof example, follow along: Let s profile openssl, 30,000 ft view: 1. Have profiling enabled while compiling the code 2. Execute the program code to produce the profiling data 3. Run the gprof tool on the profiling data file (generated in the step above).

  14. Gprof example, follow along: 1. make a directory: ~/openssl, do the rest from inside there 2. get a copy of openssl-master.tar.gz from 147.182.177.199, it s in / 3. Look at README & INSTALL to learn how to build the software 4. Before making , add the compiler flags for gprof and gcov to CFLAGS -pg -g 1. and remove the incompatible O3 and fomit-frame-pointer from CFLAGS if you find them 2. make 1. Have profiling enabled while compiling the code

  15. There are a number or prerequisite software packages, from INSTALL: To install OpenSSL, you will need: * A make implementation * Perl 5 with core modules (please read NOTES.PERL) * The perl module Text::Template (please read NOTES.PERL) * an ANSI C compiler * a development environment in the form of development libraries and C header files * a supported operating system For additional platform specific requirements, solutions to specific issues and other details, please read one of these: * NOTES.UNIX (any supported Unix like system) * NOTES.VMS (OpenVMS) * NOTES.WIN (any supported Windows) * NOTES.DJGPP (DOS platform with DJGPP) * NOTES.ANDROID (obviously Android [NDK]) all the necessary packages are already installed on 147.182.177.199 however, when running the new copy of openssl you create, REMEMBER: PATH and LD_LIBRARY_PATH

  16. Gprof example, follow along: use the openssl you built to do something: $ ./openssl dgst -sha256 ./openssl SHA256(./openssl)= 408f72a56be3602b2d03c79c9d4543b1f7ee01a8b533cd6b8c38976c41397e68 this will create a file named gmon.out $ ls -latr | tail -1 -rw-r--r-- 1 root root 200842 Apr 1 20:42 gmon.out run gprof to create a report from gmon.out: $ gprof ./openssl gmon.out > report 2. Execute the program code to produce the profiling data

  17. Gprof example, follow along: Make it statistically meaningful 1.Run your program once. 2.Save the output: `mv gmon.out gmon.sum'. 3.Run your program again, the same as before. 4.Merge the new data in `gmon.out' into `gmon.sum' : gprof -s executable-file gmon.out gmon.sum 5.Repeat the last two steps as often needed (more is better). 6.Analyze the cumulative data using this command: gprof executable-file gmon.sum > output-file 3. Run the gprof tool on gmon.sum as described above

  18. some types of dynamic analysis: memory corruption buffer overflows, dangling pointers, malloc/free balance, memory leaks Access of uninitialized/freed memory AddressSanitizer, Purify, many more

  19. AddressSanitizer example https://www.youtube.com/watch?v=1CcuD7EwhOY

  20. Types of da: fault localization As it says, find it. look through core files print statements debuggers, runtime environments + other, maybe questionable, methods See: https://personal.utdallas.edu/~ewong/fault-localization-survey.pdf

  21. Types of da: concurrency errors used to find race conditions, potential deadlocks, all those synchronization topics you discusses in operating systems class Parasoft Jtest https://en.wikipedia.org/wiki/Jtest https://www.parasoft.com/products/jtest

  22. Types of da: performance analysis Overlap with coverage tools, but more AMD codeXL, code analyst are open source dynamoRIO platform for building dynamic analysis tools Many proprietary tools

  23. Tools that watch it from the outside: Sniffers like tcpdump (t (the IP address or hostname is often retrieved from the malware by performing static malware analysis) tcpdump, etherfind etherfind, wireshark wireshark nc (netcat) strace INetSim INetSim fakes the common internet services which malware might use and answers the requests made accordingly. logs all incoming connections so you can analyze which services the malware is using and what requests it makes .

Related


More Related Content