In the end of the 90s I was 11-12 years old and used this to crack a copy of the video game SiN. I didn't really know what I was doing, but followed random tutorials for generic game cracking. They guided me through the w32dasm disassember, finding code referencing the "input your cd key" string, finding related jmps jumping to this part of the code, noting the address, opening up the executable in hiew and mulling them out.
It worked! I thought I was a genius. Now I'm amazed how I almost randomly got it right.
Hiew is peak ergonomics, kinda like good orthodox file managers (FAR Manager/Total Commander). Hiew's color scheme is, obviously, Norton Commander's as well :-) One of the few Windows applications that make me keep a Windows VM.
I just found out about ImHex yesterday when I was trying to work out a save game format for an hold retro game. For my very basic needs it was great, and the diffing took came in very handy. Would be keen to see if I could make a pattern for the save game format somehow. Will be something I have to look into.
I tried it a few years ago as a free alternative to 010editor and it was a bit unstable. But I see it is under active development, so maybe the issues have been fixed.
ImHex has so many features. Very useful for ROM hacking, as it can display custom text table mappings. I haven't even looked into patterns and other features yet.
I have done several binary analyses as a hobby and never heard of Hiew and clones, how can I?!
(I tend to start with a standalone Python script which gets gradually customized over time. I don't even use a hex editor myself, and I just used xxd if I did really need hexdump for initial explorations. Of course I would comment that xxd output heavily in my editor, and that seems the best moment to use Hiew and clones.)
For displaying 0-31 in programs and scripts of my own, I add 64 and display that in inverse video.
The resulting glyph is the letter from the matching CTRL or ^ notation for that byte, but in a single character cell, and still distinct from a byte containing that letter.
So for instance, a NUL is value 0, which is CTRL+@ or ^@
But displaying ^@ screws up formatting, and displaying @ collides with byte value 64. Inverse video @ solves both, and doesn't need any special font. I do the same for DEL which is 127 displayed as inverse ?, but the ? is meaningful and adheres to the same rule because it's literally ^? not a placeholder for "no glyph" or "non-printing control byte"
Doesn't help you with configuring an editor but just describing a way to display those undisplayable bytes in a way that is actually meaningful & unambiguous and without caring what the font or even terminal type is. (ei: works the same in BASIC on a TRS-80 Model 100 or in bash on a xterm, or in c on windows, etc).
Unicode control pictures [1] are yet another alternative if you have a reasonable Unicode font and care more about reproducibility (e.g. formats can't be copied and pasted easily). In fact, monospace fonts with control pictures represented by those inverted glyphs would be the best of both worlds! There is no reason that their reference glyphs should be exactly replicated, after all.
I know what the font looks like, and I already said this doesn't help with configuring an editor. I wasn't trying to tell you to do anything or not do anything.
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.
Thank you for mentioning this. I’ve had the most success with 010 Editor for find-and-replace across very large binaries and text files (100MB - 4GB). It seems much more performant than other text editors, much more than even favorite ones close to my heart like Sublime.
Yes, for example, `p` commands for printing and `w` commands for writing, visual hex editor (`VP`), and bit-level editor modes. There is room for improvement, but I already used it to reverse unknown firmware formats, so it's usable in that regard.
You can even explore various histograms with `p=?` and `p==?` commands (they will print help for these).
I must say I am impressed with how far Cutter had come. I will need to try it out again. I am partial to BinaryNinja because it is written by folks I was colleagues with.
Sorry for the late answer. Yes, there is. We hoped a Keystone-based[1] plugin would be a better alternative since it's based on the LLVM code, but the project looks abandoned now[2].
- https://github.com/0xeb/pyhiew/tree/main/bin/pyhiew - https://github.com/0xeb/pyhiew/tree/main/bin/pyhiew - https://0xeb.wordpress.com/2010/08/21/introducing-pyhiew/