{
    "content": [
        {
            "type": "text",
            "text": "# magic (man)\n\n## NAME\n\nmagic — file command's magic pattern file\n\n## DESCRIPTION\n\nThis  manual page documents the format of magic files as used by the file(1) command, version\n5.45.  The file(1) command identifies the type of a file using, among other tests, a test for\nwhether the file contains certain “magic patterns”.  The database of these  “magic  patterns”\nis  usually  located  in  a binary file in /usr/share/misc/magic.mgc or a directory of source\ntext magic pattern fragment files in /usr/share/misc/magic.  The database specifies what pat‐\nterns are to be tested for, what message or MIME type to print if  a  particular  pattern  is\nfound, and additional information to extract from the file.\n\n## Sections\n\n- **NAME**\n- **DESCRIPTION**\n- **SEE ALSO**\n- **BUGS**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "magic",
        "section": "",
        "mode": "man",
        "summary": "magic — file command's magic pattern file",
        "synopsis": null,
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [
            {
                "name": "file",
                "section": "1",
                "url": "https://www.chedong.com/phpMan.php/man/file/1/json"
            }
        ],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 440,
                "subsections": []
            },
            {
                "name": "SEE ALSO",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "BUGS",
                "lines": 11,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "magic — file command's magic pattern file\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "This  manual page documents the format of magic files as used by the file(1) command, version\n5.45.  The file(1) command identifies the type of a file using, among other tests, a test for\nwhether the file contains certain “magic patterns”.  The database of these  “magic  patterns”\nis  usually  located  in  a binary file in /usr/share/misc/magic.mgc or a directory of source\ntext magic pattern fragment files in /usr/share/misc/magic.  The database specifies what pat‐\nterns are to be tested for, what message or MIME type to print if  a  particular  pattern  is\nfound, and additional information to extract from the file.\n\nThe  format  of the source fragment files that are used to build this database is as follows:\nEach line of a fragment file specifies a test to be performed.   A  test  compares  the  data\nstarting  at  a particular offset in the file with a byte value, a string or a numeric value.\nIf the test succeeds, a message is printed.  The line consists of the following fields:\n\noffset   A number specifying the offset (in bytes) into the file of the data which is  to  be\ntested.  This offset can be a negative number if it is:\n•   The  first  direct offset of the magic entry (at continuation level 0), in which\ncase it is interpreted an offset from end end of the file going backwards.  This\nworks only when a file descriptor to the file is available and it is  a  regular\nfile.\n•   A continuation offset relative to the end of the last up-level field (&).\n\ntype     The type of the data to be tested.  The possible values are:\n\nbyte        A one-byte value.\n\nshort       A two-byte value in this machine's native byte order.\n\nlong        A four-byte value in this machine's native byte order.\n\nquad        An eight-byte value in this machine's native byte order.\n\nfloat       A  32-bit  single precision IEEE floating point number in this machine's\nnative byte order.\n\ndouble      A 64-bit double precision IEEE floating point number in  this  machine's\nnative byte order.\n\nstring      A string of bytes.  The string type specification can be optionally fol‐\nlowed  by  a  /<width>  option and optionally followed by a set of flags\n/[bCcftTtWw]*.  The width limits the number of characters to be  copied.\nZero means all characters.  The following flags are supported:\nb  Force binary file test.\nC  Use upper case insensitive matching: upper case characters in the\nmagic  match  both lower and upper case characters in the target,\nwhereas lower case characters in the magic only match upper  case\ncharacters in the target.\nc  Use lower case insensitive matching: lower case characters in the\nmagic  match  both lower and upper case characters in the target,\nwhereas upper case characters in the magic only match upper  case\ncharacters  in  the  target.   To  do a complete case insensitive\nmatch, specify both “c” and “C”.\nf  Require that the matched string is a full  word,  not  a  partial\nword match.\nT  Trim the string, i.e. leading and trailing whitespace\nt  Force text file test.\nW  Compact whitespace in the target, which must contain at least one\nwhitespace character.  If the magic has n consecutive blanks, the\ntarget needs at least n consecutive blanks to match.\nw  Treat  every blank in the magic as an optional blank.  is deleted\nbefore the string is printed.\n\npstring     A Pascal-style string where the first byte/short/int is  interpreted  as\nthe  unsigned  length.  The length defaults to byte and can be specified\nas a modifier.  The following modifiers are supported:\nB  A byte length (default).\nH  A 2 byte big endian length.\nh  A 2 byte little endian length.\nL  A 4 byte big endian length.\nl  A 4 byte little endian length.\nJ  The length includes itself in its count.\nThe string is not NUL terminated.  “J” is  used  rather  than  the  more\nvaluable  “I”  because this type of length is a feature of the JPEG for‐\nmat.\n\ndate        A four-byte value interpreted as a UNIX date.\n\nqdate       An eight-byte value interpreted as a UNIX date.\n\nldate       A four-byte value interpreted as a UNIX-style date, but  interpreted  as\nlocal time rather than UTC.\n\nqldate      An eight-byte value interpreted as a UNIX-style date, but interpreted as\nlocal time rather than UTC.\n\nqwdate      An eight-byte value interpreted as a Windows-style date.\n\nbeid3       A 32-bit ID3 length in big-endian byte order.\n\nbeshort     A two-byte value in big-endian byte order.\n\nbelong      A four-byte value in big-endian byte order.\n\nbequad      An eight-byte value in big-endian byte order.\n\nbefloat     A  32-bit single precision IEEE floating point number in big-endian byte\norder.\n\nbedouble    A 64-bit double precision IEEE floating point number in big-endian  byte\norder.\n\nbedate      A four-byte value in big-endian byte order, interpreted as a Unix date.\n\nbeqdate     An  eight-byte  value  in  big-endian  byte order, interpreted as a Unix\ndate.\n\nbeldate     A four-byte value in big-endian byte order, interpreted as a  UNIX-style\ndate, but interpreted as local time rather than UTC.\n\nbeqldate    An  eight-byte  value  in  big-endian byte order, interpreted as a UNIX-\nstyle date, but interpreted as local time rather than UTC.\n\nbeqwdate    An eight-byte value in big-endian byte order, interpreted as a  Windows-\nstyle date.\n\nbestring16  A two-byte unicode (UCS16) string in big-endian byte order.\n\nleid3       A 32-bit ID3 length in little-endian byte order.\n\nleshort     A two-byte value in little-endian byte order.\n\nlelong      A four-byte value in little-endian byte order.\n\nlequad      An eight-byte value in little-endian byte order.\n\nlefloat     A  32-bit  single  precision IEEE floating point number in little-endian\nbyte order.\n\nledouble    A 64-bit double precision IEEE floating point  number  in  little-endian\nbyte order.\n\nledate      A  four-byte  value  in  little-endian byte order, interpreted as a UNIX\ndate.\n\nleqdate     An eight-byte value in little-endian byte order, interpreted as  a  UNIX\ndate.\n\nleldate     A  four-byte  value  in little-endian byte order, interpreted as a UNIX-\nstyle date, but interpreted as local time rather than UTC.\n\nleqldate    An eight-byte value in little-endian byte order, interpreted as a  UNIX-\nstyle date, but interpreted as local time rather than UTC.\n\nleqwdate    An  eight-byte  value in little-endian byte order, interpreted as a Win‐\ndows-style date.\n\nlestring16  A two-byte unicode (UCS16) string in little-endian byte order.\n\nmelong      A four-byte value in middle-endian (PDP-11) byte order.\n\nmedate      A four-byte value in middle-endian (PDP-11) byte order, interpreted as a\nUNIX date.\n\nmeldate     A four-byte value in middle-endian (PDP-11) byte order, interpreted as a\nUNIX-style date, but interpreted as local time rather than UTC.\n\nindirect    Starting at the given offset, consult the  magic  database  again.   The\noffset of the indirect magic is by default absolute in the file, but one\ncan  specify  /r to indicate that the offset is relative from the begin‐\nning of the entry.\n\nname        Define a “named” magic instance that can  be  called  from  another  use\nmagic  entry,  like a subroutine call.  Named instance direct magic off‐\nsets are relative to the offset of the previous matched entry, but indi‐\nrect offsets are relative to the beginning of the file as usual.   Named\nmagic entries always match.\n\nuse         Recursively  call  the named magic starting from the current offset.  If\nthe name of the referenced begins with a ^ then the  endianness  of  the\nmagic  is  switched;  if  the magic mentioned leshort for example, it is\ntreated as beshort and vice versa.  This is useful to avoid  duplicating\nthe rules for different endianness.\n\nregex       A  regular  expression match in extended POSIX regular expression syntax\n(like egrep).  Regular expressions can take exponential time to process,\nand their performance is hard to predict, so their use  is  discouraged.\nWhen  used in production environments, their performance should be care‐\nfully checked.  The size of the string to search should also be  limited\nby  specifying  /<length>,  to  avoid  performance  issues scanning long\nfiles.  The type  specification  can  also  be  optionally  followed  by\n/[c][s][l].   The  “c”  flag makes the match case insensitive, while the\n“s” flag update the offset to the start offset of the match, rather than\nthe end.  The “l” modifier, changes the limit of length to  mean  number\nof  lines instead of a byte count.  Lines are delimited by the platforms\nnative line delimiter.  When a line count is specified, an implicit byte\ncount also computed assuming each line is 80 characters long.   If  nei‐\nther  a byte or line count is specified, the search is limited automati‐\ncally to 8KiB.  ^ and $ match the beginning and end of individual lines,\nrespectively, not beginning and end of file.\n\nsearch      A literal string search starting at the given offset.  The same modifier\nflags can be used as for string patterns.  The  search  expression  must\ncontain  the  range in the form /number, that is the number of positions\nat which the match will be attempted, starting from  the  start  offset.\nThis  is  suitable for searching larger binary expressions with variable\noffsets, using \\ escapes for special characters.  The order of  modifier\nand number is not relevant.\n\ndefault     This  is  intended to be used with the test x (which is always true) and\nit has no type.  It matches when no  other  test  at  that  continuation\nlevel  has  matched before.  Clearing that matched tests for a continua‐\ntion level, can be done using the clear test.\n\nclear       This test is always true and clears the match flag for that continuation\nlevel.  It is intended to be used with the default test.\n\nder         Parse the file as a DER Certificate file.  The test field is used  as  a\nder  type  that needs to be matched.  The DER types are: eoc, bool, int,\nbitstr, octetstr, null, objid,  objdesc,  ext,  real,  enum,  embed,\nutf8str,  reloid,  time,  res2,  seq,  set, numstr, prtstr, t61str,\nvidstr,  ia5str,  utctime,  gentime,   grstr,   visstr,   genstr,\nunivstr,  charstr,  bmpstr,  date,  tod, datetime, duration, oid-iri,\nrel-oid-iri.  These types can be followed by an optional  numeric  size,\nwhich indicates the field width in bytes.\n\nguid        A  Globally Unique Identifier, parsed and printed as XXXXXXXX-XXXX-XXXX-\nXXXX-XXXXXXXXXXXX.  It's format is a string.\n\noffset      This is a quad value indicating the current offset of the file.  It  can\nbe  used to determine the size of the file or the magic buffer.  For ex‐\nample the magic entries:\n\n-0      offset  x       this file is %lld bytes\n-0      offset  <=100   must be more than 100 \\\nbytes and is only %lld\n\noctal       A string representing an octal number.\n\nFor compatibility with the Single Unix Standard, the type specifiers dC and d1 are equivalent\nto byte, the type specifiers uC and u1 are equivalent to ubyte, the type specifiers dS and d2\nare equivalent to short, the type specifiers uS and u2 are equivalent  to  ushort,  the  type\nspecifiers  dI,  dL,  and  d4  are equivalent to long, the type specifiers uI, uL, and u4 are\nequivalent to ulong, the type specifier d8 is equivalent to quad, the type  specifier  u8  is\nequivalent to uquad, and the type specifier s is equivalent to string.  In addition, the type\nspecifier dQ is equivalent to quad and the type specifier uQ is equivalent to uquad.\n\nEach  top-level  magic pattern (see below for an explanation of levels) is classified as text\nor binary according to the types used.  Types “regex” and “search”  are  classified  as  text\ntests,  unless non-printable characters are used in the pattern.  All other tests are classi‐\nfied as binary.  A top-level pattern is considered to be a test text when  all  its  patterns\nare text patterns; otherwise, it is considered to be a binary pattern.  When matching a file,\nbinary patterns are tried first; if no match is found, and the file looks like text, then its\nencoding is determined and the text patterns are tried.\n\nThe  numeric  types  may optionally be followed by & and a numeric value, to specify that the\nvalue is to be AND'ed with the numeric value before any comparisons are done.  Prepending a u\nto the type indicates that ordered comparisons should be unsigned.\nThe value to be compared with the value from the file.  If the type is numeric, this value is\nspecified in C form; if it is a string, it is specified as a C string with the usual  escapes\npermitted (e.g. \\n for new-line).\n\nNumeric  values  may be preceded by a character indicating the operation to be performed.  It\nmay be =, to specify that the value from the file must equal the specified value, <, to spec‐\nify that the value from the file must be less than the specified value, >,  to  specify  that\nthe  value  from  the  file  must be greater than the specified value, &, to specify that the\nvalue from the file must have set all of the bits that are set in the specified value, ^,  to\nspecify  that  the  value  from  the file must have clear any of the bits that are set in the\nspecified value, or ~, the value specified after is negated before  tested.   x,  to  specify\nthat any value will match.  If the character is omitted, it is assumed to be =.  Operators &,\n^,  and ~ don't work with floats and doubles.  The operator ! specifies that the line matches\nif the test does not succeed.\n\nNumeric values are specified in C form; e.g.  13 is decimal, 013 is octal, and 0x13 is  hexa‐\ndecimal.\n\nNumeric  operations are not performed on date types, instead the numeric value is interpreted\nas an offset.\n\nFor string values, the string from the file must match the specified string.   The  operators\n=,  <  and  > (but not &) can be applied to strings.  The length used for matching is that of\nthe string argument in the magic file.  This means that a line can match any non-empty string\n(usually used to then print the string), with >\\0 (because all non-empty strings are  greater\nthan the empty string).\n\nDates are treated as numerical values in the respective internal representation.\n\nThe special test x always evaluates to true.\nThe  message  to  be  printed if the comparison succeeds.  If the string contains a printf(3)\nformat specification, the value from the file  (with  any  specified  masking  performed)  is\nprinted  using the message as the format string.  If the string begins with “\\b”, the message\nprinted is the remainder of the string with no whitespace added before it:  multiple  matches\nare normally separated by a single space.\n\nAn APPLE 4+4 character APPLE creator and type can be specified as:\n\n!:apple CREATYPE\n\nA slash-separated list of commonly found filename extensions can be specified as:\n\n!:ext   ext[/ext...]\n\ni.e.  the  literal  string  “!:ext” followed by a slash-separated list of commonly found exten‐\nsions; for example for JPEG images:\n\n!:ext jpeg/jpg/jpe/jfif\n\nA MIME type is given on a separate line, which must be the next non-blank or comment line after\nthe magic line that identifies the file type, and has the following format:\n\n!:mime  MIMETYPE\n\ni.e. the literal string “!:mime” followed by the MIME type.\n\nAn optional strength can be supplied on a separate line which refers to the current  magic  de‐\nscription using the following format:\n\n!:strength OP VALUE\n\nThe  operand OP can be: +, -, *, or / and VALUE is a constant between 0 and 255.  This constant\nis applied using the specified operand to the currently computed default magic strength.\n\nSome file formats contain additional information which is to be printed  along  with  the  file\ntype  or need additional tests to determine the true file type.  These additional tests are in‐\ntroduced by one or more > characters preceding the offset.  The number of > on the  line  indi‐\ncates  the level of the test; a line with no > at the beginning is considered to be at level 0.\nTests are arranged in a tree-like hierarchy: if the test on a line at  level  n  succeeds,  all\nfollowing  tests at level n+1 are performed, and the messages printed if the tests succeed, un‐\ntil a line with level n (or less) appears.  For more complex files, one can use empty  messages\nto get just the \"if/then\" effect, in the following way:\n\n0      string   MZ\n>0x18  leshort  <0x40   MS-DOS executable\n>0x18  leshort  >0x3f   extended PC executable (e.g., MS Windows)\n\nOffsets  do not need to be constant, but can also be read from the file being examined.  If the\nfirst character following the last > is a ( then the string after  the  parenthesis  is  inter‐\npreted  as  an indirect offset.  That means that the number after the parenthesis is used as an\noffset in the file.  The value at that offset is read, and is used again as an  offset  in  the\nfile.   Indirect  offsets  are  of  the form: (( x [[.,][bBcCeEfFgGhHiIlmsSqQ]][+-][ y ]).  The\nvalue of x is used as an offset in the file.  A byte, id3 length, short or long is read at that\noffset depending on the [bBcCeEfFgGhHiIlmsSqQ] type specifier.  The value is treated as  signed\nif “”, is specified or unsigned if “”.  is specified.  The capitalized types interpret the num‐\nber  as  a big endian value, whereas the small letter versions interpret the number as a little\nendian value; the m type interprets the number as a middle endian (PDP-11) value.  To that num‐\nber the value of y is added and the result is used as an offset in the file.  The default  type\nif one is not specified is long.  The following types are recognized:\n\nType    Sy Mnemonic   Sy Endian Sy Size\nbcBc    Byte/Char     N/A       1\nefg     Double        Little    8\nEFG     Double        Big       8\nhs      Half/Short    Little    2\nHS      Half/Short    Big       2\ni       ID3           Little    4\nI       ID3           Big       4\nm       Middle        Middle    4\no       Octal         Textual   Variable\nq       Quad          Little    8\nQ       Quad          Big       8\n\nThat way variable length structures can be examined:\n\n# MS Windows executables are also valid MS-DOS executables\n0           string  MZ\n>0x18       leshort <0x40   MZ executable (MS-DOS)\n# skip the whole block below if it is not an extended executable\n>0x18       leshort >0x3f\n>>(0x3c.l)  string  PE\\0\\0  PE executable (MS-Windows)\n>>(0x3c.l)  string  LX\\0\\0  LX executable (OS/2)\n\nThis  strategy  of examining has a drawback: you must make sure that you eventually print some‐\nthing, or users may get empty output (such as when there is neither PE\\0\\0 nor  LE\\0\\0  in  the\nabove example).\n\nIf  this  indirect  offset cannot be used directly, simple calculations are possible: appending\n[+-*/%&|^]number inside parentheses allows one to modify the value read from the file before it\nis used as an offset:\n\n# MS Windows executables are also valid MS-DOS executables\n0           string  MZ\n# sometimes, the value at 0x18 is less that 0x40 but there's still an\n# extended executable, simply appended to the file\n>0x18       leshort <0x40\n>>(4.s*512) leshort 0x014c  COFF executable (MS-DOS, DJGPP)\n>>(4.s*512) leshort !0x014c MZ executable (MS-DOS)\n\nSometimes you do not know the exact offset as this depends on the length or position (when  in‐\ndirection  was used before) of preceding fields.  You can specify an offset relative to the end\nof the last up-level field using ‘&’ as a prefix to the offset:\n\n0           string  MZ\n>0x18       leshort >0x3f\n>>(0x3c.l)  string  PE\\0\\0    PE executable (MS-Windows)\n# immediately following the PE signature is the CPU type\n>>>&0       leshort 0x14c     for Intel 80386\n>>>&0       leshort 0x184     for DEC Alpha\n\nIndirect and relative offsets can be combined:\n\n0             string  MZ\n>0x18         leshort <0x40\n>>(4.s*512)   leshort !0x014c MZ executable (MS-DOS)\n# if it's not COFF, go back 512 bytes and add the offset taken\n# from byte 2/3, which is yet another way of finding the start\n# of the extended executable\n>>>&(2.s-514) string  LE      LE executable (MS Windows VxD driver)\n\nOr the other way around:\n\n0                 string  MZ\n>0x18             leshort >0x3f\n>>(0x3c.l)        string  LE\\0\\0  LE executable (MS-Windows)\n# at offset 0x80 (-4, since relative offsets start at the end\n# of the up-level match) inside the LE header, we find the absolute\n# offset to the code area, where we look for a specific signature\n>>>(&0x7c.l+0x26) string  UPX     \\b, UPX compressed\n\nOr even both!\n\n0                string  MZ\n>0x18            leshort >0x3f\n>>(0x3c.l)       string  LE\\0\\0 LE executable (MS-Windows)\n# at offset 0x58 inside the LE header, we find the relative offset\n# to a data area where we look for a specific signature\n>>>&(&0x54.l-3)  string  UNACE  \\b, ACE self-extracting archive\n\nIf you have to deal with offset/length pairs in your file, even the second value in a parenthe‐\nsized expression can be taken from the file itself, using another  set  of  parentheses.   Note\nthat  this additional indirect offset is always relative to the start of the main indirect off‐\nset.\n\n0                 string       MZ\n>0x18             leshort      >0x3f\n>>(0x3c.l)        string       PE\\0\\0 PE executable (MS-Windows)\n# search for the PE section called \".idata\"...\n>>>&0xf4          search/0x140 .idata\n# ...and go to the end of it, calculated from start+length;\n# these are located 14 and 10 bytes after the section name\n>>>>(&0xe.l+(-4)) string       PK\\3\\4 \\b, ZIP self-extracting archive\n\nIf you have a list of known values at a particular continuation level, and you want to  provide\na switch-like default case:\n\n# clear that continuation level match\n>18     clear\n>18     lelong  1       one\n>18     lelong  2       two\n>18     default x\n# print default match\n>>18    lelong  x       unmatched 0x%x\n",
                "subsections": []
            },
            "SEE ALSO": {
                "content": "file(1) - the command that reads this file.\n",
                "subsections": []
            },
            "BUGS": {
                "content": "The  formats  long,  belong, lelong, melong, short, beshort, and leshort do not depend on the\nlength of the C data types short and long on the platform, even though the Single Unix Speci‐\nfication implies that they do.  However, as OS X Mountain Lion has  passed  the  Single  Unix\nSpecification validation suite, and supplies a version of file(1) in which they do not depend\non  the sizes of the C data types and that is built for a 64-bit environment in which long is\n8 bytes rather than 4 bytes, presumably the validation suite does not test whether, for exam‐\nple long refers to an item with the same size as the C data type long.  There should probably\nbe type names int8, uint8, int16, uint16, int32, uint32, int64, and  uint64,  and  specified-\nbyte-order variants of them, to make it clearer that those types have specified widths.\n\nDebian                                     Arpil 18, 2023                                   MAGIC(5)",
                "subsections": []
            }
        }
    }
}