[HN Gopher] Elfcat: Visualize ELF Binaries
___________________________________________________________________
Elfcat: Visualize ELF Binaries
Author : todsacerdoti
Score : 166 points
Date : 2021-06-22 11:51 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| setheron wrote:
| Love it. This is pretty useful to see how patchelf in NixOS
| works.
| MintPaw wrote:
| A browser based hex viewer? I guess Linux people jump from the
| command line to the browser because there's no standard GUI on
| Linux?
|
| Seems a bit complicated, would love to see better binary
| visualization tools on desktop.
| geraldcombs wrote:
| You could try Wireshark. Its primary focus is analyzing network
| packets, but it does support a few file formats and ELF is one.
| haswell wrote:
| Another way to frame this is that the primary viewing format is
| portable html, and can easily be viewed locally or shared with
| someone else or incorporated into a blog post, etc.
|
| The true value here is the backend and its ability to return
| data in a form that can be visualized, and the output format/UI
| can be adapted/enhanced as the project matures.
| gmadsen wrote:
| What is the complicated part? Modifying the gui?
| 7373737373 wrote:
| There's also https://binvis.io
| xvilka wrote:
| Veles[1], which is abandoned nowadays, sadly, is more
| powerful alternative.
|
| [1] https://github.com/codilime/veles
| IshKebab wrote:
| Yeah, if you just need a single page visualisation like this
| then HTML is hard to beat. It's easy, cross platform and you
| don't need any libraries to use it.
|
| Doing this with Qt or GTK would be much much more work.
| Especially if you're using Rust which doesn't have any really
| good GUI options yet.
| PennRobotics wrote:
| Two simple criticisms or potential misunderstandings:
|
| The three nulls in the load segment (between the code and data)
| are included in both the code and the data highlights as well as
| its own highlight, which is a bit unintuitive, as the start of
| the string looks to be /0/0/0Hello. It looks like these are
| supposed to be between spans like the other non-highlighted
| nulls, but they are included in a parent span, bin_segment0.
| (Issue submitted.)
|
| Also, I wish the arrow heads did not opaquely overlap the
| numbers. Adding opacity="0.3" to the svg tag fixes this for me.
|
| This is cool for a variety of reasons: It makes parsing a readelf
| output a bit easier, it's a nice/small/functional Rust demo (for
| Rust idiots like me), and the output can be redirected into html-
| based documentation easier than a command line tool's output.
| AlbertoGP wrote:
| Just tried it, does what it promises. It's more than a basic hex
| viewer because of the extra information being displayed when
| hovering with the mouse on the different bytes, and the arrows
| linking the pointers/offsets to their targets.
| Naac wrote:
| As a visual learner, this is fantastic.
|
| I do wish that that there would be a key explaining the color
| coding.
| PennRobotics wrote:
| Coral (#e99) -> Elf Header ID
|
| Medium Purple (#99e) -> Elf Header
|
| Light Salmon (#eb9) -> Program Header
|
| "Violet Orange Gradient" -> Executable and data, I think (It
| looks like this is copied to address 0x10000+0x80 and executed,
| but I'm not familiar with x86.)
|
| Violet (#f9f) -> Sections (symbol table, string table, etc.)
|
| Sky Blue (#9be) -> Section Headers
| jcranmer wrote:
| (I'm surprised this is written in Rust and doesn't use the object
| crate--did the author do this in part to learn how elf works?)
|
| Speaking of visualizing virtual memory, one of the things that I
| haven't seen a nice prior tool for is breaking down the memory
| map of a process on a per-section basis--/proc/ _pid_ /maps only
| tells which libraries are providing which sections. I've built
| something like that for my own needs, but it's the sort of thing
| that I would have expected would easily come out of some other
| tool.
| derefr wrote:
| (Not the author) I've learned to not get my hopes up about the
| capabilities of external format-parsing libraries when building
| tools like this (to the point of often not bothering to
| evaluate them for fit-for-purpose any more), as they often
| expose only a high-level fully-decoded representation that's
| unsuited to examination of "why" something decoded to what it
| did.
|
| As such, they often won't be of _any_ help in a situation where
| you're trying to use them to diagnose where exactly a corrupted
| piece of data is going wrong -- which is one of the biggest
| use-cases for such tooling!
| jcranmer wrote:
| I've been using object and gimli crates extensively, and I
| can assure that "expose only a high-level fully-decoded
| representation" is the exact opposite of what they do. In
| fact, my biggest criticism (for gimli in particular) is that
| they lack sufficient high-level representation.
|
| The object crate exposes all of the ELF types directly. The
| one thing it doesn't do is give you this from its format-
| agnostic object::read::File type, you have to start from
| object::read::elf::ElfFile instead. As a bonus, it also gives
| you all of the processor-specific defines so you don't have
| to look up what the value of, say, the x86-64 relocations
| are: https://docs.rs/object/0.25.3/object/elf/index.html#cons
| tant...
| derefr wrote:
| My point wasn't about whether you can get into to the
| nitty-gritty leaf nodes of complex structures in the fully-
| decoded data; it was about whether the representation it
| outputs losslessly represents unparseable data elements
| while still doing best-effort to decode what it can, such
| that you end up with a representation that was decoded "as
| much as possible" where the decoded parts can be used to
| figure out why the non-decoded parts didn't decode, while
| also not obscuring what the non-decoded parts "say".
|
| I'm using "high-level" here to mean "was successfully
| transformed through all the decoding/lexing/parsing/cross-
| reference stages", and "low[er]-level" to mean "failed to
| be transformed by some of those stages." Which is non-
| normative, I guess, but this sort of "layers of decoded-
| ness" representation _is_ what you expect from tools like
| Wireshark or binwalk.
| jcranmer wrote:
| Ah, I see what you mean now.
|
| Yes, object/gimli are also this kind of low-level.
| Basically, when you parse the file, you're not actually
| parsing the file, but you're parsing each element of the
| structure one bit of a time.
|
| So parsing FileHeader will make sure a) the data is
| correctly aligned [since it's UB in Rust to have
| underaligned data] and b) that the e_ident bits are
| actually the magic number for an ELF file. Want to list
| all the sections? That's when it's actually going to
| check that a) the section header offset actually points
| to valid data and b) the number of section headers exist
| and is sane, but again, it doesn't actually verify that
| the section headers themselves make any sense whatsoever.
| xvilka wrote:
| You could try to build it on top of Rizin[1][2] library. In
| particular see the `dm` commands and subcommands. Let us know
| if something is unclear or missing or doesn't work as you would
| expect.
|
| [1] https://rizin.re
|
| [2] https://github.com/rizinorg/rizin
| ohazi wrote:
| This is great. I wish every binary format had a visualizer like
| this. Or maybe even a generic tool that can take in descriptions
| of binary formats to create new annotations on the fly (like
| Wireshark).
|
| I've seen similar tools to annotate other binary formats like gpg
| and asn.1
|
| https://github.com/ConradIrwin/gpg-decoder
| gumby wrote:
| In a pre-graphics era, this is what I wrote objdump for.
|
| The original intent was simply debugging bfd while developing
| it, though people ended up using it for all sorts of things.
|
| I like Elfcat.
| gavinray wrote:
| Wait, are you insinuating that I am reading a comment by the
| author of objdump themselves?...
|
| Holy smokes, thank you! I like Elfcat.
|
| I can imagine the author is beaming right now. I would frame
| this comment on my desk were I them, I think.
| ohazi wrote:
| Thanks for writing objdump! I'm probably one of those people.
|
| The most recent thing I did with objdump was use it to patch
| in a signature that needed to be computed over the
| text/data/bss segments after compilation. This was for a bare
| metal embedded system, and being able to do this at the elf
| level (1) made it easier, and (2) allowed me to use the same
| setup for multiple targets that each had their own oddball
| binary/ihex conversion and flashing machinery.
| jk7tarYZAQNpTQa wrote:
| > Or maybe even a generic tool that can take in descriptions of
| binary formats
|
| Kaitai [1] isn't perfect, but maybe suits your needs.
|
| [1] https://kaitai.io/
| makapuf wrote:
| there was hachoir
| https://hachoir.readthedocs.io/en/latest/metadata.html
| lovasoa wrote:
| There is also kaitai struct that has an a very complete online
| IDE that I use for this kind of things: https://ide.kaitai.io/
|
| It works with ELF as well as many many other formats, and the
| online IDE is only a very small part of what you can do with it.
| ellis0n wrote:
| Great tools that have been looking for decades :)
| vyas45 wrote:
| This is so cool!
___________________________________________________________________
(page generated 2021-06-22 23:01 UTC)