# ----------------------------Archive Formats--------------------------------------

# POSIX tar archives
0	string		ustar\000		POSIX tar archive{offset-adjust:-257}
0	string          ustar\040\040\000	POSIX tar archive (GNU){offset-adjust:-257}

# JAR archiver (.j), this is the successor to ARJ, not Java's JAR (which is essentially ZIP)
0       string  \x1aJar\x1b JAR (ARJ Software, Inc.) archive data{offset-adjust:-14}
0       string  JARCS JAR (ARJ Software, Inc.) archive data


# ARJ archiver (jason@jarthur.Claremont.EDU)
0       leshort         0xea60          ARJ archive data
>5      byte            x               \b, v%d,
>8      byte            &0x04           multi-volume,
>8      byte            &0x10           slash-switched,
>8      byte            &0x20           backup,
>34     string          x               original name: "%s",
>7      byte            0               os: MS-DOS 
>7      byte            1               os: PRIMOS
>7      byte            2               os: Unix
>7      byte            3               os: Amiga
>7      byte            4               os: Macintosh
>7      byte            5               os: OS/2
>7      byte            6               os: Apple ][ GS
>7      byte            7               os: Atari ST
>7      byte            8               os: NeXT
>7      byte            9               os: VAX/VMS
>3      byte            >0              %d]

# RAR archiver (Greg Roelofs, newt@uchicago.edu)
0	string		Rar!		RAR archive data

# HPACK archiver (Peter Gutmann, pgut1@cs.aukuni.ac.nz)
0	string		HPAK		HPACK archive data

# JAM Archive volume format, by Dmitry.Kohmanyuk@UA.net
0	string		\351,\001JAM	JAM archive

# LHARC/LHA archiver (Greg Roelofs, newt@uchicago.edu)
0	string		-lzs-		LHa 2.x? archive data [lzs] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lh\40-		LHa 2.x? archive data [lh ] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lhd-		LHa 2.x? archive data [lhd] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lh2-		LHa 2.x? archive data [lh2] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lh3-		LHa 2.x? archive data [lh3] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lh4-		LHa (2.x) archive data [lh4] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lh5-		LHa (2.x) archive data [lh5] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lh6-		LHa (2.x) archive data [lh6] [NSRL|LHA2]{offset-adjust:-2}
0	string		-lh7-		LHa (2.x) archive data [lh7] [NSRL|LHA2]{offset-adjust:-2}


# cpio archives
#
# The SVR4 "cpio(4)" hints that there are additional formats, but they
# are defined as "short"s; I think all the new formats are
# character-header formats and thus are strings, not numbers.
#0       string          070707          ASCII cpio archive (pre-SVR4 or odc)

0       string          070701          ASCII cpio archive (SVR4 with no CRC),
>110	byte		0		invalid
>110	string		x		file name: "%s"
>54	string		x		{jump-to-offset:0x%.8s+112}

0       string          070702          ASCII cpio archive (SVR4 with CRC)
>110	byte		0		invalid
>110	string		x		file name: "%s"
>54	string		x		{jump-to-offset:0x%.8s+112}


# HP Printer Job Language
# The header found on Win95 HP plot files is the "Silliest Thing possible" 
# (TM)
# Every driver puts the language at some random position, with random case
# (LANGUAGE and Language)
# For example the LaserJet 5L driver puts the "PJL ENTER LANGUAGE" in line 10
# From: Uwe Bonnes <bon@elektron.ikp.physik.th-darmstadt.de>
# 
0       string          \033%-12345X@PJL        HP Printer Job Language data
>&0     string          >\0                     "%s"
>>&0    string          >\0                     "%s"
>>>&0   string          >\0                     "%s"
>>>>&0  string          >\0                     "%s"

#------------------------------------------------------------------------------
#
# RPM: file(1) magic for Red Hat Packages   Erik Troan (ewt@redhat.com)
#
0	belong		0xedabeedb	RPM
>4	byte		x		v%d
>6	beshort		0		bin
>6	beshort		1		src
>8	beshort		1		i386
>8	beshort		2		Alpha
>8	beshort		3		Sparc
>8	beshort		4		MIPS
>8	beshort		5		PowerPC
>8	beshort		6		68000
>8	beshort		7	SGI
>8	beshort		8		RS6000
>8	beshort		9		IA64
>8	beshort		10		Sparc64
>8	beshort		11		MIPSel
>8	beshort		12		ARM
>10	string		x		"%s"


#---------------------------Bootloaders--------------------------------

# CFE bootloader
0	string	CFE1CFE1	CFE boot loader, little endian
0	string	1EFC1EFC	CFE boot loader, big endian


#------------------Compression Formats-----------------------------

# AFX compressed files (Wolfram Kleff)
0	string		-afx-		AFX compressed file data{offset-adjust:-2}

# bzip2
0	string BZh91AY&SY	bzip2 compressed data, block size = 900k
0	string BZh81AY&SY	bzip2 compressed data, block size = 800k
0	string BZh71AY&SY	bzip2 compressed data, block size = 700k
0	string BZh61AY&SY	bzip2 compressed data, block size = 600k
0	string BZh51AY&SY	bzip2 compressed data, block size = 500k
0	string BZh41AY&SY	bzip2 compressed data, block size = 400k
0	string BZh31AY&SY	bzip2 compressed data, block size = 300k
0	string BZh21AY&SY	bzip2 compressed data, block size = 200k
0	string BZh11AY&SY	bzip2 compressed data, block size = 100k

# lzop from <markus.oberhumer@jk.uni-linz.ac.at>
0	string		\x89\x4c\x5a\x4f\x00\x0d\x0a\x1a\x0a	lzop compressed data
>9	beshort		<0x0940
>>9	byte&0xf0	=0x00		- version 0.
>>9	beshort&0x0fff	x		\b%03x,
>>13	byte		1		LZO1X-1,
>>13	byte		2		LZO1X-1(15),
>>13	byte		3		LZO1X-999,
## >>22	bedate		>0		last modified: %s,
>>14	byte		=0x00		os: MS-DOS
>>14	byte		=0x01		os: Amiga
>>14	byte		=0x02		os: VMS
>>14	byte		=0x03		os: Unix
>>14	byte		=0x05		os: Atari
>>14	byte		=0x06		os: OS/2
>>14	byte		=0x07		os: MacOS
>>14	byte		=0x0A		os: Tops/20
>>14	byte		=0x0B		os: WinNT
>>14	byte		=0x0E		os: Win32
>9	beshort		>0x0939
>>9	byte&0xf0	=0x00		- version 0.
>>9	byte&0xf0	=0x10		- version 1.
>>9	byte&0xf0	=0x20		- version 2.
>>9	beshort&0x0fff	x		\b%03x,
>>15	byte		1		LZO1X-1,
>>15	byte		2		LZO1X-1(15),
>>15	byte		3		LZO1X-999,
## >>25	bedate		>0		last modified: %s,
>>17	byte		=0x00		os: MS-DOS
>>17	byte		=0x01		os: Amiga
>>17	byte		=0x02		os: VMS
>>17	byte		=0x03		os: Unix
>>17	byte		=0x05		os: Atari
>>17	byte		=0x06		os: OS/2
>>17	byte		=0x07		os: MacOS
>>17	byte		=0x0A		os: Tops/20
>>17	byte		=0x0B		os: WinNT
>>17	byte		=0x0E		os: Win32

# lzip  
0       string          LZIP            lzip compressed data
>4      byte            x               \b, version: %d

# LZO
0	string		\211LZO\000\015\012\032\012	LZO compressed data

# 7-zip archiver, from Thomas Klausner (wiz@danbala.tuwien.ac.at)
# http://www.7-zip.org or DOC/7zFormat.txt 
#
0       string          7z\274\257\047\034      7-zip archive data,
>6      byte            x                       version %d
>7      byte            x                       \b.%d

# standard unix compress
0       beshort		0x1f9d          compress'd data
>2      byte&0x80       >0              block compressed
>2	byte&0x1f	!16		invalid
>2      byte&0x1f       x               %d bits

# http://tukaani.org/xz/xz-file-format.txt
0	string		\xFD\x37\x7a\x58\x5a\x00	xz compressed data

# gzip (GNU zip, not to be confused with Info-ZIP or PKWARE zip archiver)
#   Edited by Chris Chittleborough <cchittleborough@yahoo.com.au>, March 2002
#       * Original filename is only at offset 10 if "extra field" absent
#       * Produce shorter output - notably, only report compression methods
#         other than 8 ("deflate", the only method defined in RFC 1952).
0       string          \037\213\x08    gzip compressed data
>3      byte            &0x01           \b, ASCII
>3      byte            &0x02           \b, has CRC
>3      byte            &0x04           \b, extra field
>3      byte&0xC        =0x08
>>10	string		x		\b{file-name:%s}
>>10    string          x               \b, was "%s"
>3      byte            &0x10           \b, has comment
>9      byte            =0x00           \b, from FAT filesystem (MS-DOS, OS/2, NT)
>9      byte            =0x01           \b, from Amiga
>9      byte            =0x02           \b, from VMS
>9      byte            =0x03           \b, from Unix
>9      byte            =0x04           \b, from VM/CMS
>9      byte            =0x05           \b, from Atari
>9      byte            =0x06           \b, from HPFS filesystem (OS/2, NT)
>9      byte            =0x07           \b, from MacOS
>9      byte            =0x08           \b, from Z-System
>9      byte            =0x09           \b, from CP/M
>9      byte            =0x0A           \b, from TOPS/20
>9      byte            =0x0B           \b, from NTFS filesystem (NT)
>9      byte            =0x0C           \b, from QDOS
>9      byte            =0x0D           \b, from Acorn RISCOS
>9	byte		>0x0D		\b, invalid source
>9	byte		<0		\b, invalid source
>3      byte            &0x20           \b, encrypted (invalid)
# Dates before 1992 are invalid, unless of course you're DD-WRT in which
# case you don't know how to set a date in your gzip files. Brilliant.
>4	lelong		=0		\b, NULL date:
>4	lelong		<0		\b, invalid date:
>4	lelong		>0		
>>4	lelong		<694224000	\b, invalid date:
>>4	lelong		=694224000	\b, invalid date:
>>4	lelong		>694224000	\b, last modified:
>4      ledate          x               %s
>8      byte            2               \b, max compression
>8      byte            4               \b, max speed

# Zlib signatures
0	beshort		0x789C		zlib compressed data
0	beshort		0x78DA		zlib compressed data
0	beshort		0x7801		zlib compressed data

# Supplementary magic data for the file(1) command to support
# rzip(1).  The format is described in magic(5).
#
# Copyright (C) 2003 by Andrew Tridgell.  You may do whatever you want with
# this file.
#
0       string          RZIP            rzip compressed data
>4      byte            x               - version %d
>5      byte            x               \b.%d
>6      belong          x               (%d bytes)

# ZIP compression (Greg Roelofs, c/o zip-bugs@wkuvx1.wku.edu)
0       string          PK\003\004      Zip archive data,
>4      byte            0x00            v0.0
>4      byte            0x09            at least v0.9 to extract,
>4      byte            0x0a            at least v1.0 to extract,
>4      byte            0x0b            at least v1.1 to extract,
>0x161  string          WINZIP          WinZIP self-extracting,
>4      byte            0x14
>>30    ubelong         !0x6d696d65     at least v2.0 to extract,
>18	lelong		!0
>>18	lelong		<0		invalid
>>18	lelong		x		compressed size: %d,
>22	lelong		!0
>>22	lelong		<0		invalid
>>22	lelong		x		uncompressed size: %d,{extract-delay:end of zip archive}
>30	string		x		{file-name:{raw-replace}}name: {raw-replace}
>26	leshort		x		{raw-string-length:%d}
>30	string		x		{raw-string:%s
>61	string		x		\b%s
>92	string		x		\b%s
>123	string		x		\b%s
>154	string		x		\b%s}

# ZIP footer
0	string		PK\x05\x06	End of Zip archive
>20	leshort		x		{offset-adjust:22+%d}
>20	leshort		>0
>>20	leshort		x		\b, comment: {raw-replace}
>>20	leshort		x		{raw-string-length:%d}
>>22	string		x		{raw-string:%s}

# New LZMA format signature
0	string		\xFFLZMA\x00	LZMA compressed data (new),
>6	byte&0x10	0		single-block stream
>6	byte&0x10	0x10		multi-block stream

# See lzma file for LZMA signatures
# Type: OpenSSL certificates/key files
# From: Nicolas Collignon <tsointsoin@gmail.com>

0       string  -----BEGIN\x20CERTIFICATE-----    PEM certificate
0       string  -----BEGIN\x20CERTIFICATE\x20REQ    PEM certificate request
0       string  -----BEGIN\x20RSA\x20PRIVATE        PEM RSA private key
0       string  -----BEGIN\x20DSA\x20PRIVATE        PEM DSA private key

# Type: OpenSSH key files
# From: Nicolas Collignon <tsointsoin@gmail.com>

0       string  SSH\x20PRIVATE\x20KEY	OpenSSH RSA1 private key,
>28     string  >\0			version "%s"

0       string  ssh-dss\x20               OpenSSH DSA public key
0       string  ssh-rsa\x20               OpenSSH RSA public key

# Type: Certificates/key files in DER format
# From: Gert Hulselmans <hulselmansgert@gmail.com>
0	string	\x30\x82		Private key in DER format (PKCS#8),
>4	string	!\x02\x01\x00		invalid,
>>2	beshort	x			header length: 4, sequence length: %d

0	string  \x30\x82		Certificate in DER format (x509 v3),
>4	string	!\x30\x82		invalid,
>>2	beshort	x			header length: 4, sequence length: %d

# GnuPG
# The format is very similar to pgp
0	string          \001gpg                 GPG key trust database
>4	byte            x                       version %d
0       beshort         0x9901                  GPG key public ring
# This magic is not particularly good, as the keyrings don't have true
# magic. Nevertheless, it covers many keyrings.

#------------------------------------------------------------------------------
# Mavroyanopoulos Nikos <nmav@hellug.gr>
# mcrypt:   file(1) magic for mcrypt 2.2.x;
0	string		\0m\3		mcrypt 2.5 encrypted data,
>4	byte		0		invalid
>4	string		>\0		algorithm: "%s",
>>&1	leshort		<1		invalid
>>&1	leshort		>0		keysize: %d bytes,
>>>&0	byte		0		invalid
>>>&0	string		>\0		mode: "%s",

0	string		\0m\2		mcrypt 2.2 encrypted data,
>3	byte		0		algorithm: blowfish-448,
>3	byte		1		algorithm: DES,
>3	byte		2		algorithm: 3DES,
>3	byte		3		algorithm: 3-WAY,
>3	byte		4		algorithm: GOST,
>3	byte		6		algorithm: SAFER-SK64,
>3	byte		7		algorithm: SAFER-SK128,
>3	byte		8		algorithm: CAST-128,
>3	byte		9		algorithm: xTEA,
>3	byte		10		algorithm: TWOFISH-128,
>3	byte		11		algorithm: RC2,
>3	byte		12		algorithm: TWOFISH-192,
>3	byte		13		algorithm: TWOFISH-256,
>3	byte		14		algorithm: blowfish-128,
>3	byte		15		algorithm: blowfish-192,
>3	byte		16		algorithm: blowfish-256,
>3	byte		100		algorithm: RC6,
>3	byte		101		algorithm: IDEA,
>3	byte		<0		invalid algorithm
>3	byte		>101		invalid algorithm,
>3	byte		>16
>>3	byte		<100		invalid algorithm,
>4	byte		0		mode: CBC,
>4	byte		1		mode: ECB,
>4	byte		2		mode: CFB,
>4	byte		3		mode: OFB,
>4	byte		4		mode: nOFB,
>4	byte		<0		invalid mode,
>4	byte		>4		invalid mode,
>5	byte		0		keymode: 8bit
>5	byte		1		keymode: 4bit
>5	byte		2		keymode: SHA-1 hash
>5	byte		3		keymode: MD5 hash
>5	byte		<0		invalid keymode
>5	byte		>3		invalid keymode

#------------------------------------------------------------------------------
# pgp:  file(1) magic for Pretty Good Privacy
#
#0       beshort         0x9900                  PGP key public ring
#0       beshort         0x9501                  PGP key security ring
#0       beshort         0x9500                  PGP key security ring
#0	beshort		0xa600			PGP encrypted data
0       string          -----BEGIN\040PGP       PGP armored data
>15     string          PUBLIC\040KEY\040BLOCK- public key block
>15     string          MESSAGE-                message
>15     string          SIGNED\040MESSAGE-      signed message
>15     string          PGP\040SIGNATURE-       signature


#------------------Standard file formats------------------------------------

#------------------------------------------------------------------------------
# elf:  file(1) magic for ELF executables
#
# We have to check the byte order flag to see what byte order all the
# other stuff in the header is in.
#
# What're the correct byte orders for the nCUBE and the Fujitsu VPP500?
#
# updated by Daniel Quinlan (quinlan@yggdrasil.com)
0	string		\177ELF		ELF
>4	byte		0		invalid class
>4	byte		1		32-bit
# only for MIPS - in the future, the ABI field of e_flags should be used.
>>18	leshort		8
>>>36	lelong		&0x20		N32
>>18	leshort		10
>>>36	lelong		&0x20		N32
>>18	beshort		8
>>>36	belong		&0x20		N32
>>18	beshort		10
>>>36	belong		&0x20		N32
>4	byte		2		64-bit
>5	byte		0		invalid byte order
>5	byte		1		LSB
# The official e_machine number for MIPS is now #8, regardless of endianness.
# The second number (#10) will be deprecated later. For now, we still
# say something if #10 is encountered, but only gory details for #8.
>>18    leshort		8
# only for 32-bit
>>>4	byte		1
>>>>36  lelong&0xf0000000	0x00000000	MIPS-I
>>>>36  lelong&0xf0000000	0x10000000	MIPS-II
>>>>36  lelong&0xf0000000	0x20000000	MIPS-III
>>>>36  lelong&0xf0000000	0x30000000	MIPS-IV
>>>>36  lelong&0xf0000000	0x40000000	MIPS-V
>>>>36  lelong&0xf0000000	0x60000000	MIPS32
>>>>36  lelong&0xf0000000	0x70000000	MIPS64
>>>>36  lelong&0xf0000000	0x80000000	MIPS32 rel2
>>>>36  lelong&0xf0000000	0x90000000	MIPS64 rel2
# only for 64-bit
>>>4	byte		2
>>>>48  lelong&0xf0000000	0x00000000	MIPS-I
>>>>48  lelong&0xf0000000	0x10000000	MIPS-II
>>>>48  lelong&0xf0000000	0x20000000	MIPS-III
>>>>48  lelong&0xf0000000	0x30000000	MIPS-IV
>>>>48  lelong&0xf0000000	0x40000000	MIPS-V
>>>>48  lelong&0xf0000000	0x60000000	MIPS32
>>>>48  lelong&0xf0000000	0x70000000	MIPS64 
>>>>48  lelong&0xf0000000	0x80000000	MIPS32 rel2
>>>>48  lelong&0xf0000000	0x90000000	MIPS64 rel2
>>16	leshort		0		no file type,
>>16	leshort		1		relocatable,
>>16	leshort		2		executable,
>>16	leshort		3		shared object,
# Core handling from Peter Tobias <tobias@server.et-inf.fho-emden.de>
# corrections by Christian 'Dr. Disk' Hechelmann <drdisk@ds9.au.s.shuttle.de>
>>16	leshort		4		core file
# Core file detection is not reliable.
#>>>(0x38+0xcc) string	>\0		of '%s'
#>>>(0x38+0x10) lelong	>0		(signal %d),
>>16	leshort		&0xff00		processor-specific,
>>18	leshort		0		no machine,
>>18	leshort		1		AT&T WE32100 - invalid byte order,
>>18	leshort		2		SPARC - invalid byte order,
>>18	leshort		3		Intel 80386,
>>18	leshort		4		Motorola
>>>36	lelong		&0x01000000	68000 - invalid byte order,
>>>36	lelong		&0x00810000	CPU32 - invalid byte order,
>>>36	lelong		0		68020 - invalid byte order,
>>18	leshort		5		Motorola 88000 - invalid byte order,
>>18	leshort		6		Intel 80486,
>>18	leshort		7		Intel 80860,
>>18	leshort		8		MIPS,
>>18	leshort		9		Amdahl - invalid byte order,
>>18	leshort		10		MIPS (deprecated),
>>18	leshort		11		RS6000 - invalid byte order,
>>18	leshort		15		PA-RISC - invalid byte order,
>>>50	leshort		0x0214		2.0
>>>48	leshort		&0x0008		(LP64),
>>18	leshort		16		nCUBE,
>>18	leshort		17		Fujitsu VPP500,
>>18	leshort		18		SPARC32PLUS,
>>18	leshort		20		PowerPC,
>>18	leshort		22		IBM S/390,
>>18	leshort		36		NEC V800,
>>18	leshort		37		Fujitsu FR20,
>>18	leshort		38		TRW RH-32,
>>18	leshort		39		Motorola RCE,
>>18	leshort		40		ARM,
>>18	leshort		41		Alpha,
>>18	leshort		0xa390		IBM S/390 (obsolete),
>>18	leshort		42		Hitachi SH,
>>18	leshort		43		SPARC V9 - invalid byte order,
>>18	leshort		44		Siemens Tricore Embedded Processor,
>>18	leshort		45		Argonaut RISC Core, Argonaut Technologies Inc.,
>>18	leshort		46		Hitachi H8/300,
>>18	leshort		47		Hitachi H8/300H,
>>18	leshort		48		Hitachi H8S,
>>18	leshort		49		Hitachi H8/500,
>>18	leshort		50		IA-64 (Intel 64 bit architecture)
>>18	leshort		51		Stanford MIPS-X,
>>18	leshort		52		Motorola Coldfire,
>>18	leshort		53		Motorola M68HC12,
>>18	leshort		62		AMD x86-64,
>>18	leshort		75		Digital VAX,
>>18	leshort		97		NatSemi 32k,
>>18	leshort		0x9026		Alpha (unofficial),
>>20	lelong		0		invalid version
>>20	lelong		1		version 1
>>36	lelong		1		MathCoPro/FPU/MAU Required
>5	byte		2		MSB
# only for MIPS - see comment in little-endian section above.
>>18    beshort		8
# only for 32-bit
>>>4	byte		1
>>>>36  belong&0xf0000000	0x00000000	MIPS-I
>>>>36  belong&0xf0000000	0x10000000	MIPS-II
>>>>36  belong&0xf0000000	0x20000000	MIPS-III
>>>>36  belong&0xf0000000	0x30000000	MIPS-IV
>>>>36  belong&0xf0000000	0x40000000	MIPS-V
>>>>36  belong&0xf0000000	0x60000000	MIPS32
>>>>36  belong&0xf0000000	0x70000000	MIPS64
>>>>36  belong&0xf0000000	0x80000000	MIPS32 rel2
>>>>36  belong&0xf0000000	0x90000000	MIPS64 rel2
# only for 64-bit
>>>4	byte		2
>>>>48	belong&0xf0000000	0x00000000	MIPS-I
>>>>48	belong&0xf0000000	0x10000000	MIPS-II
>>>>48	belong&0xf0000000	0x20000000	MIPS-III
>>>>48	belong&0xf0000000	0x30000000	MIPS-IV
>>>>48	belong&0xf0000000	0x40000000	MIPS-V
>>>>48	belong&0xf0000000	0x60000000	MIPS32
>>>>48	belong&0xf0000000	0x70000000	MIPS64 
>>>>48	belong&0xf0000000	0x80000000	MIPS32 rel2
>>>>48	belong&0xf0000000	0x90000000	MIPS64 rel2
>>16	beshort		0		no file type,
>>16	beshort		1		relocatable,
>>16	beshort		2		executable,
>>16	beshort		3		shared object,
>>16	beshort		4		core file,
#>>>(0x38+0xcc) string	>\0		of '%s'
#>>>(0x38+0x10) belong	>0		(signal %d),
>>16	beshort		&0xff00		processor-specific,
>>18	beshort		0		no machine,
>>18	beshort		1		AT&T WE32100,
>>18	beshort		2		SPARC,
>>18	beshort		3		Intel 80386 - invalid byte order,
>>18	beshort		4		Motorola
>>>36	belong		&0x01000000	68000,
>>>36	belong		&0x00810000	CPU32,
>>>36	belong		0		68020,
>>18	beshort		5		Motorola 88000,
>>18	beshort		6		Intel 80486 - invalid byte order,
>>18	beshort		7		Intel 80860,
>>18	beshort		8		MIPS,
>>18	beshort		9		Amdahl,
>>18	beshort		10		MIPS (deprecated),
>>18	beshort		11		RS6000,
>>18	beshort		15		PA-RISC
>>>50	beshort		0x0214		2.0
>>>48	beshort		&0x0008		(LP64)
>>18	beshort		16		nCUBE,
>>18	beshort		17		Fujitsu VPP500,
>>18	beshort		18		SPARC32PLUS,
>>>36	belong&0xffff00	&0x000100	V8+ Required,
>>>36	belong&0xffff00	&0x000200	Sun UltraSPARC1 Extensions Required,
>>>36	belong&0xffff00	&0x000400	HaL R1 Extensions Required,
>>>36	belong&0xffff00	&0x000800	Sun UltraSPARC3 Extensions Required,
>>18	beshort		20		PowerPC or cisco 4500,
>>18	beshort		21		cisco 7500,
>>18	beshort		22		IBM S/390,
>>18	beshort		24		cisco SVIP,
>>18	beshort		25		cisco 7200,
>>18	beshort		36		NEC V800 or cisco 12000,
>>18	beshort		37		Fujitsu FR20,
>>18	beshort		38		TRW RH-32,
>>18	beshort		39		Motorola RCE,
>>18	beshort		40		ARM,
>>18	beshort		41		Alpha,
>>18	beshort		42		Hitachi SH,
>>18	beshort		43		SPARC V9,
>>18	beshort		44		Siemens Tricore Embedded Processor,
>>18	beshort		45		Argonaut RISC Core, Argonaut Technologies Inc.,
>>18	beshort		46		Hitachi H8/300,
>>18	beshort		47		Hitachi H8/300H,
>>18	beshort		48		Hitachi H8S,
>>18	beshort		49		Hitachi H8/500,
>>18	beshort		50		Intel Merced Processor,
>>18	beshort		51		Stanford MIPS-X,
>>18	beshort		52		Motorola Coldfire,
>>18	beshort		53		Motorola M68HC12,
>>18	beshort		73		Cray NV1,
>>18	beshort		75		Digital VAX,
>>18	beshort		97		NatSemi 32k,
>>18	beshort		0x9026		Alpha (unofficial),
>>18	beshort		0xa390		IBM S/390 (obsolete),
>>18    beshort         0xde3d          Ubicom32,
>>20	belong		0		invalid version
>>20	belong		1		version 1
>>36	belong		1		MathCoPro/FPU/MAU Required
# Up to now only 0, 1 and 2 are defined; I've seen a file with 0x83, it seemed
# like proper ELF, but extracting the string had bad results.
>4      byte            <0x80
>>8	string		>\0		("%s")
>8	string		\0
>>7	byte		0		(SYSV)
>>7	byte		1		(HP-UX)
>>7	byte		2		(NetBSD)
>>7	byte		3		(GNU/Linux)
>>7	byte		4		(GNU/Hurd)
>>7	byte		5		(86Open)
>>7	byte		6		(Solaris)
>>7	byte		7		(Monterey)
>>7	byte		8		(IRIX)
>>7	byte		9		(FreeBSD)
>>7	byte		10		(Tru64)
>>7	byte		11		(Novell Modesto)
>>7	byte		12		(OpenBSD)
>>7	byte		97		(ARM)
>>7	byte		255		(embedded)

# XXX - according to Microsoft's spec, at an offset of 0x3c in a
# PE-format executable is the offset in the file of the PE header;
# unfortunately, that's a little-endian offset, and there's no way
# to specify an indirect offset with a specified byte order.
# So, for now, we assume the standard MS-DOS stub, which puts the
# PE header at 0x80 = 128.
#
# Required OS version and subsystem version were 4.0 on some NT 3.51
# executables built with Visual C++ 4.0, so it's not clear that
# they're interesting.  The user version was 0.0, but there's
# probably some linker directive to set it.  The linker version was
# 3.0, except for one ".exe" which had it as 4.20 (same damn linker!).
#
# many of the compressed formats were extraced from IDARC 1.23 source code
#
0       string  MZ	Microsoft
>0x18  leshort <0x40 MS-DOS executable
>0 string MZ\0\0\0\0\0\0\0\0\0\0PE\0\0 \b, PE for MS Windows
>>&18   leshort&0x2000  >0      (DLL)
>>&88   leshort         0       (unknown subsystem)
>>&88   leshort         1       (native)
>>&88   leshort         2       (GUI)
>>&88   leshort         3       (console)
>>&88   leshort         7       (POSIX)
>>&0    leshort         0x0     unknown processor
>>&0    leshort         0x14c   Intel 80386
>>&0    leshort         0x166   MIPS R4000
>>&0    leshort         0x184   Alpha
>>&0    leshort         0x268   Motorola 68000
>>&0    leshort         0x1f0   PowerPC
>>&0    leshort         0x290   PA-RISC
>>&18   leshort&0x0100  >0      32-bit
>>&18   leshort&0x1000  >0      system file
>>&228  lelong          >0      \b, Mono/.Net assembly
>>&0xf4 search/0x140 \x0\x40\x1\x0
>>>(&0.l+(4)) string MSCF \b, WinHKI CAB self-extracting archive
>30             string  Copyright\x201989-1990\x20PKWARE\x20Inc.      Self-extracting PKZIP archive
# Is next line correct? One might expect "Corp." not "Copr." If it is right, add a note to that effect.
>30             string  PKLITE\x20Copr.   Self-extracting PKZIP archive

>0x18  leshort >0x3f
>>(0x3c.l) string PE\0\0 PE
>>>(0x3c.l+25) byte             1 \b32 executable
>>>(0x3c.l+25) byte             2 \b32+ executable
# hooray, there's a DOS extender using the PE format, with a valid PE
# executable inside (which just prints a message and exits if run in win)
>>>(0x3c.l+92)  leshort         <10
>>>>(8.s*16) string 32STUB for MS-DOS, 32rtm DOS extender
>>>>(8.s*16) string !32STUB for MS Windows
>>>>>(0x3c.l+22)        leshort&0x2000  >0      (DLL)
>>>>>(0x3c.l+92)        leshort         0       (unknown subsystem)
>>>>>(0x3c.l+92)        leshort         1       (native)
>>>>>(0x3c.l+92)        leshort         2       (GUI)
>>>>>(0x3c.l+92)        leshort         3       (console)
>>>>>(0x3c.l+92)        leshort         7       (POSIX)
>>>(0x3c.l+92)  leshort         10      (EFI application)
>>>(0x3c.l+92)  leshort         11      (EFI boot service driver)
>>>(0x3c.l+92)  leshort         12      (EFI runtime driver)
>>>(0x3c.l+92)  leshort         13      (XBOX)
>>>(0x3c.l+4)   leshort         0x0     unknown processor
>>>(0x3c.l+4)   leshort         0x14c   Intel 80386
>>>(0x3c.l+4)   leshort         0x166   MIPS R4000
>>>(0x3c.l+4)   leshort         0x184   Alpha
>>>(0x3c.l+4)   leshort         0x268   Motorola 68000
>>>(0x3c.l+4)   leshort         0x1f0   PowerPC
>>>(0x3c.l+4)   leshort         0x290   PA-RISC
>>>(0x3c.l+4)   leshort         0x200   Intel Itanium
>>>(0x3c.l+22)  leshort&0x0100  >0      32-bit
>>>(0x3c.l+22)  leshort&0x1000  >0      system file
>>>(0x3c.l+232) lelong  >0      Mono/.Net assembly
>>>>(0x3c.l+0xf8)       string          UPX0 \b, UPX compressed
>>>>(0x3c.l+0xf8)       search/0x140    PEC2 \b, PECompact2 compressed
>>>>(0x3c.l+0xf8)       search/0x140    UPX2
>>>>>(&0x10.l+(-4))     string          PK\3\4 \b, ZIP self-extracting archive (Info-Zip)
>>>>(0x3c.l+0xf8)       search/0x140    .idata
>>>>>(&0xe.l+(-4))      string          PK\3\4 \b, ZIP self-extracting archive (Info-Zip)
>>>>>(&0xe.l+(-4))      string          ZZ0 \b, ZZip self-extracting archive
>>>>>(&0xe.l+(-4))      string          ZZ1 \b, ZZip self-extracting archive
>>>>(0x3c.l+0xf8)       search/0x140    .rsrc
>>>>>(&0x0f.l+(-4))     string          a\\\4\5 \b, WinHKI self-extracting archive
>>>>>(&0x0f.l+(-4))     string          Rar! \b, RAR self-extracting archive
>>>>>(&0x0f.l+(-4))     search/0x3000   MSCF \b, InstallShield self-extracting archive
>>>>>(&0x0f.l+(-4))     search/32       Nullsoft \b, Nullsoft Installer self-extracting archive
>>>>(0x3c.l+0xf8)       search/0x140    .data
>>>>>(&0x0f.l)          string          WEXTRACT \b, MS CAB-Installer self-extracting archive
>>>>(0x3c.l+0xf8)       search/0x140    .petite\0 \b, Petite compressed
>>>>>(0x3c.l+0xf7)      byte            x
>>>>>>(&0x104.l+(-4))   string          =!sfx! \b, ACE self-extracting archive
>>>>(0x3c.l+0xf8)       search/0x140    .WISE \b, WISE installer self-extracting archive
>>>>(0x3c.l+0xf8)       search/0x140    .dz\0\0\0 \b, Dzip self-extracting archive
>>>>(0x3c.l+0xf8)       search/0x140    .reloc
>>>>>(&0xe.l+(-4))      search/0x180    PK\3\4 \b, ZIP self-extracting archive (WinZip)

>>>>&(0x3c.l+0xf8)      search/0x100    _winzip_ \b, ZIP self-extracting archive (WinZip)
>>>>&(0x3c.l+0xf8)      search/0x100    SharedD \b, Microsoft Installer self-extracting archive
>>>>0x30                string          Inno \b, InnoSetup self-extracting archive

>>(0x3c.l) string !PE\0\0 MS-DOS executable

>>(0x3c.l)              string          NE \b, NE
>>>(0x3c.l+0x36)        byte            0 (unknown OS)
>>>(0x3c.l+0x36)        byte            1 for OS/2 1.x
>>>(0x3c.l+0x36)        byte            2 for MS Windows 3.x
>>>(0x3c.l+0x36)        byte            3 for MS-DOS
>>>(0x3c.l+0x36)        byte            >3 (unknown OS)
>>>(0x3c.l+0x36)        byte            0x81 for MS-DOS, Phar Lap DOS extender
>>>(0x3c.l+0x0c)        leshort&0x8003  0x8002 (DLL)
>>>(0x3c.l+0x0c)        leshort&0x8003  0x8001 (driver)
>>>&(&0x24.s-1)         string          ARJSFX \b, ARJ self-extracting archive
>>>(0x3c.l+0x70)        search/0x80     WinZip(R)\x20Self-Extractor \b, ZIP self-extracting archive (WinZip)

>>(0x3c.l)              string          LX\0\0 \b, LX
>>>(0x3c.l+0x0a)        leshort         <1 (unknown OS)
>>>(0x3c.l+0x0a)        leshort         1 for OS/2
>>>(0x3c.l+0x0a)        leshort         2 for MS Windows
>>>(0x3c.l+0x0a)        leshort         3 for DOS
>>>(0x3c.l+0x0a)        leshort         >3 (unknown OS)
>>>(0x3c.l+0x10)        lelong&0x28000  =0x8000 (DLL)
>>>(0x3c.l+0x10)        lelong&0x20000  >0 (device driver)
>>>(0x3c.l+0x10)        lelong&0x300    0x300 (GUI)
>>>(0x3c.l+0x10)        lelong&0x28300  <0x300 (console)
>>>(0x3c.l+0x08)        leshort         1 i80286
>>>(0x3c.l+0x08)        leshort         2 i80386
>>>(0x3c.l+0x08)        leshort         3 i80486
>>>(8.s*16)             string          emx \b, emx
>>>>&1                  string          x "%s"
>>>&(&0x54.l-3)         string          arjsfx \b, ARJ self-extracting archive



#------------------------------------------------------------------------------
# bFLT: file(1) magic for BFLT uclinux binary files
#
# From Philippe De Muyter <phdm@macqel.be>
# 
# Additional fields added by Craig Heffner
#
0       string          bFLT            BFLT executable 
>4      belong          x               version %ld, 
>4      belong          4
>8	belong		x		code offset: 0x%.8X, 
>12	belong		x		data segment starts at: 0x%.8X, 
>16	belong		x		bss segment starts at: 0x%.8X, 
>20	belong		x		bss segment ends at: 0x%.8X, 
>24	belong		x		stack size: %d bytes, 
>28	belong 		x		relocation records start at: 0x%.8X, 
>32	belong		x		number of reolcation records: %d, 
>>36    belong&0x1      0x1             ram
>>36    belong&0x2      0x2             gotpic
>>36    belong&0x4      0x4             gzip
>>36    belong&0x8      0x8             gzdata


#-----------------------------------------------------------------
# MIPS COFF file formats
#
0       beshort 0x0160          MIPSEB ECOFF executable
>20     beshort 0407            (impure)
>20     beshort 0410            (swapped)
>20     beshort 0413            (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>22     byte    x               - version %ld
>23     byte    x               \b.%ld
#
0       beshort 0x0162          MIPSEL-BE ECOFF executable
>20     beshort 0407            (impure)
>20     beshort 0410            (swapped)
>20     beshort 0413            (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>23     byte    x               - version %d
>22     byte    x               \b.%ld
#
0       beshort 0x6001          MIPSEB-LE ECOFF executable
>20     beshort 03401           (impure)
>20     beshort 04001           (swapped)
>20     beshort 05401           (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>23     byte    x               - version %d
>22     byte    x               \b.%ld
#
0       beshort 0x6201          MIPSEL ECOFF executable
>20     beshort 03401           (impure)
>20     beshort 04001           (swapped)
>20     beshort 05401           (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>23     byte    x               - version %ld
>22     byte    x               \b.%ld
# MIPS 2 additions
#
0       beshort 0x0163          MIPSEB MIPS-II ECOFF executable
>20     beshort 0407            (impure)
>20     beshort 0410            (swapped)
>20     beshort 0413            (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>22     byte    x               - version %ld
>23     byte    x               \b.%ld
#
0       beshort 0x0166          MIPSEL-BE MIPS-II ECOFF executable
>20     beshort 0407            (impure)
>20     beshort 0410            (swapped)
>20     beshort 0413            (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>22     byte    x               - version %ld
>23     byte    x               \b.%ld
#
0       beshort 0x6301          MIPSEB-LE MIPS-II ECOFF executable
>20     beshort 03401           (impure)
>20     beshort 04001           (swapped)
>20     beshort 05401           (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>23     byte    x               - version %ld
>22     byte    x               \b.%ld
#
0       beshort 0x6601          MIPSEL MIPS-II ECOFF executable
>20     beshort 03401           (impure)
>20     beshort 04001           (swapped)
>20     beshort 05401           (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>23     byte    x               - version %ld
>22     byte    x               \b.%ld
# MIPS 3 additions
#
0       beshort 0x0140          MIPSEB MIPS-III ECOFF executable
>20     beshort 0407            (impure)
>20     beshort 0410            (swapped)
>20     beshort 0413            (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>22     byte    x               - version %ld
>23     byte    x               \b.%ld
#
0       beshort 0x0142          MIPSEL-BE MIPS-III ECOFF executable
>20     beshort 0407            (impure)
>20     beshort 0410            (swapped)
>20     beshort 0413            (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>22     byte    x               - version %ld
>23     byte    x               \b.%ld
#
0       beshort 0x4001          MIPSEB-LE MIPS-III ECOFF executable
>20     beshort 03401           (impure)
>20     beshort 04001           (swapped)
>20     beshort 05401           (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>23     byte    x               - version %ld
>22     byte    x               \b.%ld
#
0       beshort 0x4201          MIPSEL MIPS-III ECOFF executable
>20     beshort 03401           (impure)
>20     beshort 04001           (swapped)
>20     beshort 05401           (paged)
>8      belong  >0              not stripped
>8      belong  0               stripped
>23     byte    x               - version %ld
>22     byte    x               \b.%ld
#
0       beshort 0x180           MIPSEB Ucode
0       beshort 0x182           MIPSEL-BE Ucode


# Windows CE package files
0       string          MSCE\0\0\0\0    Microsoft WinCE installer
>20     lelong          0               \b, architecture-independent
>20     lelong          103             \b, Hitachi SH3
>20     lelong          104             \b, Hitachi SH4
>20     lelong          0xA11           \b, StrongARM
>20     lelong          4000            \b, MIPS R4000
>20     lelong          10003           \b, Hitachi SH3
>20     lelong          10004           \b, Hitachi SH3E
>20     lelong          10005           \b, Hitachi SH4
>20     lelong          70001           \b, ARM 7TDMI
>52     leshort         1               \b, 1 file
>52     leshort         >1              \b, %u files
>56     leshort         1               \b, 1 registry entry
>56     leshort         >1              \b, %u registry entries

#------------------------------------------------------------------------------
# Microsoft Xbox executables .xbe (Esa HyytiÃ¤ <ehyytia@cc.hut.fi>)
0       string          XBEH            XBE, Microsoft Xbox executable
# probabilistic checks whether signed or not
>0x0004 ulelong =0x0
>>&2    ulelong =0x0
>>>&2   ulelong =0x0  \b, not signed
>0x0004 ulelong >0
>>&2    ulelong >0
>>>&2   ulelong >0    \b, signed
# expect base address of 0x10000
>0x0104               ulelong =0x10000
>>(0x0118-0x0FF60)    ulelong&0x80000007  0x80000007 \b, all regions
>>(0x0118-0x0FF60)    ulelong&0x80000007  !0x80000007
>>>(0x0118-0x0FF60)   ulelong >0           (regions:
>>>>(0x0118-0x0FF60)  ulelong &0x00000001  NA
>>>>(0x0118-0x0FF60)  ulelong &0x00000002  Japan
>>>>(0x0118-0x0FF60)  ulelong &0x00000004  Rest_of_World
>>>>(0x0118-0x0FF60)  ulelong &0x80000000  Manufacturer
>>>(0x0118-0x0FF60)   ulelong >0           \b)

#------------------------------------------------------------------------------
# motorola:  file(1) magic for Motorola 68K and 88K binaries
#
# 68K
#
0       beshort         0x0208          mc68k COFF
>18     beshort         ^00000020       object
>18     beshort         &00000020       executable
>12     belong          >0              not stripped
>168    string          .lowmem         Apple toolbox
>20     beshort         0407            (impure)
>20     beshort         0410            (pure)
>20     beshort         0413            (demand paged)
>20     beshort         0421            (standalone)
0       beshort         0x0209          mc68k executable (shared)
>12     belong          >0              not stripped
0       beshort         0x020A          mc68k executable (shared demand paged)
>12     belong          >0              not stripped


#
# Motorola/UniSoft 68K Binary Compatibility Standard (BCS)
#
0       beshort         0x022A            68K BCS executable
#
# 88K
#
# Motorola/88Open BCS
#
0       beshort         0x022B            88K BCS executable

#------------------------------------------------------------------------------
# Sony Playstation executables (Adam Sjoegren <asjo@diku.dk>) :
0       string  PS-X\x20EXE       Sony Playstation executable
#  Area:
>113    string  x               ("%s")

#------------------------------------------------------------------------------
# cisco:  file(1) magic for cisco Systems routers
#
# Most cisco file-formats are covered by the generic elf code
#
# Microcode files are non-ELF, 0x8501 conflicts with NetBSD/alpha.
0	beshort			0x8501	    cisco IOS
>0      belong&0xffffff00       0x85011400  microcode
>0      belong&0xffffff00       0x8501cb00  experimental microcode
>7      string          	>\0         for "%s"

# EST flat binary format (which isn't, but anyway)
# From: Mark Brown <broonie@sirena.org.uk>
0	string	ESTFBINR	EST flat binary

# These are not the binaries themselves, but string references to them
# are a strong indication that they exist elsewhere...
#0	string	/bin/busybox	Busybox string reference: "%s"{one-of-many}
#0	string /bin/sh		Shell string reference: "%s"{one-of-many}

#--------------------File Systems---------------------

# Minix filesystems - Juan Cespedes <cespedes@debian.org>
0x410   leshort         0x137f          Minix filesystem
>0x402  beshort         !0              \b, %d zones
>0x1e   string          minix           \b, bootable
0x410   leshort         0x138f          Minix filesystem, 30 char names
0x410   leshort         0x2468          Minix filesystem, version 2
0x410   leshort         0x2478          Minix filesystem, version 2, 30 char names
0x410	leshort		0x4d5a		Minix filesystem, version 3
0x410	leshort		0x4d6a		Minix filesystem, version 3, 30 char names

0x410   beshort         0x137f          Minix filesystem (big endian)
>0x402  beshort         !0              \b, %d zones
>0x1e   string          minix           \b, bootable
0x410   beshort         0x138f          Minix filesystem (big endian), 30 char names
0x410   beshort         0x2468          Minix filesystem (big endian), version 2
0x410   beshort         0x2478          Minix filesystem (big endian), version 2, 30 char names
0x410	beshort		0x4d5a		Minix filesystem (big endian), version 3
0x410	beshort		0x4d6a		Minix filesystem (big endian), version 3, 30 char names

# YAFFS
0	string	\x03\x00\x00\x00\x01\x00\x00\x00\xFF\xFF	YAFFS filesystem

# EFS2 file system - jojo@utulsa.edu
0      lelong 0x53000000       EFS2 Qualcomm filesystem super block, little endian,
>8     string !EFSSuper        invalid,
>4     leshort &1              NAND
>4     leshort ^1              NOR
>4     leshort x               version 0x%x,
>24    lelong  x               %d blocks,
>16    lelong  x               0x%x pages per block,
>20    lelong  x               0x%x bytes per page

0      belong 0x53000000       EFS2 Qualcomm filesystem super block, big endian,
>8     string !SSFErepu	       invalid,
>4     beshort &1              NAND
>4     beshort ^1              NOR
>4     beshort x               version 0x%x,
>24    belong  x               %d blocks,
>16    belong  x               0x%x pages per block,
>20    belong  x               0x%x bytes per page

# TROC file system
0	string	TROC		TROC filesystem,
>4	lelong	x		%d file entries

# PFS file system
0	string	PFS/		PFS filesystem,
>4	string	x		version "%s",
>14	leshort	x		%d files

# MPFS file system
0	string	MPFS		MPFS (Microchip) filesystem,
>4	byte	x		version %d.
>5	byte	x		\b%d,
>6	leshort	x		%d file entries

# cramfs filesystem - russell@coker.com.au
0       lelong  0x28cd3d45      CramFS filesystem, little endian
>4	lelong	<0		invalid
>4      lelong  x 		size %lu
>8      lelong  &1 		version #2
>8      lelong  &2 		sorted_dirs
>8      lelong  &4 		hole_support
>32     lelong  x 		CRC 0x%x,
>36     lelong  x 		edition %lu,
>40	lelong	<0		invalid
>40     lelong  x 		%lu blocks,
>44	lelong	<0		invalid
>44     lelong  x 		%lu files
>4      lelong  x 		{jump-to-offset:%lu}
>4      lelong  x 		{file-size:%lu}

0       belong  0x28cd3d45      CramFS filesystem, big endian
>4	belong	<0		invalid
>4      belong  x 		size %lu
>8      belong  &1 		version #2
>8      belong  &2 		sorted_dirs
>8      belong  &4 		hole_support
>32     belong  x 		CRC 0x%x,
>36     belong  x 		edition %lu,
>40	belong	<0		invalid
>40     belong  x 		%lu blocks,
>44	belong	<0		invalid
>44     belong  x 		%lu files
>4      belong  x 		{jump-to-offset:%lu}
>4      belong  x 		{file-size:%lu}



# JFFS2 file system
# If used with binwalk's smart signature feature (on by default, -S to disable)
# this signature can potentially lead to missing some JFFS2 file systems if there
# are multiple JFFS2 file systems in a target file and there are no other identified
# files in between the JFFS2 file systems. This is an unlikely scenario however, and
# the below signatures are much improved in terms of readability and accuracy in the
# vast majority of real world scenarios.
0		leshort 0x1985	JFFS2 filesystem, little endian{filter-include}
>2		leshort !0xE001
>>2		leshort !0xE002
>>>2		leshort !0x2003
>>>>2		leshort !0x2004
>>>>>2		leshort !0x2006
>>>>>>2		leshort !0xE008
>>>>>>>2	leshort !0xE009	\b, invalid
>(4.l)		leshort !0x1985		
>>(4.l+1)	leshort !0x1985	
>>>(4.l+2)	leshort !0x1985	
>>>>(4.l+3)	leshort !0x1985
>>>>>(4.l)      leshort !0xFFFF
>>>>>>(4.l+1)   leshort !0xFFFF
>>>>>>>(4.l+2)  leshort !0xFFFF
>>>>>>>>(4.l+3) leshort !0xFFFF \b, invalid
>4		lelong	x	{one-of-many}{jump-to-offset:%d}

0       	beshort 0x1985	JFFS2 filesystem, big endian{filter-include}
>2		beshort !0xE001
>>2		beshort !0xE002
>>>2		beshort !0x2003
>>>>2		beshort !0x2004
>>>>>2		beshort !0x2006
>>>>>>2		beshort !0xE008
>>>>>>>2	beshort !0xE009	\b, invalid
>(4.L)		beshort	!0x1985	 
>>(4.L+1)	beshort	!0x1985	 
>>>(4.L+2)	beshort	!0x1985
>>>>(4.L+3)	beshort	!0x1985	
>>>>>(4.L)	beshort !0xFFFF
>>>>>>(4.L+1)	beshort !0xFFFF
>>>>>>>(4.L+2)	beshort !0xFFFF
>>>>>>>>(4.L+3)	beshort !0xFFFF \b, invalid
>4		belong	x	{one-of-many}{jump-to-offset:%d}


# Squashfs, big endian
0       string  sqsh    Squashfs filesystem, big endian,
>28     beshort >10     invalid
>28     beshort <1      invalid
>30	beshort >10	invalid
>28     beshort x       version %d.
>30     beshort x       \b%d,
>28     beshort >3      compression:
>>20    beshort 1       \bgzip,
>>20    beshort 2       \blzma,
>>20    beshort 0       \binvalid,
>>20    beshort >4      \binvalid,
>28     beshort <3
>>8     belong  x       size: %d bytes,
>28     beshort 3
>>63    bequad x        size: %lld bytes,
>28     beshort >3
>>40    bequad  x       size: %lld bytes,
>4      belong  x       %d inodes,
>28     beshort >3
>>12    belong          blocksize: %d bytes,
>28     beshort <2
>>32    beshort x       blocksize: %d bytes,
>28     beshort 2
>>51    belong  x       blocksize: %d bytes,
>28     beshort 3
>>51    belong  x       blocksize: %d bytes,
>28     beshort >3
>>12    belong  x       blocksize: %d bytes,
>28     beshort <4
>>39    bedate  x       created: %s
>28     beshort >3
>>8     bedate x        created: %s
>28	beshort <3
>>8	belong	x	{jump-to-offset:%d}
>28	beshort	3	
>>63	bequad	x	{jump-to-offset:%lld}
>28	beshort	>3
>>40	bequad	x	{jump-to-offset:%lld}

# Squashfs, little endian
0       string  hsqs    Squashfs filesystem, little endian,
>28     leshort >10     invalid
>28     leshort <1      invalid
>30	leshort >10	invalid
>28     leshort x       version %d.
>30     leshort x       \b%d,
>28	leshort >3	compression: 
>>20	leshort 1	\bgzip,
>>20	leshort	2	\blzma,
>>20	leshort 0	\binvalid,
>>20	leshort >4	\binvalid,
>28     leshort <3
>>8     lelong  x       size: %d bytes,
>>8     lelong  x       {file-size:%d}
>28     leshort 3
>>63    lequad x        size: %lld bytes,
>>63    lequad x        {file-size:%lld}
>28	leshort >3	
>>40	lequad	x	size: %lld bytes,
>>40	lequad	x	{file-size:%lld}
>4      lelong  x       %d inodes,
>28	leshort >3
>>12	lelong		blocksize: %d bytes,
>28     leshort <2
>>32    leshort x       blocksize: %d bytes,
>28     leshort 2
>>51    lelong  x       blocksize: %d bytes,
>28	leshort 3
>>51	lelong 	x	blocksize: %d bytes,
>28	leshort	>3	
>>12	lelong	x	blocksize: %d bytes,
>28	leshort <4
>>39    ledate  x	created: %s
>28	leshort >3
>>8	ledate x	created: %s
>28     leshort <3
>>8     lelong  x       {jump-to-offset:%d}
>28     leshort 3
>>63    lequad x        {jump-to-offset:%lld}
>28     leshort >3
>>40    lequad  x       {jump-to-offset:%lld}

# Squashfs with LZMA compression
0       string  sqlz    Squashfs filesystem, big endian, lzma compression, 
>28     beshort >10     invalid
>28     beshort <1      invalid
>30	beshort >10	invalid
>28     beshort x       version %d.
>30     beshort x       \b%d,
>28     beshort >3      compression:
>>20    beshort 1       \bgzip,
>>20    beshort 2       \blzma,
>>20    beshort 0       \binvalid,
>>20    beshort >4      \binvalid,
>28     beshort <3
>>8     belong  x       size: %d bytes,
>>8     belong  x       {file-size:%d}
>28     beshort 3
>>63    bequad x        size: %lld bytes,
>>63    bequad x        {file-size:%lld}
>28     beshort >3
>>40    bequad  x       size: %lld bytes,
>>40    bequad  x       {file-size:%lld}
>4      belong  x       %d inodes,
>28     beshort >3
>>12    belong          blocksize: %d bytes,
>28     beshort <2
>>32    beshort x       blocksize: %d bytes,
>28     beshort 2
>>51    belong  x       blocksize: %d bytes,
>28     beshort 3
>>51    belong  x       blocksize: %d bytes,
>28     beshort >3
>>12    belong  x       blocksize: %d bytes,
>28     beshort <4
>>39    bedate  x       created: %s
>28     beshort >3
>>8     bedate x        created: %s
>28     beshort <3
>>8     belong  x       {jump-to-offset:%d}
>28     beshort 3
>>63    bequad  x       {jump-to-offset:%lld}
>28     beshort >3
>>40    bequad  x       {jump-to-offset:%lld}

# Squashfs 3.3 LZMA signature
0       string  qshs    Squashfs filesystem, big endian, lzma signature,
>28     beshort >10     invalid
>28     beshort <1      invalid
>30	beshort >10	invalid
>28     beshort x       version %d.
>30     beshort x       \b%d,
>28     beshort >3      compression:
>>20    beshort 1       \bgzip,
>>20    beshort 2       \blzma,
>>20    beshort 0       \binvalid,
>>20    beshort >4      \binvalid,
>28     beshort <3
>>8     belong  x       size: %d bytes,
>>8     belong  x       {file-size:%d}
>28     beshort 3
>>63    bequad x        size: %lld bytes,
>>63    bequad x        {file-size:%lld}
>28     beshort >3
>>40    bequad  x       size: %lld bytes,
>>40    bequad  x       {file-size:%lld}
>4      belong  x       %d inodes,
>28     beshort >3
>>12    belong          blocksize: %d bytes,
>28     beshort <2
>>32    beshort x       blocksize: %d bytes,
>28     beshort 2
>>51    belong  x       blocksize: %d bytes,
>28     beshort 3
>>51    belong  x       blocksize: %d bytes,
>28     beshort >3
>>12    belong  x       blocksize: %d bytes,
>28     beshort <4
>>39    bedate  x       created: %s
>28     beshort >3
>>8     bedate x        created: %s
>28     beshort <3
>>8     belong  x       {jump-to-offset:%d}
>28     beshort 3
>>63    bequad  x       {jump-to-offset:%lld}
>28     beshort >3
>>40    bequad  x       {jump-to-offset:%lld}

# Squashfs for DD-WRT
0       string  tqsh    Squashfs filesystem, big endian, DD-WRT signature,
>28     beshort >10     invalid
>28     beshort <1      invalid
>30	beshort >10	invalid
>28     beshort x       version %d.
>30     beshort x       \b%d,
>28     beshort >3      compression:
>>20    beshort 1       \bgzip,
>>20    beshort 2       \blzma,
>>20    beshort 0       \binvalid,
>>20    beshort >4      \binvalid,
>28     beshort <3
>>8     belong  x       size: %d bytes,
>>8     belong  x       {file-size:%d}
>28     beshort 3
>>63    bequad x        size: %lld bytes,
>>63    bequad x        {file-size:%lld}
>28     beshort >3
>>40    bequad  x       size: %lld bytes,
>>40    bequad  x       {file-size:%lld}
>4      belong  x       %d inodes,
>28     beshort >3
>>12    belong          blocksize: %d bytes,
>28     beshort <2
>>32    beshort x       blocksize: %d bytes,
>28     beshort 2
>>51    belong  x       blocksize: %d bytes,
>28     beshort 3
>>51    belong  x       blocksize: %d bytes,
>28     beshort >3
>>12    belong  x       blocksize: %d bytes,
>28     beshort <4
>>39    bedate  x       created: %s
>28     beshort >3
>>8     bedate x        created: %s
>28     beshort <3
>>8     belong  x       {jump-to-offset:%d}
>28     beshort 3
>>63    bequad  x       {jump-to-offset:%lld}
>28     beshort >3
>>40    bequad  x       {jump-to-offset:%lld}

# Squashfs for DD-WRT
0       string  hsqt    Squashfs filesystem, little endian, DD-WRT signature,
>28     leshort >10     invalid
>28     leshort <1      invalid
>30	leshort >10	invalid
>28     leshort x       version %d.
>30     leshort x       \b%d,
>28     leshort >3      compression:
>>20    leshort 1       \bgzip,
>>20    leshort 2       \blzma,
>>20    leshort 0       \binvalid,
>>20    leshort >4      \binvalid,
>28     leshort <3
>>8     lelong  x       size: %d bytes,
>>8     lelong  x       {file-size:%d}
>28     leshort 3
>>63    lequad x        size: %lld bytes,
>>63    lequad x        {file-size:%lld}
>28     leshort >3
>>40    lequad  x       size: %lld bytes,
>>40    lequad  x       {file-size:%lld}
>4      lelong  x       %d inodes,
>28     leshort >3
>>12    lelong          blocksize: %d bytes,
>28     leshort <2
>>32    leshort x       blocksize: %d bytes,
>28     leshort 2
>>51    lelong  x       blocksize: %d bytes,
>28     leshort 3
>>51    lelong  x       blocksize: %d bytes,
>28     leshort >3
>>12    lelong  x       blocksize: %d bytes,
>28     leshort <4
>>39    ledate  x       created: %s
>28     leshort >3
>>8     ledate x        created: %s
>28     leshort <3
>>8     lelong  x       {jump-to-offset:%d}
>28     leshort 3
>>63    lequad x        {jump-to-offset:%lld}
>28     leshort >3
>>40    lequad  x       {jump-to-offset:%lld}

# Non-standard Squashfs signature found on some D-Link routers
0       string  shsq    Squashfs filesystem, little endian, non-standard signature, 
>28     leshort >10     invalid
>28     leshort <1      invalid
>30	leshort >10	invalid
>28     leshort x       version %d.
>30     leshort x       \b%d,
>28     leshort >3      compression:
>>20    leshort 1       \bgzip,
>>20    leshort 2       \blzma,
>>20    leshort 0       \binvalid,
>>20    leshort >4      \binvalid,
>28     leshort <3
>>8     lelong  x       size: %d bytes,
>>8     lelong  x       {file-size:%d}
>28     leshort 3
>>63    lequad x        size: %lld bytes,
>>63    lequad x        {file-size:%lld}
>28     leshort >3
>>40    lequad  x       size: %lld bytes,
>>40    lequad  x       {file-size:%lld}
>4      lelong  x       %d inodes,
>28     leshort >3
>>12    lelong          blocksize: %d bytes,
>28     leshort <2
>>32    leshort x       blocksize: %d bytes,
>28     leshort 2
>>51    lelong  x       blocksize: %d bytes,
>28     leshort 3
>>51    lelong  x       blocksize: %d bytes,
>28     leshort >3
>>12    lelong  x       blocksize: %d bytes,
>28     leshort <4
>>39    ledate  x       created: %s
>28     leshort >3
>>8     ledate x        created: %s
>28     leshort <3
>>8     lelong  x       {jump-to-offset:%d}
>28     leshort 3
>>63    lequad x        {jump-to-offset:%lld}
>28     leshort >3
>>40    lequad  x       {jump-to-offset:%lld}

# ext2/ext3 filesystems - Andreas Dilger <adilger@dilger.ca>
# ext4 filesystem - Eric Sandeen <sandeen@sandeen.net>
# volume label and UUID Russell Coker
# http://etbe.coker.com.au/2008/07/08/label-vs-uuid-vs-device/
0   leshort         0xEF53      	Linux EXT filesystem,{filter-include}{offset-adjust:-0x438}
>2	leshort		>4		invalid state
>2	leshort		3		invalid state
>2	leshort		<0		invalid state
>4	leshort		>3		invalid error behavior
>4	leshort		<0		invalid error behavior
>4	lelong		>1		invalid major revision
>4  lelong		<0		invalid major revision
>4  lelong          x               rev %d
>6  leshort         x               \b.%d
# No journal?  ext2
>36  lelong          ^0x0000004      ext2 filesystem data
>>2 leshort         ^0x0000001      (mounted or unclean)
# Has a journal?  ext3 or ext4
>36  lelong          &0x0000004
#  and small INCOMPAT?
>>40 lelong          <0x0000040
#   and small RO_COMPAT?
>>>44 lelong         <0x0000008      ext3 filesystem data
#   else large RO_COMPAT?
>>>44 lelong         >0x0000007      ext4 filesystem data
#  else large INCOMPAT?
>>40 lelong          >0x000003f      ext4 filesystem data
>48  belong          x               \b, UUID=%08x
>52  beshort         x               \b-%04x
>54  beshort         x               \b-%04x
>56  beshort         x               \b-%04x
>58  belong          x               \b-%08x
>60  beshort         x               \b%04x
>64  string          >0              \b, volume name "%s"


#romfs filesystems - Juan Cespedes <cespedes@debian.org>
0       string	-rom1fs-\0		romfs filesystem, version 1
>8	belong	>10000000		invalid
>8      belong  x                       size: %d bytes,
>16	string	x			{file-name:%s}
>16     string  x                       named "%s"
>8	belong	x			{file-size:%d}
>8	belong	x			{jump-to-offset:%d}

# Wind River MemFS file system, found in some VxWorks devices
0	string	owowowowowowowowowowowowowowow		Wind River management filesystem,
>30	string	!ow					invalid,
>32	belong	1					compressed,
>32	belong	2					plain text,
>36	belong	x					%d files


# netboot image - Juan Cespedes <cespedes@debian.org>
0	lelong			0x1b031336L	Netboot image,
>4	lelong&0xFFFFFF00	0
>>4	lelong&0x100		0x000		mode 2
>>4	lelong&0x100		0x100		mode 3
>4	lelong&0xFFFFFF00	!0		unknown mode (invalid)

#--------------------------Firmware Formats---------------------------

# uImage file     
# From: Craig Heffner, U-Boot image.h header definitions file
0	belong	0x27051956	uImage header, header size: 64 bytes,
>4	belong	x		header CRC: 0x%X,
>8	bedate	x		created: %s,
>12	belong	x		image size: %d bytes,
>16	belong	x		Data Address: 0x%X,
>20	belong	x		Entry Point: 0x%X,
>24	belong	x		data CRC: 0x%X,
#>28	byte	x		OS type: %d,
>28	byte	0		OS: invalid OS,
>28	byte	1		OS: OpenBSD,
>28	byte	2		OS: NetBSD,
>28	byte	3		OS: FreeBSD,
>28	byte	4		OS: 4.4BSD,
>28	byte	5		OS: Linux,
>28	byte	6		OS: SVR4,
>28	byte	7		OS: Esix,
>28	byte	8		OS: Solaris,
>28	byte	9		OS: Irix,
>28	byte	10		OS: SCO,
>28	byte	11		OS: Dell,
>28	byte	12		OS: NCR,
>28	byte	13		OS: LynxOS,
>28	byte	14		OS: VxWorks,
>28	byte	15		OS: pSOS,
>28	byte	16		OS: QNX,
>28	byte	17		OS: Firmware,
>28	byte	18		OS: RTEMS,
>28	byte	19		OS: ARTOS,
>28	byte	20		OS: Unity OS,
#>29	byte	x		CPU arch: %d,
>29	byte	0		CPU: invalid OS,
>29	byte	1		CPU: Alpha,
>29	byte	2		CPU: ARM,
>29	byte	3		CPU: Intel x86,
>29	byte	4		CPU: IA64,
>29	byte	5		CPU: MIPS,
>29	byte	6		CPU: MIPS 64 bit,
>29	byte	7		CPU: PowerPC,
>29	byte	8		CPU: IBM S390,
>29	byte	9		CPU: SuperH,
>29	byte	10		CPU: Sparc,
>29	byte	11		CPU: Sparc 64 bit,
>29	byte	12		CPU: M68K,
>29	byte	13		CPU: Nios-32,
>29	byte	14		CPU: MicroBlaze,
>29	byte	15		CPU: Nios-II,
>29	byte	16		CPU: Blackfin,
>29	byte	17		CPU: AVR,
>29	byte	18		CPU: STMicroelectronics ST200,
#>30	byte	x		image type: %d,
>30	byte	0		image type: invalid Image,
>30	byte	1		image type: Standalone Program,
>30	byte	2		image type: OS Kernel Image,
>30	byte 	3		image type: RAMDisk Image,
>30	byte	4		image type: Multi-File Image,
>30	byte	5		image type: Firmware Image,
>30	byte	6		image type: Script file,
>30	byte	7		image type: Filesystem Image,
>30	byte	8		image type: Binary Flat Device Tree Blob
#>31	byte	x		compression type: %d,
>31	byte	0		compression type: none,
>31	byte	1		compression type: gzip,
>31	byte	2		compression type: bzip2,
>31	byte	3		compression type: lzma,
>32	string	x		image name: "%s"

#IMG0 header, found in VxWorks-based Mercury router firmware
0	string		IMG0		IMG0 (VxWorks) header,
>4	belong		x		size: %d

#Mediatek bootloader signature
#From xp-dev.com
0	string		BOOTLOADER!	Mediatek bootloader

#CSYS header formats
0	string		CSYS\x00	CSYS header, little endian, 
>8	lelong		x		size: %d

0	string		CSYS\x80	CSYS header, big endian,
>8	belong		x		size: %d

# wrgg firmware image
0	string		wrgg02		WRGG firmware header,
>6	string		x		name: "%s",
>48	string		x		root device: "%s"

# trx image file
0	string          HDR0            TRX firmware header, little endian, header size: 28 bytes, 
>4	lelong		x		image size: %d bytes,
>8	lelong		x		CRC32: 0x%X
>12	lelong		x		flags/version: 0x%X

0	string          0RDH            TRX firmware header, big endian, header size: 28 bytes,
>4	belong		x		image size: %d bytes,
>8	belong		x		CRC32: 0x%X
>12	belong		x		flags/version: 0x%X


# Ubicom firmware image
0	belong	0xFA320080		Ubicom firmware header,
>12	belong	x			checksum: 0x%X,
>24	belong	x			image size: %d

# The ROME bootloader is used by several RealTek-based products.
# Unfortunately, the magic bytes are specific to each product, so
# separate signatures must be created for each one.

# Netgear KWGR614 ROME image
0	string		G614		Realtek firmware header (ROME bootloader),
>4	beshort		0xd92f		image type: KFS,
>4	beshort		0xb162		image type: RDIR,
>4	beshort		0xea43		image type: BOOT,
>4	beshort		0x8dc9		image type: RUN,
>4	beshort		0x2a05		image type: CCFG,
>4	beshort		0x6ce8		image type: DCFG,
>4	beshort		0xc371		image type: LOG,
>6	byte		x		header version: %d,
#month
>10	byte		x		created: %d/
#day	
>12	byte 		x		\b%d/
#year
>8	beshort		x		\b%d,
>16	belong		x		image size: %d bytes,
>22	byte		x		body checksum: 0x%X,
>23	byte		x		header checksum: 0x%X

# Linksys WRT54GX ROME image
0	belong		0x59a0e842	Realtek firmware header (ROME bootloader)
>4      beshort         0xd92f          image type: KFS,
>4      beshort         0xb162          image type: RDIR,
>4      beshort         0xea43          image type: BOOT,
>4      beshort         0x8dc9          image type: RUN,
>4      beshort         0x2a05          image type: CCFG,
>4      beshort         0x6ce8          image type: DCFG,
>4      beshort         0xc371          image type: LOG,
>6      byte            x               header version: %d,
#month
>10     byte            x               created: %d/
#day    
>12     byte            x               \b%d/
#year
>8      beshort         x               \b%d,
>16     belong          x               image size: %d bytes,
>22     byte            x               body checksum: 0x%X,
>23     byte            x               header checksum: 0x%X

# PackImg tag, somtimes used as a delimiter between the kernel and rootfs in firmware images.
0	string		--PaCkImGs--	PackImg section delimiter tag,
>16	lelong		x		little endian size: %d bytes;
>16	belong		x		big endian size: %d bytes


#------------------------------------------------------------------------------
# Broadcom header format
#
0       string          BCRM            Broadcom header,
>4      lelong          x               number of sections: %d,
>>8     lelong          18              first section type: flash
>>8     lelong          19              first section type: disk
>>8     lelong          21              first section type: tag


# Berkeley Lab Checkpoint Restart (BLCR) checkpoint context files
# http://ftg.lbl.gov/checkpoint
0       string  Ck0\0\0R\0\0\0  BLCR
>16     lelong  1       x86
>16     lelong  3       alpha
>16     lelong  5       x86-64
>16     lelong  7       ARM
>8      lelong  x       context data (little endian, version %d)

0       string  \0\0\0C\0\0\0R  BLCR
>16     belong  2       SPARC
>16     belong  4       ppc
>16     belong  6       ppc64
>16     belong  7       ARMEB
>16     belong  8       SPARC64
>8      belong  x       context data (big endian, version %d)

# Aculab VoIP firmware
# From: Mark Brown <broonie@sirena.org.uk>
0       string  VoIP\x20Startup\x20and      Aculab VoIP firmware
>35     string  x       format "%s"

#------------------------------------------------------------------------------
# HP LaserJet 1000 series downloadable firmware file
0       string  \xbe\xefABCDEFGH        HP LaserJet 1000 series downloadable firmware

# From Albert Cahalan <acahalan@gmail.com>
# really le32 operation,destination,payloadsize (but quite predictable)
# 01 00 00 00 00 00 00 c0 00 02 00 00
0       string          \1\0\0\0\0\0\0\300\0\2\0\0      Marvell Libertas firmware

#---------------------------------------------------------------------------
# The following entries have been tested by Duncan Laurie <duncan@sun.com> (a
# lead Sun/Cobalt developer) who agrees that they are good and worthy of
# inclusion.

# Boot ROM images for Sun/Cobalt Linux server appliances
0       string  Cobalt\x20Networks\x20Inc.\nFirmware\x20v     Paged COBALT boot rom
>38     string x        V%.4s

# New format for Sun/Cobalt boot ROMs is annoying, it stores the version code
# at the very end where file(1) can't get it.
0       string CRfs     COBALT boot rom data (Flat boot rom or file system)

#
# Motorola S-Records, from Gerd Truschinski <gt@freebsd.first.gmd.de>
0   string      S0          Motorola S-Record; binary data in text format

# --------------------------------
# Microsoft Xbox data file formats
0       string          XIP0            XIP, Microsoft Xbox data
0       string          XTF0            XTF, Microsoft Xbox data

#Windows CE
0	string		CECE		Windows CE RTOS{offset-adjust:-64}

# --------------------------------
# ZynOS ROM header format
# From openwrt zynos.h.
0	string		SIG		ZynOS header, header size: 48 bytes,{offset-adjust:-6}
#>0	belong		x		load address 0x%X,
>3	byte		<0x7F		rom image type:
>>3	byte		<1		invalid,
>>3	byte		>7		invalid,
>>3	byte		1		ROMIMG,
>>3	byte		2		ROMBOOT,
>>3	byte		3		BOOTEXT,
>>3	byte		4		ROMBIN,
>>3	byte		5		ROMDIR,
>>3	byte		6		6,
>>3	byte		7		ROMMAP,
>3	byte		>0x7F		ram image type:
>>3	byte		>0x82		invalid,
>>3	byte		0x80		RAM,
>>3	byte		0x81		RAMCODE,
>>3	byte		0x82		RAMBOOT,
>4	belong		>0x40000000	invalid
>4	belong		<0		invalid
>4	belong		0		invalid
>4	belong		x		uncompressed size: %d,
>8	belong		>0x40000000	invalid
>8	belong		<0		invalid
>8	belong		0  		invalid
>8	belong		x		compressed size: %d,
>14	beshort		x		uncompressed checksum: 0x%X,
>16	beshort		x		compressed checksum: 0x%X,
>12	byte		x		flags: 0x%X,
>12	byte		&0x40		uncompressed checksum is valid,
>12	byte		&0x80		the binary is compressed,
>>12	byte		&0x20		compressed checksum is valid,
>35	belong		x		memory map table address: 0x%X

# Firmware header used by some VxWorks-based Cisco products
0	string		CI032.00	Cisco VxWorks firmware header,
>8	lelong		>1024		invalid
>8	lelong		<0		invalid
>8	lelong		x		header size: %d bytes,
>32	lelong		>1024		invalid
>32	lelong		<0		invalid
>32	lelong		x		number of files: %d,
>48	lelong		<0		invalid
>48	lelong		x		image size: %d,
>64	string		x		firmware version: "%s"

# Firmware header used by some TV's
0	string		FNIB		ZBOOT firmware header, header size: 32 bytes,
>8	lelong		x		load address: 0x%.8X,
>12	lelong		x		start address: 0x%.8X,
>16	lelong		x		checksum: 0x%.8X,
>20	lelong		x		version: 0x%.8X,
>24	lelong		<1		invalid
>24	lelong		x		image size: %d bytes

# Firmware header used by several D-Link routers (and probably others)
0               string  \x5e\xa3\xa4\x17	DLOB firmware header,
>(7.b+12)       string  !\x5e\xa3\xa4\x17       invalid,
#>>12           string  x                       %s,
>(7.b+40)       string  x                       boot partition: "%s"

# TP-Link firmware header structure; thanks to Jonathan McGowan for reversing and documenting this format
0	string          TP-LINK\x20Technologies		TP-Link firmware header,{offset-adjust:-4}
#>-4	lelong          x               		header version: %d,
>0x94  	beshort         x               		firmware version: %d.
>0x96  	beshort         x               		\b%d.
>0x98  	beshort         x               		\b%d,
>0x18  	string          x               		image version: "%s",
#>0x74  belong          x               		image size: %d bytes,
>0x3C  	belong          x               		product ID: 0x%X,
>0x40  	belong          x               		product version: %d,
>0x70  	belong          x               		kernel load address: 0x%X,
>0x74  	belong          x               		kernel entry point: 0x%X,
>0x7C  	belong          x               		kernel offset: %d,
>0x80  	belong          x               		kernel length: %d,
>0x84  	belong          x               		rootfs offset: %d,
>0x88  	belong          x               		rootfs length: %d,
>0x8C  	belong          x               		bootloader offset: %d,
>0x90  	belong          x               		bootloader length: %d

# Tag Image File Format, from Daniel Quinlan (quinlan@yggdrasil.com)
# The second word of TIFF files is the TIFF version number, 42, which has
# never changed.  The TIFF specification recommends testing for it.
0       string          MM\x00\x2a      TIFF image data, big-endian
0       string          II\x2a\x00      TIFF image data, little-endian

# PNG [Portable Network Graphics, or "PNG's Not GIF"] images
# (Greg Roelofs, newt@uchicago.edu)
# (Albert Cahalan, acahalan@cs.uml.edu)
#
# 137 P N G \r \n ^Z \n [4-byte length] H E A D [HEAD data] [HEAD crc] ...
#
0       string          \x89PNG\x0d\x0a\x1a\x0a         PNG image
>16     belong          x               \b, %ld x
>20     belong          x               %ld,
>24     byte            x               %d-bit
>25     byte            0               grayscale,
>25     byte            2               \b/color RGB,
>25     byte            3               colormap,
>25     byte            4               gray+alpha,
>25     byte            6               \b/color RGBA,
#>26    byte            0               deflate/32K,
>28     byte            0               non-interlaced
>28     byte            1               interlaced

# GIF
0       string          GIF8            GIF image data
>4      string          7a              \b, version 8"%s",
>4      string          9a              \b, version 8"%s",
>6      leshort         >0              %hd x
>8      leshort         >0              %hd
#>10    byte            &0x80           color mapped,
#>10    byte&0x07       =0x00           2 colors
#>10    byte&0x07       =0x01           4 colors
#>10    byte&0x07       =0x02           8 colors
#>10    byte&0x07       =0x03           16 colors
#>10    byte&0x07       =0x04           32 colors
#>10    byte&0x07       =0x05           64 colors
#>10    byte&0x07       =0x06           128 colors
#>10    byte&0x07       =0x07           256 colors

# PC bitmaps (OS/2, Windows BMP files)  (Greg Roelofs, newt@uchicago.edu)
0       string          BM
>14     leshort         12              PC bitmap, OS/2 1.x format
>>18    leshort         x               \b, %d x
>>20    leshort         x               %d
>14     leshort         64              PC bitmap, OS/2 2.x format
>>18    leshort         x               \b, %d x
>>20    leshort         x               %d
>14     leshort         40              PC bitmap, Windows 3.x format
>>18    lelong          x               \b, %d x
>>22    lelong          x               %d x
>>28    leshort         x               %d
>14     leshort         128             PC bitmap, Windows NT/2000 format
>>18    lelong          x               \b, %d x
>>22    lelong          x               %d x
>>28    leshort         x               %d

#------------------------------------------------------------------------------
# JPEG images
# SunOS 5.5.1 had
#
#       0       string          \377\330\377\340        JPEG file
#       0       string          \377\330\377\356        JPG file
#
# both of which turn into "JPEG image data" here.
#
0       beshort         0xffd8          JPEG image data
>6      string          JFIF            \b, JFIF standard
# The following added by Erik Rossen <rossen@freesurf.ch> 1999-09-06
# in a vain attempt to add image size reporting for JFIF.  Note that these
# tests are not fool-proof since some perfectly valid JPEGs are currently
# impossible to specify in magic(4) format.
# First, a little JFIF version info:
>>11    byte            x               \b %d.
>>12    byte            x               \b%02d
# Next, the resolution or aspect ratio of the image:
#>>13   byte            0               \b, aspect ratio
#>>13   byte            1               \b, resolution (DPI)
#>>13   byte            2               \b, resolution (DPCM)
#>>4    beshort         x               \b, segment length %d
# Next, show thumbnail info, if it exists:
>>18    byte            !0              \b, thumbnail %dx
>>>19   byte            x               \b%d

# EXIF moved down here to avoid reporting a bogus version number,
# and EXIF version number printing added.
#   - Patrik R=E5dman <patrik+file-magic@iki.fi>
>6      string          Exif            \b, EXIF standard
# Look for EXIF IFD offset in IFD 0, and then look for EXIF version tag in EXIF IFD.
# All possible combinations of entries have to be enumerated, since no looping
# is possible. And both endians are possible...
# The combinations included below are from real-world JPEGs.
# Little-endian
>>12    string          II
# IFD 0 Entry #5:
>>>70   leshort         0x8769
# EXIF IFD Entry #1:
>>>>(78.l+14)   leshort 0x9000
>>>>>(78.l+23)  byte    x               %c
>>>>>(78.l+24)  byte    x               \b.%c
>>>>>(78.l+25)  byte    !0x30           \b%c
# IFD 0 Entry #9:
>>>118  leshort         0x8769
# EXIF IFD Entry #3:
>>>>(126.l+38)  leshort 0x9000
>>>>>(126.l+47) byte    x               %c
>>>>>(126.l+48) byte    x               \b.%c
>>>>>(126.l+49) byte    !0x30           \b%c
# IFD 0 Entry #10
>>>130  leshort         0x8769
# EXIF IFD Entry #3:
>>>>(138.l+38)  leshort 0x9000
>>>>>(138.l+47) byte    x               %c
>>>>>(138.l+48) byte    x               \b.%c
>>>>>(138.l+49) byte    !0x30           \b%c
# EXIF IFD Entry #4:
>>>>(138.l+50)  leshort 0x9000
>>>>>(138.l+59) byte    x               %c
>>>>>(138.l+60) byte    x               \b.%c
>>>>>(138.l+61) byte    !0x30           \b%c
# EXIF IFD Entry #5:
>>>>(138.l+62)  leshort 0x9000
>>>>>(138.l+71) byte    x               %c
>>>>>(138.l+72) byte    x               \b.%c
>>>>>(138.l+73) byte    !0x30           \b%c
# IFD 0 Entry #11
>>>142  leshort         0x8769
# EXIF IFD Entry #3:
>>>>(150.l+38)  leshort 0x9000
>>>>>(150.l+47) byte    x               %c
>>>>>(150.l+48) byte    x               \b.%c
>>>>>(150.l+49) byte    !0x30           \b%c
# EXIF IFD Entry #4:
>>>>(150.l+50)  leshort 0x9000
>>>>>(150.l+59) byte    x               %c
>>>>>(150.l+60) byte    x               \b.%c
>>>>>(150.l+61) byte    !0x30           \b%c
# EXIF IFD Entry #5:
>>>>(150.l+62)  leshort 0x9000
>>>>>(150.l+71) byte    x               %c
>>>>>(150.l+72) byte    x               \b.%c
>>>>>(150.l+73) byte    !0x30           \b%c
# Big-endian
>>12    string          MM
# IFD 0 Entry #9:
>>>118  beshort         0x8769
# EXIF IFD Entry #1:
>>>>(126.L+14)  beshort 0x9000
>>>>>(126.L+23) byte    x               %c
>>>>>(126.L+24) byte    x               \b.%c
>>>>>(126.L+25) byte    !0x30           \b%c
# EXIF IFD Entry #3:
>>>>(126.L+38)  beshort 0x9000
>>>>>(126.L+47) byte    x               %c
>>>>>(126.L+48) byte    x               \b.%c
>>>>>(126.L+49) byte    !0x30           \b%c
# IFD 0 Entry #10
>>>130  beshort         0x8769
# EXIF IFD Entry #3:
>>>>(138.L+38)  beshort 0x9000
>>>>>(138.L+47) byte    x               %c
>>>>>(138.L+48) byte    x               \b.%c
>>>>>(138.L+49) byte    !0x30           \b%c
# EXIF IFD Entry #5:
>>>>(138.L+62)  beshort 0x9000
>>>>>(138.L+71) byte    x               %c
>>>>>(138.L+72) byte    x               \b.%c
>>>>>(138.L+73) byte    !0x30           \b%c
# IFD 0 Entry #11
>>>142  beshort         0x8769
# EXIF IFD Entry #4:
>>>>(150.L+50)  beshort 0x9000
>>>>>(150.L+59) byte    x               %c
>>>>>(150.L+60) byte    x               \b.%c
>>>>>(150.L+61) byte    !0x30           \b%c
# Here things get sticky.  We can do ONE MORE marker segment with
# indirect addressing, and that's all.  It would be great if we could
# do pointer arithemetic like in an assembler language.  Christos?
# And if there was some sort of looping construct to do searches, plus a few
# named accumulators, it would be even more effective...
# At least we can show a comment if no other segments got inserted before:
>(4.S+5)        byte            0xFE
>>(4.S+8)       string          >\0             \b, comment: "%s"
# FIXME: When we can do non-byte counted strings, we can use that to get
# the string's count, and fix Debian bug #283760
#>(4.S+5)       byte            0xFE            \b, comment
#>>(4.S+6)      beshort         x               \b length=%d
#>>(4.S+8)      string          >\0             \b, "%s"
# Or, we can show the encoding type (I've included only the three most common)
# and image dimensions if we are lucky and the SOFn (image segment) is here:
>(4.S+5)        byte            0xC0            \b, baseline
>>(4.S+6)       byte            x               \b, precision %d
>>(4.S+7)       beshort         x               \b, %dx
>>(4.S+9)       beshort         x               \b%d
>(4.S+5)        byte            0xC1            \b, extended sequential
>>(4.S+6)       byte            x               \b, precision %d
>>(4.S+7)       beshort         x               \b, %dx
>>(4.S+9)       beshort         x               \b%d
>(4.S+5)        byte            0xC2            \b, progressive
>>(4.S+6)       byte            x               \b, precision %d
>>(4.S+7)       beshort         x               \b, %dx
>>(4.S+9)       beshort         x               \b%d
# I've commented-out quantisation table reporting.  I doubt anyone cares yet.
#>(4.S+5)       byte            0xDB            \b, quantisation table
#>>(4.S+6)      beshort         x               \b length=%d
#>14    beshort         x               \b, %d x
#>16    beshort         x               \b %d


#-------------------------Kernels-------------------------------------

# Linux kernel boot images, from Albert Cahalan <acahalan@cs.uml.edu>
# and others such as Axel Kohlmeyer <akohlmey@rincewind.chemie.uni-ulm.de>
# and Nicolás Lichtmaier <nick@debian.org>
# All known start with: b8 c0 07 8e d8 b8 00 90 8e c0 b9 00 01 29 f6 29
0	string		\xb8\xc0\x07\x8e\xd8\xb8\x00\x90\x8e\xc0\xb9\x00\x01\x29\xf6\x29	Linux kernel boot image
>514	string          !HdrS            							(invalid)

# Finds and prints Linux kernel strings in raw Linux kernels (output like uname -a).
# Commonly found in decompressed embedded kernel binaries.
0	string		Linux\ version\ 	Linux kernel version
>14	byte		0			invalid
>14	byte		!0
>>14	string		x			"%s
>>45	string		x			\b%s
>>76	string		x			\b%s
>>107	string		x			\b%s"

# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x5D
# ------------------------------------------------------------------
0		string	\x5D\x00\x00	LZMA compressed data, properties: 0x5D,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x01
# ------------------------------------------------------------------
0		string	\x01\x00\x00	LZMA compressed data, properties: 0x01,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x02
# ------------------------------------------------------------------
0		string	\x02\x00\x00	LZMA compressed data, properties: 0x02,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x03
# ------------------------------------------------------------------
0		string	\x03\x00\x00	LZMA compressed data, properties: 0x03,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x04
# ------------------------------------------------------------------
0		string	\x04\x00\x00	LZMA compressed data, properties: 0x04,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x09
# ------------------------------------------------------------------
0		string	\x09\x00\x00	LZMA compressed data, properties: 0x09,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x0A
# ------------------------------------------------------------------
0		string	\x0A\x00\x00	LZMA compressed data, properties: 0x0A,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x0B
# ------------------------------------------------------------------
0		string	\x0B\x00\x00	LZMA compressed data, properties: 0x0B,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x0C
# ------------------------------------------------------------------
0		string	\x0C\x00\x00	LZMA compressed data, properties: 0x0C,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x12
# ------------------------------------------------------------------
0		string	\x12\x00\x00	LZMA compressed data, properties: 0x12,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x13
# ------------------------------------------------------------------
0		string	\x13\x00\x00	LZMA compressed data, properties: 0x13,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x14
# ------------------------------------------------------------------
0		string	\x14\x00\x00	LZMA compressed data, properties: 0x14,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x1B
# ------------------------------------------------------------------
0		string	\x1B\x00\x00	LZMA compressed data, properties: 0x1B,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x1C
# ------------------------------------------------------------------
0		string	\x1C\x00\x00	LZMA compressed data, properties: 0x1C,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x24
# ------------------------------------------------------------------
0		string	\x24\x00\x00	LZMA compressed data, properties: 0x24,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x2D
# ------------------------------------------------------------------
0		string	\x2D\x00\x00	LZMA compressed data, properties: 0x2D,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x2E
# ------------------------------------------------------------------
0		string	\x2E\x00\x00	LZMA compressed data, properties: 0x2E,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x2F
# ------------------------------------------------------------------
0		string	\x2F\x00\x00	LZMA compressed data, properties: 0x2F,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x30
# ------------------------------------------------------------------
0		string	\x30\x00\x00	LZMA compressed data, properties: 0x30,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x31
# ------------------------------------------------------------------
0		string	\x31\x00\x00	LZMA compressed data, properties: 0x31,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x36
# ------------------------------------------------------------------
0		string	\x36\x00\x00	LZMA compressed data, properties: 0x36,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x37
# ------------------------------------------------------------------
0		string	\x37\x00\x00	LZMA compressed data, properties: 0x37,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x38
# ------------------------------------------------------------------
0		string	\x38\x00\x00	LZMA compressed data, properties: 0x38,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x39
# ------------------------------------------------------------------
0		string	\x39\x00\x00	LZMA compressed data, properties: 0x39,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x3F
# ------------------------------------------------------------------
0		string	\x3F\x00\x00	LZMA compressed data, properties: 0x3F,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x40
# ------------------------------------------------------------------
0		string	\x40\x00\x00	LZMA compressed data, properties: 0x40,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x41
# ------------------------------------------------------------------
0		string	\x41\x00\x00	LZMA compressed data, properties: 0x41,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x48
# ------------------------------------------------------------------
0		string	\x48\x00\x00	LZMA compressed data, properties: 0x48,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x49
# ------------------------------------------------------------------
0		string	\x49\x00\x00	LZMA compressed data, properties: 0x49,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x51
# ------------------------------------------------------------------
0		string	\x51\x00\x00	LZMA compressed data, properties: 0x51,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x5A
# ------------------------------------------------------------------
0		string	\x5A\x00\x00	LZMA compressed data, properties: 0x5A,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x5B
# ------------------------------------------------------------------
0		string	\x5B\x00\x00	LZMA compressed data, properties: 0x5B,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x5C
# ------------------------------------------------------------------
0		string	\x5C\x00\x00	LZMA compressed data, properties: 0x5C,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x5E
# ------------------------------------------------------------------
0		string	\x5E\x00\x00	LZMA compressed data, properties: 0x5E,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x63
# ------------------------------------------------------------------
0		string	\x63\x00\x00	LZMA compressed data, properties: 0x63,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x64
# ------------------------------------------------------------------
0		string	\x64\x00\x00	LZMA compressed data, properties: 0x64,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x65
# ------------------------------------------------------------------
0		string	\x65\x00\x00	LZMA compressed data, properties: 0x65,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x66
# ------------------------------------------------------------------
0		string	\x66\x00\x00	LZMA compressed data, properties: 0x66,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x6C
# ------------------------------------------------------------------
0		string	\x6C\x00\x00	LZMA compressed data, properties: 0x6C,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x6D
# ------------------------------------------------------------------
0		string	\x6D\x00\x00	LZMA compressed data, properties: 0x6D,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x6E
# ------------------------------------------------------------------
0		string	\x6E\x00\x00	LZMA compressed data, properties: 0x6E,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x75
# ------------------------------------------------------------------
0		string	\x75\x00\x00	LZMA compressed data, properties: 0x75,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x76
# ------------------------------------------------------------------
0		string	\x76\x00\x00	LZMA compressed data, properties: 0x76,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x7E
# ------------------------------------------------------------------
0		string	\x7E\x00\x00	LZMA compressed data, properties: 0x7E,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x87
# ------------------------------------------------------------------
0		string	\x87\x00\x00	LZMA compressed data, properties: 0x87,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x88
# ------------------------------------------------------------------
0		string	\x88\x00\x00	LZMA compressed data, properties: 0x88,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x89
# ------------------------------------------------------------------
0		string	\x89\x00\x00	LZMA compressed data, properties: 0x89,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x8A
# ------------------------------------------------------------------
0		string	\x8A\x00\x00	LZMA compressed data, properties: 0x8A,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x8B
# ------------------------------------------------------------------
0		string	\x8B\x00\x00	LZMA compressed data, properties: 0x8B,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x90
# ------------------------------------------------------------------
0		string	\x90\x00\x00	LZMA compressed data, properties: 0x90,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x91
# ------------------------------------------------------------------
0		string	\x91\x00\x00	LZMA compressed data, properties: 0x91,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x92
# ------------------------------------------------------------------
0		string	\x92\x00\x00	LZMA compressed data, properties: 0x92,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x93
# ------------------------------------------------------------------
0		string	\x93\x00\x00	LZMA compressed data, properties: 0x93,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x99
# ------------------------------------------------------------------
0		string	\x99\x00\x00	LZMA compressed data, properties: 0x99,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x9A
# ------------------------------------------------------------------
0		string	\x9A\x00\x00	LZMA compressed data, properties: 0x9A,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0x9B
# ------------------------------------------------------------------
0		string	\x9B\x00\x00	LZMA compressed data, properties: 0x9B,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xA2
# ------------------------------------------------------------------
0		string	\xA2\x00\x00	LZMA compressed data, properties: 0xA2,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xA3
# ------------------------------------------------------------------
0		string	\xA3\x00\x00	LZMA compressed data, properties: 0xA3,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xAB
# ------------------------------------------------------------------
0		string	\xAB\x00\x00	LZMA compressed data, properties: 0xAB,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xB4
# ------------------------------------------------------------------
0		string	\xB4\x00\x00	LZMA compressed data, properties: 0xB4,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xB5
# ------------------------------------------------------------------
0		string	\xB5\x00\x00	LZMA compressed data, properties: 0xB5,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xB6
# ------------------------------------------------------------------
0		string	\xB6\x00\x00	LZMA compressed data, properties: 0xB6,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xB7
# ------------------------------------------------------------------
0		string	\xB7\x00\x00	LZMA compressed data, properties: 0xB7,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xB8
# ------------------------------------------------------------------
0		string	\xB8\x00\x00	LZMA compressed data, properties: 0xB8,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xBD
# ------------------------------------------------------------------
0		string	\xBD\x00\x00	LZMA compressed data, properties: 0xBD,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xBE
# ------------------------------------------------------------------
0		string	\xBE\x00\x00	LZMA compressed data, properties: 0xBE,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xBF
# ------------------------------------------------------------------
0		string	\xBF\x00\x00	LZMA compressed data, properties: 0xBF,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xC0
# ------------------------------------------------------------------
0		string	\xC0\x00\x00	LZMA compressed data, properties: 0xC0,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xC6
# ------------------------------------------------------------------
0		string	\xC6\x00\x00	LZMA compressed data, properties: 0xC6,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xC7
# ------------------------------------------------------------------
0		string	\xC7\x00\x00	LZMA compressed data, properties: 0xC7,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xC8
# ------------------------------------------------------------------
0		string	\xC8\x00\x00	LZMA compressed data, properties: 0xC8,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xCF
# ------------------------------------------------------------------
0		string	\xCF\x00\x00	LZMA compressed data, properties: 0xCF,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xD0
# ------------------------------------------------------------------
0		string	\xD0\x00\x00	LZMA compressed data, properties: 0xD0,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes


# ------------------------------------------------------------------
# Signature for LZMA compressed data with valid properties byte 0xD8
# ------------------------------------------------------------------
0		string	\xD8\x00\x00	LZMA compressed data, properties: 0xD8,

# These are all the valid dictionary sizes supported by LZMA utils.
>1		lelong	!65536	
>>1		lelong	!131072	
>>>1		lelong	!262144	
>>>>1		lelong	!524288	
>>>>>1		lelong	!1048576	
>>>>>>1		lelong	!2097152	
>>>>>>>1	lelong	!4194304	
>>>>>>>>1	lelong	!8388608	
>>>>>>>>>1	lelong	!16777216	
>>>>>>>>>>1	lelong	!33554432	invalid
>1		lelong	x		dictionary size: %d bytes,

# Assume that a valid size will be less than 1GB. This could technically be valid, but is unlikely.
>5		lequad	<1		invalid
>5		lequad	>0x40000000	invalid

# These are not 100%. The uncompressed size could be exactly the same as the dicionary size, but it is unlikely.
# Since most false positives are the result of repeating sequences of bytes (such as executable instructions),
# marking matches with the same uncompressed and dictionary sizes as invalid eliminates much of these false positives.
>1		lelong	65536
>>5		lequad	65536		invalid
>1		lelong	131072
>>5		lequad	131072		invalid
>1		lelong	262144
>>5		lequad	262144		invalid
>1		lelong	524288
>>5		lequad	524288		invalid
>1		lelong	1048576
>>5		lequad	1048576		invalid
>1		lelong	2097152
>>5		lequad	2097152		invalid
>1		lelong	4194304
>>5		lequad	4194304		invalid
>1		lelong	8388608
>>5		lequad	8388608		invalid
>1		lelong	16777216
>>5		lequad	16777216	invalid
>1		lelong	33554432
>>5		lequad	33554432	invalid
>5		lequad	x		uncompressed size: %lld bytes

#------------------------------------------------------------------------------
# $File: sql,v 1.6 2009/09/19 16:28:12 christos Exp $
# sql:  file(1) magic for SQL files
#
# From: "Marty Leisner" <mleisner@eng.mc.xerox.com>
# Recognize some MySQL files.
#
0       beshort                 0xfe01          MySQL table definition file
>2	string			<1		invalid
>2	string			>\11		invalid
>2      byte                    x               Version %d
0       string		        \xfe\xfe\x03    MySQL MISAM index file
>3	string			<1		invalid
>3	string			>\11		invalid
>3      byte                    x               Version %d
0       string                  \xfe\xfe\x07    MySQL MISAM compressed data file
>3	string			<1		invalid
>3	string			>\11		invalid
>3      byte                    x               Version %d
0       string                  \xfe\xfe\x05    MySQL ISAM index file
>3	string			<1		invalid
>3	string			>\11		invalid
>3      byte                    x               Version %d
0       string                  \xfe\xfe\x06    MySQL ISAM compressed data file
>3	string			<1		invalid
>3	string			>\11		invalid
>3      byte                    x               Version %d
0       string                  \376bin         MySQL replication log

#------------------------------------------------------------------------------
# iRiver H Series database file 
# From Ken Guest <ken@linux.ie>
# As observed from iRivNavi.iDB and unencoded firmware
#
0   string              iRivDB  iRiver Database file
>11  string     >\0     Version "%s"
>39  string             iHP-100 [H Series]

#------------------------------------------------------------------------------
# SQLite database files
# Ken Guest <ken@linux.ie>, Ty Sarna, Zack Weinberg
#
# Version 1 used GDBM internally; its files cannot be distinguished
# from other GDBM files.
#
# Version 2 used this format:
0       string  **\x20This\x20file\x20contains\x20an\x20SQLite  SQLite 2.x database

# Version 3 of SQLite allows applications to embed their own "user version"
# number in the database.  Detect this and distinguish those files.

0   string  SQLite\x20format\x203
>60 string  _MTN               Monotone source repository
>60 belong  !0                 SQLite 3.x database, user version %u
>60 belong  0                  SQLite 3.x database
