Anti Evil Maid and Lenovo x230

Surely that depends on the current state of the IFD and what regions are locked? if all regions are unlocked, then why could the internal programmer not simply flash the whole 12mb virtual rom just like a standard update? IFD, ME, CBFS etc would all be within the 12mb file. I cant remember if x230-maximised puts out a coreboot.rom 12mb as well as the top and bottom 8/4 files. I would have thought so, but even if not then concat may be an option.,

of course, if any region is locked then its a non starter and external is required

Thanks @qubicrm and @Plexus

Please forgive me if I’ve missed it, but how would I check the current state of the IFD and/or what regions are locked?

Also, what are the downsides of staying with the regular (i.e. not maximized) configs?

IIUC from the skulls x230 readme using external_install_top.sh will enable future internal flashing. However if you want neuter the Intel ME and/or use Heads maximized configs you must also externally flash the bottom chip. I have not used skulls myself and I hope someone will correct me if say anything incorrect or ill-advised.

I expect to do some more external flashing in the future so here’s my plan, in case it helps.

On an unmodified x230 where I want to neuter the ME, enable use of 3rd party aftermarket batteries, and install maximized Heads configurations:

  1. Install / Re-install Lenovo BIOS 2.76 EC 1.14
    Why?
    The Cleaning Intel Management Engine - Heads - Wiki initial recommended step is to install the last official Lenovo x230 BIOS that includes EC firmware permitting patching. In BIOS release 2.77, and its included EC version 1.15, Lenovo implemented a digital signature check that prevents unofficial firmware modifications. Installing/re-installing the official version 2.76 Lenovo x230 BIOS with EC Firmware 1.14 may address concerns about previous BIOS and EC firmware modifications, provides a known “good” starting point, and retains the ability to install patched EC firmware.

If the x230 has a Lenovo BIOS that is already at BIOS version 2.77 I’ll make sure downgrading is enabled in the proprietary BIOS settings (Security/UEFI BIOS Update Option/Secure Rollback Prevention → Disable).

I’ll prepare a bootable USB disk using a SHA1 verified copy of g2uj32us.iso (using the El Torito Method).
On an existing Qubes machine, I’ll open a terminal in a whonix-ws dvm and do the following:

sudo apt-get install genisoimage wget
wget https://download.lenovo.com/pccbbs/mobiles/g2uj32us.iso 
sha1sum g2uj32us.iso   # Ensure ee434746cabdb7d8bb8077f79be1429d6dec5696
geteltorito -o bios.img g2uj32us.iso
# Attach trusted USB drive [whole disk sys-usb:sda] to dispXXXX 
sudo fdisk -l /dev/xvdi
sudo dd if=bios.img of=/dev/xvdi
# Detach USB drive from dispXXXX and shutdown disposable VM 

1b) I’ll ensure I have a fully charged authentic Lenovo original battery and the target x230 is connected to an external power source via the power adapter. I’ll boot the x230 and press F1 to enter BIOS settings, open the Startup tab and set the startup mode to Legacy (or Both/Legacy First), press F10 to save changes and reboot. I’ll then boot from the USB drive by pressing F12 to select the bootable USB and follow the onscreen instructions.

  1. Install Lenovo BIOS with EC Modified to Permit Aftermarket Batteries
    Why?
    Given the uncertain future cost and availability of genuine x230 Lenovo batteries it may be desirable to disable the EC’s authentic battery validation check to allow 3rd party aftermarket batteries even though I don’t currently expect to use them.

This will not alter the official Lenovo x230 BIOS v2.76, but will use the official Lenovo BIOS v2.75 bootable CD image (g2uj31us.iso) to modify the official EC 1.14 (G2HT35WW) firmware.

On an existing Qubes machine, I’ll open a terminal in a whonix-ws dvm and do the following:

sudo apt-get install wget build-essential git mtools libssl-dev
git clone https://github.com/hamishcoleman/thinkpad-ec.git && cd thinkpad-ec
make patch_disable_keyboard clean
make patch_enable_battery
cat .config
# Configuration for which patches to apply
CONFIG_KEYBOARD = n
CONFIG_BATTERY = y
make patched.x230.img
sha1sum g2uj31us.iso.orig # Ensure 971a9d57a179f4c368c827fd23c6fd5c86a52df7
#Attach trusted USB drive [whole disk sys-usb:sda] to dispXXXX 
sudo fdisk -l /dev/xvdi
sudo dd if=patched.x230.img of=/dev/xvdi
sudo shutdown -r now
#Remove the USB drive

I’ll repeat 1b and if all goes well I’ll see a “Flashing EC” message in the second stage - after the first reboot. When done the x230 should be able to use 3rd party aftermarket batteries if needed or desired.

  1. Wish I’d actually documented my previous Heads installations :frowning: …but plan anew
    If I decide to use my RPi again I’ll reread [coreboot] your preferred method for supplying power to chip for RPi spi flashing? and make sure I understand I’m going to ignore good advice again. Consider this for the top chip flash, but probably ignore it again.
    Thoroughly review
    osboot – ThinkPad X230/X230T external flashing and osboot – How to program an SPI flash chip with the Raspberry Pi
    since I don’t think it existed when I did this last.

In the end I’ll probably just follow the Heads wiki instructions and perhaps try to incorporate any information and insights gained from this discussion and the links within it.

Hope this helps.

@Justin
flashrom --force --noverify-all --programmer internal --ifd -r bios.rom

should get the file, then use ifdtool from coreboot utils directory

ifdtool -d bios.rom

and it will show you which regions are locked by IFD. You want to see the various “write access” as enabled (if its unlocked) in FLMSTR1

Trying to Flash bottom chip: Error Message:

chip not detected
flashrom v1.2 on Linux 5.8.0-43

No EEPROM/flash device found.
Note: flashrom can never write if flash chip isn;t found automatically.
chip not detected. Please find it manually and rerun with the -c parameter.

My eyes are not good enough to read a bit of etching that is like 128 of an inch high.

Are these chips standardized? Like the same chip model for all Lenovo x230 ?

I did not see a means to read the chip with the OS running. I don’t want to put it back together, and take it apart again.

probably bad contact, I had those scenarios and it had 2 cases: old version of flashrom and bad contacts. have you tried reattach the soic adapter?

Looked like really good contact

I tried to re attach once.

I could try again.

Sometime I will have someone with young youthful eyes look at chip. I am 71, diabetic and lucky to see at all.

from terminal it says

$ sudo ./external_install_bottom.sh -m -k hop
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

ok. Connect a CH341A programmer
trying to detect the chip…
The Skulls coreboot distribution
Run this script on an external computer with a flasher
connected to the X230’s bottom chip (farther away from
the display, closer to you).

Usage: ./external_install_bottom.sh [-m] [-k <backup_filename>] [-l] [-f ] [-b ] [-c ]

-f <hardware_flasher> supported flashers: rpi, ch341a
-c flashrom chip name to use
-m apply me_cleaner -S -d
-l lock the flash instead of unlocking it
-k save the current image as
-s frequency of the RPi SPI bus in Hz. default: 128
-------------- flashrom error: ---------------
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).
Couldn’t open device 1a86:5512.
Error: Programmer initialization failed.
greek@greek-Alienware-17-R4:~/Desktop/skul

Notice something new
The Programmer has a cherry red on light.

When I attach clip, it becomes very dim.

One of the forums it was suggested to use a power supply with Flashing. Someone said not to bother.

Which am I supposed to try first?

I still have amplifier.

I am perplexed as to whether the file name I provide for backup is supposed to be already created. or . . . ?

Should I change clk delay? How?

@catacombs I’ve read many of your forum posts and appreciate your thoughts and ideas. I’d like to help you get your x230 heads set up the way you desire, but have limited experience myself. I’d also like to see the heads x230 setup explained in an understandable way for new qubes users so they can make educated choices. Right now, imo, only by doing it yourself can you truly appreciate what Insurgo https://insurgo.ca/ and others offer. Please understand my questions and comments in that context.

How did you deal with the damaged clip you mentioned previously? Replacement? Repair?

How are you supplying power to the bottom chip? Externally only from the CH341A?

Were you ever able to read from that chip using that CH341A and flashrom?

With regard to visually reading the etching on chips, I’ve found digital cameras (specifically on phones) more helpful than magnifing alone. Changing the light conditions (i.e. light source angle) also made a big difference.

Hope someone else has more to offer…

If you run flashrom without specifying the chip type, does it identify
the type?
If the error message comes after that, then it’s (probably) a bad
connection.
Try reconnecting the clip - make sure you have it the right way round.
Some cheap clips can be difficult to connect.
Have you been able to read the top chip?

There are a number of different chip models used in x230.
It isn’t necessary to specify “the right one” - if you read using
different model descriptors, you will get the same output.
Similarly, writing specifying an arbitrary choice has always worked for
me.

Good to know.

If I had not tried one more time, in the dim light of my house. I would not have noticed the dropoff in the level of the Red Light on the Programmer to a much dimmer red. After worrying about it. I should try to use my tower to be run the CH341. I am relying on the power supply of the tower to provide a much more stable power level.

Justin wrote:

"How did you deal with the damaged clip you mentioned previously? Replacement? Repair?

How are you supplying power to the bottom chip? Externally only from the CH341A?"

I bought another Pomona Clip from a different supplier. I suspect that some of these Pomona Clips might be counterfeit.

I looked at the power supply, which really did come all the way from China, and it does not have a plug for the USB. Has a round hole, which I guess is for a power plug into. And no wire supplied to attach to Programmer. Rather than try to make it work, I think using my Tower would be easier. I will open it up, disconnect all the current hard drives. Insert another hard drive to use just for this task. Install Ubuntu, and so on.

I have another candidate for the computer to do the 'From" side of the Flashing. I have a mid 2009 Mac Book Pro which I could put a hard drive in to install Ubuntu to. I would be relying on the Mac Book Pro having, what they used to call “High Power” USB ports. As I can not guess if I would damage either one or both of the laptops involved.

Using the Tower, (it is a 2016, AMD Processor, 8 GB RAM) is what I will try to do, unless someone here advises me of why I should not.

If I get the problem with the, needs me to provide a chip number, anyone know a good substitute number?

1 Like

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 · osresearch/heads · GitHub
but excited by the prospect of
https://github.com/osresearch/heads/pull/326 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
OpenPGP Key Generation With Backup - Nitrokey Documentation 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 https://store.vikings.net/en/VKGS-WORK-D16

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