llvm dev - Mar 2015 - [LLVMdev] Lifting ASM to IR

> On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:
>> Does there exist a tool that could lift a binary (assembly for some
>> supported target) to LLVM IR?  If there isn't, does this seem like
>> something that would be feasible?
There's plenty of variations on the idea: Revgen/S2E, Fracture, Dagger
(my own), libcpu, several closed-source ones used by pentest shops,
some that use another representation before going to IR (say
llvm-qemu),  and probably others still I forgot about.

Are you interested in a specific target / use case?
> http://llvm.org/devmtg/2013-04/bougacha-slides.pdf
> might be a starting point.
Note that after a hiatus I've been slowly revamping Dagger (more to
come), making the implementation parts of the slides tremendously
out-of-date (it doesn't help that, at the time, I was a kid with a
laptop and a dream - not to say I'm much more now).

For instance, the translation now re-uses the existing
instruction-selection patterns in LLVM as much as possible, rather
than hand-writing them.

Also note that, as opposed to the other projects, it's a for-fun
hobby, so you might want to investigate your options ;)

-Ahmed

On Thu, Mar 12, 2015 at 6:33 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>
wrote:
> > On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:
> >> Does there exist a tool that could lift a binary (assembly for
some
> >> supported target) to LLVM IR?  If there isn't, does this seem
like
> >> something that would be feasible?
>
> There's plenty of variations on the idea: Revgen/S2E, Fracture, Dagger
> (my own), libcpu, several closed-source ones used by pentest shops,
> some that use another representation before going to IR (say
> llvm-qemu),  and probably others still I forgot about.
>
> Are you interested in a specific target / use case?
>
I was thinking something along the lines of lifting a binary into IR and
spitting it out for a different processor.

Or maybe a decompiling tool of some kind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150312/49130ac4/attachment.html>

On 3/12/15 8:14 PM, Daniel Dilts wrote:
> On Thu, Mar 12, 2015 at 6:33 PM, Ahmed Bougacha
> <ahmed.bougacha at gmail.com <mailto:ahmed.bougacha at
gmail.com>> wrote:
>
>     > On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:
>     >> Does there exist a tool that could lift a binary (assembly for
some
>     >> supported target) to LLVM IR?  If there isn't, does this
seem like
>     >> something that would be feasible?
>
>     There's plenty of variations on the idea: Revgen/S2E, Fracture,
Dagger
>     (my own), libcpu, several closed-source ones used by pentest shops,
>     some that use another representation before going to IR (say
>     llvm-qemu),  and probably others still I forgot about.
>
>     Are you interested in a specific target / use case?
>
>
> I was thinking something along the lines of lifting a binary into IR and
> spitting it out for a different processor.
This is going to be extremely difficult. Imagine for example how this 
function would be compiled:

   struct Foo {
     void *v;
     int i;
     long l;
   };

   long bar(Foo *f) {
     return f->l;
   }

If we pick a particular target, and compile this function for that, then 
'foo' will have some offset into the struct from which it loads
'l'.
This is easy because we know the sizes of the struct's members, and the 
layout rules for structs on the target.

Now turn that around: given an offset into a struct for one target, 
what's the offset into the same struct on another target? We're stuck 
because we can't reconstruct from this offset what the sizes of v and i 
are individually; all we have is their sum (and that doesn't even take 
alignment issues into account).  This is because when we're looking at 
the binary we don't know, given that offset, that the two elements in 
front of it are a void* and an int.

Now, you might think that: "well, okay we'll just use the offsets from 
one target in the other target's binaries". But that isn't going to
work
either: what if void* isn't the same size between the two targets? And 
that's just the tip of the iceberg.

TL;DR: binary translation is a very difficult problem.


Jon
>
> Or maybe a decompiling tool of some kind.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded