/..

#CONTENT

#TOP

links
550 bytes2024-12-10 06:38
notes
35 MiB2025-07-03 02:59
posts
6 MiB2025-04-04 17:35
random
225 MiB2025-02-14 17:45
writeups
431 MiB2025-07-02 05:02
all-posts.mdx
753 bytes2025-04-23 20:21
README.mdx
512 bytes2025-02-19 22:32
TODO.md
565 bytes2025-02-24 20:22

#uefi

#cheeses

#spamming f keys

There is an easy cheese for UEFI challenges that immediately expose console access on boot. By spamming the f10 key during the boot sequence of the EDK2 OVMF firmware boot sequence it will drop into the boot menu instead of the bootloader.

The byte sequence for the f keys can be found by stracing qemu:

TEXT
$ sudo strace -e readv -p $(pgrep qemu)
strace: Process 1744629 attached
readv(0, [{iov_base="\33", iov_len=1}], 1) = 1
readv(0, [{iov_base="[", iov_len=1}], 1) = 1
readv(0, [{iov_base="2", iov_len=1}], 1) = 1
readv(0, [{iov_base="1", iov_len=1}], 1) = 1
readv(0, [{iov_base="~", iov_len=1}], 1) = 1

(What qemu reads when you type f10 in -nographic mode).

This can also be used to capture the sequences for the arrow keys.

One workaround for this cheese is to either patch out the code in OVMF which registers the f keys triggering the boot menu. The easier solution is to redirect serial to a unix socket instead of stdio, sleep long enough to pass the firmware boot, then use ncat to connect to the unix socket and allow communication.

#watchdog timer

Might be possible to simply wait for the watchdog timer to fire and kill the bootloader.

#exiting back to the uefi shell

If the challenge is run through a bootloader, returning from the bootloader or exiting will return back to the uefi shell.