Iyfjky

Question

I am not sure if this question should go here or in reverseengineering.stackexchange.com

Quoting from wikipedia:

In the 8086 processor, the interrupt table is called IVT (interrupt
vector table). The IVT always resides at the same location in memory,
ranging from 0x0000 to 0x03ff, and consists of 256 four-byte real mode
far pointers (256 ÃƒÂ— 4 = 1024 bytes of memory).

This is what I find in qemu monitor:

(qemu) xp/128xw 0
0000000000000000: 0xf000ff53 0xf000ff53 0xf000e2c3 0xf000ff53
0000000000000010: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000020: 0xf000fea5 0xf000e987 0xf000d62c 0xf000d62c
0000000000000030: 0xf000d62c 0xf000d62c 0xf000ef57 0xf000d62c
0000000000000040: 0xc0005526 0xf000f84d 0xf000f841 0xf000e3fe
0000000000000050: 0xf000e739 0xf000f859 0xf000e82e 0xf000efd2
0000000000000060: 0xf000d648 0xf000e6f2 0xf000fe6e 0xf000ff53
0000000000000070: 0xf000ff53 0xf000ff53 0xf0006aa4 0xc0008930
0000000000000080: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000090: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000a0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000b0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000c0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000d0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000e0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000000f0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000100: 0xf000ec59 0xf000ff53 0xf000ff53 0xc0006730
0000000000000110: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000120: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000130: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000140: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000150: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000160: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000170: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
0000000000000180: 0x00000000 0x00000000 0x00000000 0x00000000
0000000000000190: 0x00000000 0x00000000 0x00000000 0xf000ff53
00000000000001a0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000001b0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53
00000000000001c0: 0xf000d611 0xf000ec4e 0xf000ec4e 0xf000ec4e
00000000000001d0: 0xf000d61a 0xf000d623 0xf000d608 0xf000ec4e
00000000000001e0: 0xf000ff53 0x00000000 0xf000ff53 0xf000ff53
00000000000001f0: 0xf000ff53 0xf000ff53 0xf000ff53 0xf000ff53

I am not sure what to make of those values. It does not look like an interrupt descriptor table (dereferencing those values gives all nulls). So what am I actually looking at here?

ilkkachu 50.1k676138 · Accepted Answer · 2018-08-22 16:32:27Z

Whatever your firmware left it containing.

On an ideal modern system, the processor never enters real mode at all, as I explained in this SU Q&A titled: What mode do modern 64-bit Intel chip PCs run the boot sector in?, the first KiB of physical memory is as irrelevant as Johan MyrÃƒÂ©en made it out to be in another answer here. But many modern firmwares (still) have compatibility support, meaning that

they can drop back (yes, back, given that they went directly from unreal mode to protected mode) from protected mode to real mode in order to run system softwares that are written for real mode, such as old style PC/AT boot programs in MBRs and VBRs; and

they provide the old real mode firmware APIs and set up all of the data structures for those APIs, that the aforementioned system softwares rely upon.

One of those data structures is the real mode IVT. The old real mode firmware APIs are based upon int instructions, and the real mode IVT is populated by the firmware as part of its initialization with pointers to the various firmware handling routines for those instructions.

Protected mode system softwares do not need the old real mode firmware APIs, and never run the processor in real mode, so the real mode IVT in the first 1KiB of physical memory is unused. (virtual 8086 mode does not address physical address 00000000 and upwards, remember. It addresses logical addresses 00000000 and upwards, which are translated by page tables.) In modern EFI systems, the firmware hands over a memory map of physical memory to the operating system bootstrap, telling it which parts are reserved to the firmware for its own protected mode API purposes, and which parts the operating system is free to just go ahead and use for its pool of physical memory. In theory, the first page of physical memory can be in the latter category.

In practice, firstly, firmwares often mark the first page of physical memory as "boot services code", meaning that an operating system can claim it and just go ahead and use it as part of its physical memory pool, but only after the boot-time services of the EFI firmware have been shut down by the operating system and the firmware reduced to providing its run-time services only. An example of this can be seen in the Linux kernel log (with the add_efi_memmap option) shown by Finnbarr P. Murphy:

[ 0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)

which xe decodes with another program in a more human-readable form as:

[#00] Type: EfiBootServicesCode Attr: 0xF
 Phys: 0000000000000000-0000000000001000
 Virt: 0000000000000000-0000000000001000

In practice, secondly, Linux explicitly ignores this range of physical memory even if the firmware says that it can go ahead and use it. You'll find that on both EFI and non-EFI firmwares alike, once Linux has the physical memory map it patches it (in a function named trim_bios_range), resulting in kernel log messages such as:

[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

This is not so much to cope with modern EFI firmwares, where the real mode IVT is not part of the firmware API, as it is to cope with old PC98 firmwares, where it is part of the firmware API but the firmwares report it (via that self-same API) as physical memory available to be blithely overwritten by the operating system.

So whilst in theory that range of physical memory could contain arbitrary code or data, depending from the momentary needs of the kernel memory allocators and demand-paged virtual memory; in practice Linux just leaves it untouched as the firmware originally set it up.

And on your system the firmware had populated it with real mode IVT entries. Real mode IVT entries are just 16:16 far pointers, of course, and if you look at your memory using a 2-byte hexdump you can actually see this pretty clearly. Some examples:

Most of your IVT entries point to F000:FF53, an address in the real mode firmware ROM area. It is probably a dummy routine that does nothing more than an iret.

IVT entry 1E points to F000:6AA4, a table in that same ROM area.

IVT entry 1F points to C000:8930, a table in the real mode video ROM firmware area.

IVT entry 43 points to C000:6730, another table in the real mode video ROM firmware area.

No, I mean what I wrote. Intel Architecture Software Developers' Manual volume 3 chapter 20 Â§ 2. — Aug 17 at 13:53
Well you have now, because it is; as the first sentence of that section explains. I suspect from this that non-recognition of the common abbreviation "v8086" is a sort of shibboleth. (-: — Aug 17 at 14:21
You need to learn how to read attributive nouns. Or else learn to live without mushroom soup. — Aug 22 at 13:41

Johan MyrÃ©en 6,92211322 · Answer 2 · 2018-08-10 07:01:47Z

The original 8086 processor architecture (implemented as Real Mode in 80286+ processors) has no relevance for Linux, which operates in Protected Mode. There is no interrupt vector table at physical address 0, instead an Interrupt Descriptor Table containing Interrupt Descriptors is used. The IDT can be located anywhere in memory.

The Linux kernel gets a physical memory map from the firmware (BIOS or EFI) which tells which physical memory page frames are usable and which are reserved or not present. The range of usable page frames is not contiguous, but typically has huge holes in it. Traditionally, the x86 Linux kernel has skipped the start of physical memory, even if it is marked as usable. Thus, physical address 0 is not used by the Linux kernel.

This makes sense. Any idea what the leftover content in that unused page is from? — Aug 10 at 7:08
Googling for 53 ff reveals that this is most likely actually a 8086 Real Mode interrupt vector table set up by the firmware or a boot loader. — Aug 10 at 10:34

score 3 · Answer 3 · 2018-08-10 10:20:32Z

Dumping memory

Here's an alternative way to dump the contents of memory inside the system vs. having to do it externally:

$ head /dev/mem | hexdump -C
00000000 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...S...S...S...|
00000010 53 ff 00 f0 53 ff 00 f0 cc e9 00 f0 53 ff 00 f0 |S...S.......S...|
00000020 a5 fe 00 f0 87 e9 00 f0 53 ff 00 f0 46 e7 00 f0 |........S...F...|
00000030 46 e7 00 f0 46 e7 00 f0 57 ef 00 f0 53 ff 00 f0 |F...F...W...S...|
00000040 22 00 00 c0 4d f8 00 f0 41 f8 00 f0 fe e3 00 f0 |"...M...A.......|
00000050 39 e7 00 f0 59 f8 00 f0 2e e8 00 f0 d4 ef 00 f0 |9...Y...........|
00000060 a4 f0 00 f0 f2 e6 00 f0 6e fe 00 f0 53 ff 00 f0 |........n...S...|
00000070 ed ef 00 f0 53 ff 00 f0 c7 ef 00 f0 ed 57 00 c0 |....S........W..|
00000080 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...S...S...S...|
...
...
000afea0 00 00 00 00 00 00 00 00 aa aa aa 00 aa aa aa 00 |................|
000afeb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000b0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000 55 aa 40 e9 62 0a 00 00 00 00 00 00 00 00 00 00 |U.@.b...........|
000c0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49 42 |..............IB|

Analysis

The upper portion above 000c0000 could be bootloader related. Why would I suspect this? The code 55aah at location 000c0000 can typically be a mark in memory for things such as a trigger for the BIOS to run a secondary bootloader.

Reference: Boot Signature - BIOS

Â Â ss#1

However, given this 55aah occurs in the c0000h-effffh range it's more likely this portion is the PNP Expansion Header:

Reference: BIOS Boot Specification

3.3 Devices with PnP Expansion Headers

All IPL devices with option ROMs must contain a valid option ROM header that
resides between system memory addresses C0000h and EFFFFh on a 2k boundary and
begins with 55AAh. A DeviceÃ¢Â€Â™s booting can only be controlled if it has a PnP
Expansion Header. The Expansion Header, whose address resides within the standard
option ROM header at offset +1Ah, contains important information used to configure the device. It also contains pointers to code in the deviceÃ¢Â€Â™s option ROM (BCV or BEV) that the BIOS will call to boot from the device. See Appendix A for the structure of the PnP Expansion Header. There are two ways an IPL device with a PnP Expansion Header can be booted. It must contain a BCV or a BEV.

53ff...

As to the 53ffh data that is at the beginning. It's unclear to me what that actually is. Further researching it it's likely something that the Linux kernel wrote there after the BIOS' bootloading of the MBR handed off to the Linux kernel to boot.

Usually, the bootloader will load the kernel into memory, and then jump to the kernel. The kernel will then be able to reclaim the memory used by the bootloader (because it has already performed its job). However it is possible to include OS code within the boot sector and keep it resident after the OS begins

Digging further I was able to find this paragraph from a research paper titled: Malicious Code Injection via /dev/mem:

1 The mem Device

/dev/mem is the driver interface to physically addressable memory. The
original intent of both mem and kmem was for assisting in debugging the
kernel. We can use the device like a regular character device, using lseek()
to select an address offset. The kmem device is similar but provides an image
of kernel memory in the context of virtual addressing. The Xorg server makes
use of the mem device to access VESA video memory as well as the BIOS
ROM Interrupt Vector Table (IVT) located at physical address 0x00000000
to manipulate video modes in VM86 mode. DOSEMU also uses this to access
the BIOS IVT to be able to make BIOS Interrupts for various tasks (disk
reads, printing to the console, etc).

References

How to dump memory image from linux system?

How do I dump physical memory in Linux?

Master boot record

Compaq Computer Corporation Phoenix Technologies Ltd. Intel Corporation BIOS Boot Specification Version 1.01 January 11, 1996

Linux Memory Analysis - forensic wiki

X86 Assembly/Bootloaders

ilkkachu 50.1k676138 · Accepted Answer · 2018-08-22 16:32:27Z

Whatever your firmware left it containing.

On an ideal modern system, the processor never enters real mode at all, as I explained in this SU Q&A titled: What mode do modern 64-bit Intel chip PCs run the boot sector in?, the first KiB of physical memory is as irrelevant as Johan MyrÃƒÂ©en made it out to be in another answer here. But many modern firmwares (still) have compatibility support, meaning that

they can drop back (yes, back, given that they went directly from unreal mode to protected mode) from protected mode to real mode in order to run system softwares that are written for real mode, such as old style PC/AT boot programs in MBRs and VBRs; and

they provide the old real mode firmware APIs and set up all of the data structures for those APIs, that the aforementioned system softwares rely upon.

One of those data structures is the real mode IVT. The old real mode firmware APIs are based upon int instructions, and the real mode IVT is populated by the firmware as part of its initialization with pointers to the various firmware handling routines for those instructions.

Protected mode system softwares do not need the old real mode firmware APIs, and never run the processor in real mode, so the real mode IVT in the first 1KiB of physical memory is unused. (virtual 8086 mode does not address physical address 00000000 and upwards, remember. It addresses logical addresses 00000000 and upwards, which are translated by page tables.) In modern EFI systems, the firmware hands over a memory map of physical memory to the operating system bootstrap, telling it which parts are reserved to the firmware for its own protected mode API purposes, and which parts the operating system is free to just go ahead and use for its pool of physical memory. In theory, the first page of physical memory can be in the latter category.

In practice, firstly, firmwares often mark the first page of physical memory as "boot services code", meaning that an operating system can claim it and just go ahead and use it as part of its physical memory pool, but only after the boot-time services of the EFI firmware have been shut down by the operating system and the firmware reduced to providing its run-time services only. An example of this can be seen in the Linux kernel log (with the add_efi_memmap option) shown by Finnbarr P. Murphy:

[ 0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB)

which xe decodes with another program in a more human-readable form as:

[#00] Type: EfiBootServicesCode Attr: 0xF
 Phys: 0000000000000000-0000000000001000
 Virt: 0000000000000000-0000000000001000

In practice, secondly, Linux explicitly ignores this range of physical memory even if the firmware says that it can go ahead and use it. You'll find that on both EFI and non-EFI firmwares alike, once Linux has the physical memory map it patches it (in a function named trim_bios_range), resulting in kernel log messages such as:

[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

This is not so much to cope with modern EFI firmwares, where the real mode IVT is not part of the firmware API, as it is to cope with old PC98 firmwares, where it is part of the firmware API but the firmwares report it (via that self-same API) as physical memory available to be blithely overwritten by the operating system.

So whilst in theory that range of physical memory could contain arbitrary code or data, depending from the momentary needs of the kernel memory allocators and demand-paged virtual memory; in practice Linux just leaves it untouched as the firmware originally set it up.

And on your system the firmware had populated it with real mode IVT entries. Real mode IVT entries are just 16:16 far pointers, of course, and if you look at your memory using a 2-byte hexdump you can actually see this pretty clearly. Some examples:

Most of your IVT entries point to F000:FF53, an address in the real mode firmware ROM area. It is probably a dummy routine that does nothing more than an iret.

IVT entry 1E points to F000:6AA4, a table in that same ROM area.

IVT entry 1F points to C000:8930, a table in the real mode video ROM firmware area.

IVT entry 43 points to C000:6730, another table in the real mode video ROM firmware area.

No, I mean what I wrote. Intel Architecture Software Developers' Manual volume 3 chapter 20 Â§ 2. — Aug 17 at 13:53
Well you have now, because it is; as the first sentence of that section explains. I suspect from this that non-recognition of the common abbreviation "v8086" is a sort of shibboleth. (-: — Aug 17 at 14:21
You need to learn how to read attributive nouns. Or else learn to live without mushroom soup. — Aug 22 at 13:41

Johan MyrÃ©en 6,92211322 · Answer 5 · 2018-08-10 07:01:47Z

The original 8086 processor architecture (implemented as Real Mode in 80286+ processors) has no relevance for Linux, which operates in Protected Mode. There is no interrupt vector table at physical address 0, instead an Interrupt Descriptor Table containing Interrupt Descriptors is used. The IDT can be located anywhere in memory.

The Linux kernel gets a physical memory map from the firmware (BIOS or EFI) which tells which physical memory page frames are usable and which are reserved or not present. The range of usable page frames is not contiguous, but typically has huge holes in it. Traditionally, the x86 Linux kernel has skipped the start of physical memory, even if it is marked as usable. Thus, physical address 0 is not used by the Linux kernel.

This makes sense. Any idea what the leftover content in that unused page is from? — Aug 10 at 7:08
Googling for 53 ff reveals that this is most likely actually a 8086 Real Mode interrupt vector table set up by the firmware or a boot loader. — Aug 10 at 10:34

score 3 · Answer 6 · 2018-08-10 10:20:32Z

Dumping memory

Here's an alternative way to dump the contents of memory inside the system vs. having to do it externally:

$ head /dev/mem | hexdump -C
00000000 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...S...S...S...|
00000010 53 ff 00 f0 53 ff 00 f0 cc e9 00 f0 53 ff 00 f0 |S...S.......S...|
00000020 a5 fe 00 f0 87 e9 00 f0 53 ff 00 f0 46 e7 00 f0 |........S...F...|
00000030 46 e7 00 f0 46 e7 00 f0 57 ef 00 f0 53 ff 00 f0 |F...F...W...S...|
00000040 22 00 00 c0 4d f8 00 f0 41 f8 00 f0 fe e3 00 f0 |"...M...A.......|
00000050 39 e7 00 f0 59 f8 00 f0 2e e8 00 f0 d4 ef 00 f0 |9...Y...........|
00000060 a4 f0 00 f0 f2 e6 00 f0 6e fe 00 f0 53 ff 00 f0 |........n...S...|
00000070 ed ef 00 f0 53 ff 00 f0 c7 ef 00 f0 ed 57 00 c0 |....S........W..|
00000080 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...S...S...S...|
...
...
000afea0 00 00 00 00 00 00 00 00 aa aa aa 00 aa aa aa 00 |................|
000afeb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000b0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000 55 aa 40 e9 62 0a 00 00 00 00 00 00 00 00 00 00 |U.@.b...........|
000c0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49 42 |..............IB|

Analysis

The upper portion above 000c0000 could be bootloader related. Why would I suspect this? The code 55aah at location 000c0000 can typically be a mark in memory for things such as a trigger for the BIOS to run a secondary bootloader.

Reference: Boot Signature - BIOS

Â Â ss#1

However, given this 55aah occurs in the c0000h-effffh range it's more likely this portion is the PNP Expansion Header:

Reference: BIOS Boot Specification

3.3 Devices with PnP Expansion Headers

All IPL devices with option ROMs must contain a valid option ROM header that
resides between system memory addresses C0000h and EFFFFh on a 2k boundary and
begins with 55AAh. A DeviceÃ¢Â€Â™s booting can only be controlled if it has a PnP
Expansion Header. The Expansion Header, whose address resides within the standard
option ROM header at offset +1Ah, contains important information used to configure the device. It also contains pointers to code in the deviceÃ¢Â€Â™s option ROM (BCV or BEV) that the BIOS will call to boot from the device. See Appendix A for the structure of the PnP Expansion Header. There are two ways an IPL device with a PnP Expansion Header can be booted. It must contain a BCV or a BEV.

53ff...

As to the 53ffh data that is at the beginning. It's unclear to me what that actually is. Further researching it it's likely something that the Linux kernel wrote there after the BIOS' bootloading of the MBR handed off to the Linux kernel to boot.

Usually, the bootloader will load the kernel into memory, and then jump to the kernel. The kernel will then be able to reclaim the memory used by the bootloader (because it has already performed its job). However it is possible to include OS code within the boot sector and keep it resident after the OS begins

Digging further I was able to find this paragraph from a research paper titled: Malicious Code Injection via /dev/mem:

1 The mem Device

/dev/mem is the driver interface to physically addressable memory. The
original intent of both mem and kmem was for assisting in debugging the
kernel. We can use the device like a regular character device, using lseek()
to select an address offset. The kmem device is similar but provides an image
of kernel memory in the context of virtual addressing. The Xorg server makes
use of the mem device to access VESA video memory as well as the BIOS
ROM Interrupt Vector Table (IVT) located at physical address 0x00000000
to manipulate video modes in VM86 mode. DOSEMU also uses this to access
the BIOS IVT to be able to make BIOS Interrupts for various tasks (disk
reads, printing to the console, etc).

References

How to dump memory image from linux system?

How do I dump physical memory in Linux?

Master boot record

Compaq Computer Corporation Phoenix Technologies Ltd. Intel Corporation BIOS Boot Specification Version 1.01 January 11, 1996

Linux Memory Analysis - forensic wiki

X86 Assembly/Bootloaders

Category

Random preview

What does physical address 0 in x86 Linux contain?

3 Answers 3

Whatever your firmware left it containing.

Further reading

Dumping memory

Analysis

3.3 Devices with PnP Expansion Headers

53ff...

1 The mem Device

References

Your Answer

Sign up or log in

Post as a guest

Post as a guest

3 Answers 3

3 Answers 3

Whatever your firmware left it containing.

Further reading

Whatever your firmware left it containing.

Further reading

Whatever your firmware left it containing.

Further reading

Whatever your firmware left it containing.

Further reading

Dumping memory

Analysis

3.3 Devices with PnP Expansion Headers

53ff...

1 The mem Device

References

Dumping memory

Analysis

3.3 Devices with PnP Expansion Headers

53ff...

1 The mem Device

References

Dumping memory

Analysis

3.3 Devices with PnP Expansion Headers

53ff...

1 The mem Device

References

Dumping memory

Analysis

3.3 Devices with PnP Expansion Headers

53ff...

1 The mem Device

References

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

3 Answers
3

3 Answers
3

3 Answers
3

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor