In May 1997, Garry Kasparov (the greatest chess player in history) sat down against an updated version of Deep Blue - a monster capable of analyzing 200 million positions per second. A year earlier, Kasparov had defeated the machine, and now the IBM team was desperate for a rematch, constantly tweaking both hardware and software

In the first game, Kasparov was dominating. He methodically pushed the computer into a losing position. The machine was desperately searching through millions of variations to find a way out, but its algorithms were hitting a dead end. Then, on Move 44, when everyone expected a logical defense, Deep Blue made a completely nonsensical move with its rook. It offered no positional advantage or tactical gain, breaking every known pattern of computer play

Kasparov was stunned. His brain, trained to find hidden meaning in every move, tried to decode the machine’s “plan”. He concluded that the supercomputer had calculated 20 moves ahead and found a trap too deep for a human to see. Although Kasparov eventually won that first game, his confidence was shattered. He spent the entire night with his team trying to decipher that mysterious move, exhausting himself physically and mentally

In reality, there was no brilliant plan. During the calculation of the 44th move, the evaluation algorithm encountered an unexpected error. To prevent a total system crash or a “silent failure”, IBM developers had implemented a safety mechanism. Unable to select the “best” move due to a software deadlock, the machine triggered a fallback function - it simply picked a move at random. Kasparov, haunted by this “alien intelligence” made an unprecedented blunder in Game 2 and eventually lost the match. He remained convinced IBM had cheated until the computer was dismantled

# just a pseudo-code, I cannot find an original code on c lang
def calculate_best_move(board_state, depth, time_limit):
    legal_moves = get_legal_moves(board_state)
    best_move = None
    max_score = -INFINITY
    
    try:
        # The algorithm processes 200 million positions per second
        for move in legal_moves:
            # If the engine hangs or hits a time limit, the system throws an exception
            check_engine_health(time_limit)
            
            score = minimax_eval(board_state, move, depth)

            if score > max_score:
                max_score = score
                best_move = move
                
        return best_move
        
    # THIS IS THE BUG: Instead of a logical fallback or a partial evaluation,
    # a primitive "safety" mechanism triggers to save the system from crashing
    except EvaluationException:        
        # The computer picks a COMPLETELY RANDOM legal move
        # This is exactly what Kasparov mistook for a deep, non-human strategy
        return random.choice(legal_moves)

LESSONS LEARNED BY THE TECH INDUSTRY

1. Fail-Safe mechanisms must be meaningful: A fallback should not drastically change the system’s core logic in production. Choosing a random value to avoid a crash is a poor design pattern that leads to unpredictable behavior

2. Explainable AI and Transparency: If a system makes a decision, engineers must be able to explain why. The lack of proper logging in Deep Blue (why it picked that specific move) fueled conspiracy theories and a major PR scandal

3. Handle Exceptions in Edge Cases: The algorithm failed only in a critically complex, non-standard position. All mission-critical software must be stress-tested (Chaos Engineering) to understand its behavior at the limits of its computational power

TIMELINE OF EVENTS (OR “DAMAGE IN NUMBERS”)

• May 1997: The historic rematch between Garry Kasparov and IBM’s Deep Blue

• May 3, 1997 (Game 1, Move 44): The evaluation algorithm fails and picks a random rook move, triggering paranoia in the World Champion

• May 4, 1997: IBM engineers frantically patch the code the next day, just before Game 2 begins

• 200 Million: The number of positions Deep Blue could calculate every single second

• May 11, 1997 (Game 6): Exhausted and suspicious of fraud, Kasparov resigns after only 19 moves, cementing this bug in history

And just to try some new (?) features - added the AI video here:

And I’ve built a demo right now:

1. Offline documents recognition for your projects (it does not work well, but it works)

2. Sensitive Data Validator - prevents sharing any sensitive info from customers before they send it (useful for forums or chats)

To my surprise - it’s possible to call AI that is built in Chrome, locally and it is very fast (considering that my M1 chip is almost 6 years old 🤪)

So, it is available now only after turning on some feature flags in Chrome that is why without links - just a video demo

Read more: developer.chrome.com/docs/ai/prompt-api & developer.chrome.com/docs/ai/built-in

Great repo for other cases: github.com/GoogleChromeLabs/web-ai-demos

If you are ready for experiments - https://chrome-ai.secmy.app/

Let’s remember some historical examples:

• Colonial Pipeline (2021) - this attack paralyzed fuel supplies in the US. Just because hackers used an old VPN account that did not have two-factor authentication (2FA). They found the password in an old leaked database

• 23andMe (2023) - genetic data of millions was leaked. Again - «credential stuffing». Hackers did not break the system directly; they just used old passwords that users had reused from other sites. No 2FA made it easy

• Uber (2016) - data of 57 million users was stolen. The reason: developers were careless and stored login details right inside the code on GitHub

• Marriott / Starwood (2014-2022) - this case is now in cybersecurity textbooks as a classic «silent» breach. Hackers entered the network in 2014 and stayed there for four years, even after Marriott bought the company. 500 million records were leaked because there was no 2FA on admin accounts

Common Mistakes Today

• Using personal passwords for work - if your old email or game account is hacked, your entire company is at risk. Your work account is definitely in danger

• Storing passwords in messengers - “Saved Messages” or “Favorites” are not safe if someone hijacks your session or steals your browser cookies (I call it “messenger os passwords”)

• Using the same password everywhere - this creates a domino effect for all your accounts

• Saving passwords in notes or text files - modern viruses find and steal these files in seconds

Three Steps to Safety

1. Switch to Passkeys (login with face or fingerprint) - it is faster and safer than regular passwords because they cannot be stolen by phishing

2. Turn on 2FA everywhere - a hacker cannot enter your account without a code from your app, even if they know your password

3. Use phrases instead of words - a long phrase made of random words (like «dog-likes-blue-tractor-2026») is much harder to crack than a short word with special characters

And go to Have I Been Pwned, check your email, and change your password for at least one important account - like your bank or main email

Security is a journey, not a destination. Start it right now ;)

Spoiler: On the very first random site I tested, I found everything needed for a full compromise

In reality, things are usually much more complicated: WAFs, tricky routes, and obfuscation can make life difficult. But for a quick demo of what automated “on-the-fly” source code analysis can do, this method is perfect

I put together a small Bash script that combines simple Katana crawling, lightning-fast secret searching via Betterleaks, and Gemini AI for analysis. Just three tools and a little bit of time

The script does something very simple: it downloads everything it can reach, scans it for secrets, finds configuration files, and feeds this mix to the AI with one question: “How do I hack this?” ⬇️

# it's a shorten demo, in reality I had a huge more lines
# so - you have to create your own ;) 
TARGET=${1:-"[https://example.com/](https://example.com/)"}
OUTPUT_DIR="recon_results"
mkdir -p $OUTPUT_DIR

# 1. Deep Crawling (collecting everything: JS, API, configs)
echo "[+] 1/4 Starting Katana..."
katana -u $TARGET -rate-limit 5 -d 1 -cs "$(echo $TARGET | sed -e 's|^[^/]*//||' -e 's|/.*$||')" \
    -ef png,jpg,jpeg,gif,svg,woff,ttf,css \
    -mdc "status_code == 200" \
    -fs fqdn -o $OUTPUT_DIR/clean_urls.txt -sr -srd $OUTPUT_DIR/responses

# 2. Secret Hunting via Betterleaks
echo "[+] 2/4 Starting Betterleaks..."
betterleaks dir $OUTPUT_DIR/responses --report-path $OUTPUT_DIR/betterleaks_report.json > /dev/null 2>&1

# 3. Analysis via Gemini AI
# Feed the report directly to the "brains"
if command -v gemini &> /dev/null; then
    gemini "Analyze this Betterleaks report and find high-impact attack vectors"
fi

From Script to Product: Recon-1

While the script worked, I realized that digging through text files is still “the old way”. I wanted something that visualizes the attack surface instantly. That’s how Recon-1 was born - a wrapper that turns raw scanner output into a tactical dashboard

It takes the same logic - crawling, secret extraction, and AI processing - but presents it in a way that allows you to see the “skeleton” of the target app. You can watch the AI analyze found tokens and map out routes in real-time, moving from a URL to a ready-to-use exploit plan in a single window

10 Minutes later…

I ran this workflow on the first large e-commerce project I found. While I was making coffee (about 10 minutes of crawling and analysis), the AI generated a report that would make any CISO’s eye twitch

• Admin Access in 0 Seconds: In one of the React bundles, the script found a hardcoded ADMIN_TOKEN. The AI immediately suggested: “Use it for requests to /rest/V1/orders.” The mere fact that such a token exists in public JS is a game over

• Infrastructure on a Silver Platter: A Google Cloud (GCP) API key was found. AI identified the key as for Google Maps, but it was actually for Firebase

• Route Map: The AI suggested that a full structure of hidden paths could be extracted from Next.js manifests. This immediately highlighted interesting endpoints like /admin, /staging, or /test that weren’t visible on the main page

• Encryption and Logic: The script pulled an ENCRYPTED_KEY. The AI analyzed neighboring functions in the code and explained exactly how the application encrypts user data on the client side

This experiment shows: the era of manual reconnaissance is over

Previously, I would have spent an entire evening connecting these findings together. Now, it took me half an hour to write the script, and a few more to polish it into a tool like Recon-1. Now I get a ready-to-use attack strategy in minutes

AI doesn’t replace the hacker, but it makes their work frighteningly efficient. It removes the noise and leaves the pure essence: the vulnerability and the vector. If you’re still grepping logs by hand - you’re just wasting your life

How to defend against this? It’s simple: don’t leave real data and keys in public access. You can also slow down these “smart” bots by adding dynamic junk secrets to your code. When an AI agent gets ten similar but useless keys for every real one, it forces the attacker to spend much more time on verification, turning a quick hack into an endless routine

P.S. All found bugs were not exploited (and will be reported). Don’t be a villain - use AI for good

P.P.S. I’ve been wanting to test Cloudflare Containers for a while - how they function, how to integrate them with an app, and how to set up monitoring. I was searching for the right project, and this gave me a perfect excuse to dive back into Golang. I’m beyond satisfied - it feels like a tool made by people for people

It all started with a small component - the Guest Agent, which runs inside every virtual machine. To communicate safely with the cloud, the agent needs a valid security certificate. The programmer who wrote the update logic decided that the certificate should last exactly one year. Instead of using built-in language methods, they decided to build the date manually by adding one to the current year

In C#, it looked like this - the “billion-dollar line” of code that the media later mocked as “the most expensive arithmetic error in cloud history”:

var now = DateTime.UtcNow;

var certExpiry = new DateTime(now.Year + 1, now.Month, now.Day); 

// When February 29, 2012 arrived, the code tried to create 02/29/2013
// The new DateTime threw an ArgumentOutOfRangeException because 2013 is not a leap year

This exception caused the agent to crash immediately. But the real disaster was caused by the cloud’s “care” - the Fabric Controller. Seeing that a VM agent was not responding, the controller decided the physical server or VM was broken. It marked them as “bad” and tried to move the workload to other healthy nodes. But as soon as a VM started in a new place, it tried to create a certificate, crashed again, and triggered another panic. A domino effect began: healthy servers were shutting down one by one, trying to escape the “date virus”

The irony is that the fix made it worse. When Microsoft engineers finally identified the bug, they rushed out a patch. However, the update package included a network plugin that was incompatible with the existing infrastructure. This triggered a second major service disruption, proving that in a crisis, a hurried “fix” can be as dangerous as the bug itself

This incident is a classic example of how time can be a Single Point of Failure (SPOF) in IT. We saw this in 2008 with Zune players that froze on December 31 because of a bad leap year loop. We saw the “ApocalyPS3” in 2010, when millions of PlayStation 3 consoles crashed because they incorrectly thought 2010 was a leap year. And then there is the leap second - in 2017, Cloudflare stumbled over it when their DNS resolvers panicked while trying to calculate negative time. Adding just one second to a day can take down an internet giant as effectively as a leap day

Microsoft engineers fought the outage for nearly 24 hours in total. They had to manually fix the Guest Agent and deploy the patch to millions of machines while the cloud was in chaos. In the end, the company gave a 33% credit to all customers for that month. It was the most expensive lesson in geography and calendars in the company’s history. It turns out that even if you are Microsoft, you cannot ignore the rules set by Julius Caesar and Pope Gregory XIII

Lessons for those writing code today:

• Never manipulate date parts manually. If your language has an .AddYears(1) method - use it. It knows how to turn February 29 into February 28

• Failures in distributed systems are often made worse by self-healing mechanisms. Your protection can become your executioner if it doesn’t understand the nature of the error

• Edge case testing must include the calendar. February 29, timezone changes, daylight saving, and even leap seconds - these are not anomalies, they are inevitable

• A transparent post-mortem is the best way to regain trust. Microsoft admitted that their tests simply did not check year increments specifically on a leap day

AI-Valid helps developers and business owners understand if AI can “see” and interact with their website effectively. If a site is poorly structured, lacks machine-readable manifests, or is blocked for bots, AI assistants (like ChatGPT, Claude, or Perplexity) cannot extract data correctly or recommend your services to users in their responses

The tool performs a deep, parallel scan of several key architectural areas:

• Bot accessibility - it checks your robots.txt file for specific permissions for AI crawlers like GPTBot or OAI-SearchBot to see if you are accidentally blocking the future of search

• Content optimization - it looks for Content Negotiation support (providing raw Markdown instead of heavy HTML) and Content-Signal headers that manage data usage rights for training models

• Modern protocols - the scanner looks for specialized manifests in the /.well-known folder, such as MCP (Model Context Protocol), API Catalogs (RFC 9727), Agent Skills, and Agent Cards

The best part is that this tool is completely free. It is a great way to perform technical reconnaissance on your website without any costs or complex setup. Besides scores and status codes, AI-Valid has great educational value. It helps you learn about new, emerging standards like llms.txt that are just starting to define how machines read the internet

The simple, terminal-inspired dashboard separates results into “Passed”, “Warnings”, and “Action Required”. This provides a clear implementation roadmap to upgrade your website and turn it into a high-performance platform that is friendly to the autonomous agents of the future

A quick correction: what this law is actually about. There is a common mistake that Moore’s Law predicts a growth in computer speed or performance. This is not true. Moore wrote specifically about the density of components (transistors, resistors, diodes) on a single chip. In his 1965 article, he found a formula for the perfect price: engineers learned how to fit twice as many parts on a chip so that the cost of each part would drop. It is a matter of economics, not a law of physics or a guarantee that Windows will load faster

In the original article, he predicted that complexity would double every year. He stated that by 1975, it would be possible to put 65,000 components on a single chip. Ten years later, Moore changed the forecast to “doubling every two years.” The popular “18 months” figure actually came from his Intel colleague David House, who was trying to measure pure performance. But Moore himself always counted components - basically, transistors

A prophet we actually got. It is amazing that in 1965, Moore predicted home computers, portable communication devices (mobile phones), and even automatic controls for cars. He even mentioned electronic wristwatches, noting that “they only need a display” to become real. He saw our modern world 60 years before it arrived, though he probably did not expect all this power to be used for endless scrolling

The fact that your processor has twice as many transistors does not mean that Excel will calculate twice as fast. Today, billions of extra components are often used for background processes, graphics, or AI cores. Sometimes their power is simply “eaten” by bad code optimization, because unfortunately modern programmers write code without worrying about making it work as efficiently as possible

Your smartphone is now millions of times more powerful than all NASA computers in 1969 combined. The computing power that sent humans to the Moon would not even run a simple mobile game today. (And this power is mostly used for games and social media pictures)

Moore’s Law gives us billions of new transistors, but it cannot fix heavy software. It does not apply to the speed of Slack or how much memory Chrome uses. Moore promised us hardware density, but he did not promise that programmers would stop writing “heavy” code. No matter how powerful the hardware is, Chrome will find a way to slow it down, and Slack will still lag at the worst moment

Is Moore’s Law still alive today? Physically, we have almost reached the limit: transistors are now the size of just a few atoms, and making them smaller is nearly impossible. But the law is not dead, it is mutating. The number of physical components on a single chip is still growing - top chips already have over 100 billion transistors. It is important to understand: Moore’s Law is a story about local hardware and density on one chip. Today, engineers build “skyscrapers” (3D-stacking) and create specialized chips for specific tasks, which allows the law to keep going, even if the cost is very high

And just for fun the image from an AI, I like the result:

But imagine a situation where a software error directly controls a radiation gun. Between 1985 and 1987, due to systemic flaws in the Therac-25 radiation therapy machine, six patients received massive overdoses. Three of them died from severe radiation burns

This is not just a story about bad code. It is a story about human overconfidence, poor interface design, and why a physical switch is sometimes more reliable than a thousand lines of “perfect” code

In the early 80s, a Canadian company called AECL decided to build a cutting-edge medical machine. Before this, they worked with the French company CGR on older models, but they developed the Therac-25 entirely on their own. It was a powerful device based on the PDP-11 computer that could treat cancer in two ways:

• A weak electron beam for skin cancer

• A powerful X-ray beam for deep tissues

To create X-rays, the machine fired a high-power electron beam into a tungsten shield. This shield absorbed the deadly electrons and turned them into medical X-rays

In the previous model (Therac-20), there was “hardware logic” between the powerful beam and the patient - physical interlocks. If the tungsten shield was not in place, the electrical circuit simply would not close. It was like a microwave that won’t start until you close the door

But with the Therac-25, engineers decided to save space and money. They thought: why do we need bulky mechanical locks if we have a modern computer? Let the software handle safety instead

The machine easily got FDA approval. AECL claimed that the Therac-25 was “substantially equivalent” to previous models, so no independent safety audit was done. Engineers simply copied code written in assembly from an older machine. They did not know that this code had hidden bugs for years, which were previously blocked by physical safety switches

Anatomy of Bug #1: The Race Condition

The first problem was a parallel programming error known as a “race condition”. This happens when two parts of a program try to do their work at the same time and mix up the data

Imagine an experienced operator setting up the machine. They accidentally type X (powerful X-ray), but quickly notice the mistake, hit the up arrow, and change it to E (electrons)

At that moment, the computer does the following:

1. The first part of the program sees X and tells the hardware to move the tungsten shield. This physical process takes 8 seconds

2. The operator types very fast and changes X to E in less than a second

3. The UI program instantly changes the screen text to “Electron Mode (Safe)”

4. But because there is no proper synchronization, the background setup process still thinks a high-power shot is needed, even though the shield is being moved out of the way

The screen says everything is safe. But the machine is set to full power with no protective shield in place. Patients received 16,000 to 25,000 rads of radiation (when the normal dose is around 200 rads)

Here is how it looks in simple logic (pseudocode):

Power = 0
Shield_Is_In_Place = False

Handle_UI_Input():
    User_Input = Get_Input()
    
    If User_Input == "X":    // X-ray
        Power = 100_PERCENT

    If User_Input == "E":    // Electrons
        Power = 1_PERCENT

    // ERROR: The screen is updated
    //        but we didn't wait for the hardware!
    Update_Screen(User_Input)

Setup_Hardware_Task():
    If Power == 100_PERCENT:
        Start_Moving_Shield() // It takes 8 seconds!
        Shield_Is_In_Place = True
        
    // If the operator changes the mode during 8 seconds...
    //    the hardware breaks:
    //    the program keeps Power = 100%,
    //                  but Shield_Is_In_Place = False
    
    If Power == 100_PERCENT And Shield_Is_In_Place == False:
        Show_Error("Malfunction 54. TREAT PAUSE")
        
        // THE INTERFACE BUG:
        Wait_For_Operator_Response()

        If Operator_Presses("P"): // P for Proceed
            Override_Lock()
            Fire_Beam() // Fatal shot with no shield
    Else:
        Fire_Beam()

Anatomy of Bug #2: The Overflow Error

According to reports, the Therac-25 had many issues. In Yakima, Washington, a patient died because of a completely different bug. There was a counter variable in the code that increased by one during safety checks

The variable size was only 1 byte. This means its maximum value was 255. If you add 1 to 255, the variable resets to zero (an overflow). Exactly every 256th check, the computer thought the counter was zero. In the program’s logic, zero meant “ready to fire”. If the operator hit the “Start” button at that exact millisecond, the machine would fire, bypassing all other safety checks

Bad UX as an Accomplice

When the system noticed a data conflict, it did not lock the machine with a loud alarm and a “DANGER” message. Instead, a cryptic message appeared at the bottom of the screen: Malfunction 54. Nobody knew what this meant - it wasn’t even in the manual

Medical machines at the time often showed small sensor errors. Furthermore, during a Malfunction 54, the Therac-25 screen said TREAT PAUSE and helpfully suggested the operator press P (Proceed) to continue

The operator, behind a concrete wall, would press P. The patient in the room received a massive radiation strike and screamed in pain. The operator looked at the screen, saw that “no dose was delivered” according to the computer, and... pressed P again

Lessons for the IT Industry

The Therac-25 disaster became the foundation for modern safety standards. Here are the main takeaways for engineers:

• Keep hardware interlocks
  Software always has bugs. If lives are at stake, code should not be the only line of defense - a physical switch is more reliable

• Blindly reusing code is dangerous
  Bugs from old models can appear in new architectures. Something that “worked for 10 years” can kill when the environment changes slightly

• Sync your threads carefully
  The UI should never report success until the hardware gives a firm confirmation. Race conditions do not forgive mistakes

• Good UX is a safety feature
  Deadly failures should not be hidden behind codes like Malfunction 54. The system must explain the threat clearly and not let users ignore it with one button

• Listen to users, not just logs
  The creators of the Therac-25 claimed for a long time that an overdose was “mathematically impossible,” ignoring real injuries. Never ignore incidents just because they don’t match your specifications

Some other similar examples:

Almost all quantum magic was born in Europe. The most important events took place in the old offices of Berlin, Copenhagen, and Brussels

• Berlin, 1900: Max Planck introduced the concept of the “quantum”. He did it out of desperation while trying to solve a radiation problem and could hardly believe his own discovery

• Copenhagen, 1920s: Niels Bohr created his famous interpretation here. Modern physics was born in the debates between Bohr and Einstein (who famously said “God does not play dice”)

• Brussels, 1927: The Fifth Solvay Conference became legendary. A single photo captured 29 geniuses, including Einstein, Curie, and Planck. It was a true “Avengers” meeting for scientists where they decided how reality actually works

Fun facts about “strange” physics

• Schrödinger came up with the cat experiment to show how absurd quantum mechanics is in the macro world. He didn’t want to hurt animals - he was just making fun of his colleagues’ ideas 😼

• Einstein called quantum entanglement “spooky action at a distance”. It annoyed him because it broke classical logic. It is like socks: if you put one on your right foot, its pair instantly becomes “left” even if it is on Alpha Centauri

• Quantum computers promise to break any encryption, but for now they mostly just consume electricity and require cooling down to -273°C (colder than deep space)

Real security risks

Quantum machines are dangerous because of specific algorithms that hit the weakest spots of modern cryptography

• The death of RSA and ECC: Shor’s algorithm allows a quantum computer to break asymmetric encryption. This primarily threatens systems that don’t get regular updates - in such cases, HTTPS, bank transfers, and blockchain signatures will become useless

• HNDL Strategy (Harvest Now, Decrypt Later): This is the biggest threat today. Attackers record encrypted traffic and collect database leaks or backups. Right now, these gigabytes of data are just useless digital trash. But when a powerful quantum computer appears, these “dead” archives will suddenly come to life and become dangerous. Hackers are just waiting for their time in 5-10 years

• Symmetric encryption (AES): The situation here is better. Grover’s algorithm speeds up brute-forcing, but you can stay safe simply by switching from AES-128 to AES-256

Regulators and deadlines

The European Union Agency for Cybersecurity (ENISA) and regulators like NIST (USA) have already set the standards for Post-Quantum Cryptography (PQC)

• ML-KEM (FIPS 203): The new standard for key exchange (formerly Kyber)

• ML-DSA (FIPS 204): The main standard for digital signatures (formerly Dilithium)

• 2025-2027: Start of mandatory PQC support in new government systems in the USA and EU

• 2030: Deadline for switching software and firmware signature systems

• 2035: Full retirement of RSA and ECC in European critical infrastructure and transition to CNSA 2.0

Baseline requirements for protection

Check your infrastructure against these minimum requirements to keep your data safe

• AES-256: move all symmetric encryption to 256-bit - this is the base that Grover’s algorithm cannot easily break

• RSA 3072 or Ed25519: stop using 2048-bit keys - anything below 3072 bits is considered vulnerable in the long run

• TLS 1.3: use only the latest version of the protocol - it supports hybrid key exchange and adapts better to quantum standards

• Total patching: quantum threats are worst for systems that haven’t been updated for years - make sure your libraries (OpenSSL, BoringSSL) are always on the latest versions

• Crypto-Agility: use standard libraries and don’t hardcode specific algorithms - this will allow you to change them via a config file in the future

Where to try quantum computing online (I have tried 3)

If you want to go beyond theory, there are several platforms with access to real hardware or powerful simulators

• Google Colab: the best place to start running Python code (like Qiskit) right in your browser without installing anything

• Quantum Computing Playground: perfect for simple 3D visualization of quantum states directly in the browser

• IBM Quantum Platform: the most popular option - they offer free access to 127-qubit processors and a great visual drag-and-drop tool (IBM Quantum Composer)

• Azure Quantum: Microsoft’s platform where you can try hardware from partners like IonQ or Rigetti - there are free credits for learning

• Amazon Braket: an AWS cloud service for testing different quantum architectures - good for serious experiments

Real World Example: True Random Number Generator

Classical computers use math formulas to create “pseudo-random” numbers. If you know the formula and the starting point (seed), you can predict the result. A quantum algorithm solves this by using the uncertainty of the universe to create true randomness

Note: The code below runs on a simulator, which means it technically still uses classical pseudo-randomness to mock the quantum behavior. To get TRUE randomness, you would need to run this exact circuit on a real QPU (like IBM’s hardware)

from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator

# We want an 8-bit random number (values from 0 to 255)
# Let's create a circuit with exactly 8 qubits
qc = QuantumCircuit(8)

# Apply a Hadamard gate to ALL 8 qubits
# This puts every qubit into a perfect 50/50 superposition of 0 and 1
for i in range(8):
    qc.h(i)

# Automatically add classical bits and measure all qubits
# This forces the universe to collapse them into a definitive sequence
qc.measure_all()

# Run the simulation exactly 1 time (1 shot)
simulator = AerSimulator()
result = simulator.run(qc, shots=1).result()

# Extract the binary string from the result
counts = result.get_counts()
binary_string = list(counts.keys())[0]

# Convert binary string to a regular integer
random_number = int(binary_string, 2)
print(f"Quantum random 8-bit number: {random_number} (binary: {binary_string})")

Happy World Quantum Day!

May your qubits never decohere too early and may your bugs always collapse into the right solutions

PS: Some my examples here

https://colab.research.google.com/

Just for fun notebook is shared here https://github.com/SecH0us3/check-quantum-python/blob/main/check_quantum_python.ipynb (rnd for three bits)

https://www.quantumplayground.net/ strange, but fun

• Transparency is a patch for survival - hiding technical data (like Gagarin’s ejection) slows down the entire industry. Today’s standard is a public Post-mortem, which allows others to learn from mistakes and saves lives

• Time is the foundation of security - the Shuttle incident showed that a 40-millisecond error can crash a billion-dollar cluster. If your time is out of sync, authentication mechanisms (like Kerberos) and data integrity stop working

• Diverse redundancy - you cannot rely on the same code base for everything. A backup system should be written by a different team on a different stack (like BFS in Shuttles) to avoid shared logic bugs

• Code cannot fix the human factor - even the most complex 2FA (like the “125” code in Gagarin’s envelope) is useless if admins share secrets outside of protocols because of “trust”

1961: Vostok-1 - The First Extreme Production

Yuri Gagarin’s flight was fully automated, and manual control was locked. Engineers implemented the first-ever “two-factor authentication” in conditions of total uncertainty

• Logic Lock (Code 125) - to switch to manual control, the pilot had to open an envelope, read a code, and enter it on a panel. This was a Challenge-Response test: if the person could do this, they were sane enough to fly the ship. However, “social engineering” happened even then - Gagarin was told the code before the launch

• Deadlock during separation - because of a cable failure, the service module did not detach immediately and pulled the landing capsule behind it. In the IT world, this is like a hanging process that prevents a system shutdown. The error was fixed by the environment: the cables burned up from heat during atmospheric entry

• The ejection secret and the bureaucratic brake - Gagarin ejected at an altitude of 7 km because the capsule lacked a soft-landing system. This fact was hidden for 10 years for bureaucratic reasons (FAI records). This hiding is an example of how “image” slows down technology, preventing other teams from learning from real experience

1981: Space Shuttle - Distributed Computing in Orbit

The Shuttle program introduced the concept of a high-availability (HA) cluster to the IT world

• PASS and BFS Architecture - there were four computers with the main software and a fifth one with completely independent code. This is a classic protection against systemic development bugs

• 40-Millisecond Race Condition - the first Shuttle launch failed because of a sync error. The main systems started slightly earlier than the backup, and consensus was not reached. Today, any security auditor will start checking your infrastructure with NTP (Network Time Protocol) settings, remembering this lesson

In Daniel’s version, rockets could destroy walls. The problem was that the game engine didn’t distinguish between a “light cycle trail” and the “game field boundary”. Anything that wasn’t empty space was considered a destructible wall

When the “AI” found itself trapped, it triggered a pathfinding function. Here is how the logic looked in the (pseudo)code:

# Simplified logic of the bug, originally it was Pascal

def move_cycle(cycle):

    # Calculate next move
    next_x = cycle.x + dx
    next_y = cycle.y + dy

    # Check what is at the next position
    target_pixel = get_pixel(next_x, next_y)

    if target_pixel != EMPTY:
        if cycle.has_rockets:
            # ROCKET DESTROYS THE WALL
            # If the wall is actually the screen boundary, it gets erased!
            set_pixel(next_x, next_y, EMPTY)
        else:
            cycle.explode()

    # Update position
    cycle.x, cycle.y = next_x, next_y

    # THE FATAL BUG: No check like "if x > 320 or y > 200"
    # If the boundary was destroyed, we draw directly into system RAM
    draw_at(cycle.x, cycle.y, cycle.color)

The code completely lacked bounds checking. The “AI” shot at the edge of the screen, “erased” the boundary, and kept driving. On the Apple IIgs, video memory was mapped into the general address space (Memory Map). As soon as the light cycle coordinates exceeded the screen resolution, the set_pixel function started writing data into random RAM cells

The “AI’s” light cycle rushed into the area where system data was stored. This caused a cascading failure:

• Color Chaos: The cycle hit the Color Look-up Tables (CLUTs). Because of this, the palette began to shift chaotically, creating a frantic flickering effect

• Logic Destruction: The AI’s trail passed through addresses where the executable code itself was stored. The 65816 processor began executing the light cycle’s “tail” as instructions, leading to unpredictable sounds and glitches

• Collapse: Within seconds, the AI inevitably overwrote critical OS interrupt vectors, and the computer froze solid

It looked exactly like the end of the movie: the heroes break through the system and escape into the real world. Only in Daniel’s case, the “real world” was the computer architecture, which the AI literally rewrote for itself

Lessons from the Case

1. World boundaries must be absolute. If a wall can be destroyed, it cannot be the edge of the universe. Always separate game objects from system constraints

2. Process isolation is fundamental. Modern OSs use the concept of Private Memory. This is dedicated, non-shared memory allocated exclusively to a single process. Thanks to the MMU (Memory Guard), a program physically cannot reach another’s data or the system kernel - any attempt to access memory outside the allocated context triggers an immediate Segmentation Fault

3. Bounds checking saves systems. Buffer overflow errors are the most expensive in history. Always check where your object is going before allowing it to “draw” itself in memory

The Tron bug on the Apple IIgs is a rare moment when a programmer’s mistake accidentally created a perfect metaphor that could never be reproduced on purpose

It is all caused by a classic overflow error and a safety mechanism that tries too hard. The macOS kernel (XNU) uses a 32-bit unsigned integer for the millisecond counter. After 49.7 days, the counter hits its limit of 4,294,967,295. When it tries to add one more millisecond and reset to zero, the kernel safety check kicks in - the internal TCP clock “freezes” at the maximum value

In the source code, this is a fatal logic trap. The system strictly ensures that time only moves forward. Think of a mechanical odometer: it reaches 999,999 and tries to roll over to 000,000, but the safety check sees the new value is smaller than the old one and jams the gears forever

Here is how this mechanism breaks the connection closing logic:

uint32_t tcp_now; // 32-bit uptime counter in milliseconds

// 1. UPDATING TIME AND THE FATAL SAFETY CHECK
void calculate_tcp_clock() {
    uint32_t current_time = get_system_uptime(); // Overflows and resets to 5000
    uint32_t old_time = tcp_now;                 // Stuck at max 4,294,960,000

    // THE BUG: safety check requires time to only move forward
    // The check (4,294,960,000 < 5000) returns FALSE
    // As a result, tcp_now never updates again and stays frozen
    if (old_time < current_time) {
        tcp_now = current_time; 
    }
}

// 2. SETTING THE TIMER for a closed connection
// In macOS, these connections should be removed after 30 seconds (30,000 ms)
connection->expire_time = tcp_now + 30000; 

// 3. CHECKING THE TIMER
void check_connections() {
    // Since tcp_now is frozen and never grows, 
    // it will never exceed the set expire_time
    // The connection just stays in memory forever
    if (tcp_now > connection->expire_time) {
        close_and_free_connection(connection);
    }
}

Because of the frozen time, old network connections in the TIME_WAIT status never close. They pile up and slowly consume all available system ports (about 16,000). Once the ports run out - macOS cannot establish a single new TCP connection. The only solution is a good old reboot

The counter will overflow even if the computer just sits there idle. But if you use the internet rarely and only open a few tabs a day, the port pool will drain slowly, and the network will not “die” immediately

To check how much time is left on your Mac (this is the exact moment when connections start piling up), you can use the Terminal. Just copy and paste this script:

sysctl -n kern.boottime | awk -v now="$(date +%s)" '
{
    boot = int($4)
    uptime = now - boot
    days_left = (4294967295 - uptime * 1000) / 86400000
    printf "Days left: %.2f\n", days_left
}'

The irony is the historical context. Almost 30 years ago, Windows 95 and Windows 98 suffered from the exact same bug. The system would hang after 49.7 days because of an overflow in the GetTickCount function. People didn’t notice it at first - back then, a Windows 95 PC rarely worked for 49 days without a crash or a “Blue Screen of Death” anyway

This problem has been haunting the IT industry for decades. Here are some other iconic examples of number overflows:

• The Year 2038 Problem (Y2K38) - Unix systems store time as a 32-bit signed integer. On January 19, 2038, the counter will overflow and throw computers back to 1901

• GPS Week Number Rollover - satellites use a 10-bit week counter that overflows every 19.7 years, causing old navigators to report the wrong date

• The Ariane 5 Disaster - in 1996, a European rocket exploded in 37 seconds after launch because the computer tried to convert a 64-bit float into a 16-bit integer. The overflow cost about $370 million

• Pac-Man Kill Screen - on level 256, the game breaks and fills half the screen with random symbols due to an 8-bit counter overflow

• Broken YouTube - the Gangnam Style video broke the 32-bit signed integer limit (2.1 billion views), forcing Google to upgrade their counters to 64-bit

• Nuclear Gandhi - in the game Civilization, Gandhi’s aggression was 1, but “democracy” reduced it by 2. Due to an 8-bit overflow, it jumped to 255, turning him into a nuclear warmonger (just a legend)

Technology history moves in circles, and even giants like Apple are stepping on the same 30-year-old landmines - this is why I love stories about historical software bugs

P.S. iPhone and iPad users should also be careful - the kernel there is the same. If your gadget starts having weird network issues, check its uptime. It might have simply “served its term” and needs a reboot

Each version solves some issues, but v8 says - hey, developer, solve all problems by yourself, lol

Of course it’s just a small demo and in real cases cool developers will use it to define sharding/region or other meta-information. Using C# Source Generators or Proxy Classes via DispatchProxy, AOT, Value Types and etc… instead of manual calling, but again - it’s just for demo, not more

Maybe someone could add database checks to guarantee that production database never accepts test data 😂

In the past when integer numbers were used for IDs we used some bits to keep meta-information, and I do not know why we do not do that with uuid today

Ok, just for fun 
     the IDE Rider I have run
And wrote the code below
     Just look at it and go ↓

And the full code for myself:

using static System.Console;

Guid userId = EntityIdGenerator.GenerateV8(EntityType.User);
Guid newOrderId = EntityIdGenerator.GenerateV8(EntityType.Order);

WriteLine($"User ID:  {userId}    ");
WriteLine($"Order ID: {newOrderId} \n");

WriteLine("Pass valid Order ID:   ");

ProcessOrder(newOrderId);

WriteLine("Try to pass User ID to the method for orders \n");

ProcessOrder(userId);

return;

void ProcessOrder(Guid orderId)
{
    EntityIdGenerator.ValidateType(orderId, EntityType.Order);

    WriteLine($" => The ID {orderId} accepted \n");
}

[Flags]
public enum EntityType : byte
{
    Unknown = 0x00,
    User = 0x01,
    Order = 0x02
}

public static class EntityIdGenerator
{
    private const int TypeByteIndex = 10;

    public static Guid GenerateV8(EntityType type)
    {
        var bytes = new byte[16];
        new Random().NextBytes(bytes);

        bytes[TypeByteIndex] = (byte)type; // set type, the best comment, yeah?

        // version 8 (1000) in 7-th byte
        bytes[7] = (byte)((bytes[7] & 0x0F) | 0x80);
        
        bytes[8] = (byte)((bytes[8] & 0x3F) | 0x80); // just requirements

        return new Guid(bytes);
    }

    public static EntityType ExtractType(Guid id)
    {
        byte[] bytes = id.ToByteArray();

        int version = (bytes[7] & 0xF0) >> 4;
        if (version != 8)
            return EntityType.Unknown;

        byte typeByte = bytes[TypeByteIndex]; // get type, the best comment again!
        
        if (Enum.IsDefined(typeof(EntityType), typeByte))
            return (EntityType)typeByte;

        return EntityType.Unknown;
    }

    public static void ValidateType(Guid companyId, EntityType company)
    {
        EntityType type = ExtractType(companyId);

        if (type == company) 
            return;
        
        ForegroundColor = ConsoleColor.Red;
        throw new EntityTypeException($"Invalid entity type. Expected {company}, got {type}");
    }
}

class EntityTypeException(string message) : ArgumentException(message)
{
    public override string ToString() => Message;
}

The date was not chosen by chance. On April 5, 1999, employees of the Israeli company M-Systems (Amir Ban, Dov Moran, and Oran Ogdan) filed a patent for the “USB-based Flash Drake Architecture”

Although other companies also claimed to be the inventors, this patent became the foundation for the industry. The holiday was officially started in 2018 by USB Memory Direct to celebrate how this technology changed the digital world

The first commercial flash drives went on sale in 2000. Their capacity seems tiny today: only 8 MB. For comparison, one photo on a modern smartphone is usually larger than that. Today, there are drives with 2 TB of space, which is 250,000 times more than the first models

Over the years, flash drives “killed” floppy disks, ZIP drives, and later optical discs. They became more than just storage - they are tools for system administrators (bootable drives) and a way to save data from broken computers

Security Perspective

For an IT security pro, a flash drive is not just a convenience, but also a dangerous attack vector. In IT history, flash drives are often linked to famous incidents:

1. Stuxnet: A famous worm that hit nuclear facilities in Iran. It was delivered via a flash drive into a network that was not connected to the internet (air-gapped)

2. BadUSB: An attack where the drive’s controller is reprogrammed so the computer thinks it is a keyboard and quickly types malicious commands

3. “Dropped Drive”: A classic social engineering trick where an attacker leaves a drive in a parking lot - especially one with a tempting label like “Annual Bonuses” - hoping a curious employee will plug it into a work computer

4. USB Killer: A device that looks like a regular drive but is actually a set of capacitors. When plugged in, it collects power from the port and sends a high-voltage surge back, physically burning the computer’s motherboard

How to celebrate this day?

1. Check your drawers: Find your old flash drives. You might find photos from ten years ago or an old Windows installer

2. Think about security: Encrypt important data on your drives using tools like VeraCrypt or BitLocker

3. Clean up: Flash memory has a limited life, but before you throw away an old drive, make sure the data is permanently deleted

4. Make a backup: Use this day as a reminder that important files should be stored in at least two different places

Today, flash drives are slowly being replaced by cloud services, but they are still the most reliable way to move gigabytes of data where there is no internet or where you need maximum privacy

Quick Facts

• The Patron Saint: April 4th is the feast day of St. Isidore of Seville. The Vatican once considered him for the role of the “patron saint of the internet” because he wrote the first encyclopedia in the 7th century. Even without an official decree, the IT world treats him as their saint

• The CERN Myth: Legend says that CERN had a Room 404 where the first web server lived and files often went missing. Robert Cailliau (co-creator of the WWW) debunked this: Room 404 never existed. The code is just part of a protocol where the first “4” stands for a user error

• The LEGO Effect: You won’t find a LEGO set numbered 404 in a regular store. However, the LEGO website is famous for its 404 page. It features a panicked minifigure with a disconnected cable—the gold standard of how to say “sorry” to users

• Asian Noir: In China and Japan, the number 4 sounds like the word for “death” (”sì” in Chinese, “shi” in Japanese). This is why many Asian hotels and hospitals don’t have a 4th floor. For them, a 404 error looks like “double death not found”

How to Celebrate

Set up a creative 404 page on your website with a cat, a game, or a meme. Or just set your status to “Not Found” for today and take a break from work chats

Happy holidays to those who know where broken links go! May your code always compile on the first try

The main problem with the Mars Climate Orbiter (MCO) was a communication gap between two teams of developers. The contractor, Lockheed Martin, built the thruster control software (SM_FORCES) using the imperial system (pound-force seconds). However, the navigation team at NASA JPL expected the data to be in the metric system (newton-seconds), as stated in the Software Interface Specification (and in the science!)

Because of this, sending raw numbers without converting them led to completely unmet expectations in the code. The navigation software assumed the data was in the correct metric format, but the values were fundamentally unequal and desperately needed to be converted

wow, look at here - formulas! never used them before here

It is ironic and dangerous that the United States is one of the few countries in the world (along with Liberia and Myanmar) that has not officially adopted the metric system. While the global science community has used the metric system for decades, using pounds and inches in an interplanetary mission showed a severe lack of system awareness

Just a small reminder from a school:

Physics made the situation even worse. The spacecraft’s asymmetric solar array created a twisting force from solar wind pressure. To stay stable, the system had to fire its thrusters much more often than originally planned. Every time it did this, it sent bad data to the navigation computer, where the force was 4.45 times weaker than it should have been (the ratio of a pound to a newton). This error, which might have gone unnoticed, built up to critical levels because the maneuvers happened so often

# Python pseudo-code showing the fatal out-of-sync issue 
# between Lockheed Martin (ground software) and NASA JPL (navigation)

# ---------------------------------------------------------
# Contractor module (Lockheed Martin) - Uses imperial system
# ---------------------------------------------------------
def calculate_small_forces(thrust_time_sec):
    # Developer uses pound-force (lbf)
    thrust_lbf = get_raw_thruster_force() 
    
    # data without conversion for data_from_amd_file
    return thrust_lbf * thrust_time_sec 

# ---------------------------------------------------------
# Navigation module (NASA JPL) - Expects metric system (SI)
# ---------------------------------------------------------
def update_spacecraft_trajectory(data_from_amd_file):
    # JPL is sure it gets data exactly in newton-seconds (N-s)
    impulse_newton_seconds = data_from_amd_file 
    
    # 1 lbf = 4.45 N, so navigation thinks the thrust is 4.45 times weaker
    current_trajectory.altitude -= apply_orbital_mechanics(impulse_newton_seconds)
    
    """
    RESULT: Ground computers heavily underestimated the braking force
    In reality, the spacecraft was flying lower and lower towards the planet
    """

Catastrophic Consequences

On September 23, 1999, the spacecraft began its manoeuvre to enter orbit

The navigators expected it to pass at an altitude of 226 km, with the absolute minimum survival height being 80 km

But because of the built-up error, the probe hit the atmosphere at just 57 km

The spacecraft was instantly destroyed by aerodynamic stress and burned up

Damage in numbers and facts:

• $327.6 million - the total cost of the MCO program (including $193.1M to build it, $91.7M to launch it, and $42.8M for operations)

• Science failure: The MCO probe was supposed to act as the main data relay for the next spacecraft, the Mars Polar Lander (MPL). Sadly, just a couple of months later, the MPL also crashed during landing due to a different software bug (the engines shut off too early). This made 1999 one of the worst years in the history of Mars exploration

Lessons for the IT Industry

1. Strict typing for physical values and clear naming
   Never use raw types (double, float) for measurements. Use Value Objects (like NewtonSecond or PoundSecond classes) so the compiler stops you from mixing units. For example, some programmers in financial banks create their own Money types or separate UserId and CompanyId types so they don’t accidentally add different currencies or confuse a user with a company. If strict types are impossible, arguments and methods must clearly state the unit in their name: for example, calculateThrustInNewtons instead of calculateThrust

2. Integration testing is not just a bunch of Unit tests
   Each team tested their own code perfectly, but nobody checked how the data flowed together in a real end-to-end scenario (E2E). E2E tests and long simulations with real data exchange files are the only ways to catch hidden errors that build up over time and don’t show up in short, isolated tests

3. Investigate all anomalies deeply
   Any time a system acts differently than expected, it must be studied immediately. JPL navigators actually noticed strange things a week before the crash: the spacecraft needed path corrections too often, and its approach speed didn’t perfectly match the model. These “quiet alarms” were ignored. Remember: if reality differs from your monitoring by even a fraction of a percent, it is a reason to pull the emergency brake, not just hope for the best

Space requires perfect interfaces. The story of the MCO is a painful reminder that even the most complex and advanced system will fall apart if its parts speak different languages

In July 2012, Knight Capital was preparing to launch a new program on the New York Stock Exchange (NYSE) called the Retail Liquidity Program (RLP). To do this, engineers updated their flagship system, SMARS (Smart Market Access Routing System) - an automated router that broke down large “parent” client orders into thousands of small “child” orders so they could be executed quietly on the exchange

Hidden in the SMARS code was a function called “Power Peg” (today we would call it as Angry Birds?). It was originally created for testing in a simulated environment and had not been used in live trading since 2003. Initially, Power Peg worked correctly: it sent orders to the exchange, counted the executed volume, and stopped when the order was fulfilled

However, in 2005, Knight Capital engineers updated the core system and moved the volume counter to a different module. Because everyone was certain that Power Peg was “dead,” they didn’t bother updating its code

In 2012, programmers needed a software switch (a “flag”, “feature toggle flag” etc..) in the binary order protocol to activate the new RLP logic. Changing the structure of the protocol would have required updating all connected systems, which would have taken a lot of time and money. The engineers decided to cut corners and reuse the old flag that had previously triggered Power Peg to activate the new RLP feature

On August 1, the new software was deployed to eight servers. An engineer used a custom automation script for the deployment. However, the eighth server rejected the SSH connection during the process. The script silently ignored the error and reported a successful deployment. As a result, 7 servers received the new software, but the 8th server was left running the old version of SMARS

Around 8:00 AM, the central system started sending pre-market orders with the flag turned on. The old 8th server received the order, saw the flag, and tried to launch Power Peg. But the algorithm immediately tripped over the volume counter that had been missing since 2005 and began generating system warnings (BNET Reject messages). Before the market even opened at 9:30 AM, the system generated 97 automated error emails. Unfortunately, the engineers hadn’t set up their monitoring to treat these alerts as critical, and the emails were ignored

When trading opened, Knight Capital’s external system (BNET) started tagging client orders with flag_4 = true and passing them to the SMARS routers. Here is what that looked like on the “forgotten” eighth server:

// The structure of the incoming client order from the BNET system
struct Order {
    string ticker;
    int totalShares; 
    bool flag_4;     // This is the reused flag! <-<-<-<-<-<-<-<-<
};

// Volume request function (an illustration of the "blind" code)
int getCumulativeVolume() {
    try {
        // Attempting to access the tracker, was removed in 2005
        return coreSystem.getTrackerData(); 
    } catch (...) {
        // The error is caught by the Fault Tolerance block
        // To prevent the server from crashing... simply returns 0
        return 0; 
    }
}

// The OLD version of SMARS (left on server #8)
void processOrder(Order parentOrder) {

    // Inside the message, flag_4 now triggers the old Power Peg
    if (parentOrder.flag_4 == true) { 
        int executedShares = getCumulativeVolume(); // 0!
        
        // CATASTROPHE: executedShares is ALWAYS 0
        // sooo... there are no purchases and buys shares endlessly
        while (executedShares < parentOrder.totalShares) {

            // Test logic: 
            //   buy at Ask (expensive), sell at Bid (cheap)
            sendChildOrderToExchange(parentOrder.ticker); 

            executedShares = getCumulativeVolume(); // 0!
        }
    } else {
        executeStandardRouting(parentOrder);
    }
}

Why Weren’t They Saved? The Fatal “On-the-Fly” Fix

The main tragedy of Knight Capital isn’t the bug itself, but their reaction to it. When the system started burning millions at 9:30 AM, instead of immediately stopping all trading (hitting the “Kill Switch”), the engineers frantically tried to find the cause while the system was still running

They wasted 20 precious minutes diagnosing the problem (1 sec = $172,222 every single second). Not understanding what was going on, they took a wild guess: they decided the new software was the issue and deleted it from the 7 working servers, rolling them back to the old version…

This was a death sentence. The engineers only rolled the system back halfway: they reverted the old code in SMARS, but they forgot about the upstream BNET system, which continued operating in the “new” mode, sending orders with the flag turned on. (Example for nowdays: they had rolled back backend, but not frontend)

Now, the “sleeping demon” Power Peg was activated on all eight servers at the same time. The avalanche of bad trades instantly multiplied by 8. It wasn’t until 10:15 AM, when the company was practically bankrupt, that trading was physically shut down

The Aftermath: The End of a 17-Year History

The results of the 45-minute outage were devastating:

• Financial losses: The realized loss was $440-$460 million

• Stock crash: Knight Capital’s stock plummeted 75% in two days

• Takeover: To avoid bankruptcy, the company was forced to sell itself to a competitor Getco LLC

• Fines: The SEC fined the company $12 million for a “blatant lack of risk controls”

• Management’s fate: The engineer whose script failed kept his job 😊, but the entire upper management team (including the CTO) was fired

Lessons Learned: A Guide for the Industry

1. Physically delete dead code. The 2012 bug was planted in 2005. If you delete or change shared system components, you must clean up all dependent code

2. Never reuse old flags for new features. Trying to save time by not updating a binary data protocol can cost a company its life. Different versions of code interpreted the exact same command in entirely different ways - this is architectural poison

3. Deployment scripts must not be “blind”. The deployment process must verify the result on 100% of the nodes (e.g., checking hashes or polling versions). If one server doesn’t respond, the release must be immediately aborted

4. If you don’t understand it, turn it off. The golden rule of incident management: when a system behaves abnormally, the first step is to stop the bleeding (Kill Switch), and the second step is to find the cause. Trying to fix an airplane while it’s crashing usually just speeds up the impact

5. Atomic rollbacks. You cannot roll back just one part of a system. A “partial rollback” (old code + data in a new format) guarantees a disaster

Conclusion

The Knight Capital case proves that in modern IT, there is no such thing as “just old code” or “just a script.” Real money is behind every line. Clean architecture and strict processes aren’t “bureaucracy” - they are the only way to protect a business from instant destruction

The Story of the “Great Worm”

It was 1988. The internet (then called ARPANET) was a small, closed club for universities, research centers, and the military. It was built on trust - nobody expected an attack from their own colleagues

On November 2, 1988, 23-year-old Robert Morris launched a program to count all the computers connected to the internet. The program (later called the “Morris Worm”) spread by using known weaknesses in network tools like sendmail and fingerd, as well as weak passwords

The idea was smart: the worm enters a server, checks if it is already infected, and if not, it copies itself and looks for new targets. It didn’t delete files or steal data. It was supposed to be completely harmless

But Morris thought of a problem: what if smart system admins set up a fake signal that says “I’m already infected” to protect their servers? To get around this, Morris added a rule: 1 out of every 7 times, the worm should ignore the server’s answer and infect it anyway

This was the fatal mistake!

A 1-in-7 chance (about 14%) was way too high. The worm started infecting the same computers over and over again. Each new copy created more processes, eating up all the memory and CPU power. Thousands of servers simply froze and crashed. Out of the 60,000 computers on the internet at the time, about 6,000 went down

In a panic, Morris tried to send an anonymous message explaining how to stop the worm. But the internet was so clogged that the message never arrived. Finally, following the advice of his father (who happened to be a top cybersecurity expert at the NSA), Robert turned himself in. The damage was estimated to be between $100,000 and $10,000,000. Morris got a light sentence: 3 years of probation, 400 hours of community service, and a $10,050 fine

Lessons Learned by the Tech Industry

1. Trust is a bad security plan. The Morris Worm proved that the internet was no longer a safe place. Systems had to be built assuming the network is hostile

2. The birth of CERT. Right after the attack, the government funded the first Computer Emergency Response Team (CERT) to coordinate responses to future cyber attacks

3. The danger of exponential growth. Even harmless code can become a weapon if a bug causes an endless loop or uncontrolled copying

4. Security by default. The worm used a flaw in sendmail because the program was shipped with a “debug” mode left on. This taught developers a hard lesson about turning off testing features before releasing software

Today, Robert Morris is a respected professor at MIT and a co-founder of the famous startup accelerator, Y Combinator

The Source Code and the Famous Bug

The original code was reverse-engineered back in 1988. Today, you can find its source code in historical archives on GitHub

🔗 Repository link: github.com/arialdomartini/morris-worm (a popular mirror of the recovered code)

Pseudocode of the Fatal Error

The whole disaster happened because the creator was too paranoid and misunderstood probability. In simple terms, the worm’s logic looked like this:

import random

# This logic runs INSIDE the new worm process AFTER it has successfully
# infected, compiled, and started itself on the target server

def logic_inside_new_worm_process():
    # STEP 1: The infection has ALREADY happened
    # The server has already spent CPU/RAM to receive and launch this process

    # The worm checks if another copy is already running on this machin
    # (usually by trying to connect to a specific local socket/port)
    already_infected = check_for_other_copies_locally()

    if already_infected:
        # THE FATAL BUG:
        # Morris was paranoid that system administrators would "fake" an
        # infection by running a dummy process to trick the worm into leaving

        # To bypass this, he added a 1-in-7 chance to IGNORE the result:
        if random.randint(1, 7) == 1:
            # "I don't believe this is a real worm!"
            # The worm ignores the existing process and stays alive anyway
            stay_alive_and_continue_spreading()
        else:
            # Even if the 1-in-7 chance didn't hit, the worm didn't quit yet
            # It would "talk" to the other process and flip a coin (50/50 chance)
            # to decide which one of them should terminate
            if random.choice([True, False]):
                terminate_self()
            else:
                stay_alive_and_continue_spreading()
    else:
        # No other copy found; the machine is "fresh"
        stay_alive_and_continue_spreading()

# THE RESULT:
# Because the worm was constantly re-attacking the same servers,
# the 1-in-7 "stay alive" chance was hit repeatedly
# Machines ended up with dozens of copies running simultaneously,
# eventually crashing the system (Denial of Service)

Timeline of Events

• November 2, 1988: Deploys the worm from MIT. The ARPANET infection begins

• November 3, 1988: Crashes around 6,000 computers, causing massive slowdowns. Experts at UC Berkeley and Purdue rush to reverse-engineer the code

• November 1988: DARPA responds to the crisis by funding the first CERT

• July 26, 1989: A federal grand jury indicts Morris

• January 1990: Morris is found guilty

What is the Problem Today?

Today, your browser sessions are essentially just cookie files. If malware (a desktop app or a malicious extension) or a Man-in-the-Middle (MitM) proxy is present on a device, it can steal these cookies. In this scenario, a hacker doesn’t even need your password; they can simply “replay” the stolen session to gain full access to your bank account, some messengers, or social media profiles

While you could theoretically bind sessions to a user’s IP address, this isn’t a viable solution for businesses that need to keep users logged in for days or weeks across changing networks

DBSC solves this by using the TPM (Trusted Platform Module) to cryptographically sign session requests without any user interaction

How it Works:

1. When a server decides to open a new session, it sends a requirement for the DBSC flow

2. Google Chrome intercepts this and requests the hardware TPM to generate a unique public/private key pair

3. Chrome sends the public key to the server, which associates it with that specific session. The private key never leaves the hardware

4. The server provides a “challenge” string that must be signed using that specific private key

5. The browser calls the TPM’s signing function, passing the website’s info and the server’s challenge

6. The resulting signature is sent back to the server, which verifies it using the previously stored public key

Session cookies typically have a long expiry (e.g., 30 days) for convenience. However, under DBSC, the presence of the cookie alone isn’t enough. Only an additional signature from the TPM can prove that the holder of the cookie is actually on the original device

This “authorization” (the cryptographic proof) can be set to have a very short lifespan—for example, just 10 minutes

The browser automatically handles the re-authorization in the background before sending requests. This means the process is completely seamless for the user while being incredibly difficult for attackers

A critical part of this security model is that the entire cryptographic handshake is completely invisible to the browser’s frontend

• Invisible to Extensions: Since the refresh logic happens deep within the browser’s network stack, malicious extensions cannot intercept or manipulate the DBSC headers

• Hidden from DevTools (F12): Even if you open the Network tab in DevTools, you won’t see the background challenge-response requests. They are decoupled from the standard application flow, ensuring that not even a compromised frontend can interfere with the hardware-level security

A Real-World Example

Consider this: You turn off your laptop for 7 days. You still have your authentication cookies, but your 10-minute authorization has long since expired

When you re-open example.com/account:

1. The browser sees you have a valid authentication cookie but realizes it needs a new signature

2. It requests a challenge string from the server and sends it to the TPM

3. Because the TPM holds the unique private key for that specific session on that specific device, it signs the challenge

4. The session is authorized, and you are logged in

What if a hacker steals your session cookies? The hacker cannot steal the private key from your TPM. Without it, they cannot sign the challenges. Even if they have your 30-day cookie, their “window of opportunity” is limited to the remaining life of your 10-minute authorization. Once those 10 minutes pass, they are permanently locked out

DBSC provides the perfect balance: long-term convenience for users and short-term, hardware-backed security for businesses

Thanks AI - I have “developed” the example https://dbsc.secmy.app/login

Useful links here:

• developer.chrome.com/docs/web-platform/device-bound-session-credentials

• The DBSC specification

• Demo project github.com/SecH0us3/dbsc-demo

  • You can try, but turn on the DBSC feature flags https://dbsc.secmy.app

I have written about a case when some outdated software components were used for more modern conditions, and it led to the Ariane 5 crash. But this time I wrote about a simpler case

So, at the end of 2014, the video Gangnam Style reached the most views ever in the whole of YouTube history.

And suddenly the counter of views stopped on the number `2 147 483 647` (2^31)

The counter is literally broken

Initially, YouTube was developed via the Python language, which handles large numbers very well.

But the database MySQL isn’t!

And if a number is defined like a `signed int` the value `2 147 483 647` is the maximum

Of course, YouTube’s developers implemented a fix quickly, and now the max value for counters takes 64 bits. This number is so big, so it takes more than 4 billion years for mankind to reach the limit... I would like to live so long 🖖

A little demo of how it doesn’t work for MySQL https://www.db-fiddle.com/f/uuVvjyPmCqyD3Mk38SCQhF/1

And what happens on the Python https://python-fiddle.com/?checkpoint=1771142861

It was so cool that Youtube’s developers added the Easter egg on the video page that broke their counter

Unfortunately they have removed it, but some good persons kept the video for history