Anti Evil Maid and Lenovo x230

closer…

sudo ./external_install_bottom.sh -m -k vott
[sudo] password for greek:
Skulls

Please select the hardware you use:

  1. Raspberry Pi
  2. CH341A
  3. Exit
    Please select the hardware flasher: 2
    Ok. Connect a CH341A programmer
    trying to detect the chip…
    Detected MX25L6406E/MX25L6408E.
    make: Entering directory ‘/home/greek/Downloads/skulls-1.0.1/util/ifdtool’
    gcc -O2 -g -Wall -Wextra -Wmissing-prototypes -Werror -I…/commonlib/include -c -o ifdtool.o ifdtool.c
    gcc -o ifdtool ifdtool.o
    make: Leaving directory ‘/home/greek/Downloads/skulls-1.0.1/util/ifdtool’
    Intel ME will be cleaned.
    The flash ROM will be unlocked.
    Start reading 2 times. Please be patient…
    flashrom v1.2 on Linux 5.8.0-43-generic (x86_64)
    flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip “MX25L6406E/MX25L6408E” (8192 kB, SPI) on ch341a_spi.
Reading flash… done.
flashrom v1.2 on Linux 5.8.0-43-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip “MX25L6406E/MX25L6408E” (8192 kB, SPI) on ch341a_spi.
Reading flash… done.
current image saved as vott
connection ok
start unlocking …
./external_install_bottom.sh: ./util/me_cleaner/me_cleaner.py: /usr/bin/python: bad interpreter: No such file or directory
greek@greek-To-be-filled-by-O-E-M:~/Downloads/skulls-1.0.1$


I need to install Python or ?

thanks for reply

OS is Ubuntu 20 LT. usr/bin has python3 and python 3.8, python3-futurize
python3-pasturize

Command to create Python pointer to Python 3 is:

sudo apt-get install python-is-python3

I got Flash of lower chip to finish. Put Lenovo X 230 back together. Light came on behind power button.

No other lights come on like the drive light. Screen blank. No noise. Sigh.
I opened it and tried to make sure all the connections for Touch Pad, Keyboard, CMOS battery. Same result.

I am tired. I will stay away from this project for a few days.

Wednesday 9-15-2021

I am not sure where I messed up. The path forward seems to be to Flash backup onto lower chip. I will have to research the exact Skulls command to do that.

I have been told that Skulls Flash leaves the Ethernet where it is difficult to impossible to Spoof with Qubes OS, after Flashing with the Skulls version. Implying that, Heads version is different.

A fellow also said that the Skulls flash is better documented than the Heads, but better days are coming. Pointing at, https://github.com/osresearch/heads/pull/703

Takes a few hours to get ready to Flash again. I was concerned the other day with a Fluorescent lamp on my desk creating electrostatics to interfere with Flash. I know my Cell Phone throws a powerful signal, better turn that off.

More likely I messed up the contacts Where the CMOS battery plugs in. Get out meter and check.

Might be sunspots. If anyone else has a place to look for why I failed, please post and let me know.

@catacombs Just saw

and thought of your x230.
Excerpt:
“With regards to the difficulty in reading and writing to the 8MB bottom
chip, I can confirm that the issue is not specific to the Raspberry Pi,
but also impacts the ch431a. However, the issue only appears to exist if
the CMOS battery is unplugged. When the CMOS battery is plugged in the
board appears to get just enough additional power to enable a clean
reading of the chip, much as happens with using the Wake-on-Lan method.
This has been true both of the T530 (with or without dGPU) and for the
W530…”

When I had x230 flashing successes I did not disconnect the CMOS battery.

That is since documented from Heads wiki, specifically and practically on Upgrading Heads | Heads - Wiki

Basically, calling flashrom -p internal will tell you the state of the IFD descriptor and locked regions. If some are locked, you need to externally flash.

Maximized boards provide 3 rom images for xx30 boards. The full one, internally flashable, and then bottom and top ones (separated from the full 12mb into individual ones per dd call, see board configuration) to be flashed externally.

1 Like

@Insurgo Huge fan of your work. Your endeavors are really inspiring.

That is since documented from Heads wiki, specifically and practically
on
Upgrading Heads | Heads - Wiki

The Heads https://osresearch.net/ documentation updates are great.

In my case, having flashed Heads awhile ago without unlocking the IFD, I
needed to externally reflash (both top and bottom) with maximized roms.
Both Upgrading Heads | Heads - Wiki and
Step 1 - Downloading Heads | Heads - Wiki
should help anyone similarly situated. Thanks!

When you can spare a few moments, and since we’re in a x230 AEM thread,
maybe this a good place to ask what you envision for the future of
io386, recovery shell authentication, and write-protect wrt Heads?

I was surprised when I first read
[$400 Bounty] Add write-protect support (half-working patch included) · Issue #185 · flashrom/flashrom · GitHub and
SPI flash BP3-0 bits are not set · Issue #12 · linuxboot/heads · GitHub
but excited by the prospect of
Introduce io386 to heads and use it to finalize chipset at runtime by persmule · Pull Request #326 · linuxboot/heads · GitHub with Disk Unlock Key as
fallback for GPG User PIN. Sounds to me, like a real security
improvement and differentiator for xx30. What do you think?

In

(incredibly helpful post btw) you wrote:

Long story short, as of today, current best coreboot native init
platform and user ownable, without FSP ME, that is those old 2012-2013
manufactured Ivy bridges are not yet exposing microcode-only fixable
vulnerabilities.

Really appreciate your research and analysis there. Just concerned if it
might indicate you’ve soured on the kgpe-d16’s prospects, but that’s
probably off topic. Last question, any news on the missing AR5BHB116 info?

Best regards…

2 Likes

Lots of stuff in your reply!

Thanks, this is uplifting and really appreciated.

Your question is landing just a little too early. I cannot yet give details, yet, but it seems that most of that integration work will get funded and I will finally be able to be paid to work on those topics as my main focus in the short term. More to come later on this. But short version is yes: io386 and authentication are really important and will get my main focus soon (amongst other Heads related needed work).

Write protecting bootblock, not yet convinced. Bootblock is still changing often under coreboot, and locking it down would be problematic once locked between coreboot version bump, unless external reprogramming is possible for upgrades. This is where io386 will shine, locking the platform prior of kexec’ing into OS, leaving Heads being the only one having RW access to SPI, and with Recovery Shell being authenticated (and having USB boot also being authenticated and io386 locking down platform prior of kexec call) we make sure Heads threat model will be limited accordingly.

Disk unlock key being a fallback for authentication is not as much desired then having Heads being a clean room for gpg keypair generation, backup and restore, where generated subkeys could be copied/restored to smartcard, and where the key backup media could be used as a fallback if USB dongle is lost, used to restore keys on received replacement dongle.

On those matters, i will open up/update issues and when funding is secured.

I still believe the KGPE-D16 is the best x86 workstation/server platform out there. But sourcing used, tested and even better refurbished motherboards, or best, already assembled/mounted servers/workstations or having trusted partners to collaborate with is not an easy task by itself, even less in the same country and with proper warranties, unfortunately. I don’t know if you followed, but Immunefi sponsored kgpe-d16 revival, and 3mdeb is working on the coreboot revival for that platform.

But selling refurbished workstations and servers would require proper localized partnerships, and on that, I’m a bit soured, yes.

I have not got any information on that matter, where Intel Wireless chipsets are directly targeted, vulnerable and a total different subject altogether: Low Level PC/Server Attack & Defense Timeline — By @XenoKovah of @DarkMentorLLC

1 Like

Lots of stuff in your reply!

And in yours. Super helpful!

Justin:
@Insurgo Huge fan of your work. Your endeavors are really inspiring.
Thanks, this is uplifting and really appreciated.

As with the Qubes team, I sometimes worry that you do not hear our (the user base’s) appreciation enough. So for good measure, another heartfelt thank you!

Your question is landing just a little too early.

My bad. Hope I did not speak out of turn. I am new and not ‘in the
know’. More on that at the end of this message.

I cannot yet give details, yet, but it seems that most of that
integration work will get funded and I will finally be able to be paid
to work on those topics as my main focus in the short term.

That is great news! Are donations through Insurgo Initiative - Open Collective a good way to support your Heads development work?

Write protecting bootblock, not yet convinced.

I’m definitely with you here, not eager to externally flash all Heads
upgrades unless absolutely necessary, just thought I’d inquire as to
your current thoughts. Heads wiki Countermeasures
and subsequently write-protecting-the-bios-chip-advanced just always had me curious. Similarly, recommendations to somehow physically disable writable firmware on network hardware (like AR5BHB116 ?) after externally flashing known “good” firmware, sounds interesting in theory, but I have not seen any practical info. Maybe I need to search more, tho not a priority for me atm.

Disk unlock key being a fallback for authentication is not as much desired then having Heads being a clean room for gpg keypair generation, backup and restore, where generated subkeys could be copied/restored to smartcard, and where the key backup media could be used as a fallback if USB dongle is lost, used to restore keys on received replacement dongle.

Until now, I’ve always created my gpg keys in Qubes (well except prior to my first Heads/Qubes install when I used Tails) so I could do
https://docs.nitrokey.com/pro/openpgp-keygen-backup.html and then import onto both a Nitrokey and a Yubikey 4. Using TOTP only with maximized board roms I can use the two keys interchangeably, but this also means another key to keep track of. Consequently the authentication fallback mechanism chosen is less important to me, at least until I lose one of my keys
Still really like the clean room approach!
May try it on my next key expiry.

I still believe the KGPE-D16 is the best x86 workstation/server platform out there.

Hallelujah! That’s really reassuring and made my day!
Have been neglecting my beast for far to long → HCL

But sourcing used, tested and even better refurbished motherboards, or best, already assembled/mounted servers/workstations or having trusted partners to collaborate with is not an easy task by itself, even less in the same country and with proper warranties, unfortunately. I don’t know if you followed, but Immunefi sponsored kgpe-d16 revival, and 3mdeb is working on the coreboot revival for that platform.

I assembled my own, and know nothing beyond what’s in the following
link, but it appears Vikings has 3 workstations in stock at the moment
according to KGPE-D16 Workstation – Vikings Shop

I have some idea what’s involved and understand why these machines would be a extremely challenging to supply. But developments like Thoughts dereferenced from the scratchpad noise. | KGPE-D16 open-source firmware status and https://3mdeb.com/shop/adapters/flash-chip-adapters/asus-kgpe-d16-flash-chip-adapter/ never mind values based reasons like you presciently expressed so well in
Research support for libreboot/coreboot-based systems · Issue #1594 · QubesOS/qubes-issues · GitHub
make the kgpe-d16 a compelling Qubes hardware option in my biased
opinion. Suspect ‘I’m preaching to the choir’ here, but never know who
might be listening.

But selling refurbished workstations and servers would require proper localized partnerships, and on that, I’m a bit soured, yes.

Understood. Thanks for spending your time taking this diversion with me.

In another thread Insurgo wrote:

i’m not sure how to correctly deal with this community problem/
information sharing/fact/technical discussions without having the
discussions at numerous places and then post here…

If I may ask, where are those places? As someone new to this community, I suspect I miss many of these discussions despite my interest. I try to watch the osresearch heads github, osfw slack, and the qubes forum and mailing lists but sense I miss important discussions. How do you keep track of all that you do? Any pointers, recommendations, or suggestions
for keeping abreast of news?

Thanks again.

@Justin Upgrading Heads | Heads - Wiki should answer your question?
Some history review has been written as well under Prerequisites for Heads | Heads - Wiki

There is a search bar at the top of https://osresearch.net to search the whole documentation as well.

It may have been prior of me_cleaner then? If you do not remember having done anything on the bottom SPI flash, then the firmware descriptor (IFD) and ME regions are probably locked. You can easily verify for yourself from the recovery shell.

If things are unclear about that, please open an issue over heads-wiki.

Upgrading Heads - Heads - Wiki https://osresearch.net/Updating#unlocked-ifd-and-me should answer your question?

Yes, it did.

Some history review has been written as well under Prerequisites for Heads - Heads - Wiki https://osresearch.net/Prerequisites#legacy-vs-maximized-boards

That history helped me.

It may have been prior of me_cleaner then?

Maybe. Since then, I successfully reflashed with maximized roms. The
wiki updates helped. Thanks!

If things are unclear about that, please open an issue over heads-wiki.

Okay.

1 Like