[File] [PATCH] Magdir/linux x86 kernel; duplicates; short kernel_version not long; syssize versus swap_dev
Jörg Jenderek (GMX)
joerg.jen.der.ek at gmx.net
Sat Sep 30 19:22:28 UTC 2023
Hello,
i want to fix a little minor error in mbr detection code, but it
becomes a snail tail of problems. So first i must fix/clean-up stuff
concerning Linux x86 kernel.
When running file command version 5.45 on such Linux x86 kernels i get
at first glance reasonable output, but when using also keep-going option
-k i get confusing output with many text messages like:
bootsect-lilo-24.2.b: DOS/MBR boot sector
DOS/MBR boot sector
Linux kernel
Linux style boot sector
bootsect.b: DOS/MBR boot sector
DOS/MBR boot sector
Linux kernel
Linux style boot sector
damnsmll.lnx: Linux kernel x86 boot executable
bzImage
, version 2.4.26
(root at Knoppix) #1 SMP
Sa Apr 17 19:33:42 CEST 2004
, RO-rootFS
, root_dev 0X301
, Normal VGA
DOS/MBR boot sector
Linux x86 kernel
root=0X301-ro vga=normal, bzImage
, version 2.4.26
(root at Knoppix) #1 SMP
Sa Apr 17 19:33:42 CEST 2004
DOS/MBR boot sector
Linux kernel
Linux style boot sector
ldntldr.bin: Linux kernel x86 boot executable
bzImage
, version \353fHdrS\003\002
, RW-rootFS,
DOS/MBR boot sector
DOS/MBR boot sector
DOS executable (COM), boot code
, start instruction 0x8cc83d00 207402b6
PGP symmetric key encrypted data
- Plaintext or unencrypted data
linux: Linux kernel x86 boot executable
bzImage
, version 3.7.10-1.1-default
(geeko at buildhost) #1 SMP
Thu Feb 28 15:06:29 UTC 2013 (82d3f21)
, RO-rootFS
, swap_dev 0X4
, Normal VGA
DOS/MBR boot sector
DOS/MBR boot sector
PE32 executable (EFI application)
Intel 80386 (stripped to external PDB)
, for MS Windows, 3 sections
linux-elks: DOS/MBR boot sector
DOS/MBR boot sector
Linux kernel
Linux ELKS Kernel
linux-test-1.1.42: DOS/MBR boot sector
Linux x86 boot sector version 0.99-1.1.42
DOS/MBR boot sector
Linux kernel
Linux style boot sector
linux-test-1.1.43: DOS/MBR boot sector
Linux x86 kernel vga=ask version 1.1.43-1.1.45
DOS/MBR boot sector
Linux kernel
Linux style boot sector
linux64: Linux kernel x86 boot executable
bzImage
, version 5.10.10-64
(knopper at eeepc) #3 SMP PREEMPT
Sun Feb 7 09:26:54 CET 2021
, RO-rootFS
, swap_dev 0X7
, Normal VGA
DOS/MBR boot sector
DOS/MBR boot sector
PE32+ executable (EFI application)
x86-64 (stripped to external PDB)
, for MS Windows, 4 sections
memdisk16.bin: Linux kernel x86 boot executable
bzImage
, version MEMDISK 4.05 0x4ee25341
, RW-rootFS,
DOS/MBR boot sector
DOS/MBR boot sector
memtest32.bin: Linux kernel x86 boot executable
bzImage
, version Memtest86+ v6.20
, RW-rootFS,
DOS/MBR boot sector
DOS/MBR boot sector
pxelinux loader (version 3.70 or newer)
memtest64.bin: Linux kernel x86 boot executable
bzImage
, version Memtest86+ v6.20
RW-rootFS,
DOS/MBR boot sector
DOS/MBR boot sector
pxelinux loader (version 3.70 or newer)
memtest86+.bin: DOS/MBR boot sector
Linux x86 kernel
DOS/MBR boot sector
Linux kernel
Linux style boot sector
plpbtrom.bin: Linux kernel x86 boot executable
zImage
, RW-rootFS,
DOS/MBR boot sector
DOS/MBR boot sector
DOS executable (COM), boot code
, start instruction 0xe9bb0848 692c2061
Furthermore with option -i for inspected samples only generic
application/octet-stream is shown.
For comparison reason i run the file format identification utility
TrID ( See https://mark0.net/soft-trid-e.html). This identifies also
all kernel examples as "Linux kernel x86 bootable" by dat-linux.trid.xml
or as "Linux kernel/bootloader/tools x86 bootable (v1)" by
bin-linux-v1.trid.xml (See appended trid-v-kernel.txt.gz).
By Magdir/msdos i get 2 messages. One with strength 40 as "DOS
executable (COM)" because of 16-bit jump instruction E9 at the beginning
like in sample plpbtrom.bin. So this kernel start with real x86 code
instruction suited for BIOS like mode. On the other hand some samples
like linux64 are described as "PE32+ executable (EFI application)" with
strength 50 because it start with MZ executable marker. So such sample
is suited when already running in EFI Modus. So we know the starting
bytes for such samples.
By Magdir/filesystem i get up to 3 messages with text like "DOS/MBR boot
sector". One with strength 130 (=70+60) for Volume Boot Record (VBR
starting with E9 or EB jump instruction) but not making collisions here.
Another is triggered in part doing Initial Program Loader (IPL)
identification with strength 115 (=50+65). The third with strength
105 (=40+65) is done in search for boot signature AA55. I will try to do
fixes for Magdir/filesystem in future session.
The test for boot signature also occur in Magdir/linux but here as
second level test by line like:
>510 leshort 0xAA55 x86 boot executable
By Magdir/linux i get up to four messages with text for linux kernel.
The last (That is number 4) shown for damnsmll.lnx or linux-elks is done
with strength 70 by lines like:
0 belong 0xb8c0078e Linux
>0x1e6 belong 0x454c4b53 ELKS Kernel
>0x1e6 belong !0x454c4b53 style boot sector
So here it checks for some x86 machine instruction b8c0078e at the
beginning and sub level classification is done by check for word ELKS at
offset 0x1e6. The longest mentioned starting instruction is
b8 c0 07 8e d8 b8 00 90 8e c0 b9 00 01 29 f6 29
This is true for "many" case but not all and this is equal to assembler
instructions like:
movw $0x07c0,%ax; movw %ax,%ds; movw $0x9000,%ax; movw %ax,%es; movw
$0x0001,%cx; subw %si,%si; subw
The message before (That is number 3) for damnsmll.lnx or linux-elks is
done with strength 70 by lines like:
0 belong 0xb8c0078e Linux kernel
>0x1e3 string Loading version 1.3.79 or older
>0x1e9 string Loading from prehistoric times
So here it checks for the same x86 machine instruction b8c0078e at the
beginning. Apparently when started such kernel display the word Loading
on the output device. Obviously this word is stored at different offsets
depending on kernel versions. For sample damnsmll.lnx with version
2.4.26 this word is stored at offset 459. So when using this method you
can also add 1 more line like:
>0x1cb string Loading version about 2.4.26
For Bootsectors bootsect-lilo-24.2.b and bootsect.b of bootloader LILO
version 24.2-5.1 this is done by new additional line like:
>0x1c5 string Loading from LILO 24.2
For memory test tool Memtest86 memtest86+.bin version 5.31b this is done
by by new additional line like:
>0x1d2 string Loading from Memtest86 5.31b
Because i want to unify the messages so show kernel version information
part 1 for "old" kernel variant (without HdrS magic) based on "Loading"
message offset in sub routine kernel-version-old1.
The second message like "Linux x86 kernel" for damnsmll.lnx or
memtest86+.bin with strength 110 is done by starting lines like:
0 string \xb8\xc0\x07\x8e\xd8\xb8\x00\x90 Linux
>497 leshort 0 x86 boot sector
>>514 belong 0x8e of a kernel from the dawn of time!
>>514 belong 0x908ed8b4 version 0.99-1.1.42
>>514 belong 0x908ed8b8 for memtest86
>497 leshort !0 x86 kernel
So here for a similar x86 machine code at the beginning is checked. But
here also 4 more bytes (\xd8\xb8\x00\x90) are checked.
Then the value at offset 497 (=01F1h) is used as second level
classification point. According to documentation this is the size of the
setup in sectors (setup_sects) with 512 bytes. Furthermore for backwards
compatibility, if the setup_sects field contains 0, the real value is 4.
So also show this value by line like:
>>497 ubyte !0 setup size 512*%u
>>497 ubyte =0 setup size 512*4 (not 0)
Then i get values like:
0 (memdisk16.bin) 1 (ldntldr.bin) 2 (memtest32.bin memtest64.bin) 4
(plpbtrom.bin linux-elks) 8 (bootsect.b) 10 (damnsmll.lnx) 25 27
(linux64) 29 30 31 33 (linux)
The value of setup_sects is used later to jump to Protected mode part
and the payload.
So samples are described as "Linux x86 kernel" or as "Linux x86 boot
sector" in case of zero setup sector size. So this does not makes sense
to me! So in unified variant i do not care about this second level test
any more. To get same magic indention level like in version 1.85 i must
insert a dummy test. Now the above version information part 2 for "old"
kernel variant (without HdrS magic) based on new HdrS field is done by
sub routine that start like:
0 name kernel-version-old2
>518 leshort x
>>514 belong 0x8e of a kernel from the dawn of time!
Because sometimes there exist difficulties to distinguish Linux kernel
from master boot record (MBR) i look how this field is interpreted as
MBR part. This is 4th partition entry cylinder bits 0-7 done by
Magdir/filesystems.
According to Linux/x86 boot protocol specification some fields are valid
for ALL protocol versions. These are shown here by lines like:
>>504 leshort >0 RAMdisksize=%u KB
>>502 leshort >0 swap=%#X
>>508 leshort >0 root=%#X
>>>498 leshort 1 \b-ro
>>>498 leshort 0 \b-rw
>>506 leshort 0xFFFF vga=normal
>>506 leshort 0xFFFE vga=extended
>>506 leshort 0xFFFD vga=ask
>>506 leshort >0 vga=%d
To do unifying i put these lines with dummy second test line inside a
sub routine that starts like:
0 name kernel-info-old
>504 leshort x
>>504 leshort >0 RAMdisksize=%u KB
Then we see that this deprecated or not needed in that form because in
first message the same informations are shown, but called with little
other phrases and ordering done by lines starting like:
>510 leshort 0xAA55 x86 boot executable
>>518 leshort >0x1ff
>>>529 byte 0 zImage,
>>>529 byte 1 bzImage,
>>>526 lelong >0
>>>>(526.s+0x200) string >\0 version %s,
# same!!
>>498 leshort 1 RO-rootFS,
>>498 leshort 0 RW-rootFS,
>>508 leshort >0 root_dev %#X,
>>502 leshort >0 swap_dev %#X,
>>504 leshort >0 RAMdisksize %u KB,
>>506 leshort 0xFFFF Normal VGA
>>506 leshort 0xFFFE Extended VGA
>>506 leshort 0xFFFD Prompt for Videomode
>>506 leshort >0 Video mode %d
To do unifying i put these lines with dummy second test line inside a
sub routine to show information about Linux kernel (root, swap device,
vga modus, boot protocol, setup size, init_size, EFI entry point) that
starts like:
0 name kernel-info
>48 string Plop\040Boot\040Manager from PLOP Boot Manager
>498 leshort x \b,
>>518 leshort >0x1ff
>>>529 ubyte&0x01 0 zImage,
>>>529 ubyte&0x01 1 bzImage,
#>>>526 uleshort x kernel_version=%#4.4x
>>>526 uleshort >0
>>>>(526.s+0x200) string >\0 version %s,
#>>498 uleshort >1 root_flags=%u
>498 leshort 1 RO-rootFS,
So when unifying the messages you must choose what phraseology is wanted
(done by kernel-info or kernel-info-old). I choose now the first one. So
i use in all cases the text done by sub routine kernel-info.
Now i also do sub classification for PLOP Boot Manager (no sources)
variant samples like plpbtrom.bin by additional test line. There at the
beginning after 16 bit jump comes text like "instruction Hi, are you
searching something? This is the Plop Boot Manager written by Elmar
Hanlhofer http?://www.plop.at".
Some fields are only valid under special conditions (a specific boot
protocol version number or often above is needed). So now i append at
sub routine kernel-info lines like:
>>514 string HdrS \b,
>>>519 ubyte x protocol %u
>>>518 ubyte x \b.%u
#>>>518 uleshort x (%#4.4x)
So i get Boot protocol version like:
2.3 (ldntldr.bin damnsmll.lnx) 2.6 (plpbtrom.bin) 2.10 2.11 (linux) 2.12
(memtest32.bin) 2.13 2.15 (linux64)
For sample memtest86+.bin i get at that offset 0x9000 value which can be
misinterpreted as protocol 144.0. When reading documentation
carefully there is written that boot protocol version field is valid
since version
2.00 and above. That this is true is indicated by HdrS magic at offset
514 which it self is valid since version 2 and above. So test for valid
since version 2.00 and above is done by check for above 0x1FF value at
offset 518.
For control reason the loadflags field can be shown by line like:
#>>>529 ubyte x loadflags=%#x
According to documentation this contain boot protocol option flags. So i
check and display status of bits by new additional lines like:
>>>529 ubyte&0x02 !0 \b, KASLR enabled
>>>529 ubyte&0x20 !0 \b, quiet
>>>518 uleshort >0x206
>>>>529 ubyte&0x40 !0 \b, keep segments
>>>529 ubyte&0x80 !0 \b, can use heap
According to documentation loadflags bit 0 (called LOADED_HIGH and
declared as readable) determinate image status. If this bit is set then
the protected-mode code is loaded at 0x100000 which implies "bzImage".
if this bit is not set then the protected-mode code is loaded at 0x10000
which implies "zImage". All other bits are not readable. So apparently
for kernel images on disc the other bits are not set. But for kernel
grepped from memory dumps this maybe is not true! So the status
"bzImage" or "zImage" correctly must be determinated by considering only
bit 0 of loadflags.
For control reason i add line like:
#>>>526 uleshort x kernel_version=%#4.4x
According to documentation kernel_version is a 2 byte (short) pointer to
kernel version string -200h since since protocol 2.00 if not zero. So
here i get values like:
0h (ldntldr.bin plpbtrom.bin) 260h (memtest32.bin memtest64.bin) 3b0h
(memdisk16.bin) 890h (damnsmll.lnx) 3400h (linux64) 3640h (linux)
There exist a subtile error in current kernel information part. The test
for non zero of kernel_version is done as long value (4 bytes) instead
of short (2 byte). So wrong the type_of_loader byte and loadflags are
also tested. So this error is only relevant for samples with zero
kernel_version. Here i got only 2 samples (ldntldr.bin plpbtrom.bin).
In sample plpbtrom.bin also type_of_loader byte and loadflags are zero.
So check also works by lucky circumstances. For sample ldntldr.bin
type_of_loader byte is zero and loadflags is one (which implies
"bzImage"). So the test for non zero of pointer succeed and the
"version" part is shown by line like:
>>>>(526.s+0x200) string >\0 version %s,
Because kernel_version is zero this is evaluated to
>>>>(0+0x200) string >\0 version %s,
So for sample ldntldr.bin (part of GRUB for DOS) misinterpreted as
version shown is from offset 512:
\353fHdrS\003\002
What does this mean? So i will present here the result and explain later
why. One byte jump instruction (0xEB=0353) to relative offset 0x66 (=f).
This is followed by 4 byte magic pattern HdrS at offset 0x202 (=514).
This is followed by boot protocol 2.3 in little endian.
Since Boot protocol 2.00 at offset 0x200 (=512) 2 byte x86 jump
instruction consisting of 1 byte x86 jump instruction (0xEB) followed by
a signed relative offset byte to 0x202 (0x200 for offset of jump
instruction plus 2 for instruction size). So show the absolute jump
offset (from beginning of kernel image). Then i also jump to this point
and display the next x86 instruction here. These is done by lines like:
>>512 ubyte =0xEB \b, jump
>>513 byte+2 x 0x2%2.2x
>>(513.b+514) ubequad x %#16.16llx instruction
So i get absolute jump values like:
0x230 (damnsmll.lnx) 0x240 (memdisk16.bin) 0x268 (memtest32.bin
memtest64.bin ldntldr.bin linux) 0x26c (linux64)
So nowadays for many cases we get value 0x268. So this is jump after
last mentioned handover_offset data variable. For sample linux64 there
4 more bytes are jumped. I assume that this is done because of 64-bit
alignment reasons. On the other hand the smallest offset in my samples
was 0x230 for damnsmll.lnx. So here it jumps to kernel_alignment
variable which and the following data variables are not used in such
"older" kernel images.
When looking in source listings we see what these next instruction
meaning is like:
b800088ec00fb60e mov ax,0x0800; mov es,ax; movzx cx,byte []
memdisk16.bin
8cc88ed88ec0e88b00 movw %cs,%ax; movw %ax,%ds; movw %ax,%es
; call get_mem_info
memtest32.bin
8cc88ed88ec0e88b00 movw %cs,%ax; movw %ax,%ds; movw %ax,%es
; call get_mem_info
memtest64.bin
So at the moment i show this now just for informational issues. But
maybe in the future this can be also used to do a further sub
classification.
For "older" kernel (that should be before boot protocol 2.00) that is
not precisely written what occur at offset 0x200. In my examples is is
not jump instruction, but i do not know if this is always true. So i
explicitly test for jump instruction byte. If no jump instruction is
found then display instruction by line like:
>>512 ubyte !0xEB \b, at 0x200 %#x instruction
So for Linux ELKS (see Embeddable Linux Kernel Subset ~ ELKS on
Wikipedia) i get here 0xb8 instruction (That is a mov instruction). For
Memtest86 version 5.31b sample memtest86+.bin i get here 0xfa (that is
cli). Again at the moment this is just used for information issues but
can be used to do further sub classification.
The 4 byte field payload_offset at offset 584 (=248h) contains the
offset from the beginning of the protected-mode code to the payload if
not zero and is valid since Protocol 2.08. The real-mode code consists
of the boot sector (always one 512-byte sector) plus the setup code.
So first test for protocol greater 2.07, then check for non zero
relative payload offset then jump setup size sectors a 512 bytes from
kernel beginning, then jump +512 bytes for boot sector - 8 for ubequad +
payload_offset to payload start. This looks like:
>>>518 uleshort >0x207
>>>>584 ulelong >0 at offset %#8.8x
>>>>>(497.b*512) ubequad x
>>>>>>&(584.l+504) ubeshort x PAYLOAD %#4.4x
According to documentation the payload may be compressed. The format of
the compressed data should be determined using the standard magic
numbers. The currently supported compression formats are gzip (magic
numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA (magic number
5D 00), XZ (magic number FD 37), LZ4 (magic number 02 21) and ZST v0.8+
(28B5). So show real used compression methods by lines like:
>>>>>>&(584.l+504) ubeshort =0x1F8B gzip compressed
>>>>>>&(584.l+504) ubeshort =0x1F9E gzip compressed
>>>>>>&(584.l+504) ubeshort =0x425A bzip2 compressed
>>>>>>&(584.l+504) ubeshort =0x5D00 LZMA compressed
>>>>>>&(584.l+504) ubeshort =0xFD37 XZ compressed
>>>>>>&(584.l+504) ubeshort =0x0221 LZ4 compressed
>>>>>>&(584.l+504) ubeshort =0x28B5 ZST compressed
I tried to handle compressed data by calling Magdir/compress via
indirect directive, but i had difficulties with leading space and
duplicate gzip compressed messages. So i add line only as comment like:
#>>>>>>&(584.l+504) indirect x COMPRESS_NOT_WORKING
The size of the 32-bit code in 16-byte paragraphs is stored in variable
syssize at offset 500 (=1f4h). Since protocol 2.04 size is long before
unreliable short. These value is additional shown by lines like:
>518 uleshort <0x204
>>500 uleshort x syssize %#4.4x
>518 uleshort >0x203
>>500 ulelong x syssize %#8.8x
Then i get values like:
0x0000 ldntldr.bin
0x0000 memdisk16.bin
0xf180 damnsmll.lnx
0x00000000 plpbtrom.bin
0x0000217e memtest32.bin
0x000022de memtest64.bin
0x00070c32 linux64
So for sample with "high" values like linux64 this is interpreted as
"swap_dev 0X7" by lines like:
>>502 leshort >0 swap=%#X
>>502 leshort >0 swap_dev %#X,
So this only true for "old protocol". So this must become like:
>>518 uleshort <0x204
>>>502 leshort >0 swap_dev %#X,
Because sometimes there exist difficulties to distinguish Linux kernel
from master boot record (MBR) i look how this field is interpreted as
MBR part. This is 4th partition entry 1st LBA sector in long.
The address to jump to in protected mode is stored in 4 byte variable
code32_start at offset 532 (=214h) since protocol 2.00. For control
reason this can be shown by line like:
>>>>518 uleshort >0x1FF
>>>>532 ulelong >0 \b, code32_start %#x
So for bzImage samples linux64, memtest32.bin and memtest64.bin i get
here value 0x00100000.
The byte variable relocatable_kernel at offset 564 (=234) contains value
non zero since protocol version 2.05 if the protected-mode part of the
kernel can be loaded at any address that satisfies the kernel_alignment
field (kernel is relocatable). For samples like linux64 i get here value
1. For samples like memtest32.bin, memtest64.bin and plpbtrom.bin i get
here value 0. For control reason this can be shown by lines like:
>>>518 uleshort >0x204
>>>>564 ubyte =1 \b, relocatable
#>>>>564 ubyte x \b, relocatable_kernel=%u
At offset 0x230 variable kernel_alignment is stored as 4 byte integer.
Since boot protocol 2.05 this alignment unit required by the kernel is
stored. So you may show this value by lines like:
>>>518 uleshort >0x204
>>>>560 ulelong x \b, kernel_alignment %#x
So here i get values like:
0 (plptrom.bin) 1000h (memtest32.bin memtest64.bin) 200000h (linux)
1000000h (linux64)
Since boot protocol 2.12 at offset 2 byte xloadflags is stored at offset
0x236 (566). So show this by lines like:
>>>518 uleshort >0x20B
#>>>>566 uleshort x \b, xloadflags=%#4.4x
There i get values like:
3fh (linux64) 4h(memtest32.bin) 9h(memtest64.bin)
According to documentation this variable must be interpreted per bit,
but for sample linux64 bit 5 is set which is not mentioned in
documentation. So show this unexpected bit by line like:
>>>>566 uleshort&0x0020 =32 \b, xloadflags bit 5
Maybe somebody with more brain knows what does this mean and can improve
my above line.
Interesting are here flags concerning EFI. Samples like memtest32.bin
and linux64 have bit 2 (XLF_EFI_HANDOVER_32) set. These are now
described by line like:
>>>>566 uleshort&0x0004 =4 \b, 32-bit EFI handoff entry point
Samples like memtest64.bin and linux64 have bit 3 (XLF_EFI_HANDOVER_64)
set. These are now described by line like:
>>>>566 uleshort&0x0008 =8 \b, 64-bit EFI handoff entry point
The last mentioned variable is 4 byte handover_offset at offset 0x264
(=612). Here i get values like:
0 (damnsmll.lnx ldntldr.bin) 10h (memtest32.bin memtest64.bin) 30h
(linux) 190h (linux64) 8e9000b8h (plpbtrom.bin)
According to documentation the observed values can be interpreted as
handover offset since boot protocol 2.12 and if 32 or 64-bit EFI handoff
entry point exist. So this done by lines like:
>>>518 uleshort >0x20B
>>>>566 uleshort&0x000C !0 \b, handover offset
>>>>>612 ulelong x %#x
"Newer" kernel with "HdrS" magic are handled by first branch. The
remaining kernel images are now handled by unified branch which looks like:
0 belong 0xb8c0078e
>514 string HdrS
>514 default x Linux
#!:mime application/octet-stream
!:mime application/x-linux-kernel
>>0 belong x
>>0x1e6 belong =0x454c4b53 ELKS Kernel
!:ext /
>>0x1e6 belong !0x454c4b53 x86 kernel
!:ext /b/bin
>>0 use kernel-version-old1
>>4 string \xd8\xb8\x00\x90
>>>0 use kernel-version-old2
>>>0 use kernel-version-old3
>>0 use kernel-info
First i look for starting x86 instruction (like movw $0x07c0,%ax;
movw). On next level i check for HdrS magic. This applies to "new"
kernel images which are already handled by first branch. So here i do
nothing. Then by default clause the "old" images are matched. Here in my
opinion a BUG in file command occur! For samples with file size 512
(like bootsect.b from LILO 24.2) the phrase "Linux" and mime type
"application/x-linux-kernel" are shown but the remaining lines are not
shown. So i hope an experienced c programmer can fix this!
Furthermore when running with -k option i often get here inserted 3 byte
sequence "\012- ". I believe this is also a BUG and not a feature.
After applying the above mentioned modifications by patch
file-5.45-linux-kernel.diff then all my inspected kernel examples and
related files are now described and with more details and without minor
errors. Furthermore i get no more duplicate messages. So when running
with updated Magdir/linux i get an output like:
bootsect-lilo-24.2.b: Linux x86 kernel from LILO 24.2
, RO-rootFS
, Prompt for Videomode
, setup size 512*8, syssize 0x8000
, at 0x200 0x2d instruction
bootsect.b: Linux
damnsmll.lnx: Linux kernel x86 boot executable
, bzImage
, version 2.4.26
(root at Knoppix) #1 SMP
Sa Apr 17 19:33:42 CEST 2004
, RO-rootFS
, root_dev 0X301
, Normal VGA
, setup size 512*10, syssize 0xf180
, jump 0x230 0xe800040000000000 instruction
, protocol 2.3
ldntldr.bin: Linux kernel x86 boot executable
, bzImage
, RW-rootFS
, setup size 512*1, syssize 0
, jump 0x268 0x2e8b166000662e8b instruction
, protocol 2.3
linux: Linux kernel x86 boot executable
, bzImage, version 3.7.10-1.1-default
(geeko at buildhost) #1 SMP
Thu Feb 28 15:06:29 UTC 2013 (82d3f21)
, RO-rootFS
, Normal VGA
, setup size 512*33, syssize 0x459c6
, jump 0x268 0x8cd88ec0fc8cd239 instruction
, protocol 2.11
, from protected-mode code at offset
0xcd 0x452c41 bytes gzip compressed
, relocatable
, max cmdline size 2047
, init_size 0xaa3000
linux-elks: Linux ELKS Kernel
, RW-rootFS
, root_dev 0X380
, Prompt for Videomode
, setup size 512*4, syssize 0x1270
, at 0x200 0xb8 instruction
linux-test-1.1.42: Linux x86 kernel version 0.99-1.1.42
, RW-rootFS
, Prompt for Videomode
, setup size 512*4 (not 0), syssize 0x12345600
, at 0x200 0x2d instruction
linux-test-1.1.43: Linux x86 kernel version 1.1.43-1.1.45
, RO-rootFS
, Prompt for Videomode
, setup size 512*8, syssize 0x8000
, at 0x200 0x2d instruction
linux64: Linux kernel x86 boot executable
, bzImage
, version 5.10.10-64
(knopper at eeepc) #3 SMP PREEMPT
Sun Feb 7 09:26:54 CET 2021
, RO-rootFS
, Normal VGA
, setup size 512*27, syssize 0x70c32
, jump 0x26c 0x8cd88ec0fc8cd239 instruction
, protocol 2.15
, from protected-mode code at offset
0x40d 0x6fb644 bytes LZMA compressed
, relocatable
, handover offset 0x190
, legacy 64-bit entry point
, can be above 4G
, 32-bit EFI handoff entry point
, 64-bit EFI handoff entry point
, EFI kexec boot support
, xloadflags bit 5
, max cmdline size 2047
, init_size 0x2514000
memdisk16.bin: Linux kernel x86 boot executable
, bzImage
, version MEMDISK 4.05 0x4ee25341
, RW-rootFS
, setup size 512*4 (not 0), syssize 0
, jump 0x240 0xb800088ec00fb60e instruction
, protocol 2.3
memtest32.bin: Linux kernel x86 boot executable
, bzImage
, version Memtest86+ v6.20
, RW-rootFS
, setup size 512*2, syssize 0x217e
, jump 0x268 0x8cc88ed88ec0e88b instruction
, protocol 2.12
, handover offset 0x10
, 32-bit EFI handoff entry point
, max cmdline size 255
, init_size 0x687f8
memtest64.bin: Linux kernel x86 boot executable
, bzImage
, version Memtest86+ v6.20
, RW-rootFS
, setup size 512*2, syssize 0x22de
, jump 0x268 0x8cc88ed88ec0e88b instruction
, protocol 2.12
, handover offset 0x10
, legacy 64-bit entry point
, 64-bit EFI handoff entry point
, max cmdline size 255
, init_size 0x6acf8
memtest86+.bin: Linux x86 kernel from Memtest86 5.31b
, RW-rootFS
, setup size 512*4, syssize 0x2c01
, at 0x200 0xfa instruction
plpbtrom.bin: Linux kernel x86 boot executable
from PLOP Boot Manager
, zImage
, RW-rootFS
, setup size 512*4
, syssize 0
, jump 0x250 0xb800108ed833f6b8 instruction
, protocol 2.6
, max cmdline size 2047
I hope my diff file can be applied in future version of file utility.
Unfortunately i have only enough brain to translate the mentioned rules
on documentation site to magic lines. Especially i do not fully
understand the used expression for "old" kernel images. So i am not sure
that this works 100%. After working some month i have done my best but i
am no kernel expert. So i do not know what variables are relevant for
showing to "normal" users and how to call the new variables in a human
readable way. I hope that experienced kernel programmers can check and
improve this. Also the 2 "BUGS" should be fixed.
I also do not want to change too much of the structure, which i do not
understand 100%. But when all works 100% the not need expressions with
"foo" phrase and sub routine kernel-version-4 can be removed. I you are
satisfied with output of sub routine kernel-info than the "alternative"
given by kernel-info-old can also be deleted or become comments.
With best wishes
Jörg Jenderek
--
Jörg Jenderek
-------------- next part --------------
--
File mailing list
File at astron.com
https://mailman.astron.com/mailman/listinfo/file
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-kernel.txt.gz
Type: application/x-gzip
Size: 1294 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20230930/a214498e/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.45-linux-kernel.diff.sig
Type: application/octet-stream
Size: 6290 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20230930/a214498e/attachment-0001.obj>
-------------- next part --------------
--- file-5.45/magic/Magdir/linux.old 2023-07-17 17:54:36.000000000 +0200
+++ file-5.45/magic/Magdir/linux 2023-09-30 17:41:02.994936600 +0200
@@ -139,3 +139,5 @@
# and Nicolas Lichtmaier <nick at debian.org>
-# All known start with: b8 c0 07 8e d8 b8 00 90 8e c0 b9 00 01 29 f6 29
+# and Joerg Jenderek [unifying + more kernel info]
+# many start with: b8 c0 07 8e d8 b8 00 90 8e c0 b9 00 01 29 f6 29
+# by assembler instructions like: movw $0x07c0,%ax; movw %ax,%ds; movw $0x9000,%ax; movw %ax,%es; movw $0x0001,%cx; subw %si,%si; subw
# Linux kernel boot images (i386 arch) (Wolfram Kleff)
@@ -143,2 +145,4 @@
514 string HdrS Linux kernel
+# to display Linux kernel (strength=125=70+55) after VBR boot sector (130=70+60) but before DOS/MBR IPL (115=50+65), MBR boot sector (105=40+65) via ./filesystem
+# before MZ PE32 executable (EFI application) (strength=50) and before DOS executable (COM) (strength=40) with start instruction 0xe9 via ./msdos
!:strength + 55
@@ -147,14 +151,42 @@
# DamnSmallLinux 1.5 damnsmll.lnx
+#!:mime application/octet-stream
+!:mime application/x-linux-kernel
!:ext /dat/bin/lnx
+# GRR: does there exist here samples without 55AA boot signature? I believe NO (Joerg Jenderek)
>510 leshort 0xAA55 x86 boot executable
+>>0 use kernel-info
+# show information about Linux kernel (root, swap device, vga modus, boot protocol, setup size, init_size, EFI entry point)
+0 name kernel-info
+# like: plpbtrom.bin
+# After 16 bit jump instruction Hi, are you searching something? This is the Plop Boot Manager written by Elmar Hanlhofer http?://www.plop.at
+>48 string Plop\040Boot\040Manager from PLOP Boot Manager
+# dummy test below 512 limit (for LILO 24.2 bootsect.b) to get same magic indention level like in v 1.85
+# and display comma before zImage/bzImage or version
+>498 leshort x \b,
+# boot protocol option flags valid since boot protocol >= 2.00
>>518 leshort >0x1ff
->>>529 byte 0 zImage,
->>>529 byte 1 bzImage,
->>>526 lelong >0
+# loadflags bit 0 (read); LOADED_HIGH; if 0, the protected-mode code is loaded at 0x10000
+>>>529 ubyte&0x01 0 zImage,
+# loadflags bit 0 (read); LOADED_HIGH; if 1, the protected-mode code is loaded at 0x100000; that implies is_bzImage
+>>>529 ubyte&0x01 1 bzImage,
+# kernel_version; since protocol 2.00 if not zero 2 byte pointer to kernel version string -200h; should be < 200h*setup_sects
+# 0h (ldntldr.bin plpbtrom.bin) 260h (memtest32.bin memtest64.bin) 3b0h (memdisk16.bin) 890h (damnsmll.lnx) 3400h (linux64) 3640h (linux)
+#>>>526 uleshort x kernel_version=%#4.4x
+>>>526 uleshort >0
+# GRR: \353fHdrS\003\002 wrong shown if kernel_version=0 like in ldntldr.bin (GRUB for DOS)
>>>>(526.s+0x200) string >\0 version %s,
+# 498 MasterBootRecord 4th partition entry partition type (0~empty 1~FAT12) done by ./filesystems
+# 499 MasterBootRecord 4th partition entry end heads done by ./filesystems
+# root_flags; if set (=1), the root is mounted readonly; deprecated, use the "ro" or "rw" option on the command line instead
+#>>498 uleshort >1 root_flags=%u
>>498 leshort 1 RO-rootFS,
>>498 leshort 0 RW-rootFS,
+# root_dev; default root device number like 0 301h (/dev/hda1 damnsmll.lnx) 380h (/dev/hd?? linux-elks); deprecated and replaced by command line option root=
>>508 leshort >0 root_dev %#X,
->>502 leshort >0 swap_dev %#X,
+# since protocol 2.04 the 2 upper bytes of long syssize and not swap_dev any more
+>>518 uleshort <0x204
+# 502-505 MasterBootRecord 4th partition entry 1st LBA sector done by ./filesystems
+>>>502 leshort >0 swap_dev %#X,
>>504 leshort >0 RAMdisksize %u KB,
+# 506-509 MasterBootRecord 4th partition entry sectors in partition done by ./filesystems
>>506 leshort 0xFFFF Normal VGA
@@ -163,6 +195,170 @@
>>506 leshort >0 Video mode %d
+# more kernel information added by Joerg Jenderek 2023
+# if needed display comma after video mode and before setup_sects
+>>506 leshort >-4
+>>>506 leshort !0 \b,
+# setup_sects; if field contains 0, the real value is 4; size of the setup in sectors like:
+# 0 (memdisk16.bin) 1 (ldntldr.bin) 2 (memtest32.bin memtest64.bin) 4 (plpbtrom.bin linux-elks) 8 (bootsect.b) 10 (damnsmll.lnx) 25 27 (linux64) 29 30 31 33 (linux)
+# MasterBootRecord 4th partition entry start cylinder bits 0-7 done by ./filesystems
+>>497 ubyte !0 setup size 512*%u
+>>497 ubyte =0 setup size 512*4 (not 0)
+# 500 MasterBootRecord 4th partition entry end sectors+cylinder bits 8-9 done by ./filesystems
+# 501 MasterBootRecord 4th partition entry end cylinder bits 0-7 done by ./filesystems
+# syssize; 32-bit code size in 16-byte paragraphs; since protocol 2.04 long before unreliable short
+>>518 uleshort <0x204 \b,
+# 0 (ldntldr.bin) 0 (memdisk16.bin) f180h (damnsmll.lnx)
+>>>500 uleshort x syssize %#x
+>>518 uleshort >0x203 \b,
+# 0 (plpbtrom.bin) 1270h (linux-elks) 217eh (memtest32.bin) 22deh (memtest64.bin) 2c01h (memtest86+.bin) 459c6h (linux misinterpreted as swap_dev 0X4) 70c32h (linux64 misinterpreted as swap_dev 0X7)
+>>>500 ulelong x syssize %#x
+# jump; jump instruction relative to byte 0x202
+>>512 ubyte =0xEB \b, jump
+# jump adress like: 0x230 (damnsmll.lnx) 0x240 (memdisk16.bin) 0x268 (memtest32.bin memtest64.bin ldntldr.bin linux AFTER handover offset) 0x26c (linux64)
+>>>513 byte+2 x 0x2%2.2x
+# next instruction like:
+# b800088ec00fb60e mov ax,0x0800; mov es,ax; movzx cx,byte [] memdisk16.bin
+# 8cc88ed88ec0e88b00 movw %cs,%ax; movw %ax,%ds; movw %ax,%es; call get_mem_info memtest32.bin
+# 8cc88ed88ec0e88b00 movw %cs,%ax; movw %ax,%ds; movw %ax,%es; call get_mem_info memtest64.bin
+>>>(513.b+514) ubequad x %#16.16llx instruction
+# without jump instruction like: 0 (bootsect-lilo-24.2.b EOF!) 0xb8 (mov linux-elks) 0xfa (cli memtest86+.bin)
+>>512 ubyte !0xEB \b, at 0x200 %#x instruction
+# boot protocol version field valid since version >= 2.00 which is indicated by HdrS magic
+# so skip memtest86+.bin with misinterpreted protocol 144.0 (0x9000)
+>>514 string HdrS \b,
+# Boot protocol version; 2.3 (ldntldr.bin damnsmll.lnx) 2.6 (plpbtrom.bin) 2.10 2.11 (linux) 2.12 (memtest32.bin) 2.13 2.15 (linux64)
+>>>519 ubyte x protocol %u
+>>>518 ubyte x \b.%u
+# boot protocol in hexadecimal needed for addtional tests
+#>>>518 uleshort x (%#4.4x)
+# type_of_loader; Boot loader identifier; filled out by the bootloader
+>>>528 ubyte >0 \b, loader %#x
+# loadflags; boot protocol option flags
+#>>>529 ubyte x loadflags=%#x
+# loadflags bit 1 (kernel internal); KASLR_FLAG KASLR status to kernel
+>>>529 ubyte&0x02 !0 \b, KASLR enabled
+# loadflags bit 5 (write); QUIET_FLAG
+>>>529 ubyte&0x20 !0 \b, quiet
+# loadflags bit 6 (write) since boot protocal version >= 2.07; KEEP_SEGMENTS
+>>>518 uleshort >0x206
+>>>>529 ubyte&0x40 !0 \b, keep segments
+# loadflags bit 7 (write); CAN_USE_HEAP
+>>>529 ubyte&0x80 !0 \b, can use heap
+# payload_offset; since boot protocol 2.08 if non-zero contains offset of the protected-mode code to the payload like: cdh (linux) 40dh (linux64)
+>>>518 uleshort >0x207
+>>>>584 ulelong >0 \b, from protected-mode code at offset %#x
+# payload_length; since boot protocol 2.08 the length of the payload like: 452c41h (linux) 6fb644h (linux64)
+>>>>>588 ulelong x %#x bytes
+# jump setup size sectors a 512 bytes from kernel beginning
+>>>>>(497.b*512) ubequad x
+#>>>>>(497.b*512) ubequad x 512BYTES_BEFORE_PROTECTED-MODE_CODE=%#16.16llx
+# jump payload_offset bytes + 512 bytes (for boot sector) - 8 (ubequad length) to payload start
+#>>>>>>&(584.l+504) ubeshort x PAYLOAD=%#4.4x
+# supported compression formats are gzip (magic numbers 1F8B or 1F9E linux) bzip2 (425A), LZMA (5D00 linux64), XZ (FD37) LZ4 (0221) ZST v0.8+ (28B5)
+>>>>>>&(584.l+504) ubeshort =0x1F8B gzip compressed
+>>>>>>&(584.l+504) ubeshort =0x1F9E gzip compressed
+>>>>>>&(584.l+504) ubeshort =0x425A bzip2 compressed
+>>>>>>&(584.l+504) ubeshort =0x5D00 LZMA compressed
+>>>>>>&(584.l+504) ubeshort =0xFD37 XZ compressed
+>>>>>>&(584.l+504) ubeshort =0x0221 LZ4 compressed
+>>>>>>&(584.l+504) ubeshort =0x28B5 ZST compressed
+# TODO: handle compressed data by ./compress; difficulties with leading space and duplicate gzip compressed
+#>>>>>>&(584.l+504) indirect x COMPRESS_NOT_WORKING
+# setup_move_size; for protocol 2.00-2.01; bytes starting with the beginning of the boot sector
+# like: 0 (ldntldr.bin memdisk16.bin memtest32.bin memtest64.bin plpbtrom.bin) 8000h (damnsmll.lnx linux linux64)
+>>>518 uleshort <0x202
+>>>>518 uleshort >0x1FF
+>>>>530 uleshort x \b, setup_move_size %#4.4x
+# code32_start; address to jump to in protected mode like: 100000h (linux linux64 memtest32.bin memtest64.bin)
+#>>>>532 ulelong >0 \b, code32_start %#x
+# kernel_alignment; since boot protocol 2.05 alignment unit required by the kernel (if relocatable_kernel is true) like: 0 (plptrom.bin) 1000h (memtest32.bin memtest64.bin) 200000h (linux) 1000000h (linux64)
+#>>>518 uleshort >0x204
+#>>>>560 ulelong x \b, kernel_alignment %#x
+# relocatable_kernel; since boot protocol 2.05 the protected-mode part of the kernel can be loaded at any address if this field is nonzero
+>>>518 uleshort >0x204
+>>>>564 ubyte =1 \b, relocatable
+#>>>>564 ubyte x \b, relocatable_kernel=%u
+# min_alignment; since boot protocol 2.10 if nonzero, indicates as a power of two the minimum alignment required like: 12 (4 KB memtest32.bin memtest64.bin) 13 (8 KB linux) 21 (2 MB linux64)
+#>>>518 uleshort >0x209
+#>>>>565 ubyte >0 \b, min_alignment %u
+# xloadflags; since boot protocol 2.12 like: 3fh (linux64 unexpected value) 4h(memtest32.bin) 9h(memtest64.bin)
+>>>518 uleshort >0x20B
+#>>>>566 uleshort x \b, xloadflags=%#4.4x
+# handover_offset; offset from beginning of kernel image to EFI handover protocol entry point like:
+# 0 (damnsmll.lnx ldntldr.bin) 10h (memtest32.bin memtest64.bin) 30h (linux) 190h (linux64) 8e9000b8h (plpbtrom.bin INVALID!)
+# this value makes only sense when 32 or 64-bit EFI handoff entry point
+>>>>566 uleshort&0x000C !0 \b, handover offset
+>>>>>612 ulelong x %#x
+# Bit 0 XLF_KERNEL_64; if 1, this kernel has the legacy 64-bit entry point at 0x200
+>>>>566 uleshort&0x0001 !0 \b, legacy 64-bit entry point
+# Bit 1 XLF_CAN_BE_LOADED_ABOVE_4G; if 1, kernel/boot_params/cmdline/ramdisk can be above 4G
+>>>>566 uleshort&0x0002 !0 \b, can be above 4G
+# Bit 2 XLF_EFI_HANDOVER_32; if 1, the kernel supports the 32-bit EFI handoff entry point
+>>>>566 uleshort&0x0004 !0 \b, 32-bit EFI handoff entry point
+# Bit 3 XLF_EFI_HANDOVER_64; if 1, the kernel supports the 64-bit EFI handoff entry point
+>>>>566 uleshort&0x0008 !0 \b, 64-bit EFI handoff entry point
+# Bit 4 EFI_KEXEC; if 1, the kernel supports kexec EFI boot with EFI runtime support
+>>>>566 uleshort&0x0010 !0 \b, EFI kexec boot support
+# GRR: What does bit 5 mean?
+>>>>566 uleshort&0x0020 !0 \b, xloadflags bit 5
+# cmdline_size; since boot protocol 2.06 maximum size of the kernel command line like: 255 (memtest32.bin memtest64.bin) 2047 (linux linux64 plpbtrom); version <= 2.06 maximum was 255
+>>>518 uleshort >0x205
+>>>>568 ulelong x \b, max cmdline size %u
+# hardware_subarch; since boot protocol 2.07 hardware subarchtecture like: 0~default x86 1~lguest 2~Xen 3~Moorestown 4~CE4100 TV
+>>>518 uleshort >0x206
+>>>>572 ulelong >0 \b, hardware_subarch %u
+# hardware_subarch_data; since boot protocol 2.07 pointer to data specific for hardware subarch; unused for default x86
+>>>>>576 ulequad >0 \b, hardware_subarch_data %#llx
+# setup_data; since boot protocol 2.09 64-bit physical pointer to NULL terminated single linked list of struct setup_data
+>>>518 uleshort >0x208
+>>>>592 ulequad >0 \b, setup_data %16.16llx
+# pref_address; since boot protocol 2.10 if nonzero preferred load address for kernel like: 100000h (memtest32.bin memtest64.bin) 200000h (linux) 1000000h (linux64)
+#>>>518 uleshort >0x209
+#>>>>600 ulequad >0 \b, pref_address %#llx
+# init_size; since boot protocol 2.10 indicates amount of contiguous memory kernel needs before it is capable of examining its memory map
+# like: 0h (damnsmll.lnx) 687f8h (memtest32.bin) 6acf8h (memtest64.bin) aa3000h (linux) 2514000h (linux64) 67ea0000h (memdisk16.bin INVALID) a4f3f2ffh (plpbtrom.bin INVALID) ffffff80h (ldntldr.bin INVALID)
+>>>518 uleshort >0x209
+>>>>608 ulelong x \b, init_size %#x
# This also matches new kernels, which were caught above by "HdrS".
-0 belong 0xb8c0078e Linux kernel
+# but also few samples without "HdrS" magic like: bootsect-lilo-24.2.b linux-elks memtest86+.bin
+# URL: https://tldp.org/HOWTO/Linux-i386-Boot-Code-HOWTO/bootsect.html
+#0 belong 0xb8c0078e Linux kernel
+0 belong 0xb8c0078e
+# to display Linux x86 kernel or Linux ELKS Kernel (strength=70=70+0) after VBR boot sector (130=70+60) DOS/MBR IPL (115=50+65), MBR boot sector (105=40+65) via ./filesystem
+#!:strength +0
+# "newer" kernel (with HdrS magic) already done before
+>514 string HdrS
+# so handle "old" kernel variant (without HdrS magic)
+>514 default x Linux
+#!:mime application/octet-stream
+!:mime application/x-linux-kernel
+# GRR: in file 5.45 remaining default clause not working for samples with size = 512 like LILO 24.2 bootsect.b
+>>0 belong x
+# ELKS kernel variant is now unified with other "old" kernel variant (without HdrS magic)
+>>0x1e6 belong =0x454c4b53 ELKS Kernel
+!:ext /
+# "old" kernel variant and not ELKS
+>>0x1e6 belong !0x454c4b53 x86 kernel
+!:ext /b/bin
+# show kernel version information based on "Loading" message offset
+>>0 use kernel-version-old1
+# unified "old" variant with start instruction \xb8\xc0\x07\x8e\xd8\xb8\x00\x90
+>>4 string \xd8\xb8\x00\x90
+# show kernel version information part 2 for "old" kernel variant (without HdrS magic) based on new HdrS field
+>>>0 use kernel-version-old2
+# show kernel version information part 3 for "old" kernel variant (without HdrS magic) based on new HdrS field
+>>>0 use kernel-version-old3
+# show common kernel information
+>>0 use kernel-info
+# show kernel version information part 1 for "old" kernel variant (without HdrS magic) based on "Loading" message offset
+0 name kernel-version-old1
>0x1e3 string Loading version 1.3.79 or older
>0x1e9 string Loading from prehistoric times
+# LILO 24.2-5.1 bootsect.b
+>0x1c5 string Loading from LILO 24.2
+# Memtest86 5.31b memtest86+.bin
+>0x1d2 string Loading from Memtest86 5.31b
+# DamnSmallLinux kernel version 2.4.26 damnsmll.lnx not needed because done by kernel_version pointer
+#>0x1cb string Loading damnsmll.lnx 2.4.26~
+# Memtest86+ v6.20 memtest32.bin not needed because done by kernel_version pointer
+#>0x1c6 string Loading\040Memtest86+ from Memtest86+ v6.20
@@ -185,4 +381,18 @@
-0 string \xb8\xc0\x07\x8e\xd8\xb8\x00\x90 Linux
+# apply only to "old" kernel variant (without HdrS magic) like damnsmll.lnx memtest86+.bin
+# wrong (497 setup_sects 498 root_flags) and now already done by 1st unified "old" kernel variant
+#0 string \xb8\xc0\x07\x8e\xd8\xb8\x00\x90 Linux
+0 string \xb8\xc0\x07\x8e\xd8\xb8\x00\x90foo OLD_VARIANT Linux
>497 leshort 0 x86 boot sector
+>>0 use kernel-version-old2
+>497 leshort !0 x86 kernel
+# not needed any more because information is now shown by common kernel-info with other phrases
+>>0 use kernel-info-old
+# kernel version information part 3 for "old" kernel variant (without HdrS magic) based on HdrS field
+>>0 use kernel-version-old3
+>>0 use kernel-version-4
+# version information part 2 for "old" kernel variant (without HdrS magic) based on new HdrS field
+0 name kernel-version-old2
+# dummy test to get same magic indention level like in v 1.85
+>518 leshort x
>>514 belong 0x8e of a kernel from the dawn of time!
@@ -190,4 +400,14 @@
>>514 belong 0x908ed8b8 for memtest86
-
+# dummy test function to get same magic indention level like in v 1.85
+0 name kernel-version-dummy
>497 leshort !0 x86 kernel
+# not needed any more because information is now shown by kernel-info
+#>0 use kernel-info-old
+>>0 use kernel-info
+# kernel version information part 3 for "old" kernel variant (without HdrS magic) based on HdrS field
+>0 use kernel-version-old3
+# deprecated because same information is shown by kernel-info with other phrases
+0 name kernel-info-old
+# dummy test to get same magic indention level like in v 1.85
+>504 leshort x
>>504 leshort >0 RAMdisksize=%u KB
@@ -201,2 +421,6 @@
>>506 leshort >0 vga=%d
+# kernel version information part 3 for "old" kernel variant (without HdrS magic) based on HdrS field
+0 name kernel-version-old3
+# dummy test to get same magic indention level like in v 1.85
+>514 belong x
>>514 belong 0x908ed881 version 1.1.43-1.1.45
@@ -209,2 +433,7 @@
>>>0xaf7 belong 0x55AA5a5a version 1.3.46-1.3.72
+# show kernel version information part 4 for kernel variant (with HdrS magic) based on "HdrS" field
+# not needed any more because information is now shown by common kernel-info
+0 name kernel-version-4
+# dummy test to get same magic indention level like in v 1.85
+>518 leshort x
>>514 string HdrS
@@ -213,2 +442,3 @@
>>>>529 byte 1 \b, bzImage
+# GRR: Not valid if kernel_version=0
>>>>(526.s+0x200) string >\0 \b, version %s
@@ -216,5 +446,10 @@
# Linux boot sector thefts.
-0 belong 0xb8c0078e Linux
->0x1e6 belong 0x454c4b53 ELKS Kernel
->0x1e6 belong !0x454c4b53 style boot sector
+# ELKS kernel variant is now unified with above "old" kernel variant (without HdrS magic)
+#0 belong 0xb8c0078e Linux
+# display "Linux ELKS Kernel" or "Linux style boot sector" (strength=70) after DOS/MBR IPL (115=50+65) and MBR boot sector (105=40+65) via ./filesystem
+#!:strength +0
+# https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset
+# https://github.com/jbruchon/elks/releases/download/v0.6.0/fd2880-fat.img/linux
+#>0x1e6 belong 0x454c4b53 ELKS Kernel
+#>0x1e6 belong !0x454c4b53 style boot sector
More information about the File
mailing list