ImHex – A Hex Editor
github.com
github.com
Under the hood, Capstone use LLVM's TableGen as a source for descriptions of registers and opcodes. http://llvm.org/docs/TableGen/index.html
I've given ImHex a test run on an Amiga binary and it kind of works. However, the Amiga Hunk format (equivalent of ELF) is not recognized, and is interpreted as opcodes. Also there are issues with copper lists.
https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-h...
You will have to edit imgui.ini which is generated after launching the program once.
Another open source macOS one to consider.
But this has some nice features! For example, it can parse the executables, and show structures:
Disassembler supporting many different architectures ARM32 (ARM, Thumb, Cortex-M, aarch32) ARM64 MIPS (MIPS32, MIPS64, MIPS32R6, Micro) x86 (16 bit, 32 bit, 64 bit)
Just to start, along with a ton of other file parsing, etc.
This looks pretty cool. Compiling it needs a C++20 compiler and no small list of dependencies...but it’s cool.
There have been discussions here about modern C++ example code. Lots of projects that use C++11, C++14 and a few C++17 codebases are suggested, but I've not seen a recommendation for a C++20 codebase to study - this might be one.
> A Hex Editor for Reverse Engineers, Programmers and people that value their eye sight when working at 3 AM.
Or their announcement page (https://werwolv.net/projects):
> A Hex editor with data pattern support and many features useful for Reverse Engineers
Maybe "ImHex - A Hex Editor for Reverse Engineers" would be a better title?
The union of "reverse engineers" and "programmers" is just "programmers", and that basically means "a hex editor for people who use hex editors". No?
You should know better than to draw that equivalence, dang.
If someone wants to point out what about this hex editor makes it more suitable for reverse engineers than the median text editor, I'll happily edit the title. The point is there needs to be something.
There is a strong overlap, but it is still a different set of skills and different tools (ex: hex editor vs IDE)
I don't know if this editor offers a light mode. I hope it does. I love good hex editors, and this one looks very interesting. But light mode is a necessity for me because of my vision.
I have no quarrel with anyone who only wants to implement dark modes, it just means I won't be able to use their products.
And that is why AppImage (as dev of ReHex did[0]) is much better way to provide binary for Linux, than ZIPed static linked binary package.
Just trying to execute binary from release asset `ImHex_1.5.0_Linux.zip`[0] under Debian 10:
$ ./ImHex
./ImHex: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
$ ./ImHex
./ImHex: error while loading shared libraries: libcapstone.so.4: cannot open shared object file: No such file or directory
I like white background and bright color themes, as in I like my retina "burned". Does it has settings where you can choose your own color scheme or this tool is on the same par with all "cool kids" who think anyone not using dark mode is unworthy?
If dark mode is enforced, then me and a lot of other people are excluded from using it.
I'm in the middle, I prefer dark modes for my day to day work though.
It‘s commercial though.
For fancier visualizations of binaries, check out this thread:
https://www.reddit.com/r/ReverseEngineering/comments/k62yr6/...
I think that the difference in comfort when reading is that in the case of a book the light is reflected, instead of emitted, like in a monitor.
Recently I had a series of very intensive sessions with Ghidra, and jumping through hex code for hours was really hurtful, until I learn Ghidra has a dark mode (an ugly one, just colors inverted).
> error while loading shared libraries: libcapstone.so.4: cannot open shared object file: No such file or directory
Apt installed libcapstone, what am I missing?
Might require the dev libs
If anything, amber terminals were easier on the eyes. Or the white on black ones. Those were nice.
BTW, "Retina" doesn't necessarily mean OLED either. It's a trademark that Apple has applied to more LCDs, as recently as the iPhone 11.
I had the impression that pre-1980's screens were green for chemical reasons not for eye-strain optimization (?)
If you actually want easy on the eyes do what they actually did in the 80s... grey on dark blue.
Is AmigaOS 1.x default color scheme related to this?
But on my terminals, I do indeed prefer amber on black.
There is no evidence dark mode is better. In fact, human eyes don't have good night vision, we see best in daylight.
Light text on a dark background makes the eye work harder and open wider, since it needs to absorb more light. When this happens, the light letters can bleed into the dark background and cause halation. Our eyes focus better when the iris is narrow.
Additionally, most people are born with some form of astigmatism, a misshaped cornea that blurs vision. For people that have the worst forms of astigmatism, light text on dark backgrounds aggravates the condition. When looking at a light display, the iris closes more, decreasing the effect of the deformed cornea. When using a dark display the iris opens to receive more light and the deformation of the cornea makes halation worse.
On the flip side, dark mode helps with floaters, tiny fibers or spots that appear in a person's vision. These are caused by changes to the fluid in the eye which cause shadows to be cast on the retina. Floaters distort vision in light mode. This condition tends to increase with age.
Also, people with light sensitivity might be better served by a dark background.
I have found that dark mode works best in low light, 100% contrast can be harder to read with more eye strain, reading large amounts of text in dark mode is harder.
It is frustrating when people who work in IT don't take accessibility seriously. Not everybody is young and in perfect health. Both light and dark mode should be offered for accessibility reasons.
The screenshots sure are unkind on my presbyopic eyes, even when blown up to full size.