{"title":"argp","link":[{"@attributes":{"href":"https:\/\/argp.github.io\/atom.xml","rel":"self"}},{"@attributes":{"href":"https:\/\/argp.github.io\/"}}],"updated":"2023-04-24T13:19:40+00:00","id":"https:\/\/argp.github.io","author":{"name":"argp","email":"argp@census-labs.com"},"entry":[{"title":"Paper notes: HeapHopper","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2018\/09\/06\/heaphopper\/"}},"updated":"2018-09-06T00:00:00+00:00","id":"https:\/\/argp.github.io\/2018\/09\/06\/heaphopper","content":"

Title: HeapHopper: Bringing bounded model checking to heap implementation security
\nPDF: 970a2d1ce20edee6eaf3b9cecd071f81.pdf<\/a><\/p>\n\n

A system for evaluating heap allocator implementations for metadata corruption\nattacks. Comes with an open source implementation<\/a>,\nand it uses angr<\/a> to analyze the binaries that implement the\ntarget allocator. A configuration file is also required to specify the attackers capabilities;\nthe heap operations she can perform (malloc, free), but also higher level attack primitives,\nlike heap buffer overflows, use-after-frees, double frees, and arbitrary frees. The configuration\nfile also includes a list of states corresponding to violated security properties (i.e. exploitation\nprimitives). For example, a return-used primitive (or \u201coverlapping allocation\u201d as the authors call\nit) is checked when a new allocation is made with malloc returning address A, by using an SMT solver\nto check if the following holds (B is the address of an already used allocation):<\/p>\n\n

\u2203B : ((A \u2264 B) \u2227 (A + sizeof(A) > B)) \u2228 ((A \u2265 B) \u2227 (B + sizeof(B) > A))<\/p>\n\n

The corresponding Python angr code for the above check can be found\nhere<\/a>.<\/p>\n\n

Based on the configuration file, series of C programs are produced, compiled, and symbolically\nexecuted against the target allocator. Using angr, the allocator\u2019s malloc and free functions are\nhooked and monitored for the security violations described in the configuration file. The symbolic\nexecution traces and the associated constraints are finally used to create the next series of C\nprograms, until the specified exploitation primitives are achieved. The paper includes a detailed\nevaluation section for the dlmalloc and ptmalloc allocators. I didn\u2019t have the time yet to play\nwith HeapHopper\u2019s code, but I plan to test it against jemalloc; I\u2019ll be posting my findings here\nwhen I do so.<\/p>\n"},{"title":"Paper notes: Block oriented programming: automating data-only attacks","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2018\/08\/02\/bop\/"}},"updated":"2018-08-02T00:00:00+00:00","id":"https:\/\/argp.github.io\/2018\/08\/02\/bop","content":"

Title: Block oriented programming: automating data-only attacks
\nPDF: aec7ba2a6395ec82632e323f0aef2295.pdf<\/a><\/p>\n\n

Proposes a system for automating the process of constructing exploitation payloads\nthat can bypass control-flow integrity and related mitigations. The target binary is\nlifted to an (unspecified) intermediate representation and its CFG is recovered. Each\nbasic block is \u201csummarized\u201d using symbolic execution into a set of constraints with\nchanges to memory and registers. These summarized data for each basic block also include\nany calls or jumps.<\/p>\n\n

The desired payload is specified in a pseudo-C language (SPloit Language - SPL ;) which\nis translated into an again unspecified (another? the same as the target binary?)\nintermediate representation. At the next step, non-surprisingly, the summarized basic\nblocks are matched to SPL IR statements. A matched basic block must satisfy changes to\nregisters and\/or calls specified by the corresponding SPL IR statement. The target binary\nis scanned for \u201cdispatcher\u201d blocks that enable the connection of the basic blocks\nidentified in the previous step. Dispatchers are found using concolic execution.\nConcretization of symbolic addresses is used to initialize memory before the execution\nof a previously matched basic block, guiding execution through the shortest path to\nthe next matched basic block. The identified paths must satisfy the constraints of the\nbasic blocks they traverse.<\/p>\n\n

Finally, the execution trace of the identified paths is encoded as a series of writes\nfor the target binary (the exploit payload). A bug giving an arbitrary write primitive\nis assumed of course.<\/p>\n\n

Update (2018\/11\/02): The authors have released the\naccompanying code<\/a>, and, not surprisingly, it\nis based on angr<\/a>.<\/p>\n"},{"title":"Paper notes: Reverse engineering x86 processor microcode","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2017\/09\/14\/re-x86-microcode\/"}},"updated":"2017-09-14T00:00:00+00:00","id":"https:\/\/argp.github.io\/2017\/09\/14\/re-x86-microcode","content":"

Title: Reverse engineering x86 processor microcode
\nPDF: 133f02627cbd3771ad5d4b09729cfce7.pdf<\/a><\/p>\n\n

A very interesting paper with technical details on the x86 microcode inner\nworkings of AMD\u2019s K8 and K10 CPUs. The reason for focusing on these old CPUs\nis that other\/newer ones cryptographically protect their microcode updates,\nboth for authenticity\/integrity and confidentiality.<\/p>\n\n

AMD\u2019s K8 and K10 microcode updates are encoded (but not encrypted or signed)\nin a proprietary format which is only partly explained in the paper. The update\nprocess decodes the blob, which includes sets of microcode instructions\n(microinstructions) called triads<\/code>, and values for match registers<\/code> which are\nmicrocode-internal register-like locations that hold addresses of triads in\nmicrocode ROM. The new triads that the update carries are mapped in\nmicrocode RAM directly after the address space of the ROM, and the match\nregister values are copied to their respective match registers. The match\nregisters (which are eight by design) can be used to run the updated\nmicrocode triads by redirecting execution to the new addresses in RAM. The\nauthors use this to hook CPU microcode triads and run their version of the\ndiv<\/code> instruction for example. One limitation (apart from the only eight\navailable match registers) is that instructions are separated into\nperformance critical ones (called direct path instructions), and more complex\nones (called vector path instructions). Match registers are used only for the\nlatter. Since the microcode update is mapped into RAM, it\u2019s not permanent,\nbut is applied at each boot.<\/p>\n\n

Using the above way to load arbitrary microcode triads via updates, the\nauthors then proceeded to reverse the microcode instruction set by trial and\nerror using a minimal operating system they developed. With some information\nfrom AMD\u2019s patents and bruteforcing the microcode instruction fields, they\nobserved the protection faults and CPU states their triads caused. This led\nto around 40% disassembling of existing microcode updates, which is an\nimpressive feat.<\/p>\n\n

The paper\u2019s accompanying code<\/a>\nincludes a\npatch for the Linux kernel<\/a> that applies a microcode update from file\n\/lib\/firmware\/amd-ucode\/myupdate.bin<\/code> without any checks. It also includes\nvarious\nsample updates<\/a> (in binary and encoded format, and microinstruction source)\nimplementing instrumentation and backdoor PoCs described in the paper.<\/p>\n\n

The references seem complete, apart from neglecting to cite Ben Hawkes\u2019\nnotes on Intel microcode updates<\/a>.<\/p>\n"},{"title":"Paper notes: Telling your secrets without page faults","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2017\/08\/28\/no-pagefaults\/"}},"updated":"2017-08-28T00:00:00+00:00","id":"https:\/\/argp.github.io\/2017\/08\/28\/no-pagefaults","content":"

Title: Telling your secrets without page faults
\nPDF: b81efa3a4c5826fa441852bd63a402c6.pdf<\/a><\/p>\n\n

A paper on two attacks against Intel SGX enclaves using side-effects of\npage table walks, without explicitly observing page faults. Both attacks\nare based on the fact that when the processor is in enclave execution mode,\nit still accesses the page table which is in unprotected (i.e. non-SGX) memory.\nSGX defines some access control mechanisms on top of that, but they don\u2019t\nhinder the presented attacks.<\/p>\n\n

The threat model under which the attacks are developed assumes a completely\nattacker-controlled operating system (both userland and kernel), and\nknowledge of the source code of the attacked SGX application (in order to\nmonitor interesting page accesses).<\/p>\n\n

The first attack exploits that accessed (and dirty) bits are set on pages\naccessed\/used by SGX application code in secure enclave mode. The page table\nentry (PTE) attribute (accessed and\/or dirty) that corresponds to the page\naccessed in SGX mode is stored in the kernel memory of the unprotected system.<\/p>\n\n

The second attack is based on cache misses; PTEs that refer to interesting\npages are evicted from the TLB (using clflush<\/code>). When the enclave is\nentered the TLB is cleared by design, therefore the attacker measures the\ntime required to reload the interesting PTEs when the enclave has returned.<\/p>\n\n

Both attacks require the identification of interesting pages (and the\ncorresponding PTEs) in advance. There is an initial step in which the\nattacked SGX application code is run outside the enclave, and a PC trace of\npage accesses is recorded.<\/p>\n\n

The authors have published\ntheir implementation<\/a>, which I haven\u2019t tested, but from a quick pass\nseems complete.<\/p>\n"},{"title":"Paper notes: BinSim","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2017\/08\/21\/binsim\/"}},"updated":"2017-08-21T00:00:00+00:00","id":"https:\/\/argp.github.io\/2017\/08\/21\/binsim","content":"

Title: BinSim: Trace-based semantic binary diffing via system call sliced segment equivalence checking
\nPDF: 0070bdf0db1fe29e6730d8e63662b0b3.pdf<\/a><\/p>\n\n

BinSim is a dynamic system for identifying differences between two malware\nsamples based on the executed system and API calls. I decided to read the paper\nin order to see if I can reuse anything in my usual bindiffing workflow for patch\nanalysis and symbol porting. Since it is dynamic, its first analysis step is to\nrun the two target x86 executables with the same input. BinSim uses BitBlaze as\nits dynamic analysis infrastructure, and therefore its next step is to lift the\nexecution trace logs to BitBlaze\u2019s Vine IL. The system and API calls from the two\ntraces are collected and aligned based on their call sequence. Then, the arguments\nof the matched calls are checked for equivalence. This is done by collecting all\ninstructions that affect them using backward slicing, and calculating each\nslice\u2019s weakest precondition symbolic formula. Finally, the two formulas,\neach representing an aligned system or API call from the target executables, are\nchecked for equivalence with a constraint solver. Similarity scores (1.0 for\na match, 0.7 for an approximate match, and 0.5 for an unknown case) are used\nto summarize the equivalence for the whole binaries.<\/p>\n"},{"title":"Paper notes: ARTISTE","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2016\/04\/26\/artiste\/"}},"updated":"2016-04-26T00:00:00+00:00","id":"https:\/\/argp.github.io\/2016\/04\/26\/artiste","content":"

Title: ARTISTE: Automatic generation of hybrid data structure signatures from\nbinary code executions
\nPDF: 8bd55709138804473a2e1d974ef8afd7.pdf<\/a><\/p>\n\n

Another runtime system with the goal of recovering both primitive types,\nand complex ones (structures, arrays and dynamic arrays), without the\nrequirement of source code or debugging symbols. The implementation supports\nboth Windows (PE) and Linux (ELF) binaries, but the paper does not mention\nif a DBI framework is used. An execution log is captured which contains\nexecuted instructions, operands, and also memory allocations and\ndeallocations. Based on this log, primitive data types are inferred via\nx86 instructions. For example, both operands of an add<\/code> instruction are\ngiven the type num32<\/code>. The prototypes of standard library functions are also\nused for the same purpose, and to narrow down the types (e.g. from num32<\/code>\nto size_t<\/code>).<\/p>\n\n

The interesting part of the paper is that a heap graph is constructed and\nlogged at periodic intervals during execution. This heap graph includes\nwhich functions operate on an allocation, and the types assigned to its\noffsets. Based on that, an allocation is denoted as an array or a structure,\nand a signature is created for it. These signatures are organized in a tree\nand updated during the analysis of the execution log.<\/p>\n"},{"title":"Paper notes: Towards automatic inference of kernel object semantics from binary code","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2016\/02\/20\/kernel-object-semantics\/"}},"updated":"2016-02-20T00:00:00+00:00","id":"https:\/\/argp.github.io\/2016\/02\/20\/kernel-object-semantics","content":"

Title: Towards automatic inference of kernel object semantics from binary code
\nPDF: 63062e684afced0b70009b33d9ba7b26.pdf<\/a><\/p>\n\n

This is a runtime system that infers the types of kernel objects (data structures)\nbased on a) which system calls access an object, and b) how they access it (read,\nwrite, create, delete). The implementation is based on a VMI (virtual machine\nintrospection) framework built on top of QEMU, and the presented results are\nonly for Linux kernels. A set of inference rules for Linux kernel data\nstructures must be manually defined. For example, an object created by\nsys_clone<\/code> and accessed for reading by sys_getpid<\/code> is denoted as either\ntask_struct<\/code> or pid<\/code>. Therefore, the automatic<\/em> claim of the title isn\u2019t\nstrictly applicable (at least according to my definition of automatic<\/em>).<\/p>\n"},{"title":"Paper notes: Automating information flow analysis of low level code","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2015\/09\/04\/automating-information-flow-analysis-low-level-code\/"}},"updated":"2015-09-04T00:00:00+00:00","id":"https:\/\/argp.github.io\/2015\/09\/04\/automating-information-flow-analysis-low-level-code","content":"

Title: Automating information flow analysis of low level code
\nPDF: 68d4b37e9623d0c67e7b856b76ebe4a1.pdf<\/a><\/p>\n\n

Uses BAP to lift ARMv7 code to BIL (BAP\u2019s intermediate representation language) with\nthe HOL4 model of ARMv7<\/a> and does forward\nsymbolic execution to build a logical formula that describes several executions. At\ninteresting execution points (called observation points in the paper), such as writes,\noffloading to SMT solving is used to verify that relational properties hold. Loops are\nhandled by manually finding relational invariants and using them to decorate the loops\naiding the verification.<\/p>\n"},{"title":"Paper notes: Fuzzy stack hash","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/12\/29\/fuzzy-stack-hash\/"}},"updated":"2014-12-29T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/12\/29\/fuzzy-stack-hash","content":"

If you have done any large scale fuzzing then you have faced the problem of\nduplicate bugs. These take time to be manually recognized and marked as\nduplicates.<\/p>\n\n

I have been discussing this recently with fellow CENSUS researcher\n@anestisb<\/a> (be sure to check out\nand vote for his SyScan\n2015 submission<\/a> on fuzzing and the internals of the new Android L runtime).<\/p>\n\n

We have reached the conclusion that the \u201cfuzzy stack hash\u201d provides\nan easily configurable trade-off to automatically identify semantically duplicate\nbugs. You can find its full description in the otherwise also very interesting\npaper \u201cDynamic test\ngeneration to find integer bugs in x86 binary linux programs\u201d<\/a>, section 6.1,\npage 9.<\/p>\n\n

The information used in the calculation of the fuzzy stack hash are a) the name\nof the function in which the crash occurred (or its address if no debug symbols\nare available), b) the source code line number if available (excluding the last\ndigit to allow for changes in the code), and c) the name of the object file for\neach frame in the call stack. The hash is calculated over all these for N functions\non the top of the call stack at the crash. N determines the \u201cfuzzy-ness\u201d of the\nhash and provides us with a configurable trade-off. A small N leads to labelling as\nduplicates different bugs that cause a crash at the same location; a large value for\nN leads to the fuzzy stack hash being essentially a normal backtrace leading to\nduplicate bugs being labelled as unique.<\/p>\n"},{"title":"Paper notes: Enhancing symbolic execution with veritesting","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/12\/23\/enhancing-symbolic-execution-with-veritesting\/"}},"updated":"2014-12-23T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/12\/23\/enhancing-symbolic-execution-with-veritesting","content":"

Title: Enhancing symbolic execution with veritesting
\nPDF: 2bf778fdcdfb9924adf057a79a9dc9a0.pdf<\/a><\/p>\n\n

The core idea is the switching from dynamic symbolic execution to static\n(and vice-versa) when certain identified transition points are reached.<\/p>\n\n

Example transition points from static to dynamic switching are unresolved\njumps, system calls, function boundaries, and other cases that are easier\nto handle dynamically.<\/p>\n"},{"title":"Paper notes: Toward a foundational typed assembly language","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/19\/typed-assembly-language\/"}},"updated":"2014-11-19T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/19\/typed-assembly-language","content":"

Title: Toward a foundational typed assembly language
\nPDF: 7b0f643010e5537ff02debab6b2fce4b.pdf<\/a><\/p>\n\n

A paper from 2002 but a very interesting read; it formally defines a type system for a\ncomplete assembly language (TAL). The paper gives typing rules for the instructions and\nfor memory allocation; its advantages are verification and reasoning (for things like\nheap object reachability) with machine-checked proofs.<\/p>\n\n

An implementation (in OCaml) of TAL for x86 is\nTALx86<\/a>; includes a type-checker\nand an assembler.<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/524588812731969536<\/a><\/p>\n"},{"title":"Paper notes: Time-ordered event traces","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/18\/debugging-primitive-for-concurrency-bugs\/"}},"updated":"2014-11-18T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/18\/debugging-primitive-for-concurrency-bugs","content":"

Title: Time-ordered event traces: a new debugging primitive for concurrency bugs
\nPDF: 4feb0d2508fcab1061401f6212dde8a2.pdf<\/a><\/p>\n\n

A methodology and\naccompanying pintool<\/a> for\nroot cause analysis of concurrency bugs; it basically records a runtime trace of function calls\nand returns, their thread IDs and global timestamps, making clear the order in which they execute.<\/p>\n\n

I really liked that the paper includes five case studies, one of which demonstrates a shortcoming\nof the approach (a quite common one however).<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/521674700683223041<\/a><\/p>\n"},{"title":"Paper notes: Interprocedural program analysis","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/17\/interprocedural-program-analysis\/"}},"updated":"2014-11-17T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/17\/interprocedural-program-analysis","content":"

I have been reading\/thinking about interprocedural (binary mostly) program\nanalysis lately. There are two ways to do it: a) function summaries produced\nin advance; b) inlining function bodies and (try to) do whole-program analysis.\nThe problem with a) is (possible) reduced accuracy, and with b) scalability.<\/p>\n\n

Have I missed something? Any pointers to relevant work?<\/p>\n\n

Program analysis Jedi @jvanegue<\/a>\nsuggested SLAM<\/a>\nand Daikon<\/a>.<\/p>\n\n

Relevant Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/514491405142863872<\/a><\/p>\n"},{"title":"Paper notes: A first step towards automated detection of buffer overrun vulnerabilities","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/12\/boon-paper\/"}},"updated":"2014-11-12T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/12\/boon-paper","content":"

Title: A first step towards automated detection of buffer overrun vulnerabilities (BOON)
\nPDF: 24dcd918253f6a44a43ac6612294397f.pdf<\/a><\/p>\n\n

I was looking at BOON lately and it has a nice integrated and reusable range\nsolver to check constraints for integer variables. Much faster and scalable\nthan an SMT solver, although imprecise since it is path insensitive.<\/p>\n\n

See BOON\u2019s implementation<\/a>\nfor the range solver; specifically files boon-1.0\/{newsolver.c, constraint-set.sml}<\/code>.<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/512231214153871360<\/a><\/p>\n"},{"title":"Paper notes: Undangle","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/11\/undangle-early-detection-of-dangling-pointers\/"}},"updated":"2014-11-11T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/11\/undangle-early-detection-of-dangling-pointers","content":"

Title: Undangle: early detection of dangling pointers in use-after-free\nand double-free vulnerabilities
\nPDF: 881dc45d33c7bfea662a0889918999e4.pdf<\/a><\/p>\n\n

Uses TEMU<\/a> to produce\nan execution\/allocations log which is then parsed offline; for each freed heap\nobject the pointers to it are labeled as dangling; taint propagation-like\ntechniques are used to track pointers.<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/505011997445193728<\/a><\/p>\n"},{"title":"Paper notes: Efficiently detecting all dangling pointer uses in production servers","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/10\/efficiently-detecting-dangling-pointer-uses\/"}},"updated":"2014-11-10T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/10\/efficiently-detecting-dangling-pointer-uses","content":"

Title: Efficiently detecting all dangling pointer uses in production servers
\nPDF: 5f11226846ef1fb1e447ca58fbba6d33.pdf<\/a><\/p>\n\n

Runtime detection by placing each allocated object on a new virtual page\n(like pageheap), but mapping multiple virtual pages to the same physical\npage avoiding physical memory depletion.<\/p>\n\n

Freed objects cause an mprotect on their page, so possible later uses of\nthe object cause an access violation in turn. Implemented as LLVM IR\ntransformation; tested via\nC -> IR -> transformations -> IR' -> C' -> gcc -O3<\/code> :)<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/499961355097866241<\/a><\/p>\n"},{"title":"Paper notes: Type-based memory allocator hardening notes","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/07\/type-based-memory-allocator-hardening-notes\/"}},"updated":"2014-11-07T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/07\/type-based-memory-allocator-hardening-notes","content":"

Internet Explorer\u2019s new g_hIsolatedHeap<\/code> mitigation is like a poor man\u2019s\ntype-safe memory reuse implementation. \u201cPoor man\u2019s\u201d since instead of real\ntype-safety, it specifies categories of \u201cdangerous\u201d objects that are placed\non the isolated heap. An example full implementation of type-safe memory\nreuse is Cling<\/a>,\na heap manager that restricts memory reuse to same-type objects.<\/p>\n\n

Of course\nFirefox\u2019s\nframe poisoning<\/a> (since 2010) also implements some type-safe memory reuse\nideas.<\/p>\n\n

Btw, the above frame poisoning blog post does not refer to Cling, but a\nmuch earlier paper<\/a>\non type-safe memory reuse.<\/p>\n\n

Relevant Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/498798680863145984<\/a><\/p>\n"},{"title":"Paper notes: Memory leak detection based on memory state transition graph","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/06\/memory-leak-detection-based-on-memory-state-transition-graph\/"}},"updated":"2014-11-06T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/06\/memory-leak-detection-based-on-memory-state-transition-graph","content":"

Title: Memory leak detection based on memory state transition graph
\nPDF: 9d850ea1ce88e3705bd40b56164a6f40.pdf<\/a><\/p>\n\n

Memory state transition graph (MSTG) nodes model heap objects\u2019 states; edges are\nannotated with path conditions (via symbolic execution); used for function\nsummaries and the leak detection algorithm.<\/p>\n\n

Implementation (just binaries, no source code) available at:\nhttp:\/\/lcs.ios.ac.cn\/~xuzb\/melton.html<\/a><\/p>\n\n

Relevant Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/490102227819053056<\/a><\/p>\n"},{"title":"Paper notes: Path and context sensitive inter-procedural memory leak detection","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/05\/path-context-sensitive-memory-leak-detection\/"}},"updated":"2014-11-05T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/05\/path-context-sensitive-memory-leak-detection","content":"

Title: Path and context sensitive inter-procedural memory leak detection
\nPDF: 44a45c88f524da1a62fbf91581d8ede9.pdf<\/a><\/p>\n\n

Models heap objects, tracks their state (not pointers to), inter-procedural analysis via
\nfunction summaries; solver for path feasibility. Straightforward.<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/487275885872312320<\/a><\/p>\n"},{"title":"Paper notes: A memory model for static analysis of C programs","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/04\/memory-model-static-analysis-c-programs\/"}},"updated":"2014-11-04T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/04\/memory-model-static-analysis-c-programs","content":"

Title: A memory model for static analysis of C programs
\nPDF: 44f93d2a09e3d91eca160b387db6cd8c.pdf<\/a><\/p>\n\n

Nice read; defines a region-based memory model that can describe C semantics\nand keep track of lvalue expressions; like a poor man\u2019s alias analysis.\nImplementation available as part of the clang analyzer.<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/483678143371550720<\/a><\/p>\n"},{"title":"Paper notes: Static program analysis assisted dynamic taint tracking","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2014\/11\/03\/static-program-analysis-assisted-paper\/"}},"updated":"2014-11-03T00:00:00+00:00","id":"https:\/\/argp.github.io\/2014\/11\/03\/static-program-analysis-assisted-paper","content":"

\n

Note:<\/em> A while back<\/a>\nI started tweeting notes on research papers I\u2019m reading. Gradually the notes became\nmore verbose, making Twitter a poor medium for them. So, I decided to start keeping\nthe notes here and tweet the links to the posts instead. I will start the\n\u201cpaper notes\u201d category with all the previous notes I have twitted so far.<\/p>\n<\/blockquote>\n\n

Title: Static program analysis assisted dynamic taint tracking for software vulnerability discovery
\nPDF: 1c943b679e1d0fa168f784a34eaee149.pdf<\/a><\/p>\n\n

Read that yesterday evening; very brief and underdeveloped for my taste.<\/p>\n\n

Original Twitter link:\nhttps:\/\/twitter.com\/_argp\/statuses\/478777665898700800<\/a><\/p>\n"},{"title":"Heap Exploitation Abstraction by Example - OWASP 2012","link":{"@attributes":{"href":"https:\/\/argp.github.io\/2012\/08\/17\/heap-exploitation-abstraction-owasp\/"}},"updated":"2012-08-17T00:00:00+00:00","id":"https:\/\/argp.github.io\/2012\/08\/17\/heap-exploitation-abstraction-owasp","content":"

This year\u2019s OWASP AppSec Research<\/a> conference took\nplace in Athens, Greece and we were planning to be there as participants.\nHowever, the day before the conference, Konstantinos Papapanagiotou (General Chair)\nasked if we could do a presentation to replace a cancelled talk. Myself and Chariton \nKaramitas (huku) agreed to help and spent around three hours preparing a talk on heap \nexploitation abstraction, a subject dear to us.<\/p>\n\n

\n\n<\/p>\n\n

Our talk was titled Heap Exploitation Abstraction by\nExample<\/a>\nand was divided into two main parts. In the first part we focused on presenting \nexamples of exploiting heap managers. Specifically, we talked about attacking \nthe FreeBSD kernel allocator (UMA), the Linux kernel allocator (SLUB) and the \njemalloc userland allocator.<\/p>\n\n

In the second part we started by finding the common elements of these three \nallocators and categorizing them into the following:<\/p>\n\n