Watch as a vulnerability cybersecurity expert with 10 years of experience in the field becomes astonished by the reverse engineering powers of... GLM 5.3

**TL;DR: A low-level vulnerability researcher with 10 years of experience used AI (GLM5.3) to complete monitor firmware reverse engineering in 16 minutes — a task that normally takes about a week — extracting, decrypting, and verifying firmware from an encrypted Dell update image. The author is now worried that reverse engineering skills have been "commoditized."** ## Hacking a Monitor with AI — And Why It Terrifies Me A hacking project that used to take me one to two days, sometimes even a full week, I genuinely completed in 15 minutes using AI. That's starting to scare me a little, and I want to walk you through my thinking. First, let me set the scene: I was trying to hack my own monitor. I know what you're thinking — wait, monitors can be hacked? Yes. Peripheral devices have a whole world of hacking, and monitors are just one part of them. Inside a monitor is a blob of firmware that handles HDMI commands, processes video signals, manages any wireless functionality, and so on. And I, as a low-level vulnerability researcher (which, by the way, is the name of this channel), wanted to see if I could find vulnerabilities on the monitor in my upstairs office — a Dell S3422 34-inch monitor. I'm a fan of 34-inch screens. Maybe we can cut that from the video. ## The Rise of AI in Vulnerability Research I know you've probably seen the news — AI is getting stronger at hacking. I've long been an AI skeptic myself, but every time I actually test these models — whether it's frontier models from OpenAI or Anthropic, or open-source models like GLM and Kimi — they've gotten very, very good at quickly accomplishing things that used to take me a long time. Just as calculators revolutionized the way people do math, I truly believe AI is going to revolutionize the way people do vulnerability research — thanks to its ability to automate hypotheses and quickly arrive at concrete conclusions when testing them. ## The Goal: Extract Firmware from the Update Program When you go to Dell's website to update your monitor firmware, the process is simple: download a small `.exe` file, plug in a USB drive, and update the firmware. What I wanted to do was dig into this EXE, find the firmware itself, and then hunt for potential vulnerabilities in that firmware. By exploiting those vulnerabilities, I could gain code execution on the monitor — and my objective would be achieved. ## The Pre-AI Approach: Recursive Extraction with binwalk In the pre-AI era, I would have used a small tool called `binwalk`: ``` binwalk -Me ``` This performs recursive extraction. I ran this command against the Dell image, recursively extracting files within the EXE to look for other files. The idea was that the actual firmware image to be flashed onto the monitor would be hidden somewhere inside the EXE. Once inside the extracted folder, you'd see all sorts of things falling out — and that's expected. We have a self-extracting EXE with a bunch of stuff inside. Two particularly interesting files stand out: 1. **The actual upgrade file itself** — containing the model and firmware version number for our monitor 2. **Dell ISP library.dll** — the In-System Programming library, which should contain functions for uploading and downloading firmware and would tell me where to look in the upgrade file for the actual code ## The First Obstacle: Firmware Encryption Now things start to get more complicated — and AI completed the entire process in just 16 minutes. No exaggeration, I have the timeline. A common problem in firmware vulnerability research is that firmware is often encrypted. Manufacturers may not want you peeking into how their monitors work internally, so they encrypt it. You can actually tell pretty quickly — if you run binwalk's **entropy analysis** using the `-E` flag, you get a cool little chart where the edges all show **0.96**. That's a high-entropy edge, meaning the binary entropy is very high — the randomness of the data bits is sufficient to indicate encryption. Not great. I don't have the key for this file, and I'd guess the key is encrypted and hidden somewhere in the monitor. ### Ad Break: Sentry As everyone's seen in the news, AI is making it increasingly easy for hackers to compromise your application. With Sentry, you just integrate Sentry into your codebase — often with just a single line of code — and you get a clear stream of errors: all the exceptions and errors surfacing across your codebase. When you drill into a bug, you can see the exact time it occurred and the environment. Using **Sentry's MCP server**, I can combine MCP data with my codebase and have an AI agent help me triage the bug. The AI agent quickly couples the telemetry data Sentry provides via the MCP server with my local codebase and, in 15 seconds, identifies that the root cause is a user-provided GitHub URL containing a subfolder, which the project repository can't handle, resulting in an uncaught exception. Sentry not only tells you what happened but also shows a suggested fix. From a security standpoint, my biggest personal concern is **security debt** — as AI agents drive an increase in code volume, things start to break. These seemingly minor bugs can gradually accumulate and evolve into real security vulnerabilities. New users can get $100 in Sentry credits via the link below. ## Reverse Engineering the Encryption with Ghidra If you open this library in the NSA's reverse engineering framework **Ghidra**, you'll notice a function called `encrypt_decrypt_method`. "Luke, I am your only hope" — our only hope is that somewhere within this function, the key for encrypting and decrypting these firmware images is hidden, since they need to be encrypted before being pushed to the monitor and flashed. Open the binary, go into one of these functions, and you'll see a virtual function table called `encrypt_decrypt`. This is where reverse engineering becomes **very iterative, very brute-force trial and error** — and AI makes it terrifyingly simple. Inside the virtual function table for this encrypt-decrypt method, there are **nine functions**, each doing something different, many containing content that looks like random data. I've been doing this for a while, and I can quickly spot that this ASCII data is typically some form of encryption/decryption algorithm key. But if you scroll down a bit further, things get more complicated. Suddenly you're seeing lots of for loops, lots of random structures populating values from other structures. Before you know it, things become very unmanageable, very difficult to understand what's actually going on here. This is reverse engineering. You can browse a binary like this, stare at it, and eventually you'll figure out the manufacturer's intent, the intent of whoever wrote the code. But it's not free, it doesn't happen automatically. You have to spend a lot of time iterating, guessing, making informed hypotheses and testing them, trying to reduce the noise in your mental model of the program. ## How AI Accelerates Reverse Engineering AI is very good at narrowing down the search space. The problem with reverse engineering an encryption routine like this is that the file offsets where encryption starts or ends aren't always obvious. So if you get a byte, a single character wrong in the encryption or decryption process, the result is completely wrong. This is where you need to do some brute-force testing of hypotheses. But by using AI, we can make all of this much faster. All I typed was: > "Hey, I'm trying to find the firmware in this image, and I want to identify the HDMI command parsers in the firmware. The firmware is potentially encrypted." That's it. That's all I said. I let it run. ## The Timeline: A 16-Minute Miracle Folks, here's the timeline. I said 15 minutes — that might have been clickbait — it was actually 16 minutes. But by my 8-hour full-time workday, this would have taken me roughly a week. You could call it a "skill issue," but regardless, it did it in 15 minutes. The AI picked up right where we left off — around the **13:51** mark, things got super scary: 1. It launched a session 2. It found the **UPG container** — the upgrade file containing the actual image 3. It launched **Ghidra MCP** and decompiled the binary into pseudocode C (it was guessing at the manufacturer's best-case C code, since we don't actually have the source) 4. it identified the same function we found in the Dell ISP library 5. It immediately noted: **"Wait. In function 10012A60, there's a constructor that creates a key blob. Then, this other function is literally the decrypt — it uses data from that key blob to perform cryptographic math on the operand."** 6. It extracted those keys and, **in under a minute**, wrote a Python script to decrypt the UPG file 7. **Less than 40 seconds later**, it ran the first decryption on the image and said: **"Yes, decryption confirmed."** ## Verification: MD5 Checksum As anyone doing AI vulnerability research should be, I was equally skeptical. How could we be so sure? How do we know the binary was actually decrypted and not just a pile of high-noise gibberish? The next part — AI completed this in **45 seconds**. ### The Decisive Verification Step The definitive check was: the decrypted image carries its own MD5 at offset **0x1CD**. This MD5 is computed by the DLL over the plaintext — provided the corresponding MAC field is zeroed out. It took the output image, jumped to offset **0x1CD**. When it zeroed out that field and computed the MD5 over the entire image, the MD5 value matched what was stored there. It wrote a small script to check this and simply said: > **"The stored MD5 is this, and the computed MD5 is this. Based on my reading of less than 15 minutes of this DLL's spec, it has been correctly decrypted."** Not me — the AI said it. ### More Verification: Entropy Analysis, Architecture Match, Valid Reset Vector On top of that, it ran **statistical entropy analysis** on the binary, showing patterns containing zeros and FF — byte densities consistent with what you'd expect from a firmware image across flash-to-flash, along with plaintext semantics associated with the image. It also recognized that the code it believed it had disassembled was consistent with the **MSTAR 8051** — the microcontroller architecture inside the monitor. And it found a **valid reset vector** at the correct offset within the image — exactly where execution would begin. You can verify the math. You can go into the image itself and look line by line, and you'll find that what it decrypted contains not just the monitor's **valid model number**, but also the **specific build version** and a wealth of other metadata about it. ## Why This Is Terrifying But the truly scary thing you start to see are these patterns: - This is **complete gobbledygook** — completely meaningless to anyone reading this output - But when you start seeing these **repeating patterns** in an image that shouldn't be repetitive, this suggests there's some kind of data structure here, possibly a **function pointer table** or something structural to the binary - Then you start seeing patterns like `0208????`, `0208????`. This could be a function prologue, or how instructions begin in their encoding. This is a very strong indicator that this is a **well-formed image** - Then we go to the very bottom of the image and see those **FF patterns** — marking the end of a flash image, because in flash, the positions where you'd expect zeros are actually high FFs ## What This Means If some of you didn't follow along, that's fine. The purpose of this video isn't to teach you how to do reverse engineering, nor to walk you through my thought process. The purpose of this video is to show you: **the ability to deobfuscate, tear apart poorly designed things, and find the problems within them has now been commoditized. This is something anyone can do.** You might ask: what's the actual problem here? If the purpose of this encryption is to protect Dell's intellectual property, then handing the encryption method directly to the end user is an **inherent design flaw**. If you were going to do this properly, the approach would be: the flash file from the actual end user is encrypted at rest, and it's flashed to a location in the motherboard firmware. Then from the motherboard or microcontroller's perspective — a key is fused into ROM, one you cannot extract from that MCU — and decryption is performed on the motherboard using that key. The way it's currently done is fundamentally flawed. And any skilled reverse engineer can pull this off in a few days, maybe a week, maybe less. Maybe I'm exhibiting a skill issue here — some people might be able to do this in just one or two days. ## Conclusion GLM5.3 did this in **15 minutes**, and by my best assessment, the results look correct. What does this mean for security as a whole? **More bugs. Anyone can do reverse engineering. Anyone can find vulnerabilities.** That's it. Thanks for watching. Source: Watch as a vulnerability cybersecurity expert with 10 years of experience in the field becomes astonished by the reverse engineering powers of... GLM 5.3 (https://youtu.be/wIe3eDfGKUo)