BIN File

What are BIN files and how to open them

Are you having problems opening a BIN file or are you simply curious about its contents? We're here to explain the properties of these files and provide you with software that can open or handle your BIN files.

What is a BIN file?

BIN files have multiple uses, and Binary is one of them. Read more about the other uses further down the page.

Binary File

The BIN file extension is very widely used for very different purposes. Normally BIN indicates that the file is binary, meaning that it is not human readable.

These files are used by many different computer applications and for a variety of purposes, from DVD backup images, and anti-virus updates, to images and audio.

On this page, you will find a collection of some of the known uses of BIN files. You can try opening your file with a hex editor like UltraEdit or 010 Editor to inspect the raw content, or you can use our File Analyzer to find out exactly what type of BIN file you have.

How to open BIN files

We have identified three BIN openers that are compatible with this specific type of BIN file.

Programs that open Binary files

Last updated: August 24, 2026

All known file formats using extension .BIN

While Binary File is a popular type of BIN-file, we know of 77 different uses of the .BIN file extension. Different software may use files with the same extension for different types of data.

Macintosh MacBinary

Macintosh MacBinary is a format used by classic Mac OS to package all parts of a file - including its data fork, resource fork, and metadata like file type, creator, timestamps, and Finder flags - into a single binary file so it can be stored or sent via systems that do not understand the Mac file structure.

It was developed to allow Macintosh users to send files over FTP, email, or through non-Macintosh servers without losing vital file details. When the host Mac receives it, software decodes the MacBinary file and reconstructs both forks along with its metadata so the file behaves on the Mac just as the original did.

Technically, a MacBinary file begins with a 128-byte header that stores the filename, file type and creator codes, Finder window position, flags, and the sizes of both forks. After the header comes the data fork and then the resource fork, each padded to a multiple of 128 bytes if necessary. Early versions (MacBinary I and II) date from the mid-1980s; MacBinary III, which added support for newer Finder metadata (such as icon badging and routing flags), was introduced in 1996.

BIN opener for Windows

We have identified one BIN opener that is compatible with this specific type of BIN file.

Agilent Binary Waveform

We know that one BIN format is Agilent Binary Waveform. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

While we have not verified the apps ourselves yet, our users have suggested ten different BIN openers which you will find listed below.

Agon MOS Executable

Agon MOS Executable files are programs developed for the MOS firmware that runs on Agon Light (and related Agon) microcomputers. They are written in assembly or C using tools like Zilog ZDS II, compiled for the eZ80 processor, and placed on the micro-SD card. When MOS runs, it loads these executables (regular programs or "moslets") into memory and executes them as commands entered in the MOS command interface or invoked from scripts.

Regular programs are loaded at address 0x040000 in user RAM; moslets are special executables built to run from address 0x0B0000 in the "moslet" memory area. From MOS version 2.3 onward MOS ensures programs don't overlap the system's reserved memory; version 3.0 adds support for modules and "module safe" or "module compatible" flags to executables.

The file begins with a header at offset 0x40: the 3 ASCII characters MOS, followed by a header version byte and a byte defining executable type (0 for classic Z80 mode, 1 for ADL mode). In header version 1 (advanced format) additional bytes follow: a flags byte, its bitwise inverse, and optionally a little-endian load/execution address if a flag is set.

Amazfit GTR Watchface

Amazfit GTR Watchface files are binary packages used by the original Amazfit GTR (47 mm and 42 mm) smartwatches to define complete custom watch faces. They bundle together image assets, layout instructions, and configuration data so that the watch displays the desired visual design and functionality. These files are created using community tools that convert image files (typically PNGs) and a layout description into the single binary package the watch firmware accepts.

Production of these watchface binaries follows this workflow: Create or edit a layout in a JSON file that references numbered PNG images, each image corresponding to a visual element like numbers, hands, or background. Use a packer/unpacker tool designed for GTR original watchfaces (e.g. py_amazfit-TOOLS or amazfit_gtr_tools) to convert the JSON and PNGs into a .BIN file, or to extract assets from an existing .BIN into editable form. After packaging, the resulting file is loaded onto the phone into the watch face storage area (for example under Android in files/watch_skin_local) and synced to the watch using the official app. There is a maximum file size limit (around 1.95-2 MB) that must not be exceeded or the watch rejects (or fails to load) the face.

Internally the binary begins with a header that identifies it as a GTR watchface package, followed by sections for image data, configuration tables (layout coordinates, which image corresponds to which part of the face), metadata for previews and optional animations, and checksums to validate integrity.

Amazon Kindle Update Package

Amazon Kindle Update Package is a firmware bundle created by Amazon's Lab126, used to deliver operating system updates and system component upgrades to Kindle e-reader devices. It is what Amazon builds and signs for its over-the-air (OTA) and recovery update workflows, helping ensure devices stay up to date with security patches and feature enhancements.

This package format can also serve as a signature envelope type labeled "SP01" in KindleTool for wrapping user-data updates (introduced with firmware version 5.1 and later); "SP01" type packages do not directly replace system partitions but provide signed wrappers used during update verification. KindleTool is a community tool that reproduces the same format: it can create, convert, extract or analyze Kindle update packages, including SP01 signature-envelope packages, OTA V1 and V2 packages, and recovery packages.

Contents include one or more archive layers (often a gzipped tar of the payload), metadata such as target firmware revision, device identifiers, certificate number(s), and cryptographic signatures. Amazon devices verify the package against a public key stored in the device; only properly signed packages can install.

The file begins with a magic number: the ASCII string "SP01" at byte offset 0, which identifies this package type.

Android Battery Usage Data

Android Battery Usage Data files store detailed battery usage statistics recorded by Android's BatteryStatsService. These files track how apps and system components consume power over time. Android writes this file to monitor things like CPU usage per app, how long wakelocks are held, network and sensor use, charging versus discharging events, and system history of battery level and state changes. Developers and diagnostics tools read it via system utilities and APIs to generate battery usage reports or visualizations.

This file is produced by Android itself and saved in the device's system directory, typically under /data/system/batterystats.bin. Android reads from it when generating reports (for example with adb shell dumpsys batterystats) and uses it internally to keep track of past battery-related events and app behavior. Users or third-party tools generally do not write this file. It serves for diagnostics, troubleshooting, and power optimization rather than configuration or user-facing data.

The format is a proprietary, binary serialization of internal Android battery statistics classes. It includes records for charge/discharge cycles, CPU time, wakelock usage, foreground/background state durations, and events such as GPS, network, screen state changes. Android marshals data into a Parcel and writes the marshalled bytes to disk. The file may reset once the device is charged to a high level, unplugged, rebooted, or upon factory reset depending on Android version.

Identification of the file is possible via specific byte signatures. Among them are initial zero bytes at certain offsets (for example 0x000000 at offset 1), fixed sequences like 0x0000FDFF0300 at offset 14, and certain strings embedded in the file including "POWERMANAGERSERVICE", "DELETED_WAKE_LOCKS", "SUSPEND_BACKOFF", "UNKNOWN_WAKEUPS", and other component tags like "WAKLOCK", "AUDIO", "BAT", "ADC", "USB". These help distinguish Android Battery Usage Data from other binary files.

Anjoy Vision IP Camera Firmware

Anjoy Vision IP Camera Firmware is a firmware file produced by Shenzhen Anjoy Vision Information Technology Co., Ltd., designed for their range of network/IP surveillance cameras. It contains the low-level system code that runs the camera's hardware - including bootloader, kernel, drivers, and built-in features such as video encoding, motion detection, remote access, and network protocols. Its main role is to be installed (flashed) into Anjoy Vision camera devices to update their embedded Linux-based system, fix bugs, add improvements, or enable new features.

This firmware is built for the company's hardware and is distributed in binary form. Anjoy Vision publishes specific firmware versions for models such as MC200J, MC400L, MC500L, MC800 series, etc., via their official website and support platforms. Users install it using the camera's upgrade facility (usually through a web interface or via tools provided by Anjoy Vision) in order to replace or overwrite the existing system software.

Technical identifiers include the ASCII signature ANJOY888 at the very beginning of the file, an "MSTAR_I" string around byte offset 32, and strings such as "_LINUX" elsewhere. These byte signatures help differentiate this firmware from unrelated binaries.

Atari Jaguar CD Image

Atari Jaguar CD Images are exact, sector-perfect copies of Jaguar CD discs, preserving the proprietary "raw" CD-DA style layout used by Atari rather than the standard ISO-9660 filesystem. They record every byte from the disc's sessions and tracks - including data stored in audio-format sectors - allowing Jaguar CD hardware or accurate emulators to boot and run the disc just like the original. This format supports the full dual-session structure, cinematic FMV, CD audio tracks, and the "Virtual Light Machine" features that reacted to standard audio CDs.

These images are produced by dumping the raw sectors from an original Jaguar CD, usually via disc-ripping hardware or software that can handle the Jaguar's multi-session layout. All 2352 bytes of each sector are preserved, and sessions are stored in order so that disc boot tracks and copy protection remain intact. The format is useful for preservation and emulation compatibility. Retro-processors and emulators often expect the disc image to be accompanied by a cue sheet, in "CUE/BIN" pairing, so that track boundaries and session offsets are correctly interpreted.

A technical signature near the start of the image identifies it as authentic Jaguar CD content: sector zero begins with an ASCII header reading "ATARI APPROVED DATA HEADER ATRI", repeated after a sequence of "ATRI" tags. That byte signature helps software tools detect the format.

ATIS DVR/dashcam Firmware

ATIS DVR/dashcam firmware is a device-firmware file used for updating the software that runs on certain ATIS brand digital video recorders and dashcams. It is written by the manufacturer or provided through authorized firmware update tools. Its role is to replace or patch the internal system software of the DVR or dashcam, fixing bugs, improving performance, or adding features.

These firmware files are generally deployed by copying them to a storage device such as a USB drive or micro-SD card, placing that storage into the DVR or dashcam, and then initiating a firmware upgrade mode. Once installed, the updated firmware executes on boot and becomes the new system image that the device uses to control recording, storage, sensors, interfaces, and file handling.

This format is identified by a fixed header: at byte offset zero the ASCII signature "AITS" followed by a particular version or control byte (specifically: bytes 0x41495453010000000000000000000000). That signature helps devices or firmware tools distinguish genuine ATIS DVR/dashcam firmware from arbitrary binary data.

Autel EVO Drone Firmware

Autel EVO Drone Firmware files hold the official firmware upgrade package for Autel EVO series aerial drones. They are downloaded from Autel's website to update the aircraft, remote controller, camera, gimbal, battery, and other onboard modules so that all components match current versions for optimal performance. These files are used by the drone when inserted on a microSD card (or accessed by other methods depending on model), and are crucial for applying fixes, enhancements, and maintaining compatibility within the EVO system.

The firmware files are created by Autel Robotics and provided to users as part of official updates. They are not created or edited by third-party tools. Upon being copied uncompressed to the root directory of the microSD card, the drone automatically detects and applies the update when powered with sufficient battery level (typically above 25 %) and after the remote controller is on. After the update, both aircraft and controller are restarted.

Inside these firmware packages are structured components each targeting different drone subsystems such as flight control, camera, image transmission, vision modules, ESC, and batteries. Version and release notes provided by Autel specify each component's version in the package. Updates may be applied across the whole drone system or selectively depending on model.

For identification, these firmware binaries begin with byte signatures like an ASCII header containing tags such as FILETRANSFER, FILEINFO, FILECONTENT, and IHHEADER.JSON. They also include strings like "FWIMAGE.UPGUT", component identifiers like _FW_V, and metadata fields like MD5SUM and FILESIZE.

AVG Anti-Virus Update Package

AVG Anti-Virus Update Package files are used by AVG (formerly Grisoft) software to deliver virus definition updates. These are data packets created by the AVG update system when new malware signature databases are released so that the antivirus engine has information needed to detect newly discovered threats.

These files are generated by AVG's servers and downloaded to AVG programs on user computers. After download, they are applied internally by the AVG software to update its virus definition database. Older versions of AVG allowed installing such packages manually or via offline update when internet access was unavailable, but in more recent versions those manual import features have been removed or deprecated.

Files in this format include all data needed for AVG's detection libraries - signature definitions, perhaps encrypted or packed - so the antivirus engine can identify threats. The files are not intended for users to open or edit; instead AVG reads them internally to update its detection rules.

Internally these files can be identified by particular byte-patterns: they begin with the ASCII sequence MZAVG at the very start of the file (offset zero), and contain the string UPDATEBIN within their contents.

Casio Loopy ROM

Casio Loopy ROM files store complete game or BIOS images designed for the Casio Loopy home video game console (Japan, 1995). Created from the data dumped from physical Loopy cartridges, these files provide the exact binary contents of the cartridge's ROM, preserving all code, graphics, sound data, and internal BIOS functions used by the Loopy system. They are used by emulators or flash carts to run authentic Loopy software without hardware cartridges.

The Loopy ROM format is produced by cartridge hardware and by homebrew toolchains targeting that cartridge. These ROM images are mapped into the address space by Loopy-compatible emulators or by the console when using specialized flash carts. The console system includes a built-in 2 MB ROM area for cartridges and a separate system BIOS area; the ROM image file covers the cartridge portion so it can be read directly by the console CPU. Homebrew developers compile source code (often in C for SH-7021) into a binary image named "rom.bin" which matches the expected layout and size for proper execution on Loopy or in emulation.

The console's hardware uses a Hitachi SH‐7021 32-bit RISC CPU operating at 16 MHz, with 1 MB of RAM and support for 512-color graphics and four channels of 12-bit PCM audio. Total cartridge ROM (not counting internal BIOS) is typically 2 MB in size, and some games are larger (e.g. 3 MB) due to including extra data or banked content.

Internal identification of a valid Casio Loopy ROM image may be done via specific byte patterns at set offsets. One known signature starts at offset 0 and is "0x000E80001F0EFEFF", and another at offset 12 is "0xFFFFFFFF000200000002FF".

CASIO WinCE PDA Backup

We know that one BIN format is CASIO WinCE PDA Backup. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

CD-I Disk Image

CD-I Disk Image files store a complete, uncompressed copy of a Compact Disc-Interactive (CD-i) disc's data sector by sector. They are produced from full optical disc captures that include all tracks - data, audio and/or video - as they exist in the original disc image format standardized by Philips and Sony under the Green Book. These images are used for archival, preservation, or for loading in CD-i players and emulators. They reproduce the disc format's specific interleaved audio, video and data structure exactly.

The data layout follows CD-i's disc specification: a lead-in area, followed by a program area containing CD-i tracks that use the CD-ROM/XA sector format (Mode 2, Form 1 or Form 2) along with Red Book CD-DA audio tracks potentially in the same session. The file is created by imaging utilities that support raw sector dumps of CD-i discs; tools that read Green Book-compliant discs can produce or use these images. Typically such images are accompanied by cue sheets that mark track boundaries, session offsets, and lead-in/out data.

These disk images can be used by devices or software that understand the Green Book disc layout and data track interleaving rules. The Green Book defines classes for sectors (data, video, audio, empty, message) and requires the first track in the program area to be a CD-i track. The file format does not alter any sector content - it maintains all header, sub-header, user data, error detection and correction and error correction codes as found on the original CD-i disc.

A CD-i Disk Image begins with a fixed byte signature at the very start: bytes from offset 0 up to offset 23 start with 00 FF FF FF FF FF FF FF FF FF FF FF FF FF 00; there are null bytes at offsets 14 and 16; and a space (0x20) at offset 18.

Chasm: The Rift Game Data Archive

Chasm: The Rift Game Data Archive files hold the main game data for Chasm: The Rift, a first-person shooter released in 1997 by Action Forms. These archives are created by the game to store nearly all assets - levels, graphics, sounds, scripts, models, textures - so the game can load them during play. The archive is typically named CSM.BIN in the original DOS version and csm.bin in the 2022 Remaster.

When the game runs, it reads this archive to retrieve files by name: the archive contains a file-allocation table at the start listing each contained file's name, size, and offset. There is no compression or encryption, no subdirectory structure inside the archive file itself; all files' paths must correspond to expected folder names outside the archive when extracting or replacing. In the Remaster, the archive is implemented as an uncompressed tar renamed to archive format, so standard tar tools like 7-Zip can pack or unpack it.

Internally, the file begins with the ASCII header string "CSid", followed by a 16-bit little-endian count of files. Then each table-of-contents entry includes a filename length byte, up to 12 bytes for the filename (only the number of characters indicated by the length are used), then 32-bit little-endian fields for file size and absolute file offset.

Chasys Draw IES Metadata

Chasys Draw IES is an advanced freeware raster graphics editor with layer and animation support. The Chasys suite also consists of an image converter and an image viewer.

Programs that open these BIN files

We have identified 2 BIN openers that are compatible with this specific type of BIN file.

Cisco Firmware

Cisco Firmware files are packaged software images created by Cisco for its network hardware such as routers, switches, and Unified Computing System components. These firmware bundles include the complete operating system, feature sets, device drivers, and hardware-specific code required for the device to boot and run its functions. The firmware may also include multiple firmware components such as system, kickstart, and management modules, depending on the platform.

Creation happens at Cisco during the software build and release process; the firmware image is then distributed to customers for manual installation or remote upgrade. During installation, devices copy the .BIN firmware into their flash memory (for example, "bootflash:") and then either execute directly or extract contents into separate packages depending on the mode (bundle mode vs installed mode). Administrators typically verify firmware integrity using MD5 or more modern cryptographic signatures delivered alongside the firmware before activating the image.

Internally, firmware files begin with a small header that includes metadata such as image length, version, platform type, compression type, verification type, and build timestamp. After the header, the image often contains a self-extracting archive structure (for example compressed content such as tar/gzip) that starts with standard archive magic numbers. Filename conventions are meaningful: the name encodes platform identifier, feature set codes (such as "k9" for cryptography), run-time memory location codes (like "m" for RAM), compression format codes ("z", "x", etc.), version and release designators, plus indicators of whether the image is signed and its release type.

CloudCompare Data File

CloudCompare is a 3D point cloud processing software used to find differences in 3D points. It is often used with laser scanners.

Programs that open these BIN files

We have identified one BIN opener that is compatible with this specific type of BIN file.

CoolCV Snapshot

CoolCV Snapshot files store a complete saved state (snapshot) of the CoolCV emulator. CoolCV is software that emulates the ColecoVision console (as well as the Coleco Adam and Sega SG-1000), allowing pause, resume, and save/restore of gameplay states. Snapshot files preserve the emulator's entire internal state, so that when reloaded the system returns precisely to the moment at which the snapshot was taken.

These files are created by the CoolCV emulator during gameplay when the save/restore snapshot feature is used. They are read by the same emulator to restore the state - your exact position, memory, registers, and video frame - but are not used by the original hardware. Such snapshots are useful for preserving progress, debugging, or sharing saved moments across different sessions.

Files begin with an ASCII header signature: the first 7 bytes are the string "CoolCVv " (that is C-o-o-l-C-V - v-space), followed by specific version data at byte 9. The signature is "43 6F 6F 6C 43 56 20 76" at offset 0, with an additional byte (0x2E) at offset 9.

Escu:de Engine Resource Data

Escu:de Engine Resource Data files serve as archives used in visual novel games built with the Escu:de engine. They bundle together many resource files - such as graphics, backgrounds, sound effects, voices, scripts, and more - so the game can load all needed assets from one packaged file.

These archives are produced by the Escu:de engine, which structures its data into named internal entries. During development or packaging, individual files are collected and encrypted or compressed as part of the archive. Tools made for handling this format locate and extract each entry so that script writers, localizers, or modders can access or modify game assets.

The archive format named "ESC-ARC" begins with an ASCII header "ESC-ARC" at the start of the file. Inside the archive is a version byte (often part of a header "ESC-ARC2" for newer releases), followed by an initial seed used in XOR-style obfuscation, then counts and offsets for the directory of entries. Each entry's metadata records the file's name, its starting offset, and its size. Non-image resources are often further compressed using LZW compression, typically beginning with a sub-header "acp" and using big-endian byte order.

ESP8266 Device Firmware

ESP8266 Device Firmware is the raw firmware image produced for Espressif's ESP8266 microcontroller. It combines the device's bootloader, application code, libraries, and configuration data into a single binary so the chip's built-in ROM bootloader can verify and execute it directly from flash memory.

The format is created by Espressif's tools such as elf2image (or other firmware-build tools included with the ESP8266 SDK or RTOS SDK). Once produced, it is flashed into the SPI flash memory of an ESP8266 board using tools like esptool, so that on power-up the device starts executing at the image's entry point.

The file begins with an 8-byte header. The first byte is always 0xE9. The second byte is the number of data segments in the image. The third byte encodes the SPI flash mode (e.g. QIO, DIO, etc.). The fourth byte's high 4 bits encode flash size (e.g. values for 512KB, 1-4MB, etc.), and its low 4 bits encode SPI flash frequency (e.g. 20, 26, 40, or 80 MHz). Bytes 4-7 give the CPU entry address. After the header come the data segments, each with its own address and length, followed by a footer: zero padding to align, then a checksum (xor of all data bytes and 0xEF).

Espressif ESP32 IDF Application Image

The Espressif ESP32 IDF Application Image format stores a compiled firmware/application built with Espressif's ESP-IDF framework. It is what developers generate when building an ESP32 project - for example using idf.py - and what the ESP32 bootloader loads from flash to run. Its purpose is to encode the application's code and data segments along with metadata needed for boot, versioning, integrity checks, optional security signing, and Over-The-Air (OTA) updates.

This image is assembled into several parts. First is a header (esp_image_header_t) specifying how many memory segments follow, the SPI flash mode, size, frequency, flash chip size, entry address, and range of chip revisions supported. Next comes one or more segment headers (esp_image_segment_header_t), each followed by the actual data for that segment, mapped to particular memory addresses (IRAM, IROM, DRAM etc.). After all segments, there is a one‐byte checksum. Optionally, a SHA-256 "simple hash" of all preceding content can be appended when a header field (hash_appended) is set. If secure boot or signed apps are enabled, a cryptographic signature or signature block may also be added.

Within one of the memory segments (specifically the DROM segment) appears a fixed structure called esp_app_desc_t. It holds project metadata including a magic word, the image's version string, project name, compile date and time, the IDF version, and a SHA-256 of the ELF application (among others). This descriptor sits at a known offset relative to the start of the image, allowing OTA updates or bootloader checks to identify whether to accept the image.

Bytes near the beginning help identify files of this format. For example the very first byte is a magic identifier (ESP_IMAGE_HEADER_MAGIC, whose value is 0xE9), segment count, flash mode and size fields appear shortly after the header. Strings commonly found in the image include diagnostic messages ("ERROR A STACK OVERFLOW", "GURU MEDITATION ERROR", etc.) and keywords like "VERSION", "PROJECT_NAME", "FLASH" among others; these strings are embedded by components of the framework.

Free42 State

Free42 State format files store all of a Free42 instance's internal data so the calculator state can be saved, restored, or transferred. They include every active feature such as programs, variables, the automatic stack, flags, custom and programmable menus, the ALPHA register, and solver/integrator state. Such files are created by the States → Export (desktop) or States → More → Share (mobile) features in the Free42 application.

These files are typically used to capture the exact running condition of Free42 so that work can continue seamlessly or be moved between instances. Importing a state file fully replaces the current state in memory. Desktop versions store the current state internally in state.bin (alongside print.bin and keymap.txt), while mobile and DM42 versions save state data in files with the .f42 (formerly .s42 on DM42) extension.

Files in this format begin with the ASCII signature "24kF" at offset 0, indicating the magic number or file header identifier.

Gamate Game ROM

Gamate Game ROM files store complete game data dumped from ROM cards made for the Gamate handheld console produced by Bit Corporation (later handled by UMC). They hold exactly what the original cartridge provides: executable code, graphics, sound data, and any fixed content needed for the game to run under an emulator or replica hardware.

Game data is typically read-only in use and does not change during gameplay. The ROM card from which the dump comes has a specific capacity aligned with the hardware constraints of the Gamate, which uses a 2 KB-ROM chip in its basic configuration. These dumps preserve the full binary contents of the cartridge so that emulators like MAME can replicate the original hardware behavior.

At certain byte offsets the ROM includes identifying signatures. For example, the ASCII string COPYRIGHT BIT CORPORATION appears starting at offset 5. A single byte of value 0x01 appears at offset 2. Other distinctive bytes like 0x4C show up at offsets 32 and 38. These signatures help tools recognize genuine Gamate ROM dumps and distinguish them from other files with the same extension.

Gemtek Router Firmware

Gemtek router firmware is a binary image used by Gemtek networking devices to load their operating system and supporting software. It contains everything needed for booting, including a bootloader, a Linux kernel, and a filesystem. This image is written by Gemtek (or their device firmware tools) and then installed (flashed) to the router's non-volatile memory to replace or update the device software.

The firmware image is typically structured into several partitions or segments corresponding to different functionality: a bootloader region, environment (U-Boot variables), kernel code, root filesystem (often SquashFS), and sometimes duplicate or backup partitions. During an update, one partition is overwritten while others may remain intact to provide redundancy. For routers using MIPS architecture, updates are often applied via web interface, TFTP, or from U-Boot.

The firmware image starts with the ASCII signature GMTK at offset 0, followed by the ASCII string "LinuxKernelImage" at offset 64, and the string "zImage" at offset 106. These identifiers allow tools to recognize the image format.

GoDEX Character Translation Table

GoDEX produces barcode scanners, printers, and related barcode and label design software.

Programs that open these BIN files

We have identified one BIN opener that is compatible with this specific type of BIN file.

GPS (MTK Chipset) Tracklog

This file format is used by GPS logging devices based on the MTK chipset.

Grandstream Ringtone

Grandstream Ringtone files store custom ringtone audio data for Grandstream's IP phone and DECT handset devices. These are created using Grandstream's Ringtone Generator tools. Users select a source audio file (commonly WAV or PCM), convert it via the tool to the appropriate format, generate one or more ringtone files named "ring1.bin", "ring2.bin", etc., and upload them to the phone's server. The base station then distributes the chosen ringtone file(s) to individual handsets via provisioning.

These ringtone files contain linear PCM audio, specifically 16-bit, mono, sampled at 8000 Hz. If the original audio is stereo or sampled at a higher rate, it is downsampled to 8 kHz and mixed to mono during conversion. File size limits are imposed: for newer DECT base models such as DP750 or DP720, up to ten custom ringtone files can be stored, each no larger than 128 KB. Earlier desk phone models often supported three ringtone files, each limited to approximately 64 KB.

Each ringtone file begins with a header that includes identifiable byte signatures. These include specific bytes at offsets 0 and 6, and the ASCII string "ring.bin" at offset 16. The string "RING.BIN" also appears somewhere in the file.

HackRF Firmware

HackRF firmware files serve as the low-level control programs used inside HackRF-series software-defined radio devices made by Great Scott Gadgets. These files are written into the device's SPI flash memory, or loaded temporarily into RAM in recovery or development contexts. Their purpose is to implement the radio's core logic: USB communication, radio transmit/receive functionality, board ID handling, and support for different HackRF variants such as HackRF One, HackRF Pro, Jawbreaker, and Rad1o.

Creation of these firmware binaries happens via building HackRF's firmware source code (notably the hackrf_usb project) using the ARM GCC toolchain and dependencies like libopencm3. Once compiled, the result is a binary image specifically tied to a board model. Updating or installing such a firmware requires tools provided by the project: hackrf_spiflash writes the firmware to the device's SPI flash (e.g. using hackrf_spiflash -w hackrf_one_usb.bin), while DFU mode and dfu-util can be used to load firmware into RAM in exceptional cases (such as recovery).

The beginning of the binary includes identification data to ensure compatibility with the target device. A signature of ASCII "HACKRFFW" appears at a fixed offset (0x400 into the file), inside a firmware info structure that specifies things like structure version and which board models are supported. This structure allows the flashing utility to reject firmware incompatible with the specific board ID.

Inno Setup Data

Inno Setup Data files are archives created by the Inno Setup installer when the script's [Setup] section enables disk-spanning. They store the compressed payload (all the actual files to be installed) separately from the main setup executable, allowing the installer to split its data into one or more "slice" files. These archive files are used during installation: the setup executable reads from them to extract and deploy the installed files.

The Inno Setup compiler writes these data archives when the directive DiskSpanning=yes is set. The names are normally like setup-0.bin, setup-1.bin, etc., where each contains part of the installer's data slices. The installer executable must be present along with all the .bin archive slices to perform installation properly.

Files of this format begin with a 4-byte signature 0x7A6C621A (ASCII "zlb" with an extra control character) at offset zero. The archive also contains the ASCII string "SETU" somewhere inside, which helps tools recognize it.

Leapster Cartridge Image

Leapster Cartridge Image files hold the complete program data from a LeapFrog Leapster educational cartridge game. Each is a raw dump of a game's read-only memory (ROM) content exactly as stored in the cartridge, used for archival or emulation of Leapster games. The images are produced by copying the full ROM from the physical cartridge.

The images typically include the game's code, graphics, audio, and other assets all merged in sequence just as the original cartridge presents to the Leapster console. Emulators treat these images as standalone cartridges, reading them directly like real hardware would. Several known images are 8 MiB in size (for example, "Learning with Leap" is 8 megabytes) for many titles, while others vary depending on the version or game.

Identification can use internal strings and signatures embedded in the ROM. For example at offset 256 the ASCII string "CopyrightLeapFrog" appears; other common markers include "LF_REGISTERCALLBACK'DOCALL", "LF_SETMASTERVOLUME", "PROJECT.XML", among many strings beginning with "LF_", which are commands or identifiers in the LeapFrog ROM architecture.

Linksys RT31P2-NA Firmware

Linksys RT31P2-NA firmware files contain the internal operating software built for the RT31P2-NA router, a broadband router equipped with two VoIP phone ports. These firmware files are produced by Linksys (a division of Cisco) to upgrade the router's functionality and fix issues. They package both the routing and voice processing software so the router can handle network traffic and manage Internet phone service.

The firmware image is written by Linksys and installed using the router's web-based administration interface. Once a file has been selected in the Firmware Upgrade section under Administration, the router overwrites its existing firmware with the new one, and reboots. The firmware versions are typically labeled like "RT31P2_NA_v1.30.04_000_VM_3.1.07_LIa_combin_code.bin" where different parts indicate the version of the router-firmware, module names (e.g. Router vs Voice), and build identifiers.

Internal identification is possible by examining the early bytes of the file: it begins with the ASCII characters "P2NA" at offset 0, and somewhere inside contains the string "LSINTEG FIRMWARE".

Linux Kernel/bootloader/tools X86 Bootable

Linux Kernel/bootloader/tools X86 Bootable files are small binary programs that serve as the very first code run by the BIOS on legacy x86 computers. They are real-mode boot sectors or initial bootstrap code, produced by the Linux kernel build process, to allow bootloaders or firmware to load the rest of the kernel image from disk. These files include the "bootsect" code, which is 512 bytes long and placed at the start of the kernel's bootable archive.

The Linux build system generates these files when building old-style Linux kernels that use protocol version before 2.00. Examples include the very early zImage/Image kernel formats (commonly named "linux", "bootsect.b", or "memtest86+.bin"). During boot, BIOS loads one of these bootable binaries to address 0x07C0:0x0000 or similar, where its real-mode code executes to load further setup, switch to protected mode if applicable, load an initial ramdisk if present, and jump into higher privileged code.

Inside the binary, the layout of its 512 bytes follows the Linux i386 boot code specification. The last two bytes at offset 510 - 511 must be the boot signature 0x55AA. A word at offset ~0x1FE holds this magic. Fields earlier in the sector include setup_sects (offset 0x01F1), root_flags, syssize, and others, matching the structure defined in linux/arch/i386/boot/bootsect.S. The first bytes include a jump instruction to skip over header data, and a "HdrS" magic field appears at offset 0x202 for protocols 2.00 or later.

Internal identifiers include the boot signature value 0xAA55 at offset 510, a jump instruction at offset 0, and fields like setup_sects (byte at 0x1F1), HdrS at 0x202 ("HdrS" = ASCII 0x53726448) which determines boot protocol version.

LMMC Encoded Router Configuration Backup

LMMC Encoded Router Configuration Backup is a proprietary router configuration backup file produced by D-Link and similar routers whose backup files begin with the ASCII signature "LMMC." It is used to store a router's settings - including wireless network keys, login credentials, ISP account data and other configuration parameters - in an encrypted or encoded form. Such files let users save a snapshot of their router's configuration so that it can later be restored if the router is reset, replaced, or otherwise altered.

This format is created by the router's built-in "backup configuration" or "export settings" feature via the router's web interface. Because the data is protected, typical users cannot directly read or edit this .BIN file without using a tool that understands the LMMC encoding. One such program is RouterPassView; it can detect the "LMMC"-signature format, decrypt or decode the file, and display stored passwords and settings for recovery.

Internally the file begins at offset zero with the four ASCII bytes "LMMC" which uniquely identify this specific format.

Programs that open these BIN files

We have identified one BIN opener that is compatible with this specific type of BIN file.

Marvel Appfw Firmware

Marvel Appfw Firmware is a binary firmware format created for Marvell's 88MW30x series microcontrollers to hold application (app) firmware images. It packages executable code and data intended to run on the MCU after the bootloader has performed initial startup. Its purpose is to be flashed into device memory so the microcontroller can execute application-level functions such as managing Wi-Fi and other features.

Firmware makers construct this format by compiling application code to an ELF (Executable and Linkable Format) file, then converting it into the proprietary binary layout using a tool in Marvell's SDK called axf2firmware. Once transformed, this binary is used by device firmware update mechanisms or by bootloaders of Marvell's 88MW300/302 chips. Utilities have been developed to reverse the format back into ELF (e.g. firmware2elf) so that analysts and toolchains can inspect or analyze the firmware contents statically.

On the inside, the file begins with a fixed header using little-endian byte order. The first four bytes are the ASCII signature "MRVL". It includes a hardcoded constant (0x2E9CF17B), a UNIX timestamp for creation time, the number of segment headers that follow (up to 9), and an ELF version identifier. Each segment header specifies a segment type (always 2 for application firmware), its offset in the file, size (a multiple of 4 bytes), virtual address where it will execute, and a CRC-32 checksum over the padded segment data. Segment data is aligned and any padding is filled with byte value 0xFF.

Mass Effect 3 Coalesced Data

Mass Effect 3 Coalesced Data holds compiled configuration values used by the Mass Effect 3 game engine to define nearly every gameplay, UI, and content parameter. It is a data file produced by BioWare, output as a tool's build or update process, that combines dozens of INI-style configuration sources into one optimized binary form for runtime reading.

This file is created by the game and by tools such as ME3Explorer or Mod Manager when packaging or patching Mass Effect 3 (including DLCs and mods). It is read by the game engine at startup or when certain DLCs are loaded, overriding or extending base game behaviour. When edited, it is typically decompiled into text (XML or JSON) to allow edits, then recompiled back into the same binary structure to be usable in the game.

The contents cover dozens of INI groups - about 25 in the base game - and many fewer in DLCs. Each group controls a specific set of parameters: for example, bioui.ini influences user-interface related settings such as HUD scale, FOV, keybindings; bioinput.ini covers input controls; biogame.ini covers gameplay variables like weapons, power functions, and economy; and DLC versions contain subsets relating only to the new or modified content.

Binary layout includes internal identifiers such as ASCII signatures. The file begins with a specific header ("mrmf" followed by version markers and counts) and contains strings like CONFIGCOALESCEFILTER that help identify the format.

MediaTek Combined Download Agent Package

The MediaTek Combined Download Agent Package is a special firmware component created by MediaTek. It provides low-level code that a tool or host (for example SP Flash Tool or mtkclient) sends to a MediaTek-powered device when it is in its BootROM or Preloader stage in order to perform critical operations such as flashing firmware, reading or writing flash memory, unlocking or relocking security features, accessing e-fuses, or performing device-level diagnostics.

This package is not something the device stores permanently. It is loaded temporarily into RAM over a serial or USB link and executed by the device's BootROM or Preloader to enable trusted, controlled access. When MediaTek or a service provider builds firmware toolsets, they bundle or create a Download Agent file specific to - or in some cases covering multiple - chipsets. It is used during device recovery, firmware updates, or during development, and is paired with authentication mechanisms if the device's secure boot or download agent authorization (DAA) features are enabled.

Files of this type always begin with a fixed signature string in ASCII: at offset 0 the characters MTK_DOWNLOAD_AGENT mark the start of the file. That signature is followed by metadata including an internal version number, an identifier string (for example MTK_AllInOne_DA_v3 in XFlash protocol), the count of supported System-on-Chip (SoC) entries, and then a table of entries each describing what part of the file is meant for which chipset (hardware code, revision), what memory regions will be loaded, their offsets and signature lengths.

Micomsoft Framemeister Profile

Micomsoft Framemeister Profile files hold configuration settings for the XRGB-mini Framemeister video upscaler sold by Micomsoft. They store saved user presets (known as profiles) which include video processing parameters such as scaling, input type calibration, image mode, color and noise adjustments. These allow the device to quickly switch to tailored settings for different consoles or displays without re-adjusting manually each time.

These profiles are generated and saved by the Framemeister itself after a user has adjusted the settings via its menus. To use third-party or custom profiles, the .BIN file must be placed in the EEPData folder on the Framemeister's micro-SD card inside the XRGBmini directory. The device only allows up to 20 profiles to appear in its menu for loading via DATA → LOAD_SELECT or DATA → LOAD. Some settings (for instance zoom status) are not fully applied when using LOAD_SELECT but are when using LOAD. Profile files are typically named something like EEP001.BIN, and filenames are limited to 8 characters.

Technical identifier details are not publicly documented in full depth. They are binary, non-text files saved by the device. Insiders note fields corresponding to settings like IMAGE_MODE, H_SCALER, V_SCALER, zoom horizontal/vertical position, and color calibration among others, though precise offsets or signature bytes are not available publicly.

Mozilla Script Cache

Mozilla Script Cache files store a cache of JavaScript code used during Firefox's startup in order to speed up later launches. These files are produced by Firefox, specifically by its ScriptPreloader subsystem. The cache contains scripts that were loaded during the previous session so that Firefox can pre-load or reuse them early on. It makes startup smoother by avoiding re-parsing those scripts, improving performance.

Firefox both reads and writes these files. At startup, Firefox looks for a previous startup cache file and loads script definitions from it; at shutdown or after startup, it writes a new cache file that includes only those scripts used in the early-launch phase. Child and parent processes have separate cache files (e.g. scriptCache, scriptCache-child), and there is logic to rename or move old files to "-current.bin" to manage versioning across sessions.

The format begins with an ASCII magic string "mozXDRcachev003" (previous versions used "mozXDRcachev002\0") followed by a 32-bit little-endian header size, a CRC32C checksum of the header block, then a header block that describes multiple cached scripts. Each script entry includes its key (URI/path), offset, size, and which process types used it. After the header, the encoded script bytecode data ("stencil-XDR") is laid out, aligned to the required boundary. Integrity checks ensure corrupted or partial cache writes are detected.

Multipaint Image

Multipaint is a drawing application used to draw pictures with the color limitations of some typical 8-bit computer platforms like the Commodore 64, ZX Spectrum, Amstrad CPC, and Atari ST.

Nintendo Switch Atmosphere Firmware Fatal Error Log

The Nintendo Switch Atmosphere Firmware Fatal Error Log is a diagnostic file created by Atmosphère (a custom firmware for the Nintendo Switch) whenever a fatal system-level error causes the system to crash. It records a binary memory dump capturing the stack and thread-local storage (TLS) contents so that developers or advanced users can analyze what went wrong. These files are saved to the SD card under sdmc:/atmosphere/fatal_errors/ or sdmc:/atmosphere/fatal_reports/dumps/ with filenames including a timestamp and the Program ID of the crashing process.

This log is generated by the Atmosphère fatal service whenever an unrecoverable error occurs. It works together with other reporting infrastructure (creport) which logs human-readable crash reports; this .BIN file provides raw binary data that those reports cannot include. The data includes the full register state of the CPU, the latest 32 return addresses on the call stack, a section of the stack's memory, and TLS memory dump.

Inside the .BIN file, the structure begins with a header identifying CPU architecture (for example AArch64), the crashed process's Program ID, the instruction pointer (PC), stack pointer (SP), link register (LR), and frame pointer (FP). After the header follow serialized sections for the stack backtrace - up to 32 return addresses - then raw bytes for a fixed-size region of the stack and TLS memory.

Nullsoft Install Data

Nullsoft Install Data files store embedded installer data used by executables built with the Nullsoft Scriptable Install System (NSIS). They are appended to NSIS setup or uninstall executables so that all the files to be installed or removed are contained inside the single executable.

When NSIS compiles a setup or uninstaller, it embeds a compressed archive containing program files, resources, scripts, UI graphics and other assets into the end of a Windows PE executable. After installation, the embedded data is extracted and placed in the target directories as described by the NSIS script.

Files created as Nullsoft Install Data are not standalone applications. They are produced by the NSIS compiler and read only during execution of the NSIS installer/uninstaller which contains them. The NSIS toolchain (specifically the installer EXE) is responsible for extracting and acting on this data.

Internal structure includes a signature identifying the start of this embedded installer data. At offset 0 bytes in the data segment there is the four-byte little-endian value 0xEFBEADDE (hexadecimal for DEADBEEF), followed by the ASCII string "NullsoftInst…" signaling the beginning of NSIS install data.

Pascal Script Binary

Pascal Script Binary (also known as IFPS) files store compiled scripts written in the Pascal Script language so that they can be run without requiring the original source code. These files are produced by the Pascal Script compiler (used in tools such as Inno Setup) and contain bytecode that the Pascal Script runtime interprets. They enable script-based custom logic - such as installer behavior - to run efficiently while keeping the implementation details hidden.

Keys inside a Pascal Script Binary file include type definitions, procedure definitions (both declared in the script and external ones), global variables, and the main entry procedure. The script compiler serialises all imports, names, types, global variables, and the bytecode into a single blob, which the runtime loads and executes. If an installer or software package uses scripting sections, that compiled script is embedded via this format, then disassembled or executed by the runtime.

Every Pascal Script Binary begins with a 28-byte header record. The first four bytes are the ASCII signature IFPS ("InnerFuse Pascal Script") in little-endian order. Following that are fields such as build number, counts of types, procedures and variables, the index of the main procedure, and an import table size placeholder.

Pebble Application Binary

Pebble Application Binary files are the compiled output of a Pebble smartwatch app or watchface. These include both the app's executable code and metadata such as name, version, developer, icon, UUID, resource data, and build information. The Pebble SDK produces them when an app project is built for installation onto a Pebble device.

Such files are uploaded to a Pebble watch using Pebble's app‐management tools. During installation, the metadata in the binary is parsed by the Pebble OS to display the app's name and icon, verify version compatibility, check permissions or capabilities (e.g. whether it is a watchface), assign resource IDs, and execute the app starting at its given entry point. The watch firmware uses a relocations table within the binary to adjust in‐flash addresses after loading.

Internally, the binary begins with an 8‐byte ASCII header string "PBLAPP" (plus a null), which identifies it as a Pebble Application Binary. Just after that, a PebbleProcessInfo struct appears, containing fields such as struct_version, sdk_version, process_version, load_size, filename offset, CRCs for code and resources, the app's name and company strings (each 32 bytes), icon_resource_id, number of relocation entries, virtual_size, offset to the entry point, UUID, flags (e.g. indicating watchface or visibility settings), and a symbol table address.

PrintFox Bitmap

PrintFox Bitmap files are raster‐graphics images produced by the Printfox or Pagefox desktop publishing programs for the Commodore 64, developed by the German company Scanntronik in the mid-1980s. They combine text and graphics inside a graphic work area, normally at screen resolution, and are used for designing and printing pages.

Images are created or edited inside Printfox/Pagefox and are saved in several related formats which differ chiefly by their resolution and purpose. The 320×200 mode (called "Bildschirm" or BS format) is used for screen‐size graphics; a larger 640×400 mode (GB format) provides higher fidelity for full page layout; the PG (Pagefox) format allows arbitrary dimensions between small and very large page-sized graphics. All formats support optional run‐length encoding (RLE) compression to save space.

Each file begins with a format tag byte that identifies the mode: 'B' (hex 42) for the 320×200 BS format; 'G' (hex 47) for the 640×400 GB format; 'P' (hex 50) for PG files. In the BS and GB formats, compressed files include an additional pack byte $9B before run and count segments; BS and GB count fields are one byte (BS) or two bytes (GB) long. The PG format also includes in its header the image width and height expressed in tile or block units (second and third bytes of the file in that format). Nothing beyond those elements (pixels, RLE-segments, header) is reliably documented.

PSP PGD Encrypted

PSP PGD Encrypted files store protected game data from Sony-PlayStation Portable (PSP) platforms, used to keep parts of a game package, such as manuals (DOCUMENT.DAT), PS1 Classics, minis dossiers, or other modules, in encrypted form. The "PGD" is short for Protected Game Data. The format is used by PSP, minis and PS1 Classic titles distributed over PSN, and by the PSP firmware to enforce DRM by hiding certain assets until the system decrypts them.

A PGD encrypted file is produced during the packaging or updating of a game on Sony's distribution system. When a game is downloaded or installed (often via PKG or EBOOT.PBP), content that must remain unseen or protected - such as user manuals, press materials, or certain game data - is wrapped into PGD encryption so that the file cannot be read directly. Once the PSP or compatible system has the necessary keys ("Secure Install ID", "PSP HMAC Key", etc.), it decrypts and uses the data at runtime.

Technical characteristics include the file beginning with the ASCII signature "\0PGD" (bytes 00 50 47 44) at offset 0. The header following that includes fields like key index, DRM type, and a reserved field; an encapsulated header section; and later a portion for a message authentication code (MAC) or digest - used to verify integrity.

QubIDE Disk Image

QubIDE disk image files are sector-by-sector snapshots of storage devices prepared with the QubIDE interface for the Sinclair QL computer. They store the entire contents of an IDE drive (such as Compact Flash, SD-IDE adapters, DOMs, or hard disks) formatted using the QubIDE format, including all partitions, directories, and files exactly as they were seen by the QL system. These images are used for preserving the logical layout of the storage or transferring the contents between QubIDE-formatted media and hosts such as PC using companion tools.

The QubIDE format was developed by Zeljko Nastasic and later supported by Qubbesoft with driver software and utility programs which create, format, partition, and read/write these IDE devices under Sinclair QL. Original hardware with correct ROM (for example, versions 1.56 or higher, or updates under version 2.x with updated GAL chips) mounts and uses drives formatted with QubIDE partition layout. PC-side utilities such as "Disk Utility" and "partition_exe" generate and manage these images for devices of various capacities, handling primary and secondary partitions, block size settings, and drive geometry for compatibility.

These image files begin with a distinctive signature in their header which identifies them as QubIDE disk images. Specifically the first bytes of the file at offset zero are ASCII "QLW1QL-SD", stored as the byte sequence 0x51 0x4C 0x57 0x31 0x51 0x4C 0x2D 0x53 0x44.

Rasberry Pi EEPROM

Raspberry Pi EEPROM files store the internal bootloader firmware used by newer Raspberry Pi models. They are created by the Raspberry Pi bootloader project (rpi-eeprom) and loaded from on-board SPI flash EEPROM instead of being read from the SD card as in older models. These firmware files control the early-stage boot process: initializing SoC components, discovering boot sources (SD card, USB, network), and executing whichever second-stage loader is specified.

Images used for EEPROM updates - such as those named pieeprom-2021-10-04 - include both the bootloader code and its configuration. These update images are applied using Raspberry Pi tools like rpi-eeprom-update; they are typically binary files that combine firmware and metadata. They are also accompanied by checksum files (like pieeprom.sig) to ensure integrity.

Technically these firmware files begin with a magic pattern of bytes 0x55AAF00F at offset 0. They also contain a number of ASCII-strings at fixed offsets, such as "BOOT_UART", "POWER_OFF_ON_HALT", "BUILD_TIMESTAMP" and other configuration and diagnostic keywords.

RDP Bitmap Cache

RDP Bitmap Cache files are used by the Microsoft Remote Desktop client on modern Windows systems for persistent caching of graphical elements transmitted during remote sessions. These files store small bitmaps that the server sends to the client so that repeating visual elements - icons, window frames, buttons - need only be sent once and thereafter are reused from local cache, which improves performance and reduces bandwidth. They are automatically created when the Persistent Bitmap Cache feature is enabled in the Remote Desktop client, especially from Windows 7 onward.

These cache files are written by the Remote Desktop client on the user's machine. After the header, the files contain multiple entries, each corresponding to a cached bitmap: dimensions, color depth, and the raw bitmap data. On subsequent remote sessions, the client reads these entries so that the server does not need to resend bitmaps it already holds in cache. Tools exist that can parse these .bin cache files to extract and analyze the stored bitmaps.

File identity is confirmed by an 8-byte signature at the very start of the file: the ASCII string "RDP8bmp" followed by a null byte.

Realtek Router Configuration

Realtek Router Configuration files store the settings used by certain Realtek-based networking devices, such as routers and gateways. They are generated by the device's firmware when a backup of the device configuration is saved, and are used later to restore the exact same configuration. Settings inside include wireless credentials, network and firewall rules, MAC addresses, device names, administrative structure, and other parameters needed for the router to operate in its intended network setup.

These files are written by the router itself (or by its firmware interface via a web GUI or management portal) and read by that same firmware when restoring. The file may be encrypted or signed to prevent tampering, and sometimes tied to version of firmware so that restoring across versions is either blocked or warned against.

File signatures show identifiable markers: the file begins with the ASCII string COMPCS starting at offset zero (bytes "43 4F 4D 50 43 53"). This signature uniquely identifies the file format as Realtek Router Configuration.

RetroTINK-4K Firmware

RetroTINK-4K firmware files are binary firmware images used exclusively by the RetroTINK-4K video processor/scaler made by RetroTINK LLC. They are provided by the vendor and are installed to update or replace the internal operating software of the device. These firmware images enable new features, improvements, bug fixes, enhanced hardware compatibility, and refinements to video processing performance.

These firmware images are created by RetroTINK LLC and distributed via their official Firmware Repository. To install one, its binary file - typically named "rt4kup.bin" - is placed on the root of the SD card used with the RetroTINK-4K. The device either installs the firmware via its on-screen menu ("Check SD Card" option), or automatically during boot when the Reset button is held as power is applied.

Firmware versions are released in two tracks: stable "Release" builds and more frequent "Experimental" builds. Each build carries a version number (for example "1.9.6" in the stable track, "1.75.0" in experimental as of August 2026) and includes a changelog that describes added features, tweaks to video/audio input processing, scaling improvements, UI enhancements, and various fixes.

Binary firmware files begin with a distinctive header string identifying them as RetroTINK-4K firmware images. At offset zero the ASCII signature "RT4KProFWImage" marks the file as a compatible firmware image for the RetroTINK-4K device.

Rigol Binary Waveform

Rigol Binary Waveform files hold waveform data exported from Rigol oscilloscopes using the instrument's binary (.bin) waveform-save commands. These files store captured signal voltages and timing metadata from enabled channels in a compact, machine-readable form that programs can import or analyze.

Rigol scopes produce these files when executing commands such as :SAVE:WAVeform <path>, which writes recorded analog or digital channel data along with associated settings and headers. Users commonly export waveform data for later viewing or processing with post-capture tools, preserving the scope's memory depth rather than just what is shown onscreen.

The binary waveform file organizes data in blocks: a global file header, followed by one or more per-waveform headers, each paired with waveform-data blocks. The file header includes a two-byte cookie "RG" identifying the format, a version number, the total file size, and the count of waveform records. Each waveform header specifies waveform type (normal, peak-detected, averaged, or logic), number of points, number of buffers, and timing parameters. The sample values are stored as calibrated analog float data (for example float32), along with digital-logic channel bits when applicable.

Byte signature RG0 at the very start of the file confirms the Rigol binary waveform format.

Saleale Logic 2 Binary Data File

Saleae Logic 2 Binary Data File stores raw captured signal data that the Logic 2 analysis application can export in "binary" form. It is produced when a user performs a raw data export in Logic 2. There are two main modes: digital, for recording state transitions on digital lines; and analog, for waveform samples on analog channels. Saleae devices acquire mixed signal captures over time, and Logic 2 writes that data into these binary files so that external tools can process or analyze the raw measurements independently of the Logic software.

Digital export files record the moments when signal lines change state; each transition is timestamped. Analog export files record voltage samples at a fixed sample rate, possibly downsampled, along with time metadata. Exported files include metadata in their headers so external parsers can interpret sample rate, timing, and data type.

Binary format versioning: Saleae Logic 2 supports two versions. Version 1 (introduced around mid-2025) is the current format for both digital and analog exports; older devices still use version 0. All multi-byte fields are little-endian. The file begins with an 8-byte ASCII identifier "<SALEAE>", followed by a 32-bit version number and a 32-bit type code (0 for digital, 1 for analog). From there the layout depends on type. In version 1 digital format, the file enumerates chunks with initial state, sample rate, begin/end times, number of transitions, then each transition's timestamp. The analog variant lists waveforms with begin time, trigger, sample rate, downsample factor, number of samples, then all voltage values as IEEE-754 floats.

Sega Genesis / Megadrive / 32x ROM Image

Sega Genesis / Megadrive / 32X ROM Image files are raw binary dumps of game cartridges for the Sega Genesis (also called Mega Drive) console and its 32X add-on. These files contain the complete Read-Only Memory (ROM) data from original physical game cartridges. They are created by hardware cartridge dumpers that read the ROM chip directly (usually via the cartridge's pins), producing a file that is usable by emulation programs and flash cartridges. These ROM images allow games to be played without the original cartridge, assuming ownership of the original cartridge under relevant laws.

These ROM image files are not modified to add headers or extra metadata - except in cases where a "copier header" exists in certain legacy formats like .SMD. They include all game code, graphics, sound, and metadata that the cartridge itself contained. Most emulators require the unaltered ROM data; if a file has extra bytes (for example from a header), those may need to be removed for proper use. The .BIN extension is interchangeable with .MD in many cases when the data is identical. The ROM data is used by emulators and compatible hardware to simulate or reproduce the behavior of the original cartridge in software or load it into flash-based cartridges for use on original hardware.

Internally, this format is identified by specific signatures near the start of the file. At offset 0x100 (256 bytes) you will typically find the ASCII string "SEGA " (hex: 53 45 47 41 20). At offset 0x110 you may see "(C)" starting at 0x110+16 bytes, and at offset 0x17F some games include "GM". The file contains the string "SEGA" somewhere else within the header region as well. These byte signatures are used by detection tools to confirm the file indeed holds a Genesis / Mega Drive / 32X ROM image.

Programs that open these BIN files

We have identified one BIN opener that is compatible with this specific type of BIN file.

Sky: Children Of The Light Level Data

We know that one BIN format is Sky: Children Of The Light Level Data. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

Sony PS3 Silk Web Browser Container Format

Sony PS3 Silk Web Browser Container Format files are data packages used by the Silk Web Browser on the PlayStation 3 to bundle UI resources, HTML content, images, menus, dialogs and other interface-related assets used by the browser. These files are embedded in the PS3 firmware, under paths like dev_flash/vsh/resource/silk/data/, and are organized so that the console's browser code can look up, load and render each piece during runtime.

These files are produced by Sony as part of the firmware for the PS3; they are not user-editable unless modified via special tools. Each Silk Web Browser Container Package holds multiple entries, each with an identifier, an offset, and length, so that the browser executable (sprx) can locate each asset via its ID. Common types of content inside include text strings (plain and HTML), image files of several predefined types (PNG, GIF, icons, cursors), and various UI components (dialogs, buttons, menus).

At the start of the file there is a header identifying the format by the ASCII signature SILKPADD. Following that are fixed-size fields: two unknown-purpose 2-byte zeroed areas, a 2-byte count of entries (little endian), another 4 bytes of zeroes, then an index table. Each index entry is 12 bytes long and gives a data entry's ID, its offset and its length (all in little endian). After the index table the data entries appear in the file.

Sony SELF - SPRX Format

Sony Signed Executable and Linkable Format (SELF) and Signed PlayStation Relocatable Executable (SPRX) files are executable modules used on Sony's PlayStation 3 and PlayStation Vita consoles. These files contain machine code produced with Sony's official SDK. SELF files are standalone executables such as games or system programs; SPRX files are shared modules (similar to libraries) that multiple programs can load and use.

Files of this kind are created during game or firmware development by Sony or licensed developers. They are digitally signed, and often encrypted, so that the console's operating system can verify authenticity and prevent unauthorized or modified code from running. SELF and SPRX files are packaged into the game system or stored in system firmware; the console loads and executes SELF files directly, while SPRX modules are linked or loaded into other executables at runtime when shared functionality is needed.

Technically, these files use Sony's proprietary SELF format that wraps standard ELF (Executable and Linkable Format) binaries with additional metadata, digital signatures, and possibly encryption or compression. They include headers that describe file size, program type, required firmware version, and content IDs. On PS4, SELF files have a header signature including a magic value such as 0x1D3D154F for compatibility and contain segment tables defining flags for encryption, signing, and compression.

SELF-SPRX files begin with identifiable bytes: the ASCII string "SCE" at offset zero, followed by two zero bytes at offset five.

Sound Images Sound Driver

We know that one BIN format is Sound Images Sound Driver. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

StarCalc Data Index

StarCalc Data Index files store the index data used by the StarCalc planetarium program by Alexander E. Zavalishin for Windows 9x. They organise information that lets the program quickly look up and display celestial objects during a simulation of the night sky, improving performance when loading star or object catalogues.

StarCalc generates a data index when assembling its internal catalog of stars, constellation boundaries, planets, comets or asteroids. This index is used each time the sky is redrawn or adjusted (for example, when changing date, time, viewing direction or zoom) so the program doesn't need to scan every data record from scratch. These files are not edited directly by users; they are read by StarCalc internally to speed up access.

Each file in this format begins with a fixed ASCII signature at the very start: bytes "SCSAOINDEX" at offset zero. The signature identifies it as a StarCalc Data Index file. The rest of the file consists of binary structures matching StarCalc's internal index tables and pointers, allowing fast lookup into its stored star and object data.

SwissMicros DM42 DMCP Firmware

SwissMicros DM42 DMCP Firmware files store the operating system (DMCP) and calculator program software for the SwissMicros DM42 (and DM42n) scientific calculator. They are used when performing firmware updates, either as a combined "combo" image (OS plus calculator application) or, since version 3.7, separately as DMCP OS ("DMCP_flash_x.x.bin") and program files ("DM42-x.x.pgm").

The files are created and provided by SwissMicros. Updates are installed by copying the firmware image to the root of the calculator's USB-mounted FAT disk and confirming the update from the device, or by switching the calculator into bootloader mode and flashing via DFU using tools such as dfu-util or dm_tool. The firmware image includes the main internal flash contents and optionally auxiliary QSPI flash data when required.

The format begins with a unique byte signature: at offset 0 the sequence of bytes "F07F0120." It contains ASCII textual messages including "BOOTLOADER MODE'CONNECT USB TO ENTER BOOTLOADER'MODE", "FIRMWARE IS NOW IN INCONSISTENT'STATE", "SWISSMICROS GMBH'STANDALONE SYSTEM FIRMWARE.' PRESS", "SWISSMICDM42", "MISSING DISK INFO", and "SAVE CALCULATOR STATE". These strings assist in detecting during the firmware update process and verifying correct format.

Symantec/Norton Config

Symantec/Norton Config files store configuration settings used by Norton or Symantec software that employs the NCFG1.0 configuration format. These files are generated by Symantec/Norton programs (such as Norton Utilities or one of the Norton/Symantec configuration utilities) to preserve user preferences or application options so the security software can restore or apply them as needed. They are not general document or media files but internal binary configuration containers.

These configuration files are not intended for manual editing. They are written in a structured binary format by Norton or Symantec components and read back in by those components when applying settings or during startup. Other programs do not typically parse them; changes should be made through the Norton or Symantec program's user interface or configuration export/import features.

These files begin with a fixed byte sequence: the ASCII header ".NCFG1.0" starting at offset 3. At the very beginning (offset 0), they include the bytes 0x2000. These signatures uniquely identify the format as the Symantec/Norton Config (v1.0) format. Contains string "NCFG1.0".

Taxman's Retro Engine Data File

We know that one BIN format is Taxman's Retro Engine Data File. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

TBAFS Compressed Archive

The TBAFS Compressed Archive format is an archived collection of files produced by TBA Software for the RISC OS operating system. It is designed to bundle multiple files and folder hierarchies into a single compressed package suitable for backup and distribution purposes on RISC OS systems.

Files in this format are created by archiving tools on RISC OS that implement TBAFS. Once created, the archive can be extracted to restore the original files and directories, preserving their RISC OS - specific metadata such as filetypes and timestamps. The compression used reduces storage space, and the format supports efficient storage of many files within directories.

Internally the archive begins with an ASCII signature "TAFS" at the very start of the file, indicating the format identifier.

Tesla Wall Connector Firmware

The Tesla Wall Connector Firmware format is a firmware image used to update Tesla's Gen 3 Wall Connector (home EV charger). It is written by Tesla and read by the Wall Connector itself during firmware update operations. The file is intended to deliver new firmware that includes both controller code and communication firmware (including Wi-Fi chipset code) so the Wall Connector can function correctly and receive feature updates.

This firmware file begins with a container header that encapsulates firmware for a Marvell 88MW30x wireless chip. That inner firmware uses its own segment-based structure to hold different code/data regions, each mapped to specific memory locations in the device. The file includes metadata such as where each segment in the image should be loaded into the Wall Connector's SoC memory, sizes of those segments, and in many cases little-endian encoded values. Tesla distributes firmware in this format for both over-the-air updates (via Wi-Fi) and offline/manual installations.

Technical identifier: The file begins with the ASCII signature "SBFH" at byte offset 0, followed by a 32-bit little-endian field giving the header size (for known firmware files this header size is 0x11C bytes).

Thomson Speedtouch WLAN Router Firmware

Thomson SpeedTouch WLAN Router Firmware is a proprietary firmware image used to update the embedded system software on Thomson (also known as Technicolor) SpeedTouch series wireless LAN routers. It packages the router's operating system, kernel, bootloader components, drivers, and other low-level software that control the device's functions.

This format is produced by Thomson/Technicolor for SpeedTouch routers. Service providers or users apply files in this format using either the device's web interface or a dedicated upgrade tool (often called the "Upgrade Wizard"). Deployment replaces or updates the existing firmware in the router's non-volatile memory so the router boots using the newly installed software.

Known counterparts of this format include files ending in ".bli", which are often interchangeable with the same images renamed as this format. The ".bli" images are commonly used with the Upgrade Wizard and contain a full Boot Loader Image (BLI) signed by Thomson.

Image layouts for certain models, for example the TG587n V2, begin with ASCII signatures such as "BLI223…" (for example "BLI223UX0"), followed by metadata fields (model names, brand, version info), cryptographic signature or checksums, and then the compressed operating system and filesystem. Files typically contain the strings "IPKG2-HEADER" and "IPKG2_SIGN" as part of their internal packaging.

Tiger Electronics Game.com Cartridge Image

The Tiger Electronics Game.com cartridge image format holds a ROM dump from Game.com game cartridges produced by Tiger Electronics. It represents the complete read-only program data that the handheld console reads directly from its game cartridges and is used in emulation or archival contexts.

The image is produced by dumping the contents of an original Game.com cartridge. Emulation programs and ROM collections use the image to run games originally released on the physical cartridges. The format is entirely read-only, and no further changes are made once the data has been dumped from the cartridge.

The size of a typical Game.com cartridge image is up to 0x200000 bytes (2,097,152 bytes) as listed in software-list metadata. The metadata also includes checksums like CRC and SHA-1 to verify data integrity.

A Game.com cartridge image can be identified internally by specific byte signatures: at offset 2, the byte value 0x40; at offset 5, the ASCII string "TigerDMGC" (hex - 54 69 67 65 72 44 4D 47 43). The file generally contains the literal "TIGERDMGC" text.

TimeTop GameKing Cartridge Image

TimeTop GameKing cartridge image files contain the full data from a game cartridge made for the GameKing handheld video game consoles developed by Timetop (manufacturer Guangzhou Daidaixing Electronics Tech Co. Ltd.). These files are used with emulators or when preserving or distributing copies of GameKing cartridges. They are not produced by the handheld itself but are dumps taken from physical game cartridges.

GameKing cartridges commonly come in two sizes: 128 KB for single games, or 512 KB for "4-in-1" multi-cartridge sets that include four separate games plus a selection menu. The images reproduce the ROM contents including any banking structures used for larger carts. Emulation systems such as MAME use these images with a required BIOS file to allow running GameKing games.

Files of this type begin with a distinctive byte sequence at the very start of the file, and contain identifying text in the header: the bytes at offset 0 are "B9 E3 D6 DD B4 FA B4 FA D0 C7 B5 E7 D7 D3 BF C6 BC BD 43 D0 CF DE B9 AB CB BE 47 45" - and at offset 29 appear ASCII text "Daidaixing Tec.Electronics Co.,ltd". The file also contains the string "DAIDAIXING TEC.ELECTRONICS CO.".

Toshiba Pasopia ROM Image

We know that one BIN format is Toshiba Pasopia ROM Image. We have not yet analyzed in detail what these files contain and what they are used for. We're working on it.

TP-Link Router Firmware

TP-Link router firmware files are the complete binary images that TP-Link issues to update the software running inside its wireless routers, including both the bootloader and embedded Linux system. These firmware blobs are created by TP‐Link, delivered via their support site, and applied over the router's web interface or recovery mechanism. Their purpose is to fix bugs, add features, patch security vulnerabilities, or support new hardware revisions.

When updating, the firmware image must match the router's model, hardware version, and region. If a downloaded firmware bundle is compressed, a firmware image file must be extracted before upload. The router's web management interface provides a "Firmware Upgrade" or "Local Upgrade" option where the firmware file is uploaded, triggering the device to replace its current firmware content and reboot into the new version. TP-Link also provides backed-up configuration files via the same interface, but these are separate from the firmware image itself.

Inside a TP-Link published firmware blob there is structure. Tools reverse-engineering version-3 firmware describe a header starting at offset 0 containing version numbers, product and hardware identifiers, an MD5 checksum, and RSA signature data. In these v3 images the bootloader section is usually bundled, padded, and the kernel and root filesystem start at defined offsets following the header(s). Most versions validate the signature during the upgrade process.

When routers write these firmware files, they typically combine bootloader, kernel, filesystem, and sometimes vendor configuration partitions. Users never edit these parts directly; firmware creators (TP-Link) build them, routers read or flash them. The image file is binary data, not human-readable. Any preserved region for configuration is encrypted or signed in many models.

TrueBeam Trajectory Log

TrueBeam trajectory log files record what Varian's TrueBeam linear accelerator actually does during a radiation treatment, in minute detail. These files are binary and are written during delivery of each beam, capturing both the expected (planned) and actual positions of all moving parts of the machine (such as multileaf collimator leaves, jaws, gantry angle, collimator angle, couch translations, and rotations), and the delivered dose in monitor units (MU), sampled at fixed short intervals. They are primarily used for verifying delivery accuracy, performing quality assurance, and analyzing mechanical performance of the treatment machine.

Production of a trajectory log begins when beam delivery starts (or resumes after gating or hold), and the machine control system periodically samples all relevant axes, usually every 20 milliseconds, for durations up to about 20 minutes. The machine projects the positions of the MLC leaves to the isocenter plane at the moment they are recorded. After delivery is complete, the log file including a fixed-length header, descriptors for subbeams (if used), and the full time-series axis snapshot records is saved by the TrueBeam control system.

Inside the binary file, the header begins with the ASCII signature VOSTL and includes metadata such as version number, header size (commonly 1024 bytes), sampling interval, enumeration of axes, number of subbeams, and number of snapshots. Following the header, each subbeam has entries listing internal control point, planned dose (MU) for that subbeam, expected irradiation time, sequence number, and name. After the subbeam listings comes the axis data: for every snapshot, expected vs actual values for each sampled axis. Numeric values like linear positions are stored in centimeters, rotations in degrees, and dose in MU. Integers and floats use little-endian format.

Ubiquiti Firmware

Ubiquiti firmware files are images used to upgrade the internal software of Ubiquiti network equipment such as routers, switches, access points, gateways, and controllers. These firmware images are published by Ubiquiti on their official servers and downloaded either manually or automatically. Specialized tools or device bootloaders then install them onto devices using commands such as "upgrade", "syswrapper.sh upgrade2", or "fwupdate". These files ensure devices run updated, secure, and feature-rich operating system components.

Creation of these firmware images is done by Ubiquiti itself. They bundle multiple partitions into the image, often including bootloader, kernel, file system (often SquashFS), rootfs, configuration sections, and partition metadata. Devices first verify the firmware's integrity (using checksums and signatures), then swap in the new firmware image by writing it to a "secondary" partition, marking it for boot, and rebooting. Some models maintain two firmware images so they can revert if the new version fails.

Files begin with a four-byte ASCII header "UBNT", followed by a header checksum (CRC32) and metadata including version strings. Keywords that often appear inside the file include "DATE", "FIRM", "PATH", "LOAD". These strings, along with the header structure, help tools recognize the file as a valid Ubiquiti firmware image.

V86 Saved State

V86 Saved State files record everything needed to pause and later restore a virtual x86 PC running inside the v86 emulator in the exact same condition. Those files are created by v86's save_state API, which serialises the entire emulator state (CPU registers, memory, device states etc.) into a binary ArrayBuffer, so that restore_state can bring it back from that snapshot.

Each saved state includes all typed arrays and internal variables for every device in the emulated machine. It typically contains the contents of RAM and VGA memory, state of the CPU (registers, instruction pointers, flags), I/O device states, disk and filesystems, network configuration, and any floating-point or specialized hardware state (such as FPU), so that execution resumes seamlessly. Versions of v86 may alter the serialisation format, so a saved state must be restored using the same major emulator configuration (memory size, BIOS/disk images etc.) that was used when it was created.

In technical terms, the file begins with a fixed binary signature (for example bytes 0x7686768606000000 at offset 0, ASCII "v.v…") identifying it as a v86 saved state, followed at later offsets by JSON-style labeled data including buffer_infos with fields like OFFSET, LENGTH, BUFFER_ID and type identifiers like FLOAT64ARRAY, UINT8ARRAY etc. Internal strings like VERSION, MEMORY, DRIVE, SYSTEM, BUFFER_INFOS etc. appear throughout the file, allowing the code to map buffers in the file back into the emulator's state.

VDriveQL Firmware

VDriveQL Firmware files contain the machine-code that runs on the vDriveQL hardware created by Charles Ingley. It emulates Microdrive cartridges for the Sinclair QL, storing the firmware which controls the virtual microdrives, handles SD card access, implements the toolkit interface, and manages commands issued via the QL.

The firmware is produced by the vDriveZX / vRetroDesign project. To install it, the update file named VDRIVEQL.BIN is placed in the root directory of a formatted SD card. The QL's toolkit VINFO command can verify current versions before and after updating.

The firmware file always begins with the ASCII header "VDRIVEQLFIRMWARE" at offset 0, and includes the string "CHARLESINGLEYALLRIGHTSRESERVED" starting at offset 30. These signatures help devices verify the file is valid before installing to avoid damage.

VDriveZX Firmware

VDriveZX Firmware is a device update file used by vRetro Design's vDrive ZX, an external Microdrive emulator for the Sinclair Spectrum with Interface 1 expansion. It delivers updated internal software that improves features, fixes bugs, and updates which ROMs are supported.

The file is produced by the vRetro Design developer and is intended to be loaded into the vDriveZX hardware via its firmware update mechanism. Users retrieve official firmware updates from the vDriveZX website, typically as binary packages distributed in ZIP archives. Once installed, they change the behaviour of filesystem handling, toolkit commands and ROM support inside the device.

The first bytes of the file contain an ASCII signature reading VDRIVEZXFIRMWARE starting at offset 0, and another marker "CHARLESINGLEYALLRIGHTSRESERVED" appears at offset 30. These strings identify the file as an authentic vDriveZX firmware binary.

Vivaldi Music Dump

Used by Vivaldi for Acord RISC OS-based computers.

Yamaha MBDF Archive Firmware

Yamaha MBDF Archive Firmware is a proprietary container format used by Yamaha to package update firmware for devices like the DM3 console. It bundles together multiple firmware components and metadata so the device's update system can apply each part appropriately.

These archive firmware files are produced by Yamaha and designed to be read by the firmware update mechanisms built into Yamaha hardware. Inside the archive are headers identifying the device model, version info, component names and descriptions, and compressed payloads (often using zlib). During update, the device or installer examines those headers, checks version or path fields, then extracts only the changed components and installs them with any associated hooks.

The format begins with the ASCII signature "#YAMAHA MBDFArchive" at offset zero followed by fixed-size fields including a 16-byte model identifier. It then contains one or more "#FIRMWARE" records, each including five big-endian 32-bit integers, three null-terminated strings (path, description, version), and a compressed payload. The archive ends with "#END".

Various apps that use files with this extension

These apps are known to open certain types of BIN files. Remember, different programs may use BIN files for different purposes, so you may need to try out a few of them to be able to open your specific file.

Help us help others

File.org helps thousands of users every day, and we would love to hear from you if you have additional information about BIN file formats, example files, or compatible programs. Please use the links below or email us at submit@file.org to discuss further.