Supported Formats¶
Didn't find what you're looking for? (1)
- ONEKEY is easily extensible and can handle proprietary formats. For custom format integration, reach out to us by filling our contact form or emailing us at support@onekey.com.
All supported formats
7-Zip¶
Fully supported
The 7-Zip file format is a compressed archive format with high compression ratios, supporting multiple algorithms, CRC checks, and multi-volume archives.
- Handler type: Archive
Advenica Image¶
Partially supported
The Advenica image file format consists of a header followed by one or more partitions. Each partition contains data for a specific application.
- Handler type: Archive
- Vendor: Advenica
- Does not support encrypted partitions
Alcatel Image¶
Fully supported
The Alcatel image format is a proprietary archive used by Alcatel devices, consisting of an encrypted application output file and a ramdisk file. The format requires specific decryption keys and tools to extract the contents.
- Handler type: Archive
- Vendor: Alcatel
Android AVB¶
Fully supported
The Android Verified Boot (AVB) filesystem format wraps a standard partition image (e.g., ext4, f2fs) with a cryptographic footer containing metadata such as hash-tree roots, rollback indexes, and public-key signatures to ensure integrity and authenticity at boot time.
- Handler type: FileSystem
- Vendor: Google
Android bootimg¶
Fully supported
The Android boot image format is a packed container that begins with a fixed-size header (including magic, kernel load address, sizes, and command-line), followed by the kernel binary, a compressed ramdisk (a CPIO archive providing the initial root filesystem), an optional second-stage bootloader, and a device tree blob.
- Handler type: FileSystem
- Vendor: Google
Android Bootloader (ABL)¶
Fully supported
The Android Bootloader AVB format is a vbmeta image—a structured binary blob containing hash-tree roots, rollback indexes, algorithm identifiers, and public-key signatures—that the bootloader uses to cryptographically verify and authorize loading of downstream partitions at startup.
- Handler type: Archive
- Vendor: Google
Android DTBO¶
Fully supported
The Android DTBO format is a packed image containing one or more Device Tree Blob overlays preceded by a header that lists each overlay's offset, size, and version, allowing the bootloader to dynamically apply hardware-specific modifications to the base device tree at startup.
- Handler type: FileSystem
- Vendor: Google
Android EROFS¶
Fully supported
EROFS (Enhanced Read-Only File System) is a lightweight, high-performance file system designed for read-only use cases, commonly used in Android and Linux. It features compression support, metadata efficiency, and a fixed superblock structure.
- Handler type: FileSystem
- Vendor: Google
Android OTA¶
Fully supported
The Android OTA payload format is a custom block-based container beginning with the magic “CrAU” followed by a header, manifest of partition update operations, and a sequence of signed binary data chunks that the recovery applies to incrementally or fully update device partitions.
- Handler type: FileSystem
- Vendor: Google
Android Sparse¶
Fully supported
Android sparse images are a file format used to efficiently store disk images by representing sequences of zero blocks compactly. The format includes a file header, followed by chunk headers and data, with support for raw, fill, and 'don't care' chunks.
- Handler type: FileSystem
- Vendor: Google
Android Sparse (transfer list)¶
Fully supported
The Android sparse image format encodes a block device image using a header that defines the block size and a sequence of chunk descriptors (raw, fill, don't-care, and CRC), allowing long runs of zeroed data to be represented compactly and flashed efficiently. This handler can handle sparse images encoded in 'transfer.list' files. The transfer list is a text file containing commands to transfer data from one place to another on the target partition.
- Handler type: FileSystem
- Vendor: Google
Android Super¶
Fully supported
The Android super image format (dynamic partitions) is a single GPT-based container image that includes metadata describing flexible “logical” partitions and their extents—stored in the metadata and super partitions—allowing the bootloader or fastboot to dynamically allocate, resize, and flash individual partition slices without rewriting the entire image.
- Handler type: FileSystem
- Vendor: Google
Android vendorimg¶
Fully supported
The Android vendorimg format is a wrapper around a raw ext4 filesystem image containing vendor-specific HALs, binaries, and resources, which is flashed to and mounted as the /vendor partition during system boot.
- Handler type: Archive
- Vendor: Google
AR¶
Fully supported
Unix AR (archive) files are used to store multiple files in a single archive with a simple header format.
- Handler type: Archive
ARC¶
Fully supported
ARC is a legacy archive format used to store multiple files with metadata such as file size, creation date, and CRC.
- Handler type: Archive
ARJ¶
Fully supported
ARJ is a legacy compressed archive formats used to store multiple files with metadata such as file size, creation date, and CRC.
- Handler type: Archive
ARM Linux Kernel¶
Fully supported
- Handler type: Executable
Autel ECC¶
Fully supported
Autel ECC files consist of a custom header followed by encrypted data blocks. The header includes metadata such as magic bytes, file size, and copyright information.
- Handler type: Archive
- Vendor: Autel
Belden MTS¶
Fully supported
Proprietary archive format from Belden.
- Handler type: Archive
- Vendor: Belden
Binary Flat (BFLT)¶
Fully supported
The Binary Flat (BFLT) executable format is a lightweight, headered binary layout used primarily in MMU-less embedded systems (notably uClinux), featuring a fixed-size BFLT header with fields for architecture, entry point, load addresses, and segment sizes, followed directly by the raw executable segments.
- Handler type: Executable
Bosch CPP¶
Fully supported
Bosch Communication Protocol Firmware Format, typically used for firmware partitions from Bosch surveillance cameras.
- Handler type: Archive
- Vendor: Bosch
Bosch CPP File¶
Fully supported
Bosch Communication Protocol Firmware Format, typically used for firmware files from Bosch surveillance cameras.
- Handler type: Archive
- Vendor: Bosch
BTRFS¶
Fully supported
Btrfs is a computer storage format that combines a file system based on the copy-on-write (COW) principle with a logical volume manager (distinct from Linux's LVM), developed together.
- Handler type: FileSystem
bzip2¶
Fully supported
The bzip2 format is a block-based compression format that uses the Burrows-Wheeler transform and Huffman coding for high compression efficiency. Each stream starts with a header and consists of one or more compressed blocks, ending with a footer containing a checksum.
- Handler type: Compression
CAB¶
Fully supported
Microsoft Cabinet (CAB) archive files are used for compressed file storage and software installation.
- Handler type: Archive
- Vendor: Microsoft
Cisco ASDM¶
Cisco CBS¶
Fully supported
Proprietary partitioning format from Cisco Systems, mostly observed in Cisco TESLA/CBS images.
- Handler type: Archive
- Vendor: Cisco
Cisco SGZ Archive¶
Fully supported
Handler for extracting files from Cisco SGZ archive format.
- Handler type: Archive
- Vendor: Cisco Systems
compress¶
Fully supported
Unix compress files use the Lempel-Ziv-Welch (LZW) algorithm for data compression and are identified by a 2-byte magic number (0x1F 0x9D). This format supports optional block compression and variable bit lengths ranging from 9 to 16 bits.
- Handler type: Compression
CPIO (binary)¶
Fully supported
CPIO (Copy In, Copy Out) is an archive file format used for bundling files and directories along with their metadata. It is commonly used in Unix-like systems for creating backups or transferring files, and supports various encoding formats including binary and ASCII.
- Handler type: Archive
CPIO (portable ASCII CRC)¶
Fully supported
CPIO (Copy In, Copy Out) is an archive file format used for bundling files and directories along with their metadata. It is commonly used in Unix-like systems for creating backups or transferring files, and supports various encoding formats including binary and ASCII.
- Handler type: Archive
CPIO (portable ASCII)¶
Fully supported
CPIO (Copy In, Copy Out) is an archive file format used for bundling files and directories along with their metadata. It is commonly used in Unix-like systems for creating backups or transferring files, and supports various encoding formats including binary and ASCII.
- Handler type: Archive
CPIO (portable old ASCII)¶
Fully supported
CPIO (Copy In, Copy Out) is an archive file format used for bundling files and directories along with their metadata. It is commonly used in Unix-like systems for creating backups or transferring files, and supports various encoding formats including binary and ASCII.
- Handler type: Archive
CramFS¶
Fully supported
CramFS is a lightweight, read-only file system format designed for simplicity and efficiency in embedded systems. It uses zlib compression for file data and stores metadata in a compact, contiguous structure.
- Handler type: FileSystem
D-Link encrpted_img¶
Fully supported
A binary format used by D-Link to store encrypted firmware or data. It consists of a custom 12-byte magic header followed by the encrypted payload.
- Handler type: Archive
- Vendor: D-Link
D-Link SHRS¶
Fully supported
SHRS is a D-Link firmware format with a custom header containing metadata, SHA-512 digests, and AES-CBC encryption parameters. The firmware data is encrypted using a fixed key and IV stored in the header.
- Handler type: Archive
- Vendor: D-Link
Dahua Archive¶
Fully supported
A proprietary archive format used by Dahua devices for storing video recordings and other data.
- Handler type: Archive
- Vendor: Dahua
Dahua Secrity¶
Fully supported
Dahua Secrity (sic) is a custom proprietary format from Dahua. It supports AES encryption, with cryptographic material saved in the bootloader code. Both kernel and filesystems have different keys. The handler is capable of transparently decrypting these images without prior knowledge of the key.
- Handler type: FileSystem
- Vendor: Dahua
Device Tree Blob (DTB)¶
Fully supported
The Device Tree Blob (DTB) format is a flattened, binary-encoded representation of a system's hardware description—starting with a header that includes size and version information followed by a hierarchy of nodes and properties—used by bootloaders and kernels to dynamically configure platform-specific resources at startup.
- Handler type: Executable
DMG¶
Fully supported
Apple Disk Image (DMG) files are commonly used on macOS for software distribution and disk image storage.
- Handler type: Archive
- Vendor: Apple
dmverity¶
Fully supported
Device-Mapper's verity target provides transparent integrity checking of block devices using a cryptographic digest provided by the kernel crypto API.
- Handler type: FileSystem
Docker Image¶
Fully supported
A Docker image is a lightweight, standalone, executable package that includes everything needed to run a piece of software, including the code, runtime, system tools, system libraries and settings.
- Handler type: Archive
- Vendor: Docker Inc.
eCos ROMFS¶
Fully supported
The eCos ROMFS format is a simple, contiguous read-only filesystem designed for embedding directly into ROM or flash memory, featuring a single flat image that begins with a global header followed by a sequence of file entries.
- Handler type: FileSystem
- Vendor: eCos
ELF (32-bit)¶
Fully supported
The 32-bit ELF (Executable and Linkable Format) is a binary file format used for executables, object code, shared libraries, and core dumps. It supports 32-bit addressing and includes headers for program and section information.
- Handler type: Executable
ELF (64-bit)¶
Fully supported
The 64-bit ELF (Executable and Linkable Format) is a binary file format used for executables, object code, shared libraries, and core dumps. It supports 64-bit addressing and includes headers for program and section information.
- Handler type: Executable
Engenius¶
Partially supported
Engenius firmware files contain a custom header with metadata, followed by encrypted data using an XOR cipher.
- Handler type: Archive
- Vendor: Engenius
- Does not support all firmware versions.
ExtFS¶
Fully supported
ExtFS (Ext2/Ext3/Ext4) is a family of journaling file systems commonly used in Linux-based operating systems. It supports features like large file sizes, extended attributes, and journaling for improved reliability.
- Handler type: FileSystem
FAT¶
Fully supported
FAT (File Allocation Table) is a file system format used for organizing and managing files on storage devices, supporting FAT12, FAT16, and FAT32 variants. It uses a table to map file clusters, enabling efficient file storage and retrieval.
- Handler type: FileSystem
Festo FEZLV¶
Fully supported
FEZLV is a proprietary filesystem format from Festo.
- Handler type: FileSystem
- Vendor: Festo
Festo FFWU¶
Fully supported
Proprietary archive format built on XML from Festo.
- Handler type: Archive
- Vendor: Festo
FreeRTOS OTA¶
Fully supported
The FreeRTOS OTA (OTA1) format is a binary firmware update image that begins with a fixed-size header containing metadata such as magic number, header version, image size, and CRC32 checksum, immediately followed by the raw application firmware payload for over-the-air installation.
- Handler type: Archive
- Vendor: FreeRTOS
GZIP¶
Fully supported
GZIP is a compressed file format that uses the DEFLATE algorithm and includes metadata such as original file name and modification time. It is commonly used for efficient file storage and transfer.
- Handler type: Compression
GZIP (multi-volume)¶
Fully supported
GZIP is a compressed file format that uses the DEFLATE algorithm and includes metadata such as original file name and modification time. It is commonly used for efficient file storage and transfer.
- Handler type: Compression
Hirschmann Container¶
Fully supported
Proprietary archive format from Hirschmann.
- Handler type: Archive
- Vendor: Hirschmann
Hirschmann NEWH¶
Fully supported
Proprietary archive format from Hirschmann.
- Handler type: Archive
- Vendor: Hirschmann
HP BDL¶
Fully supported
The HP BDL format is a firmware archive containing a custom header and a table of contents that specifies offsets and sizes of embedded firmware components. It includes metadata such as release, brand, device ID, version, and revision.
- Handler type: Archive
- Vendor: HP
HP IPKG¶
Fully supported
HP IPKG firmware archives consist of a custom header, followed by a table of contents and file entries. Each entry specifies metadata such as file name, offset, size, and CRC32 checksum.
- Handler type: Archive
- Vendor: HP
HRFS¶
Fully supported
HRFS is a proprietary filesystem format from Xilinx
- Handler type: FileSystem
- Vendor: Xilinx
Instar BNEG¶
Fully supported
BNEG firmware files consist of a custom header followed by two partitions containing firmware components. The header specifies metadata such as magic value, version, and partition sizes.
- Handler type: Archive
- Vendor: Instar
Instar HD¶
Fully supported
Instar HD firmware files are modified ZIP archives with non-standard local file headers, central directory headers, and end-of-central-directory records. These modifications include custom magic bytes to differentiate them from standard ZIP files.
- Handler type: Archive
- Vendor: Instar
Intel HEX¶
Fully supported
Intel hexadecimal object file format, Intel hex format or Intellec Hex is a file format that conveys binary information in ASCII text form, making it possible to store on non-binary media such as paper tape, punch cards, etc., to display on text terminals or be printed on line-oriented printers.
- Handler type: Executable
- Vendor: Intel
ISO 9660¶
Fully supported
ISO 9660 is a file system standard for optical disc media, defining a volume descriptor structure and directory hierarchy. It is widely used for CD-ROMs and supports cross-platform compatibility.
- Handler type: FileSystem
JFFS2 (new)¶
Fully supported
JFFS2 (Journaling Flash File System version 2) is a log-structured file system for flash memory devices, using an older magic number to identify its nodes. It organizes data into nodes with headers containing metadata and CRC checks for integrity.
- Handler type: FileSystem
JFFS2 (old)¶
Fully supported
JFFS2 (Journaling Flash File System version 2) is a log-structured file system for flash memory devices, using an older magic number to identify its nodes. It organizes data into nodes with headers containing metadata and CRC checks for integrity.
- Handler type: FileSystem
LittleFS¶
Fully supported
A little fail-safe filesystem designed for microcontrollers.
- Handler type: FileSystem
LZ4¶
Fully supported
LZ4 is a high-speed lossless compression algorithm designed for real-time data compression with minimal memory usage.
- Handler type: Compression
LZ4 (legacy)¶
Fully supported
LZ4 legacy format is an older framing format used prior to the LZ4 Frame specification, featuring a simpler structure and no support for skippable frames or extensive metadata. Unlike the default LZ4 Frame format, it lacks built-in checksums, versioning, or block independence flags, making it less robust and primarily used for backward compatibility.
- Handler type: Compression
LZ4 (skippable)¶
Fully supported
LZ4 skippable format is designed to encapsulate arbitrary data within an LZ4 stream allowing compliant parsers to skip over it safely. This format does not contain compressed data itself but is often used for embedding metadata or non-LZ4 content alongside standard frames.
- Handler type: Compression
LZH¶
Fully supported
LZH is a legacy archive format that uses various compression methods such as '-lh0-' and '-lh5-'. It was widely used in Japan and on older systems for compressing and archiving files.
- Handler type: Compression
Lzip¶
Fully supported
Lzip is a lossless compressed file format based on the LZMA algorithm. It features a simple header, CRC-checked integrity, and efficient compression for large files.
- Handler type: Compression
LZMA¶
Fully supported
LZMA is a compression format based on the Lempel-Ziv-Markov chain algorithm, offering high compression ratios and efficient decompression. It is commonly used in standalone .lzma files and embedded in other formats like 7z.
- Handler type: Compression
LZO¶
Fully supported
LZO is a data compression format featuring a simple header structure and optional checksum verification. It is optimized for fast decompression and supports various compression levels and flags for additional metadata.
- Handler type: Compression
Master Boot Record (MBR)¶
Fully supported
A master boot record (MBR) is a type of boot sector in the first block of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond.
- Handler type: FileSystem
Mediatek MTK¶
Fully supported
Proprietary bare-metal image format from Mediatek.
- Handler type: Archive
- Vendor: Mediatek
Microchip MPFS¶
Fully supported
MPFS is a proprietary filesystem from Microchip.
- Handler type: FileSystem
- Vendor: Microchip
Motorola S-record (SREC)¶
Fully supported
Motorola S-record is a file format, created by Motorola in the mid-1970s, that conveys binary information as hex values in ASCII text form. It is commonly used for programming flash memory in microcontrollers, EPROMs, EEPROMs, and other types of programmable logic devices.
- Handler type: Executable
- Vendor: Motorola
multi-sevenzip¶
Fully supported
The 7-Zip file format is a compressed archive format with high compression ratios, supporting multiple algorithms, CRC checks, and multi-volume archives.
- Handler type: Archive
Netgear CHK¶
Fully supported
Netgear CHK firmware files consist of a custom header containing metadata and checksums, followed by kernel and root filesystem partitions. The header includes fields for partition sizes, checksums, and a board identifier.
- Handler type: Archive
- Vendor: Netgear
Netgear TRX v1¶
Fully supported
Netgear TRX v1 firmware format includes a custom header with partition offsets and a CRC32 checksum for integrity verification. It supports up to three partitions defined in the header.
- Handler type: Archive
- Vendor: Netgear
Netgear TRX v2¶
Fully supported
Netgear TRX v2 firmware format includes a custom header with partition offsets and a CRC32 checksum for integrity verification. It supports up to four partitions defined in the header.
- Handler type: Archive
- Vendor: Netgear
NTFS¶
Fully supported
NTFS (New Technology File System) is a proprietary file system developed by Microsoft, featuring metadata support, advanced data structures, and journaling for reliability. It is commonly used in Windows operating systems for efficient storage and retrieval of files.
- Handler type: FileSystem
- Vendor: Microsoft
Partclone¶
Fully supported
Partclone is a utility used for backing up and restoring partitions. Many cloning tools (such as Clonezilla) rely on it to create block-level images that include filesystem metadata.
- Handler type: Archive
PCK¶
Fully supported
Proprietary archive format.
- Handler type: Archive
- Vendor: Worx Landroid
QNAP NAS¶
Fully supported
QNAP NAS firmware files consist of a custom header, encrypted data sections, and a footer marking the end of the encrypted stream. The header contains metadata such as device ID, firmware version, and encryption details.
- Handler type: Archive
- Vendor: QNAP
QNX Image Filesystem (IFS) v4¶
Fully supported
The QNX 4 Image Filesystem (IFS) format is a flat, contiguous binary image containing the boot loader, startup code, and a compressed or raw embedded filesystem used for booting QNX 4-based systems. It includes a structured header, startup program, and a collection of files organized in a simple directory structure directly accessible by the QNX 4 microkernel at boot time.
- Handler type: FileSystem
- Vendor: Blackberry
QNX Image Filesystem (IFS) v6¶
Fully supported
The QNX 6 Image Filesystem (IFS) format serves as a bootable container combining the initial boot loader, startup program, and an embedded copy of the procnto microkernel along with vital system resources. Unlike QNX 4, QNX 6 IFS supports more complex ELF binaries and is structured to load the Neutrino RTOS microkernel with its resource managers and drivers at system startup.
- Handler type: FileSystem
- Vendor: Blackberry
Qualcomm FBPK v1¶
Fully supported
Custom proprietary partitioning format from Qualcomm.
- Handler type: FileSystem
- Vendor: Qualcomm
Qualcomm FBPK v2¶
Fully supported
Custom proprietary partitioning format from Qualcomm.
- Handler type: FileSystem
- Vendor: Qualcomm
Qualcomm FBPK v2¶
Fully supported
Custom proprietary firmware update container format from Qualcomm.
- Handler type: FileSystem
- Vendor: Qualcomm
Qualcomm MIBIB¶
Fully supported
Custom proprietary bootloader format from Qualcomm
- Handler type: Executable
- Vendor: Qualcomm
RAR¶
Partially supported
RAR archive files are commonly used for compressed data storage. They can contain multiple files and directories, and support various compression methods.
- Handler type: Archive
- Does not support encrypted RAR files.
Rockchip RKAF¶
Fully supported
RKAF is a custom proprietary partitioning format built by Rockhip.
- Handler type: FileSystem
- Vendor: Rockchip
Rockchip RKFW¶
Fully supported
RKFW is a custom proprietary format built by Rockchip. It works as a container for firmware update files.
- Handler type: FileSystem
- Vendor: Rockchip
Rockwell CoB1¶
Fully supported
Proprietary archive format from Rockwell.
- Handler type: Archive
- Vendor: Rockwell
RomFS¶
Fully supported
RomFS is a simple, space-efficient, read-only file system format designed for embedded systems. It features 16-byte alignment, minimal metadata overhead, and supports basic file types like directories, files, symlinks, and devices.
- Handler type: FileSystem
Sauter¶
Fully supported
Sauter proprietary wrapper for Zephyr bare-metal images.
- Handler type: Archive
- Vendor: Sauter
SMA Solar SMA¶
Fully supported
Custom proprietary archive format from SMA Solar.
- Handler type: Archive
- Vendor: SMA Solar
SquashFS (v1)¶
Fully supported
SquashFS version 1 is a compressed, read-only file system format designed for minimal storage usage. It is commonly used in embedded systems and early Linux distributions.
- Handler type: FileSystem
SquashFS (v2)¶
Fully supported
SquashFS version 2 is a compressed, read-only file system format designed for minimal storage usage. It builds upon version 1 with additional features and improvements for embedded systems and Linux distributions.
- Handler type: FileSystem
SquashFS (v3)¶
Fully supported
SquashFS version 3 is a compressed, read-only file system format designed for minimal storage usage. It is widely used in embedded systems and Linux distributions for efficient storage and fast access.
- Handler type: FileSystem
SquashFS (v3-Broadcom)¶
Fully supported
SquashFS version 3 Broadcom is a variant of the SquashFS v3 format used in Broadcom firmware. It features a unique magic number and may include specific optimizations for Broadcom devices.
- Handler type: FileSystem
- Vendor: Broadcom
SquashFS (v3-DDWRT)¶
Fully supported
SquashFS version 3 DD-WRT is a variant of the SquashFS v3 format used in DD-WRT firmware. It features a unique magic number and may include specific optimizations for embedded systems.
- Handler type: FileSystem
- Vendor: DDWRT
SquashFS (v3-non-standard)¶
Fully supported
SquashFS version 3 is a compressed, read-only file system format designed for minimal storage usage. It is widely used in embedded systems and Linux distributions for efficient storage and fast access.
- Handler type: FileSystem
- Vendor: unknown
SquashFS (v4-BE)¶
Fully supported
SquashFS version 4 is a compressed, read-only file system format designed for minimal storage usage and fast access. It supports both big-endian and little-endian formats and is widely used in embedded systems and Linux distributions.
- Handler type: FileSystem
SquashFS (v4-LE)¶
Fully supported
SquashFS version 4 is a compressed, read-only file system format designed for minimal storage usage and fast access. It is widely used in embedded systems and Linux distributions for efficient storage management.
- Handler type: FileSystem
Stuffit SIT¶
Fully supported
StuffIt SIT archives is a legacy compressed archive format commonly used on macOS and earlier Apple systems.
- Handler type: Archive
- Vendor: StuffIt Technologies
Stuffit SIT (v5)¶
Fully supported
StuffIt SIT archives is a legacy compressed archive format commonly used on macOS and earlier Apple systems.
- Handler type: Archive
- Vendor: StuffIt Technologies
TAR (Unix)¶
Fully supported
Unix tar files are a widely used archive format for storing files and directories with metadata.
- Handler type: Archive
TAR (USTAR)¶
Fully supported
USTAR (Uniform Standard Tape Archive) tar files are extensions of the original tar format with additional metadata fields.
- Handler type: Archive
UBI¶
Fully supported
UBI (Unsorted Block Image) is a volume management system for raw flash devices, providing wear leveling and bad block management. It operates as a layer between the MTD subsystem and higher-level filesystems like UBIFS.
- Handler type: FileSystem
UBIFS¶
Fully supported
UBIFS (Unsorted Block Image File System) is a flash file system designed for raw flash memory, providing wear leveling, error correction, and power failure resilience. It operates on top of UBI volumes, which manage flash blocks on raw NAND or NOR flash devices.
- Handler type: FileSystem
UEFI¶
Partially supported
UEFI (Unified Extensible Firmware Interface) is a modern firmware specification that initializes hardware and boots the operating system, replacing the legacy BIOS interface. UEFI firmware provides a flexible pre-boot environment with support for large drives, faster startup, secure boot, and modular drivers.
- Handler type: Archive
- Only supports Flash Descriptor extraction for now.
uImage¶
Fully supported
The uImage format is U-Boot's kernel image container consisting of a fixed-length header holding a magic number, timestamp, load and entry addresses, image size, OS type, architecture, compression type, and descriptive name—followed by the compressed or raw binary payload.
- Handler type: Archive
USB Flashing Format (UF2)¶
Fully supported
UF2 is a file format, developed by Microsoft for PXT (also known as Microsoft MakeCode), that is particularly suitable for flashing microcontrollers over MSC (Mass Storage Class; aka removable flash drive).
- Handler type: Executable
- Vendor: Microsoft
UZIP¶
Fully supported
FreeBSD UZIP is a block-based compressed disk image format. It uses a table of contents to index compressed blocks, supporting ZLIB, LZMA, and ZSTD compression algorithms.
- Handler type: Compression
- Vendor: FreeBSD
VMWare Virtual Machine Disk¶
Fully supported
VMDK (short for Virtual Machine Disk) is a file format that describes containers for virtual hard disk drives to be used in virtual machines like VMware Workstation or VirtualBox.
- Handler type: FileSystem
- Vendor: VMWare
VxWorks MemFS¶
Fully supported
MemFS is an embedded filesystem from Wind River, mostly seen in VxWorks images.
- Handler type: FileSystem
- Vendor: Wind River
Webrom¶
Fully supported
Proprietary archive format from Belden.
- Handler type: Archive
- Vendor: Belden
x86 Linux Kernel¶
Fully supported
- Handler type: Executable
Xiaomi HDR1¶
Fully supported
Xiaomi HDR1 firmware files feature a custom header containing metadata, CRC32 checksum, and blob offsets for embedded data. These files are used in Xiaomi devices for firmware updates.
- Handler type: Archive
- Vendor: Xiaomi
Xiaomi HDR2¶
Fully supported
Xiaomi HDR2 firmware files feature a custom header with metadata, CRC32 checksum, and blob offsets for embedded data. These files also include additional fields for device ID and region information.
- Handler type: Archive
- Vendor: Xiaomi
Xilinx FSBL¶
Fully supported
Xilinx proprietary bootloader format.
- Handler type: Executable
- Vendor: Xilinx
XZ¶
Fully supported
XZ is a compressed file format that uses the LZMA2 algorithm for high compression efficiency. It is designed for general-purpose data compression with support for integrity checks and padding for alignment.
- Handler type: Compression
YAFFS¶
Fully supported
YAFFS (Yet Another Flash File System) is a log-structured file system designed for NAND flash memory, storing data in fixed-size chunks with associated metadata. It supports features like wear leveling, error correction, and efficient handling of power loss scenarios.
- Handler type: FileSystem
Yealink ROM¶
Fully supported
Yealink ROM is a custom proprietary image format from Yealink. It acts as a container for firmware update files.
- Handler type: FileSystem
- Vendor: Yealink
Yealink SquashFS¶
Fully supported
Custom encryption layer on top of SquashFS.
- Handler type: FileSystem
- Vendor: Yealink
Yealink UBI¶
Fully supported
Custom encryption layer on top of UBI.
- Handler type: FileSystem
- Vendor: Yealink
Yealink YAFFS¶
Fully supported
Custom encryption layer on top of YAFFS.
- Handler type: FileSystem
- Vendor: Yealink
ZIP¶
Partially supported
ZIP is a widely used archive file format that supports multiple compression methods, file spanning, and optional encryption. It includes metadata such as file names, sizes, and timestamps, and supports both standard and ZIP64 extensions for large files.
- Handler type: Archive
- Does not support encrypted ZIP files.
zlib¶
Fully supported
The zlib format is a compressed data format based on the DEFLATE algorithm, often used for data compression in various applications. It includes a lightweight header and checksum for data integrity.
- Handler type: Compression
ZSTD¶
Fully supported
Zstandard (ZSTD) is a fast lossless compression algorithm with high compression ratios, designed for modern data storage and transfer. Its file format includes a frame structure with optional dictionary support and checksums for data integrity.
- Handler type: Compression