Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Importing executable files with auto-detected format exports corrupted binaries #19

Open
rszibele opened this issue Mar 6, 2019 · 28 comments

Comments

Projects
None yet
@rszibele
Copy link

commented Mar 6, 2019

Describe the bug
If you import an ELF binary with the format as Executable and Linking Format (ELF) and then export that binary, it creates a corrupted binary that segfaults.

However, if you import it as "Raw binary" and manually select the language, then the exported file works as expected.

To Reproduce
Steps to reproduce the behavior:

  1. Import the cp ELF binary into your project (default settings).
  2. Right-Click it and click Export...
  3. Select Binary as the format.
  4. Export it.
  5. Make the exported binary executable.
  6. Run the exported binary.

Expected behavior
The exported binary should work instead of segfaulting (happens with multiple binaries that I've tested).

Screenshots
Default:
image
Import as Raw binary:
image

Environment (please complete the following information):

  • OS: Kubuntu 18.10
  • Ghira Version 9.0

Additional context
Happens with both i386 and x86_64 binaries.

@rszibele rszibele added the bug label Mar 6, 2019

@woachk

This comment has been minimized.

Copy link

commented Mar 6, 2019

Issue affects ARM binaries too.

@rszibele

This comment has been minimized.

Copy link
Author

commented Mar 6, 2019

Just tested it on Windows and it's the same story with PE executables. They also need to be imported raw, else you can't run them.
image

@rszibele rszibele changed the title Importing ELF files with format "Executable and Linking Format (ELF)" exports corrupted binaries Importing executable files with auto-detected format exports corrupted binaries Mar 6, 2019

@Ristovski

This comment has been minimized.

Copy link

commented Mar 6, 2019

Can confirm. The exported ls becomes ~3kb larger than the original.
Some binaries also end up with missing headers.

@Ristovski

This comment has been minimized.

Copy link

commented Mar 6, 2019

Note: Loading as Raw Binary does not seem to produce the same analysis/disassembly output at all.

The disassembly after analysis is missing various things ranging from functions not being disassembled to missing Xrefs.

It also appears to analyze the binary much faster than when imported as ELF indicating it is either unable to analyze is as thoroughly when loaded as a Raw Binary or just skips a bunch of analysis options which are enabled/supported only under ELF.

Thus, loading as Raw Binary should not be considered a workaround for this as the output differs.

@ghost

This comment has been minimized.

Copy link

commented Mar 7, 2019

The binary export is not intended to create a valid executable - there is no export for doing this. It simply dumps the memory blocks that exist within Ghidra void of any address placement information.

@Ristovski

This comment has been minimized.

Copy link

commented Mar 7, 2019

@gnooby22 Would be nice if there was a way to imitate the behavior when loading a binary as Raw Binary (which when exported creates a valid verbatim copy of the loaded program) but retaining all the analysis options when loading it as ELF.

One would expect that Export Program as Binary would create a valid executable when loaded as ELF as well.

This means that executables as of now can't be nicely patched like in IDA.

@bratao

This comment has been minimized.

Copy link

commented Mar 7, 2019

Yeah,
Working exported binaries is a very important feature for many workflows.

@Corallo

This comment has been minimized.

Copy link

commented Mar 8, 2019

Once I imported as Raw Binary what can I do to produce the same binary analysis of an ELF? At least to automatically show assembly code.

@Ristovski

This comment has been minimized.

Copy link

commented Mar 8, 2019

@Corallo It sadly does not seem to be possible as of now

@johnalanwoods

This comment has been minimized.

Copy link

commented Mar 20, 2019

Also have this issue.

When I make patches to apps, I can't export a binary without seg fault, nor does it make the change to the underlying binary referenced by the project.

@looterz

This comment has been minimized.

Copy link

commented Mar 31, 2019

Same issue here with every binary I have tested.

@johnalanwoods

This comment has been minimized.

Copy link

commented Mar 31, 2019

Does 9.0.1 fix this?

@najamelan

This comment has been minimized.

Copy link

commented Mar 31, 2019

@johnalanwoods Don't worry, it won't be long. Imagine all these poor agents at the NSA who can't work because their hacking toy is broken. They won't let this linger long. LOL

@Ristovski

This comment has been minimized.

Copy link

commented Mar 31, 2019

@najamelan it does not appear to be a bug

One of the devs (whose account is now deleted) mentioned this:

The binary export is not intended to create a valid executable - there is no export for doing this. It simply dumps the memory blocks that exist within Ghidra void of any address placement information.

I doubt this will be "fixed"

@johnalanwoods

This comment has been minimized.

Copy link

commented Apr 1, 2019

@Ristovski interesting. To me this would seem like a basic feature. The ability to edit the binary and run that binary independently of Ghidra. I’m shocked this is seen as normal behaviour. Even IDA does this.

@Ristovski

This comment has been minimized.

Copy link

commented Apr 1, 2019

@johnalanwoods I agree. I don't see why the binaries loaded as ELF should not export the same way they do when loaded as Raw Binary. I haven't looked into the bundled source code yet, but maybe this could be trivial to fix.

@ryanmkurtz

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2019

A few things to add:

  • This was not addressed in 9.0.1. The effort is most likely too large to appear in a patch release.
  • I'm changing this from a bug to an enhancement because while the feature isn't working as requested, it's working as documented (see help page for exporting files).
  • #154 is related, because the file offset to memory address mapping is lost during import. Keeping track of that mapping would be required to properly go back to file-form.

@ryanmkurtz ryanmkurtz added enhancement and removed bug labels Apr 1, 2019

@johnalanwoods

This comment has been minimized.

Copy link

commented Apr 1, 2019

Thank you for the clarification @ryanmkurtz.

It seems unusual to me that, as sophisticated as Ghidra is, it doesn't include this feature.

How much utility can there be without being able to generate an edited executable?

Anyway, not to worry.

Regards,
John

@valentinbreiz

This comment has been minimized.

Copy link

commented Apr 5, 2019

Same problem, works with raw binary, doesn't with auto detection.

@bernky

This comment has been minimized.

Copy link

commented Apr 8, 2019

So what are people supposed to do without the ability to export a working binary for windows? Re-write the program or? Isn't this the point of reversing an EXE or am I missing something that people are doing better than patching a working binary?

@johnalanwoods

This comment has been minimized.

Copy link

commented Apr 12, 2019

I agree with @bernky, there are things which can be done without export. Such as exfiltration of data and there is python scripting etc, but still the ability to export is very important.

@ertosns

This comment has been minimized.

Copy link

commented Apr 18, 2019

alright then, i can't finish my root-me assignments using ghidra, what i should do without export, use other tools, what is the point, this is high priority bug.

@Jest25

This comment has been minimized.

Copy link

commented May 5, 2019

Great find, almost lost my mind trying to figure it out.

@bernky

This comment has been minimized.

Copy link

commented May 6, 2019

alright then, i can't finish my root-me assignments using ghidra, what i should do without export, use other tools, what is the point, this is high priority bug.

they are considering this as an "Enhancement feature"

@johnalanwoods

This comment has been minimized.

Copy link

commented May 6, 2019

I just went back to IDA, at least I can export from it easily and I don’t have to run it inside 4 nested VMs to avoid myself being backdoored ;)

@johnalanwoods

This comment has been minimized.

Copy link

commented May 15, 2019

@johnalanwoods

This comment has been minimized.

Copy link

commented May 23, 2019

Does 9.0.4 fix this?

@ryanmkurtz

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

No, 9.0.4 is mostly a bug fix release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.