![\"VirusTotal](\"./rcl-vti-tmp.png\")
Distilling what a Red Team does can be difficult at times, because frequently\npeople focus on the tactical findings: this vulnerability, that\nmisconfiguration, some control that didn't work or doesn't exist. Those are all\nvaluable and important aspects of the work, no doubt, and they're the common\nartifacts of operations. But they're not the essence.
\nI like Andy's characterization of red teaming as a truth-finding function, and\nit's very close to how I've been describing the work as well. Taking a\ncontrarian position to a given claim (\"Our data is secure.\") and then working to\nvalidate that hypothesis, to find the truth.
", "date_published": "2026-08-05T18:11:29.239Z", "date_modified": "2026-08-05T18:11:29.239Z", "tags": [ "quote", "offensive security", "red team" ] }, { "id": "https://hackd.net/posts/prompt-injection-as-role-confusion/", "url": "https://hackd.net/posts/prompt-injection-as-role-confusion/", "external_url": "https://role-confusion.github.io/", "title": "Prompt injection as role confusion", "content_html": "It seems intuitively true that it is not possible to secure a system with an\napproach that's enmeshed with the input mechanism through which attacks also\narrive; we've done much better using out-of-band controls to avoid commingling\ncode and data. Still, it's great to see this research land and confidently show\nthis:
\n\n", "date_published": "2026-06-23T03:52:27.233Z", "date_modified": "2026-06-23T03:52:27.233Z", "tags": [ "ai", "llm", "security" ] }, { "id": "https://hackd.net/posts/we-are-living-in-pinocchios-world/", "url": "https://hackd.net/posts/we-are-living-in-pinocchios-world/", "external_url": "https://om.co/2026/05/25/we-are-living-in-pinocchios-world/", "title": "We are living in Pinocchio's world", "content_html": "Role tags were a formatting trick that became the security architecture and\nthe cognitive scaffolding of modern LLMs. We've shown that this architecture\ndoesn't survive into the model's actual representations, and that such role\nconfusion is linked to prompt injection.
\nUnless LLMs achieve genuine role perception, we think injection defense will\nremain a perpetual whack-a-mole game. And the continuous nature of role\nboundaries opens the threat of injections designed to subtly shift LLM states\nthrough seemingly innocuous text, legally and at scale.
\n
\n\nThe grifters and the hucksters and the influencers selling impossible things\nsucceed because audiences reward certainty and punish doubt. They honor\nconfidence and resist complication. A clean story about a genius who will fix\neverything travels faster than a difficult story about tradeoffs.
\n
Skepticism is always healthy. Mostly everything has trade-offs, apparent or not,\nso you have to keep going until you can see their shape.
", "date_published": "2026-06-03T17:06:56.518Z", "date_modified": "2026-06-03T17:06:56.518Z", "tags": [ "quote" ] }, { "id": "https://hackd.net/posts/uv-lockfiles-and-malware-on-pypi/", "url": "https://hackd.net/posts/uv-lockfiles-and-malware-on-pypi/", "title": "uv lock files and malware on PyPI", "content_html": "I'm pretty sure that saying \"software supply chain security is important\" won't\nwin anyone a prize, yet we see quite an alarming ramp-up in malicious campaigns\nthat take advantage of various gaps in the space, despite all the industry\nattention. Some problems take time to fix, but there's a lot more we could be\ndoing today that isn't for lack of technology, but organizational friction.\nAnyway, we're not here to discuss that right now.
\nThe LiteLLM compromise was interesting to watch, especially the\nimpact on downstream consumers. Essentially, everyone that installed or happened\nto update the LiteLLM package (or something that depended on it) got\ncompromised, as the newest (malicious) version was pulled in their environment.
One of the ways to reduce this kind of thing from happening is to use lock files\nin the package managers that support them. Lock files are a record of all\ndependencies for a given package, including versions and cryptographic hashes.\nUpdating the lock file happens intentionally, during development, but deploying\nthe package in production uses the lock file as-is, installing known-good\nversions as specified. This also has some other non-security related properties,\nlike making sure the versions of packages you're deploying won't magically break\nthings because of upstream changes. So you do your dev work, add deps as needed,\nupdate the lock file, and ship that. It's also best practice to pin your\ndependencies to a specific version (like ==X.Y.Z) instead of using softer\nconstraints that may allow for updates (e.g., >=X.Y.0 installing X.Y.23).\nThis pinning usually happens in a configuration file adjacent to the lock file,\nlike pyproject.toml or Cargo.toml.
Let's talk concretely about Python:
\npyproject.toml.uv because it actually lets you create and use a lock file, uv.lock\n(and it's fast).uv sync and record all package versions, hashes, and download\nURLs in the lock file.uv sync --frozen which will only use what's\nin the lock file, installing the same package versions regardless of upstream\nchanges. This uses the URLs directly, and won't check for any newer versions\nof packages, even if the constraints would allow for updates.PyPI is the free package hosting and distribution solution for Python, and it's\na wonderful service to be grateful for. It's where uv (and pip) look for by\ndefault for any Python dependency. So usually uv.lock will contain quite a few\nentries for things hosted there, and download URLs like\nhttps://files.pythonhosted.org/packages/12/34/big-hash/my_pkg-X.Y.Z-py3-none-any.whl\nwhich provide the location of my-pkg at version X.Y.Z.
But what if version X.Y.Z is compromised and malicious? Well, PyPI or a\nmaintainer can delete it, which removes the package from the index, and it won't\nbe installable anymore.
Well, not quite.
\nThe package does get removed from the index, true, but the URL remains active\nas a result of how storage works, and the PyPI CDN will happily continue\nserving it. Which means subsequent uv sync --frozen invocations will install\nthat malicious package, since this form doesn't consult the registry anymore,\nand just directly fetches the URL.
So, if during the window of time that an upstream package is compromised, one or\nmore lock files get updated to point to that malicious URL, the bad package will\nstill get installed. There can be a delay here until a defender might see these\nlock files deployed, especially given the nuance of unpinned versions and other\nthings, so having an effective inventory of all installed packages to query is\nvery important to properly address this. Package aging (delaying updates) and\nother mitigations are also part of the defensive story here, but ultimately it's\nworth knowing what gets installed and where.
\nThis isn't really the fault of PyPI or uv, just how these two things\ninterplay. uv is thinking about the problem and how to fix it.
Every time new technology comes out and becomes widely available, there is a\ndifficult balance to be found between the exuberance of early adopters—keen to\ndrive broad usage and land early wins unlocked by the new thing—1and those\nwho would seek to better understand the downsides before going too deep. There\nare essential (and obvious) risks none disagree on, but these are few. The real\nchallenge is in negotiating the middle-ground, all the second+ order effects.\nIt's fair that neither side prevails unchallenged2.
\nMy primary perspective comes from doing Security Engineering work across\ncompanies of different sizes (and cultures), some defense but mostly offense. On\neither side though, I've largely thought about what the new technology amplifies\nin terms of risk. Today, of course, it's LLMs, but the problem space is fractal:\nwe run into variants3 of the same meta issues all the time in security,\nbecause that's the nature of our work. Something shiny, often useful, almost\nnever designed with safety4 as a primary property.
\nYet, in accepting that we cannot wait for good-enough guardrails around new\ntechnology within certain time constraints, we also do not get to abdicate our\nresponsibility for the choice of using such tech. We might not be aware of all\nthe specific second+ order effects, but we can be sure they exist5.
\nSo it is with LLMs and all they've recently unlocked in terms of working with\nsoftware and systems (e.g., code assistance, vulnerability discovery, semi- or\nfully- autonomous personal agents). Broadly, we've been able to convert A LOT of\nideas into running code, and got some pretty funny and clever things out, too.\nQuite fast, generally. Yet, all of this software remains the responsibility of\nwhatever human actor is ultimately at the top of the pyramid, and we should\nneither pretend otherwise, nor enable unaccountability in this regard.
\nThere are situations where and simply using whatever the LLM generated for code\nis fine without paying it too much attention: prototypes, one-off scripts, even\ntools that would only ever impact that human if there was a problem (i.e., skin\nin the game), etc.
\nYet for code that's to be shared with other people it remains the human's\nresponsibility to review it, ensure its quality, and do so both in terms of\nrespect, and empathy, before sharing it in the first place. That human is still\nresponsible.
\nI really enjoyed reading (and recommend) both Russ Cox's\npost in golang-dev@\non suggestions for how to approach aspects of this issue in that project, and\nthe Oxide RFD (576) he mentions.
I happen to know how to use em-dashes; this article is 100% organic. ↩
\nEven this concession is uncomfortable for some cultures, which would much\nrather build up a high degree of confidence/containment before allowing\nanything. This moves into a different discussion on risk, and while that\nconversation is interesting and worth iterating on, it is not how things\ncurrently work in practice. ↩
\nInjections of all kinds are as old as computing, as is the unsafe mixing of\ncode and data. ↩
\nI think of safety in general, not just security. They are deeply\nintertwined, yet the actual, meaningful property we should strive to deliver\nupon has to be safety; security is a critical and related, but not\nidentical, attribute. ↩
\nAt a macro scale this gets complex, and we see plenty of imbalances in who\npays for these externalities; it's why we have regulations for some things,\nfrequently the result of socialized negative outcomes we want to avoid\nrepeating. ↩
\nA nice bit of technical detail on how to achieve a privacy-preserving\nimplementation for email push. I hope many people would care about such details,\nthough realistically I'm unsure of it. It's one of those things that can be done\nquickly, easily, and poorly; or with a little more effort and attention, quite\nwell.
", "date_published": "2026-02-07T02:19:10.320Z", "date_modified": "2026-02-07T02:19:10.320Z", "tags": [ "privacy" ] }, { "id": "https://hackd.net/posts/capabilities-for-agent-delegation/", "url": "https://hackd.net/posts/capabilities-for-agent-delegation/", "external_url": "https://niyikiza.com/posts/capability-delegation/", "title": "Capabilities for agent delegation", "content_html": "This is one of the more interesting ideas I've come across in terms of securing\nagentic workloads.
", "date_published": "2026-01-09T00:55:52.102Z", "date_modified": "2026-01-09T00:55:52.102Z", "tags": [ "ai", "llm", "security" ] }, { "id": "https://hackd.net/posts/atuin-and-tailscale-and-containers-and-1password/", "url": "https://hackd.net/posts/atuin-and-tailscale-and-containers-and-1password/", "title": "Atuin and Tailscale and containers and 1Password", "content_html": "I'm not sure how it took me this long to discover1 atuin but I've been\nmissing out for sure. Atuin is essentially (much) \"better shell history\" in a\nbunch of ways, as it:
\nThat last feature was one of the things I was most excited about, although 2 is\nreally great as well in practice. While there is a public sync server available,\nI thought I should run and host my own, given that's an option and I'm that sort\nof person.
\nSo, we're setting up a self-hosted Atuin sync server reachable via Tailscale,\nrunning in containers (Podman, but Docker would work), with 1Password providing\nsecrets management, running on macOS. The completed configuration is available\non GitHub, if you want to skip ahead. The documentation from Atuin is\npretty thorough, but I did have to figure out a bit more glue, hence this post.
\nI use Podman as most container workloads don't need root. In this particular\nsetup, we'll deploy 3 containers via podman-compose:
Setting up the Postgres and Atuin containers is pretty well-covered in the\nofficial self-hosting docs, though I did have to figure out a\nsmall thing and ended up submitting a PR to fix the upstream docs.
\nAnnotated container config:
\natuin:\n image: ghcr.io/atuinsh/atuin:latest\n # start after the DB and Tailscale\n depends_on:\n - db\n - tailscale\n restart: always\n command: server start\n # Make config persistent\n volumes:\n - './config:/config'\n # Map the ports\n ports:\n - 8888:8888\n environment:\n # Listen an all interfaces.\n ATUIN_HOST: '0.0.0.0'\n # same port as above\n ATUIN_PORT: 8888\n # I don't keep registration open generally, but you probably need to set\n # this to \"true\" once to set up a first account.\n ATUIN_OPEN_REGISTRATION: 'false'\n # These env vars will be injected later. Make sure that `db` matches your\n # database container's name!\n ATUIN_DB_URI: postgres://${ATUIN_DB_USERNAME}:${ATUIN_DB_PASSWORD}@db/${ATUIN_DB_NAME}\n RUST_LOG: info,atuin_server=debug\n network_mode: service:tailscale\nThe main trouble I had was the DB container name not matching the ATUIN_DB_URI\nstring. Now that the upstream docs are fixed, it's unlikely you'd run into this\nissue.
Given that we're using Tailscale to access the server, I don't worry about\nsetting up TLS.
\nAnnotated container config:
\ndb:\n image: postgres:17\n depends_on:\n - tailscale\n restart: unless-stopped\n volumes:\n # Don't remove permanent storage for index database files!\n - './database:/var/lib/postgresql/data/'\n # If the WAL ever gets corrupt (e.g., due to abrupt container stops), fix it with:\n # docker run -it -v ./database:/var/lib/postgresql/data/ postgres:17 /bin/bash\n # su postgres && cd /var/lib/postgresql/data && pg_resetwal\n environment:\n POSTGRES_USER: ${ATUIN_DB_USERNAME}\n POSTGRES_PASSWORD: ${ATUIN_DB_PASSWORD}\n POSTGRES_DB: ${ATUIN_DB_NAME}\nWe want our Tailscale container to be able to route to and from our Atuin\nserver, while being able to independently authenticate to the network so that we\ndon't lose connectivity periodically. Tailscale docs are pretty good on how to\nset up containers, including OAuth configuration.
\nAnnotated container config:
\ntailscale:\n image: ghcr.io/tailscale/tailscale:latest\n restart: always\n # TS_AUTHKEY from the OAuth config\n environment:\n TS_AUTHKEY: ${TS_AUTHKEY}\n TS_HOSTNAME: atuin\n TS_STATE_DIR: /var/lib/tailscale\n TS_EXTRA_ARGS: --advertise-tags=tag:container\n volumes:\n - './tailscale:/var/lib/tailscale/'\n devices:\n - /dev/net/tun:/dev/net/tun\n cap_add:\n - net_admin\nI've known for a while that 1Password has a CLI integration, allowing secrets\naccess from the command line, in scripts etc. This seemed like a good spot to\ntry that. My approach was to reference the secrets as environment variables (via\nmise), have their values be paths into a 1Password vault, and start my\ncluster by having op inject the values at start-up time.
So, for example, to set the database password for Atuin, in mise.toml I have:
[env]\nATUIN_DB_PASSWORD = \"op://Personal/atuin/password\"\nWith the finished compose.yaml for the cluster, and having set up the\nrespective secrets in 1Password, all that's left to do is:
op run -- podman compose up -d\nThis should prompt for authentication with 1Password, and then bring up all the\ncontainers and have everything ready to go! As mentioned, you may need to allow\nfor registration once, to set up one account that you'll use. Or keep it on if\nyou're doing this for a team, friend group, polycule, etc. Given the server has\nto be reached over Tailscale, it won't matter too much if you leave this on.
\nIf you have issues, check the logs for clues. I've had the occasional issue with\nthe DB WAL.
\npodman compose logs -n -t -f\nYou can also configure 1Password integration (and mise populating the env) is\nworking as expected by printing the environment unmasked:
op run --no-masking -- printenv # might want to pipe into grep ATUIN\nGet Atuin (the client) from the official place or use homebrew /\nanother package manager of your choice. You'll need a little configuration to\ntell your client which is the right server to use.
Here's my (annotated) configuration as an example, but only the sync_address\nis really needed. For the rest, find what works for you, and make sure to look\nat the Atuin docs:
# Tailnet address and correct port; remember this is HTTP.\nsync_address = \"http://atuin.<your-tailnet>.ts.net:8888\"\n# Workspaces use per-git-repository history, rather than directory-only\nworkspaces = true\n# Prefer to see the workspace history by default.\nfilter_mode_shell_up_key_binding = \"workspace\" # or global, host, directory, etc\n# Run commands directly; tab to edit.\nenter_accept = true\n# Use Ctrl-0 .. Ctrl-9 instead of Alt-0 .. Alt-9 UI shortcuts; better on macOS.\nctrl_n_shortcuts = true\n# Invert window?\ninvert = false\n# Window style\nstyle = \"auto\"\nAt this point you should be able to run atuin status and see you're green and\nconnecting to the server you've just configured!
It was probably\nthis comic by Julia\nEvans that finally made me look. ↩
\nReflective code loading is an interesting attack technique, useful when\nthere's a desire to conceal or protect the code that's being executed on a\nsystem. This is primarily accomplished by avoiding the creation of any files on\ndisk (e.g., downloading the binary that's then going to run) or other execution\nartifacts that would become indicators of behavior. Instead, code can be\ndownloaded and executed directly in the memory of an otherwise benign process.\nWhile not completely interchangeable, sometimes we see this technique also\nreferred to as \"fileless\", \"artifact-free\", and/or \"in-memory (only)\" as those\nare desirable characteristics.
\nProbably the best known implementation of this technique on macOS relies on\nfunctionality exposed by dyld, and first documented in \"The Mac Hacker's\nHandbook\" by Dino Dai Zovi and Charlie Miller in 2009, though it's been\nalso discussed/popularized by Patrick Wardle at BlackHat 2015, and by\nStephanie Archibald at INFILTRATE '17. The high-level approach is:
MH_EXEC to\nMH_BUNDLE - needed for the subsequent steps as the necessary APIs expect a\nbundle1NSCreateObjectFileImageFromMemory to, well, create an object file from\nthe memory region that contains the binaryNSLinkModule to link in the necessary shared librariesThis technique has been used by malware authors rather recently, notably the\nLazarus Group in the 2019 version of Apple Jeus.
\nThere's just one thing: this technique hasn't been truly fileless for… some\ntime.
\n@bluec0re initially got me looking into this in\ndepth, after noticing during a debug run that artifacts are, in fact,\ncreated when these specific functions are called. Given the public perception\naround this in-memory loading technique, this was a bit of a surprise, so I\nspent some time doing a bit more research and putting it together for this\nanalysis.
\nI used @its_a_feature's simple\nmacos_execute_from_memory PoC for testing (there's also Archibald's\nPoC, for historical reference). For convenience/ease of\niteration, these PoCs do actually load a target binary from disk, rather than\nover the network, but the execution is meant to be in-memory only.
\nTo figure out what's going on, a good starting place is to run the code while\nprinting anything that has to do with dyld, given that's where the two\nfunctions are. There are some helpful environment variables to set before\nrunning the code:
clang -g -o main main.c\nDYLD_PRINT_APIS=1 DYLD_PRINT_LIBRARIES=1 ./main\n// some output ellided\ndyld[80184]: NSCreateObjectFileImageFromMemory(0x105010000, 0x00008258)\ndyld[80184]: NSCreateObjectFileImageFromMemory() copy 0x105010000 to 0x10501c000\ndyld[80184]: NSLinkModule(0x6000029d4270, module)\ndyld[80184]: dlopen(\"/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-VTd6S38q\", 0x80000080)\ndyld[80184]: <DDBBB7CE-78F7-3E78-AD09-2C79ED030E2A> /private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-VTd6S38q\ndyld[80184]: dlopen(NSCreateObjectFileImageFromMemory-VTd6S38q) => 0x20a24d4a0\ndyld[80184]: NSLinkModule(0x6000029d4270, module) => 0x20a24d4a0\ndyld[80184]: NSLookupSymbolInModule(0x20a24d4a0, _execute)\ndyld[80184]: NSLookupSymbolInModule(0x20a24d4a0, _execute) => 0x105037f84\nold timey mode: Executed!\ndyld[80184]: NSUnLinkModule(0x20a24d4a0)\ndyld[80184]: dlclose(0x20a24d4a0)\ndyld[80184]: NSDestroyObjectFileImage(0x6000029d4270)\nLooks like NSLinkModule uses dlopen to load the\nNSCreateObjectFileImageFromMemory-VTd6S38q file from a temporary location. To\nconfirm and get a bit more detail, I monitored the execution of ./main using\nPatrick Wardle's File Monitor to see what files are being accessed. To\nnarrow the output, I'm piping this through jq to filter out for events related\nto the PoC, and extracting only the type and the file destination for each\nevent:
sudo /Applications/FileMonitor.app/Contents/MacOS/FileMonitor | \\\njq '.\n | select(.file.process.path | contains(\"macos_execute_from_memory/main\"))\n | {event: .event, dest: .file.destination}' | \\\ntee filemon-filtered.json # also saving for futher analysis\n# start ./main in another terminal, Ctrl-C the FileMonitor process when done\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_OPEN\",\n \"dest\": \"…/macos_execute_from_memory/test.bundle\"\n}\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_CLOSE\",\n \"dest\": \"…/macos_execute_from_memory/test.bundle\"\n}\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_CREATE\",\n \"dest\": \"/private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-7zEgh32K\"\n}\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_WRITE\",\n \"dest\": \"/private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-7zEgh32K\"\n}\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_CLOSE\",\n \"dest\": \"/private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-7zEgh32K\"\n}\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_OPEN\",\n \"dest\": \"/private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-7zEgh32K\"\n}\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_CLOSE\",\n \"dest\": \"/private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-7zEgh32K\"\n}\n// open-close twice more\n{\n \"event\": \"ES_EVENT_TYPE_NOTIFY_UNLINK\",\n \"dest\": \"/private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-7zEgh32K\"\n}\nDuring the execution of ./main a file is created, accessed a few times, then\ndeleted. The name changes slightly with every run (the 7zEgh32K above,\ncompared to VTd6S38q previously) and based on the path it's fairly obvious\nthis is a temporary file. I wanted to understand more about when it's created,\nand if its presence means this particular technique is no longer as interesting\nas we once thought: it can be replaced with a much less brittle combo of\ndlopen and dlsym, but it's also not artifact-free.
So next I ran ./main in lldb with a breakpoint on\nNSCreateObjectFileImageFromMemory, stepping through instructions to figure out\nwhat's going on:
(lldb) b NSCreateObjectFileImageFromMemory\nBreakpoint 1: where = libdyld.dylib`NSCreateObjectFileImageFromMemory, address = 0x0000000180314fa0\n(lldb) r\nProcess 94604 launched: 'macos_execute_from_memory/main' (arm64)\nProcess 94604 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1\n frame #0: 0x000000018e3b8fa0 libdyld.dylib`NSCreateObjectFileImageFromMemory\nlibdyld.dylib`NSCreateObjectFileImageFromMemory:\n-> 0x18e3b8fa0 <+0>: mov x3, x2\n 0x18e3b8fa4 <+4>: mov x2, x1\n 0x18e3b8fa8 <+8>: mov x1, x0\n 0x18e3b8fac <+12>: adrp x8, 366208\nTarget 0: (main) stopped.\nAfter for a while we eventually get to\ndyld4::APIs::NSCreateObjectFileImageFromMemory(void const*, unsigned long, __NSObjectFileImage**)\nwhich superficially looks like the function called in main.c but, as we'll see\na bit later on, is not.
Continuing on we reach first\nlibdyld.dylib\\NSCreateObjectFileImageFromMemoryand thendyld`dyld4::APIs::NSLinkModule(__NSObjectFileImage*,\nchar const*, unsigned\nint)in a similar fashion. Here we'll see a call tomkstemp` that's a give-away\nwe're likely creating a temporary file:
(lldb)\nProcess 97220 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into\n frame #0: 0x000000018e3bdea8 libdyld.dylib`dyld4::LibSystemHelpers::getenv(char const*) const\nlibdyld.dylib`dyld4::LibSystemHelpers::getenv:\n-> 0x18e3bdea8 <+0>: mov x0, x1\n 0x18e3bdeac <+4>: b 0x18e3c329c ; symbol stub for: getenv\n\nlibdyld.dylib`dyld4::LibSystemHelpers::mkstemp:\n 0x18e3bdeb0 <+0>: mov x0, x1\n 0x18e3bdeb4 <+4>: b 0x18e3c336c ; symbol stub for: mkstemp\nTarget 0: (main) stopped.\n(lldb)\nProcess 97220 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into\n frame #0: 0x000000018e3bdeac libdyld.dylib`dyld4::LibSystemHelpers::getenv(char const*) const + 4\nlibdyld.dylib`dyld4::LibSystemHelpers::getenv:\n-> 0x18e3bdeac <+4>: b 0x18e3c329c ; symbol stub for: getenv\n\nlibdyld.dylib`dyld4::LibSystemHelpers::mkstemp:\n 0x18e3bdeb0 <+0>: mov x0, x1\n 0x18e3bdeb4 <+4>: b 0x18e3c336c ; symbol stub for: mkstemp\n\nlibdyld.dylib`dyld4::LibSystemHelpers::getTLVGetAddrFunc:\n 0x18e3bdeb8 <+0>: adrp x16, -5\nTarget 0: (main) stopped.\nRight after the return from mkstemp, I checked the temporary file location to\nsee a file created there:
fd NSCreateObjectFileImageFromMemory /private/var/folders/\n/private/var/folders/q8/28dylf2973q_22bqzy2_lplr0000gn/T/NSCreateObjectFileImageFromMemory-wySJJ7WJ\nThe SHA-256 checksum of this temp file matched the SHA-256 checksum of the file\nthat was loaded in-memory by the PoC, so it's pretty clear at this point that\nNSLinkModule writes the file out, then uses dlopen to load it back to do the\nrest. dlopen is part of a stable API, unlike the long-deprecated\nNSCreateObjectFileImageFromMemory and NSLinkModule.
Apple publishes the source code to dyld, though with some delay\nafter the corresponding OS release that introduces a new version. For example,\nthe latest available source is 852, which corresponds to macOS 11, but\nthe current macOS 12.2 version is dyld-941.5.
strings /usr/lib/dyld | rg \"dyld-\\b\\d\\d\\d\\b\" # also /System/Library/dyld/dyld_shared_cache_arm64e\n@(#)PROGRAM:dyld PROJECT:dyld-941.5\nAn interesting fact is that the function we saw earlier as\ndyld4::APIs::NSCreateObjectFileImageFromMemory is from the dyld4 namespace,\nwhich is not present in any of the source code releases (there's only dyld and\ndyld3 respectively.) During debugging I saw a few functions called that are\npart of the dyld3 namespace, so my guess is that all of these will coexist, at\nleast for a while. For the purposes of this analysis, I'll focus on the\n852 version of dyld, but I'll keep an eye out for whenever 941 drops,\nto check out dyld4 there.
There are a few implementations of NSCreateObjectFileImageFromMemory in the\nsource for 852, in:
src/dyldAPIs.cpp\nadded with the dyld-43 release, about 17 years ago.src/dyldAPIsInLibSystem.cpp\nadded by dyld-519.2.1 in 2017dyld3/APIs_macOS.cpp\nwhere the relevant portion was also added with dyld-519.2.1 in 2017.The same is true for NSLinkModule, just a few lines below in those same files.
It looks like gUseDyld3 controls whether the version that's being used is the\none in the dyld3 namespace, versus the \"original\" from the dyld-43 release.\nThere are a few places this is assigned to throughout the code base, though only\none spot where it's set to true, in\nlibdyldEntryVector.cpp.\nFollowing the path further through the build config files in Xcode and the\nsource itself, I believe the entry vector is a dependency to building\nlibdyld.dylib. So that's how we get to the code path that uses the new\n(dyld3) implementation of NSCreateObjectFileImageFromMemory and\nNSLinkModule, the latter of which creates a temp file and loads it via\ndlopen.
I admit that, while researching, I went through a few different theories as to\nwhen this behavior changed. Given I hadn't seen anyone discuss it, seemed like a\nrecent change. But when I began tracing through the dyld source, I figured\nmaybe this changed around 2017 when the initial dyld3 code was added, and\nsomehow nobody noticed. I even went to search VirusTotal for files named\naccording to this pattern, and found quite a few, dating back to 2018.
Somehow though, nobody noticing just… didn't seem right?
\ndyldWhile version 941.5 isn't out, I was curious to check out how execution of this\ncode path looks now, so I opened my local copy of dyld in Ghidra. Searching\nfor NSLinkModule returned a single location, in the dyld4 namespace as we\nexpected. The decompiled2 code does bear resemblance to the source in\nversion\n852:
void dyld4::APIs::NSLinkModule(__NSObjectFileImage*, char const*, unsigned int)\n\n{\n int iVar1;\n char *pcVar2;\n size_t sVar3;\n undefined8 uVar4;\n long *plVar5;\n char acStack1096 [1024];\n long local_48;\n\n local_48 = ___stack_chk_guard;\n if (*(char *)(param_1[1] + 0x90) != '\\0') {\n dyld4::RuntimeState::log(param_1,\"NSLinkModule(%p, %s)\\n\");\n }\n if (param_2[1] == (char *)0x0) {\n uVar4 = 0;\n }\n else {\n *param_2 = (char *)0x0;\n pcVar2 = (char *)(**(code **)(*(long *)param_1[0xd] + 0x80))((long *)param_1[0xd],\"TMPDIR\");\n if ((pcVar2 == (char *)0x0) || (sVar3 = _strlen(pcVar2), sVar3 < 3)) {\n _strlcpy(acStack1096,\"/tmp/\",0x400);\n }\n else {\n _strlcpy(acStack1096,pcVar2,0x400);\n sVar3 = _strlen(pcVar2);\n if (pcVar2[sVar3 - 1] != '/') {\n _strlcat(acStack1096,\"/\",0x400);\n }\n }\n _strlcat(acStack1096,\"NSCreateObjectFileImageFromMemory-XXXXXXXX\",0x400);\n iVar1 = (**(code **)(*(long *)param_1[0xd] + 0x88))((long *)param_1[0xd],acStack1096);\n if (iVar1 != -1) {\n pcVar2 = (char *)_pwrite(iVar1,param_2[1],(size_t)param_2[2],0);\n if (pcVar2 == param_2[2]) {\n plVar5 = (long *)param_1[0xd];\n sVar3 = _strlen(acStack1096);\n pcVar2 = (char *)(**(code **)(*plVar5 + 8))(plVar5,sVar3 + 1);\n *param_2 = pcVar2;\n _strcpy(pcVar2,acStack1096);\n }\n _close(iVar1);\n }\n uVar4 = 0x80000080;\n }\n if (*param_2 != (char *)0x0) {\n pcVar2 = (char *)(**(code **)(*param_1 + 0x70))(param_1,*param_2,uVar4);\n param_2[4] = pcVar2;\n if (pcVar2 != (char *)0x0) {\n pcVar2 = (char *)dyld4::Loader::loadAddress(dyld4::RuntimeState& pcVar2 >> 1,param_1);\n param_2[3] = pcVar2;\n if (param_2[1] != (char *)0x0) {\n _unlink(*param_2);\n }\n if (*(char *)(param_1[1] + 0x90) != '\\0') {\n dyld4::RuntimeState::log(param_1,\"NSLinkModule(%p, %s) => %p\\n\");\n }\n pcVar2 = param_2[4];\n goto LAB_00029c40;\n }\n if (*(char *)(param_1[1] + 0x90) != '\\0') {\n (**(code **)(*param_1 + 0x80))(param_1);\n dyld4::RuntimeState::log(param_1,\"NSLinkModule(%p, %s) => NULL (%s)\\n\");\n }\n }\n pcVar2 = (char *)0x0;\nLAB_00029c40:\n if (___stack_chk_guard != local_48) {\n /* WARNING: Subroutine does not return */\n ___stack_chk_fail(pcVar2);\n }\n return;\n}\nLine 32 confirms the template for the temporary name is the same as what we saw\nduring execution.
\nLine 51 would be around where we expect a dlopen call to happen, although in\nthis case there's an indirection to resolve an address for a function from a\njump table. Unfortunately Ghidra isn't able to resolve that table, so we're left\nspeculating if that'll end up being dlopen or not. But I'm pretty sure that's\nwhere we end up eventually, given what we've observed during live debugging.
I wanted to compare this version with some of the older ones, but lacking at the\nmoment any non-Monterey installs, I had to resort to grabbing copies of\n/usr/lib/dyld from VMs and, eventually, download them from VirusTotal. I was\nquite surprised to see that every one of them, as far back as 551, and including\n852, do in fact use a non-dlopen version of the code, basically the true\nfileless implementation. I can't rule out that maybe all of these versions are\noff VMs, where maybe something is different with dyld… I think it's rather\ncurious that I didn't find any that use the dyld3 implementation.
The thing that throws me off the most—if this behavior really was only enabled\nin Monterey—is that so many files matching the mkstemp pattern of\n/private/var/tmp/NSCreateObjectFileImageFromMemory-XXXXXX show up in\nVirusTotal since 2018. I'm not convinced either way just yet.
The predictable file name and location means XDR can easily grab these files\nwhenever they're created, as it would be exactly the code to run that's written\nout (so any obfuscation would happen before, most likely). There are some benign\nuses of these APIs, certainly, but there are bound to be some cool findings too.\nI haven't spent any time looking through such files on VirusTotal to see if\nanything good is there, but it's certainly tempting.
\nOnce the code for the latest version of dyld is out, I hope to better\nunderstand the specifics of how the dyld4 namespace is enabled for use. Of\ncourse, I also want to see what direction Apple is taking for these APIs, given\nthe new namespace.
On the offensive tooling side, I'm curious if it's possible to develop a pure\nin-memory (true fileless) way to execute code on macOS. Mostly that seems to\nrequire writing a Mach-O loader, and I bet significant parts of the logic can be\nborrowed from both the deprecated code, and the dlopen implementation.
If you happen to come across any interesting implementations of true in-memory\nloaders for macOS, have figured out some of the missing parts I didn't get to in\nthis analysis, or found any issues/mistakes etc. please let me know via\n@roguesys.
\nThanks for reading!
\nIf we're to go by Apple's old documentation, the motivation for this API is\nto allow loading of plug-ins in applications that might want them. Bundles\n(in the Mach-O sense) fit this purpose rather well, though since it's\ntrivial to turn a binary into a bundle as shown ↩
\nThe GNU demangler that's part of Ghidra threw a bunch of errors and did not\ndemangle any names, so I ran the decompiled code through c++filt manually\nand adjusted as necessary. Still, I may have made some errors re:\nparameters, which was fine for my purposes but may not be for yours. ↩
When I started trialling VS Code and ended up\ndistracted reverse-engineering extensions, my\ngoal was to document a simple mechanism to re-order the way architectures are\npresented to the loader in universal Mach-O binaries. This is that post.
\nWhy would this be necessary? For me, it was the need to test a custom Mach-O\nloader, to make sure it can handle certain special cases. This exercise ended up\nbeing a straightforward, practical introduction to the Mach-O file format, which\nin some ways was more valuable, any why I decided to share the process.
\nThis post focuses on universal (a.k.a. \"fat\") Mach-O binaries, unless otherwise\nnoted. Specifically, those containing object files for x86_64 (Intel) and\narm641 (Apple Silicon) architectures. There are other potential\narchitectures inside such binaries, since Apple also used the format when moving\nfrom PowerPC to Intel. As we'll see, the specific architectures don't really\nmatter when it comes to reordering, but since I did not test with older\nbinaries, I won't claim this works as-is for those combinations.
The header describing universal binaries is defined in\nmach-o/fat.h,\nand the essential information is rather short:
#define FAT_MAGIC 0xcafebabe\n#define FAT_CIGAM 0xbebafeca /* NXSwapLong(FAT_MAGIC) */\n\nstruct fat_header {\n uint32_t magic; /* FAT_MAGIC */\n uint32_t nfat_arch; /* number of structs that follow */\n};\n\nstruct fat_arch {\n cpu_type_t cputype; /* cpu specifier (int) */\n cpu_subtype_t cpusubtype; /* machine specifier (int) */\n uint32_t offset; /* file offset to this object file */\n uint32_t size; /* size of this object file */\n uint32_t align; /* alignment as a power of 2 */\n};\nEach universal binary starts with a header that is always stored in\nbig-endian\nformat on disk, and which contains the magic number (0xcafebabe) and the total\nnumber of architectures the binary contains. Headers for each architecture then\nfollow, specifying the CPU, its subtype, an absolute offset into the binary for\nthe object file corresponding to the architecture, that object file's size, and\nan alignment.
To list architectures in a binary on macOS, either the file utility, or\nlipo -archs can be used; the output is different, but both parse and display\nthe headers, in the order they're present in the binary.
The order as displayed is in fact entirely determined by how these headers are\nlaid out inside the binary. Think of the universal binary as a container for its\nmultiple architectures. Each one of those is a (non-universal) binary in its own\nright. In fact, lipo can be used to \"thin\" a binary to only a specified\narchitecture, which essentially parses these headers, identifies the one\ncorresponding to the architecture that was requested, skips to the offset\nindicated in the header, and dumps the next size bytes out.
┌────────────────────────────┐\n│ ┌──────────┐ │\n│┌┤fat_header├──────────────┐│\n││└──────────┘ ││\n││┌────────────────────────┐││\n│││magic │││\n││├────────────────────────┤││\n│││num archs │││\n││└────────────────────────┘││\n│└──────────────────────────┘│\n│ ┌────────────┐ │\n│┌┤arch_headers├────────────┐│\n││└────────────┘ ││\n││┌──────────────────────┬─┐││\n│││ cputype │0│││\n│││ cpusubtye └─┤││\n│││ offset │││\n│││ size │││\n│││ align │││\n││├──────────────────────┬─┤││\n│││ cputype │1│││\n│││ cpusubtye └─┤││\n│││ offset │││\n│││ size │││\n│││ align │││\n││└──────┬───────┬─────────┘││\n││ │ … │ ││\n││ └───────┘ ││\n│└──────────────────────────┘│\n└────────────────────────────┘\nThis means that, in order to reorder the way architectures in the binary are\nprocessed, the simplest approach is to reorder the headers to get the desired\nsequence. It is possible (but insufficient) to shift the actual architecture\ncode in the binary as well, but there's no benefit, except a (dubious)\nperformance claim that if the offset is earlier, there's less seeking necessary\nto get to the relevant code. That's out of scope for this post, but certainly\nsomething one can try.
\nlipo has a way to carve out architectures from a binary, and also supports\ncreating a universal binary from specific architecture binaries, but the\nordering is fixed, based on a sort by alignment, to save space2, so\nit's unsuitable for reordering. The best option is a small tool that can shift\nthe arch headers as needed. Fortunately, we don't need to understand the arch\nheaders (not that it's hard) for this task, it's sufficient to figure out how\nmany there are, read 20 bytes for each, and save to a new file with a different\nordering.
The Python code is fairly straightforward,\nthough it doesn't allow for anything fancy like specifying what order the\narchitectures should be output in etc. Simply shifts \"left\", so for example for\nthe file binary, which has the following 3 architectures on my macOS install,\nthe first shift would go from 0 1 2 to 1 2 0 etc. as indicated below:
arch | x86_64 arm64 arm64e -> arm64 arm64e x86_64 -> arm64e x86_64 arm64\nposition | 0 1 2 -> 1 2 0 -> 2 0 1\nObviously (and reassuringly) shifting all the way to the original yields the\nsame SHA256 hash for the binary.
\nTo begin, read in the fat_header to confirm this has multiple architectures,\nthen read how many architectures we're dealing with:
offset = 0\nmagic = struct.unpack(\">I\", inbin.read(4))[0]\noffset += 4\ninbin.seek(offset)\n\nif magic != MAGIC:\n print(\"not a universal binary\")\n return 2\n\n# next value tells us how many archs the binary contains\nnarchs = struct.unpack(\">I\", inbin.read(4))[0]\noffset += 4\ninbin.seek(offset)\n\nif narchs < 2:\n print(\"not enough archs: %d\", narchs)\n return 3\nOnce we know how many architectures are in the binary, we can simply read their\nheaders, 20 bytes at the time, but we do not need to parse them. This would be\ndifferent if we also had to reorder the object files inside the binary, since\noffsets would need to be adjusted, but that's not the case here.
\nheaders = []\nfor _ in range(narchs):\n headers.append(inbin.read(20))\n offset += 20 # promise\n inbin.seek(offset)\nThen write to the output binary, maintaining the fat_header and using a simple\nshift in the loop to write the arch headers themselves. Finally, copy the\nremainder of the file:
# write back magic\noutbin.write(struct.pack(\">I\", magic))\n# write out how many narchs\noutbin.write(struct.pack(\">I\", narchs))\n# put headers in, shifting \"left\"\nfor idx in range(1, narchs + 1):\n outbin.write(headers[idx % narchs])\n# inneficiently copy the remaining bytes\noutbin.write(inbin.read())\nThere is not much to this once there's an understanding of how the headers in\nthe binary are laid out. This is somewhat documented in the open source code\nApple publishes, though resources like Jonathan Levin's books make for much\neasier references to learn from.
\nAs for follow-up work (besides improved error checking) a better way to\nunderstand the Mach-O format is to also enable object file reordering in the\nbinary, and/or have a way to specify the sequence for header reordering.
\n