Playing With Bits: Of Malware Labs, Steganography and Narnia

 

 

                                    Where's mah Gibson, punk?

 

 Hi y'all!

As mentioned here, I played around with some steganography. The idea was simple and unfancy: just a .ppm file and some Python.
Why .ppm? Because it’s stupidly simple: uncompressed RGB values, no PNG compression, or arcane metadata. Just bytes (although .ppm headers can have comments, so keep that in mind).

 

The Method

                A .ppm header

 

Looking at the image above, the header is simply to get:

(0x50 0x36)  → P6: binary PPM file

(0x0a) → newline

(0x36 0x34 0x30) → 640: image width

(0x20) → space

(0x34 0x32 0x36) → 426: image height

And bam—our header info.

And then we get 3 bytes at a time, for each pixel (RGB: Red, Green, Blue), defining the color of that precise byte.

After that, pixel data: 3 bytes per pixel (RGB). Nothing else.

To hide data, I zeroed the least significant bit (LSB) of each byte, which doesn’t really alter the image in a visible way. This gives you 3 bits per pixel to encode data. Stack those bits together and slice them in blocks of 8—now you have bytes. Bytes mean ASCII. ASCII means text.

That’s the gist. You can write an entire hidden message (or image, or audio) inside another image by tampering with just the LSBs.

To make this practical, I wrote a couple of Python scripts. You can find them here. Mess with that as you see fit.

 

 

Limitations?

Sure. Quite a few:

• .ppm headers with comments will throw things off. But you can easily code around that. Heck, have that as a homework if you'd like.
• No encryption. Anyone with a hex editor and some free time can sniff it out. 
• No error detection or correction. More homework.
• Every LSB is predictably overwritten—pattern detection is trivial.
• Any kind of compression or encryption on the container image kills the message.
  

 

OpSec Level: Meh

You’d probably want to:

• Only use one LSB per pixel (maybe just Blue).

• Randomize altered pixels with a PRNG.
  

• Encrypt the payload beforehand.

   ...

But let’s be real—Chi-squared tests, histograms, stego‑detectors—if someone’s looking for it, they’ll find it.

Still, security through obscurity has its place (despite all the hate). Think authoritarian regimes where strong crypto might be illegal or where you might simply be forced to decrypt everything you own.
Just saying... it can be part of your 'onion'.


Malware Analysis Lab - The Barebones Setup

I’ve said before I’d blog about my lab setup. Never got around to it because I kept tweaking things or getting distracted by something shinier.

 Goal here: no fancy stuff, just a focus on working securely with malware.

My current setup:
- a dedicated Mini-PC.
- a managed switch which has a port isolated for the Mini-PC
- a VLAN dedicated to that host
- a Raspery Pi as Gateway/firewall/logger for that VLAN

 

A true minimal setup:

- Your laptop

- Two VMs:

• Flare VM (Windows + analysis tools)

• REMnux (Linux + reverse engineering toolkit)

Essentials:

• Keep malware VM networks disabled unless strictly needed

• Take frequent snapshots

• Log and document everything

• Don’t aim for perfect—just safe and functional

That's it. I won't go further into this for now. If I find the need, I'll do it later. What you want is something that will let you experiment with some safe malware samples, learn the basic tools and avoid having your home invaded by your baddies.


🧙‍♂️ Back to Narnia (OverTheWire)

Yup, I’m back at it. I paused these CTFs months ago—wasn’t getting much out of them. Realized I needed to read more about shellcode and memory handling before diving deeper.

So now I’m back. And yeah, I’m also changing my mind about avoiding walkthroughs. Everyone does them, so I might as well add my spin: fewer spoilers, more insights. You’ll find the step-by-step mess here on GitHub (don’t expect polish).

narnia0

What’s this one about? Buffer overflows and UTF-8 stuffsesses. Simple code:

                There's the Gibson <3

 

Buffer overflow by 4 bytes. The goal is to insert \xde\xad\xbe\xef in little-endian form.

First instinct was to strings, gdb, and objdump my way through. But you don’t need that. Just feed the program 20 garbage bytes (aaaaaaaa...) followed by those 4 crafted bytes.

Small snag: input is treated as UTF-8. So outputting raw 0xde didn’t work nicely.

Long story short, I learned that I couldn't easily output xde, and I did try, by looking at UTF-8/HEX lists, but it was a no go. I then decided to build a binary with printf:

printf "aaaaaaaaaaaaaaaaaaaa\xef\xbe\xad\xde" > /tmp/key
 

This solved the problem, but didn't elevate me to narnia1. A picture can explain more than a thousand words, and so a picture filled to the brim with words might be a wonder. So, here:

 

See at the top? the redirection is not returning an error message, but I am still user narnia0, and thus haven't really solved the issue. But why?
 

The issue is Linux related, to be fair. As we run the script with our payload, we're spawning a shell, but it is dying instantly since it's not connected to a tty. I needed to keep the shell opened, so I got the cat out of the bag. It forces the shell session to remain open and thus granting us permanence.
The shell is ugly, but we get elevated privileges (you can always load a nicer shell, if you really want to), and now we can search for the password. That's easy enough, so we can leave it out of this explanation.

 

That’s it for now. These blogposts are mostly memory aids and curiosity igniters. Narnia stuff goes to GitHub as I solve them, and I’ll post here only when there’s something worth rambling about.

 

Get your tools ready and keep exploring!

Why Won’t You Power Off?

                       

        "Beneath this mask there is more than flesh. Beneath this mask there is an idea, Mr. Creedy."

 

 I recently purchased an old-school Lenovo ThinkPad x260 - a beautiful little tank of a machine. It was in tip top shape: clean chassis, no keyboard shine, and great battery health. So, first things first: wipe Windows off the face of the earth and install Linux (not Arch, btw).

Everything was great ... except for this teeny tiny issue:

Even after shutdown, the laptop stayed warm. 

This typically means the system isn’t reaching a full ACPI S5 (soft off) or G3 (mechanical off) state.

 ...I didn't expect it to have any temperature issues, but I decided to play it safe, and installed lm-sensors, just to be sure. No worries there! The temperature was low, even after running some tests and forcing the CPU to do some work. So, the issue wasn't that it was overheating... perhaps it just wasn't shutting down properly?
After some testing, I confirmed that hypothesis: USB ports were still feeding power. The fan wasn't spinning, and there was no noise or visible lights, but something was still alive in there and refusing to go to sleep.

 

I tried to issue clean shutdown commands, with shutdown -P now, oldschool init 0, the desktop shutdown button, etc. You name it. Nothing forced the computer to turn off and the battery was still sipping away slowly. Plugging  a phone to the USB would charge the phone. You get the picture.

---

 

Step 1: Blame the BIOS

I quickly checked the BIOS setup (on this ThinkPad F1 does the trick) and went through the tabs:

- Disabled "Wake on LAN"

- Checked "Intel SpeedStep" and thermal profiles

- Ensured USB always-on charging was off

Note: this did not stop phone charging through USB.

- Even poked at virtualization, secure boot, and power-on behaviors

 

No luck. I all looked fine an dandy. And yet, the x260 continued to undead itself.

There was a slight mystery in that the power button worked 'strangely'. And by strangely I mean that the computer didn't connect directly when pressing the power button. But the reason was quite obvious. Since the computer was not properly shut down, I couldn't turn it on by just pressing the power button. I had to first keep the power button pressed for long enough to force a hard shut down. Only then did the computer shut down and allowed me to turn it on by pressing the power button.

---

 

Step 2: Linux Kernel Parameters, ACPI... huh, no?

So, I guessed I might as well go up a couple of layers and check the OS itself. Maybe the Kernel wasn't handling ACPI (Advanced Configuration and Power Interface) properly.

This led me to go and modify GRUB entries:

# In /etc/default/grub, change the following line:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force reboot=pci"

# Then update GRUB (Debian/Ubuntu):
sudo update-grub

...And reboot=hard, reboot=efi

( `acpi=force` forces the kernel to enable ACPI even if it thinks the BIOS doesn’t support it, and `reboot=pci`, `reboot=efi`, ... tell the kernel which reboot/shutdown method to try — in some buggy firmware cases, different paths behave differently

Also, please please and pretty please make sure to back up your current GRUB configuration before modifying it. Bad kernel parameters can sometimes prevent boot. You have been warned)

I also tested power off sequences with systemctl poweroff, shutdown -h now, and halt.

Same result every time: "Bye bye, mate. I'm going into zombie mode." 

I found the emergency reset button in the back of the x260, which cleared the battery state - cute. But not the fix either.

 

 

---

Step 3: It's elementary TPM,  my dear Watson Reader. 

Eventually, buried in a forum post, someone suggested disabling the security chip - also known as TPM (Trusted Platform Module) - in the BIOS.

Interesting. Why would a security chip interfere with system shutdown?

But hey! Let's try it.  And try I did. BIOS > Security > Security Chip, and I set it to disabled.

There was the option to switch between intel PTT (Intel's firmware-based implementation of TPM) and discrete TPM.

Boom! Disabling both solved the problem.

No... really. No more zombies in my machine.

 

 So, erm. What was all that about?

---

 

Step 4: Read up

TPM and ACPI can be tightly coupled, especially on systems originally designed to work with Windows. 

Firmware behavior is often not standardized across vendors, and ACPI implementations are notoriously inconsistent. 

When Windows is installed, in this case, it plays nicely with proprietary firmware handling of secure state transitions (shutdowns/hibernation). But Linux? That OS expects firmware to follow spec, not to have it silently ignore part of the validation process. 

By disabling the TPM, we cut off whatever interaction was confusing the firmware - and Linux finally does get a say in controlling the power sequence.

 

 Anecdote du jour: did you know that Torvalds once said something nice about ACPI?

 "ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce."

 

It must have been a Monday.

 

Should you, dear reader, disable TPM on your old machine?

Well, if you don't use full-disk encryption tied to TPM, yes I guess.

If you're using Linux and notice a behavior such as this, then certainly try it.

But if you do rely on TPM for encryption (why do you need to do that nowadays is beyond me) then be careful. TPM often stores or seals encryption keys. Disabling it can make your system unable to decrypt the disk unless you’ve backed up your recovery keys elsewhere.

 If you’re still facing power-off issues after all this, check if your BIOS firmware is outdated (I admit that this was my F plan, after all else didn't work... but I can be lazy like that). Lenovo occasionally issues updates that patch quirky ACPI or EC bugs, especially for Linux users.

---

 

Alright, that's it for today! I finally am getting my life-work-zen states figured out and aligned, so I'm getting a bit more time to do research and to document my work, which is totally awesome. So I hope to start posting a bit more frequently.

 

As always, enjoy the ride!

How a Spy Pixel Crashed Into My Friend's Vacation

 

         So it goes.

 

A friend of mine, a freelancer, recently went on a much-deserved vacation. Like most of us in today's always-on culture, she left an automated "I'm away" response on her email.

One day, she received a message from a client. Curious whether it might be urgent, she opened the email — but chose not to reply. A few hours later, she received another email from the same client:

"I know you opened our email. Can you please answer to our job offer?" 

Creepy material right there.

How in two hecks did the client know that she had opened their email and read their message, without her replying? The answer is tiny, technically invisible, and fascinating — a spy pixel!

 

                 There's totally a Spy Pixel there, trust me bro.

 

---

But what are they?

 

A spy pixel is a tiny, invisible image that gets embedded in emails. Usually just a 1x1 pixel, fully transparent, and basically impossible to spot by just looking at the email.

The moment your email app loads it — boom — it sends a signal back to whoever embedded it.

What's in that signal? Well, I'm glad you asked. It can include, at the very least:

- Your IP address (which can give away your rough location),

- The exact time when you opened the email,

- Your device type, OS, maybe even your browser,

- Whether you opened it multiple times or forwarded it to someone else.

 Here's her little spy:

<img src=3D"https://app.frontapp.com/api/1/noau= th/companies/5faa110782efdfc2d885/seen/msg_uugvds6/0/0a5b6123.gif" alt=3D"S= ent from Front" aria-hidden=3D"true" style=3D"width: 1px; height: 1px">

That image isn't there to show anything. It's there to quietly send metadata back to the pixel's creator.

---

Where and when are these buggers used?

 

You might be surprised — they're everywhere in digital communications. Here are some common uses:

• Email newsletters and marketing campaigns, to track open rates,

• Sales outreach tools, for engagement tracking,

• Transactional emails, just to confirm delivery.
  

But also in more questionable cases:

- Stalking or surveillance by controlling or manipulative individuals,

- Aggressive sales tactics, that cross boundaries (case in point: my friend),

- Phishing campaigns, to confirm which addresses are active.

And, for the most part — barring some exceptions — this stuff is completely legal.

---

Fear-mongering

 

I love some areas of cybersecurity, but I'm definitely not a fan of the constant fear-mongering I see everywhere.

This stuff is genuinely cool! And interesting. And did I say cool? But it has its downsides. Serious ones, especially when you are on the receiving end of it. Most people don't know these pixels exist, let alone how to block them.

 

                         I B Nautghy!

 

---

Action.

 

Are we allowed to lie to protect our privacy or avoid annoying people? I think we are. But that becomes hard when someone throws back:

• "We know you were at your computer yesterday."
•  "You say you didn't see our message, but we know you did."
• Or you try to browse anonymously, and the pixel exposes your location

This little guy can enable social engineering attacks by confirming your device type, when you were online, even whether you forwarded the email.

And, all that advice about "not clicking suspicious links"?

You didn't! You just opened the email. And that's all it takes

---

You gotta fight, for your right. (to party)

 

Thankfully, we've got defenses. Here are some of the basics:

• Block remote images in your email client (Thunderbird, ProtonMail, and others do this by default),

• Use privacy-focused email services that prevent images from auto-loading,

• Browser plugins like uBlock Origin can help if you're using webmail,

• Use a VPN to mask your IP and location,

• Or go hardcore and view emails in plain text only.

Just a heads-up: many mobile apps load images by default unless you manually turn that off. And in some cases, you can’t.

 

         Oops...

---

DIY Spy Pixel.

 

Want to try one for fun? Here’s a simple experiment:

1. Host a transparent 1x1 GIF or PNG on your own server.

2. Log image requests using your server (e.g., Apache, nginx, or a basic Flask script).

3. Add this to an HTML email:

<img src="https://yourdomain.com/tracker.gif" width="1" height="1" />

1. Send it to yourself.

2. Open it and check your logs — you'll probably see something like:

   • IP address

   • User-Agent string (your OS, browser, etc.)

   • Timestamp

Research how to do this stuff if it’s new to you. It’s a great little exercise and can be done in an afternoon.

---

Beyond the Pixel

 

Our tiny spy pal isn’t alone.

There’s a whole army of sneaky tools out there:

• Link shorteners with tracking redirects,

• Invisible iframes embedded in webmail,

• Email fingerprinting, using subtle code to track opens,

• Read receipts in platforms like Slack, Notion, and LinkedIn.

Once you notice this stuff, it’s everywhere.

---

A final dot.

Have fun exploring. Even if this isn't your favorite cybersec topic, it's a fun rabbit hole and might lead you to some unexpected discoveries.

 

And as always — enjoy the ride.