ImHex VS rizin

ImHex

“A Hex Editor for Reverse Engineers, Programmers and people who value their retinas when working at 3 AM.”

I actually used it not too long ago to inspect why a mp4 file wasn’t valid. The pattern language that they have is quite nice and having sections of the hex highlighted and being able to see what structures they represent and what data was on those structures was very useful!

https://github.com/WerWolv/ImHex

Just one note: Please use UI scaling; it's near impossible to read on a 150% 4k screen (much less on 100%). Unfortunately, young eyes don't last forever.

The UI looks very much like ImHex (https://imhex.werwolv.net/) is this a coincidence, or is it the standard ImGui look and feel?

I wish ImHex had a decompiler for Z80 as well, but this is much better.

I didn't use RemedyBG or Tracy, but I did try ImHex (https://github.com/WerWolv/ImHex) and it loaded 12% of the CPU because everything is being repainted 60 times per second. Heck, it even has an option to limit the FPS, which solves the CPU load a bit, but at the same time results in sluggish input because the event handling is tied to the drawing frequency.

So yes, the experience was not good, and I don't see what these tools would lose by using a proper GUI. I don't want every utility to drain my laptop battery like a decent video game.

ImGui is great if you already have a loop where everything is unconditionally redrawn every frame, but otherwise it's a really odd choice for an end-user application.

I now use ImHex after looking for years for a good one. It has a pattern language to provide highlighting.

https://imhex.werwolv.net/

ImGui is brilliant. I can highly recommend this hex editor built using it: https://github.com/WerWolv/ImHex

If you want a true Hex Editor (or better, Hex IDE), I strongly suggest you to take a look ad ImHex [1].

[1]: https://github.com/WerWolv/ImHex

I'd also like to throw https://github.com/WerWolv/ImHex in the mix here.

Documentation for AoE2 graphics formats have been enhanced and there is now a pattern file that you can use in imHex to explore the SLP file structure

I’ve heard really good things about https://github.com/WerWolv/ImHex but haven’t gotten enough experience to say for sure. Modern, made for reversing, and includes hooks for a disassembler.

Just for the record, for nicer inspection of files with such debug information, including compressed sections, and debuginfod support, Rizin[1] can be used, since starting from the 0.7.0 release[2] all of those were added.

[1] https://rizin.re

[2] https://github.com/rizinorg/rizin/releases/tag/v0.7.0

Rizin[1] is also able to uplift native code to the new RzIL, which is based on the BAP Core Theory[2] and is essentially an extension of SMT theories of bitvectors, bitvector-indexed arrays of bitvectors and effects[3].

[1] https://rizin.re/

[2] https://binaryanalysisplatform.github.io/bap/api/master/bap-...

[3] https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md

Everything Hiew can do, Rizin[1] can do too, and is completely free and open source[2] under LGPL3 license. Moreover, it supports more architectures, platforms, and file formats, as well as GUI in Qt - Cutter[3][4]. If something is missing in Rizin but presented in Hiew, please let us know by opening the issue with details.

[1] https://rizin.re

[2] https://github.com/rizinorg/rizin

[3] https://cutter.re

[4] https://github.com/rizinorg/cutter

This is precisely what we are trying to do at Rizin[1][2]. Though the primary goal of the tool/framework is static analysis. All that portability across OSes, their versions, platforms and architectures, etc is definitely hard. If anyone is interested in these subjects, all contributions are welcome. For example, check out our "RzDebug" label, marking debugging issues[3].

[1] https://rizin.re

[2] https://github.com/rizinorg/rizin

[3] https://github.com/rizinorg/rizin/labels/RzDebug

Okay, so, your comment about a "Dasher + Guitar Hero music theory/improvisation practice program" just sent me down a huge rabbit hole...

Well, rabbit hole(s) plural, I guess, most not directly related. :D

Largely because I made the "mistake" of looking at your HN profile & discovering you're also in NZ & we seem to have somewhat overlapping interests (and an affinity for "bacon" in account names, apparently), so, some thoughts[0]... :)

# Topic 1: Nissan Leaf VSP hacking

After reading your recent posts (https://ianrrees.github.io//2023/07/03/vsp-hacking.html & https://ianrrees.github.io//2023/08/05/voltage-glitch-inject...) on this topic & noting your remark about wanting to try reverse engineering a firmware image, I found the following thesis PDF (via a brief google search for `"reverse engineer" "firmware" "Renesas"`):

* "AUTOMOTIVE FIRMWARE EXTRACTION AND ANALYSIS TECHNIQUES" by Jan Van den Herrewegen https://etheses.bham.ac.uk/id/eprint/11516/1/VandenHerrewege...

Not really what I was anticipating finding but seems relevant to your interests--I don't think it was already in your resource list.

While the thesis addresses the Renesas 78K0 rather than the Renesas 78K0R, from a brief look at the "Flash Protection" PDF Application Note in your resource list it seems there's a large overlap.

Perhaps most significantly the author presents "novel methods" that combine bootloader binary analysis with constraint-based power glitching in an effort to improve on the results described in "Shaping the Glitch".

While I haven't read the entire 186 pages :D they theorize that using their approach extracting 8kB firmware might only take ~10 hours.

And, most helpfully, they even published their source code under the GPL here: https://github.com/janvdherrewegen/bootl-attacks

So, an interesting adjacent read even if it turns out not to be directly applicable to your situation.

Given I have an interest in & a little experience with firmware reversing my original thought was to maybe provide some hopefully helpful references that more generically related to firmware reversing but more specific is good too, I guess. :)

In terms of reverse engineering tooling, I've used Rizin/Cutter/radare2 previously: https://rizin.re https://cutter.re

On the CAN tooling/info front, you might be interested in taking a look at my "Adequate CAN" list which I originally wrote-up for a client a couple years ago: https://gitlab.com/RancidBacon/adequate-can

Some other probably outdated reverse engineering tooling links of mine: https://web.archive.org/web/20200119074540/http://www.labrad...

In terms of how to approach RE, other than just "getting started & digging in" & learning by doing, I've sometimes found it informative to read other people's firmware reverse engineering write-ups to learn about potentially useful approaches/tools.

Anyway, hopefully some of this is helpful!

[0] I have a tendency to be a little... "verbose" and/or "thorough" (depending on one's POV :) ) so I'll probably split this over a couple of comments, in case I run out of steam while writing and for topic separation.

See our FAQ[1] on why we forked. As three years passed and both projects are actively developed, the divergence has grown a lot since. We aim for exposing the proper API instead of relying just commands, see e.g. our new Python bindings and rz-bindgen[2]. We have completely different concept of projects, new intermediate language - RzIL[3], and many other things. And under the new organization Cutter is a first-class citizen, not an afterthought as before.

[1] https://rizin.re/posts/faq/

[2] https://rizin.re/posts/gsoc-2022-rz-bindgen/

[3] https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md

Rizin[1][2] provides basic diffing capabilities out of the box with the `rz-diff` tool. We plan to expose it in our GUI, Cutter, too, in the near future.

[1] https://rizin.re

[2] https://github.com/rizinorg/rizin

There are many different technical differences that accumulated over time - we save projects as a state snapshot, not a sequence of commands[1], we save types as semantically connected structures in a database that is guaranteed to be consistent[2], use better stack tracking for arguments and variables[3], not SP/BP/whatever, slowly migrate to a new generation of IL - RzIL instead of ESIL[4], provide standard libraries signatures out of the box in the FLIRT format[5], switched to a new way of parsing and processing commands[6], provide basefind, and many other small differences.

[1] https://rizin.re/posts/introducing-projects/

[2] https://github.com/rizinorg/rizin/tree/dev/librz/type

[3] https://github.com/rizinorg/rizin/releases/tag/v0.5.0

[4] https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md

[5] https://github.com/rizinorg/sigdb

[6] https://rizin.re/posts/rzshell/

For this kind of task, using low-level debugger tools is probably better. Rizin[1][2]/Cutter[3][4] could help. We also have GSoC participant this year who works hard on improving debuginfo and debugging support[5]. I personally also like Binary Ninja, they recently made their debugger stable enough[6].

[1] https://rizin.re/

[2] https://github.com/rizinorg/rizin

[3] https://cutter.re/

[4] https://github.com/rizinorg/cutter

[5] https://rizin.re/posts/gsoc-2023-announcement/

[5] https://binary.ninja/2023/05/03/3.4-finally-freed.html#debug...