It took a few days longer than that. But I did it.

The paper is "Attention Is All You Need." Published in 2017 by a team at Google. 8 authors. 15 pages. And it changed everything.

ChatGPT, Claude, Gemini, LLaMA — every large language model you've ever used traces back to this paper. It introduced the Transformer. And I wanted to understand what that actually means.

I saw a tweet from Ahmad Osman breaking down foundational AI papers. I commented that I'd tackle this one over the weekend. Public commitment. No backing out.

I'm a software engineer with genuine enthusiasm for AI — not just using the tools, but understanding what's underneath. I wanted to go to the source. The actual paper. The architecture that powers this entire wave.

Before Transformers

Before Transformers, the dominant approaches were RNNs (Recurrent Neural Networks) and CNNs (Convolutional Neural Networks). I had to learn these first to understand what the paper was replacing.

RNNs process words one at a time. Left to right. Each word depends on the previous one. Like reading a sentence but you're only allowed to look at one word, remember what you can, and move on. CNNs were better at parallelization, but struggled with words far apart in a sentence. ByteNet tried to fix that, but the computational path between distant words grew with distance.

The fundamental problem: sequential processing is slow. You can't train on word 5 until you've processed words 1 through 4.

The Transformer processes all words at the same time. Not one by one. Not left to right. All of them. Simultaneously.

That's the breakthrough. The paper threw out recurrence entirely and replaced it with self-attention — a mechanism that lets every word in a sentence look at every other word, all at once. The path between any two words? O(1). Constant. Doesn't matter if they're next to each other or 500 words apart.

This is why Transformers can be trained on massive datasets. This is why GPUs love them. This is why we went from "AI is a neat research topic" to "AI is rewriting every industry."

Parallelization. That's the unlock.

How Attention Works

The paper introduces Scaled Dot-Product Attention built on three components: a Query, a Key, and a Value.

Think of it like a search engine. The Query is what you're looking for. The Keys are labels on every piece of information. The Values are the actual information. You compare your Query against all Keys to figure out which Values matter most. The more relevant a Key is to your Query, the more weight its Value gets.

Every word generates its own Query, Key, and Value. So every word is simultaneously asking "what should I pay attention to?" and answering that question for every other word.

Multi-head attention takes this further. Instead of one attention operation, you run multiple in parallel — each one looking at different types of relationships. One head might focus on grammar. Another on meaning. Another on position. The paper uses 8 heads, each operating on a 64-dimensional slice of the 512-dimensional model (d_model = 512), then concatenated back together. More eyes on the same data, each looking for something different.

Encoder, Decoder, and Three Types of Attention

The Transformer has two halves. The encoder takes the input and builds a rich representation using self-attention — every word attends to every other word. The decoder generates output one token at a time, but with masked self-attention — each word can only look at what came before it. No peeking at the future. If you're translating a sentence and generating word 3, you shouldn't know what word 4 is yet.

Then there's encoder-decoder attention, where the decoder looks at the encoder's output. This connects input to output — the decoder asks "what parts of the input are relevant to the word I'm generating right now?"

Three types of attention. Same mechanism. Different purposes.

The Rest of the Architecture

The part that genuinely tripped me up: positional encoding and position-wise feed-forward networks. Two completely different concepts with nearly identical names.

Positional encoding solves a real problem — since the Transformer processes all words simultaneously, it has no sense of order. "The cat sat on the mat" and "mat the on sat cat the" would look identical. So you inject position information using sine and cosine functions at different frequencies. The sine wave choice felt arbitrary at first. But sinusoids let the model learn relative positions — the encoding for position 10 can be expressed as a linear function of the encoding for position 5.

Position-wise feed-forward networks are just regular neural network layers applied independently to each position. Nothing to do with encoding position. Completely different concept.

NotebookLM helped me untangle this. I'd paste a section, ask it to break down the terminology, and it pulled the definitions apart clearly.

Other things worth noting: layer normalization keeps values stable so numbers don't explode or vanish as they flow through the network. Dropout at 0.1 randomly cuts 10% of connections during training to prevent memorization. And the embedding and softmax layers share the same weight matrix — the model's understanding of words stays consistent whether it's reading or writing.

Harvard's NLP group published an annotated version that reimplements the entire Transformer in code. Not all of it ran cleanly in their Colab notebook, but reading the implementation alongside the paper gave me a second lens on every concept. When the math was abstract, the code made it concrete.

What's Next

Reading this paper did something I didn't expect. It didn't just teach me how Transformers work. It made me realize how badly research papers are designed for learning.

15 pages of dense notation. No interactive diagrams. No way to poke at the architecture and see what changes. You either already have the background or you're Googling every other sentence.

I want to build something that fixes this. A tool that takes a research paper and turns it into an interactive, visual experience — 3blue1brown-style animations where you can see attention weights flow, watch embeddings form, step through the architecture layer by layer.

Papers shouldn't be walls. They should be doors.

That's the project for the future.

Every LLM you use today — every chatbot, every coding assistant, every AI-generated anything — runs on the ideas in this paper. Eight researchers in 2017 figured out that attention is all you need, and the world hasn't been the same since.

I spent a few days understanding their work. Now when someone says "Transformer" I don't just nod. I know what's happening under the hood.

Worth every hour.

The paper: Attention Is All You Need (Vaswani et al., 2017)

Spoiler: the vulnerability was already patched. I just didn't know it yet.

The Beginning (Feels Easy)

Things were vague in the beginning. I started by information gathering, like any software engineer would:

1. Have access to the target network (LAN or over the internet)

2. Know the services - domain finding and IP address scanning

3. Quick scan known ports against couple of servers

4. Identify services and corresponding versions

5. Map vulnerabilities by service/open port

6. Select highest CVE score vulnerability

Scanner finds Netatalk 3.1.8 on port 548. CVE-2018-1160. CVSS score 9.8. Pre-authentication remote code execution.

I thought: "Nice. This will be easy."

It was not!

What is Netatalk?

Netatalk is a Free and Open Source file server that implements the Apple Filing Protocol (AFP) over TCP/IP. It lets Apple devices talk to Linux/Unix servers. Synology NAS uses it so Mac users can access their files.

Simple enough. Now let's look at the bug.

The Vulnerability (Looks Simple on Paper)

CVE-2018-1160 is a heap overflow in dsi_opensess.c. Here's the vulnerable code:

/* parse options */
while (i < dsi->cmdlen) {
  switch (dsi->commands[i++]) {
  case DSIOPT_ATTNQUANT:
    memcpy(&dsi->attn_quantum, dsi->commands + i + 1,
            dsi->commands[i]);  // <-- THE BUG
    dsi->attn_quantum = ntohl(dsi->attn_quantum);
  case DSIOPT_SERVQUANT:
  default:
    i += dsi->commands[i] + 1;
    break;
  }
}

See the problem? dsi->attn_quantum is a 4-byte integer, but dsi->commands[i] controls how many bytes get copied. Attacker controls that value. Send a big number, overflow the buffer, overwrite the commands pointer, redirect execution to your shellcode.

Classic heap overflow. Tenable published a working exploit. Should be straightforward.

Should be.

Setup and Replication (The First Layer)

The main target was a Synology running DSM 6.2.4-25556. I needed to replicate the environment.

Problem: Synology isn't just software. It's hardware with a custom OS. You can't just download an ISO.

I searched:

• "Synology 6.2.4-25556 iso"

• "Synology docker"

• "Synology virtualbox"

Results were confusing. I had to zoom out and understand what I was even looking at.

NAS: Network Attached Storage - the general category
Synology: A popular brand that makes NAS hardware
DSM: DiskStation Manager - the web-based OS that runs on Synology devices

To run DSM without Synology hardware, you need XPenology - a community project that creates bootloaders to run DSM on regular PCs/VMs.

This is where the pain started.

The Virtualization Nightmare

Attempt 1: VirtualBox

Created a VM. Downloaded a bootloader. Configured the virtual disk.

Boot. Black screen. Nothing.

Tried different settings. Different SATA controllers. Different network adapters.

Boot. Black screen. Still nothing.

The e1000 network adapter wasn't being recognized properly. XPenology forums mentioned this. Solutions were vague. "Try VMware instead."

Attempt 2: VMware Workstation

New VM. Same bootloader.

Boot. Actually got somewhere this time. Bootloader menu appeared.

Selected the option. Loading... loading...

Kernel panic.

The Bootloader Carousel

I tried them all:

• Jun's Loader 1.03b - wouldn't boot

• Jun's Loader 1.04b - booted but couldn't find DSM

• RedPill - complex setup, failed

• ARPL (Automated RedPill Loader) - promising but version incompatibility

• TinyCore RedPill - finally something worked

I rebuilt that VM probably 6-10 times. Each time thinking "this configuration will work."

Each time: it didn't.

The Dead Link Problem

Finding the right DSM .pat file was its own adventure. I searched:

• Official Synology archive (missing old versions)

• XPenology forums (half the links were dead)

• Web Archive (saved my life multiple times)

• Random forum posts from 2019

Lost count of how many 404s I hit. Every promising link led to a dead end. Some files were corrupted. Some were wrong versions. Some required registration on forums that no longer existed.

Plot Twist: The Real Synology

At some point I thought: "Maybe I should just buy the hardware."

I got my hands on a real DS920+. Used, from previous owner.

Problem: it had data on it. Previous owner's data. Couldn't just wipe it without complications.

Back to the VM.

Finally: A Working Environment

After weeks of VM failures, I got DSM 6.2.2-24922 running in VMware. Not the exact version I wanted (25556), but close enough. Same Netatalk version. Should be vulnerable.

Time to exploit.

The Exploit Attempts (The Second Layer)

I read Tenable's writeup. Downloaded the Exploit-DB code (EDB-46034). Studied the DSI protocol.

The exploit strategy:

1. Send malformed DSI OpenSession packet

2. Overflow attn_quantum to overwrite commands pointer

3. Point commands to the AFP dispatch table (afp_switch)

4. Next command executes from the dispatch table = code execution

First step: find addresses. The binary has no PIE (Position Independent Executable), so addresses are fixed. Good news.

$ checksec usr/bin/afpd
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)  # <-- NICE

Extracted afp_switch address: 0x65b880

Now build the payload. Send it.

Crash.

Okay, wrong offset probably. Adjust. Send again.

Crash.

Different offset. Different approach.

Crash. Crash. Crash.

I wrote more than 10 different exploit scripts. Different offsets, different padding, different techniques.

Every. Single. One. Crashed the server.

The Confusion

The server crashed every time. But here's what was weird:

When I sent a normal DSI OpenSession (option length = 4 bytes), the server responded fine.

When I sent length = 6 or more, instant crash. No response.

My theory: "The exploit is working. I'm just hitting the wrong offset. Maybe ASLR is on somehow?"

I checked ASLR. It was off.

I kept trying different offsets. 16 bytes from attn_quantum. 24 bytes. 32 bytes. 40 bytes.

All crashed.

What was I missing?

The Discovery

After 2-3 weeks of this, I decided to actually look at what the server was doing.

Opened radare2 on the library file:

r2 -A usr/lib/libatalk.so.17.0.0
[0x00011d80]> pdf @ sym.dsi_opensession

Scrolled through the disassembly. Looking for the memcpy. Looking for the vulnerable pattern.

Then I saw it:

0x00029c09      cmp r9b, 1           ; if option_type == 1
0x00029c0d      jne 0x29c24          ; skip if not
0x00029c0f      cmp rsi, 4           ; CHECK: is length == 4?
0x00029c13      jne 0x29d01          ; if NOT 4 → jump to ERROR

Followed the error path:

0x00029d01      ...
0x00029d18      lea r8, str.option__u_bad_length:__zu  
               ; "option %u bad length: %zu"
...
0x00029cfc      call sym.imp.exit    ; exit(1)

There it was.

The "crash" wasn't the vulnerability triggering. It wasn't my payload corrupting memory. It wasn't wrong offsets.

It was a patch.

Synology added a length check. If the option length isn't exactly 4, the server logs an error message and calls exit(1). Clean termination. Not a crash.

The vulnerability was patched before I even started.

The Timeline

• CVE-2018-1160 disclosed: December 2018

• Synology patch (DSM 6.2.1-23824-4): December 2018

• My target (DSM 6.2.2-24922): May 2019

• Reality: Already patched for 6 months before the build date

I spent 3 weeks trying to exploit something that was fixed before I started.

What I Actually Learned

Here's the thing: I'm not even mad. I learned more from this failure than I would have from a working exploit.

1. Verify the vulnerability exists before exploiting

I trusted the scanner. Scanner said "Netatalk 3.1.8 = vulnerable." Scanner didn't check for vendor patches.

Lesson: Version numbers lie. Synology ships Netatalk 3.1.8 but with backported security fixes. Always verify by looking at the actual code.

2. Read the disassembly FIRST

10 minutes in radare2 would have saved me 3 weeks. I should have looked at dsi_opensession before writing a single line of exploit code.

Lesson: Understand what you're attacking before you attack it.

3. The setup struggle was valuable

All those failed VMs taught me:

• How bootloaders work (and why they exist)

• VirtualBox vs VMware networking differences

• How to extract firmware (.pat files are just compressed archives)

• How XPenology actually functions

• That sometimes the "easy path" (buying hardware) isn't easy either

4. Document everything

I wish I had written this article as I went. Half my notes were scattered across terminal history and random text files.

Tools I Used

• radare2 - Binary analysis (the tool that finally showed me the truth)

• checksec - Quick binary security check (PIE, ASLR, etc.)

• file - Identifying file types during firmware extraction

• VMware Workstation - After VirtualBox failed me

• Various XPenology bootloaders - TinyCore RedPill eventually worked

What Would I Do Differently?

1. Check if patched first - Before any exploit development, look at the actual vulnerable function. Compare to patched version.

2. Document from day one - Every failure, every dead end, every small victory.

3. Trust but verify - Vulnerability scanners give you leads, not guarantees.

Attack End Goal (That Never Happened)

For the record, here's what CVE-2018-1160 would have allowed:

An unauthorized attacker could gain remote code execution on a Synology DiskStation NAS server. No authentication required. Send malformed packet → execute arbitrary code → own the box.

Critical vulnerability. CVSS 9.8. Would have been a clean kill.

If only it wasn't patched.

Final Thoughts

Failing is part of the process. I went in expecting to pop a shell in a few days. Instead I learned how NAS systems work, how firmware is structured, how to read assembly, and how to properly verify a vulnerability before wasting weeks on it.

The next pentest will go differently. I'll check the code first.

But I wouldn't trade this experience for a quick win. The struggle taught me more than success ever could.

This was an authorized penetration test in a controlled lab environment. Don't hack things you don't have permission to hack.

There is a concept called cloud computing that allows on-demand access to a shared pool of configurable computing resources, allowing for convenient, on-demand access to these resources. As examples of these resources, networks, servers, storage, applications, and services can be rapidly provisioned and released with minimum management effort or service-provider interaction.

There are five key characteristics of cloud computing, three deployment models, and three service models that form the model of cloud computing. These five key characteristics are as follows:

1. On-demand self-service: This allows users to access cloud resources such as processing power, storage, and network using a simple interface without interaction with the service provider.

2. Broad network access: Cloud computing resources can be accessed via the network through standard mechanisms and platforms such as mobile phones, tablets, laptops, and workstations.

3. Resource pooling: This gives providers economies of scale, which they pass on to their customers, making the cloud cost-efficient. Resources are dynamically assigned based on demand.

4. Rapid elasticity: This allows users to access more resources when they need them and scale back when they don't.

5. Measured service: Users can pay for what they use or reserve resources as they go. Resource usage is monitored, measured, and reported transparently based on utilization.

Many characteristics make cloud computing a highly flexible, cost-effective, and efficient solution for companies of all sizes and across a wide variety of industries. This lesson will focus on the business case for cloud computing and how it changes the way businesses operate. Besides the five essential characteristics, cloud computing also includes three deployment models and three service models in addition to the five essential characteristics.

Among the three deployment models, the following are the most commonly used:

1. Public cloud: This leverages cloud services over the open internet on hardware owned by the cloud provider, but its usage is shared by other companies.

2. Private cloud: The cloud infrastructure is provisioned for exclusive use by a single organization. It could run on-premises or it could be owned, managed, and operated by a service provider.

3. Hybrid cloud: This is a mix of both public and private clouds, working together seamlessly.

As far as service models are concerned, there are three:

1. Software as a Service (SaaS): This is a software licensing and delivery model in which software and applications are centrally hosted and licensed on a subscription basis. It is also known as "on-demand software."

2. Platform as a Service (PaaS): You get access to the platform, that is the hardware and software tools, usually those needed to develop and deploy applications to users over the internet.

3. Infrastructure as a Service (IaaS): You get access to infrastructure and physical computing resources such as servers, networking, storage, and data center space without the need to manage and operate them.

These deployment and service models provide a wide range of options for organizations to choose from depending on their specific needs and requirements. In this article, we provided an overview of cloud computing, including its definition, essential characteristics, deployment models, and service models. We also discussed how these characteristics, models and service make cloud computing a highly flexible, cost-effective, and efficient solution for organizations of all sizes, across all industries.

As a conclusion, cloud computing has become more than a buzzword, but rather a reality which has dramatically changed how businesses operate and how IT resources are used in the digital age. In order to be able to decide which deployment and service model best suits the needs of their organization, it is important for them to be aware of the benefits and challenges of cloud computing.

It is crucial for businesses to keep up-to-date with the latest developments in this field to stay competitive in the future, and the future of technology largely revolves around the cloud.