End of an era. Skype is finally shutting down for good.

What happens when you press that glowing blue call button? For most of Skype’s users—once numbering in the hundreds of millions—this question never crossed their minds. The magic just worked. A connection formed across continents, through firewalls, past corporate security systems, delivering crystal-clear encrypted communication when other technologies failed.

But for some of us, these black boxes of technology are irresistible puzzles begging to be solved.

The Man Behind the Keyboard

“What is it that you actually do?” It’s a question I’ve fielded countless times, even from family members, and one I can rarely answer completely.

Some of you may know me through my work on the Cicada 3301 puzzles in 2012—those cryptic internet mysteries that captivated the world’s brightest minds. Others might recognize me from my public-facing security research: speaking about kernel exploitation techniques at BlackHat and Defcon, presenting “Hacking the Hacker” at the RSA conference, or perhaps from my appearance in a Netflix documentary about the Ashley Madison hack, where I led the technical investigation.

My team and I have traveled the world competing in the finals of international hacking competitions—from Codegate in South Korea to DefCamp in Romania and Defcon in Las Vegas. I’ve turned down more speaking opportunities than I can remember.

But these public endeavors, as challenging as they might seem, have always been child’s play compared to the projects I’ve been involved with where matters of national security were at stake. That work—the truly thrilling work—remains largely classified, existing only as redacted sections in unseen reports.

The significance of this hidden work hasn’t gone unnoticed by adversaries. Just a few years ago, I became a target of North Korean state-sponsored hackers, not once but twice, during their coordinated campaigns against security researchers in late 2020 and again in 2021. Fortunately, both attempts proved futile.

What I’m about to share is a rare glimpse into this other world—the one that exists in the shadows of technology. Like Cicada 3301, this journey had many layers, twists, and turns. Unlike those puzzles, however, this challenge demanded far more technical ability and persistence, with real-world implications that extended far beyond intellectual curiosity.

For obvious reasons, many details must remain secret. But what follows is perhaps the closest answer I can provide to that persistent question: “What is it that you actually do?”

First Contact

In 2004, Skype was revolutionary: a communication system that seemed to defy the conventional rules of networking. It could establish connections between computers that shouldn’t have been able to reach each other, it promised encryption that nobody could break, and it guarded its secrets behind layers of sophisticated protection.

This used to be top-secret, but at this point I would assume it doesn’t really matter anymore. At least not when it comes to the technical aspects related to why I became very intimately familiar with Skype.

I initially started reverse-engineering Skype in 2004, slightly more than 20 years ago. They had a proprietary supposedly encrypted protocol, and they were using various techniques to make life significantly more difficult for anyone who wanted to take a peek inside.

What drew me to Skype wasn’t just technical curiosity. There was something almost defiant about how thoroughly they had locked their system down—as if issuing a challenge to those of us who believe that understanding how our technology works is a fundamental right. In a world increasingly built on closed systems, Skype represented a fortress of code that millions entrusted with their most private communications without knowing what was happening beneath the surface.

Every time I heard that distinctive Skype ringtone, I couldn’t help but wonder: what’s really happening behind that friendly interface? What mechanisms were at work, shuttling voices and messages across the digital expanse? And perhaps most importantly—was it as secure as everyone believed?

Little did I know that pulling on this thread would unravel a technological tapestry more intricate and ingenious than I had imagined. One that would consume countless hours over years of exploration, leading me deep into the heart of what was then the world’s most sophisticated peer-to-peer communication system.

This is the story of how I cracked open one of the internet’s most closely-guarded secrets, one assembly instruction at a time.

Breaking Through the First Layer

My first encounter with Skype’s internals felt like opening a Russian nesting doll. Each layer revealed another, more intricate challenge beneath.

As with most protected software, Skype’s exterior defenses came in the form of a custom “packer”—a program that compresses and encrypts the actual executable code, unfolding itself only at runtime. It’s digital camouflage, designed to thwart curious eyes like mine.

The packer used self-modifying code, a technique where the program literally rewrites parts of itself as it runs. It’s like a document that changes its contents the moment you try to read it—elegant but frustrating for someone trying to understand what lies beneath.

Fortunately, this first guardian had a weakness. By setting a hardware breakpoint—a special instruction that pauses execution at a precise moment without altering any code—I could wait patiently until the unpacking process completed. Once Skype had fully “unpacked” itself into memory, I could dump the now-decrypted code and data segments for analysis.

The digital vault had cracked open just enough to peer inside. I transferred the memory dump to IDA Pro, the industry-standard disassembler at the time. This was 2004, so I was looking at raw assembly code—the most fundamental language computers speak. No convenient translation to higher-level programming languages, no helpful abstractions. Just the bare instructions, cryptic and numerous.

What should have been a moment of triumph quickly gave way to a sobering realization. The clean, decrypted binary revealed selective but sophisticated obfuscation. While most of the code was “readable” with enough patience, certain critical sections—precisely the most interesting ones—were protected by layers of deliberate confusion.

The developers had employed techniques like opaque predicates and overlapping instructions that would cause linear disassemblers to fail, misinterpreting what was code and what was data. The hundreds of functions involved in cryptographic operations were particularly well-guarded, suggesting their importance.

Adding to the challenge was the nature of C++ itself—a maze of indirect calls, virtual function tables, and complex object hierarchies. Reconstructing which methods belonged to which classes, and what each field in their structures represented, required mapping countless execution paths through this deliberately confusing landscape.

This wasn’t just software; it was software designed by people who expected someone like me to come looking. And they had deliberately fortified the most valuable parts of their digital fortress.

As I scrolled through thousands of assembly instructions, the message became clear: the packer was merely the doorman. The real guardians of Skype’s secrets lay within, and they were watching my every move.

This was, however, only the beginning…

Down the Rabbit Hole

With Skype’s outer shell cracked, I ventured deeper into its digital labyrinth. What I discovered was a security system that didn’t just protect—it actively fought back.

Like any cautious explorer, I brought along my favorite tool: a debugger, software that lets you pause code execution and examine its state. But Skype had anticipated this approach. It was riddled with anti-debugging measures, digital tripwires designed to detect and thwart analysis tools.

Most of these countermeasures were standard fare in the world of software protection—annoying but manageable. But then I encountered something far more sophisticated: hundreds of obfuscated polymorphic integrity checks scattered throughout the code.

Imagine booby traps that not only detect when you’ve disturbed them but actively change their appearance after each encounter. These checks continuously verified that Skype’s code remained unaltered, performing checksums on different parts of the program. The moment I tried to modify anything—even temporarily placing a breakpoint—the program would crash spectacularly.

What made these integrity checks particularly devious was their design. When one triggered, it wouldn’t simply display an error message. Instead, the program would continue running with corrupted data, causing a crash elsewhere, far from the actual tampering point. The digital equivalent of a delayed-action mine.

Even more insidious: each check didn’t just verify code integrity—it used the checksum result as an actual value in subsequent operations. This meant I couldn’t simply disable the checks; I had to replace them with code that produced the exact expected values.

After discovering and patching one check, another would trigger. Then another. And another. Hundreds of these obfuscated polymorphic bastards were scattered throughout the code, and dealing with them one by one would be incredibly time-consuming. It was a classic Whack-a-Mole scenario, except each mole required surgical precision to handle.

I had to step up my game. Forget Whack-a-Mole—I was going to do this Pokémon style: Gotta catch ’em all!

I created a specialized tool—a minimal disassembler coupled with a tiny emulator—designed specifically to recognize and neutralize these checks. Instead of handling every possible CPU instruction, I carefully mapped out and implemented only the specific subset of instructions used in the integrity checks. By identifying the distinctive patterns of these instructions, I could automatically scan the entire code section, emulate each check to determine its expected output, and replace it with a simple instruction that provided the required value.

It was like creating a vaccine against Skype’s immune system, teaching it to accept my presence without triggering its defenses.

My tool worked beautifully. In one sweep, it neutralized hundreds of integrity checks, replacing complex verification code with simple value assignments. Not only could I now debug the program freely, but I could also inject my own code to observe and manipulate Skype’s inner workings.

What’s more, because I had kept the tool so focused and efficient, it was small enough to later be incorporated directly into exploit payloads for in-memory patching, not just for static binary modification.

The protective barriers had fallen, revealing the next level of the maze: Skype’s proprietary protocol and cryptographic system. Another mystery waiting to be unraveled.

The Art of Digital Archaeology

With Skype’s protections neutralized, the real archaeology began. Like an explorer uncovering an ancient civilization, I needed to piece together how this digital world functioned by examining its artifacts.

Modern reverse engineers have luxuries I didn’t have in 2004: sophisticated decompilers that transform machine code into readable programming languages. Back then, the process was far more manual—translating assembly instructions into higher-level concepts line by painstaking line, reconstructing complex data structures, and mapping out function relationships.

It’s like being handed a book written in a dead language where each word might represent an entire concept, and you need to reconstruct not just the text but the grammar and cultural context behind it.

A couple of years later, when the first version of the Hex-Rays decompiler was released for IDA Pro, I had the honor of being one of the pre-release beta testers. This was a game-changer for the reverse engineering community—suddenly what had taken days could be done in hours. I was absolutely thrilled—it was like being handed a Rosetta Stone after years of manual translation. But in 2004, such tools were still just a dream.

Standard tools weren’t going to cut it. I needed something tailored specifically for Skype’s peculiarities. So I built not one, but two custom Skype debuggers—one for Windows and another for Linux—tools designed to answer my specific questions while navigating Skype’s labyrinthine code.

My approach was methodical. First, I injected hooks into all of Skype’s internal logging functions—code that redirected these functions to my own code. This revealed messages that were never meant to be seen, debugging information the developers had left behind. The Linux version of Skype proved especially valuable, containing more verbose logging than its Windows counterpart.

These custom tools gave me unprecedented visibility. I could:

• Track function calls with inline trampoline hooks, redirecting them to my own code
• Manipulate parameters and return values to test hypotheses
• Intercept external library calls with LD_PRELOAD or IAT-patching techniques
• Set targeted breakpoints to examine or manipulate registers and memory contents at precise moments

Each time I extended my toolset, I gained new insights. Each insight led to new questions, which led to new tools, creating a virtuous cycle of discovery.

But this wasn’t just about watching the gears turn. My goal was comprehensive: to document the actual protocol Skype used, understand its cryptographic primitives, and ultimately interact with the Skype network independently.

As my understanding grew, so did my map of Skype’s internal structure. Function by function, data structure by data structure, I was reconstructing the blueprint of a system that had never been documented publicly. Each piece of the puzzle revealed more of the bigger picture: how Skype connected users across the internet, bypassed firewalls, and secured communications.

The techniques I was developing would prove particularly valuable at later stages of my investigation. For instance, I later found that scanning Skype’s memory heap for expanded AES keys—the cryptographic keys used for secure communications—was relatively straightforward due to their distinctive patterns. This would become crucial when I needed to intercept supposedly secure conversations.

I was no longer just peering through a keyhole—I was walking through the halls of Skype’s architecture, opening doors that were supposed to remain closed.

Breakthrough Moments

The deeper I ventured into Skype’s architecture, the more fascinating discoveries I made. Each breakthrough felt like solving a puzzle box that revealed another, more intricate puzzle inside.

One critical revelation came when I discovered how Skype encrypted its signaling layer—the traffic between users and supernodes, and between the supernodes themselves. Unlike the end-to-end encryption used for calls and messages, this layer used RC4, a streaming cipher with known weaknesses. More interesting still was how the RC4 keys were generated.

Rather than using a proper key exchange, Skype derived the keys through a deterministic yet heavily obfuscated algorithm. The process began with a 32-bit random seed sent by the receiving supernode. This seed was fed into hundreds of small, obscured functions that each performed various bitwise and arithmetic operations on a key buffer.

What made this particularly challenging was that the execution flow itself—which functions were called and in what order—depended on the value of the seed. This meant it wasn’t possible to simply create a flattened representation of the operations that would work for any seed. The algorithm’s path through these functions changed dynamically based on the input, creating a labyrinth where the walls themselves shifted with each new seed.

The complexity was daunting. While I did eventually reverse-engineer the entire algorithm—mapping every function and control flow path—this was a gradual and time-consuming process of careful analysis. But I didn’t need to wait for the complete picture to make meaningful progress. As I worked toward full understanding, I created what I called an “RC4-key oracle”—a service that would take a 32-bit seed as input and return the complete RC4 key by calling the actual key derivation function from the original Skype binary.

This oracle became the foundation for my next breakthrough: a custom plugin for Ethereal (now known as Wireshark), the network protocol analyzer. With my plugin, I could decrypt and analyze all signaling traffic on the Skype network in real-time. Suddenly, the invisible became visible.

When Ethereal changed its name to Wireshark in 2006, I maintained and updated my plugin accordingly. This wasn’t just a one-off tool—it became part of my analytical arsenal for years.

I later developed similar protocol dissectors for other investigations, including my work reverse-engineering RATs (Remote Access Trojans) that were being used in nation-state sponsored attacks against political and strategic targets. This work went beyond just understanding their protocols—I also identified vulnerabilities in these tools and developed exploits that allowed us to actually “hack the hackers,” turning their own tools against them. I presented findings from this work at the RSA conference in 2008 in my “Hacking the Hacker” talk, a couple of years after these attacks had taken place.

I still remember the first time I watched the decrypted Skype protocol appear in my custom Ethereal window. Messages that had once been gibberish transformed into structured data before my eyes. User lookups, connection requests, network topology information—all the mechanisms that made Skype’s supposedly impenetrable network function were now exposed.

Being able to read the protocol was just the beginning. The logical next step was to speak it myself. With my understanding of how Skype communicated, I developed standalone tools that could interact directly with the Skype network. One particularly useful capability this unlocked was the ability to look up any Skype user’s current IP address simply by knowing their username. This had meaningful implications—it could potentially be used to track a person’s location or explore attack vectors unrelated to Skype in their network environment.

Each discovery built upon the last. What began as a focused technical investigation evolved into something more sobering: a recognition that this communication system trusted by millions contained exploitable vulnerabilities. Not just theoretical weaknesses, but practical attack vectors that could be leveraged by someone with enough knowledge and determination.

A key moment was the discovery of memory corruption vulnerabilities in the signaling layer. These weren’t just bugs—they were potential gateways for remote code execution. With enough effort, an attacker could take complete control of a Skype client without the user ever knowing.

A challenging and necessary step was figuring out how to exploit these vulnerabilities without crashing the Skype client. This required delicate memory manipulation—cleaning up after the exploit and reconstructing whatever had been overwritten so that the program could continue running as if nothing had happened.

When I finally succeeded, the implications were clear and unsettling. This capability could bypass any perimeter defense, gain access to a user’s computer, and maintain that access without detection. All through an encrypted channel that no security system could inspect.

This was no longer just reverse engineering. This was the discovery of a digital skeleton key.

Hidden Patterns Revealed

As my map of Skype’s internal architecture became more complete, I began to understand not just how it worked, but why it was designed this way—and what that meant for millions of users worldwide.

The brilliance of Skype’s original network design was its true peer-to-peer nature. What appeared to users as a simple messaging application was actually a sophisticated distributed system. Any Skype client could be silently promoted to a “supernode” if it had a public IP address and sufficient bandwidth. These supernodes formed the backbone of the network—interconnected relay points that handled user lookups and managed connections between regular clients.

This architecture solved a fundamental challenge of internet communication. When two users wanted to connect, even if they were behind corporate firewalls or complex NAT setups, Skype could almost always establish a connection. If direct paths weren’t available, traffic would be relayed through these supernodes, creating virtual tunnels through the internet’s obstacles.

The system was elegant, resilient, and almost entirely invisible to users. You never knew if your Skype client had become a supernode, silently routing strangers’ connection attempts. You never knew if your calls traveled directly to your friend or were bounced through someone else’s computer halfway around the world.

Skype’s creators maintained a fleet of their own supernodes to ensure network capacity, but these were technically identical to user-operated supernodes. This decentralization made the system remarkably resistant to outages or attacks—there was no single point of failure.

But this architecture had profound implications that most users never considered.

First, while all message and call content was encrypted end-to-end using AES, the network’s design created natural surveillance points. Any computer serving as a supernode could observe connection patterns and metadata—who was talking to whom, when, and for how long.

When Microsoft acquired Skype in 2012, they fundamentally altered this architecture. Regular clients could no longer become supernodes; instead, Microsoft-controlled servers took over all relay and lookup functions. This centralization meant that one entity now controlled the entire network’s topology and could monitor all connection patterns.

For users concerned with privacy, this was a significant shift. While content remained encrypted, Microsoft now had the technical capability to observe all connection metadata. And if they chose to, they could ensure that traffic to or from specific users was always routed through their servers.

The same architectural features that made Skype so effective—its ability to establish connections where other applications failed, its encrypted channels that bypassed firewalls—also made it an ideal vector for targeted attacks.

By deploying modified supernode clients, an attacker could position themselves in the Skype network to intercept connections. By exploiting vulnerabilities in the signaling layer, they could compromise a target’s client without their knowledge. And by extracting session keys, they could silently monitor supposedly private communications.

As so many times before, this served as a clear example of an uncomfortable truth: the wide gap between security perception and reality. Millions of users trusted Skype with their most sensitive communications, believing in the privacy promises of encryption, never suspecting that the system’s very architecture created points of vulnerability that could be exploited by those with sufficient technical knowledge.

The system wasn’t broken—it was working exactly as designed. But that design, once fully understood, revealed trade-offs between convenience and security that users were never informed about. The black box, once opened, contained surprises that raised serious questions about digital privacy and trust.

Reflections

Twenty years have passed since I first began unraveling Skype’s mysteries. In that time, we’ve witnessed remarkable transformations in how we communicate. Skype itself evolved from a revolutionary peer-to-peer system to just another corporate-controlled messaging platform, before finally fading into obsolescence.

The journey I’ve described represents countless hours of meticulous work—hours spent staring at assembly instructions, crafting custom tools, testing hypotheses, and gradually piecing together the puzzle. What began as technical curiosity evolved into something more profound: a window into the complex relationship between technology, privacy, and power.

For me, this exploration revealed a fundamental truth about our digital world: the systems we trust most are often the ones we understand least. We place our most intimate conversations into black boxes, trusting labels like “encrypted” and “secure” without questioning what those claims really mean in practice.

Skype’s original architecture was brilliantly designed for resilience and connectivity, but this same design inadvertently created vectors for surveillance and attack. The very features that made it revolutionary—its ability to traverse firewalls, its encrypted channels, its distributed nature—could be weaponized against its users by those with sufficient knowledge and resources.

This duality exists in almost all technology. The same encryption that protects journalists and dissidents also shields criminal communications. The same vulnerabilities that enable legitimate security research can be exploited for surveillance or sabotage. The same knowledge that empowers can also endanger.

I’ve always believed strongly in each individual’s right to privacy. I oppose mass surveillance in all its forms, especially government-mandated backdoors which inevitably weaken security for everyone. Yet I also recognize that we live in a complex world where blanket principles sometimes collide with urgent realities. There are moments when targeted access to communications might prevent immense harm.

The capabilities I developed while reverse-engineering Skype could have been used in different ways. They could have enabled widespread privacy violations if deployed at scale. They could have compromised the security of countless users. But they could also have been used with surgical precision to access the communications of those planning to cause harm, potentially saving lives.

To anyone working in offensive security, especially those developing capabilities for nation-states, I offer this reflection: Choose your clients carefully. The knowledge you gain and the tools you build carry enormous power—power to protect or to compromise, to defend or to exploit. This power comes with corresponding responsibility.

As Skype finally shuts down for good, I’m left with a sense of nostalgia for those early days of discovery. There was something pure about the challenge of understanding a system that didn’t want to be understood, of mapping terrain that no outsider had ever documented. It was a form of exploration that has become increasingly rare in our world of open-source software and detailed documentation.

Yet I also feel hope. Each generation of technology brings new challenges and opportunities. The lessons learned from Skype’s architecture have influenced how we design secure communication systems today. The vulnerabilities discovered have been addressed in newer protocols. And the critical questions raised—about transparency, trust, and the balance between security and convenience—continue to shape our evolving digital landscape.

In the end, perhaps the most valuable outcome of this journey wasn’t the technical knowledge gained, but the perspective it offered: a deeper appreciation for what lies beneath the surfaces of our digital world, and a heightened awareness of both the wonder and the warning those depths contain.