Releases on ebyte.org

EByte Case Study Comparing Sensor Captures Before and After a Firmware Update

Wed, 21 Oct 2026 00:00:00 +0000

A firmware update changes what a device sends, and the usual way to find out what changed is to capture its traffic before and after and stare at hex dumps. EByte 0.5.0 adds ebyte diff, which decodes two files through the same schema and lists the fields that differ, with each side’s offset and length and the old and new values of integers. This case study compared two packet captures of a small network sensor using the released ebyte 0.5.0 Linux binary, downloaded from GitHub. Its checksum matched SHA256SUMS before anything ran.

EByte Case Study Editing a PNG File With Every Chunk CRC Recomputed

Wed, 21 Oct 2026 00:00:00 +0000

A PNG file is an 8-byte signature followed by chunks, and every chunk ends with a CRC-32 of its type and data. Change one byte of a comment by hand and the image is broken, because that CRC no longer matches. EByte 0.4.0 adds checksums to its schemas: a field can be declared as the CRC-32, Adler-32 or one of three CRC-16 variants of other fields, and EByte checks it on decode and writes it on encode. This case study tried it on a real PNG with the released ebyte 0.4.0 Linux binary, downloaded from GitHub. Its checksum matched SHA256SUMS before anything ran.

EByte Case Study Editing a WAV Title in the Browser

Wed, 21 Oct 2026 00:00:00 +0000

EByte 0.7.0 runs in a web browser. The release has a new asset, ebyte-wasm.zip, which is the same Go library compiled to WebAssembly, and the demo page on this site loads it. There’s no server behind the page: a file you open is read by the page itself and never sent anywhere. This case study used the demo the way someone new to EByte would, with a file of their own, and then checked what came out with tools that know nothing about EByte.

EByte Case Study Editing WAV and ZIP Files Without Fixing Sizes by Hand

Wed, 21 Oct 2026 00:00:00 +0000

Every earlier case study ended with the same chore. Change the length of anything and some size field elsewhere in the file goes stale, and you fix it yourself: riff_size in a WAV, the name lengths and the directory offset in a ZIP. EByte 0.3.0 adds derived sizes and offsets, so the schema can say where those numbers come from and the encoder works them out. This case study tried it on the same WAV and ZIP samples as before, using the released ebyte 0.3.0 Linux binary downloaded from GitHub. Its checksum matched SHA256SUMS before anything ran.

EByte Case Study Floats Bit Fields and Palettes in WAV BMP and IPv4

Wed, 21 Oct 2026 00:00:00 +0000

EByte 0.6.0 adds three kinds of field that real formats kept asking for. There are floating-point numbers. There are bit fields, several small numbers packed into the same bytes. And there are byte fields that run up to an offset another field declares, like the colour palette in an 8-bit BMP. This case study tried each one on a different format with the released ebyte 0.6.0 Linux binary, downloaded from GitHub. Its checksum matched SHA256SUMS before anything ran. Every result was checked with a tool that knows nothing about EByte: ffmpeg, Pillow and dpkt.

EByte Case Study Reading Every Chunk of a WAV File

Tue, 20 Oct 2026 00:00:00 +0000

The first WAV case study used a schema that knew exactly three chunks in a fixed order. Real WAV files aren’t that tidy. Recorders and editors add a LIST chunk with a title and the software name, and some put it before the audio, some after. EByte 0.2.0 adds a repeat field for this, and this case study tries it on a WAV file with metadata, using the released ebyte 0.2.0 Linux binary downloaded from GitHub. Its checksum matched SHA256SUMS before anything ran.

EByte Launches One Schema for Reading and Writing Binary Files

Tue, 20 Oct 2026 00:00:00 +0000

EByte 0.1 is out. It’s a small Go library and a command-line tool for binary file formats, and it does one thing that sounds obvious until you’ve tried it: you describe a format once, and that single description reads files, writes them and explains them.

Here’s the usual situation it’s meant for. A device exports a file, or an old program saves one, and you need to look inside it, change a value and save it again. You end up writing a reader. Then a writer, which has to agree with the reader to the byte. Then, when a file won’t load, you open a hex editor and count bytes by hand to find out which field went wrong. That’s three descriptions of the same format, and they drift.