On 04/17/2014 11:08 AM, E.Robbins wrote:
On 17/04/2014 16:40 PM Bill Williams wrote:
Oh. One other thing--if you're trying to analyze PE files on Linux,
that's not presently going to work. It might be possible, if you have a
Linux system with the necessary Windows headers present and you know of
a replacement for the debug SDK, to coerce a Linux build of Symtab to
speak PE.

Thanks. We are indeed trying to analyse PE files in Linux. I didn't realise 
that this wasn't supported. When you say the debug SDK, do you mean some kind 
of MS VS debugger?

No, there's a Debug Information Access (DIA) SDK that's available and does a fair bit of symbol parsing for PE files that we then bake into Symtab form. Its accessibility and redistributability have been somewhat variable IIRC but if you have a non-Express version of Visual Studio, you have full access to MS SDKs last I checked.

You could probably pull the text section out via objdump or
similar and stuff it into a fake ELF file.

We'll have to think about that, but it's certainly an option in the short term 
I guess. We are mostly looking at malware so symbols are mostly useless, but we 
probably will need to know about linkage, the entry point etc etc.

Yeah, if you're concerned with malware, you'll probably want a custom CodeSource whether you're working on Linux or Windows.

I think I also have an
memory-backed CodeSource implementation floating around somewhere that
you could use as a starting point--as long as you can find the text
section and either don't care about symbols or can find them without
Windows headers, mocking up a CodeSource that speaks PE on Linux is a
simple matter of engineering.

What do you mean by a memory-backed CodeSource? We would be interested in 
anything that can help, though obviously we may decide it's too big a task.

The two CodeSource implementations we distribute are Symtab and Symlite based; both of these work with files on disk, as one does. For internal testing purposes, it's convenient to be able to splat a blob of code into memory and parse it, and the CodeSource implementation to do that is what I mean by "memory-backed".

It occurs to me that what you actually may want is a Windows implementation of SymLite--something that knows how to mmap in sections, read section headers and the entry point, and optionally can give you a lightweight representation of each symbol. That would then plug into the existing SymLiteCodeSource and should work seamlessly.

It's engineering we haven't done because
parsing PE on Linux is not of much use to Dyninst without a *very*
full-featured cross-format Symtab backing it, such that we could rewrite
PE files on Linux.

Fair enough... we are somewhat at odds with the goals of dyninst because we are 
doing static analysis and mostly use it for its control flow recovery which is 
very good, and to some extent for reading symbols too.

The obvious answer then is to use windows. Can the windows version of dyninst 
work over ELF binaries?

The Windows version doesn't speak ELF, though that's I think more practical than getting Linux Dyninst to speak PE fully. I haven't checked recently whether libelf/libdwarf build cleanly on Windows, but if they do then that's a pretty straightforward project; we'd build with libelf, libdwarf, and the dynElf/dynDwarf wrapper libraries, add the various ELF-reading source files to the build, and toss a mechanism into Symtab::openFile to check the file type and open things on the right path. (Note, straightforward does not mean low-effort; we'd almost certainly have to redesign some of the class structure so that the file type could be a runtime decision rather than a build-time one. But it's doable in principle.)

I think your best bet would be a cross-platform PE implementation of SymLite, though.

Thanks a lot,
Ed



--
--bw

Bill Williams
Paradyn Project
b...@cs.wisc.edu
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Reply via email to