UEFI Vulnerability Analysis Using AI: Part 1

UEFI vulnerabilities are “the next frontier” in attack vectors, as boot firmware can be persistent on any given target, and runtime services will persist even after an operating system is loaded. And in this new era of very powerful generative pre-trained transformers (GPTs), AI analysis tools are emerging to detect and mitigate such vulnerabilities as never before. In this article, I explore the use of these tools on Tianocore EDKII UEFI builds.

Over time, malware and threats have “gone down the stack”, as privileges increase the closer you get to the silicon. This can be depicted visually by the following:

Caption: Diagram courtesy of Pavel Yosifovich, Windows Internals course

The closer you get to the hardware and silicon (CPU), the more dangerous any vulnerability or threat will be; offset by the fact that attacks at these levels are very difficult to craft. As an example, for silicon, vulnerabilities or trojans could in theory be present, but extremely low-level knowledge, physical access and/or access to the semiconductor fab supply chain would be necessary to take advantage of them.

But firmware, and in this particular instance UEFI, makes for an interesting case study. The UEFI supply chain is relatively fragile; for Intel CPUs, the major suppliers (AMI, Insyde, Phoenix) base their code on the Tianocore EDKII open-source distribution, which in isolation is somewhat flawed; some notebook/server/embedded system OEMs/ODMs make (sometimes random) changes to the base to add their own features; and distribution of security updates is haphazard. Companies like Binarly and Eclypsium do a brisk business in hardening enterprise firmware supply chains.

Given that, I’ve done some research to explore the following:

1. How accurate are today’s LLMs at identifying vulnerabilities in UEFI?
2. Can correct migitations be crafted to these weaknesses, and easily integrated into an IFWI (Integrated Firmware Image)?
3. Are there advantages/benefits to using larger open-source language models (in terms of parameters and tokens) as opposed to off-the-shelf closed-source offerings like ChatGPT, Gemini, etc.?

And I’ll present the findings in a form that others can follow along if interested.

So, with that, let’s proceed.

OVERALL APPROACH

In terms of an overall approach, I wanted to start with an established baseline: a known UEFI build, with source and symbols, and with known vulnerabilities. This is difficult, as most commercial products have their firmware locked down, resident in flash memory, and accessible only as binaries. Fortunately, for the purpose of this study, a publicly available board that meets my criteria does exist: the AAEON UP Xtreme Whiskey Lake board:

Caption: AAEON UP Xtreme Whiskey Lake board

In terms of analysis tools, I plan to compare and contrast the results from:

ChatGPT 5.1

Gemini 3.0

My DGX Spark with model llama3.1:70b

My NVIDIA DGX Spark with model deepseek-r1

But first, let’s compare and contrast older code with known defects to a “golden” baseline of modern firmware: in this case, the CryptoPkg part of the UEFI build. We’ll build an older version of the code that uses OpenSSL 1.1.1j (with known defects); and then compare it against the current version, that incorporates OpenSSL 3.5.1.

BUILDING THE UEFI DEBUG IMAGE WITH SOURCE/SYMBOLS

The UP Xtreme board has a documented, working implementation of what’s termed “MinPlatform” for it within the Tianocore framework. That is, a fully working, mostly open-source, build tree that is available online for anyone to download and play with. I say “mostly” open source because it uses the Intel Firmware Support Package (FSP), and there are binary blobs therein. But that’s OK: the blogs are mostly for silicon initialization, and a small part of the overall build files.

Intel (mostly Harry Hsiung and Laurie Jalstrom, to the best of my knowledge; and my apologies in advance for anyone I neglected to mention) did a terrific job of providing step-by-step instructions on building a bootable UEFI image on this target, based on an older release. The general instructions on how to build the UEFI image are in text form here:

https://github.com/tianocore-training/PlatformBuildLab_MinPlatform_FW/blob/master/FW/MinPlatformBuild/UpX_Lab/Lab_Guide.md

A PowerPoint/PDF with some more detail on building the image is here:

https://github.com/tianocore-training/PlatformBuildLab_MinPlatform_FW/blob/master/FW/MinPlatformBuild/Platform_Build_MinPlatform_Win_Lab.pdf

You can see within the GitHub Intel/tianocore-training repository a ton of tutorial material on UEFI; it’s well worth spending some time here learning, if you have technical interest.

You’ll want to obtain a copy of Visual Studio 2019 as well as Git Bash on your local Windows PC build machine.

On that build machine, launch Git Bash and type in the following, essentially downloading with tag edk2-stable202108:

$ cd c:

$ mkdir fw

$ cd fw
$ mkdir UpX

$ cd UpX

$ git clone https://github.com/tianocore/edk2.git

$ cd edk2

$ git checkout 7b4a99be8a39c12d3a7fc4b8db9f0eab4ac688d5

$ git submodule update --init

$ cd ..

Then download edk2-platforms with the August 2021 tag:

$ git clone https://github.com/tianocore/edk2-platforms.git

$ cd edk2-platforms

$ git checkout 40609743565da879078e6f91da76fc58a35ecaf7

$ cd ..

Finally download the edk2-non-osi and FSP repositories:

$ git clone https://github.com/tianocore/edk2-non-osi.git

$ git clone https://github.com/Intel/FSP.git

At this point, the UpX directory should have four subdirectories: edk2, edk2-non-osi, edk2-platforms, and FSP. You’ll also want to download the ASL compiler and NASM assembler to complete the build. They can be obtained here:

https://github.com/tianocore-training/Presentation_FW/blob/main/FW/Presentations/Lab_Guides/_E_05_Platform_Build_MinPlatform_Win_Lab_Guide.md.

Now, it’s time for the build. Launch the Developer Command Prompt for VS 2019 from a CMD line, and change to the Min Platform Build directory:

$ cd c:\Fw\UpX\edk2-platforms\Platform\Intel

You’ll need to do this build with Python 3.8 (sic) on your PC. Once this is installed and set up, fire off the build:

$ python build_bios.py -p UpXtreme -t VS2019

And, voila, in a few minutes, you’ll have all that you need. The complete 2021 release folder is 2.91GB in size, and holds 48,883 files, with 6,812 folders. In zipped form, it is 1.45GB.

 Note that in the folder:

c:\fw\UpX\Build\WhiskeyLakeOpenBoardPkg\UpXtreme\DEBUG_VS2019\FV

is the 6,848kB UPXTREME.fd file. We’ll refer to this file in a follow-up article in the series; it is the binary file that we’ll be flashing onto the AAEON UP Xtreme target.

You’ll have noted that we built this with the 2021 stable release commit hash for WhiskeyLakeOpenBoardPackage. This boots on the AAEON UP Xtreme board – at least, it boots on mine. This might change in the future if the AAEON hardware board changes in any way incompatibly with this build.

For the purpose of this study, we’ll also need to do a build with today’s most stable release commit hash. This can be done by repeating the commands above, but this time just omit the two lines:

$ git checkout 7b4a99be8a39c12d3a7fc4b8db9f0eab4ac688d5

$ git checkout 40609743565da879078e6f91da76fc58a35ecaf7

As an FYI: you’ll note that the current most recent stable tag at the time of this writing is edk2-stable202511 (released on November 21, 2025); and its commit hash is 46548b1adac82211d8d11da12dd914f41e7aa775.

Note: The 2021 image, once flashed onto the AAEON Up Xtreme board, will boot; but the 2025 version will not. Apparently, Intel did not do the open-source work to enable this image to boot on this target in follow-up releases; that is left as an exercise for the student. Which brings me to a future interesting project: can AI help us “modernize” UEFI and also tune it to boot upon a specific board topology (essentially, a board support package) in an arbitrary release? What information does it need to succeed at a task like this? This would make for a great learning experience to check out.

ANALYZING THE CRYPTOPKG VIA CHATGPT 5.1

Now, I happen to know that the 2021 build files implement an older, flawed version of OpenSSL: release 1.1.1j. You can verify this by looking in:

C:\fw\UpX\edk2\CryptoPkg\Library\OpensslLib\openssl\include\openssl\opensslv.h

where you’ll see:

#define OPENSSL_VERSION_TEXT “OpenSSL 1.1.1j  16 Feb2021”

OpenSSL makes for an interesting attack surface, as it provides core cryptographic services within UEFI firmware for:

• Secure Boot
• Firmware Image Authentication
• Secure Communications

Note: Some may ask, is this version susceptible to the “Heartbleed” attack that was in the news 10 years ago? The answer is no: Heartbleed took advantage of a buffer overrun bug that was patched in OpenSSL 1.0.1g in 2014 – how time flies!

But, back to the present: let’s feed the old image information into ChatGPT 5.1, and see what it finds.

But first, you need to take into account the limitations of the public GPTs. In particular, here’s what ChatGPT says about that topic, when I once tried to upload an 8GB Intel Processor Trace file to it:

ChatGPT file uploads have a hard per-file cap of 512 MB and text/doc uploads are limited to ~2 million tokens per file (far smaller than your 8 GB trace). The blocking issue is the per-file 512 MB and 2M-token caps, which apply broadly—not just Plus. Pro/Enterprise mainly increase file count/quota, not the single-file size/token limit.

My current context window is about 128k tokens (roughly 400–500 pages of text). That’s the maximum amount of text I can keep “in working memory” at once when analyzing a file or conversation.

ChatGPT will choke on our 2021 and 2025 trees:

The 2021 folder is 2.91GB in size, and holds 48,883 files, with 6,812 folders. In zipped form, it is 1.45GB.

The 2025 folder is 3.58GB in size, holds 43,800 files, with 8,521 folders. In zipped form, it is 2.07GB.

Because of the sizes, neither one of these complete builds, even when zipped, can currently be consumed by ChatGPT. As you’ll see later, this is the essence of my research project: to overcome the limitations of file size and LLM token context windows by using my NVIDIA DGX Spark with open source LLMs and technology. More to come on this topic in follow-up episodes in this series!

But for now, we’ll just focus on the EDKII CryptoPkg module, that contains our flawed OpenSSL implementation in the 2021 tree. The 2021 CryptoPkg folder is 60.2 MB with 18,440 files and 228 folders, and zipped it is 19.6MB. The 2025 CryptoPkg folder is 192MB with 7,242 files, and zipped it is 63.5MB. And we’ll use AI to compare the two and scan for vulnerabilities, knowing that we have an incomplete picture; we’ll need the Spark to dig deeper, later!

The precise prompt I used with the 2021 zipped CryptoPkg file was:

Assume that you are a senior systems engineer with specific expertise in UEFI development and programming. You are attempting to make a UEFI firmware build more secure, and you suspect that the EDK2 CryptoPkg may have some vulnerabilities in it. Could you please scan the attached zip file of the CryptoPkg folder and report on any vulnerabilities you detect?

ChatGPT gave me quite a bit of useful information. It thought for 6 minutes and 41 seconds, and provided the following (abridged substantially):

It’s fascinating to read this analysis. Although no obvious vulnerabilities exist in this build, the fact that MD5 and SHA-1 APIs are exposed, and therefore might potentially be used or taken advantage of, is of concern. And the fact that the UEFI supply chain is so hodgepodge makes this an even more delicate situation.

I next completed the 2025 build, and fed this CryptoPkg.zip into ChatGPT, with this prompt:

Analyze the new CryptoPkg2.zip. Have all the vulnerabilities that you identified in the original CryptoPkg.zip been resolved in CryptoPkg2.zip? If so, please identify them. Also, please separately identify any new vulnerabilities that have been introduced within CryptoPkg2 versus CryptoPkg.

And for completeness, I’ll include the full response, ChatGPT this time taking 3 minutes and 0 seconds to respond:

If you read the analysis carefully, it becomes obvious (as it may have been from the beginning): in large codebases, it’s impossible to fully assess vulnerabilities without looking at the big picture: in this case, analyzing the complete codebase, including the build environment. The above is far from a complete vulnerability analysis. And an additional combination of full static analysis, fuzzing, and dynamic analysis would certainly help.

In my next article in this series, I’ll be using the NVIDIA DGX Spark to perform a more massively comprehensive analysis of the entire codebase – in this case, the entire build tree, which is gigabytes in size.

Caption: NVIDIA DGX Spark, Founders Edition

As a brief introduction, I’ll describe the overall approach, for those who want to run ahead:

If everything goes according to plan, this should be amazing. See you in the next article!