<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Cybersec on Benny Simmonds</title>
    <link>https://www.bencode.io/tags/cybersec/</link>
    <description>Recent content in Cybersec on Benny Simmonds</description>
    <generator>Hugo -- 0.149.1</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 04 Jul 2021 21:25:37 +0000</lastBuildDate>
    <atom:link href="https://www.bencode.io/tags/cybersec/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Binary Similarity Analysis Technical Paper</title>
      <link>https://www.bencode.io/posts/binhunt/</link>
      <pubDate>Sat, 29 May 2021 22:46:47 +0000</pubDate>
      <guid>https://www.bencode.io/posts/binhunt/</guid>
      <description>&lt;p&gt;An academic paper I authored in May 2019, as part of studying &lt;em&gt;Reverse Engineering&lt;/em&gt; at UNSW.&lt;/p&gt;
&lt;h1 id=&#34;abstract&#34;&gt;Abstract&lt;/h1&gt;
&lt;p&gt;Extracting meaningful semantic differences between software binaries without source code is difficult. This is a challenging problem due to the overwhelming amount of syntactic noise that small changes can result in at the assembly level. Curiously when it comes to program semantics the &amp;ldquo;signal from the noise&amp;rdquo; can be distilled in a manner that is both static and processor agnostic, through the application of control flow and graph isomorphism analysis, symbolic execution and theorem proving. The graph isomorphism problem has no known polynomial time algorithm (i.e. is NP) making brute force approaches computationally infeasible. By blending various static analysis techniques and applying some generalisations, consider a novel approach to overcoming the computationally infeasibility of this problem domain with a view to binary difference analysis.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Exploiting Heap Allocators Technical Paper</title>
      <link>https://www.bencode.io/posts/heap/</link>
      <pubDate>Sat, 19 Oct 2019 18:31:14 +1000</pubDate>
      <guid>https://www.bencode.io/posts/heap/</guid>
      <description>&lt;p&gt;An academic paper I authored in October 2019, as part of studying &lt;em&gt;Modern Exploit Development&lt;/em&gt; at UNSW.&lt;/p&gt;
&lt;h1 id=&#34;abstract&#34;&gt;Abstract&lt;/h1&gt;
&lt;p&gt;Heap oriented exploits continue to be an ongoing threat, and have gained popularity post the stack smashing frenzy of the 90&amp;rsquo;s and early 00&amp;rsquo;s. Even so called safe languages (e.g. JavaScript, Java) remain vulnerable due to their underlying C/C++ implementations. Heap allocator designs and implementations, of which there are many, struggle to strike the balance between performance and security, performance often winning out to keep programs running as fast as possible. Two ingredients are needed for a successful heap exploit, the first a memory management error in the target program, and second an exploitable heap allocator implementation. Many countermeasures in mainstream allocators seen to date are often the result of knee-jerk reactions to exploits of the past, with patching occurring to existing designs. A large body of research exists around detecting, preventing or mitigating heap attacks.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
