Case Studies 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 Flipping and Editing a Real BMP Image

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

BMP is about as plain as image formats get, which makes it a good test of whether a schema can describe a real file down to the last byte. This case study made a tiny bitmap with Python’s Pillow library, read it with the released ebyte 0.1.1 binary, edited it four ways and broke it five ways. Every number below is what the tools printed.

The image is 5 pixels wide and 3 tall: a red stripe on top, green in the middle, blue at the bottom. Pillow saved it as a 102-byte, 24-bit BMP. That’s a 14-byte file header, a 40-byte info header and 48 bytes of pixels. Five pixels at 3 bytes each make 15 bytes a row, and BMP pads every row to a multiple of 4, so each row carries one extra zero byte.

EByte Case Study Inspecting and Editing a Real ZIP Archive

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

A ZIP file is a good test of whether a schema can follow a real format’s bookkeeping. Every file inside it is described twice: once in a local header just before its data, and again in a central directory near the end. A short end record then says where that directory starts. This case study built a one-file ZIP with Python’s zipfile module, read it with the released ebyte 0.1.1 binary, edited it and then fed it archives it wasn’t built for.

EByte Case Study Reading and Editing a Real WAV File

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

The example that ships with EByte is a made-up format. This case study uses a real one: a WAV audio file, made by Python’s standard wave module and read with the released ebyte 0.1.0 binary, downloaded from GitHub like anyone else would get it. Everything below, every number and every error, is what that binary actually printed.

The file is a tenth of a second of a 440 Hz tone, mono, 16-bit, 8,000 samples a second. That makes 1,644 bytes: a 44-byte header and 1,600 bytes of samples. The Linux archive’s checksum matched SHA256SUMS before anything ran.

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.