We type a few words into a search bar, press Enter, and within milliseconds, we're presented with a list of results. But what actually happens between entering a query and receiving those results? How does a search engine find relevant documents? How does it decide which results should appear first?

I wanted to understand these processes beyond just learning the theory. So, I decided to build my own search engine from scratch.

This is the beginning of a series where I'll document the development of my search engine, the technologies I'm using, the challenges I encounter, and the concepts I learn along the way.

What Am I Building?

My goal is to develop a search engine that can process documents, organize information, and retrieve relevant results based on a user's search query.

Rather than relying on an existing search engine API to handle the main functionality, I want to implement the underlying search mechanisms myself.

Some of the major components I plan to work on include:

• Document Processing: Preparing and processing documents so they can be searched efficiently.
• Inverted Indexing: Creating a data structure that maps terms to the documents in which they appear.
• Information Retrieval: Finding documents that match a user's search query.
• Search Ranking: Determining how relevant each document is to a query.
• Query Processing: Taking a user's input and transforming it into something the search engine can process.

These components will work together to turn a basic search query into an organized list of relevant results.

Technologies I'm Using

I'm building this project with technologies that allow me to develop and connect the different parts of the search engine.

Some of the technologies currently involved include:

• Python: The primary programming language for implementing the search engine's backend logic.
• FastAPI: A Python framework I'm using to build the backend API and handle requests.
• JavaScript: Used for frontend functionality and communication with the backend.
• HTML and CSS: Used to structure and style the user interface.
• Git and GitHub: Used for version control and documenting the project's development.

I'm also keeping the project locally runnable rather than depending on a deployed application. This allows me to focus on the underlying implementation and provide instructions for others who want to run it on their own machines.

How Does a Search Engine Actually Work?

Before getting deeper into the implementation, it's useful to understand the general workflow I'm trying to build.

A simplified search engine follows a process like this:

1. Collect documents: The system obtains the information that users will eventually be able to search.
2. Process documents: The content is cleaned and prepared for indexing.
3. Build an index: The system organizes terms so it doesn't have to scan every document from scratch for every query.
4. Process a query: A user enters a search term, which the system analyzes.
5. Retrieve and rank results: The search engine finds matching documents and determines which ones are most relevant.
6. Display results: The user receives an ordered list of search results.

One particularly interesting part of this process is the inverted index.

Imagine having thousands of documents. Without an index, the search engine might need to examine every document whenever someone searches for a word. An inverted index changes this approach by storing a mapping between words and the documents containing them.

For example:

Instead of searching through every document, the engine can use this mapping to locate potentially relevant documents much more efficiently.

This is one of the core concepts I want to implement and understand in this project.

What Makes This Project Interesting to Me?

I could have built another basic web application, but I wanted to work on something that would challenge me to understand the computer science concepts operating behind the scenes.

Building a search engine involves several interesting areas of computer science, including:

• Data structures and algorithms
• Information retrieval
• Text processing
• Backend development
• API design
• Software testing
• Performance optimization

I'm particularly interested in understanding how different algorithms affect search quality and performance.

For example, I plan to explore TF-IDF and BM25, two approaches used in information retrieval to evaluate how relevant a document is to a search query.

I also want to understand the trade-offs involved in designing a system that can retrieve useful results without unnecessarily wasting computational resources.

Where Does the Project Stand Right Now?

I'm developing the project incrementally rather than trying to implement everything at once.

I've started by setting up the local development environment, organizing the project structure, and building the initial backend functionality.

At this stage, the project is still under development. The more advanced indexing, ranking, and retrieval features are part of the implementation roadmap, not features I'm claiming to have completed.

I'll be sharing actual code, screenshots, test results, and explanations as I implement each component.

You can also follow the development through my GitHub repository:

GitHub: https://github.com/ved-p-coder/Search-Engine

What's Next?

In the next article, I'll take a closer look at the backend architecture and how I'm using FastAPI to build the foundation of the search engine.

I'll explain the project structure, how the backend handles requests, and how the different components will communicate with one another.

This is just the beginning. I'm looking forward to documenting the process, learning more about information retrieval, and seeing how far I can take this project.

Thanks for following along!

This is the first article of my Search Engine development series. More updates coming as the project progresses.

The incident quickly became known as the largest cryptocurrency theft on record. It also raised an uncomfortable question. If one of the world's largest crypto exchanges can suffer a breach of this scale, how secure are the platforms holding billions of dollars in customer assets?

What makes this incident particularly interesting is that attackers reportedly didn't need to break Bitcoin or discover a flaw in its blockchain. Instead, they targeted the systems responsible for authorizing cryptocurrency transactions.

When Did the Attack Happen?

The attack occurred on October 29, 2026. According to blockchain investigators, most of the stolen funds were transferred within approximately 20 minutes.

Initial estimates placed the losses at more than $6 billion, with blockchain analytics firms later estimating the total at around $6.3 billion.

The stolen assets were spread across multiple cryptocurrencies and blockchains. Bitcoin was among the affected assets, but this was not exclusively a Bitcoin theft.

The FBI later attributed the incident to North Korean state-sponsored hackers associated with the TraderTraitor group, also tracked under names connected to the Lazarus Group. The attribution was announced on October 31.

How Did the Hack Actually Happen?

To understand this incident, we first need to understand how cryptocurrency exchanges handle transactions.

When customers withdraw cryptocurrency from an exchange, the platform must authorize and sign transactions using systems that control access to its wallets. These systems are extremely sensitive because anyone who gains sufficient control over them may be able to move large amounts of cryptocurrency.

According to Binance's initial investigation, the attack may have involved a compromised laptop belonging to a DevOps engineer. The attacker allegedly used access to an internal service container to submit unauthorized withdrawal transactions.

However, blockchain investigators uncovered evidence suggesting the incident involved a broader compromise of Binance's transaction-signing infrastructure.

Here's a simplified breakdown of what reportedly happened:

1. Initial access

The attackers gained access to internal infrastructure, reportedly through a compromised employee device. This gave them a potential entry point into systems involved in transaction processing.

2. Compromising transaction authorization

Rather than simply stealing a wallet's private key, investigators believe the attackers compromised systems capable of authorizing transactions. This distinction is important, even if private keys remain protected, an attacker who can abuse the systems controlling transaction approvals may still move funds.

3. Unauthorized transfers

The attackers used their access to initiate transactions across multiple blockchains. On Ethereum, investigators reported the use of EIP-7702, a feature that allows externally owned accounts to temporarily delegate certain execution capabilities.

4. Moving and laundering the funds

After the theft, the attackers moved assets through different wallets, decentralized exchanges, and other services to make tracking and recovery more difficult.

The investigation is ongoing, so the precise sequence of every action should be treated as provisional.

What Happened to the Stolen Cryptocurrency?

One interesting aspect of this incident is that stealing cryptocurrency doesn't necessarily mean attackers can immediately spend all of it.

Blockchain transactions are publicly visible, allowing investigators to follow funds as they move between addresses. Additionally, certain cryptocurrency issuers can freeze tokens held at identified addresses.

Following the breach, companies including Tether and Circle reportedly froze significant amounts of assets associated with the attackers. Estimates of the frozen funds varied, with reports placing the amount around $3 billion.

However, Bitcoin and Ether cannot simply be frozen by a central issuer in the same way as certain stablecoins. This makes recovering those assets considerably more difficult.

The FBI also warned that the stolen funds were being converted primarily into Ethereum and could be moved through decentralized finance platforms and instant-swap services.

What Impact Will This Have on Cybersecurity?

I believe this incident will have consequences beyond Binance and the cryptocurrency industry.

1. Exchanges will need stronger internal security.

For years, cryptocurrency security discussions have focused heavily on protecting private keys and auditing smart contracts. This incident highlights another major risk: the infrastructure, employee devices, and internal services that control access to those keys.

Organizations will likely need stronger access controls, hardware-backed authentication, isolated signing environments, and additional transaction verification.

2. Insider and supply-chain security will become more important.

A compromised employee device can potentially become an entry point into an organization's most sensitive systems. Companies must treat employee endpoints, developer tools, service accounts, and internal infrastructure as part of their security perimeter.

3. Real-time blockchain monitoring will become essential.

Blockchain analytics helped investigators follow the stolen assets and identify suspicious transaction patterns. Exchanges and security companies will likely invest further in automated monitoring systems that detect unusual transfers and respond before funds disappear.

4. Trust in centralized exchanges could decline.

Cryptocurrency exchanges act as custodians for enormous amounts of customer money. Incidents like this may encourage users to reconsider how much cryptocurrency they leave on centralized platforms. Exchanges will face greater pressure to demonstrate that their security controls and financial reserves are reliable.

The Bigger Picture

The $6.3 billion Binance incident demonstrates that cryptocurrency security is about much more than protecting blockchain technology.

Bitcoin's underlying network was not the system breached in this incident. The attackers reportedly exploited weaknesses in the infrastructure surrounding the exchange and its transaction authorization processes.

That distinction is important. A decentralized blockchain can operate as designed while the centralized services built around it remain vulnerable.

As cryptocurrency adoption grows, exchanges will need to approach cybersecurity with the same seriousness as major financial institutions. Stronger infrastructure security, continuous monitoring, and carefully controlled transaction authorization will be essential.

The biggest lesson is simple. You don't always have to break the technology itself to compromise the money it protects. Sometimes, you just need to compromise the systems controlling it.

Further Reading

Reuters: Binance's response to the $6.3 billion heist

The Block: Inside the largest crypto hack on record

CoinDesk: Binance loses over $6 billion

BleepingComputer: FBI links the hack to North Korea

But the most interesting part of this story isn't just the vulnerabilities themselves. AI played a major role in helping researchers uncover and investigate flaws that had remained hidden for years.

This raises an important question: Are we entering an era where AI can discover security weaknesses faster than humans can?

How Did AI Help Find PHP2Shell?

PHP powers a huge portion of the web, including platforms such as WordPress, Drupal, and Joomla. Because PHP is mature and widely used, its underlying code has been examined by developers and security researchers for years.

Yet, extensive human review doesn't guarantee that every vulnerability will be found.

According to Wiz Research, the PHP2Shell investigation involved AI-assisted research tools, including models from OpenAI and Google, alongside the team's own expertise and tooling. OpenAI also reported that Calif identified a critical flaw using GPT-5.6 Sol, while Wiz independently discovered and reported both vulnerabilities.

The breakthrough wasn't simply asking an AI to scan code and point out a mistake. The challenge involved complex memory-safety problems, situations where PHP's handling of errors and internal memory state could leave invalid data behind.

Researchers used AI to help analyze code, investigate unusual behavior, develop exploit techniques, and work through repeated testing and debugging. These flaws required connecting multiple low-level behaviors into a chain that could produce a serious security impact.

In other words, AI helped make a difficult research process more practical. Human researchers still played an essential role in understanding the system, validating results, coordinating disclosure, and ensuring the problems were fixed.

Why Does This Discovery Matter?

The vulnerabilities affected PHP itself, rather than one particular website or content management system. That distinction matters, changing application code alone would not necessarily protect a server running a vulnerable PHP version.

The flaws could expose sensitive process memory or enable remote code execution, potentially giving attackers access to a compromised server and the information it handles.

More importantly, the discovery illustrates a shift in cybersecurity: AI can help turn obscure, difficult-to-exploit bugs into practical security findings.

If AI lowers the time and expertise needed to investigate complex code, vulnerabilities that once seemed too difficult to exploit may become realistic targets. The same capability can help defenders discover and fix those flaws before attackers take advantage of them.

The AI-Assisted Vulnerability Discovery Loop

A simplified version of the process looks like this:

1. Analyze: Examine source code and identify suspicious patterns.
2. Test: Generate edge cases and investigate unexpected behavior.
3. Trace: Follow crashes and errors to potential root causes.
4. Validate: Confirm whether a genuine vulnerability exists.
5. Fix: Work with maintainers to patch the issue and verify the solution.

AI can accelerate several of these stages, but it doesn't automatically make every result correct. Researchers must distinguish real vulnerabilities from false positives and test whether proposed fixes actually work.

What Does This Mean for the Future of Cybersecurity?

I see three major implications.

1. Attackers may become more capable. AI could help malicious actors analyze unfamiliar code, adapt techniques, and automate parts of their work. That doesn't mean every attacker will suddenly become an expert, but the barrier to certain tasks may fall.
2. Defensive security could become more proactive. Organizations may increasingly use AI-assisted code review, automated testing, and vulnerability research to find weaknesses before software reaches production.
3. Human expertise will evolve. Security professionals will need to understand systems, evaluate AI-generated findings, prioritize risk, and make sound decisions under pressure. Knowing how to use AI responsibly may become as important as knowing how to use traditional security tools.

The Bottom Line

PHP2Shell is a warning and an opportunity. AI can help uncover vulnerabilities that have survived years of scrutiny, but the same capabilities could also accelerate attacks.

The future of cybersecurity won't be determined by AI alone. It will depend on how quickly developers patch flaws, organizations improve their defenses, and security professionals learn to work effectively with these tools.

The real advantage won't belong to whoever uses AI first. It will belong to whoever can use it responsibly, verify its findings, and act before the other side does.

Further Reading

Wiz Research: PHP2Shell technical analysis

OpenAI: Coordinated disclosure of critical vulnerabilities

Elastic Security Labs: PHP2Shell detection coverage

PHP official website and security updates

You type https://example.com into your browser, press Enter, and a website appears a moment later. It feels almost instant, but several systems work together behind the scenes to make that happen.

Your browser needs to locate the server hosting the website, establish a connection, securely exchange information when using HTTPS, and request the resources needed to display the page.

Understanding this process helps explain fundamental concepts in software engineering, networking, and cybersecurity.

Let's follow a request from your browser to a web server and back.

1. Understanding the big picture

When you visit a website, the process generally involves these stages:

1. DNS resolution: Find the IP address associated with the domain name.
2. Connection establishment: Set up the necessary network connection.
3. TLS handshake: Establish a secure connection when using HTTPS.
4. HTTP request: Ask the server for a resource, such as a webpage.
5. Server response: Receive a response containing content or an error.
6. Rendering: The browser processes the returned resources and displays the page.

These steps are a simplified model. Some can be skipped, reused, or combined when information is cached or an existing connection is available.

2. DNS: Finding the server

Computers communicate across networks using IP addresses. However, remembering numerical addresses for every website would be inconvenient. That's why we use domain names such as example.com.

The Domain Name System (DNS) translates domain names into records that help a client locate the appropriate server.

Your device may first check its DNS cache. If it doesn't have a usable answer, it sends a query to a DNS resolver, often provided by your internet service provider or a public DNS service.

The resolver can consult other DNS servers, including authoritative name servers, to obtain the relevant record. It then returns the answer to your device.

For example, suppose DNS returns the IPv4 address 93.184.216.34. Your browser can use that address to connect to the destination server.

The example address is illustrative. The actual address depends on the domain and its DNS configuration.

Why it matters: DNS makes the web easier to navigate, but it also creates security considerations. Incorrect DNS responses can direct users toward unintended destinations, which is one reason DNS security and certificate validation matter.

3. TCP: Establishing a connection

Once the browser has an IP address, it needs a way to communicate with the server.

For a typical HTTPS connection using HTTP/1.1 or HTTP/2 over TCP, the browser establishes a TCP connection before beginning the TLS handshake.

TCP, or Transmission Control Protocol, provides an ordered, reliable stream of data. It handles retransmission when data is lost and ensures bytes are delivered in order.

The connection begins with a three-way handshake.

The three messages are:

• SYN: The client asks to establish a connection.
• SYN-ACK: The server acknowledges the request and responds.
• ACK: The client acknowledges the server's response.

The connection is now established.

TCP commonly uses port 443 for HTTPS and port 80 for HTTP. These are conventional ports, not guarantees about which port every server uses.

One important detail: not every modern website uses TCP. HTTP/3 uses QUIC, which runs over UDP and incorporates transport security setup differently. This is why the exact sequence depends on the protocol being used.

4. TLS: Securing the connection

If you're visiting an HTTPS website, your browser also needs to establish secure communication with the server.

HTTPS uses HTTP over a connection secured by TLS (Transport Layer Security). TLS helps protect data from being read or modified in transit and helps authenticate the server.

During a simplified TLS handshake, the browser and server negotiate security parameters, establish shared cryptographic keys, and authenticate the server using its certificate.

The browser checks whether the certificate is valid for the requested hostname and whether it chains to a trusted certificate authority, along with other applicable checks.

After the handshake, application data can be transmitted through the protected connection.

This matters when you're entering passwords, sending payment information, or accessing private accounts. Without appropriate transport security, information could be exposed or altered by an attacker positioned to intercept network traffic.

However, HTTPS doesn't automatically mean a website is trustworthy. A malicious website can also obtain a valid TLS certificate.

5. HTTP: Requesting the webpage

Now the browser can send an HTTP request to the server.

For example, a simplified request might look like this:

GET / HTTP/1.1

Host: example.com

Accept: text/html

The GET method asks the server to retrieve a resource. The "/" path refers to the root path of the website, and the headers provide additional information about the request.

The server receives the request and determines how to handle it. Depending on the application, it might retrieve a static file, execute application code, query a database, or communicate with another service.

The server then sends an HTTP response containing a status code, headers, and potentially a response body.

For example:

• 200 OK means the request succeeded.
• 301 Moved Permanently indicates a permanent redirect.
• 404 Not Found means the requested resource wasn't found.
• 500 Internal Server Error indicates a server-side failure.

These codes help the browser and developers understand what happened. An error response can still contain a useful response body explaining the problem.

6. Rendering: Turning data into a webpage

Receiving the initial HTML document doesn't necessarily mean the browser has finished loading the website.

The browser parses HTML to construct the Document Object Model (DOM). It processes CSS to determine how elements should appear and executes JavaScript when required.

As it discovers referenced resources, the browser may request additional files, including stylesheets, scripts, images, and fonts. Those requests may reuse existing connections or establish new ones.

The browser combines the relevant information to render the page on your screen. JavaScript can also modify the page after the initial rendering.

This is why a website can display some content before everything has finished loading.

Conclusion

Typing a URL into your browser triggers a chain of operations involving DNS, network connections, TLS, HTTP, and browser rendering.

Each component solves a different problem: DNS locates the destination, transport protocols move data, TLS protects communication, HTTP defines requests and responses, and the browser turns returned resources into an interactive webpage.

Understanding this process gives you a useful foundation for debugging web applications, investigating network problems, and learning about web security.

The next time a webpage loads almost instantly, remember that multiple protocols and systems are working together behind the scenes.