0

To diagnose secure boot issues, I'm looking at the sbat sections of all bootloaders on a machine:

sudo sh -c 'for f in /boot/efi/EFI/*/*.efi; do echo "$f"; objdump -j .sbat -s "$f" |xxd -r; echo; done' 

The idea is to compare with strings /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23.

I'm using xxd -r to go from objdump's hex output to plain ascii, but it looks like it isn't the command I want, because if the hexdump's first column contains large offsets, xxd will get stuck writing zeroes for longer than I can wait to get readable output. For example, for systemd-boot from systemd-boot-efi on ubuntu:

objdump -j .sbat -s /usr/lib/systemd/boot/efi/systemd-bootx64.efi /usr/lib/systemd/boot/efi/systemd-bootx64.efi: file format pei-x86-64 Contents of section .sbat: 101319000 73626174 2c312c53 42415420 56657273 sbat,1,SBAT Vers 101319010 696f6e2c 73626174 2c312c68 74747073 ion,sbat,1,https 101319020 3a2f2f67 69746875 622e636f 6d2f7268 ://github.com/rh 101319030 626f6f74 2f736869 6d2f626c 6f622f6d boot/shim/blob/m 101319040 61696e2f 53424154 2e6d640a 73797374 ain/SBAT.md.syst 101319050 656d642d 626f6f74 2c312c54 68652073 emd-boot,1,The s 101319060 79737465 6d642044 6576656c 6f706572 ystemd Developer 101319070 732c7379 7374656d 642c3235 352c6874 s,systemd,255,ht 101319080 7470733a 2f2f7379 7374656d 642e696f tps://systemd.io 101319090 2f0a7379 7374656d 642d626f 6f742e75 /.systemd-boot.u 1013190a0 62756e74 752c312c 5562756e 74752c73 buntu,1,Ubuntu,s 1013190b0 79737465 6d642c32 35352e34 2d317562 ystemd,255.4-1ub 1013190c0 756e7475 382e312c 68747470 733a2f2f untu8.1,https:// 1013190d0 62756773 2e6c6175 6e636870 61642e6e bugs.launchpad.n 1013190e0 65742f75 62756e74 752f0a00 et/ubuntu/.. 

Is there another way to unhex data while ignoring anything that comes before the first offset?

1

2 Answers 2

1

It's possible with seek:

$ xxd -r -s -0x101319000 < sample sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md systemd-boot,1,The systemd Developers,systemd,255,https://systemd.io/ systemd-boot.ubuntu,1,Ubuntu,systemd,255.4-1ubuntu8.1,https://bugs.launchpad.net/ubuntu/ 

(Note: this output still includes the \0 byte at the end.)

However, this mode is more sensitive to garbage. With the wrong offset or with garbage in the input, you might end up getting this error instead:

xxd: Sorry, cannot seek backwards. 

If you have to preprocess the input anyway, you might just as well remove these offsets altogether, retain the hexadecimal strings only and then try your luck with xxd -r -p.

0

So far the best I have is this awk script that shifts the offsets before piping to xxd:

objdump -j .sbat -s /usr/lib/systemd/boot/efi/systemd-bootx64.efi \ |awk '/^ [0-9a-f]+ / { b = strtonum("0x" $1); sub(" .*", "", $0); $1 = ""; if (!a) a = b; printf "%4x ", (b - a); print $0 }' \ |xxd -r 
/^ [0-9a-f]+ / { b = strtonum("0x" $1) sub(" .*", "", $0) $1 = "" if (!a) a = b; printf "%4x ", (b - a) print $0 } 

Simpler preprocessing, deleting offsets and using -p as suggested by @frostschutz:

objdump -j .sbat -s /usr/lib/systemd/boot/efi/systemd-bootx64.efi \ |sed -E '/^ \w+/!d; s/^ \w+ //; s/ .*//' \ |xxd -r -p 

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.