1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
# $OpenBSD: freebsd,v 1.2 2004/06/03 03:14:20 tedu Exp $
#------------------------------------------------------------------------------
# freebsd: file(1) magic for FreeBSD objects
#
# All new-style FreeBSD magic numbers are in host byte order (i.e.,
# little-endian on x86).
#
# XXX - this comes from the file "freebsd" in a recent FreeBSD version of
# "file"; it, and the NetBSD stuff in "netbsd", appear to use different
# schemes for distinguishing between executable images, shared libraries,
# and object files.
#
# FreeBSD says:
#
# Regardless of whether it's pure, demand-paged, or none of the
# above:
#
# if the entry point is < 4096, then it's a shared library if
# the "has run-time loader information" bit is set, and is
# position-independent if the "is position-independent" bit
# is set;
#
# if the entry point is >= 4096 (or >4095, same thing), then it's
# an executable, and is dynamically-linked if the "has run-time
# loader information" bit is set.
#
# On x86, NetBSD says:
#
# If it's neither pure nor demand-paged:
#
# if it has the "has run-time loader information" bit set, it's
# a dynamically-linked executable;
#
# if it doesn't have that bit set, then:
#
# if it has the "is position-independent" bit set, it's
# position-independent;
#
# if the entry point is non-zero, it's an executable, otherwise
# it's an object file.
#
# If it's pure:
#
# if it has the "has run-time loader information" bit set, it's
# a dynamically-linked executable, otherwise it's just an
# executable.
#
# If it's demand-paged:
#
# if it has the "has run-time loader information" bit set,
# then:
#
# if the entry point is < 4096, it's a shared library;
#
# if the entry point is = 4096 or > 4096 (i.e., >= 4096),
# it's a dynamically-linked executable);
#
# if it doesn't have the "has run-time loader information" bit
# set, then it's just an executable.
#
# (On non-x86, NetBSD does much the same thing, except that it uses
# 8192 on 68K - except for "68k4k", which is presumably "68K with 4K
# pages - SPARC, and MIPS, presumably because Sun-3's and Sun-4's
# had 8K pages; dunno about MIPS.)
#
# I suspect the two will differ only in perverse and uninteresting cases
# ("shared" libraries that aren't demand-paged and whose pages probably
# won't actually be shared, executables with entry points <4096).
#
# I leave it to those more familiar with FreeBSD and NetBSD to figure out
# what the right answer is (although using ">4095", FreeBSD-style, is
# probably better than separately checking for "=4096" and ">4096",
# NetBSD-style). (The old "netbsd" file analyzed FreeBSD demand paged
# executables using the NetBSD technique.)
#
0 lelong&0377777777 041400407 FreeBSD/i386
>20 lelong <4096
>>3 byte&0xC0 &0x80 shared library
>>3 byte&0xC0 0x40 PIC object
>>3 byte&0xC0 0x00 object
>20 lelong >4095
>>3 byte&0x80 0x80 dynamically linked executable
>>3 byte&0x80 0x00 executable
>16 lelong >0 not stripped
0 lelong&0377777777 041400410 FreeBSD/i386 pure
>20 lelong <4096
>>3 byte&0xC0 &0x80 shared library
>>3 byte&0xC0 0x40 PIC object
>>3 byte&0xC0 0x00 object
>20 lelong >4095
>>3 byte&0x80 0x80 dynamically linked executable
>>3 byte&0x80 0x00 executable
>16 lelong >0 not stripped
0 lelong&0377777777 041400413 FreeBSD/i386 demand paged
>20 lelong <4096
>>3 byte&0xC0 &0x80 shared library
>>3 byte&0xC0 0x40 PIC object
>>3 byte&0xC0 0x00 object
>20 lelong >4095
>>3 byte&0x80 0x80 dynamically linked executable
>>3 byte&0x80 0x00 executable
>16 lelong >0 not stripped
0 lelong&0377777777 041400314 FreeBSD/i386 compact demand paged
>20 lelong <4096
>>3 byte&0xC0 &0x80 shared library
>>3 byte&0xC0 0x40 PIC object
>>3 byte&0xC0 0x00 object
>20 lelong >4095
>>3 byte&0x80 0x80 dynamically linked executable
>>3 byte&0x80 0x00 executable
>16 lelong >0 not stripped
# XXX gross hack to identify core files
# cores start with a struct tss; we take advantage of the following:
# byte 7: highest byte of the kernel stack pointer, always 0xfe
# 8/9: kernel (ring 0) ss value, always 0x0010
# 10 - 27: ring 1 and 2 ss/esp, unused, thus always 0
# 28: low order byte of the current PTD entry, always 0 since the
# PTD is page-aligned
#
7 string \357\020\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 FreeBSD/i386 a.out core file
>1039 string >\0 from '%s'
# /var/run/ld.so.hints
# What are you laughing about?
0 lelong 011421044151 ld.so hints file (Little Endian
>4 lelong >0 \b, version %d)
>4 belong <=0 \b)
0 belong 011421044151 ld.so hints file (Big Endian
>4 belong >0 \b, version %d)
>4 belong <=0 \b)
#
# Files generated by FreeBSD scrshot(1)/vidcontrol(1) utilities
#
0 string SCRSHOT_ scrshot(1) screenshot,
>8 byte x version %d,
>9 byte 2 %d bytes in header,
>>10 byte x %d chars wide by
>>11 byte x %d chars high
|
