EDBT 2026 Demo / reviewers in the wild / expert
Carson Harmon
dblp:272/8286
· DBLP profile ↗
2ranked-venue papers
0as first author
1since 2021 · last 2024
0009-0003-3793-881XORCID · corroborated
Domains — the database's venue-derived domains; a paper can count in several
Security and privacy · 1Software engineering, systems software and programming languages · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Program analysis · 100% | |
| Network and information security
1 paper |
Malware analysis · 100% |
Topics — the 4 heaviest of 5, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Program analysis
dynamic analysis |
0.8 | 1 | 2024 | PolyTracker: Whole-Input Dynamic Information Flow Tracing · ISSTA 2024 |
Program analysis › dynamic analysis
dynamic information-flow tracking |
0.8 | 1 | 2024 | PolyTracker: Whole-Input Dynamic Information Flow Tracing · ISSTA 2024 |
Malware analysis › dynamic malware analysis
forced execution |
0.4 | 1 | 2020 | PMP: Cost-effective Forced Execution with Probabilistic Memory Pre-planning · SP 2020 |
Program analysis › static analysis
bug detection |
0.2 | 1 | 2024 | PolyTracker: Whole-Input Dynamic Information Flow Tracing · ISSTA 2024 |
Methods — techniques the papers use, named apart from their topics
fuzzing · 0.8LLVM instrumentation · 0.8probabilistic memory pre-planning · 0.4forced execution · 0.4
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2024 | PolyTracker: Whole-Input Dynamic Information Flow TracingabstractWe present PolyTracker, a whole-program, whole-input dynamic information flow tracing (DIFT) framework. Given an LLVM compatible codebase or a binary that has been lifted to LLVM intermediate representation (IR), PolyTracker compiles it, adding static instrumentation. The instrumented program will run normally with modest performance overhead, but will additionally output a runtime trace artifact in the co-designed TDAG (Tainted Directed Acyclic Graph) format. TDAGs can be post-processed for a variety of analyses, including tracing every input byte through program execution. TDAGs can be generated either by running the program over a corpus of inputs or by employing a randomized input generator such as a fuzzer. PolyTracker traces (TDAGs) are useful not only for very localized, targeted dynamic program analysis as with smaller-scale DIFT: TDAGs are primarily intended for whole-program runtime exploration and bug finding, granular information-flow diffing between program runs, and comparisons of implementations of the same input specification without any need to emulate and instrument the entire running environment. For user-friendliness and reproducibility, the software repository provides a number of examples of PolyTracker-instrumented builds of popular open-source software projects. We also provide an analysis library and REPL written in Python that are designed to assist users with operating over TDAGs. Evan Sultanik, Marek Surovic, Henrik Brodin, Kelly Kaoudis, Facundo Tuesca, Carson Harmon, Lisa Overall, Joseph Sweeney, Bradford Larsen |
ISSTA | 6 |
| 2020 | PMP: Cost-effective Forced Execution with Probabilistic Memory Pre-planningabstractMalware is a prominent security threat and exposing malware behavior is a critical challenge. Recent malware often has payload that is only released when certain conditions are satisfied. It is hence difficult to fully disclose the payload by simply executing the malware. In addition, malware samples may be equipped with cloaking techniques such as VM detectors that stop execution once detecting that the malware is being monitored. Forced execution is a highly effective method to penetrate malware self-protection and expose hidden behavior, by forcefully setting certain branch outcomes. However, an existing state-of-the-art forced execution technique X-Force is very heavyweight, requiring tracing individual instructions, reasoning about pointer alias relations on-the-fly, and repairing invalid pointers by on-demand memory allocation. We develop a light-weight and practical forced execution technique. Without losing analysis precision, it avoids tracking individual instructions and on-demand allocation. Under our scheme, a forced execution is very similar to a native one. It features a novel memory pre-planning phase that pre-allocates a large memory buffer, and then initializes the buffer, and variables in the subject binary, with carefully crafted values in a random fashion before the real execution. The pre-planning is designed in such a way that dereferencing an invalid pointer has a very large chance to fall into the pre-allocated region and hence does not cause any exception, and semantically unrelated invalid pointer dereferences highly likely access disjoint (pre-allocated) memory regions, avoiding state corruptions with probabilistic guarantees. Our experiments show that our technique is 84 times faster than X-Force, has 6.5X and 10% fewer false positives and negatives for program dependence detection, respectively, and can expose 98% more malicious behaviors in 400 recent malware samples. Wei You 0001, Zhuo Zhang 0002, Yonghwi Kwon 0001, Yousra Aafer, Carson Harmon, Xiangyu Zhang 0001 |
SP | 7 |