[File] [PATCH] Magdir/linux x86 kernel; duplicates; short kernel_version not long; syssize versus swap_dev
Christos Zoulas
christos at zoulas.com
Mon Oct 9 13:29:15 UTC 2023
Committed, thanks!
christos
> On Sep 30, 2023, at 3:22 PM, Jörg Jenderek (GMX) <joerg.jen.der.ek at gmx.net> wrote:
>
> 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
> <Nachrichtenteil als Anhang.DEFANGED-132208><trid-v-kernel.txt.gz><file-5_45-linux-kernel_diff_sig.DEFANGED-132209><file-5_45-linux-kernel_diff.DEFANGED-132210>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
More information about the File
mailing list