CS110L L2 - Program Analysis

Last

Warning

If someone is reading this blog, please be aware that the writer did not consider the experience of the other readers.
After all, the most important part is about writing things down for better memorization.

Valgrind

  • Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail.

  • The tool does it’s job by modifying some of the assembly code which is assosiated to memory operation, like call malloc or load/store, when executing the code.

  • It is doing what we call ‘dynamic analysis’, which is run the program and watch what it does.

  • Though it is able to detect heap-based buffer overflows, valgrind cannot detect stack-based buffer overflows, as it does not know the source code of the program and has no idea about the stack layout.

LLVM Sanitizers

  • Instead of instrumenting binary file like Valgrind does, it instruments the source code.

  • There’re several kinds of sanitizers, including memory sanitizer, leak sanitizer, undefined behavior sanitizer and thread sanitizer.

Fundamental Limitation of Dynamic Analysis

  • Dynamic analysis can only report bad behavior that actually happened.

  • The program might crash due to some specific input from the user which is probably not going to show up during the test/dynamic analysis.

  • This leads to the fact that, we just can’t find lots of the issues before it happens. There’re just too much possible issues.

Fuzzing Testing

  • A very simple but extremely effective way to find bugs.

  • AFL & libfuzzer

  • Still can not provide any guarantees that a program is bug-free.

Static Analysis

  • Static analyzers could be helpful when finding bugs in the code by doing data-flow analysis. It can detect some edge cases that dynamic analysis might never be able to run into.

  • However, static analyzers can report a lot of false positives, which means that reporting bugs that could only be triggerred theoratically and impossible in real world.

  • Also, tracing every possible control flow could be a very cpu-consuming job.

  • Plus a whole bunch of potential problems. There’re just too many possible issues that exceeds the limit of code analysis.

  • Title: CS110L L2 - Program Analysis
  • Author: Last
  • Created at : 2025-05-01 00:17:00
  • Link: https://blog.imlast.top/2025/04/30/cs110l-l2/
  • License: This work is licensed under CC BY-NC-SA 4.0.
Comments
Nickname
Email
Website
0/500
  • OωO
  • |´・ω・)ノ
  • ヾ(≧∇≦*)ゝ
  • (☆ω☆)
  • (╯‵□′)╯︵┴─┴
  •  ̄﹃ ̄
  • (/ω\)
  • ∠( ᐛ 」∠)_
  • (๑•̀ㅁ•́ฅ)
  • →_→
  • ୧(๑•̀⌄•́๑)૭
  • ٩(ˊᗜˋ*)و
  • (ノ°ο°)ノ
  • (´இ皿இ`)
  • ⌇●﹏●⌇
  • (ฅ´ω`ฅ)
  • (╯°A°)╯︵○○○
  • φ( ̄∇ ̄o)
  • ヾ(´・ ・`。)ノ"
  • ( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
  • (ó﹏ò。)
  • Σ(っ °Д °;)っ
  • ( ,,´・ω・)ノ"(´っω・`。)
  • ╮(╯▽╰)╭
  • o(*////▽////*)q
  • >﹏<
  • ( ๑´•ω•) "(ㆆᴗㆆ)
  • 😂
  • 😀
  • 😅
  • 😊
  • 🙂
  • 🙃
  • 😌
  • 😍
  • 😘
  • 😜
  • 😝
  • 😏
  • 😒
  • 🙄
  • 😳
  • 😡
  • 😔
  • 😫
  • 😱
  • 😭
  • 💩
  • 👻
  • 🙌
  • 🖕
  • 👍
  • 👫
  • 👬
  • 👭
  • 🌚
  • 🌝
  • 🙈
  • 💊
  • 😶
  • 🙏
  • 🍦
  • 🍉
  • 😣
  • 颜文字
  • Emoji
  • Bilibili
0 comments
No comment