1.\" $File: magic.man,v 1.85 2015/01/01 17:07:34 christos Exp $ 2.Dd January 1, 2015 3.Dt MAGIC __FSECTION__ 4.Os 5.\" install as magic.4 on USG, magic.5 on V7, Berkeley and Linux systems. 6.Sh NAME 7.Nm magic 8.Nd file command's magic pattern file 9.Sh DESCRIPTION 10This manual page documents the format of the magic file as 11used by the 12.Xr file __CSECTION__ 13command, version __VERSION__. 14The 15.Xr file __CSECTION__ 16command identifies the type of a file using, 17among other tests, 18a test for whether the file contains certain 19.Dq "magic patterns" . 20The file 21.Pa __MAGIC__ 22specifies what patterns are to be tested for, what message or 23MIME type to print if a particular pattern is found, 24and additional information to extract from the file. 25.Pp 26Each line of the file specifies a test to be performed. 27A test compares the data starting at a particular offset 28in the file with a byte value, a string or a numeric value. 29If the test succeeds, a message is printed. 30The line consists of the following fields: 31.Bl -tag -width ".Dv message" 32.It Dv offset 33A number specifying the offset, in bytes, into the file of the data 34which is to be tested. 35.It Dv type 36The type of the data to be tested. 37The possible values are: 38.Bl -tag -width ".Dv lestring16" 39.It Dv byte 40A one-byte value. 41.It Dv short 42A two-byte value in this machine's native byte order. 43.It Dv long 44A four-byte value in this machine's native byte order. 45.It Dv quad 46An eight-byte value in this machine's native byte order. 47.It Dv float 48A 32-bit single precision IEEE floating point number in this machine's native byte order. 49.It Dv double 50A 64-bit double precision IEEE floating point number in this machine's native byte order. 51.It Dv string 52A string of bytes. 53The string type specification can be optionally followed 54by /[WwcCtbT]*. 55The 56.Dq W 57flag compacts whitespace in the target, which must 58contain at least one whitespace character. 59If the magic has 60.Dv n 61consecutive blanks, the target needs at least 62.Dv n 63consecutive blanks to match. 64The 65.Dq w 66flag treats every blank in the magic as an optional blank. 67The 68.Dq c 69flag specifies case insensitive matching: lower case 70characters in the magic match both lower and upper case characters in the 71target, whereas upper case characters in the magic only match upper case 72characters in the target. 73The 74.Dq C 75flag specifies case insensitive matching: upper case 76characters in the magic match both lower and upper case characters in the 77target, whereas lower case characters in the magic only match upper case 78characters in the target. 79To do a complete case insensitive match, specify both 80.Dq c 81and 82.Dq C . 83The 84.Dq t 85flag forces the test to be done for text files, while the 86.Dq b 87flag forces the test to be done for binary files. 88The 89.Dq T 90flag causes the string to be trimmed, i.e. leading and trailing whitespace 91is deleted before the string is printed. 92.It Dv pstring 93A Pascal-style string where the first byte/short/int is interpreted as the 94unsigned length. 95The length defaults to byte and can be specified as a modifier. 96The following modifiers are supported: 97.Bl -tag -compact -width B 98.It B 99A byte length (default). 100.It H 101A 2 byte big endian length. 102.It h 103A 2 byte big little length. 104.It L 105A 4 byte big endian length. 106.It l 107A 4 byte big little length. 108.It J 109The length includes itself in its count. 110.El 111The string is not NUL terminated. 112.Dq J 113is used rather than the more 114valuable 115.Dq I 116because this type of length is a feature of the JPEG 117format. 118.It Dv date 119A four-byte value interpreted as a UNIX date. 120.It Dv qdate 121A eight-byte value interpreted as a UNIX date. 122.It Dv ldate 123A four-byte value interpreted as a UNIX-style date, but interpreted as 124local time rather than UTC. 125.It Dv qldate 126An eight-byte value interpreted as a UNIX-style date, but interpreted as 127local time rather than UTC. 128.It Dv qwdate 129An eight-byte value interpreted as a Windows-style date. 130.It Dv beid3 131A 32-bit ID3 length in big-endian byte order. 132.It Dv beshort 133A two-byte value in big-endian byte order. 134.It Dv belong 135A four-byte value in big-endian byte order. 136.It Dv bequad 137An eight-byte value in big-endian byte order. 138.It Dv befloat 139A 32-bit single precision IEEE floating point number in big-endian byte order. 140.It Dv bedouble 141A 64-bit double precision IEEE floating point number in big-endian byte order. 142.It Dv bedate 143A four-byte value in big-endian byte order, 144interpreted as a Unix date. 145.It Dv beqdate 146An eight-byte value in big-endian byte order, 147interpreted as a Unix date. 148.It Dv beldate 149A four-byte value in big-endian byte order, 150interpreted as a UNIX-style date, but interpreted as local time rather 151than UTC. 152.It Dv beqldate 153An eight-byte value in big-endian byte order, 154interpreted as a UNIX-style date, but interpreted as local time rather 155than UTC. 156.It Dv beqwdate 157An eight-byte value in big-endian byte order, 158interpreted as a Windows-style date. 159.It Dv bestring16 160A two-byte unicode (UCS16) string in big-endian byte order. 161.It Dv leid3 162A 32-bit ID3 length in little-endian byte order. 163.It Dv leshort 164A two-byte value in little-endian byte order. 165.It Dv lelong 166A four-byte value in little-endian byte order. 167.It Dv lequad 168An eight-byte value in little-endian byte order. 169.It Dv lefloat 170A 32-bit single precision IEEE floating point number in little-endian byte order. 171.It Dv ledouble 172A 64-bit double precision IEEE floating point number in little-endian byte order. 173.It Dv ledate 174A four-byte value in little-endian byte order, 175interpreted as a UNIX date. 176.It Dv leqdate 177An eight-byte value in little-endian byte order, 178interpreted as a UNIX date. 179.It Dv leldate 180A four-byte value in little-endian byte order, 181interpreted as a UNIX-style date, but interpreted as local time rather 182than UTC. 183.It Dv leqldate 184An eight-byte value in little-endian byte order, 185interpreted as a UNIX-style date, but interpreted as local time rather 186than UTC. 187.It Dv leqwdate 188An eight-byte value in little-endian byte order, 189interpreted as a Windows-style date. 190.It Dv lestring16 191A two-byte unicode (UCS16) string in little-endian byte order. 192.It Dv melong 193A four-byte value in middle-endian (PDP-11) byte order. 194.It Dv medate 195A four-byte value in middle-endian (PDP-11) byte order, 196interpreted as a UNIX date. 197.It Dv meldate 198A four-byte value in middle-endian (PDP-11) byte order, 199interpreted as a UNIX-style date, but interpreted as local time rather 200than UTC. 201.It Dv indirect 202Starting at the given offset, consult the magic database again. 203The offset of th 204.Dv indirect 205magic is by default absolute in the file, but one can specify 206.Dv /r 207to indicate that the offset is relative from the beginning of the entry. 208.It Dv name 209Define a 210.Dq named 211magic instance that can be called from another 212.Dv use 213magic entry, like a subroutine call. 214Named instance direct magic offsets are relative to the offset of the 215previous matched entry, but indirect offsets are relative to the beginning 216of the file as usual. 217Named magic entries always match. 218.It Dv use 219Recursively call the named magic starting from the current offset. 220If the name of the referenced begins with a 221.Dv ^ 222then the endianness of the magic is switched; if the magic mentioned 223.Dv leshort 224for example, 225it is treated as 226.Dv beshort 227and vice versa. 228This is useful to avoid duplicating the rules for different endianness. 229.It Dv regex 230A regular expression match in extended POSIX regular expression syntax 231(like egrep). 232Regular expressions can take exponential time to process, and their 233performance is hard to predict, so their use is discouraged. 234When used in production environments, their performance 235should be carefully checked. 236The size of the string to search should also be limited by specifying 237.Dv /<length> , 238to avoid performance issues scanning long files. 239The type specification can also be optionally followed by 240.Dv /[c][s][l] . 241The 242.Dq c 243flag makes the match case insensitive, while the 244.Dq s 245flag update the offset to the start offset of the match, rather than the end. 246The 247.Dq l 248modifier, changes the limit of length to mean number of lines instead of a 249byte count. 250Lines are delimited by the platforms native line delimiter. 251When a line count is specified, an implicit byte count also computed assuming 252each line is 80 characters long. 253If neither a byte or line count is specified, the search is limited automatically 254to 8KiB. 255.Dv ^ 256and 257.Dv $ 258match the beginning and end of individual lines, respectively, 259not beginning and end of file. 260.It Dv search 261A literal string search starting at the given offset. 262The same modifier flags can be used as for string patterns. 263The search expression must contain the range in the form 264.Dv /number, 265that is the number of positions at which the match will be 266attempted, starting from the start offset. 267This is suitable for 268searching larger binary expressions with variable offsets, using 269.Dv \e 270escapes for special characters. 271The order of modifier and number is not relevant. 272.It Dv default 273This is intended to be used with the test 274.Em x 275(which is always true) and it has no type. 276It matches when no other test at that continuation level has matched before. 277Clearing that matched tests for a continuation level, can be done using the 278.Dv clear 279test. 280.It Dv clear 281This test is always true and clears the match flag for that continuation level. 282It is intended to be used with the 283.Dv default 284test. 285.El 286.Pp 287For compatibility with the Single 288.Ux 289Standard, the type specifiers 290.Dv dC 291and 292.Dv d1 293are equivalent to 294.Dv byte , 295the type specifiers 296.Dv uC 297and 298.Dv u1 299are equivalent to 300.Dv ubyte , 301the type specifiers 302.Dv dS 303and 304.Dv d2 305are equivalent to 306.Dv short , 307the type specifiers 308.Dv uS 309and 310.Dv u2 311are equivalent to 312.Dv ushort , 313the type specifiers 314.Dv dI , 315.Dv dL , 316and 317.Dv d4 318are equivalent to 319.Dv long , 320the type specifiers 321.Dv uI , 322.Dv uL , 323and 324.Dv u4 325are equivalent to 326.Dv ulong , 327the type specifier 328.Dv d8 329is equivalent to 330.Dv quad , 331the type specifier 332.Dv u8 333is equivalent to 334.Dv uquad , 335and the type specifier 336.Dv s 337is equivalent to 338.Dv string . 339In addition, the type specifier 340.Dv dQ 341is equivalent to 342.Dv quad 343and the type specifier 344.Dv uQ 345is equivalent to 346.Dv uquad . 347.Pp 348Each top-level magic pattern (see below for an explanation of levels) 349is classified as text or binary according to the types used. 350Types 351.Dq regex 352and 353.Dq search 354are classified as text tests, unless non-printable characters are used 355in the pattern. 356All other tests are classified as binary. 357A top-level 358pattern is considered to be a test text when all its patterns are text 359patterns; otherwise, it is considered to be a binary pattern. 360When 361matching a file, binary patterns are tried first; if no match is 362found, and the file looks like text, then its encoding is determined 363and the text patterns are tried. 364.Pp 365The numeric types may optionally be followed by 366.Dv \*[Am] 367and a numeric value, 368to specify that the value is to be AND'ed with the 369numeric value before any comparisons are done. 370Prepending a 371.Dv u 372to the type indicates that ordered comparisons should be unsigned. 373.It Dv test 374The value to be compared with the value from the file. 375If the type is 376numeric, this value 377is specified in C form; if it is a string, it is specified as a C string 378with the usual escapes permitted (e.g. \en for new-line). 379.Pp 380Numeric values 381may be preceded by a character indicating the operation to be performed. 382It may be 383.Dv = , 384to specify that the value from the file must equal the specified value, 385.Dv \*[Lt] , 386to specify that the value from the file must be less than the specified 387value, 388.Dv \*[Gt] , 389to specify that the value from the file must be greater than the specified 390value, 391.Dv \*[Am] , 392to specify that the value from the file must have set all of the bits 393that are set in the specified value, 394.Dv ^ , 395to specify that the value from the file must have clear any of the bits 396that are set in the specified value, or 397.Dv ~ , 398the value specified after is negated before tested. 399.Dv x , 400to specify that any value will match. 401If the character is omitted, it is assumed to be 402.Dv = . 403Operators 404.Dv \*[Am] , 405.Dv ^ , 406and 407.Dv ~ 408don't work with floats and doubles. 409The operator 410.Dv !\& 411specifies that the line matches if the test does 412.Em not 413succeed. 414.Pp 415Numeric values are specified in C form; e.g. 416.Dv 13 417is decimal, 418.Dv 013 419is octal, and 420.Dv 0x13 421is hexadecimal. 422.Pp 423Numeric operations are not performed on date types, instead the numeric 424value is interpreted as an offset. 425.Pp 426For string values, the string from the 427file must match the specified string. 428The operators 429.Dv = , 430.Dv \*[Lt] 431and 432.Dv \*[Gt] 433(but not 434.Dv \*[Am] ) 435can be applied to strings. 436The length used for matching is that of the string argument 437in the magic file. 438This means that a line can match any non-empty string (usually used to 439then print the string), with 440.Em \*[Gt]\e0 441(because all non-empty strings are greater than the empty string). 442.Pp 443Dates are treated as numerical values in the respective internal 444representation. 445.Pp 446The special test 447.Em x 448always evaluates to true. 449.It Dv message 450The message to be printed if the comparison succeeds. 451If the string contains a 452.Xr printf 3 453format specification, the value from the file (with any specified masking 454performed) is printed using the message as the format string. 455If the string begins with 456.Dq \eb , 457the message printed is the remainder of the string with no whitespace 458added before it: multiple matches are normally separated by a single 459space. 460.El 461.Pp 462An APPLE 4+4 character APPLE creator and type can be specified as: 463.Bd -literal -offset indent 464!:apple CREATYPE 465.Ed 466.Pp 467A MIME type is given on a separate line, which must be the next 468non-blank or comment line after the magic line that identifies the 469file type, and has the following format: 470.Bd -literal -offset indent 471!:mime MIMETYPE 472.Ed 473.Pp 474i.e. the literal string 475.Dq !:mime 476followed by the MIME type. 477.Pp 478An optional strength can be supplied on a separate line which refers to 479the current magic description using the following format: 480.Bd -literal -offset indent 481!:strength OP VALUE 482.Ed 483.Pp 484The operand 485.Dv OP 486can be: 487.Dv + , 488.Dv - , 489.Dv * , 490or 491.Dv / 492and 493.Dv VALUE 494is a constant between 0 and 255. 495This constant is applied using the specified operand 496to the currently computed default magic strength. 497.Pp 498Some file formats contain additional information which is to be printed 499along with the file type or need additional tests to determine the true 500file type. 501These additional tests are introduced by one or more 502.Em \*[Gt] 503characters preceding the offset. 504The number of 505.Em \*[Gt] 506on the line indicates the level of the test; a line with no 507.Em \*[Gt] 508at the beginning is considered to be at level 0. 509Tests are arranged in a tree-like hierarchy: 510if the test on a line at level 511.Em n 512succeeds, all following tests at level 513.Em n+1 514are performed, and the messages printed if the tests succeed, until a line 515with level 516.Em n 517(or less) appears. 518For more complex files, one can use empty messages to get just the 519"if/then" effect, in the following way: 520.Bd -literal -offset indent 5210 string MZ 522\*[Gt]0x18 leshort \*[Lt]0x40 MS-DOS executable 523\*[Gt]0x18 leshort \*[Gt]0x3f extended PC executable (e.g., MS Windows) 524.Ed 525.Pp 526Offsets do not need to be constant, but can also be read from the file 527being examined. 528If the first character following the last 529.Em \*[Gt] 530is a 531.Em \&( 532then the string after the parenthesis is interpreted as an indirect offset. 533That means that the number after the parenthesis is used as an offset in 534the file. 535The value at that offset is read, and is used again as an offset 536in the file. 537Indirect offsets are of the form: 538.Em (( x [.[bislBISL]][+\-][ y ]) . 539The value of 540.Em x 541is used as an offset in the file. 542A byte, id3 length, short or long is read at that offset depending on the 543.Em [bislBISLm] 544type specifier. 545The capitalized types interpret the number as a big endian 546value, whereas the small letter versions interpret the number as a little 547endian value; 548the 549.Em m 550type interprets the number as a middle endian (PDP-11) value. 551To that number the value of 552.Em y 553is added and the result is used as an offset in the file. 554The default type if one is not specified is long. 555.Pp 556That way variable length structures can be examined: 557.Bd -literal -offset indent 558# MS Windows executables are also valid MS-DOS executables 5590 string MZ 560\*[Gt]0x18 leshort \*[Lt]0x40 MZ executable (MS-DOS) 561# skip the whole block below if it is not an extended executable 562\*[Gt]0x18 leshort \*[Gt]0x3f 563\*[Gt]\*[Gt](0x3c.l) string PE\e0\e0 PE executable (MS-Windows) 564\*[Gt]\*[Gt](0x3c.l) string LX\e0\e0 LX executable (OS/2) 565.Ed 566.Pp 567This strategy of examining has a drawback: You must make sure that 568you eventually print something, or users may get empty output (like, when 569there is neither PE\e0\e0 nor LE\e0\e0 in the above example) 570.Pp 571If this indirect offset cannot be used directly, simple calculations are 572possible: appending 573.Em [+-*/%\*[Am]|^]number 574inside parentheses allows one to modify 575the value read from the file before it is used as an offset: 576.Bd -literal -offset indent 577# MS Windows executables are also valid MS-DOS executables 5780 string MZ 579# sometimes, the value at 0x18 is less that 0x40 but there's still an 580# extended executable, simply appended to the file 581\*[Gt]0x18 leshort \*[Lt]0x40 582\*[Gt]\*[Gt](4.s*512) leshort 0x014c COFF executable (MS-DOS, DJGPP) 583\*[Gt]\*[Gt](4.s*512) leshort !0x014c MZ executable (MS-DOS) 584.Ed 585.Pp 586Sometimes you do not know the exact offset as this depends on the length or 587position (when indirection was used before) of preceding fields. 588You can specify an offset relative to the end of the last up-level 589field using 590.Sq \*[Am] 591as a prefix to the offset: 592.Bd -literal -offset indent 5930 string MZ 594\*[Gt]0x18 leshort \*[Gt]0x3f 595\*[Gt]\*[Gt](0x3c.l) string PE\e0\e0 PE executable (MS-Windows) 596# immediately following the PE signature is the CPU type 597\*[Gt]\*[Gt]\*[Gt]\*[Am]0 leshort 0x14c for Intel 80386 598\*[Gt]\*[Gt]\*[Gt]\*[Am]0 leshort 0x184 for DEC Alpha 599.Ed 600.Pp 601Indirect and relative offsets can be combined: 602.Bd -literal -offset indent 6030 string MZ 604\*[Gt]0x18 leshort \*[Lt]0x40 605\*[Gt]\*[Gt](4.s*512) leshort !0x014c MZ executable (MS-DOS) 606# if it's not COFF, go back 512 bytes and add the offset taken 607# from byte 2/3, which is yet another way of finding the start 608# of the extended executable 609\*[Gt]\*[Gt]\*[Gt]\*[Am](2.s-514) string LE LE executable (MS Windows VxD driver) 610.Ed 611.Pp 612Or the other way around: 613.Bd -literal -offset indent 6140 string MZ 615\*[Gt]0x18 leshort \*[Gt]0x3f 616\*[Gt]\*[Gt](0x3c.l) string LE\e0\e0 LE executable (MS-Windows) 617# at offset 0x80 (-4, since relative offsets start at the end 618# of the up-level match) inside the LE header, we find the absolute 619# offset to the code area, where we look for a specific signature 620\*[Gt]\*[Gt]\*[Gt](\*[Am]0x7c.l+0x26) string UPX \eb, UPX compressed 621.Ed 622.Pp 623Or even both! 624.Bd -literal -offset indent 6250 string MZ 626\*[Gt]0x18 leshort \*[Gt]0x3f 627\*[Gt]\*[Gt](0x3c.l) string LE\e0\e0 LE executable (MS-Windows) 628# at offset 0x58 inside the LE header, we find the relative offset 629# to a data area where we look for a specific signature 630\*[Gt]\*[Gt]\*[Gt]\*[Am](\*[Am]0x54.l-3) string UNACE \eb, ACE self-extracting archive 631.Ed 632.Pp 633If you have to deal with offset/length pairs in your file, even the 634second value in a parenthesized expression can be taken from the file itself, 635using another set of parentheses. 636Note that this additional indirect offset is always relative to the 637start of the main indirect offset. 638.Bd -literal -offset indent 6390 string MZ 640\*[Gt]0x18 leshort \*[Gt]0x3f 641\*[Gt]\*[Gt](0x3c.l) string PE\e0\e0 PE executable (MS-Windows) 642# search for the PE section called ".idata"... 643\*[Gt]\*[Gt]\*[Gt]\*[Am]0xf4 search/0x140 .idata 644# ...and go to the end of it, calculated from start+length; 645# these are located 14 and 10 bytes after the section name 646\*[Gt]\*[Gt]\*[Gt]\*[Gt](\*[Am]0xe.l+(-4)) string PK\e3\e4 \eb, ZIP self-extracting archive 647.Ed 648.Pp 649If you have a list of known avalues at a particular continuation level, 650and you want to provide a switch-like default case: 651.Bd -literal -offset indent 652# clear that continuation level match 653\*[Gt]18 clear 654\*[Gt]18 lelong 1 one 655\*[Gt]18 lelong 2 two 656\*[Gt]18 default x 657# print default match 658\*[Gt]\*[Gt]18 lelong x unmatched 0x%x 659.Ed 660.Sh SEE ALSO 661.Xr file __CSECTION__ 662\- the command that reads this file. 663.Sh BUGS 664The formats 665.Dv long , 666.Dv belong , 667.Dv lelong , 668.Dv melong , 669.Dv short , 670.Dv beshort , 671and 672.Dv leshort 673do not depend on the length of the C data types 674.Dv short 675and 676.Dv long 677on the platform, even though the Single 678.Ux 679Specification implies that they do. However, as OS X Mountain Lion has 680passed the Single 681.Ux 682Specification validation suite, and supplies a version of 683.Xr file __CSECTION__ 684in which they do not depend on the sizes of the C data types and that is 685built for a 64-bit environment in which 686.Dv long 687is 8 bytes rather than 4 bytes, presumably the validation suite does not 688test whether, for example 689.Dv long 690refers to an item with the same size as the C data type 691.Dv long . 692There should probably be 693.Dv type 694names 695.Dv int8 , 696.Dv uint8 , 697.Dv int16 , 698.Dv uint16 , 699.Dv int32 , 700.Dv uint32 , 701.Dv int64 , 702and 703.Dv uint64 , 704and specified-byte-order variants of them, 705to make it clearer that those types have specified widths. 706.\" 707.\" From: guy@sun.uucp (Guy Harris) 708.\" Newsgroups: net.bugs.usg 709.\" Subject: /etc/magic's format isn't well documented 710.\" Message-ID: <2752@sun.uucp> 711.\" Date: 3 Sep 85 08:19:07 GMT 712.\" Organization: Sun Microsystems, Inc. 713.\" Lines: 136 714.\" 715.\" Here's a manual page for the format accepted by the "file" made by adding 716.\" the changes I posted to the S5R2 version. 717.\" 718.\" Modified for Ian Darwin's version of the file command. 719