PHP2Shell: From Source Code and Memory Analysis to a Working Exploit

ariane djad — Sun, 08 Nov 2026 10:39:11 +0000

When the PHP vulnerabilities were first announced, I spent a HUGE amount of time trying to figure out the logic behind them.

As many others who tried investigating them probably noticed, there was barely any technical information available at the time. We had a few basic hints: something related to PHP_SESSION_UPLOAD_PROGRESS, some kind of Out of Memory condition, and, of course, that video Calif published showing a dancing girl with a shell running the exploit in the background. 😂

I found that pretty funny, especially considering the scale of the vulnerabilities and how many servers around the world could potentially be affected. Anyway, that was pretty much all we had to work with!

Even AI assistants weren't particularly helpful. At the time, they were heavily restricted when it came to this subject. A simple technical question about an internal PHP function could get flagged just because you mentioned PHP and something technical in the same sentence. For those of us without access to a more cybersecurity-focused model, even asking basic questions and using AI to help investigate things was practically impossible.

So I started digging into the PHP codebase myself (I was honestly getting a little mentally insane by that point).

I spent countless hours going through the source code, tracing functions, setting up experiments, debugging, and trying to understand exactly what was happening behind the scenes. There were long days and endless nights spent following one thing after another, trying to connect all the pieces until things finally started making sense.

The more I investigated, the more I realized that I wanted to put everything together somewhere. Not just the final explanation, but the entire process: the PHP internals behind the vulnerabilities, what's happening in memory, why certain things happen the way they do, and how all of this eventually leads to a working exploit.

That's how this research project started.

I structured the write-up to start from the basics and gradually build up to the actual exploitation. Each part builds on what came before, with the explanations becoming progressively more technical until we get to the real thing. I wanted someone with little or no experience in low-level memory exploitation to be able to follow along and understand how all the pieces fit together.

The write-up also goes through the actual exploit code used to solve the "Steal My Bitcoin" challenge, breaking it down step by step rather than simply showing the final result.

Everything is based on my own research, local experiments, and understanding of the PHP engine. I'm not claiming this is an official analysis or that everything is necessarily correct. I'm still learning, and there might be mistakes or things I've misunderstood.

And honestly, I was getting tired of explanations that only scratched the surface without actually showing what was happening internally. I wanted to do something different: a proper, in-depth technical walkthrough covering the entire process, examining the important details and explaining not just WHAT happens, but WHY and HOW it happens.

You can read the full write-up here:

PHP2Shell: From Memory to C Internals to Real Exploit Code

And here's the GitHub repository, which also includes the project files and the backstory behind the research:

GitHub Repository

Understanding Text-block Metrics in Qt framework

ariane djad — Thu, 17 Jul 2025 23:00:16 +0000

Understanding Text‑Block Metrics in Qt

Text Block

A QTextBlock represents one “paragraph” or line of text in a QTextDocument.

blockBoundingRect()

Returns only the size (width & height) of that block , no positional information.

blockBoundingGeometry()

Returns the block’s full rectangle in the document’s coordinate system, giving both its size and its original position in the unscrolled document.

contentOffset()

Reports the current scroll translation of the viewport (how far the content has shifted).

Geometry + Offset → On‑Screen Position

By translating the block’s document‑coordinates rectangle by the content offset, you compute exactly where that block appears in the visible viewport—essential for drawing aligned overlays (e.g., line numbers, custom highlights).

Note: The black rectangle in the diagram represents the visible portion of the document. In reality, each QTextBlock may have a different width depending on its content; we’ve simplified it to a single rectangle here for clarity.

DEV Community: ariane djad