ByteRipperWeb 0.9.5-1 — documents that follow you across tabs and windows

This release is about where a file lives. A document now belongs to the app rather than to a page, so a pane carried to another tab or window keeps its unsaved changes, its undo history and its way back to the file it came out of. The Windows build opens several windows as one workspace, brings it back at the next launch with every unsaved change and the undo history, and keeps a job's workspace as a project.

Tabs and windows

• Open in New Tab, on the header menu of either pane of a comparison or on a panel's pill, moves it into a new browser tab, and a pane dragged by its header — or a panel by its pill — onto another tab of the app goes there. The document is not copied: both tabs see the same one, so Undo in the new tab takes back the edits made in the old.
• A part keeps its link wherever it goes: carried to another pane, tab or window, it still updates its parent through Update in Parent, and draws the parent file's annotations.
• The Windows build has several windows, as one workspace (File ▸ New Window, Ctrl+Shift+N). A pane or a panel is dragged from one window to another, or onto the New Window strip that appears above the panes while you drag; with Alt it is copied. A file is open only once: opening it again offers Show in Its Window or Move to This Window.
• In the Windows build the annotations, the help and the agent each have a window of their own, and a setting changed in one window applies in all of them.
• A file an annotation card or the agent opens, when this window's panes are both taken, opens in a new window or tab instead of asking which pane to give up.

The workspace and projects (Windows build)

• Reopen the workspace at launch (Settings ▸ General, off after installation) brings back every window at its place and size, and in each the files, the caret and the selection, bookmarks, segments, the minimap, the Find bar, the fragment panels, the tool panel with its node and open branches, and the Annotations panel.
• Nothing unsaved is lost: documents never saved, parts with changes not yet put back, and unsaved changes to files come back as they were, still red, and survive an abnormal termination too. Quitting does not ask about them.
• The undo history outlives the session: after a relaunch Undo takes back the edits made before it, and undoing to the saved state makes a file unmodified again.
• A file that changed on disk is caught, by its size and date and, where changes are kept over it, by its SHA-256: a copy that only moved the date keeps its changes, different bytes under the same date do not. One message after the restore lists the files that changed or are missing.
• Projects: File ▸ Save as Project… keeps every window in a .brw folder of its own; Open Project…, Open Recent Project and Close Project switch between jobs, nothing asked about the one being left. A project refers to the dumps where they are and stays a few kilobytes unless it holds unsaved bytes. File ▸ Open Recent lists the files opened lately.
• A workspace or a project written by an earlier build is read and brought up to date; one written by a newer build is left untouched, and the app says so.
• The browser edition has none of this: a page cannot open a file again by itself, so a reload starts from an empty window.

Undo history

• The undo history keeps its bytes in a journal on disk, not in memory, so a fill or a paste of gigabytes can be undone without holding them twice. Settings ▸ General bounds each history by the size of its changes (512 MB to 16 GB, 4 GB by default) and by its number of steps; past either, the oldest steps go first.

More of the image read

• Panasonic's DMI area in the BIOS region's padding: model, serial, asset tag and Windows key, each record's checksum checked, with the correct byte given where one fails.
• HP's HP_MUD and Apple's SysF store are read as DMI areas, and every vendor's values are listed in one Entries table, each row a link to where its value is read from. The DMI badge says whose layout it found — Lenovo DMI, HP DMI, Apple DMI.
• The BIOS Version Data Table of Insyde firmware lists the BIOS, product and kernel versions, the release date, the compiler and the ESRT entry under Entries; a click outlines the bytes each value is read from.
• A Lenovo LENV block stored unencoded opens as itself. The flash chip catalogue knows the Eon EN25QE32A.

Smaller things

• A pointer on a mark, a bookmark or the minimap shows what is there at once, in a callout beside it; a note's text appears when the pointer reaches its outline.
• Tree rows in UEFI Structure and the ME Analyzer open and close with motion, and the tree scrolls to make room before a branch opens. The disclosure triangle takes a click on the row's full height.
• Update in Parent reports its refusals, warnings and progress in the interface language.
• The ME Analyzer's summary selects and copies like the other detail lists; the name column fits the longest name.
• In a comparison both minimaps draw their bytes at the same width.
• Save on a document with no file asks where to save it, wherever the browser has a save dialog, instead of downloading.
• Edit ▸ Select All selects a text field's text while you type in one; Settings opens on General. The help's search field sits at the top of its contents.
• The ME region is read at most twice when opened, instead of four times, and its analysis no longer holds up the UEFI tree.

Fixes

• Dragging a pane by its header, or a panel by its pill, with the mouse moved nothing.
• After opening the ME region of a CSME 13 dump, opening the BIOS region left its row on "Loading…" for good.
• While dragging a pane, every pane lit its drop bands, not only the one under the pointer.
• Check for Update… without a network connection failed with an error instead of saying that GitHub could not be reached.

---

The page (ByteRipperWeb-0.9.5-1.html) is the whole app in one file:
open it in Chrome or Edge from disk, no installation and no server. Files
never leave the machine. Opened from disk, a page has no private storage, so
File ▸ Duplicate needs the hosted page or the Windows build.

Windows (ByteRipper-0.9.5-1-setup.exe installs it for the current user
and starts fastest; -portable.exe and the .zip need no installation): the
same app in a window of its own, x64. Help ▸ Check for Update… installs the
next release from the setup. Not code-signed, so SmartScreen warns on the
first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ —
and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.9.3-1 — annotations, a way back, and an agent on Windows

This release lets you leave notes on a dump and find your way back: annotations on bytes and on UEFI nodes, kept with the file and listed as cards, and Back and Forward through the places you have been. The UEFI tree is searched by content, inside compressed sections too, Lenovo's DMI store is read and edited, and the Windows build lets an AI agent work on the dumps you have open.

Annotations

• Add Annotation… on a selection or on a node of the UEFI tree: a title and a note, drawn over the bytes as a dashed outline wherever the file is on screen, the note shown when the pointer rests on it. Yours are green, an agent's violet.
• An annotation belongs to the file: it comes back when the file is opened again, and a node inside a compressed section or an encoded LENV block is annotated in the bytes it decodes to.
• The Annotations panel in the dock lists them all as cards, open files or not: the newest first and tagged New, any card dragged to where you want it, the order kept between visits.
• A double click on a card goes to its place, opening the file again if it has to, decompressing the way to it, and opening UEFI Structure down to the node. Open Annotation “…” on the dump's menu does the same from the bytes.

Finding your way back

• Back and Forward step through the places you went to — bookmarks, search matches, a tool's rows, annotations — and a tool's choice is a step of its own.
• The UEFI tree is searched by content: a pattern, text or GUID, inside compressed sections in what they decompress to. The matches are listed under the tree, and a match opens the tree down to its node, or opens the decompressed part with the match selected.
• The Find bar and the tree's search share one set of pattern controls.

Parts of a dump

• Every part opens through what it is: a node, a decompressed body, a decoded block opens as a panel over the dump and goes back through Update in Parent the same way — compressed again, encoded again, its checksum written.
• A pill is named after what was opened — the node, its body, the zone — with the codec beside it when the bytes went through one (LZMA, XOR 58, bzip2), a part opened out of a decompressed one included. A part saved for the first time is offered as a .bin.
• A double click on a node with rows — a volume, a DMI store — opens it whole, with its tree.

More of the image read

• Lenovo's DMI store is read into the UEFI tree: the LDBG change log, both LENV blocks and the block the firmware uses, each entry decoded. A block opens decoded and goes back encoded with its checksum recomputed; Show DMI Area finds the store.
• Acer's DMI area is read.
• FIT microcode names every processor an update serves, and a second update for the same processor is refused.
• The ME analysis says what the file system state rests on.

The agent (Windows build)

• Settings ▸ Agent lets in Claude Code, Claude Desktop, Cursor or any MCP client, with the text its configuration needs. It reads what you are looking at — the caret, the selection, the UEFI tree, the FIT table, the ME analysis — and brings forward the place it wants you to see.
• Across many dumps: it opens a folder of dumps without putting them on screen, asks one question of each (each file named by its path from the folder), compares them byte by byte, by NVRAM variable or by ME file, and leaves its findings as annotations.
• Edits only when you allow it: a second switch lets it write bytes, fix checksums and change FIT microcode, each change one undo step. Every call is listed in the Agent panel. Nothing of the agent exists in the browser.

Smaller things

• Appearance, layout and language are on one View tab in Settings.
• The bookmark command says Add or Delete rather than Toggle.
• A quick second Ctrl/⌘ Z takes back the rest of a typed run.
• The minimap's overview draws the content over a difference, and a modified row in red.
• A click on the empty part of the Annotations panel clears the selection, and the panel's empty view says how to make an annotation.

Fixes

• A recent file that was moved or deleted stayed in the list, and opening it said only "This file could not be opened". It now says the file is no longer there and leaves the list; a refused permission says so too.
• The ✕ of the open panel's pill could not be seen under the pointer.
• The hosted page no longer offers an update: its next load is the newest release.

---

The page (ByteRipperWeb-0.9.3-1.html) is the whole app in one file:
open it in Chrome or Edge from disk, no installation and no server. Files
never leave the machine. Opened from disk, a page has no private storage, so
File ▸ Duplicate needs the hosted page or the Windows build.

Windows (ByteRipper-0.9.3-1-setup.exe installs it for the current user
and starts fastest; -portable.exe and the .zip need no installation): the
same app in a window of its own, x64. Help ▸ Check for Update… installs the
next release from the setup. Not code-signed, so SmartScreen warns on the
first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ —
and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.9.1-1 — AMD and BIOS Guard read, a searchable tree, and panels that move

This release reads the rest of the bench's dumps: AMD's PSP map and EC firmware, AMI BIOS Guard update files you can compare with a dump's BIOS region, ASUS's GPNV store, HP's signature blocks and Apple's device overrides. The UEFI tree can be searched, a row's details open large on Space, and the panels move — a panel grows out of its pill and folds back into it, and is pulled down by its header.

AMD dumps

• The AMD PSP's map is read: the EFS, every PSP and BIOS directory and the firmware they list, as rows, with each directory's Fletcher-32 checked and fixed. The PSP's compressed BIOS image opens to what it inflates to.
• AMD's Zlib sections open, and their stated length is written back when they are rebuilt.
• AMD microcode found in padding and in Insyde map regions is shown by CPUID and revision.
• The EC firmware is found on AMD dumps: an ITE image is cut out of the padding it sits in, and an Insyde map is placed by its own entry — also on a dump with bytes appended.

AMI BIOS Guard

• A BIOS Guard (PFAT) update file opens as a tree in the UEFI panel: its table, its entries and the BIOS region they assemble.
• Compare it with a dump's BIOS region: the dialog says which parts match and which differ, and Write puts the update's BIOS region into the dump as one undo step.

More of the image read

• ASUS's GPNV store, where the machine's serial numbers, model and Windows key are kept, is read with a row per record.
• HP's signature blocks are read out of padding, and the digest whose span is known is checked.
• Apple's device overrides are read as a table of rules, the ROM information and the BIOS ID as tables, and a bzip2-compressed variable can be opened decompressed.
• A VSS or NVAR variable's value is shown after its name, read as its type, and the VSS header is taken apart in the details.
• The descriptor's PCH straps are read as words, with the ME-disable bit, GPR0 and the eSPI clock.
• A WAV found among the data plays in a player under its details; a GIF's frames are counted.
• Empty padding, free space and erased pad files are drawn grey in the tree.

Finding your way

• Search the UEFI tree by name, GUID, type and subtype, from match to match; the tree opens the way to each match and shuts it again on the next.
• Show in Tree: the dump's context menu takes you to the node under the clicked byte, and the reveal button explains what it does in the help.
• A row's details open large over the window on Space; the arrow keys keep moving through the table behind them.
• The empty screen lists the recent files, and prints what's new in the latest release under the version.
• A help page has an address: in the browser, a link copied from the help opens the app on that page.

Panels

• A panel grows out of its pill in the dock and folds back into it; closing one folds it into its pill too, and a new panel waits for the one it replaces.
• Pull a panel down by its header — a part's, a tool's or the help's — to fold it away.
• Update in Parent is offered in a modified part's header.
• The minimap names what the pointer is over: a segment, a zone or a bookmark.

Smaller things

• Operations that block the window show an indeterminate bar, and a Cancel already pressed says Cancelling….
• A microcode change shows its progress and result in a dialog of its own.
• A tool opened on a file whose image is already parsed shows its tree at once, without reading the image again.
• The selected row of a tool's table is drawn in the saturated blue the Mac's tables use.

Fixes

• Append File… and Insert File at Start… work in the page opened from disk. They failed with "certain files are unsafe for access within a Web application".
• The bookmark popover is shown deep in a large file. In Chrome and in the Windows build it came up as a lone frame around the name field.
• Copy Link and the other plain copies work when the app is opened over plain HTTP on a bench's network.
• The minimap button is greyed out with no file open, as the menu item already was.
• A panel opening out of its pill grows the same way it folds, instead of from the middle.
• A fractional page zoom no longer draws a scroll bar under the dump.

---

The page (ByteRipperWeb-0.9.1-1.html) is the whole app in one file:
open it in Chrome or Edge from disk, no installation and no server. Files
never leave the machine. Opened from disk, a page has no private storage, so
File ▸ Duplicate needs the hosted page or the Windows build.

Windows (ByteRipper-0.9.1-1-setup.exe installs it for the current user
and starts fastest; -portable.exe and the .zip need no installation): the
same app in a window of its own, x64. Help ▸ Check for Update… installs the
next release from the setup. Not code-signed, so SmartScreen warns on the
first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ —
and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.9-1 — more of the image read, and an ME panel that answers at once

This release brings the web edition level with upstream 0.9: the UEFI panel reads far more of what a vendor's image carries — AMI, Insyde and Dell variable stores, pictures, EC firmware, the Top Swap copy of the boot block — and the ME panel answers at once instead of after its databases have been worked through. It is level with upstream 0.9; the upstream commits made since then (the VSCC table's chip catalogue, the microcode change in sheets of its own) come in the next build.

More of the image read

• AMI NVAR stores are read into their variables, and a variable's history shows every copy its store keeps and what each one changed.
• Dell's DVAR stores are read, their variables named from what Dell's Setup forms say each one is, and superseded copies can be hidden.
• Insyde images: the regions the flash device map lays out are named, the Variable Defaults are read where that map puts them, and the BIOS version the version table states is shown — with the rest of the BVDT: the compiler, the ESRT entry and the $BME$ ranges.
• EVSA stores, MFSB backup areas and a $VSS store whose size was never set are found by the signature they carry, and an NVRAM store shows how full it is.
• Pictures — JPEG, PNG, GIF and BMP — are recognised, with a preview under their details.
• ITE EC firmware is named by the identification it carries; each EC image in a block gets a row and a size of its own.
• The Top Swap copy of the boot block is named, and you can step between a node and its Top Swap twin.
• A pad file and a raw file show what they hold, read the way UEFITool reads them; a Mac's microcode volume is read as the microcode it holds; the FIT names what it finds in padding.
• The flash descriptor's component section is read, and the descriptor's generation is told from its layout.
• Save a tree node, or its body, to a file from the node's menu.

The ME panel answers at once

• The first reading is shown straight away. The values that depend on the databases read "Loading…" until they arrive, and the full reading then replaces it. The UEFI panel's ME region opens on that first reading too, and both panels share one reading of the same image.
• The help page of the ME panel is upstream's, in all three languages.

Smaller things

• Open… and Open Recent put the file into the active pane, and Compare with… into the other one.
• The Tools menu has keys in the Windows build: Ctrl+1, Ctrl+2, … open the panels in the menu's order. A browser keeps these keys for its tabs.
• A part's panel carries its pane's title bar across its whole width.
• Picking a row in a tool shows its place in the dump without selecting it.
• No checksum is held against a file that its state marks invalid, and the parser's nesting limit is raised to 32.
• The version is upstream's release and a build of this edition, so this one is 0.9-1.

Fixes

• The arrow keys move through a tool's table after a click in it. They used to move the dump's caret, or scroll the table and leave the selected row where it was.
• A refused microcode change is said in the FIT panel, in red, in the line under its buttons. It used to flash in the pane's status line for two seconds, too briefly to read.
• The UEFI panel starts over when the pane's file is replaced, instead of showing the tree of the file that was there.
• When a browser will not give the file behind a picked handle, the app says so.

---

The page (ByteRipperWeb-0.9-1.html) is the whole app in one file:
open it in Chrome or Edge from disk, no installation and no server. Files
never leave the machine. Opened from disk, a page has no private storage, so
File ▸ Duplicate needs the hosted page or the Windows build.

Windows (ByteRipper-0.9-1-setup.exe installs it for the current user
and starts fastest; -portable.exe and the .zip need no installation): the
same app in a window of its own, x64. Help ▸ Check for Update… installs the
next release from the setup. Not code-signed, so SmartScreen warns on the
first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ —
and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.8.5-5 — the Windows build's Open Recent menu

This build adds the Open Recent menu to the Windows window — the files opened most recently, as the Mac app lists them under File, ready to open again without a picker. It is level with upstream 0.8.5.

Open Recent in the Windows build

Under File, right after Open…, the window now lists the files opened most recently, most recent first, up to ten. Re-opening one goes straight back to that file, and a re-opened file keeps Save in place working, because the app re-opens it through the same file handle that opened it. The menu is the window's own: a browser tab's in-page menu is unchanged.

• A re-open never asks for a folder. Each entry is the file itself, so a file from one drive and one from another are separate, and re-opening reads each at the place it came from. When the window has not been given access to a file since a restart, it asks once — for that file — rather than showing a picker.
• The list survives a restart. The recent files are kept on disk and come back when the window is opened again; a file that is no longer there drops out on its own.
• Clear Menu wipes the list. It stands under the files, set apart by a divider, and appears only while there is something to clear; an empty list shows a greyed Empty, the way an empty menu does.
• The menu is localised in Russian and German, word for word with the Mac app.

---

The page (ByteRipperWeb-0.8.5-5.html) is the whole app in one file:
open it in Chrome or Edge from disk, no installation and no server. Files
never leave the machine. Opened from disk, a page has no private storage, so
File ▸ Duplicate needs the hosted page or the Windows build.

Windows (ByteRipper-0.8.5-5-setup.exe installs it for the current user
and starts fastest; -portable.exe and the .zip need no installation): the
same app in a window of its own, x64. Help ▸ Check for Update… installs the
next release from the setup. Not code-signed, so SmartScreen warns on the
first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ —
and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.8.5-4 — the help and the error messages in their own languages

This build brings the web's own help pages and the three storage error messages that were still in English into Russian and German, written as the language's own text rather than a translation of the English, and adds a few small interactions. It is level with upstream 0.8.5.

The help and the error messages in their own languages

The web's own help pages — opening files and saving — are written in Russian and German as the language's own help, carrying the same meaning in its own words rather than as a calque of the English, in a strictly technical register. The three storage error messages that were still in English are now translated.

• The saving page is accurate about a changed file. A browser cannot watch a file, so the app does not notice when the one it has open changes on disk. The pane keeps the bytes it read at open time, and the only check is the narrow one at save — a shrunken file is refused, a rewrite to the same size is not. The page now says that plainly, instead of implying the app would catch it.
• The three storage error messages are in Russian and German — a file changed on disk, the browser refusing access, and a file that could not be read were the last user-facing strings left in English.

A few interactions

• A pane grows to its content when you double-click its header, as far as the split allows.
• Closing one file promotes the other to the first panel, so a new file opens into the second rather than the one just vacated.
• The update check says why it failed where a check cannot be made, rather than a bare failure; on the Windows build the check also asks the way past the API's limit.

Smaller things

• The Russian Boot Guard legend names the kind of range — «Область IBB Boot Guard», «Диапазон, который прошивка проверяет при запуске» — instead of «Внутри …».
• The tool panel's file list uses the theme's colours, so it is not a white list on a dark theme.
• The active tool is marked with a check rather than a radio, and None is left unmarked.

Fixes

• A Select Block selection is no longer eaten by the caret move a reveal makes.

---

The page (ByteRipperWeb-0.8.5-4.html) is the whole app in one file:
open it in Chrome or Edge from disk, no installation and no server. Files
never leave the machine. Opened from disk, a page has no private storage, so
File ▸ Duplicate needs the hosted page or the Windows build.

Windows (ByteRipper-0.8.5-4-setup.exe installs it for the current user
and starts fastest; -portable.exe and the .zip need no installation): the
same app in a window of its own, x64. Help ▸ Check for Update… installs the
next release from the setup. Not code-signed, so SmartScreen warns on the
first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ —
and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.8.5-3 — the zoom is remembered, and the dump redraws after zooming out

The third build against upstream ByteRipper 0.8.5: the Windows build remembers its zoom, and the dump redraws correctly when you zoom out.

Windows

• The zoom is remembered. The level chosen in View ▸ Zoom In / Zoom Out / Actual Size is kept and restored when the app starts again.
• The dump redraws correctly after a zoom. Zooming out could leave the hex panes drawn one step behind, with rows of the old scale showing at the bottom and the right edge. The page now reads the new scale again after the zoom has settled and draws for that.
• The tool and word-size buttons are set in the menu's own size (13 px, where they were 15) so they no longer stand out from the rest of the window.

Not in this release: the one-file HTML page, which is being reworked. Upstream commits after 0.8.5 are not ported yet.

---

Windows (ByteRipper-0.8.5-3-setup.exe installs it for the current user and starts fastest; -portable.exe and the .zip need no installation): the same app in a window of its own, x64. Help ▸ Check for Update… installs the next release from the setup. Not code-signed, so SmartScreen warns on the first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ — and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.8.5-2 — the update shows its progress, and an About panel

The second build against upstream ByteRipper 0.8.5: the Windows build says what it is doing while it updates, and gains an About panel.

Windows

• The update shows its progress. Choosing Update — on the landing screen or in Help ▸ Check for Update… — now opens a window that says what is happening: asking GitHub, downloading (with a bar and how many megabytes of how many), checking the file, closing. Cancel stops the download. Before, the window went quiet for as long as it took.
• The installer shows itself. The setup runs with its own progress window between the old window closing and the new one opening, instead of silently, and starts ByteRipper again when it is done.
• Help ▸ About ByteRipper repeats upstream's About panel: the icon, the name and version, the projects whose data the app uses (UEFITool, MEAnalyzer, CPUMicrocodes) with their authors and repositories, and the copyright.

Not in this release: the one-file HTML page, which is being reworked. Upstream commits after 0.8.5 are not ported yet.

---

Windows (ByteRipper-0.8.5-2-setup.exe installs it for the current user and starts fastest; -portable.exe and the .zip need no installation): the same app in a window of its own, x64. Help ▸ Check for Update… installs the next release from the setup. Not code-signed, so SmartScreen warns on the first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ — and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest

ByteRipperWeb 0.8.5-1 — the first release, with a Windows installer and updates

The first tagged ByteRipperWeb release: the Windows build with an installer, and an app that can tell you a newer one exists. It is level with upstream ByteRipper 0.8.5; the -1 is this edition's own build number, which counts up with every release made against the same upstream version (0.8.5-2, 0.8.5-3 …) and starts again when upstream moves on.

Windows

• A setup (ByteRipper-0.8.5-1-setup.exe) that installs for the current user, without administrator rights, and starts fast — the portable .exe unpacks itself into a temporary folder on every launch.
• Check for Update… in the Help menu asks GitHub for the latest release and, on an installed build, downloads the new setup, checks it against SHA256SUMS, and installs it when the window closes. Unsaved work is asked about first.
• The landing screen says when a newer version is out, with an Update button beside it, as upstream's does — checked at most once a day, and silent when there is no network.
• View ▸ Zoom In / Zoom Out / Actual Size, on Ctrl++, Ctrl+- and Ctrl+0.
• File ▸ Exit, which asks before it drops unsaved changes.

Smaller things

• Shortcuts with Ctrl work on any keyboard layout — Russian, for one — not only on the Latin one.
• Filler bytes (00 and FF) are drawn as the text colour at 40 % opacity, as upstream draws them, so they stay readable over the orange wash of a difference in both themes.
• The desktop build's development run keeps a profile of its own and no longer collides with an installed build.

Not in this release: the one-file HTML page, which is being reworked. Upstream commits after 0.8.5 (three, none of them changing a feature) are not ported yet.

---

Windows (ByteRipper-0.8.5-1-setup.exe installs it for the current user and starts fastest; -portable.exe and the .zip need no installation): the same app in a window of its own, x64. Help ▸ Check for Update… installs the next release from the setup. Not code-signed, so SmartScreen warns on the first launch: choose More info ▸ Run anyway.

In the browser, the same release: https://maxshevelev.github.io/ByteRipperWeb/ — and on a Mac, the native app: https://github.com/maxshevelev/ByteRipper/releases/latest