Olivia A. Gallucci

Packers modify executables to obscure contents, often through compression, encryption, or binary transformation. Packing may help with:

• Reducing file size
• Protecting IP (e.g., anti-debugging, anti-cheat, DRM routines)
• Evading detection 
• Hampering reverse engineering

The Ultimate Packer for eXecutables (UPX) and the MPRESS are examples of packers. In most settings, the packer itself isn’t malicious; it’s the content inside that determines intent. 

This article explains the language used in Apple security communities to discuss packing, and why traditional packers are uncommon on macOS compared to Windows. Most of all, I’ll explain why packing is almost always viewed as suspicious in the context of Apple security! :) 

Learn more: Obfuscated Files or Information: Software Packing – MITRE.

Packing on macOS

While packers are common on Windows, they are rare on macOS. A few cross-platform tools like UPX and MPRESS support Mach-O binaries, but usage on macOS is limited. In niche cases, such as demo scene releases or games with size constraints, third-party packers have been used, but even those uses are uncommon.

Apple’s security ecosystem also discourages packing. macOS’ Gatekeeper, Notarization, and Code Signing requirements make it difficult for packed binaries to function without triggering alarms or being rejected outright. I’ll explain this in more detail later. 

Furthermore, Apple devs use native tools and services that perform the security and IP-protecting functions associated with packers: size reduction, resource bundling, and encryption. But these are part of standard app lifecycle processes; for example, Code Signing, app thinning, and DRM-helpers, like FairPlay, AMFI, and App Store receipts. 

As a result, we don’t call them “packers,” and you won’t hear the term used in many Apple security discussions about these mechanisms. Instead, we refer to them by name.

Why does terminology and distinction matter? 

When we say “packer,” we mean a third-party tool used for obfuscation, especially those employed by malware authors.

This distinction is deliberate. Again, Apple has native systems that perform the same technical functions as packers (e.g., compression, bundling, code obfuscation). 

What can “packing” include? 

Adding to this confusion, packing is an umbrella term that may include (awesome packing): 

• Bundling: combines multiple files into a single executable
• Compression: reduces the executable’s size through compression
• Encoding: obfuscates the executable using reversible encoding schemes
• Encryption: obfuscates the executable using cryptographic techniques
• Mutation: modifies the executable’s code or instruction set (e.g., oligomorphism*) to evade static signatures.
• Protection: employs anti-debugging, anti-tampering, or similar techniques to resist reverse engineering
• Virtualization: translates code into a custom instruction set interpreted by an embedded virtual machine

* Oligomorphism is a technique where malware uses a limited set of encryption or code transformation routines to generate multiple variants of its payload while maintaining the same functionality.

Bruh, what about crypters? Crypters are often considered a subtype of packers, focused on encrypting payloads to evade static detection. In many cases, crypters and packers are used interchangeably, although technically they serve different purposes. In the same way that “hacking” is used broadly when people mean “cracking,” “packing” is often used loosely to describe any obfuscation technique, whether it’s compression, encryption, or runtime protection. 

Many tools include a mix of these features. The boundaries between “packer,” “protector,” and “crypter” are blurry, and context matters. Additionally, you’ll encounter researchers using these terms synonymously. Pay attention to context to understand exactly what the author is referring to, especially if you or the author is coming from a Linux or Windows background! :) 

Why are packers suspicious? 

TLDR: Given that Apple has native security protections and processes for packing functionality, it would be strange for Apple devs to use third-party packers! 

macOS has native mechanisms that handle most functionality typically provided by packers: compression, bundling, encryption, and anti-tamper protections. 

These are tightly integrated into Apple’s Code Signing and Notarization pipelines. As a result, legit macOS devs almost never use third-party executable packers. There’s no need, and doing so would break signing and trigger Gatekeeper alerts.

A chunk of my knowledge of Mac packers stems from Patrick Wardle, so I’ll provide some knowledge from him. Although no researcher is infallible, I often check his resources to measure my spidey senses. 

Though packing a binary doesn’t make it malicious per se, it’s rare to see a legitimate binary packed on macOS. – Patrick Wardle

In TOAMM vol. 2, he discusses that legit software is sparsely packed on macOS, so the presence of a packer is a strong red flag. 

“Malware authors are quite fond of packers, as compressed code is more difficult to analyze. Moreover, certain packers encrypt or further obfuscate the binary in an attempt to thwart signature-based detections and complicate analysis. Legitimate software is rarely packed on macOS, so the ability to detect obfuscation can be a powerful heuristic for tagging binaries that warrant closer inspection” – Patrick Wardle.

In practice, virtually any use of an executable packer on macOS should trigger your spidey senses. Given this, EDRs often flag packed software. 

Some packed malware history on Mac

However, that does not mean they have never been used.

The 2016 ransomware KeRanger hid its malicious payload inside a .rtf file that was actually a Mach-O executable packed with UPX 3.91. The OceanLotus APT group consistently packed their 2025 macOS backdoors with UPX to evade detection. Here, various EDRs, antivirus, and other security vendors failed to flag these because packer signatures for Mach-O files are scarce and not regularly updated. 

According to We Live Security, some packer detectors look for “UPX” markers in Windows PE files; Mac packer signatures are less common, so the same packed Mac binary might slip by some static scanners.

Sometimes security vendors point to executable packing as a contributing factor when detection occurs later in execution rather than at launch. However, Patrick Wardle’s research shows that third-party packed software on macOS is itself a signal that warrants inspection. Solutions that claim to offer advanced macOS protections should be capable of analyzing and monitoring packed binaries (at least) at a basic level.

Coldroot is another example of packed macOS malware. The RAT was shipped packed with UPX even though no benign Mac app would normally be UPX‑packed. Another 2025 Trojan (“Sliver” implants) was manually repacked with UPX and other bundling tools. 

“A Sliver binary will weigh in at around 10 MB or more, making it important that teams have solutions that can handle large executables. The Sliver project does not itself support further obfuscation or packing, but in the wild samples may be found with off-the-shelf or custom UPX packing” – Phil Stokes.

Also, there are Sliver samples masquerading as Apple software update used “off-the-shelf tools including UPX, MacDriver and Platypus” to obfuscate the payload. 

Note: MacDriver is now DarwinKit.

Still looking for packing resources? 

Other packers, outside UPX and IMPRESS, have been observed or are theoretically usable on some versions of macOS.

Pakr

Although it is deprecated, Pakr was an in-memory Mach-O packer that embedded an encrypted Mach-O payload inside a stub (in-memory Mach-O bundle loader). At runtime, the stub decrypted the payload and used NSCreateObjectFileImageFromMemory to load and execute it.

NSCreateObjectFileImageFromMemory is a function in Apple’s dynamic loader (dyld) API that takes a block of memory containing a Mach‑O image (usually a Mach‑O bundle) and creates an NSObjectFileImage from it. This object represents a Mach‑O image that dyld can link into the current process without reading it from disk via the normal dlopenpath. In other words, it lets you treat a Mach‑O binary loaded into memory as something dyld can work with. 

Learn more: 

• In-Memory Execution in macOS: the Old and the New by Manish Bhatt
• Understanding and Defending Against Reflective Code Loading on macOS by Justin Bui
• Allow Unsigned Executable Memory Entitlement by Apple

Platypus 

Platypus creates native macOS application bundles from interpreted scripts (shell, Python, Perl, Ruby, etc.) by packaging the script inside a .app bundle together with a small native launcher binary that runs that script.

Essentially, it takes a script and generates a standard macOS application bundle (.app) that users can launch like any other app. The bundle contains the script plus a stub binary that invokes the script through the appropriate interpreter. This lets you distribute scripts without requiring users to run them from Terminal. 

So, if you’ve read to this point, you might be wondering…  

Why are there so few packers for macOS?

TLDR: Mac malware authors were far fewer than on Windows, so few Mac-specific packing tools were developed. Moreover, macOS enforces code signing and notarization; most packers would break a signed binary unless the malware re-signs itself, which is nontrivial. Also, macOS apps commonly come as bundles or frameworks with scripts and resources, making simple “pack and unpack” less common. In short, Mac devs typically avoid packers, favoring frameworks or encrypted assets if needed. Apple’s ecosystem doesn’t encourage packing, so most packers are third-party or cross-platform, like UPX. In my past work, I recall that packers compress or encrypt instructions. Thus, you can detect them by high entropy or unusual section names (e.g., __XHDR, upxTEXT, __MPRESS__). In detection tools, these signatures flag UPX and MPress.

• __XHDR – A non‑standard Mach‑O segment name used by the UPX packer to hold UPX’s internal header or metadata when compressing an executable.
• upxTEXT – A UPX packer‑specific section (often inside a UPX segment) containing compressed executable code or related data introduced by UPX when it repacks a binary.
• __MPRESS__ – A packer‑specific segment name inserted by the MPRESS packer to store its compressed payload and stub instead of standard Mach‑O segments.

Mach‑O binaries normally use standard segments like __TEXT and __DATA, but third-party packers may rename or add segments or sections like these. As a result, some unpacking tools and static heuristics use nonstandard segments as a signal of packing. This behavior is not required by the Mach-O format. The loader (dyld) primarily enforces structural correctness and memory permissions rather than specific segment names. Renaming or creating new segments is therefore best understood as a side effect of custom packing, and a static indicator of obfuscation or non-native tooling.

Read: Understanding the Mach-O File Format by Travis Matthews and Parsing Binaries by Patrick Wardle. 

Now, let’s get into why packers are uncommon. 

App Store rules

First, Apple’s ecosystem App Store rules discourage heavy binary modification. A Developer ID-signed Mac app must not be altered after signing. Using a generic packer could break the signature and prevent the app from launching or raise macOS Gatekeeper warnings.

For example, UPX-compressed binaries often fail Apple’s code signature validation on macOS, causing “permission denied” or quarantine errors. This means legit Mac devs rarely bother with packers, instead relying on Apple’s app distribution compression or leaving binaries uncompressed. 

Resources: 

• When you don’t have permission to run an app on an M1 Mac – Eclectic Light Company  
• Can’t run app because of permission in macOS v11 (Big Sur) [closed] – Stack Overflow 

Code signing and runtime protections

Another big reason for the lack of packers is Apple’s Code Signing, and runtime protections. macOS requires apps to be signed and uses a Hardened Runtime that prevents self-modifying code. 

If a developer packed their app, they would typically compress and/or encrypt the main binary and include a stub loader to unpack at runtime. But that unpacking process often involves generating new executable code in memory. Apple’s Hardened Runtime forbids running unsigned code or modifying code segments on the fly unless the app has special entitlements (e.g., JIT compilation entitlement). 

“Specifically, due to privacy concerns, Apple does not allow any process, even trusted security tools, to read the “remote” memory of another process. This means if you are a hacker your reflectively loaded payloads are safe from any (non-kernel-mode) macOS security tool, as such tools are essentially blind to what other processes are doing in-memory! As Matt Suiche put it: “memory scanning capabilities on macOS are pretty bad in general. But [the] abolition of kexts for macOS will definitely make it impossible to access [remote] memory.” Kernel extensions (kexts) can read arbitrary processes’ memory, including reflectively loaded payloads. However, they have been wholly deprecated (essentially abolished)” – Patrick Wardle.

A legit dev likely won’t want to deal with those complexities… Even if they did, the app might be flagged by Apple’s notarization or crash due to code signing violations. This friction makes generic packers on Mac less practical. 

In fact, System Integrity Protection (SIP) and code signing’s design means any change to an on-disk binary post-signing invalidates the signature. 

How can a packer work? 

Thus, packers must either forego signing, or run before code signing (embedding the packed data and an unpacker, then sign the whole package). 

KeRanger’s authors, for example, packed the payload then signed it with a stolen developer certificate, a trick not available to average developers. You’d have to essentially commit identity fraud via stolen certs from compromised devs or orgs (like KeRanger). Alternatively, you could: 

• Use enterprise provisioning profiles to sign malware internally.
• Register fake companies to get certs through social engineering or exploiting weak verification by Certification Authorities… though Apple has stricter vetting now. 

Less people

Another factor is demand. 

Historically, macOS had a smaller share of users, and thus, malware, so fewer Mac packers were developed. Windows malware faces an army of signature-based AV engines, so packers are needed to constantly morph malware. 

Apple’s aggressive notarization and Gatekeeper checks (which block unsigned/un-notarized apps by default) also change the attack surface. Many malware attacks focus on social engineering the user to run something, rather than sneaking past AV with packers. 

Even today, threat actors often find easier ways to evade detection, like using AppleScripts or abusing trusted system components. They didn’t (and still don’t) need complex packers as frequently. 

However, this might change as Mac threats increase. Additionally, Apple’s XProtect (built-in AV) and Gatekeeper provide a strong baseline of protection, which many people consider sufficient. 

In fact, some folks claim third-party vendors only create problems, and that macOS-specific antivirus companies thrive on fear. That doesn’t mean third-party tools have no place in managing (or securing!) Macs. But, you need to understand exactly what that software is doing, and how it interacts with macOS.

The best way to do that is by exploring open-source tools or vendors with a proven track record of building Mac-native software. They should be able to demonstrate, technically, how their tools complement or enhance Apple’s existing security. Most of all, vendor blogs from talented Apple security researchers does not always equal a focused, well-resourced macOS product team.

---

Rant

~Occasionally~ vendors charge for features that can be implemented with a script and your existing MDM. Their marketing often suggests they’re rivaling Apple’s 1,000+ security engineers.

In reality, many vendors prioritize Windows and Linux, and their macOS marketing often reveals fundamental misunderstandings of macOS security protections. I often wonder if these vendors consistently (if ever) outperform Apple’s built-in controls.

Before buying, I’d ask to speak directly with product engineers, or try to keep up with EDR security folks at conferences. Push for details on their macOS teams’ scope and focus. You’ll (hopefully) see whether they’re solving hard problems or just reselling configuration profiles.

Just because a successful vendor offers a product, does not mean it is a good product, especially when it comes to macOS.

End of rant.

---

This attitude may contribute to fewer packers. If fewer defenders are scanning Mac binaries for signatures, there’s less pressure on attackers to pack them. I could simply use unsigned code or new languages (discussed below) to evade detection. 

Conclusion 

In summary, I think the combination of technical barriers (e.g., code signing) and historical low demand means not many packers were created for macOS. Even today, packing a Mac binary is tricky. But as shown with UPX in OceanLotus and KeRanger, they are used by some Mac malware. 

If you enjoyed this article on packers, consider reading Signature-Based Analysis for Reversing. My next post will be on code obfuscation techniques on Mac, outside of packing! :D