TR19: No more dumb hex!

### Overview In "TR19: No more dumb hex!", security engineer Ange Albertini ("Ange") and front-end developer Rafał present modern alternatives to traditional hex editors and binary viewers. Conventional hex editors display fixed 16-byte wrapping with dual columns (hex and ASCII) that treat all bytes equally, losing structural context and making binary analysis and crafting cumbersome. The speakers propose two parallel approaches to address these limitations: enhancing the classic view with structured, constraint-based rendering, and replacing raw hex editing altogether using assembly language.

### Key Topics - **Limitations of Traditional Hex Editors**: Hex views historically wrapped at 16 bytes (or 8 bytes on 40-column systems like the Apple II) simply because of 80-column terminal defaults. They separate parsers from views, display compressed data and null blocks verbatim, and fail to highlight boundaries between logical fields. - **Grammar Parsers and Kaitai Struct**: While tools like Kaitai Struct provide excellent declarative YAML grammars and format parsing, traditional tree-plus-hex visual layouts remain rigid and difficult to navigate horizontally and vertically, lacking built-in editing capabilities. - **The 'bud' Architecture ('this' and 'that')**: A modular framework separating file parsing from rendering via lightweight JSON representations. `this` acts as an instrumentation/parser module outputting minimal field boundaries and values, while `that` consists of renderers including a Python terminal ANSI output tool (`that.py`) and a JavaScript-based SVG renderer (`that.js`). - **Albert & Constraint-Based Layouts**: Using the Cassowary constraint solving algorithm, Rafał created Albert—a standalone, client-side JavaScript low-level SVG builder with only one dependency. Albert translates layout relationships (margins, equal widths, relative alignments) into mathematically solved SVG diagrams and themes (e.g., Solarized, Dracula) without font-dependence breakage. - **Binary Crafting via NASM Assembly**: Replacing hex editing entirely by using NASM as a data preprocessor (`DB`, `DW`, `DD`, macro calculations, and `incbin`). This approach treats binaries as modular text sources, simplifying file format dissection, offset recalculations, and the generation of complex polyglots and hash collisions.

### Technical Details - **Constraint Solving**: Cassowary defines mathematical relationships between element properties ($X, Y, \text{width}, \text{height}$). Setting constraints like fixed 20-pixel spacing or aligned centers avoids hardcoding positions across disparate file sizes, though debugging can present unexpected solver behavior when element dimensions scale inversely. - **Assembly Representation**: Rather than writing instruction mnemonics, NASM is used strictly for byte definition. Large uninspected blobs are included via `incbin`, while relevant headers, endianness macros, and offsets (`$` notation for relative line addresses) are explicitly named. Comments replace unnecessary labels to avoid polluting namespaces, allowing post-processors to compute CRCs and hashes dynamically. - **File Crafting & Polyglots**: Ange demonstrated how structural assembly macros allowed crafting complex polyglot files (e.g., combining JAR, ZIP, and PDF/HTML), where blocks of assembly can be repositioned and automatically recalculated.

### Takeaways Separating the parsing layer (`this`) from rendering (`that` and `Albert`) produces reusable, vector-based, and copy-pasteable visual artifacts suitable for technical papers and slides without losing structural fidelity. For advanced binary manipulation and polyglot research, declaring structures via an assembler like NASM offers significant advantages over manual byte editing.