SMP table faking

[salil_bhagurkar]

Hi..

I just got an idea. Provided you have an SMP machine with more than 1 processors,

1. Modify the MBR of your hard disk to include your code, which would then load the actual MBR (chaining)
2. Your code would disable one processor from the SMP table entries by setting the appropriate bit.
3. It would start that processor by doing the init etc stuff..
4. Then the code would jump to the original MBR.

This way your code has now reserved one processor from your system. Now suppose windoze boots in, you have access to all the secure application and kernel data of windoze through the second processor. The protection mechanisms i guess don't work for the second processor and the second processor can access the physical memory and possibly send out the data through the serial or parallel port upon requests from the hacker...

So, is this possible?

[Laksen]

You would have to make sure windows doesn't overwrite the code you are running on the second processor, which I don't think you possibly could be sure of. What if windows doesn't even use the smp tables? What if they use the ACPI tables instead. Those are probably a bit harder to patch. The smp tables are outdated and broken on many machines

[salil_bhagurkar]

Aaaah ****... Simple and amazing stuff seems to be withering away from good old PCs... About windows wiping the code, you could experimentally determine or use the BDA or EBDA to write code (which i don't think would be used by the OS IMHO ? ).. I will go read ACPI...

[cg123]

Hmm, this is an interesting idea.

I'm not sure what the best route to take would be in regards to table modification, but it shouldn't be all that hard to get around the code overwriting issue. You could replace various BIOS memory detection functions with a method that calls the original and modifies the result.

Realistically, though, it might be easier to just install a driver.

[Brendan]

Hi,

This should work, if it's done right. For ACPI, there's a "enabled/disabled" flag for each CPU, so you'd just set that bit for the corresponding CPU (and do the same for MP Spec tables).

For memory you should be able to re-route BIOS interrupts. For example, write your own Int 0x15 handler that returns modified memory map information (your Int 0x15 handler can call the BIOS's Int 0x15 handler for unrelated functions), and possibly mess with Int 0x12 too. I'd probably steal 4 KiB just below the EBDA (and make the EBDA look larger than it is) for my BIOS hooks, and steal some extended RAM (e.g. at 0x01000000) for the main code and data. Your "Int 0x15 EAX=0xE820" handler would tell people that these areas "system" instead of RAM.

The protection mechanisms i guess don't work for the second processor and the second processor can access the physical memory and possibly send out the data through the serial or parallel port upon requests from the hacker...

The protection mechanisms setup by the OS won't effect you. However, it'd be very hard to figure out which pages of RAM the OS is using for page directories, etc - you'd only see physical memory, which may be fragmented to oblivion. Also, it'd be very difficult to use any IRQs (the OS would reprogram any IRQ controllers and polling any hardware you use is probably much easier), and you won't be able to guarantee that the OS won't mess with the devices you're trying to use (e.g. the OS might check the serial port to see if anything was plugged in every 2 seconds and stuff up the data you're trying to send).

There was someone else that is (or was?) already doing something similar to this. I can't remember who it was though, and I don't think they were a regular poster here. They were planning on writing a Windows device driver that communicated with the borrowed CPU, where the Windows driver would take care of getting data out reliably, etc. Of course I thought this was silly - if you've got a CPL=0 device driver you can access anything without needing the extra complexity of borrowing a CPU. They were also starting with a modified version of Coreboot, where the BIOS/firmware was modified to hide the CPU and memory. Of course I thought this was silly too - no sane person is going to trash their BIOS and install Coreboot (and hope it actually works) just to try your "CPU borrower".


Cheers,

Brendan