systems security

Every obfuscation must still run on the CPU in a form the CPU understands. That single fact tells you how each one is undone, and why obfuscation buys time rather than secrecy.

EDR products, profilers, game cheats and banking trojans all use the same trick: make a call to function A run your code first. Knowing the mechanics tells you both how to detect it and why user-mode hooks are a weak place for security controls.

Most Mac compromises do not break these controls. They persuade the user to step around them, or borrow the permissions of an app that already has them.

'It's signed' means different things depending on when the signature is checked: once at install, every time the binary loads, or on every page of memory as it executes.

sudo is a policy engine that runs as root and parses user input. Grant it carelessly and 'run this one command' becomes 'run anything'.

A seccomp filter decides on a system call number and six integers. It cannot read the file path a pointer refers to, and that one limitation shapes every good policy.

Secure Boot checks signatures until the kernel is running. What keeps root from loading unsigned code into the kernel after that is a different set of controls, and interviewers check you know both.

NTLM proves you can answer a challenge. It never proves which server you meant to answer, so whoever sits in the middle can pass your answer to a server you never chose.

Once an attacker is admin on one machine, the credentials cached there decide whether they stop at one machine or reach the domain. Every control in this answer is about that step.

Browsers assume the JavaScript engine will be exploited. The architecture is built so that one bug buys an attacker a locked room, and they need a second, different bug to leave it.

W^X says memory is writable or executable, never both. A JIT compiler's whole job is writing code and then running it. How a runtime squares that circle decides how much an attacker gains from a memory bug.