Oninit® Forensic Tools — Patching examples

ondebug is primarily a read tool, but its -w patch mode closes the loop on the chunk file: read the page, splice one or more bytes at a matrix position, write the new page back to the chunk file in place. Reading the result back through the engine confirms that the engine accepts the modified page.

The example throughout is the same page used in the reading examples — chunk 4, page 54 of encryptdbs, holding 'Informix is pure dead brill' and 'Informix runs on scotch'. The patch flips the lowercase b of brill to a capital B; the b sits at row 0x30, column 0x02 in the bottom-left view of the four-views grid.

Patching a byte — full round trip

The flag spelling: -w is a no-arg switch that turns on patch mode; the byte (or byte sequence) is supplied via three companion long options. --row and --col match the matrix the hex dump prints; --value is the byte sequence to write. --offset replaces --row + --col when the flat byte address is already in hand. The engine MUST be offline — the buffer cache otherwise serves the old in-memory copy on read, masking the patch.

Before — engine view

With the engine running, dbaccess reads the row through the buffer cache:

$ echo "SELECT payload FROM test_enc WHERE id = 1;" | dbaccess testdb -

payload  Informix is pure dead brill

1 row(s) retrieved.

Before — on-disk view

Take the engine offline (onmode -ky) so the chunk file is stable and not shadowed by the buffer cache, then read the same page with ondebug:

00000030  64 20 62 72 69 6c 6c 20 20 20 20 20 20 20 20 20  |d brill         |

The patch (single byte)

$ ondebug -P 54 -C 4 -w --row 0x30 --col 0x02 --value 0x42 \
      /home/informix/data/encryptdbs
ondebug: patched chunk=4 page=54 offset=0x32 (row=0x30 col=0x2): 0x62 -> 0x42

Read the argument list as “write byte 0x42 at row 0x30, column 0x02” — the row and column values are copied straight off the hex dump's column header. When the byte address is already in hand, --offset 0x32 replaces --row + --col.

The patch (multi-byte sequence)

--value accepts a colon-separated byte list to splice up to 256 bytes in one invocation. Each token is 1–2 hex digits with optional 0x prefix:

$ ondebug -P 54 -C 4 -w --row 0x30 --col 0x02 \
          --value 42:72:69:6c:6c \
          /home/informix/data/encryptdbs
ondebug: patched chunk=4 page=54 offset=0x32 (row=0x30 col=0x2): 5 bytes
        from: 62 72 69 6c 6c
        to:   42 72 69 6c 6c

The output format diverges: single-byte patches keep the back-compat 0x62 → 0x42 line so scripts grepping for “0x.. -> 0x..” still work; multi-byte patches emit a 2-line from/to display. Bytes are written consecutively starting at the splice offset.

Cross-page splices are rejected

A splice that would extend past the end of the current page is rejected at the CLI:

$ ondebug -P 54 -C 4 -w --offset 0x7fc --value 11:22:33:44:55 encryptdbs
ondebug: -w: splice would cross page boundary (offset 0x7fc + 5 bytes >
        page_size 2048). Issue one -w per page.

Spanning pages requires one -w per page. The CLI keeps a patch contained within a single page to keep the on-disk write predictable.

After — on-disk view

Re-running the same hex dump — same page, same ondebug configuration — shows the new byte on disk:

00000030  64 20 42 72 69 6c 6c 20 20 20 20 20 20 20 20 20  |d Brill         |

After — engine view

Bring the engine back up (oninit -vw) and re-run the same SELECT — the engine now reads the patched page and serves the new payload to SQL:

$ echo "SELECT payload FROM test_enc WHERE id = 1;" | dbaccess testdb -

payload  Informix is pure dead Brill

1 row(s) retrieved.

That second SELECT closes the loop: ondebug wrote bytes through to the chunk file, and the engine accepted the modified page on next read. Whether a given engine build also validates an extra header / footer field that the tool doesn't reproduce is a per-version question; on the instance these examples are captured against, the round trip lands.

Why the engine has to be offline

While the engine is up, every page in the active buffer cache is the authoritative copy — reads come from cache, not from the chunk file. A patch written directly to the chunk file is invisible to any session reading from the cached copy, and at the next checkpoint the cached page is flushed back to disk, overwriting the patch. onmode -ky evicts the cache and stops the engine cleanly, which is why the recipe brackets the -w call with onmode -ky and a fresh oninit -vw. The patch survives the restart because the engine reads from disk on recovery, not from the now-discarded cache.

Limits of the patching primitive

ondebug -w writes a contiguous byte span of up to 256 bytes per invocation, contained within a single page. For payloads that span slot boundaries within a page, the slot's stored length stays unchanged — the patch can't grow or shrink a row, only modify byte content within the already-allocated space. Cross-page edits require one -w per page.

End-to-end script

# 1. Stop the engine — buffer cache off, chunk file authoritative
$ onmode -ky

# 2. (Optional) capture a baseline image of the chunk in case the
#    patch needs to be reverted
$ cp /home/informix/data/encryptdbs /tmp/encryptdbs.pre-patch

# 3. Apply the patch (multi-byte form here, single-byte form is
#    `--value 0x42` without colons)
$ ondebug -P 54 -C 4 -w --row 0x30 --col 0x02 --value 42:72:69:6c:6c \
          /home/informix/data/encryptdbs

# 4. Verify on disk via ondebug — same page, same configuration
$ ondebug -P 54 -C 4 /home/informix/data/encryptdbs | grep -A1 '^00000030'

# 5. Bring engine back up; the patch survives recovery
$ oninit -vw

# 6. Confirm via SQL — engine reads the new page and serves the
#    patched payload
$ echo "SELECT payload FROM test_enc WHERE id = 1;" | dbaccess testdb -
payload  Informix is pure dead Brill