<div dir="ltr">Thanks for the reply. I was looking over the papers describing the respective projects you mentioned and it seems that from my limited understanding these systems tend to finesse the more complicated issues. s2e does not explicitly explore the code to generate the full code at one time and instead analyzes an execution trace tree thus avoiding the need for merge point analysis via phi functions (since it does symbolic execution I guess this makes sense). Revgen does not cope with the runtime code "closure" problem and BAP uses a custom probably lower level IR. <div><br></div><div>The main thing I don't understand about mapping machine code to SSA is that given that the control flow graph is not guaranteed to be static with both runtime generated code and indirect jumps how is it possible to specify the phi functions when the standard algorithm relies on these static graph like properties. </div><div><br></div><div>Thanks again,</div><div><br></div><div>Carter. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 23, 2016 at 11:30 PM, John Criswell <span dir="ltr"><<a href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Dear Carter,<br>
<br>
You should look at tools like s2e and Revgen (from EPFL) and BAP
(from CMU, I think). These projects convert binary code into LLVM
IR.<br>
<br>
The issues that you raise are somewhat orthogonal to conversion to
SSA form. Regardless of whether one is decompiling machine code
to an SSA-based IR or a non-SSA IR, one must deal with the
challenges of disassembly (if doing static decompilation),
self-modifying code, and control-flow graph reconstruction. Once
you get some sort of IR reconstructed, standard algorithms for
converting the IR into SSA form apply.<br>
<br>
Regards,<br>
<br>
John Criswell<div><div class="h5"><br>
<br>
<br>
On 1/23/16 10:00 AM, Carter Cheng via llvm-dev wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hi,
<div><br>
</div>
<div>Is decompilation possible in general to the SSA form for
binaries? I assume one has to make certain assumptions about
code in general to get tools like these to work. For example
if code like with dlsym or jit heap allocated functions can be
incorporated at runtime it would seem that in general it is
quite difficult to ascertain the boundaries of a basic block
and insert the correct phi functions for the predecessors
since one could have jumps from the new code into the middle
of the static code. This is already ignoring the problem of
self modification.</div>
<div><br>
</div>
<div>I haven't managed to find many references on the topic but
I am curious about what sorts of assumptions are made in
decompilation code recovery and general issues theoretical
issues about when it is possible to do. </div>
<div><br>
</div>
<div>Thanks in advance,</div>
<div><br>
</div>
<div>Carter,</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
<pre cols="72">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a href="http://www.cs.rochester.edu/u/criswell" target="_blank">http://www.cs.rochester.edu/u/criswell</a></pre>
</font></span></div>
</blockquote></div><br></div>