werwolv/imhex

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

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

Supporting

If you like my work, please consider supporting me on GitHub Sponsors, Patreon or PayPal. Thanks a lot!

Screenshots

More Screenshots

Features

Featureful hex view

• Byte patching
• Patch management
• Infinite Undo/Redo
• "Copy bytes as..."
  • Bytes
  • Hex string
  • C, C++, C#, Rust, Python, Java & JavaScript array
  • ASCII-Art hex view
  • HTML self-contained div
• Simple string and hex search
• Goto from start, end and current cursor position
• Colorful highlighting
  • Configurable foreground highlighting rules
  • Background highlighting using patterns, find results and bookmarks
• Displaying data as a list of many different types
  • Hexadecimal integers (8, 16, 32, 64 bit)
  • Signed and unsigned decimal integers (8, 16, 32, 64 bit)
  • Floats (16, 32, 64 bit)
  • RGBA8 Colors
  • HexII
  • Binary
• Decoding data as ASCII and custom encodings
  • Built-in support for UTF-8, UTF-16, ShiftJIS, most Windows encodings and many more
• Paged data view

Custom C++-like pattern language for parsing highlighting a file's content

• Automatic loading based on MIME types and magic values
• Arrays, pointers, structs, unions, enums, bitfields, namespaces, little and big endian support, conditionals and much more!
• Useful error messages, syntax highlighting and error marking
• Support for visualizing many different types of data
  • Images
  • Audio
  • 3D Models
  • Coordinates
  • Time stamps

Theming support

• Doesn't burn out your retinas when used in late-night sessions
  • Dark mode by default, but a light mode is available as well
• Customizable colors and styles for all UI elements through shareable theme files
• Support for custom fonts

Importing and Exporting data

• Base64 files
• IPS and IPS32 patches
• Markdown reports

Data Inspector

• Interpreting data as many different types with endianness, decimal, hexadecimal and octal support and bit inversion
  • Unsigned and signed integers (8, 16, 24, 32, 48, 64 bit)
  • Floats (16, 32, 64 bit)
  • Signed and Unsigned LEB128
  • ASCII, Wide and UTF-8 characters and strings
  • time32_t, time64_t, DOS date and time
  • GUIDs
  • RGBA8 and RGB65 Colors
• Copying and modifying bytes through the inspector
• Adding new data types through the pattern language
• Support for hiding rows that aren't used

Node-based data pre-processor

• Modify, decrypt and decode data before it's being displayed in the hex editor
• Modify data without touching the underlying source
• Support for adding custom nodes

Loading data from many different data sources

• Local Files
  • Support for huge files with fast and efficient loading
• Raw Disks
  • Loading data from raw disks and partitions
• GDB Server
  • Access the RAM of a running process or embedded devices through GDB
• Intel Hex and Motorola SREC data
• Process Memory
  • Inspect the entire address space of a running process

Data searching

• Support for searching the entire file or only a selection
• String extraction
  • Option to specify minimum length and character set (lower case, upper case, digits, symbols)
  • Option to specify encoding (ASCII, UTF-8, UTF-16 big and little endian)
• Sequence search
  • Search for a sequence of bytes or characters
  • Option to ignore character case
• Regex search
  • Search for strings using regular expressions
• Binary Pattern
  • Search for sequences of bytes with optional wildcards
• Numeric Value search
  • Search for signed/unsigned integers and floats
  • Search for ranges of values
  • Option to specify size and endianness
  • Option to ignore unaligned values

Data hashing support

• Many different algorithms available
  • CRC8, CRC16 and CRC32 with custom initial values and polynomials
    • Many default polynomials available
  • MD5
  • SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
  • Adler32
  • AP
  • BKDR
  • Bernstein, Bernstein1
  • DEK, DJB, ELF, FNV1, FNV1a, JS, PJW, RS, SDBM
  • OneAtTime, Rotating, ShiftAndXor, SuperFast
  • Murmur2_32, MurmurHash3_x86_32, MurmurHash3_x86_128, MurmurHash3_x64_128
  • SipHash64, SipHash128
  • XXHash32, XXHash64
  • Tiger, Tiger2
  • Blake2B, Blake2S
• Hashing of specific regions of the loaded data
• Hashing of arbitrary strings

Diffing support

• Compare data of different data sources
• Difference highlighting
• Table view of differences

Integrated disassembler

• Support for all architectures supported by Capstone
  • ARM32 (ARM, Thumb, Cortex-M, AArch32)
  • ARM64
  • MIPS (MIPS32, MIPS64, MIPS32R6, Micro)
  • x86 (16-bit, 32-bit, 64-bit)
  • PowerPC (32-bit, 64-bit)
  • SPARC
  • IBM SystemZ
  • xCORE
  • M68K
  • TMS320C64X
  • M680X
  • Ethereum
  • RISC-V
  • WebAssembly
  • MOS65XX
  • Berkeley Packet Filter

Bookmarks

• Support for bookmarks with custom names and colors
• Highlighting of bookmarked region in the hex editor
• Jump to bookmarks
• Open content of bookmark in a new tab
• Add comments to bookmarks

Featureful data analyzer and visualizer

• File magic-based file parser and MIME type database
• Byte type distribution graph
• Entropy graph
• Highest and average entropy
• Encrypted / Compressed file detection
• Digram and Layered distribution graphs

YARA Rule support

• Scan a file for vulnerabilities with official yara rules
• Highlight matches in the hex editor
• Jump to matches
• Apply multiple rules at once

Helpful tools

• Itanium, MSVC, Rust and D-Lang demangler based on LLVM
• ASCII table
• Regex replacer
• Mathematical expression evaluator (Calculator)
• Graphing calculator
• Hexadecimal Color picker with support for many different formats
• Base converter
• Byte swapper
• UNIX Permissions calculator
• Wikipedia term definition finder
• File utilities
  • File splitter
  • File combiner
  • File shredder
• IEEE754 Float visualizer
• Division by invariant multiplication calculator
• TCP Client/Server
• Euclidean algorithm calculator

Built-in Content updater

• Download all files found in the database directly from within ImHex
  • Pattern files for decoding various file formats
  • Libraries for the pattern language
  • Magic files for file type detection
  • Custom data processor nodes
  • Custom encodings
  • Custom themes
  • Yara rules

Modern Interface

• Support for multiple workspaces
• Support for custom layouts
• Detachable windows

Easy to get started

• Support for many different languages
• Simplified mode for beginners
• Extensive documentation
• Many example files available on the Database
• Achievements guiding you through the features of ImHex
• Interactive tutorials

Pattern Language

The Pattern Language is the completely custom programming language developed for ImHex. It allows you to define structures and data types in a C-like syntax and then use them to parse and highlight a file's content.

• Source Code: Link
• Documentation: Link

Database

For format patterns, libraries, magic and constant files, check out the ImHex-Patterns repository.

Feel free to PR your own files there as well!

Requirements

To use ImHex, the following minimal system requirements need to be met.

Important

ImHex requires a GPU with OpenGL 3.0 support in general. There are releases available (with the -NoGPU suffix) that are software rendered and don't require a GPU, however these can be a lot slower than the GPU accelerated versions.

If possible at all, make ImHex use the dedicated GPU on your system instead of the integrated one (especially Intel HD GPUs are known to cause issues).

• OS:
  • Windows: Windows 7 or higher (Windows 10/11 recommended)
  • macOS: macOS 11 (Big Sur) or higher,
  • Linux: "Modern" Linux. The following distributions have official releases available. Other distros are supported through the AppImage and Flatpak releases.
    • Ubuntu 22.04/23.04
    • Fedora 36/37
    • RHEL/AlmaLinux 9
    • Arch Linux
• CPU: x86_64 (64 Bit)
• GPU: OpenGL 3.0 or higher
  • Intel HD drivers are really buggy and often cause graphic artifacts
  • In case you don't have a GPU available, there are software rendered releases available for Windows and macOS
• RAM: 256MB, more may be required for more complicated analysis
• Storage: 100MB

Installing

Information on how to install ImHex can be found in the Install guide

Compiling

To compile ImHex on any platform, GCC (or Clang) is required with a version that supports C++23 or higher. On macOS, Clang is also required to compile some ObjC code. All releases are being built using latest available GCC.

Note

Many dependencies are bundled into the repository using submodules so make sure to clone it using the --recurse-submodules option. All dependencies that aren't bundled, can be installed using the dependency installer scripts found in the /dist folder.

For more information, check out the Compiling guide.

Contributing

See Contributing

Plugin development

To develop plugins for ImHex, use the following template project to get started. You then have access to the entirety of libimhex as well as the ImHex API and the Content Registry to interact with ImHex or to add new content.

• ImHex Plugin Template

Credits

Contributors

• iTrooz for getting ImHex onto the Web as well as hundreds of contributions in every part of the project
• jumanji144 for huge contributions to the Pattern Language and ImHex's infrastructure
• Mary for her immense help porting ImHex to MacOS and help during development
• Roblabla for adding MSI Installer support to ImHex
• Mailaender for getting ImHex onto Flathub
• Everybody else who has reported issues on Discord or GitHub that I had great conversations with :)

Dependencies

• Thanks a lot to ocornut for their amazing Dear ImGui which is used for building the entire interface
  • Thanks to epezent for ImPlot used to plot data in various places
  • Thanks to Nelarius for ImNodes used as base for the data processor
  • Thanks to BalazsJako for ImGuiColorTextEdit used for the pattern language syntax highlighting
• Thanks to nlohmann for their json library used for configuration files
• Thanks to vitaut for their libfmt library which makes formatting and logging so much better
• Thanks to btzy for nativefiledialog-extended and their great support, used for handling file dialogs on all platforms
• Thanks to danyspin97 for xdgpp used to handle folder paths on Linux
• Thanks to aquynh for capstone which is the base of the disassembly window
• Thanks to rxi for microtar used for extracting downloaded store assets
• Thanks to VirusTotal for Yara used by the Yara plugin
• Thanks to Martinsos for edlib used for sequence searching in the diffing view
• Thanks to ron4fun for HashLibPlus which implements every hashing algorithm under the sun
• Thanks to mackron for miniaudio used to play audio files
• Thanks to all other groups and organizations whose libraries are used in ImHex

License

The biggest part of ImHex is under the GPLv2-only license. Notable exceptions to this are the following parts which are under the LGPLv2.1 license:

• /lib/libimhex: The library that allows Plugins to interact with ImHex.
• /plugins/ui: The UI plugin library that contains some common UI elements that can be used by other plugins

The reason for this is to allow for proprietary plugins to be developed for ImHex.

imhex's Issues

Customize location of data directories

Similair to #46, it would be nice to modify the location where the patterns include and magic folders are searched.

This could be achieved by either a command line flag or an environment variable

GUID should be parsed by spec

GUID or UUID actually has a spec, it is not just 16bytes interpret in a specific way:
https://tools.ietf.org/html/rfc4122

And although in my experience sometimes it is violated with some homebrew GUID generation (hello Unreal Engine), overall it still worth to parse it by spec and optionally display raw anyway with caveats.
Recommendations:

1. Parse normally by spec
2. In options (later down the line), add 2 directives that control this behavior:
   a) Parse all 16bytes chunk as GUIDs
   b) Highlight GUID data out of spec in the Interprter (for example, red tint or bg)

or just go straight for b) in general.

CMAKE: libmagic is not part of the cmake script

CMakeLists.txt does not contain a check for the magic lib.

Feature Request: Support for user-defined character encodings

Since you're taking feedback and this hex editor is geared more towards reverse engineering, it may be a good idea to offer this suggestion. There's a need among game modders for a hex editor that supports non standard text encodings, but hardly any viable tools that satisfy this.

Text Encoding?

You know, how byte 0x41 maps to the text character "A". However, this assumes this data structure abides by the ASCII standard.
All hex editors support this in some way.

There's a lot of different ways to interpret bytes after 0x7F, depending on the encodings (often called code pages). Some of these encodings would even use 2 bytes per character (and then 3 when we added emoji, etc) because 256 characters just ain't enough. One of these encodings is UTF-8. For the sake of the argument, I'll call these standard character encodings.
Many hex editors support these or a smaller portion of them out of the box.

Then, there's the completely arbitrary character encodings, seen in Teletext transmissions, some early printer formats, video games, and eastern asian computers. They don't abide by ASCII or any existing established encoding, because the designers prioritized something else, like using a partial font (with rarely used symbols thrown out) and fitting it into a limited video memory, then starting the count from whatever is the first character as 00. This practice still lives on to this day. I'll call these the user-defined character encodings, and they'll be the main subject of my feature request.

Existing approaches to user-defined character encodings

Character Sets (010 Editor)

010 Editor has a bunch of standard character encodings, both single byte (which it calls "simple") and double byte ("complex", which are hardcoded). Exclusively for single byte encodings, it allows editing, exporting and importing the characters sets as csv files.
The csv of a 010 Editor Character Set is a comma separated 16*16 array that represents all possible 256 characters from 0x00 to 0xFF. In each cell, the UTF-8 code for the character meant to interpret that character value is written in the 0xABCD format. For example, one of its customizable character sets that assign the euro symbol ( U+20AC ) to 0x80 will have 0x20AC in the first cell of the ninth line.
A cell can have -1 as its value to tell 010 Editor to leave it blank and/or not overwrite the last used character there.

0x0000,0x0001,0x0002,0x0003,0x0004,0x0005,0x0006,0x0007,0x0008,0x0009,0x000A,0x000B,0x000C,0x000D,0x000E,0x000F, 0x0010,0x0011,0x0012,0x0013,0x0014,0x0015,0x0016,0x0017,0x0018,0x0019,0x001A,0x001B,0x001C,0x001D,0x001E,0x001F, 0x0020,0x0021,0x0022,0x0023,0x0024,0x0025,0x0026,0x0027,0x0028,0x0029,0x002A,0x002B,0x002C,0x002D,0x002E,0x002F, 0x0030,0x0031,0x0032,0x0033,0x0034,0x0035,0x0036,0x0037,0x0038,0x0039,0x003A,0x003B,0x003C,0x003D,0x003E,0x003F, 0x0040,0x0041,0x0042,0x0043,0x0044,0x0045,0x0046,0x0047,0x0048,0x0049,0x004A,0x004B,0x004C,0x004D,0x004E,0x004F, 0x0050,0x0051,0x0052,0x0053,0x0054,0x0055,0x0056,0x0057,0x0058,0x0059,0x005A,0x005B,0x005C,0x005D,0x005E,0x005F, 0x0060,0x0061,0x0062,0x0063,0x0064,0x0065,0x0066,0x0067,0x0068,0x0069,0x006A,0x006B,0x006C,0x006D,0x006E,0x006F, 0x0070,0x0071,0x0072,0x0073,0x0074,0x0075,0x0076,0x0077,0x0078,0x0079,0x007A,0x007B,0x007C,0x007D,0x007E,0x007F, 0x20AC,0xFFFD,0x201A,0x0192,0x201E,0x2026,0x2020,0x2021,0x02C6,0x2030,0x0160,0x2039,0x0152,0xFFFD,0x017D,0xFFFD, 0xFFFD,0x2018,0x2019,0x201C,0x201D,0x2022,0x2013,0x2014,0x02DC,0x2122,0x0161,0x203A,0x0153,0xFFFD,0x017E,0x0178, 0x00A0,0x00A1,0x00A2,0x00A3,0x00A4,0x00A5,0x00A6,0x00A7,0x00A8,0x00A9,0x00AA,0x00AB,0x00AC,0x00AD,0x00AE,0x00AF, 0x00B0,0x00B1,0x00B2,0x00B3,0x00B4,0x00B5,0x00B6,0x00B7,0x00B8,0x00B9,0x00BA,0x00BB,0x00BC,0x00BD,0x00BE,0x00BF, 0x00C0,0x00C1,0x00C2,0x00C3,0x00C4,0x00C5,0x00C6,0x00C7,0x00C8,0x00C9,0x00CA,0x00CB,0x00CC,0x00CD,0x00CE,0x00CF, 0x00D0,0x00D1,0x00D2,0x00D3,0x00D4,0x00D5,0x00D6,0x00D7,0x00D8,0x00D9,0x00DA,0x00DB,0x00DC,0x00DD,0x00DE,0x00DF, 0x00E0,0x00E1,0x00E2,0x00E3,0x00E4,0x00E5,0x00E6,0x00E7,0x00E8,0x00E9,0x00EA,0x00EB,0x00EC,0x00ED,0x00EE,0x00EF, 0x00F0,0x00F1,0x00F2,0x00F3,0x00F4,0x00F5,0x00F6,0x00F7,0x00F8,0x00F9,0x00FA,0x00FB,0x00FC,0x00FD,0x00FE,0x00FF,

It's obviously limited because of the lack of support for encodings that use more than 1 byte per character.

Thingy Table Files (Thingy)

These were used by romhacking communities to deal with retro game modding.
They consist of text files that contain entries separated by newlines for each character.
Each entry is the hex value (not case sensitive) for the byte(s) value in big endian, then the equal sign, then the actual character(s), and finally a newline. Any entry that doesn't follow this is ignored. Representing the character for the "equal" sign can be done with 03==

Some custom versions of this used a tabulation instead of the equal sign as a separator, but it wasn't used as much.
Table files have the extension .tbl and are supported by some "special" romhacking-focused hex editors such as Tinke, WindHex and Thingy. The problem is that most of these are obsolete, closed source and not under active development anymore.

00=A
01=B
02=C
10=あ
3F=!

Occasionally, games will resort to some compression techniques for the text like byte pair encoding, often called within romhacking circles "dual tile encoding (DTE)" or "multi tile encoding (MTE)" (imprecise terminology, but DTE is exclusively used when two characters are encoded with one byte, and for the lowest layer if it's recursive)
Or things like so-called control codes, markdown tags in binary forms that tell the game where to stop parsing text ("end" control code) or add newlines, waits for user prompts, timers, sound effects, instructions for different text colors, fonts and sizes...
This can also be represented with tables.

# this is a comment
# byte pair encoding (mte)
8500=Hello
8501=You got 
8502=ight

# byte pair encoding (dte)
A0=ed
A1=ng
A2=..

# control codes
FE=\n
FF=\e
FC00=[color:default]
FC01=[color:red]
FC02=[color:yellow]
FA=[wait_user]

One main flaw in the implementations seen in previous hex editors with Thingy TBL support was that, in the process of filling the 16*16 array with character values, any unfilled characters would be replaced with a placeholder character which can't be customized, such as a period or an interrogation mark or whatever.

Some notes about previous hex editors with support for this:

• Considering the Thingy TBL file format didn't include conditions how it needs to be formatted, and it's a text file, users picked whatever code pages to save them. Some hex editors are hardcoded to only accept specific encodings (like ASCII, or Shift-JIS) but a couple have the more welcome option to pick which encoding to parse the table as, similar to LibreOffice's handling of csv files.
• Some hex editors with support for standard character encodings will include the user defined character encoding as a toggle rather than by default ("Use TBL")
• In regards to byte pair encoding and user keyboard input in the text field, many of these hex editors just type the "uncompressed" word rather than using the DTE/MTE bytes, unless a "DTE mode" is toggled on that behaves similarly to a Japanese IME (writing text outside the editor then pressing return, that's when it's inserted (overwrite as always, of course) into the text field with the DTE/MTE in mind.) or accepts copy pasting.

abcde Table Files

A refinement of the Thingy Table File format that standardizes it more and adds some more esoteric features. It's meant more for text dumping utilities (that extract and reinsert the text into the game binary following a table file in this newer format, and a configuration file for the text data location and pointer formats), but there are some additions worth mentioning. Note that this abcde comes with a readme that goes into this in much more detail than I ever could.

• It's mostly retro-compatible with Thingy Table Files.
• HAS TO BE UTF-8. Of course, the Byte Order Mark (which is optional) will be ignored when parsing the abcde TBL file.
• Comments now have to be prefixed with #
• The characters <> are reserved and can no longer be included, because of the newly added support for multi-table files. Maybe this can be solved by adding escape characters \< or turning off multi-table support?

Its new concepts:

A standardized way to mark the end control code character meant to stop the parsing of the current string.

# FF is the end control code
/FF=[END]

Support for binary values.
Useful when dealing with games that use less than 8 bits to transcribe characters, either of fixed length (like Battle of Olympus on NES which used 5 bits for all characters. abcde included examples based on it) or variable length (Huffman compression is one of the more known worthwhile applications of this, and one such implementation would display texts encoded using it in plain text)
It requires an anchor point offset to start interpreting text from, and an explicit end control code in binary.
Might be challenging to implement in a hex editor, though I saw some unpublished attempts by some romhackers to program hex editors which display the hex field using BINARY rather than hexadecimal. Maybe the text output could be added to the pattern data viewer instead?

# binary values are prefixed by %
# huffman coding wikipedia page example used here
%111= 
%010=A
%000=E
%1101=F
%1010=H
%1000=I

Support for multiple tables.
Some games, instead of coding different values for both upper-case and lower-case characters, had them share the same value, and added a "table switch control code" to change between them. This was used for Latin characters (A/a) or Japanese kana (あ/ア) quite often, but was also used to pick between 2 sets of punctuation and symbols. To this date, there's no hex editor to date which can handle this use case. Here's an example of a hypothetical game implementation:

Internal Data:
h(§2)ello! (§1)m(§2)y name is (§1)erdrick t(§2)he(\n)
d(§2)ragonmaster.(\e)
Output:
Hello! My name is ERDRICK The
Dragonmaster.

Some key observations here:

• The game has two sets, first one is for all caps, second one is for lowercase characters. In abcde tables, these sets are defined just like with normal tables, but as 2 tables in succession preceded each by a line with @FirstSet and @SecondSet
• The game has a default set, the first. It's used in the very beginning, or after some characters/control codes like the line break here. In abcde tables, this will be the first set present in the table file, so FirstSet.
• These sets can be explicitly called with control codes. (§2) forces lower case characters. These are the table switch control codes. In abcde tables, they are defined with a line preceded by ! and including a "table ID" (which set to use) and a "match type" (when to go back to the default set)

In our example, assuming (§2) uses the byte value 02 in hexadecimal, and likewise (§1) is 01, and the line break is 0A, the abcde table will be something like:

# switch to SecondSet and never switch back unless it hits §1, or unless it hits a line break
!02=,<@SecondSet>:$01,<@SecondSet>:$0A

or, alternatively:

# switch to FirstSet and never switch back (condition 0)
!01=,<@FirstSet>,0
# switch to SecondSet and never switch back unless it hits a line break
!02=,<@SecondSet>:$0A

Some games have kanji characters they call from an additional font. For example 8200 would call the first character (ID: 00), and would display 今 so this could be represented in two different ways:

• using the features of a normal thingy table, so 8200=今
  OR
• add a new set to the table, called @kanji1 (of course taking care to name the main set, @main or something)
• include under it 00=今
• include in the @main table the following !82=,<@kanji1>:1 The value 1 means (make exactly 1 match in the kanji1 table, then fall back. Why this? Some games like Secret of Mana's Japanese version will have similar syntax but read a fixed amount of characters from 1 to 5 depending on the control code, so it will be from 1 to 5 matches then...)

This multiple table support is also very useful for variables.
There's all kinds of control code that tell the game to wait X frames, display character portrait X out of a hundred or so, play sound effect X, and so on. With the older Thingy table format, you'd have to write 256 different entries just to catch all possible values for EACH control code.

FA00=[Sound_00]
FA01=[Sound_01]
FA02=[Sound_02]
# ...
FAFF=[Sound_255]

Whereas you could use the syntax this way:

00=A
01=B
02=C
!FA=<[Sound]>,1
# Output for FA00 will be: [Sound]($00), NOT [Sound]A

Search feature for user-defined character encodings

This is actually implemented in WindHex32 as "Relative Search". It's a way to quickly analyze a binary file and try and detect text data that might be using a custom encoding, as long as:

• Its characters in this unknown character set are ordered with no gaps
• Search query only includes the characters [A-Za-a-z0-9] or wildcard characters that don't assume the character's nature (whitespace, letter, number, capital, etc)
• Search query is 3 characters or more

The standalone utility monkeymoore adds the ability to include user input for the character set (a list of the characters as they appear in the font, and likely the encoding), this allows for searching text in languages other than English, such as European languages and Japanese, as long as the characters in the search query are included in order in the set and no character appears twice.

The results of a relative search operation is a list of possible search results and their custom encodings. The user can then confirm which one is the more correct, and save it as a user-defined character encoding to view the rest of the file with (although it will be lacking, especially punctuation and whitespace until the user manually adds them back to the character set definition aka table or character set)

Closing words

As a feature, it's very in demand, and I'm surprised how many attempts were made that went nowhere, and seeing how much reinventing the wheel there was compelled me to write this wall of text.
Even the bare minimum Thingy TBL support with no DTE/MTE support is very rare, even among hex editors that pride themselves on being as comprehensive as possible when it comes to supporting encodings, so it's not like there's a high barrier to entry to instantly become the best hex editor at game modding (already up there with the pattern viewer).
Going the extra mile for the latter details will be very interesting for anyone interested in Huffman.

I hope it sparks your interest and I'd be very grateful if it came to happen. Thanks a lot for reading all of this.

P.S. Imgui doesn't seem to support non English languages all that well, so you might be interested in Unifont as a fallback font to cover about everything else. I'll look for other attractive alternatives for pixel fonts.

Job

Hi

CTRL + F, CTRL + G don't work in "Hex Editor", crash after entering an empty string in Search->Hex

Hello. I found several bugs in ImHex.

1. CTRL + F, CTRL + G don't work in "Hex Editor"
2. If open Edit->Search->Hex and enter (null string) - ImHex crashed
   

PKGBUILD for Arch

Hi, first of all: very nice project!
We need a good cross platform hex editor and this is a great one!

I have prepared a PKGBUILD so it can be uploaded on AUR:

pkgname=imhex-git
pkgver=r183.5915525
pkgrel=1
url='https://github.com/WerWolv/ImHex'
arch=('i686' 'x86_64')
pkgdesc='A Hex Editor for Reverse Engineers and Programmers'
license=('GPL2')
depends=('glm' 'glfw' 'file' 'openssl' 'capstone' 'llvm' 'llvm-libs' 'nlohmann-json' 'python3')
makedepends=('git')
conflicts=(imhex)
provides=(imhex)
source=('git+https://github.com/WerWolv/ImHex.git' 'imhex')
md5sums=('SKIP' 'cc704bc8db518dbf16197e3a0a9b94ad')

pkgver() {
  cd ImHex
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

build() {
  mkdir -p build
  cd build
  cmake ../ImHex -DCMAKE_INSTALL_PREFIX=/usr
  make -j
}

package() {
  install -D -m755 imhex ${pkgdir}/usr/bin/imhex
  cd build
  install -D -m755 ImHex ${pkgdir}/usr/bin/ImHex
}

There is also a little bash script called imhex, so imgui.ini is saved in $HOME/.local/share/ImHex (I don't know if this path can be changed from C++):

#! /bin/sh

SETTINGS_FOLDER=$HOME/.local/share/ImHex
mkdir -p $SETTINGS_FOLDER
cd $SETTINGS_FOLDER
/usr/bin/ImHex

[FR] Theme color setup/template

Yes, I've read the description. I could strongly argue a few points here but it is pointless. What isnt pointless is a choice if visual data representation and I figured it is already valued here. Colors scheme is part of it, some people prefer lighter colors due to physical limitations/issue, whatever.

runtime_error: Failed to initialize GLFW

ImHex/build on  master via 喝 v3.19.1 took 6s 
❯ ./ImHex                                                                      
Glfw Error 65544: Wayland: Failed to connect to display
terminate called after throwing an instance of 'std::runtime_error'
  what():  Failed to initialize GLFW!
[1]    419447 abort (core dumped)  ./ImHex

I'm using Xorg, openbox, Xfce.

ImHex/build on  master via 喝 v3.19.1 
❯ neofetch                                                                  
                   -`                    user@userArch 
                  .o+`                   ━━━━━━━━━━━━━ 
                 `ooo/                   〻 Arch x86_64 
                `+oooo:                  〻 5.9.11-arch2-1 
               `+oooooo:                 〻 1157 (pacman) 
               -+oooooo+:                〻 Openbox 
             `/:-:++oooo+:               〻 2285MiB / 16001MiB (14%) 
            `/++++/+++++++:              〻 1 hour, 25 mins 
           `/++++++++++++++:             CPU〻 AMD Ryzen 5 3600X (12) @ 3.8GHz  
          `/+++ooooooooooooo/`           CPU Usage〻 4% 
         ./ooosssso++osssssso+`          GPU〻 NVIDIA GeForce GTX 1660 SUPER 
        .oossssso-````/ossssss+`         GPU Driver〻 NVIDIA 455.45.01 
       -osssssso.      :ssssssso.        Disk (/)〻 65G / 261G (26%) 
      :osssssss/        osssso+++.       Host〻 ROG Strix GA15DH_G15DH 1.0 
     /ossssssss/        +ssssooo/-       Terminal〻 tilix 
   `/ossssso+/:-        -:/+osssso+-     Locale〻 en_US.UTF-8 
  `+sso+:-`                 `.-/+oso:
 `++:.                           `-/+/                           
 .`                                 `/

Cannot run on VMware Windows 10 20H2 guest

Hi,

When I tried to run ImHex 1.4.0 on VMware Windows 10 20H2 guest, it exited immediately with the following error message:

Glfw Error 65542: WGL: The driver does not appear to support OpenGL
terminate called after throwing an instance of 'std::runtime_error'
  what():  Failed to create window!

It can run on Windows 10 20H2 host and it seems useful!

libLLVMDemangle.so

Is it possible to make the dependency optional? I am trying to package this for @openSUSE and I can't find the dependency. As I ran into many broken links for other distributions, I think it may be deprecated.

Hex Editor navigation broken in 1.5.0/Windows

I have no navigation cursor.
Win7x64

[Roadmap] Any plan to support MOS6502 disassembly (already in capstone) ?

Everything is in the title :)

Thanks !

Compile errors with gcc-10 and python2.7 develop packages installed

installing python3 dev package helps. Would be nice to either add this to cmake or to the readme.

In file included from /usr/include/python2.7/Python.h:88,
                 from /home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:8:
/usr/include/python2.7/unicodeobject.h:534:24: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
  534 |     register PyObject *obj,     /* Object */
      |                        ^~~
/usr/include/python2.7/unicodeobject.h:553:24: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
  553 |     register PyObject *obj      /* Object */
      |                        ^~~
/usr/include/python2.7/unicodeobject.h:575:29: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
  575 |     register const wchar_t *w,  /* wchar_t buffer */
      |                             ^
/usr/include/python2.7/unicodeobject.h:593:23: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
  593 |     register wchar_t *w,        /* wchar_t buffer */
      |                       ^
In file included from /usr/include/python2.7/Python.h:97,
                 from /home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:8:
/usr/include/python2.7/stringobject.h:173:24: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
  173 |     register PyObject *obj, /* string or Unicode object */
      |                        ^~~
/usr/include/python2.7/stringobject.h:174:21: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
  174 |     register char **s,  /* pointer to buffer variable */
      |                     ^
/usr/include/python2.7/stringobject.h:175:26: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
  175 |     register Py_ssize_t *len /* pointer to length variable or NULL
      |                          ^~~
/home/mgerhardy/dev/ImHex/source/views/view_disassembler.cpp: In member function ‘virtual void hex::ViewDisassembler::createView()’:
/home/mgerhardy/dev/ImHex/source/views/view_disassembler.cpp:221:30: error: ‘CS_ARCH_M68K’ was not declared in this scope; did you mean ‘CS_ARCH_MAX’?
  221 |                         case CS_ARCH_M68K:
      |                              ^~~~~~~~~~~~
      |                              CS_ARCH_MAX
/home/mgerhardy/dev/ImHex/source/views/view_disassembler.cpp:222:30: error: ‘CS_ARCH_TMS320C64X’ was not declared in this scope
  222 |                         case CS_ARCH_TMS320C64X:
      |                              ^~~~~~~~~~~~~~~~~~
/home/mgerhardy/dev/ImHex/source/views/view_disassembler.cpp:223:30: error: ‘CS_ARCH_M680X’ was not declared in this scope; did you mean ‘CS_ARCH_MAX’?
  223 |                         case CS_ARCH_M680X:
      |                              ^~~~~~~~~~~~~
      |                              CS_ARCH_MAX
/home/mgerhardy/dev/ImHex/source/views/view_disassembler.cpp:224:30: error: ‘CS_ARCH_EVM’ was not declared in this scope; did you mean ‘CS_ARCH_ARM’?
  224 |                         case CS_ARCH_EVM:
      |                              ^~~~~~~~~~~
      |                              CS_ARCH_ARM
[ 38%] Building CXX object CMakeFiles/ImHex.dir/libs/ImGui/source/imgui_draw.cpp.o
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp: In function ‘PyObject* hex::createStructureType(std::string, PyObject*)’:
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:116:31: error: ‘PyUnicode_AsUTF8’ was not declared in this scope; did you mean ‘PyUnicode_Type’?
  116 |             auto memberName = PyUnicode_AsUTF8(PyTuple_GetItem(item, 0));
      |                               ^~~~~~~~~~~~~~~~
      |                               PyUnicode_Type
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp: In static member function ‘static bool hex::LoaderScript::processFile(std::string_view)’:
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:151:43: error: ‘__argv’ was not declared in this scope
  151 |         Py_SetProgramName(Py_DecodeLocale(__argv[0], nullptr));
      |                                           ^~~~~~
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:151:27: error: ‘Py_DecodeLocale’ was not declared in this scope
  151 |         Py_SetProgramName(Py_DecodeLocale(__argv[0], nullptr));
      |                           ^~~~~~~~~~~~~~~
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp: In lambda function:
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:167:20: error: ‘PyModuleDef’ does not name a type; did you mean ‘PyModule_New’?
  167 |             static PyModuleDef ImHexModule = {
      |                    ^~~~~~~~~~~
      |                    PyModule_New
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:171:45: error: ‘ImHexModule’ was not declared in this scope
  171 |             auto module =  PyModule_Create(&ImHexModule);
      |                                             ^~~~~~~~~~~
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:171:28: error: ‘PyModule_Create’ was not declared in this scope; did you mean ‘PyModule_Check’?
  171 |             auto module =  PyModule_Create(&ImHexModule);
      |                            ^~~~~~~~~~~~~~~
      |                            PyModule_Check
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp: In static member function ‘static bool hex::LoaderScript::processFile(std::string_view)’:
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:176:10: error: invalid user-defined conversion from ‘hex::LoaderScript::processFile(std::string_view)::<lambda()>’ to ‘void (*)()’ [-fpermissive]
  176 |         });
      |          ^
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:156:42: note: candidate is: ‘constexpr hex::LoaderScript::processFile(std::string_view)::<lambda()>::operator PyObject* (*)()() const’ (near match)
  156 |         PyImport_AppendInittab("_imhex", []() -> PyObject* {
      |                                          ^
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:156:42: note:   no known conversion from ‘PyObject* (*)()’ {aka ‘_object* (*)()’} to ‘void (*)()’
In file included from /usr/include/python2.7/Python.h:134,
                 from /home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:8:
/usr/include/python2.7/import.h:54:65: note:   initializing argument 2 of ‘int PyImport_AppendInittab(const char*, void (*)())’
   54 | PyAPI_FUNC(int) PyImport_AppendInittab(const char *name, void (*initfunc)(void));
      |                                                          ~~~~~~~^~~~~~~~~~~~~~~
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:181:44: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
  181 |             auto sysPath = PySys_GetObject("path");
      |                                            ^~~~~~
[ 41%] Building CXX object CMakeFiles/ImHex.dir/libs/ImGui/source/imgui_widgets.cpp.o
[ 44%] Building CXX object CMakeFiles/ImHex.dir/libs/ImGui/source/imgui_demo.cpp.o
make[2]: *** [CMakeFiles/ImHex.dir/build.make:381: CMakeFiles/ImHex.dir/source/views/view_disassembler.cpp.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet....
make[2]: *** [CMakeFiles/ImHex.dir/build.make:173: CMakeFiles/ImHex.dir/source/helpers/loader_script_handler.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/ImHex.dir/all] Fehler 2
make: *** [Makefile:103: all] Fehler 2

Drag and drop is crashing the hex editor

The GIF explains the issue

OS: Windows 10 (2004)

No HiDPI support

I tried to use this because I value my eyesight but it backfired due to the lack of HiDPI support and now my eyes hurt.

Your friends for Windows are:

• MonitorFromWindow: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-monitorfromwindow
• GetDpiForMonitor: https://docs.microsoft.com/en-us/windows/win32/api/shellscalingapi/nf-shellscalingapi-getdpiformonitor
• ImGuiIO::DisplayFramebufferScale

Non functional under Windows

Did you even run it once under Windows?

It opens, console window stays behind it (compile it in UI mode).

Open File in menu doesn't work at all.

[Bug] Inspector dies abruptly at the end of the binary data

Happens often:

Are there any macos binary packages available for download?

Does it support macos now? I saw only linux and windows binary packages under releases.

Add expressions to the pattern language

I'm trying to reverse engineer a file format which has some length-prefixed strings at some point, which are encoded as such:

struct PString {
    u32 length;
    u8 string[length / 12];
};

(I don't know why 12, this format is weird like that :P)

It would be nice to be able to use simple arithmetic expressions in the size of an array rather than just variables so I could express this struct in the pattern language. I've seen there's already #15 open for expressions in variable placements, but that looked a bit more complex and also didn't cover array sizes.

And thank you for making this, I'm finding it very useful!

[FR] Output style could use some consistency

For example, Data Inspector:

There are 3 different ways to indicate invalid data. It is not a big deal but hurts "at the glance" readabilty.

I dont know how to get the current offset of file.

Im trying to use your patterns and I dont know how to get the current offset of the file.

Use SUBSYSTEM:WINDOWS when making the Windows build

You should use the SUBSYSTEM;WINDOWS parameter to MSVC so that it doesn't open a console window before opening the actual window

Build error on Fedora 33 (magic.h: No such file or directory)

While working on #47, I stumbled upon the following build error:

[ 44%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_pattern.cpp.o
/ImHex/source/views/view_pattern.cpp:12:10: fatal error: magic.h: No such file or directory
   12 | #include <magic.h>
      |          ^~~~~~~~~

I'm also getting the same build error on my bare metal Fedora 33 system (outside the Docker container, that is).

Cusutomize location of `imgui.ini`

It would be nice to modify the location where the imgui.ini file wil be saved.
Either a environment variable or a command line option would be a good choice to configure the location.

The location of the file can be modified by changing the IniFilename pointer of the ImGuiIO struct before any call to NewFrame().

32bits build

Hi

this is looks really good but seems ImHex released only for 64bits , is it possible to provide a 32bits build for windows ?

Feature request: Specify base address

Hi, I would like to be able to specify base address of loaded file.
i.e. File is downloaded from a RAM of CortexM4 (0x20000000). Being able to specify base address, navigation would be easier.

Command line option support

I am surprised that no file can be passed on the command line to be loaded.
please support this :)

v1.4.0 "File->Open File" dialog does not appear

Using latest release and trying to open a file doesn't bring up the dialog.

No log on the console.

Running on Debian testing.

Not sure if I should open a separate ticket as feature request for this, but it would be sweet to open a file from the command line.

Thanks a lot for the tool.

Compile errors with gcc-10 and python3.9 develop headers

this time i'm getting compile errors with the python 3.9 dev package installed.

/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp: In static member function ‘static bool hex::LoaderScript::processFile(std::string_view)’:
/home/mgerhardy/dev/ImHex/source/helpers/loader_script_handler.cpp:151:43: error: ‘__argv’ was not declared in this scope
  151 |         Py_SetProgramName(Py_DecodeLocale(__argv[0], nullptr));
      |                                           ^~~~~~
[ 55%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_help.cpp.o
make[2]: *** [CMakeFiles/ImHex.dir/build.make:173: CMakeFiles/ImHex.dir/source/helpers/loader_script_handler.cpp.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet....
make[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/ImHex.dir/all] Fehler 2
make: *** [Makefile:103: all] Fehler 2

Feature Request: Wayland support

Currently, when ImHex is ran with glfw-wayland, it gives a notable amount of errors regarding window position retrieval/setting. I've even faced crashes when doing random things in a not very reliably reproducible way (I've had one after I clicked "Open File" and another when I was resizing the hex editor). I'm willing to test more if needed.

Here's an output containing both the usual errors, and the specific error that led to the crash on the file open:

Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
[...a lot more of the same...]
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position setting not supported
Glfw Error 65544: Wayland: Window position setting not supported
xdg_wm_base@9: error 3: xdg_surface must not have a buffer at creation
Glfw Error 65544: Wayland: Window position retrieval not supported
Glfw Error 65544: Wayland: Window position retrieval not supported

It would be nice to have ImHex account for a wayland environment and not use unsupported features, if possible.

To any other glfw-wayland users, the only workaround I found is to install glfw-x11 (and remove glfw-wayland) to force ImHex to run in XWayland.

enhancement: conditional field / algebaric data type / tagged union

something like a field in a struct with predicates about previous variable.

enum TypeTag : u8{
    U32 = 1,
    ARRAY = 2
}
struct Variable {
    TypeTag tag;
    u32 u32Value if tag==TypeTag.U32;
    u32 length if tag==TypeTag.ARRAY;
    Variable elements[length] if tag==TypeTag.ARRAY; // or pointer to array
}

that may help parsing of byte streams with a bit more complex structures with branching (like some simplified version of MessagePack, Protocol Buffer...) (but they're more complicated, e.g. the type tag is in bitfield, and needs more advanced way to spedcify how to parse a variable int, etc.)

ImHex Icon and Banner need a overhaul

As the project's getting more and more attention, I feel like it's time for a proper icon (that wasn't just taken from iconshock) and a proper banner (that wasn't just made in GIMP in 2 minutes)

Icon: 72x72px
Big Icon (for my Website): 256x256px
Banner: 1280x640px

Ideas, concepts and generally feedback are highly welcomed!

Open file doesn't work with Release 1.4 on Windows 10 1803

The File Open dialog does not show up, no matter if ImHex was started as admin or normal user.

Mac support request

Is there any plan to support mac os?

I've tried some build and got this.

[  2%] Building CXX object CMakeFiles/ImHex.dir/source/window.cpp.o
[  5%] Building CXX object CMakeFiles/ImHex.dir/source/main.cpp.o
[ 13%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/crypto.cpp.o
[ 13%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/patches.cpp.o
[ 13%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/math_evaluator.cpp.o
[ 16%] Building CXX object CMakeFiles/ImHex.dir/source/helpers/loader_script_handler.cpp.o
[ 19%] Building CXX object CMakeFiles/ImHex.dir/source/lang/lexer.cpp.o
[ 22%] Building CXX object CMakeFiles/ImHex.dir/source/providers/file_provider.cpp.o
[ 27%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_hexeditor.cpp.o
[ 27%] Building CXX object CMakeFiles/ImHex.dir/source/lang/evaluator.cpp.o
[ 33%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_pattern.cpp.o
[ 36%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_pattern_data.cpp.o
[ 36%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_hashes.cpp.o
[ 38%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_information.cpp.o
[ 41%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_help.cpp.o
[ 44%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_tools.cpp.o
[ 47%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_strings.cpp.o
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/window.cpp:1:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/window.hpp:3:10: fatal error: 'concepts' file
      not found
#include <concepts>
         ^~~~~~~~~~
[ 50%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_disassembler.cpp.o
[ 52%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_bookmarks.cpp.o
[ 58%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_patches.cpp.o
[ 58%] Building CXX object CMakeFiles/ImHex.dir/source/views/view_data_inspector.cpp.o
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/main.cpp:1:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/window.hpp:3:10: fatal error: 'concepts' file
      not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/providers/file_provider.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/file_provider.hpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/lang/evaluator.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/evaluator.hpp:5:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/helpers/patches.cpp:3:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/helpers/crypto.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/lang/lexer.cpp:24:10: error: no template named
      'optional' in namespace 'std'
    std::optional<u64> parseInt(std::string_view string) {
    ~~~~~^
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/helpers/patches.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/lang/lexer.cpp:234:41: error: no matching
      constructor for initialization of 'std::string_view' (aka 'basic_string_view<char>')
                auto integer = parseInt(std::string_view(&code[offset], end));
                                        ^                ~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string_view:229:5: note:
      candidate constructor not viable: no known conversion from 'char *' to
      'std::__1::basic_string_view::size_type' (aka 'unsigned long') for 2nd argument; dereference the
      argument with *
    basic_string_view(const _CharT* __s, size_type __len) _NOEXCEPT
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string_view:223:5: note:
      candidate constructor not viable: requires 1 argument, but 2 were provided
    basic_string_view(const basic_string_view&) _NOEXCEPT = default;
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string_view:238:5: note:
      candidate constructor not viable: requires single argument '__s', but 2 arguments were provided
    basic_string_view(const _CharT* __s)
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string_view:220:5: note:
      candidate constructor not viable: requires 0 arguments, but 2 were provided
    basic_string_view() _NOEXCEPT : __data (nullptr), __size(0) {}
    ^
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/providers/file_provider.cpp.o] Error 1
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_patches.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_strings.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_data_inspector.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/helpers/loader_script_handler.cpp:5:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_information.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_hashes.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_disassembler.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_pattern_data.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_pattern_data.hpp:7:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/pattern_data.hpp:7:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/libs/ImGui/include/imgui_memory_editor.h:230:23: warning:
      flag ' ' results in undefined behavior with 'c' conversion specifier [-Wformat]
        ImGui::Text("% *c   ", s.AddrDigitsCount, ' ');
                     ~^~~
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/helpers/math_evaluator.cpp:10:10: fatal error:
      'numbers' file not found
#include <numbers>
         ^~~~~~~~~
1 error generated.
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_pattern_data.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_pattern_data.hpp:7:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/pattern_data.hpp:9:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
1 error generated.
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_bookmarks.cpp:3:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
make[2]: *** [CMakeFiles/ImHex.dir/source/helpers/crypto.cpp.o] Error 1
make[2]: *** [CMakeFiles/ImHex.dir/source/helpers/math_evaluator.cpp.o] Error 1
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_hexeditor.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_hexeditor.hpp:6:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/libs/ImGui/include/imgui_memory_editor.h:230:23: warning:
      flag ' ' results in undefined behavior with 'c' conversion specifier [-Wformat]
        ImGui::Text("% *c   ", s.AddrDigitsCount, ' ');
                     ~^~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_help.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_help.hpp:7:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/pattern_data.hpp:7:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/libs/ImGui/include/imgui_memory_editor.h:230:23: warning: 2 errors generated.

      flag ' ' results in undefined behavior with 'c' conversion specifier [-Wformat]
        ImGui::Text("% *c   ", s.AddrDigitsCount, ' ');
                     ~^~~
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/lang/lexer.cpp.o] Error 1
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_strings.cpp.o] Error 1
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_data_inspector.cpp.o] Error 1
1 error generated.
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_help.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_help.hpp:7:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/pattern_data.hpp:9:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_patches.cpp.o] Error 1
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_hashes.cpp.o] Error 1
1 error generated.
1 error generated.
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/window.cpp.o] Error 1
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_bookmarks.cpp.o] Error 1
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_disassembler.cpp.o] Error 1
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_pattern.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_pattern.hpp:6:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/pattern_data.hpp:7:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/libs/ImGui/include/imgui_memory_editor.h:230:23: warning:
      flag ' ' results in undefined behavior with 'c' conversion specifier [-Wformat]
        ImGui::Text("% *c   ", s.AddrDigitsCount, ' ');
                     ~^~~
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_pattern.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_pattern.hpp:6:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/pattern_data.hpp:9:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/lang/evaluator.cpp.o] Error 1
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_information.cpp.o] Error 1
1 warning and 1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_pattern_data.cpp.o] Error 1
1 error generated.
1 warning and 1 error generated.
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_tools.cpp:7:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
make[2]: *** [CMakeFiles/ImHex.dir/source/helpers/loader_script_handler.cpp.o] Error 1
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_help.cpp.o] Error 1
1 error generated.
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/source/views/view_hexeditor.cpp:1:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/views/view_hexeditor.hpp:13:
In file included from /Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/lang/pattern_data.hpp:9:
/Users/benjioh5/Coding/hobby/4_Contribution/ImHex/include/providers/provider.hpp:6:10: fatal error:
      'concepts' file not found
#include <concepts>
         ^~~~~~~~~~
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_tools.cpp.o] Error 1
1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/main.cpp.o] Error 1
1 warning and 1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_hexeditor.cpp.o] Error 1
1 warning and 1 error generated.
make[2]: *** [CMakeFiles/ImHex.dir/source/views/view_pattern.cpp.o] Error 1
make[1]: *** [CMakeFiles/ImHex.dir/all] Error 2
make: *** [all] Error 2

I think Apple clang 12.0.0 doest not support C++17 std::optional and C++20 features fully. Is there any support plan on Mac OS after apple clang supports C++20 featrues?

Zero length arrays

I am working with a file format that uses the same structure for many things,
this can lead to variables that indicate arrays of length 0 / no array for that element.
ImHex will crash as soon as it encounters such an array.

It would be awesome if ImHex would skip reading arrays of size 0.

example files.zip

//setting the length to 0 with a variable will crash ImHex
//manually setting the length to 0 will create a array of length one

struct ZeroArray{
	u8 size1;
	u8 size2;
	
	//size1 will cause a crash: [terminate called after throwing an instance of 'std::bad_optional_acces']
	u8 array[size2];
	u8 a2[0];
};

ZeroArray data @0x00;

Version: 1.4.0 & 1.5.0
Os: Windows

feature request

I just finding hex editor yesterday and saw your ImHex in the gallery thread of ImGui.
Great !

It will be more convenience if these features are implemented for the pattern.

1. null-terminated string like this:

s8 string[];

2. variable array size

struct tmp
{
    s8 arraySize;
    s8 arr[arraySize];
};

3. tree view of pattern data

Some suggestions and a question

Not sure where to put this other than an issue. If this is not the correct place, please let me know where to put the suggestions and then close the issue.

Suggestions:

1. Arrow keys should move the cursor in the hex editor.
2. Cheat Sheet dialog should not be modal - I need to be able to type into the Pattern editor pane as I read the cheat sheet.
3. Allow me to choose a different monospaced font for the GUI. The default IMGUI font is non-ideal, to me.
4. Related to 3: Allow me to change the scaling of the application. This thing is tiny on my 4K monitor. I can use it, but I want to scale it up just a bit without scaling up other windows (I don't want to scale everything, just this one program.)

Question: I want to write a pattern for a filetype which has an uncompressed header and a gzip-compressed payload. Is that kind of thing supported in the pattern editor? If not, please add!

This is already shaping up to be a fantastic tool.

[FR] Insert mode and Editing multiple bytes

FR1 - Currently, you can edit files by clicking the byte and writing/pasting one byte there. Pasting (CTRL+V) multiple bytes at once and changing as much as bytes ( 112233 should edit 3 cells) from the cursor would be nice to have as a feature.
FR2- a mode that inserts bytes from certain offset / cursor is must-have feature.

Add some CI tool like CircleCI

There are many options but I recommend this two services.

• Circle CI
• Travis CI

Using CI tool, you can easily deliver compiled version.

• How about add this project on apt & snap & yum & choco & brew?

Hex

I want someone to make compiling for windows

Try. But it needs many files and many errors I did not know to deal with

LLVM library path ignored, causing linking to fail on Debian

LLVM_LIBRARY_DIRS is ignored, causing the build to fail on debian, because LLVMDemangle is installed in a subdirectory of lib/ somewhere.

Adding the following line to your CMakeLists.txt made it build correctly here:

link_directories(${LLVM_LIBRARY_DIRS})

Hex editor for

RISC-V Support

It would be great if you could support RISC-V.

More expressive variable placement

Imagine we're dissecting a tar file, and we're interested in a particular PNG file within the tar file. We might do something along those lines:

TAR tar @ 0;
PNG interesting_file @ 0x1234;

This will allow the user to inspect the overall TAR file, and simultaneously see the PNG living at offset 0x1234. While this is nice, it might be more interesting to allow the user to do something like:

TAR tar @ 0;
PNG interesting_file @ tar.files[12].offset;

In general, having a more expressive offset would unlock a few really interesting possibilities.

A request to add a menu in the RMB (Hex Editor)

For example, on click RMB (hex editor) - a window appeared where you can select an action:

• Create a bookmark
• Copy as... *from the edit menu"
• Search
• Goto

Thanks

No interaction in OpenSUSE

Hi! 🙂 My name is Walter and i'm testing your app under OpenSuse Tumbleweed. I downloaded your package from https://github.com/WerWolv/ImHex/releases/download/v1.4.0/ImHex_1.4.0_Linux.zip i installed the required libs, but when i try yo open the open tab nothing happens. The same with the other buttons (import and so on...). Maybe is required to install other libs packages?

Problem building on Ubuntu 20.04

Hi. Trying to build on a clean VM of Ubuntu 20.04. I'm building the latest stable (and master) and get the same.

[ 78%] Building CXX object CMakeFiles/ImHex.dir/libs/ImGui/source/imgui_draw.cpp.o
[ 81%] Building CXX object CMakeFiles/ImHex.dir/libs/ImGui/source/imgui_widgets.cpp.o
/root/parts/imhex/src/source/views/view_disassembler.cpp: In member function ‘virtual void hex::ViewDisassembler::createView()’:
/root/parts/imhex/src/source/views/view_disassembler.cpp:221:30: error: ‘CS_ARCH_M68K’ was not declared in this scope; did you mean ‘CS_ARCH_MAX’?
  221 |                         case CS_ARCH_M68K:
      |                              ^~~~~~~~~~~~
      |                              CS_ARCH_MAX
/root/parts/imhex/src/source/views/view_disassembler.cpp:222:30: error: ‘CS_ARCH_TMS320C64X’ was not declared in this scope
  222 |                         case CS_ARCH_TMS320C64X:
      |                              ^~~~~~~~~~~~~~~~~~
/root/parts/imhex/src/source/views/view_disassembler.cpp:223:30: error: ‘CS_ARCH_M680X’ was not declared in this scope; did you mean ‘CS_ARCH_MAX’?
  223 |                         case CS_ARCH_M680X:
      |                              ^~~~~~~~~~~~~
      |                              CS_ARCH_MAX
/root/parts/imhex/src/source/views/view_disassembler.cpp:224:30: error: ‘CS_ARCH_EVM’ was not declared in this scope; did you mean ‘CS_ARCH_ARM’?
  224 |                         case CS_ARCH_EVM:
      |                              ^~~~~~~~~~~
      |                              CS_ARCH_ARM
[ 84%] Building CXX object CMakeFiles/ImHex.dir/libs/ImGui/source/imgui_demo.cpp.o
make[2]: *** [CMakeFiles/ImHex.dir/build.make:323: CMakeFiles/ImHex.dir/source/views/view_disassembler.cpp.o] Error 1

I have the following dependencies installed:

      - libmagic-dev
      - libglfw3-dev
      - libssl-dev
      - llvm-10-dev
      - nlohmann-json3-dev
      - libcapstone-dev
      - python3-dev
      - pkg-config
      - libglm-dev
      - gcc-10
      - g++-10

Perhaps I'm missing something? Capstone related? The only thing I modified was to bodge it to use Python 3.8.5 rather than the explicitly specified 3.8.6 as Ubuntu doesn't have that. But I don't think that's related.

placing a struct wrong crashes

in 1.5, entering something to the effect of

struct H {};
struct H h @ 0x0;

will crash as soon as it recognizes the placement as an expression.

I tried it this way since H h @ 0x0; didn't work on my first attempt for some reason, so I figured I'd try C syntax. It works fine with struct H { u32 foo; }; H h @ 0x0;