cscg24-haunted

notes (5814B)

Find in bootx86.efi that there is a loop that should not terminate,
that terminates though.. sometimes 1 + 1 does not cmp to 2.

Disassembly the rest of the image, it seems harmless.. probably there
is a backdoor in the OVMF code.

Also failed to upload a custom disk image with the same .efi file..
time stamps / uids in the vfat were different but nothing else..
probably also prevented by ovmf with some sort of checksum

Address of bootx86.efi loaded is 0x5ab7000 (found by searching for strings),
Also once at a different address.. but I assume it first loads the image
and then puts it at an address to execute once its been verified / modified.

Indeed one of the images was different from the original, but the only
thing modified was the base address and some values in data, since
the program had already started running.


Can use gdb commands "ignore N M" to ignore hits on breakpoint M for N times.
After the program finally makes it through the braekpoint we can use "info break"
to get the amount of times the breakpoint was hit.
 => 128 hits until the value was modified worked

Use python virt-firmware package virt-fw-dump -i FILE to dump code map and var infos

Whatever is modifying the execution is checking the register state to do so..
we can transform the conditional branch to a jmp and it still makes it past..

Use qemu trace function and sleep to figure out what is triggered in the critical section.

interupts with registers: qemu -d "int" -D log
apic events: qemu -d "trace:*apic*" -D log

in output we see that SMM is entered at 0x5ad0346 and left at 0x5ad0351 with
rax changed to 3.

We can confirm that the SMM handler is in the OVMF_CODE, because
if we build EDK2 ourselves and swap out OVMF_CODE it does not get past the loop
and we dont see any SMI interrupts in the qemu trace.

I still dont understand why this challenge allows a remote connection..
probably the flag is the flash we are given is slightly different
with the actual flag only recoverable on remote.


Since we know we are trying to find out what the SMI handler does, lets
look at the SMI handler code.. The actual mapping of the smi handler is
done by the firmware, but we can set a watchpoint on the standard location
SMBASE+0x8000=0x38000 to find out what is written there when.

   0x38000:     cs mov bp,WORD PTR [rsi]
   0x38004:     adc    BYTE PTR [rax+0xed8166],al
   0x3800a:     add    BYTE PTR [rbx],al
   0x3800c:     add    BYTE PTR [rsi-0x1],ah
   0x3800f:     in     eax,0x8a
   0x38011:     int1
   0x38012:     cld
   0x38013:     (bad)

If we copy out the memory and dissassemble in 16-bit realmode:

   0000:0000   flags:
   0000:0000         2e668b2e1080  mov ebp, dword cs:[0x8010]
   0000:0006       6681ed00000300  sub ebp, 0x30000
   0000:000d               66ffe5  jmp ebp
   0000:0010                 8af1  mov dh, cl
   0000:0012                   fc  cld
   0000:0013                   07  pop es
   0000:0014                   ff  invalid

We can break in the SMI handler, but qemu wont show us the actual memory
or SMM register contents.. so we have a bit more reversing to do.

If we look closely at what is done before qemu reports the SMI, we
can see that there is a write to 0xfee00300.

Local apic registers are memory-mapped in the physical range 0xFEE00xxx!
Using the intel programming reference, we find that register 0x300 is the
interrupt command register. We are wirting 0x00000000, which corresponds to a
vector number of 0, normal delivery mode and physical destination.

The code is registering a local apic which triggers an SMI and finally
the "SMM: enter" we saw on the commandline!

To figure out where the SMI handler jumps to we need to inspect the SMM
state save are (typically at SMBASE+0x3fc00 for 64-bit). Oddly though,
the layout from the intel 64 architecture reference manual does not
match the save state layout for 64 or 32-bit.

Section 32.5.1 describes the "Initial SMM Execution Environment",
where we can see that we start in real-address mode at 0x3000*16+0x8000=0x38000 (cs:rip).

The smm code can be then read as loading the address stored in 0x38010 and jumping
to it = 0x3000*16+0x7f9f18a = 0x7fcf18a.

In Section 2.1 we see an overview of the architecture functionality, as well
as the purpos of the global descriptor table.

THe only reason *0x38000 works is that the interrupt is on the read
before the actual entering of SMI handler.. if you trigger the TRAP
inside SMM mode qemu freezes up with "check_exception"

PML4T (Page-Map Level-4 Table) -> PDPT (Page-Directory Pointer Table)
  -> PDT (Page-Directory Table) -> PT (Page Table) -> 4kB

512 * 512 * 512 * 4kB = 256 TB


To solve the challenge in different execution modes, we need
to generate assembly specific to that mode for each level.
We can use the GCC `.code16gcc` and `.code32` directives for this.

When GS and FS segments are used in 64-bit mode they select from
tables at the GSBASE and FSBASE addresses stored in model-specific registers.

Far jump to pretend to be in the correct code segment sorta works, but
only until the SMI triggers while you are still in long mode.


Solutions:

1. qemu maps the bios flash to 0x100000000 - len(flash),
   if we can figure out where the smi handler is stored (and encoded)
   in the flash we can dump the remote flash and unpack it locally
   (creds to `emxl`)
2. to get around the smi handler changing the execution mode of our
   code segment, we can use a trick: we just switch back and forth
   to a different code segment. There are different code segments
   with the same base address (0) but different permissions..

Lessons learned:
- how segmented memory maps work on ia32
- can use ".intel_syntax" and ".att_syntax" in inline assembly
- can use %= in assembler is replaced by a number unique to that instruction