Live data from Hacker News

ImHex – A Hex Editor

github.com

61–70 of 78 posts

Re: ImHex – A Hex Editor

#61

Ah my first assembler program was a Z80 hex editor <3

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!

Re: ImHex – A Hex Editor

#62
post #53
post #20

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. [1] https://github.com/rizinorg/rizin

> 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.

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

[2] https://rizin.re/posts/why-meson/

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

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

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

Re: ImHex – A Hex Editor

#63

The AppImage is 79MB. Are Appimages usually this huge, even for immediate mode GUI apps?

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.

Re: ImHex – A Hex Editor

#65
post #18

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 sett…

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?

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

Re: ImHex – A Hex Editor

#66
post #20

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. [1] https://github.com/rizinorg/rizin

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

Re: ImHex – A Hex Editor

#68
post #18

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 sett…

Yeah, and ironically it says "[for] people who value their retinas"..

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.

Re: ImHex – A Hex Editor

#69

Earlier quoted context omitted.

Yeah, and ironically it says "[for] people who value their retinas"..

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.

Re: ImHex – A Hex Editor

#70
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.

Post reply on HN