Hex editors are a seriously undervalued learning tool. As a kid, I loved opening up the game files of stuff I was playing and see what I could tweak.
I’m not sure this particular editor could replace HxD for me - I’m not seeing process memory editing in its list of features. I’m glad to see the space is still getting love though.
So true! That was my introduction to binary format and serialization as a kid, probably didn't even knew what these words were back then. Or, when something crashed I think there used to be button -- "Debug" an it would open up Visual/Windows Debugger with assembly filling up the screen.
Yeah. I learned in primary school that I could bypass a password prompt in a simple program just by changing one conditional jump instruction to another (if password is wrong, success)
Thanks a lot for the love!
If you have any feature requests, face any problems or have any questions, please open an issue on my GitHub page and I'll make sure to look into it as soon as possible. There's also a Discord server linked at the top of the Readme
I used it for some work recently. First it's a bit sluggish, may be it's the way UI is built. Secondly, earching in the binary is very basic atm. https://hexed.it can search for a given value in lot more ways and also has some other features.
Defining data format as code is a very nice feature though.
Oh, looks neat. I've been looking for a cross-platform hex editor for simple editing (wxmedit kind of sucks on macos and had issues for a while now).
This seems to have some very powerful features, but sadly doesn't support trivial editing stuff. Like when you have a simple text file and need to do some light unicode or other encoding fixups.
Like "delete/remove selection" or "type in ascii replacements for these bytes one after the other".
But I mean it's open source, so if I somehow find the time I might add those.
This is a potential modern replacement for the 010 editor[1], which is kind of the standard hex editor for reverse engineering.
010 is great but also a bit dated[2] and clunky. I thought numerous times that a modern rewrite could be a nice project to work on. I'm happy that others tackled it! Kudos to the team.
One super cool feature would be if ImHex could read the 010 templates, but I'm not sure if that is legally OK. I'm not even sure if it would be morally OK, because I guess just as much work has gone into them as into the actual editor.
I like Oketa as well. Oketa, ImHex and HexFiend are all nice tools. Some folks swear by the radare suite as well. ImHex has the most features for fiddling with data structures and such.
Nice. The one simple, but incredibly useful feature I personally can't live without in hex editors is wildcard search like the one in 010 Editor. For instance, being able to search CB ?? FF and showing all matches
I wish they used Rizin[1] as a library to get the advantage of using mature analysis in addition to the simple disassembly, more architectures and formats, debugging, and decompilation plugins.
> Rizin is a fork of the radare2 reverse engineering framework with a focus on usability, working features and code cleanliness.
Interesting; is there some backstory I could read about that? I mean, the "code cleaniness" I bet is subjective, but I somehow thought radare2 was still under development
We have a FAQ[1] with this covered. Few examples of concrete steps are in the blog: changing the buildsystem and dependency handling [2], projects saving and loading [3], commands parsing [4], new intermediate language [5]. We also switched to using IDA's FLIRT signatures and added their generation. Types parsing and model was rewritten from scratch as well.
Seems the radare2 GitHub readme and website is so much clearer on what’s going on, you don’t even have a screenshot in your repo. For someone unfamiliar I don’t think I would chose your fork. Perhaps update the readme and site to have some images of what the product does. Also your “book” seems completely empty, better to not even link to it
Do all ImGui apps have text rendering this bad? I'm having trouble smoothly reading... any of the text, at least on Mac. It has a settings box, which allows you to change font size (but appears to do nothing), and a scaling option which ... just seems to make the artifacts bigger.
Switching to dark mode (by default it matched the system) made it slightly better just by virtue of having more contrast (and all the setting boxes actually have different coloured backgrounds that means you can tell where one ends and the other begins).
It would be nice to find a good replacement for 010.
I think there’s something off with the render scaling, because the pixels are enormous even when I set it to a non-fixed sized font (Monaco). I had to set 2x scaling and then it looked better but only because the text was enormous.
I recall this being something you had to pay attention to with imgui/glfw — probably just needs a small tweak.
I think there's just no single good answer for this. Up to 2560x1440 on a 27" screen I much prefer bitmap fonts. Above, for e.g. 3840x2160+ at the same physical size I think vector is better.
I used to prefer bitmap fonts too during the transition period. But after using vector fonts for years, it's hard to look at them now. I don't even use particularly high dpi screens.
Either way, I think for default the dev should just go with the norm (i.e. what is popular for the majority). Users can always change to bitmap fonts if they want.
They claim [1] the text rendering is "pixel-perfect" now in the default font. But anti-aliasing is on by default for custom-chosen fonts, maybe one of those will work better?
Looks maybe like the opposite, there's way too much smoothing. I don't mind pixel perfect fonts or even aliased text but these just look like an aggressive blur was applied to everything
If you're seeing it blurry, the problem is likely your browser scaling it. Try downloading the photo and viewing it in a viewer with a 1:1 pixel ratio, like MS Paint. Alternatively, if you're on Chrome, running this in the dev console might scale it back for you:
Mine first big project was also a hex editor I called Super Zap. I think Zap was already an existing hex editor. It's main use was hex editing disk sectors on the Apple II. After I finished it, I used it all the time. I still have the source code and executables!
On Arch Linux KDE X11 with 100% display scaling and 120 font DPI, whenever I pop the hex editor view out of the main window, it's missing a title bar by default, until I resize the popped-out view to around 2000 pixels tall.
This might have been a daily driver if whatever UI library being used wasn't so quirky and unfriendly. Oh well. Looks "leet" or whatever, which is obviously more important.
I think so; they're basically just some custom functionality around a filesystem image with all of the shared library dependencies and assets included, along with some wrapper functionality. Running appimages with `--appimage-help` shows what some of the available options are, including `--appimage-extract` to get all of the files installed.
That said, it's also probable that you can cut the size significantly by using `strip`; when you essentially statically link all of your dependencies, it turns out that there's quite a bit of low-hanging fruit with regards to eliminating dead code.
EDIT: trying this out, it looks like using `strip` actually corrupts the appimage and makes it unable to run. I guess there's something about the format that doesn't play nice with that, although I'm not sure exactly what.
> Next goal: CA$76.88 per month - I can pay all my monthly bills
This is why the open-source software is sad. The author will keep burning through his youthful energy in return for some words of appreciation (but much more issues and demands), and will at best quietly give up at some moment, or at worst freak out and have his colors/faker moment [0].
At the same time, products like this create the expectations that some types of software should be free (i.e. subsidized by the author's willingness to not have a life) and make it 10x harder for people like the author to turn their work into a revenue-generating business.
That said, if you have 16K stars on Github, you absolutely do have enough userbase to sell a paid premium edition and eventually grow it into your main job.
I work in videogames and we often use custom binary file formats, a HEX editor is very useful because, as an industry, we don't document anything and the code is often a car crash :)
What title are you referring to? I am guessing that title got edited and initially used partial header from github page "A Hex Editor for Reverse Engineers" cutting of second part "Programmers and people who value their retinas when working at 3 AM".
Hex editor can also be very useful for programmers when working with binary file formats. Implementing support for image and archive formats. Testing that your code outputs the thing you expected it to output or inspecting a file which your program fails to process because some other program included some unexpected option fields or something like that. It's sometimes even useful even when working with text fails, typically because they included some invisible symbols which you didn't expect or differentiating between similar looking unicode symbols.
How else are you supposed to debug misbehaving byte order markers and emojis and other U̷̼͌T̷͔̑F̷̤̂ ̴̯͗b̶̤̋l̵̜̈́a̸̭̚c̵͕̊k̶̦̅ ̶͓͆m̸͙̎a̴͖̿g̴̠͝i̸͛ͅc̸̡͌ in your "plain text"?
At work, I sometimes have to encode or decode binary data, to which I have full specs, and a hex editor is an extremely valuable tool.
A hex editor is to binary data what a debugger is to code, a packet analyzer is to networking, and an oscilloscope is to electronics. These tools can be used for reverse engineering, but it is certainly not their only purpose.
I don’t work with binary files much these days but I still use hex editors a lot just to debug any weird rendering glitches in terminal emulators. The ability to see the exact character codes being generated rather than the terminal emulators interpretation of them is invaluable. Though for that purpose hexdump is usually sufficient.
Back in the 90s, when I was working with binary data regularly, I’d have killed for something like ImHex.
If you're writing tools that generate spec-based binary files, you need a debugger that lets you examine generated files at the binary level. For instance, I don't think you can do any OpenType font tool engineering (as in, working on applications that generate fonts) without having a good hex editor to check whether the binary internals of your files are structured correctly.
I’m not sure this particular editor could replace HxD for me - I’m not seeing process memory editing in its list of features. I’m glad to see the space is still getting love though.