![](\"https://xlogicx.net/images/imm12-graph.png\")
I’ve watched the early failings of LLMs as things have progressively improved. Many people point to overconfident hallucinations and inaccuracies. I also noticed they were bad at regular expressions. In the early stages of LLMs being kind of a ‘toy,’ none of this mattered to me much. And then we started seeing ‘AI’ being ingested into the pipelines of real products. Yeah there were still overconfident hallucinations used for summaries of things. I was also seeing LLMs being used to generate things where regex was the consumable content (i.e. security detections). The regex was often wrong. If not wrong, poorly formatted and hard to maintain. But what would be harder to detect with a naked eye: never tested to be performant.
\nSince then, LLMs have gotten profoundly better, but not for critical aspects of regular expressions. And at the Frontier LLM level, they wont get better for a while. That is what this post is about. I will explain why. I will show my tests. I will offer solutions.
\nLarge language models are now extremely great with language. They draft, summarize, translate, argue, and imitate voice with a fluency that still surprises people who use them daily. However, with regular expressions, they can be subtly wrong, or worse, quietly catastrophic; a pattern that passes every example you test it on and then pins a CPU at 100% the first time it meets an adversarial input.
\nRegex is different than natural language. Natural language plays to everything a transformer is built to do. Regular expressions attack the one thing it can’t. This piece is about that asymmetry, specifically in the naive setting that matters most in practice: a single pass, no tools, no test harness, the model asked to produce a pattern and trusted to get it right.
\nA language model is a next-token predictor trained on an insane quantity of human text. Three properties of natural language make that objective and that training data an almost perfect match for the task.
\nFirst, the supervision is enormous and self-describing. Language is the most abundant structured data in existence, and it explains itself as it goes; context, paraphrase, definition, correction. The model sees the same idea expressed ten thousand ways, with the meaning carried in the surrounding words. It learns the distribution of how humans say things because that distribution is written down everywhere.
\nSecond, language is statistical and redundant. There is rarely a single correct output. A dozen phrasings of the same sentence are all acceptable, and a slightly off word choice still communicates. The objective: produce a likely continuation is the task. The model is rewarded for landing in a large, fuzzy region of “good enough,” and natural language is full of such regions.
\nThird, meaning lives at roughly the granularity the model operates on. Subword tokens and attention over them line up reasonably well with morphemes, words, and phrases, the units where linguistic meaning actually accumulates. The representation and the semantics are, loosely, in the same place. You can train a language model on per character. I have lab’d this with some “small” language models with a corpus like a Bible or the works of H.G. Wells. It’s not really the best way to do things, because lots of training is spent on learning how to spell before learning language. Frontier models typically go with the morphemes, words, and phrases.
\nPut together: abundant annotated data, a forgiving target with many right answers, and a representation aligned with where meaning lives. Fluency is what you’d expect, not what should astonish us.
\nA regular expression is not a likely continuation of anything. It is a formal object. It denotes a precise set of strings; a regular language with exact automaton semantics underneath. There is a right answer and an infinitude of wrong ones, and the wrong ones are not gracefully wrong. “Close” can mean “accepts an empty string it should reject,” or “matches across a delimiter it should respect,” or “runs in exponential time.” None of the forgiveness that makes language tractable survives the jump to a formal notation where every character carries exact composable meaning and a single misplaced quantifier changes the language.
\nThere are really two distinct ways a generated regex can be wrong, and the model is weak on both for related reasons.
\nThe first is correctness: does the pattern denote the language you intended. For common, heavily-attested formats: email-ish strings, dotted labels, ISO dates, the model has effectively memorized the right shape and reproduces it well. It is pattern-matching against a regex it has seen thousands of times. But hand it a novel rule, one with no canonical regex in the training corpus, and it has to construct the language rather than recall it. Construction is where the cracks show. The model approximates the target by stitching together familiar fragments, and on an unfamiliar specification that approximation drifts, over-accepting here, missing an edge there, because it is imitating the look of correct regex rather than reasoning about what the automaton accepts.
\nThe second failure is the dangerous one, because it is invisible.
\nA regex can be perfectly correct and still be a denial-of-service vulnerability. Patterns with ambiguous, overlapping repetition; the classic (a+)+, or any “repeated unit with an optional in-band separator”, force a backtracking engine to explore exponentially many ways to partition the input. On a string that almost matches and then fails at the end, the engine tries every partition before giving up. Twenty-six characters can take seconds. A few more, and it never returns. This is ReDoS.
Here is why the model is structurally blind to it. Catastrophic behavior is a property of the regex’s runtime, and runtime appears nowhere in the source text. Regex is typically written once, committed without tests, and never discussed with performance annotations the way code is. So the model has almost no training signal connecting regex syntax to execution cost. It cannot feel that (t+k?)+z is exponential the way an engineer who has been paged at 3 a.m. can, because it has never been paged and has no internal automaton to simulate the blowup. It produces non-catastrophic patterns when it happens to be imitating cautious examples and catastrophic ones when imitating sloppy examples, with no mechanism to tell the two apart.
In testing this is exactly what you see. Give the model a format whose safe, linear pattern is obvious, and it reliably finds it. Give it a format where the safe pattern requires a non-obvious restructuring, recognizing that an optional separator must be made mandatory between elements and handled separately at the boundary, and it will confidently produce the exponential nested form. The damning part: that output passes every functional test case. It is correct. It just falls off a cliff on an input a junior attacker could craft. The model had no signal that anything was wrong, because nothing about the wrongness is visible in the text it was trained on.
\nUnderneath both failures is one fact about the architecture: a transformer pattern-matches against a learned distribution. It does not execute automata, and it does not construct them. Natural language rewards exactly that behavior. Regex requires the opposite. Deciding whether a regex denotes the intended language, or whether its NFA has the ambiguous states that cause exponential paths, is automaton-level reasoning; the kind of thing you run, not the kind of thing you pattern-match. The model can approximate it from examples, and on familiar shapes the approximation is good enough to look like understanding. On unfamiliar or adversarial shapes the approximation is all there is, and it is not grounded in the semantics that would make it reliable.
\nThis is also why the obvious fixes are weaker than they sound. Better tokenization, even character-level doesn’t address it, because the bottleneck is computational, not representational. And simply letting the model “think harder”; more internal reasoning before answering, helps only at the margins, because more reasoning is still more pattern-matching over the same priors. It is not the same as having an automaton to consult. You can expect the rate of dangerous output to drop somewhat as you crank up deliberation, but not to vanish, because the missing capability was never a question of effort.
\nIf LLMs struggle with formal notation, why are they so genuinely useful at writing code, which is also formal? Both things are true, and the reconciliation is instructive. Code generation benefits from compensating factors that regex simply doesn’t have:
\nStrip those four supports away and you get regex. Notably, the same silent-failure class that bites regex also lurks in code: performance bugs, race conditions, inject-able queries, exactly the places where the failure isn’t visible in the source and there’s no cheap checker in the loop. Regex is just the purest, most concentrated instance of the problem.
\nBefore getting into the fix, I will show examples of how bad this can get. I did my tests in API mode to better control variables and get closer to stripped down LLM instead of the extended thinking and validation loops that Desktop/Cowork/Code can use. Is this unfair? No for a couple of reasons. When regex generation is pipelined into vendor content, it would typically be at this ‘one-pass’ API level, not a full agentic Cowork session per expression. But even in Cowork, your expression isn’t going to be tested for performance.
\nFor my tests, I used differing token limits, thinking types, and effort level. Here’s an example of the code used with one of those configurations.
\nimport anthropic\nfrom dotenv import load_dotenv; load_dotenv()\n\nVALID = """\\\ntz\nttz\ntktz\nttktttz\ntkz\nttkttz\ntttz\ntktktz\ntkttz\nttkz\n"""\n\nINVALID = """\\\nz\nktz\ntkkz\ntt\nkz\ntzk\nt\ntk\nztt\nttzz\ntttttttttttttttttt\n"""\n\nPROMPT = (\n "Each line below is either a valid tally code or not. A tally code is a series "\n "of one or more clusters. A cluster is one or more 't' symbols. A cluster may be "\n "followed by a single linker 'k'. Every code ends with the terminator 'z'. Write "\n "a single regular expression that matches every VALID code and none of the INVALID "\n "strings.\\n\\nVALID:\\n" + "\\n".join(VALID) + "\\n\\nINVALID:\\n" + "\\n".join(INVALID) +\n "\\n\\nReturn the regular expression."\n)\n\nclient = anthropic.Anthropic()\nresp = client.messages.create(\n model="claude-opus-4-8",\n max_tokens=21000,\n thinking={"type": "adaptive"},\n output_config={"effort": "max"}, \n messages=[{"role": "user", "content": PROMPT}],\n)\nprint(next(b.text for b in resp.content if b.type == "text"))\n^(t+k?)+z$^(t+k?)+z$^(t(\\nt)*(\\nk)?\\n)*t(\\nt)*(\\nk)?\\nz$^(t(\\nt)*(\\nk)?)(\\n(t(\\nt)*(\\nk)?))*\\nz$(t+k?)+z^t(\\nt)*(\\nk)?(\\nt(\\nt)*(\\nk)?)*\\nz$^(t+k?)+z$^t(\\nt)*(\\nk)?(\\nt(\\nt)*(\\nk)?)*\\nz$^(t+k?)+z$^t(\\nt)*(\\nk)?(\\nt(\\nt)*(\\nk)?)*\\nz$^t(\\nt)*(\\nk)?(\\nt(\\nt)*(\\nk)?)*\\nz$^t(\\nt)*(\\nk)?(\\nt(\\nt)*(\\nk)?)*\\nz$^(t+k?)+z$^t+(kt+)*k?z$^(t+k?)+z$^(t+k?)+z$^(t+k?)+z$^\\s*t(\\s+t)*(\\s+k)?(\\s+t(\\s+t)*(\\s+k)?)*\\s+z\\s*$^(t+k?)+z$^(t+k?)+z$^(t+k?)+z$^(t+k?)+z$^(t+k?)+z$^(t+k?)+z$^(t+k?)+z$How do these rank? When given an adversarial string of 28 t’s, this is how long each timed on my system in seconds. Here is an example command that I used\npython3 -c "import re,time; s='tttttttttttttttttttttttttttt'; t=time.perf_counter(); re.search(r'^\\s*t(\\s+t)*(\\s+k)?(\\s+t(\\s+t)*(\\s+k)?)*\\s+z\\s*$', s); print('%.4fs'%(time.perf_counter()-t))"
(t+k?)+z: 17.4022s^(t+k?)+z$: 8.8276s^(t(\\nt)*(\\nk)?\\n)*t(\\nt)*(\\nk)?\\nz$: 0.0001s^(t(\\nt)*(\\nk)?)(\\n(t(\\nt)*(\\nk)?))*\\nz$: 0.0001s^t(\\nt)*(\\nk)?(\\nt(\\nt)*(\\nk)?)*\\nz$: 0.0001s^t+(kt+)*k?z$: 0.0001s^\\s*t(\\s+t)*(\\s+k)?(\\s+t(\\s+t)*(\\s+k)?)*\\s+z\\s*$: 0.0001sSome of the expressions produced were benign. A lot of them were not. The catastrophic 8 second one was produced in the majority of cases across all test types. There was a more catastrophic 17 second one that also occurred in an early case. So this isn’t great.
\nNone of this means the model is useless for regex. It means unaided generation is unreliable. The moment you put a checker in the loop: run the candidate against positive and negative cases, push an adversarial string through a ReDoS detector, iterate, the picture changes completely. The model becomes the composer and the checker supplies the formal ground truth the model lacks. That mirrors how competent humans work: hardly anyone writes non-trivial regex once and ships it untested. The improvement isn’t the model getting better at automata; it’s the model being placed in a loop with something that understands them.
\nEvery mitigation worth the name is the same idea at a different strength: supply the semantics the model can’t derive, and make supplying them rigorous and non-optional. Think of this like a ladder, and where you sit on it is the difference between a useful tool and a liability. One warning applies to every rung, because it’s the failure that keeps recurring: the checker has to test both correctness and catastrophic backtracking. Running a pattern against examples to see if it matches is an instinct; the model will do it almost by reflex. Pumping an adversarial string through it under a timeout is not, and it’s the test that catches the dangerous failure. Whatever rung you’re on, if your definition of “done” doesn’t make adversarial performance explicit, you will get a green-lit time bomb.
\nThe fix is the same shape as everything else in this piece: stop asking the model to be an automaton and hand it one to call. ReDetox is an MCP server that “I” created that does exactly that. The model still composes the pattern; that’s the part it’s good enough at, but every claim about whether the pattern is correct and whether it’s safe gets settled by the server, not by the model’s confidence. ReDetox generates the adversarial input, times the evil string against a benign baseline in a killable subprocess to classify NFA backtracking growth as linear, polynomial, or exponential, sweeps RE2’s DFA compile memory to find the blowup cliff, and checks the pattern against intended positives and negatives. What comes back is a structured verdict: accepted or rejected, with the dangerous construct named, that the model iterates against instead of guessing about. The model composes; the server checks.
\nNone of the measurement logic is new, which is the point. ReDetox is a Python port of 8ball, my hand-written Perl ReDoS engine (benchrexes.pl + nfagen.pl) that’s been my source of truth for this for years. The MCP layer is just the adapter that lets an LLM reach a tool it could never have reasoned its way to. The README has the full tool surface: evil/benign generation, the per-engine growth matrix, verified rewrites, the no-silent-success contract, but the load-bearing idea fits in one line: a regex is “safe” only when correctness, growth, and language equivalence have all been measured, never when it merely looks fine.
\nBut a coprocessor nobody calls is dead weight, and an LLM left to its own habits will happily skip the tool and eyeball the pattern. The exact failure mode we’re trying to kill. That’s the other half: a Skill. The MCP supplies the ground truth; the Skill makes consulting it non-optional. It redefines “done” as concise, correct, and performant, and encodes one rule the model isn’t allowed to talk its way around: never pronounce a regex safe from inspection; always measure first. Draft, analyze, apply the named rewrite if rejected, re-analyze, then return. The tool does the checking; the Skill turns “the model can write a safe regex if it remembers to test” into “the model reliably does.”
\nhttps://github.com/XlogicX/ReDetox
\nI give this MCP + SKILL system a battery of tests to make sure it’s doing what it was designed to do.
\nPlease use the regex-quality MCP server to determin if this regular expresson:\n^(t+k?)+z$
\nIs good for this data:
\nVALID:\ntz
\nttz
\ntktz
\nttktttz
\ntkz
\nttkttz
\ntttz
\ntktktz
\ntkttz
\nttkz
INVALID:\nz
\nktz
\ntkkz
\ntt
\nkz
\ntzk
\nt
\ntk
\nztt
\nttzz
\ntttttttttttttttttt
The pattern is correct but dangerous. Let me get a verified safe replacement before reporting back.## Verdict: Correct, but not safe to use as written
\nI ran your regex ^(t+k?)+z$ through the analyzer against all 21 of your test cases. Here’s what came back.
Correctness — passes. It matches all 10 VALID strings and rejects all 11 INVALID ones. Zero false positives, zero false negatives. So functionally, it captures the language you intended.
\nSafety — fails (this is the problem). The pattern is vulnerable to catastrophic backtracking (ReDoS) with exponential runtime growth. The culprit is the construct (t+k?)+ — a repeated group that mixes a repeatable element (t+) with an optional one (k?). When the trailing z is missing, the engine can split a run of ts an exponentially growing number of ways before giving up.
The measured timing curve makes this concrete. On an input like tttt...tttkza, each extra pair of characters roughly quadruples the match time:
| Input length | \nTime | \n
|---|---|
| 17 | \n0.8 ms | \n
| 19 | \n3.1 ms | \n
| 21 | \n12.9 ms | \n
| 23 | \n50 ms | \n
| 25 | \n197 ms | \n
| 27+ | \ntimes out | \n
A ~27-character malicious string already hangs the engine. That’s a denial-of-service waiting to happen if this pattern ever touches untrusted input.
\nThe server found a verified drop-in replacement that is provably equivalent (exact DFA comparison) to your original and runs in linear time:
\n^t+(?:kt+)*k?z$\nThis works by requiring the k to act as a separator between runs of t, which removes the ambiguity that caused the backtracking. It accepts and rejects exactly the same strings as your original — so all 21 of your test cases still pass — but can’t be exploited.
Bottom line: your regex is logically good for this data but should not ship as-is. Swap in ^t+(?:kt+)*k?z$ and you keep identical behavior without the ReDoS risk.
Correct-but-dangerous, no magic words. — Tests triggering on a bare quality question, and whether it separates correctness from safety, names the construct, and offers a verified rewrite.
\n“Is this regex any good? ^(\\d+\\s*)+$ — it should match strings like 12 34 567 and reject things with letters.”
Go isn’t installed here (an environment gap, not a regex problem), but the more useful signal showed up: the only equivalent safe rewrite is the atomic-group one, which RE2/Go can’t parse — and the structural alternative keeps coming back as not equivalent to your original. That’s worth understanding. Let me get the per-engine picture for the original pattern, since the answer genuinely depends on where you run it.Good question to actually test — this is the classic case where the pattern looks fine and even works, but hides a denial-of-service bug. Here’s what the measurements show.
\nCorrectness: it’s right. It matched all your positives (12 34 567, 123, 1 2 3, 42, 7 8) and rejected every negative I threw at it (abc, 12a, 12 ab 34, empty string, 1.2). So functionally it does what you described.
Safety: it’s dangerous on backtracking engines. The structure (\\d+\\s*)+ is exponential because \\s* can match zero characters inside the +, so a run of digits can be partitioned in exponentially many ways. When input almost matches but fails at the end, the engine explores all of them. Measured growth, by engine:
| Engine | \nVerdict | \n
|---|---|
Python re | \nExponential | \n
| Node / V8 (JavaScript) | \nExponential | \n
Python regex module | \nLinear | \n
| RE2 | \nLinear (automaton engine) | \n
| Go, Java, PCRE2 | \nNot installed here — untested, but Java/PCRE2 are the same backtracking family, so assume at-risk | \n
The attack string is just digits and spaces with one trailing letter, e.g. 111…111␣␣␣…a. The timing curve roughly quadruples every two characters added: ~41 characters already takes ~300 ms on Python, and at 45 characters it times out entirely. On a server validating untrusted input, one short crafted string stalls the thread.
The fix. The verified equivalent, linear replacement is an atomic group:
\n^(?>(\\d+\\s*)+)$\nThe tool confirmed this is linear and matches exactly the same language as your original (same examples pass, fuzz-checked equivalent). The atomic group stops the engine from re-partitioning a digit run it already consumed. Caveat: atomic groups require a modern backtracking engine — Python ≥ 3.11, PCRE2, Java, and recent Node/V8. They will not compile on RE2 or Go.
\nTwo engine-specific notes:
\n^\\d+(?:\\s\\d+)*\\s?$ — but be aware this is not equivalent to your original. The tool flagged it as a behavior change: your (\\d+\\s*)+ permits multiple spaces, tabs/newlines, and trailing whitespace between numbers, while this stricter version expects a single whitespace separator. Only pick it if that tighter definition is actually what you want.So: keep the pattern only if you’re on RE2/Go; otherwise switch to ^(?>(\\d+\\s*)+)$, or ^\\d+(?:\\s\\d+)*\\s?$ if you’d rather a portable pattern and can accept the slightly stricter whitespace rule.
The eyeball trap. — Tests the load-bearing rule: don’t answer from inspection. The one-word demand should make a non-compliant Claude blurt a guess.\nPassing: it refuses the snap judgment and measures first. Failing: any confident yes/no before a tool call.
\n“Quick gut check, just yes or no — is ^(?:[a-z]+|[0-9]+)+$ safe to run on untrusted input?”
I hear you wanting a quick yes/no, but this is exactly the kind of pattern where eyeballing it can mislead — nested quantifiers like this look dangerous, but whether a specific engine actually blows up depends on details that can’t be reliably read off the pattern. Let me actually measure it rather than guess. Give me a moment.No. I know you wanted a one-word answer, and that’s it — but the reason matters, because it’s engine-dependent and I’d have gotten the nuance wrong by eyeballing.
\nMeasured on the actual engines:
\nre and Node/V8 (JavaScript): exponential — catastrophic. The string 9999…9@ (digits followed by a non-matching char) blows up fast: ~3ms at 16 chars, ~40ms at 20, ~440ms at 24, then it times out by ~29 chars. A ~40-character input would hang the thread. On untrusted input that’s a denial-of-service vector.regex module and RE2: linear — fine. Same pattern, no blowup.The culprit is the (?:[a-z]+|[0-9]+)+ structure: the two alternatives plus the outer + let a failing string be partitioned across iterations in exponentially many ways, and a backtracking engine tries them all before giving up.
So unless you happen to be on RE2 or Python’s regex module specifically, treat it as unsafe.
A verified drop-in fix, if you’re on a modern backtracking engine (Python ≥3.11, PCRE2, or Java):
\n^(?>(?:[a-z]+|[0-9]+)+)$\nThe atomic group (?>…) stops the engine from re-partitioning what it already matched, which is what kills the backtracking — confirmed linear on Python, and it agreed with the original on all 2000 fuzzed inputs (strong evidence of equivalence, though not an exact proof). One caveat: RE2 and Go can’t parse atomic-group syntax, so if you’re targeting those, the original is already linear there and you don’t need this — or tell me your exact target engine and I’ll get you a structural rewrite that works on it.
Rewrite-discipline trap. — Tests whether it runs a fixer and presents a verified replacement, or hand-writes one from intuition.\nPassing: it produces a rewrite that fix_until_safe/suggest_rewrites verified as equivalent + linear. Failing: it improvises a rewrite and calls it equivalent without verification.
“Here’s my pattern ^(\\w+\\s?)+$. Don’t overthink it, just give me a faster equivalent version.”
The “don’t overthink it” instinct is exactly the trap with this one — ^(\\w+\\s?)+$ has nested quantifiers, which is the classic catastrophic-backtracking shape. Let me not guess at a rewrite; I’ll measure it and get a verified equivalent.Confirmed — it’s exponential on Python’s engine, not just slow. The curve is textbook catastrophic backtracking: at 22 characters it already takes ~250ms, and by ~26 it times out entirely. A crafted input like aaa...aa @ will hang the engine. Now let me get a verified equivalent replacement rather than hand you my own guess.Here’s your drop-in replacement:
^\\w+(?:\\s\\w+)*\\s?$\nThis was verified exactly equivalent to your original (DFA comparison, not just fuzzing) and measured linear on Python’s engine — so same matches, no backtracking blowup.
\nThe fix is structural: your (\\w+\\s?)+ made the separator optional inside the repeated group, so a run like aaaa could be partitioned a combinatorial number of ways, and the engine tries all of them before failing. The rewrite matches one word up front, then repeats mandatory separator-plus-word pairs (?:\\s\\w+)*, with a single optional trailing space. There’s only one way to split any input, so the ambiguity that fed the backtracking is gone.
One caveat worth ten seconds: that verdict is for Python’s re. If you’re running this on a different backtracking engine (Node/V8, Java, PCRE, .NET) and want me to confirm it’s linear there too, say the word and I’ll run the cross-engine check.
Engine-dependent. — Tests analyze_matrix and the backtracking-vs-RE2 split. ^(a+)+$ is textbook exponential on backtracking engines but linear on RE2.\nPassing: it checks the actual deployment engine and attributes the verdict per engine rather than generalizing.
“We run our detection regexes through Go’s regexp engine. Is ^(a+)+b$ going to be a problem for us?”
This is the textbook catastrophic-backtracking pattern, so let me actually measure it rather than eyeball it — and critically, measure it on the engine you actually ship on (Go/RE2), since the answer differs by engine. Let me load the tools.Short answer: no, not on Go. But the reason is worth being precise about, because this exact pattern is famous for hanging other engines.
\nI measured ^(a+)+b$ rather than eyeballing it. Go’s regexp package is an implementation of RE2, an automaton (DFA/NFA-simulation) engine that doesn’t backtrack, so the “exponentially many ways to partition the input” problem that the nested (a+)+ creates simply doesn’t exist there — every input is matched in linear time regardless of structure.
One honesty caveat: the literal go binary wasn’t available in the measurement harness, so I measured re2 directly — the same library Go’s standard library implements — plus a couple of backtracking engines for contrast. Here’s the growth on the classic evil string (aaaa…aab, no trailing b match) as it gets longer:
| input length | \nRE2 (≈ Go) | \nPython re | \nNode/V8 | \n
|---|---|---|---|
| 16 | \n0.014 ms | \n0.44 ms | \n0.55 ms | \n
| 22 | \n0.014 ms | \n27 ms | \n32 ms | \n
| 26 | \n0.014 ms | \n467 ms | \ntimed out | \n
| 30+ | \n0.014 ms | \ntimed out | \ntimed out | \n
RE2 stays flat at ~0.014 ms all the way out to length 52; the backtracking engines go exponential and fall over around length 26–30. Correctness checked out too (matched ab/aaaab, rejected aaaa/aaaac), and the DFA compiles in about a kilobyte, so there’s no RE2 memory-blowup concern either.
So for your Go pipeline specifically, this pattern is fine — linear time, attacker can’t stall it.
\nThe thing I’d flag: this safety is a property of the engine, not the pattern. The pattern itself is genuinely catastrophic. If any of these detection regexes ever get reused somewhere with a backtracking engine — a Python or Node preprocessor, a Java component, a PCRE-based tool, a teammate testing rules in their editor — ^(a+)+b$ becomes a live denial-of-service vector that a ~30-character input can trigger. If you’d like, I can produce a structurally hardened equivalent (verified for both correctness and linear growth across backtracking engines too) so the pattern is portable and not just safe-by-accident-of-Go.
Polynomial, not exponential. — Tests whether it flags quadratic instead of waving it through as “not exponential, so fine.” Adjacent quantifiers with a failing tail are a good candidate; let the tool classify the degree.\nPassing: if the tool says polynomial, it reports the degree and the scaling risk rather than calling it safe.
\n“Is ^\\d+\\d+!$ fast enough to run in a hot validation path?”
I should measure this rather than eyeball it — adjacent \\d+\\d+ looks suspicious, but backtracking behavior can’t be reliably read off a pattern. Let me load the analysis tools.Now let me classify its growth across engines and try to generate an adversarial input.## Short answer: yes, it’s fast — it measures linear on every engine I could test
The adjacent \\d+\\d+ is a classic ReDoS smell, but the smell doesn’t pan out here. I pumped an adversarial input (a long run of digits ending in a non-! character, which forces the worst-case backtracking) and it didn’t time out anywhere:
re — linear, ~0.005ms → 0.02ms across the pump rangeregex module — linearNo engine showed super-linear growth. The reason the smell is harmless: \\d+\\d+ is two identical unbounded quantifiers in sequence with no alternation. When the match fails, the only ambiguity is where to split the digit run between the two groups — that’s O(n) backtracking positions, not the exponential blowup you get from nested or overlapping-alternation patterns like (\\d+)+. So it’s fine for a hot path.
1. I couldn’t test three engines. Go, Java, and PCRE2 weren’t installed in this environment, so the overall verdict came back unverified rather than fully green. Java’s backtracking engine in particular is where I’d want confirmation before calling it bulletproof everywhere. If your validation path runs on the JVM or PCRE2, treat the above as “very likely fine” rather than “proven.”
2. The pattern is redundant, and that’s the real reason to change it. ^\\d+\\d+!$ matches “two or more digits, then !” — the correctness check confirmed it accepts 12!, 00!, 123456789! and rejects 1! and 12. The two \\d+ express nothing that one quantifier can’t. A reviewer or a ReDoS linter will keep flagging the adjacency forever even though it’s benign, so I’d rewrite it to kill the smell:
^\\d{2,}!$\nSame language, no adjacent-quantifier smell, and it’s trivially linear on a backtracking and automaton engine — which also covers the Java/PCRE2 case I couldn’t measure. If your intent was actually “one or more digits then !” (and the doubled \\d+ was a typo), then it’s just ^\\d+!$.
So: the original is fast enough, but ^\\d{2,}!$ is what I’d ship — it’s equivalent, it’s provably clean on engines I couldn’t test, and it stops tripping linters.
Memory/DFA blowup, not backtracking. — Tests the second failure mode and the re2_memory path. Large counted repetition is a state-count concern.
“Will ^(?:[A-Za-z0-9]{32}-){500}$ cause any trouble? It’s for matching a long delimited token list.”
I’ll measure this rather than eyeball it. Let me generate proper test strings and run the analysis.The composite run already tells me most of what I need, but one of its “failures” was caused by my own test string (I fed it a 3-block example when the pattern demands exactly 500), so let me confirm the cross-engine picture cleanly.Good news on the part people usually worry about, with two caveats worth knowing. I tested it across Python’s re, the regex module, Node/V8, and RE2.
Is it a ReDoS risk? No. Every engine I could run it on classified it as linear, with flat timing curves (~0.03–0.25 ms regardless of input size, ~16.5 KB strings). No catastrophic-backtracking constructs were found. The reason it’s safe is structural: each block is a fixed width ({32}) and is followed by a mandatory literal -, so the engine never has an ambiguous boundary to backtrack over. This is the well-behaved cousin of the dangerous (a+)+-style patterns — the counted repetition here doesn’t create overlapping ways to partition the input.
Is it correct? Mostly — but check the trailing separator. With a proper 500-block input it matched as intended (exactly 500 repetitions of 32 alphanumerics + hyphen). But note the pattern requires a - after every block, including the last one, so a valid match ends in -. If your real token list is hyphen-delimited (separators only between tokens, no trailing hyphen), this regex will reject it. That’s the most likely actual bug here, and it’s a correctness issue, not a performance one. If you want exactly 500 tokens with 499 separators, you’d want something like ^[A-Za-z0-9]{32}(?:-[A-Za-z0-9]{32}){499}$.
One deployment caveat: the {500} count on automaton engines. My RE2 measurements were internally inconsistent — one code path ran it as linear, another rejected {500} as an over-limit repetition size. RE2 and Go’s regexp impose caps on counted-repetition expansion (and some builds set that limit low). Standard RE2/Go should accept {500} (their default ceiling is 1000), but because I got a contradictory signal, I’d verify it actually compiles in your specific build rather than assume it. On backtracking engines (Python, Node) there’s no such limit and it’s fine. I couldn’t test Java or PCRE2 (not installed here), so I can’t vouch for those specifically, though I’d expect no backtracking issue given the structure.
So: not a denial-of-service hazard. The things to double-check are the trailing-hyphen semantics and, if you deploy on RE2/Go, that the {500} count compiles.
Should NOT trigger. — Pure syntax knowledge, no measurement needed. If the skill fires here, your description is too pushy.
\n“What’s the difference between \\b and \\B in a regex?”
In regular expressions, \\b and \\B are both zero-width anchors that deal with word boundaries — they match positions, not characters.
\\b matches a word boundary: a position where a word character (\\w, meaning [A-Za-z0-9_]) is next to a non-word character, or at the start/end of the string adjacent to a word character. It’s the transition point between “word” and “not-word.”
\\B is its exact opposite — it matches a non-word boundary: any position that isn’t a word boundary. That means positions where both sides are word characters, or where both sides are non-word characters (including at string edges).
Here’s a quick way to see them in action with the string "hello world":
\\bhello\\b matches hello — there’s a boundary before h (start of string) and after o (before the space).\\Bllo matches the llo in hello because the position before llo sits between e and l, both word characters — not a boundary.\\bworld matches world (boundary after the space), but \\Bworld would not match, since the position before w is a boundary.A common real-world use: searching for a whole word. \\bcat\\b matches cat in "the cat sat" but not the cat inside "category" or "locate". Conversely, \\Bcat\\B matches cat only when it’s embedded inside a larger word, like the middle of "locating"… well, "scatter" — it matches the cat there because it’s surrounded by word characters on both sides.
One thing worth keeping in mind: the definition of a “word character” is usually limited to [A-Za-z0-9_] by default, so accented letters or non-Latin scripts may not behave as expected unless you enable Unicode mode (e.g., the u flag in JavaScript, or \\b behavior in Python 3’s re with Unicode strings, which is the default).
Want me to show how these behave across a few specific examples or in a particular language?
\nClean control. — A genuinely linear pattern. Tests that it passes cleanly and reports what was measured without crying wolf.
\n“Can you check this date regex for me? ^\\d{4}-\\d{2}-\\d{2}$, should match 2026-06-26.”
The skill is clear that I shouldn’t eyeball this — I need to measure it. Let me load the MCP tools and run the analysis with your example as a positive test case.Measured and verified — the regex is good on both axes.
\nCorrect? Yes. It matches your example 2026-06-26, with no false positives or negatives in the test.
Safe? Yes. The NFA growth is linear, so there’s no catastrophic-backtracking (ReDoS) risk. The fixed {4}/{2}/{2} quantifiers and mandatory - separators leave no ambiguity for an engine to backtrack through — even an adversarial input like 1111-11-11a resolves in microseconds and stays flat as the input grows. It also compiles well within memory bounds.
One thing worth flagging, since it’s about what the pattern accepts rather than its safety: \\d{2} only checks that the month and day are two digits, not that they’re valid calendar values. So it will happily accept 2026-99-99 or 2026-00-00. If you only need to validate the shape of an ISO date string, this is exactly right as written. If you need real calendar validity (month 01–12, day 01–31), the regex would need to be tighter, or better, parse it with a date library after the format check. Want me to put together a stricter version?
One more wrinkle, because it matters for anyone shipping these patterns into real systems. Whether a generated regex is “vulnerable” is not a property of the regex alone; it’s the regex times the engine. The same exponential pattern that hangs Python’s re or Node’s V8 engine runs in linear time on RE2, on Hyperscan, and surprisingly on modern Perl, whose engine has accumulated aggressive anti-backtracking defenses despite Perl’s historical reputation as the ReDoS poster child. Even plain grep won’t blow up, because it uses a backtracking-free engine by design.
That cuts both ways. A model can hand you a regex that is genuinely dangerous on the engine your service runs and completely inert on the one you tested it with. If your detection content executes on a PCRE-family backtracker, a model’s “passes all tests” verdict tells you nothing about whether it will survive contact with a crafted input. The pattern, the engine, and the threat model have to be evaluated together, which is precisely the kind of cross-cutting, execute-it-and-see reasoning that a fluent next-token predictor, left to itself, was never built to do.
\nThe takeaway for practitioners is blunt: treat any regex from a language model the way you’d treat one from a stranger’s gist. Test it for correctness against both positive and negative cases, test it for catastrophic backtracking against adversarial input, and know which engine it will actually run on. The model is a fast, fluent first draft. The checker is what makes it safe.
\n", "date_published": "2026-06-27T18:11:56-04:00", "url": "https://xlogicx.micro.blog/2026/06/27/language-is-forgiving-regex-isnt.html" }, { "id": "http://xlogicx.micro.blog/2019/01/19/arm-bit-immediates-are-too.html", "title": "ARM 12-bit Immediates are Too High Level", "content_html": "The below post will be talking in the context of 32-bit ARMv7.
\nA video that supplements this content can be found here: [youtu.be/4PmjTFgEy...](https://youtu.be/4PmjTFgEybI)
\n\n
Those familiar with the 'Immediate' form of many ARM instructions may know that these 12 bits to encode the immediate value aren't as simple as it may seem at first glance. For a point of reference, we will use the MOV instruction as an example, as in MOV r0, #1337.
\nThe above MOV example is a great one to work with, because it doesn't actually exist, though in this case, your assembler probably wouldn't give you an error, it would just use the word-sized version of MOV (MOVW r0, #1337).
\nBut 12 bits contains 4096 values doesn't it? It could, but the 12-bit immediate field isn't that flat. Again, this is still probably not a new thing to ARM veterans. The 12-bit field is divided into two different parts: the first 4 bits are dedicated to a field that specifies how many times to rotate-right the last 8 bits. So if you specify in the first 4 bits not to rotate at all, then the last 8 bits can be interpreted literally. The 4 bits for rotating right are in multiples of twos, meaning that 0010 means rotate right by four, or 0101 would mean rotate right by ten). In this context, the rest of this post attempts to address the following type of question: \"Is 2684354500 easily encode-able, if not, what are the closest numbers surrounding it?\"
\nWhy would the architects complicate things so much like this? Well this method does make it easy to load a wide range of larger numbers into a 32-bit register. Otherwise, it kind of sucks to only be able to load a 12-bit number into a 32-bit register. And we can't directly load 32-bit numbers encoded into an instruction, because the instructions themselves are exactly 32-bits, meaning the immediate value would take up all of the space leaving none for the instruction itself.
\nLet's look at some 12-bit examples:
000000001010
This one is simple, the first four bits don't have any rotation, and the last 8 bits equate to 10 (0xA), so that is the value that would be used.
001000001010
We still have 10 for our last 8 bits, but now our rotate right value is 0010, which means that we will rotate 10 (as a 32 bit value) to the right by four places. So 0x0000000A would then be 0xA0000000, which is a much larger value in decimal (2,684,354,560).
This is the type of thing that means that an instruction like 'MOV r0, #2684354560' is completely valid. On the other hand, 'MOV r0, #2684354500' is not valid. The distinction is unfortunately not super obvious to the naked eye.
\n\n
Before digging into types of solutions to this issue, I would like to take a small detour about the range of possible numbers you can use, as the behavior here is incredibly interesting in my opinion. Due to the power of rotating bits around, you really can use numbers anywhere from zero to 4 billion and some change, with only 12-bits, or 4,096 possible values. Did I say 4,096 values? this is not true either! There are redundancies, we can rotate one 8-bit value by a certain amount that has the same result of rotating a different 8-bit value by a different amount (we will circle back to this soon). In reality, 25% of these encodings are redundant. There are only 3,073 unique values after eliminating redundancies.
\nWe might also have some intuition that the spread of numbers isn't linear. As in we should know we can literally use values 0-255 with no issue (as we have an un-rotated version of the first 8-bits). Starting at 256 we start counting in fours; as in 256, 260, 264, etc. After 1,024 we start counting in 16's and so on. However, if graphed, the result isn't as exponential as one would expect. There are clusters of numbers that hover on the incrementing by 1 for some stretches, conveniently around half way through as well (two billion and some change). I say conveniently because this allows us to capture small 2's compliment negative numbers. As in, all of these unsigned numbers 2147483648-2147483711 (0x80000000 - 0x8000003F), can be encoded without modification. So this gives us a run of about the first 64 negative integers, not bad. Below is a graph of this spread:
\n
Because redundant. Though it does turn out that there is corresponding assembly for these redundant forms that achieve the same thing (due to some syntactical sweetness). Let's look at an example of MOVing 192 into r0. This can be done vanilla with just 'MOV r0, #192'. The 12-bit encoded value would be 0x0c0. But there are other ways. We could encode 3 into the 8-bit part of the 12-bit encoding and '0xd' into the ROR 4-bit field; which effectively rotates the value 3 in a 32-bit field to the right by 26 places (0xd03). The result is 192. We could also rotate 12 to the right by 28 places (0xe0e). Finally, we could rotate 48 to the right by 30 places to get 192 (0xf30).
\nIn the ARM manual, the syntax for this MOV instruction is: MOV{S}<c> <Rd>, #<const>
To break this down, the {S} is a 1-bit field that specifies if we want to set any conditional flags. The <c> is a 4-bit field specifying under which condition to execute MOV, if you don't include this, the default is to execute under any condition. <Rd> is the destination register that you want your result value stored in. Finally, #<const> is the number you want placed into Rd. What isn't shown for the syntax in this part of the manual (though I remember reading elsewhere in the manual that you can do this) is that you can also specify the ROR value that you want. I would revise the syntax to: MOV{S}<c> <Rd>, #<const>, ror_amount for my own personal use.
All of the below assembly instructions are valid and all achieve the same thing:
mov r0, #192 @e3a000c0
mov r0, #3, 26 @e3a00d03
mov r0, #12, 28 @e3a00e0c
mov r0, #48, 30 @e3a00f30
\n
So say your in a situation where you want to move an immediate large value into a register, but you don't have a good idea of if it is compatible with this format? There are plenty of unsatisfying answers to this question online. Although I probably spent more time on this blog post than I did researching good solutions to this issue. I'll talk about some of the different approaches I have seen to this issue, including my own approach and my own tool.
\n\n
One of the first resources I came across was https://alisdair.mcdiarmid.
Next up, you will likely find numerous scripts that will take your number as an input and tell you whether or not the number is encodable. I feel like this kind of a tool is a complete waste of my time. Why? I can just try writing 'MOV r0, #2684354500' in assembly, and my assembler will quickly tell me \"Error: invalid constant (9fffffc4) after fixup\" and at which line this was found. This kind of tool also doens't give me context as to which numbers I CAN use that are close to this one.
\n\n
There's another approach that kind of side-steps my question altogether. What I like about it is that it is consistent and you don't have to worry about post-processing the number to get it to fit. This solution is to put the number in a .data section and ldr it. What isn't immediately obvious about this solution, however, is that it takes up more data than it first appears.
\nThe number in the data section itself takes up 32 bits. As far as the assembly goes, you need 2 instructions: one to load the pointer address ('ldr r0, =pointer'), and another to de-reference it ('ldr r0, [r0]'). That's another additional 64-bits of data. However, there's another 32-bits that are needed for something way less obvious. In the encoding of this ldr instruction, it always de-references; there's no such thing as ldr just getting a pointer. In actuality, the assembler itself does some behind the scenes magic. At the end of you're .txt section, the address for 'pointer' (or whatever you name it), will be stored. The instruction 'ldr r0, =pointer' replaces =pointer to that end of .txt address, which contains the real pointer. In that context, 'ldr r0, =pointer' is still dereferencing and getting a value, it's just that this value is an address for the value you really want.
\nIn conclusion of this method, it takes 16 bytes (equivalent of 4 instructions) to achieve loading any arbitrary value into a register. The benefit of this instruction is that it is easy and consistent (in both the instructions used and the size taken). Though it consumes 16 bytes of data, run-time only requires 2 instructions of execution (although they are memory operations).
\n\n
This is my favorite method when it makes sense to use it. This method involves moving the closest valid number to the one you want to move into a register and then using an ADD or SUB to make up for the difference.
\nThere are challenges to this though. First, it's not readily easy (without some kind of tool) to just guess what the next closest encodable number is to the number you want. Next, it is also possible that the number it would take to ADD or SUB to get to your number is also not encodable, meaning you may have to do more than one ADD or SUB. Finally, and related to the previous point, if you hit a point where you're doing 4 or more ADD/SUB operations, you would be taking up more disk space than the LDR method. Additionally, it's not only 4 instructions worth of storage, but 4 instructions executed too, however, these are all direct register operations (quicker).
\nWhy do I prefer this method? Assuming I'm not going to have to deal with all of these annoying calculations myself, I like the elegance of it, subjective, I know. But I like that all the information regarding this operation is all right there in-line. I don't have to refer to a .data section. It also usually takes up less space than the LDR method. The space savings may not be enough to justify for some, but less space is less space. However, if I didn't have some external tool to make this process easy, I would probably just be lazy and use the LDR method.
\n\n
Regarding the following question: \"Is 2684354500 easily encodable, if not, what are the closest numbers surrounding it?\" I wrote a tool to answer this question and additionally suggest a solution to the Post Processing method. I was going to write this tool in a high level scripting language like a bitch, but then decided to write it in ARM assembly.
\nThe tool is called ImmSuggest, it takes one argument; the number you want to encode. If the number is encodable, it just gives an example instruction such as 'mov r0, #200' (assuming your number was 200).
\nIf your number is not encodable, the tool will display your number surrounded by the next lowest and highest number that is encodable. Next it gives a series of instructions that would get your number into register r0 with a MOV and ADD instructions. For example, say you wanted to encode 301 (not encodable), the output of the tool would look like this:
300 < 301 > 304
mov r0, #300
add r0, #1
300 is encodable, so is 304. If those numbers are good enough for you for your use-case, you can just choose one of those instead. Otherwise, move 300 into your register, and then just add 1 to it.
\nAgain, our question: \"Is 2684354500 easily encodable, if not, what are the closest numbers surrounding it?\"
./ImmSuggest 2684354500
2667577344 < 2684354500 > 2684354560
mov r0, #2667577344
add r0, #16711680
add r0, #65280
add r0, #196
Note, this isn't perfect at all, which is nice that it also displays the surrounding closest numbers for us. I say that because you may notice that the number we want to encode is actually only 60 away from the next highest encodable integer. This means that the following code would also work:
mov r0, #2684354560
sub r0, #60
For simplicity, I wanted to just keep this to MOV and ADD instructions. I thought about doing a series of the most efficient combination of ADD and SUB instructions, but it weirdly got more complicated than I felt dealing with. Especially with the limitations I gave myself.
\n\n
This is all self-imposed, hence why stupid. This program is about 16k and runs pretty fast. I know, it would run fast in perl/python/ruby/etc as well, as it's not that complicated. I mostly chose the challenge of writing this in assembly, since it is about assembly. I also tried to be pure and not rely on external libraries (notably libc).
\n\n
This is often a mutually exclusive trade-off and this program is no exception. Where this really stands out is that I pre-generated a header file that contains a sorted list of all 3,073 valid encodable integers. This is about 80% of the resulting program. The program could be significantly smaller if it just dynamically generated all of these values and put them into memory, however, this would also add a lot of cycles that would be executed every single time the program is run. With the pre-computed header file, this needs to be done none of the times.
\n\n
Even though I have been using the libc library from assembly quit a bit lately, I decided to throw away all of its usefulness and overhead and only rely on Linux API functionality to do my work. Just linking with gcc costs 3,000 instructions of execution, and then another 1,000 instructions of execution for the first time of use of any function (your printf's, malloc's, isupper's, etc...). Granted, either strategy of whether to use libc or not will still result in this program executing in an un-noticable fraction of a second, my version currently executes in anywhere from about 325 - 6900 instructions (depending on how large the argument is; as this affects how complicated the result is).
\nIn other words, on average, this program finishes before a gcc linked executable would even be done loading it's functions. If you use more than 4 libc functions (printf, malloc, getopt, etc...), youre libc overhead already runs slower than even the worst case run of my program. In a best case run of my program, a gcc linked program wouldn't have even gotten to your part of the code (main function) yet. Don't get me wrong, I don't hate libc, and I understand much of the benefits of dynamic linking of shared libraries. But I also rage when I see shit like this: https://stackoverflow.com/questions/3233560/in-c-is-it-faster-to-use-the-standard-library-or-write-your-own-function (honest question, naive and misled text-book answers). So I guess what I'm trying to say is I wrote my program this way out of principle.
\nThroughing away libc brings challenges though, even the simplest things. For example, I want to print the value of a register to stdout, but as an ASCII decimal number. Printf would make that effortless, but I'm not using printf. One good way to get a decimal equivalent is to massage the data through many rounds of div by 10 and extracting the modulus values. This is all and good, but my Raspberry Pi doesn't support the div instruction. The code for this actually has to be written as well. I cheated with this a little, by manually 'statically' including a version of divsi3 from libc (as it both does division and keeps the remainder). Though halfway through modifying divsi3 to my needs, I realized it worked on signed values instead of unsigned. And the udivsi3 function didn't seem to capture the remainders of the divs. So I just kind of strategically commented out most of the rsb (negate) instructions from divsi3 and things worked out.
\nGetting an argument from stdin was actually pretty easy, as arguments are on the stack. Converting the ASCII number to a register value takes more work than acquiring it from the stack.
\n\n
Therez none. If you supply an integer too large (to fit in 32 bits), you'll get stupid answers back. If it's not an integer, stupid crap back. If it's not even a number, stupid crap. I removed the div by 0 error checking in the soft division routine, I'm always dividing by 10. I hope that decision enrages at least one person.
\nSo you know, do this, I don't care:
./ImmSuggest burgers
57409536 < 57621027 > 57671680
mov r0, #57409536
add r0, #210944
add r0, #544
add r0, #3
(or another perspective on the Invoke vs Call argument)
\nThe video version (for the illiterate) can be found at: [youtu.be/QyjXBv3sq...](https://youtu.be/QyjXBv3sqRY)
\nI'm in the process of re-certifying for the GREM certification (GIAC Reverse Engineering Malware). Although I'm pretty good with assembly language in a handful of architectures (Motorolla, x86, propeller, and ARM), my skills are shit with Windows and its APIs. In the context of GREM and static code analysis goes, I still have a ways to go; a 'not seeing the forest for the trees' issue. I will still likely pass the certification like last time, because I understand most of the concepts in their compartmentalized pieces. My problem is some of the big picture stuff (always has been). I joke about everything being too high level, and honestly, most of the time it really is a joke or an extreme over exaggeration. But for me, I sometimes do have a harder time comprehending an abstraction when it abstracts away how things actually work. For most people, it doesn't matter how the technology works, so long as it does. However, as a hacker, I have technology 'trust issues'; things don't always 'just work.'. And the abstraction likely wont give you any hints as to why the thing failed, the answers are revealed at a lower layer.
\nBlah blah blah, I digress. I wanted to set out to learn many of these Windows APIs in a bit more detail. Reverse engineering usually teaches how to read the code, but my (and probably your) comprehension magnifies when we actually write code. So in this case, I wanted to set out and write a few very simple assembly programs that put the correct arguments on the stack and call a Windows API, just how I see this happening when debugging some malware, just how it is supposed to work. As a point of reference I am using the FLARE VM setup from FireEye. It comes with fasm, so that's the assembler I will use (I don't really have religious preferences with an assembler).
\nFor API's, the Windows way is a bit different than the Linux way. For Linux, generally, you put all of your arguments in registers and then do an Int 80 (interrupt to Linux). In windows, with 'sdtcall' functions, you push all of your arguments to the stack and Call the Windows API function by name (the corresponding addresses of these functions end up getting linked in). I'm not really opposed to this method, it allows for a large amount of arguments by default, as it's the stack, not a limited amount of registers.
\nAs I didn't know the fasm ways of assembly, I looked to the Internet for some examples. I wanted to create a simple dialog box. I expected to see a simple assembly program with a .data section with the strings and then the .text (.code) section with some instructions pushing the arguments to the stack and then a call to the API function. For pretty much every google result I got, what I got back was a heavily abstracted version of how this is generally done, and the ironic bonus: NO ASSEMBLY INSTRUCTIONS!
\nBefore I get to that, I will say that I eventually figured out the way to do this with real assembly language in the source file. And it was as straight forward as I would have expected it to be. For reference, here is a screenshot of the source program:
\n![](\"https://xlogicx.micro.blog/uploads/2026/e01bc77c62.jpg\")
This is what it looks like in the x64dbg debugger:
\n![](\"https://xlogicx.micro.blog/uploads/2026/e8e8b48d0d.jpg\")
Note that the assembly looks awfully similar to the source. This is no mistake. This is exactly what I'm going for here. Remembering that my goal is to try and understand what is actually going on with these API functions, this is the most comprehensible way to go about this. You'll notice that all the arguments are on the stack and ready to go for when I'm about to call them. And it is extremely clear how they all got onto the stack (the 4 preceding push instructions).
\nOkay. Now let's talk about the 'no assembly required' way that is recommended to write this. Because the source code is easier to read. Because it's 'cleaner code.' Because assembly language is so 'hard' to write that you might as well write assembly programs that don't use assembly instructions (then just give up and fucking use python). Anyway, here's a screenshot of the 'clean' way to do this:
\n![](\"https://xlogicx.micro.blog/uploads/2026/d52171a2d9.jpg\")
It is clearer to read. If there were no comments in my version, then the 'invoke' version would be much more obvious in its intentions. But now, here's a screenshot of how dirty and incomprehensible this is in the debugger:
\n![](\"https://xlogicx.micro.blog/uploads/2026/359669f301.jpg\")
Before I start ranting and criticizing, I have to be fare and state that the examples I found on the Internet didn't use a .data section and inlined the strings in the invoke section (cleaner source code). This is the real cause of the mess of the disassembly. Had I used a .data section with this invoke command: 'invoke MessageBox,HWND_DESKTOP,message,title1,MB_OKCANCEL', it woulnd't be so bad. I digress. So note that even though the source code is 'clean,' what's actually being 'assembled' (compiled really) is nothing but. You see as we are about to make the call, all the right arguments are on the stack. I see two of the original pushes needed for two of our arguments (push 1 and push 0). We also need two more arguments; we need pointers to our strings for the title of the window and the message in the window. How on earth did these get into the stack, and what the fuck are these confusing instructions doing in our program. Do we really need to do ARPL, INSB, OUTSD, DAA, and IMUL instructions? Well no, that's not what is happening. What we are actually seeing is a disassembled representation of our strings. See our first call to 'syscalls.40201B', it's jumping past our first string. A call normally knows how to return to where we came from by pushing the address of the next instruction to the stack. In this case though, our program doesn't intend to return to this at all, it is using that pushed address as a side effect, as that address really is the first byte of our string, it serves as a pointer to it, and it is now on the stack conveniently as an argument. So that call jumps us to another call that does the same thing; it skips over the next string that follows it, getting a pointer to it on the stack, indirectly. So that second call instruction brings us all the way down to the 'push 0' instruction right before our API call to MessageBoxA. These abused CALL instructions are how we got the string arguments onto the stack.
\nThe end result is the same. As somebody that has to read or write the assembly source, using invoke is likely a better way to write and collaborate. However, nothing about it is actual assembly language, it abstracts it away. It's not like this behavior is uncommon or indefensible. Compilers do this kind of thing all the time, even when they aren't optimized that much (and when they are optimized, wow). Joking aside, using invoke is probably the way to go if your writing something more serious, although, why not just use C? Writing \"assembly\" in shortcuts and macros with no actual assembly sounds a lot like a higher level language (like C). This is why I always found HLA (High Level Assembly) so objectionable. Though to be clear, I respect the Author of HLA and he has done other really amazing work.
\nA lot of arguments of which way is better than which (with many things) comes down to what your doing at the moment. In the use case from the paragraph above, invoke away. But to return to my use case, I'm trying to familiarize myself with some simple Windows API calls by playing with different arguments in assembly and calling them, and then watching them perform their actions in a debugger (as not all API's will do something visual; I might have to see the stack, registers, and memory getting manipulated). Using invoke for this strategy makes this process all the more confusing.
\nAll this said, you might be able to see why I have a little ways to go when it comes to fully reverse engineering Windows binaries. Not to be confused with targeted reversing. I'm somewhat adequate with looking at particular APIs and pulling out IOCs from the artifacts they leave behind, and all the other 'cheater' dynamic forms of analysis. But if I ever want to see a bigger and fuller picture, I'm going to want to start writing the assembly that I'm reading and put bigger pieces of the puzzle together. At least, that's the plan.
\n", "date_published": "2018-10-05T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2018/10/05/invoke-is-too-high-level.html" }, { "id": "http://xlogicx.micro.blog/2018/09/25/arm-assembly-is-too-high.html", "title": "ARM Assembly is Too High Level - ROR and RRX", "content_html": "Note: If you prefer video format to reading stuff, there's a companion video for this: https://youtu.be/ONQLWdd5nuc
\nLooking at instruction encodings, 'ROR r0, #0' should be the same as 'RRX r0, r0'.
\nLet's first take a look at the encoding for the ROR instruction:
\n![](\"https://xlogicx.micro.blog/uploads/2026/e959ab5b2c.jpg\")
\n
So Rm gets rotated imm5 places and gets stored into Rd
\nNow let's look at the encoding for RRX:
\n![](\"https://xlogicx.micro.blog/uploads/2026/344f632120.jpg\")
\n
Note that the encoding is identical to ROR, with the exception that the imm5 field is harcoded to 0.
\nSo if we were to write 'ROR r0, #0', we should expect this to disassemble as an RRX instruction; as we are merely mimicking these hardcoded zeros by providing '#0' as the imm5 value:
\n![](\"https://xlogicx.micro.blog/uploads/2026/436a2b06b8.jpg\")
\n
Yep! wait wut? Very much no. What is the encoding for this MOV instruction?
\n![](\"https://xlogicx.micro.blog/uploads/2026/915045e6b1.jpg\")
\n
Come on assembler, why don't you know that I wanted to do an RRX when properly writing ROR in such a way that should encode into RRX? You have no idea how many times I legitimately need to use ROR to use RRX instead of actually typing RRX in assembly (even if it's zero times).
\nAs a reminder from the ARM Assembly is Too High Level: Moving by Shifting post, the MOV instruction is just an LSL with it's immediate value set to 0's. If we were to take the 5 (of the 8) zeros following Rd and make them something else, the above MOV instruction would become an LSL by that amount. After these 5 bytes, the next 2 bytes define what kind of shift, rotate (or MOV) we are doing. For example, MOV and LSL are '00', LSR is '01', ASR is '10', and RRX and ROR share '11' (you can see this '11' field occur after the imm5 field in the first screenshot above). I really don't know why the assembler jumped from a ROR instruction to the MOV/LSL type instruction when giving it an imm5 value of zero. Sometimes assembly language is too high level for me to comprehend.
\n", "date_published": "2018-09-25T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2018/09/25/arm-assembly-is-too-high.html" }, { "id": "http://xlogicx.micro.blog/2018/07/14/arm-assembly-is-too-high.html", "title": "ARM Assembly is Too High Level - Moving by Shifting", "content_html": "The syntax for the register form of a Logical Shift Left is:
\nLSL{S}c Rd, Rm, #imm5
This will take a value stored in the source register of Rm and shift the bits left by the amount defined in #imm5. The result of this operation is stored in the destination register of Rd. Like many instructions on ARM, you can make it conditional defined by a condition code (c) and define if you want the flags to be set as well with {S}.
\nThe real question (for freaks like me) is what happens if you use #0 as the shift value, doesn't it just effectively move Rm into Rd? Wouldn't LSL r0, r1, #0 do the same thing as MOV r0, r1?
\nTo say that the answer is 'yes' should be obvious and also boring. The interesting thing is that ARM decides to make the machine encoding for LSL Rd, Rm, #0 equivalent to MOV Rd, Rm. Look at the encoding graphic near the bottom of the post for further context of this and the following info.
\nWhat about LSR? It effectively does the same thing as our MOV when imm5 is 0, but the machine encoding is off by one bit. Interestingly, LSL can have shifts from 0-31 (well, the manual says 1-31...), but LSR has shifts from 1-32, and there is no fucking way to force it to shift by 0. If directly writing the binary for the imm5 field of this instruction, and setting it to 00000, it actually ends up being LSR Rd, Rm, #32; that's how they fit that 32 in there (as 11111 is still 31 in binary). You can look to the last image in this post for a comparison how the source assembly is encoded.
\nSo the next question is what happens when we just write LSR Rd, Rm, #0? If what the ARM manual says is true about the 1-32 range, this instruction should be illegal (it kind of is). In the case of the 'as' assembler, it changes this to a MOV Rd, Rm, but with the exact same machine encoding as the LSL. See, the 3 bits between the imm5 and Rm field should be '010' for an LSR, it is '000' for the MOV and LSL. So the LSR Rd, Rm, #0 gets encoded as an actual different instruction even at the machine encoding level.
\nThis is all interesting. It just goes to show that it is regular behavior for an assembler to just take your shitty assembly and do whatever it fucking feels like with it. This is, I should remind everyone, because assembly language is too high level.
\nFor reference, here is a nice little graphic illustrating the machine encodings of each instruction discussed:
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/screen-shot-2018-07-13-at-10.57.35-pm.png\")
Also for reference is some source assembly instructions (cat'ed out) followed by a disassembly of the assembled program (using objdump):
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/screen-shot-2018-07-13-at-11.11.00-pm.png\")
BrainFuck is an 'esoteric' programming language with only 8 one-character instructions. I've used it here-and-there for well over a decade. I love minimalist languages, so RISCy. A brainfuck environment operates on a large array of data. There's an instruction to move the pointer in this array forwards and backwards and to increment or decrement it's value...that's already half the language. There's also an instruction for input or output of 1 character. Finally, there's an instruction to start and stop a loop. That's the language. There are many interpreters out there, I'm sure there are some compilers too, but I wanted to write a one-liner-esque command with common simple *nix tools. I actually ended up with 4 separate commands, but we will get to all of that.
\n\n
sed is the main tool I used to compile the BrainFuck code into x86. dd, printf, tr, and cat are helpers with formatting and staging the resulting 512-byte boot image output.
\nThis does mean that the output file is limited to 512 bytes (more like 470-ish bytes after some of the overhead).
\nEach BrainFuck command takes different amounts of bytes to encode:
\n>: 1 byte
\n<: 1 byte
\n+: 2 bytes
\n-: 2 bytes
\n,: 12 bytes
\n.: 5 bytes
\n[: 3 bytes
\n]: 10 bytes
The looping stack (controlled by '[', and ']') has 4k allocated to it. It is unlikely you will come to the nested loop limit with this.
\nThe data stack that you control with <, >, +, and - is about 21.5k (in theory)
\n\n
dd bs=512 count=1 if=/dev/zero of=out.bin; printf '\\x31\\xc0\\x8e\\xd8\\x8e\\xd0\\xbc\\x00\\x9c\\xbb\\x00\\xac\\xb4\\xb8\\x8e\\xc0\\xb0\\x03\\xcd\\x10\\xb4\\x01\\xb5\\x26\\xcd\\x10\\xb9\\xd0\\x07\\xb8\\x20\\x00\\x31\\xff\\xf3\\xab\\x31\\xff' | dd of=out.bin bs=1 count=38 conv=notrunc ;printf '\\x55\\xaa' | dd of=out.bin bs=1 seek=510 count=2 conv=notrunc; cat source.bf | tr '\\n' 'x' | sed -e 's/x//' -e 's/>/\\x43/g' -e 's/</\\x4b/g' -e 's/\\+/\\xfe\\x07/g' -e 's/\\-/\\xfe\\x0f/g' -e 's/,/\\xb4\\x01\\xcd\\x16\\x74\\xfa\\x30\\xe4\\xcd\\x16\\x88\\x07/g' -e 's/\\./\\x8a\\x07\\xb4\\x0f\\xab/g' -e 's/\\[/\\xe8\\x00\\x00/g' -e 's/\\]/\\x5a\\x52\\x80\\x3f\\x00\\x74\\x02\\xff\\xe2\\x5a/g' | dd of=out.bin bs=1 seek=38 conv=notrunc
\nLet's go through these 4 separate commands in detail:
\ndd bs=512 count=1 if=/dev/zero of=out.bin
\nWe are using an output file of out.bin. We want to start with a blank 512 byte file. So we use dd, set the block size to 512 bytes and use /dev/zero as the source of nulls to pad this file with.
printf '\\x31\\xc0\\x8e\\xd8\\x8e\\xd0\\xbc\\x00\\x9c\\xbb\\x00\\xac\\xb4\\xb8\\x8e\\xc0\\xb0\\x03\\xcd\\x10\\xb4\\x01\\xb5\\x26\\xcd\\x10\\xb9\\xd0\\x07\\xb8\\x20\\x00\\x31\\xff\\xf3\\xab\\x31\\xff' | dd of=out.bin bs=1 count=38 conv=notrunc
\nIn this command we are sending machine code to dd. It's 38 bytes of machine code (count=38). At a high level, this machine code sets up the environment so we have our stacks, video memory (for output), a routine to clear the screen, etc... Below is what a disassembly of this would look like (as it shows the machine code too). Even though this is partially an objdump output, I have included comments too
\n31 c0 xor ax,ax ;set ax to 0
\n8e d8 mov ds,ax ;DS=0
\n8e d0 mov ss,ax ;stack starts at 0
\nbc 00 9c mov sp,0x9c00 ;200h past code start, 4k of stack
\nbb 00 ac mov bx,0xac00 ;brainfuck stack location
\nb4 b8 mov ah,0xb8 ;text video memory
\n8e c0 mov es,ax ;ES=0xB800
\nb0 03 mov al,0x3 ;Set Video Mode
\ncd 10 int 0x10 ;syscall
\nb4 01 mov ah,0x1 ;Set Cursor Shape
\nb5 26 mov ch,0x26
\ncd 10 int 0x10 ;syscall
\nb9 d0 07 mov cx,0x7d0 ;whole screens worth
\nb8 20 00 mov ax,0x20 ;empty black background
\n31 ff xor di,di ;upper left corner
\nf3 ab rep stos WORD PTR es:[di],ax ;clear screen
\n31 ff xor di,di ;set cursor back to upper left corner
printf '\\x55\\xaa' | dd of=out.bin bs=1 seek=510 count=2 conv=notrunc
\nThe image file needs to end with 0x55aa to be considered a bootable image. So we use printf and dd to inject these bytes into the image
cat source.bf | tr '\\n' 'x' | sed -e 's/x//' -e 's/>/\\x43/g' -e 's/</\\x4b/g' -e 's/\\+/\\xfe\\x07/g' -e 's/\\-/\\xfe\\x0f/g' -e 's/,/\\xb4\\x01\\xcd\\x16\\x74\\xfa\\x30\\xe4\\xcd\\x16\\x88\\x07/g' -e 's/\\./\\x8a\\x07\\xb4\\x0f\\xab/g' -e 's/\\[/\\xe8\\x00\\x00/g' -e 's/\\]/\\x5a\\x52\\x80\\x3f\\x00\\x74\\x02\\xff\\xe2\\x5a/g' | dd of=out.bin bs=1 seek=38 conv=notrunc
\nThis is the compound command that does the real work!
First we feed the source file to our chain of commands with 'cat'
\nWe then use tr (translate) to replace the ending newline with the x character (because we can't just make it blank / remove it with tr)
\nThen we have a long line of find/replace commands with sed. The first one is simple, we now can just remove that 'x' that we put in there, so there are no longer any newlines.
\nThe rest of the find/replace (regex) sed arguments are to literally find BrainFuck instructions and replace it with equivalent machine code. Before we explore each instruction, let's make some notes about our environment. I mentioned that we are using a large array in our environment, we will be using the 16 bit 'bx' register to track this; we use it as a pointer that we increment and decrement. I considered not even using a real stack for this resulting program, because it is mostly not needed as a concept, but I ended up needing it for the looping instructions, which I will get to
Instruction: > (increment array pointer)
\n43 inc bx ;bx is our pointer, increment it
Instruction: < (decrement array pointer)
\n4b dec bx ;decrement pointer
Instruction: + (increment value in array)
\nfe 07 inc BYTE PTR [bx] ;increment the value
Instruction: - (decrement value in array)
\nfe 0f dec BYTE PTR [bx] ;decrement the value
Instruction: , (Take keyboard input)
\nb4 01 mov ah,0x1 ;check if keyboard input
\ncd 16 int 0x16 ;interupt for it
\n74 fa je 0x2c ;keep checking if no input
\n30 e4 xor ah,ah ;get keypress
\ncd 16 int 0x16 ;interupt for it
\n88 07 mov BYTE PTR [bx],al ;put keypress in array
Instruction: . (Print character)
\n8a 07 mov al,BYTE PTR [bx] ;get character from array
\nb4 0f mov ah,0xf ;make sure video background is still black (possible this isn't needed)
\nab stos WORD PTR es:[di],ax ;display the character
Instruction: [ (Start the loop)
\ne8 00 00 call 0x40 ;pushes address of next instruction onto the stack
Instruction: ] (End the loop if array at pointer is zero)
\n5a pop dx ;get loop start
\n52 push dx ;keep it on the stack
\n80 3f 00 cmp BYTE PTR [bx],0x0 ;is the value zero yet
\n74 02 je 0x49 ;if so, the loop is over, jump past it
\nff e2 jmp dx ;otherwise, go back to the beginning of the loop
\n5a pop dx ;return stack to pristine state
\n
Just to show this works, I used the first two examples from Wikipedia's article on BrainFuck
\n![](\"https://xlogicx.micro.blog/uploads/2026/9558070464.jpg\")
\n
![](\"https://xlogicx.micro.blog/uploads/2026/f16b5c7560.jpg\")
\n
![](\"https://xlogicx.micro.blog/uploads/2026/a4e042c593.jpg\")
![](\"https://xlogicx.micro.blog/uploads/2026/e8b5035dbb.jpg\")
\n
...because reasons
\n", "date_published": "2017-04-13T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2017/04/13/sedregex-based-brainfuck-compiler.html" }, { "id": "http://xlogicx.micro.blog/2017/02/09/assembly-is-too-high-level.html", "title": "Assembly is Too High Level - Commutative Property, Sometimes - it may save your byte", "content_html": "![](\"https://xlogicx.net/images/apples.png\")
I remember learning these properties in basic algebra: Associative, Distributive, and Commutative. It's the Commutative property that states that a + b = b + a. The same principle is true with multiplication. In x86 pointer math, of course the results of these operations follow the commutative property; that's just math. However, the machine encoding doesn't consistently take this into account. To be facetious with the blog title image, machine code takes apple color into account most of the time, assembly language just looks at the number of apples.
\nTo spoil everything from the beginning, 'xor byte [esp + eax], 0' is encoded the same as 'xor byte [eax + esp], 0'. In machine code, when using esp as one of two non-scaled registers as a pointer, the commutative property is acknowledged. However, any other of the 8 general purpose registers are not treated this way! In other words, 'xor byte [ebx + ecx], 0' is not encoded the same as 'xor byte [ecx + ebx], 0'
\n![](\"https://xlogicx.micro.blog/uploads/2026/a6805177be.jpg\")
The claim I just made is slightly unfair though, or unfair-ish. Assemblers (like nasm) allow us to get kind of loose with our assembly. An instruction like 'xor byte [ebx + ecx], 0' isn't really showing the whole story. In assembly, these pointers are made of up 3 parts (all 3 are optional...ish): one base register, one scaled register, and one displacement (8/32 bit offset). Scaled registers can be multiplied by 1, 2, 4, or 8. So more accurately, the above instruction is actually a base register of 'ebx' + a scaled register of 'ecx' with a scale of 1 (multiplied by 1). In machine code, the encoding of a base register and scaled register are encoded entirely differently.
\nWith the above knowledge in mind, it's no surprise that 'xor byte [ebx + ecx * 1], 0' is not the same as 'xor byte [ecx + ebx * 1], 0'. Even if the result of what memory location this points to is the same (it is), it is now obvious why these are encoded differently...except for when it's the 'esp' register...
\nWhen writing assembly, 'xor byte [eax + esp * 1], 0' would get encoded the same as 'xor byte [esp + eax * 1], 0'. The actual encoding for both more accurately represents the 2nd form of this instruction: xor byte [esp + eax * 1]. Remember, the esp register can not be scaled (Why ESP doesn't scale (But EBP can still Base) post). If I were to write 'xor byte [eax + esp * 2], 0' instead of '* 1', I would get an error from my assembler. Instead, my assembler (nasm) is clever enough to know that even though my instruction (scaling esp by 1) is not valid, it replaces it with an equivalent instruction (using the commutative property), and all is well. But without knowing machine code, this would all be happening magically behind the scenes to us, because assembly is too high level.
\nBefore we forget, lets take a look at ebp, because the ebp register also gets encoded differently sometimes in memory pointers. Even though esp can not in any case be encoded as a scaled register, making ebp the base register can be done, but comes with a compromise: the displacement component of the pointer is no longer optional. So if you didn't include a displacement in your assembly, the assembler will add a zeroed out byte as a displacement for you. In other words, 'xor byte [ebp + eax], 0' is actually more accurately 'xor byte [ebp + eax + 0x00], 0'.
\n![](\"https://xlogicx.micro.blog/uploads/2026/b6a05c9e74.jpg\")
So taken the above information about the encoding of ebp, we are faced with a trade-off. This is one of those times where my assembler takes me literally, in the sense that it obeys making ebp the base (first) register (even though it may add an extra null byte behind our backs to do it). So even though, 'xor byte [eax + ebp * 1], 0' logically does the same thing (commutative property), nasm does not choose this form, because it doesn't need to do this, like it does with the scaled esp register. The interesting thing is that this alternate form of the instruction is a byte less (because it doesn't need that displacement byte). The takeaway is that if you are using two unscaled registers in your pointer, and ebp is one of them, and you didn't already have a displacement: make ebp the last one (all to save one byte)
\n", "date_published": "2017-02-09T09:00:00-04:00", "url": "https://xlogicx.micro.blog/2017/02/09/assembly-is-too-high-level.html" }, { "id": "http://xlogicx.micro.blog/2017/02/01/assembly-is-too-highlevel-signed.html", "title": "Assembly is Too High-Level - Signed Displacements", "content_html": "For those that don't know about unsigned and signed data types, it's not all that complicated. One byte can hold a total of 256 possible values. If these values were only positive numbers and included zero, we would have a number range of 0-255. But what if we wanted negative numbers? The byte is divided; we now have a range of -128 through 127. When including zero, this is all 256 possible values. The data is formatted as [en.wikipedia.org/wiki/Two'...](https://en.wikipedia.org/wiki/Two's_complement)
\nWith a 32 bit register, we have four bytes, giving us 0-4,294,967,295 for unsigned values and -2,147,483,647 through 2,147,483,647 for a signed value.
\nWhen using instructions that use memory locations for an operand, we are allowed to use literal displacements. For example, we can use an address/pointer stored in EAX and add 128 to the address (not value). This 128 is called a displacement, or offset. This displacement can be up to 32 bits, but if the displacement is small enough, it can be encoded as 8 bits.
\nOne thing to note however, is that this displacement is a signed value. At least for me, the documentation of this fact was subtle. And in practice, if you operate at the level of abstraction that assembly language provides and don't know this subtlety, it is possible to run into some unfortunate bugs.
\nA good example is the two following lines of assembly language:
\nlea ebx, [eax - 1337]
\nlea ebx, [eax + 4294965959]
As it turns out, when it comes to machine code, both of these instructions are completely identical. Remember to look up to the range of a 32 bit signed value, the range stops after around 2 billion; it doesn't go all the way up to 4 billion as in the above lea instruction example. This 4 billion value would be valid as an unsigned 32 bit number, however. Nasm doesn't appear to care about warning us; it just encodes this positive 4 billion number as if it were unsigned. But when you actually execute this instruction, it is surely treated as a signed number (which turns out to be -1337).
\nExhibit A:
\n![](\"https://xlogicx.micro.blog/uploads/2026/ce5c1dbd82.jpg\")
We see that the 2nd line of assembly has the eax-1337, even though the machine code has a value of 0xfffffac7 (2's compliment little endian). My assembly source actually used lea ebx, [eax + 4294965959] to generate that line. Even though my source added a large source number, and the machine code appears to be a large number (if it weren't 2's compliment), the disassembled version in edb (not how my original source was written) is what is actually executed. We know this because 0x80000000 - 1337 is 0x7ffffac7 (the result that gets stored into ebx shown in the screenshot).
\nHere's another thing to think about that can get glossed over when not paying attention to the details. In 32 bit, negative 1337 is represented as 0xfffffac7 in 2's compliment. if this value were to be interpreted as unsigned, it's value would be 4,294,965,959. This is where I got this value to use in my examples above.
\nDoes this same logic work in 8 bit? Say we use negative 100. This is 0x9c in 2's compliment and as an unsigned 0x9c is 156. So to review, these two instructions are the same:
\nlea ebx, [eax - 1337]
\nlea ebx, [eax + 4294965959]
Does that mean that these two are too?
\nlea ebx, [eax - 100]
The answer is no. Note the below screenshot showing the difference between adding 127 and 156:
\n![](\"https://xlogicx.micro.blog/uploads/2026/63d1d7935d.jpg\")
As a signed number, 156 would be too big to fit into 8 bits, so nasm graduates this to 32 bits instead, and it actually gets interpreted as positive, where as the 4 billion positive number is unable to graduate to anything higher than 32 bits, as there is no machine encoding for this (even in a 64 bit architecture; this encoding is not part of the Mod/RM encoding).
\nWhat about this instruction?:
\nlea ebx, [eax + 4294967292]
\nBelow is the same instruction represented in hex instead of decimal:
\nlea ebx, [eax + 0xfffffffc]
The resulting machine code is 8d58fc. Where'd all the f's go? They are leading f's, just as there's a such thing as leading zeros. As in 00003 is the same thing as 3. In twos compliment, f's in a negative number are leading f's. This number represents -4, this number is small enough to fit into 1 byte; all the leading ff bytes can be dropped.
\nAnd on the other hand, the below assembly instruction:
\nlea ebx, [eax + 0xfc]
\nHas the machine code of 8d98fc000000; a bunch of leading zeros (looks like trailing due to little endian) get added to the machine code. nasm must pick between the ambiguities of 0xfc. Does the author mean '+ 252' or do they mean this to be a signed value of '-4'? Nasm chooses to interpret 0xfc as positive, but if it were to put this data into only one signed byte, it would actually represent negative 4, therefore has to be placed into 4 bytes.
\n", "date_published": "2017-02-01T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2017/02/01/assembly-is-too-highlevel-signed.html" }, { "id": "http://xlogicx.micro.blog/2016/08/29/boot-sector-graphical-programming-tutorial.html", "title": "Boot Sector Graphical Programming - Tutorial", "content_html": "This tutorial is aimed at those that have some assembly experience, but very minimal 16-bit BIOS programming experience, in other words; a short list of some of my friends that I want to coerce into doing some BIOS programming.
\nQemu
\nAssemble source: nasm yourboot.asm -f bin -o yourboot.bin
\nRun with qemu: qemu tronsolitare.bin
\nRun with qemu (alternate): qemu-system-i386 -hda yourboot.bin
VirtualBox
\nCreate floppy image: Use this padding in 2nd to last line of code: 1440 * 1024) - ($ - $$) db 0 (instead of times 510-($-$$) db 0)
\nRun floppy image in VirtualBox: Create a low spec VM and set it to boot to yourboot.bin as the floppy image. Either rename image file to tronsolitare.img or use: nasm yourboot.asm -f bin -o yourboot.img
Disassembly
\nDisassemble tronsolitare.bin with objdump: objdump -D -b binary -mi386 -Maddr16,data16 tronsolitare.bin
\n\n
These programs are small, as in only 512 bytes of code. Fortunately, you don't have to do absolutely everything, there are some extremely useful BIOS routines that you can call to do some heavy lifting. A good guide/lookup of these routines can be found at [wiki.osdev.org/BIOS.](http://wiki.osdev.org/BIOS.)
\nIn the below examples, an 80x25 (80 columns and 25 rows of characters) display is assumed. This isn't the only mode, it's just a mode I feel comfortable with. It's actually not too small. The main reason to not go too much bigger is the memory challenges that you will already have will get even more noticeable.
\nEach 'character' is actually 2 bytes (16-bits) of information. The first 4 bits is the background color, the next 4 bits is the text color, and the last 8 bits is the actual character. The 8-bit character is not ASCII however (it is similar), it is code-437. [en.wikipedia.org/wiki/Code...](https://en.wikipedia.org/wiki/Code_page_437) has more information on this.
\nYou will have a register (di) that points to this video memory. It starts at the upper left of the screen. As you increment di, it stays on the same row and moves to the right. After it reaches the end of the row, it moves back to the left on the next row.
\n\n
This section will have snippets of code to get you started
\n\n
This is really the only required part that you need in your bootable image. This should be your last 2 lines of code.
\n\n\ntimes 510-($-$$) db 0
\n
\ndw 0xAA55
The last line of code is a 2-byte signature that must be at the end of your image file. The line of code above it makes sure that no matter how much code you write, your image file will be exactly 512 bytes (after your code, the rest of the file will be filled with nulls, and then end with the signature.
\n\nThis should be the first line of your assembly file when using the nasm assembler
\n\n\n[ORG 0x7c00]
\n
\n
\n\nxor ax, ax ;make it zero
\n
\nmov ds, ax ;DS=0mov ss, ax ;stack starts at 0. Add these lines only if you plan to use stack (Call/Ret, Push/Pop, etc...)
\n
\nmov sp, 0x9c00 ;200h past code startmov ah, 0xb8 ;text video memory
\n
\nmov es, ax ;ES=0xB800mov al, 0x03
\n
\nint 0x10mov ah, 1
\n
\nmov ch, 0x26
\nint 0x10
This code does all of the BIOS video overhead. It initializes the data segment (to zero), it allocates an area of memory for the stack and puts the pointer at 0x9c00 (assuming you'll be using the stack, and you probably should), initializes video memory at 0xb800, sets the video mode to 80x25 (80 columns by 25 rows), and hides the cursor. For more video BIOS info, check out [en.wikipedia.org/wiki/INT_...](https://en.wikipedia.org/wiki/INT_10H.)
\n\n
di - pointer to video memory location
\nax - pixel data bfcc (4 bit background color, 4 bit foreground color, 8-bit character (code 437))
\ncx - counter used in combination with stosw
\nstosw - puts ax data into di (video memory) and decrements cx
\nscasw - way to increment di with 1 byte (even though it's supposed to scan a string...)
\ncbw - 1 byte trick to zero out ah (zero mask) and leave al intact so long as al is less than 0x80
\n
\n\nmov bx, [0x046C] ;Get timer state
\n
\nadd bx, 2 ;2 ticks (can be more)
\ndelay:
\ncmp [0x046C], bx
\njb delay
This may look a little complicated, but it's not so bad. It's also the most reliable way that I've found to take keyboard input without lag, with continuous polling, and remembers last key pressed. For more keyboard information, check out [en.wikipedia.org/wiki/INT_...](https://en.wikipedia.org/wiki/INT_16H)
\n\n\nLEFT EQU 75
\n
\nRIGHT EQU 77
\nUP EQU 72
\nDOWN EQU 80;............
\n
\n;............;Get keyboard state
\n
\nmov ah, 1
\nint 0x16
\npop ax
\njz persisted ;if no keypress, jump to persisting move state;Clear Keyboard buffer
\n
\nxor ah, ah
\nint 0x16;Otherwise, move in direction last chosen
\n
\npersisted:
\npush ax
\n;Check for directional pushes and take action
\ncmp ah, LEFT
\nje left
\ncmp ah, RIGHT
\nje right
\ncmp ah, UP
\nje up
\ncmp ah, DOWN
\njne mainloopdown:
\n
\n;do down stuffleft:
\n
\n;do left stuff
\nup:
\n;do up stuff
\nright:
\n;do right stuff;do defualt stuff
\n
\nret
This instruction actually reads the time-stamp counter and puts the returned value into the ax register. Because of this, low bits are more random than high bits.
\n\n\nrdtsc
\n
\n\n;Hello World
\n
\n[ORG 0x7c00];Init the environment
\n
\nxor ax, ax ;make it zero
\nmov ds, ax ;DS=0mov ss, ax ;stack starts at 0
\n
\nmov sp, 0x9c00 ;200h past code startmov ah, 0xb8 ;text video memory
\n
\nmov es, ax ;ES=0xB800mov al, 0x03
\n
\nint 0x10mov ah, 1
\n
\nmov ch, 0x26
\nint 0x10;Fill in all blue
\n
\nmov cx, 0x07d0 ;whole screens worth
\nmov ax, 0x1f20 ;empty blue background
\nxor di, di
\nrep stosw ;push it to video memory;Print Hello World
\n
\nmov di, 0x07c4 ;coord to start 'YOU WIN!' message
\nhelloloop: mov al, [hello] ;get win message pointer
\nmov ah, 0x0f ;white text on black background
\nstosw ;commit char to video memory
\ninc byte [helloloop + 0x01] ;next character (self modifying code, 'helloloop: mov al, [hello]' is '[hello + 1]' next, and then '[hello + 2]', etc...)
\ncmp di, 0x07e4 ;is it the last character?
\njne helloloop;Infinite Loop To end the program
\n
\nendloop:
\njmp endloop;Hello World text
\n
\nhello:
\ndb 0x02, 0x20, 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f, 0x72, 0x6c, 0x64, 0x21, 0x20, 0x02;BIOS sig and padding
\n
\ntimes 510-($-$$) db 0
\ndw 0xAA55
I made a boot sector program (https://github.com/XlogicX/colors) to display all of the foreground/background colors. These are the hex codes that would be in the upper part of ax (ah) register right before a stosw. As an example, knowing that 0x58 is the character for 'X', E458 in ax right before a stosw would produce a red 'X' in a yellow background.
\n![](\"https://xlogicx.micro.blog/uploads/2026/e4fdc0d693.jpg\")
\n
Some examples of some projects out there that are boot sectors that don't boot to an OS (that I know of):
\nTetranglix (Tetris Clone with scoring)
\n[github.com/Shikhin/t...](https://github.com/Shikhin/tetranglix)
\n[github.com/XlogicX/t...](https://github.com/XlogicX/tetranglix) (nanochess added color)
TetrOS (Very old color Tetris Clone, but no score)
\n[github.com/daniel-e/...](https://github.com/daniel-e/tetros)
TronSolitare (Snake with Tron tailing)
\n[github.com/XlogicX/t...](https://github.com/XlogicX/tronsolitare)
\nBattle Snakes (Tron like clone)
\n[github.com/darkvoxel...](https://github.com/darkvoxels/battlesnakes)
\nBootSlide (15 number slider puzzle)
\n[github.com/XlogicX/B...](https://github.com/XlogicX/BootSlide)
\nBoot Me, Crack Me (Boot Sector CrackMe Game)
\n[xlogicx.net](http://xlogicx.net/?page_id=618)
\nValidation (Social Commentary Slot Machine Game, private repo, coming soon)
\n[github.com/XlogicX/V...](https://github.com/XlogicX/Validation)
\nBoot-Man (Pac-Man Game)
\n[github.com/guyhill/B...](https://github.com/guyhill/Boot-Man)
\nPillman (Another Pac-Man Game
\n[github.com/nanochess...](https://github.com/nanochess/Pillman)
\nDasher512 (Puzzle Game)
\n[github.com/QiZD90/da...](https://github.com/QiZD90/dasher512)
\nSnake
\n[github.com/JulianSlz...](https://github.com/JulianSlzr/project512)
\nInvaders
\n[github.com/nanochess...](https://github.com/nanochess/Invaders)
\nFbird (Flappy Bird Clone)
\n[github.com/nanochess...](https://github.com/nanochess/fbird)
\nPetty Bird (Another Flappy Bird Clone
\n[github.com/XanClic/5...](https://github.com/XanClic/512-petty-bird)
\nGlitchHeArt (Visual)
\n[github.com/kurtunder...](https://github.com/kurtunderscore/HelloPixelArt)
\nGoatse (Image)
\n[github.com/jbremer/g...](https://github.com/jbremer/goatse.mbr)
\nBoot2Sol (Game)
\n[github.com/masneyb/b...](https://github.com/masneyb/boot2sol)
\nNyanboot (Animated Image)
\n[github.com/XanClic/n...](https://github.com/XanClic/nyanboot)
\nPhosphene (Hi-Def Animated Fractal)
\n[github.com/kmcallist...](https://github.com/kmcallister/phosphene)
\n512B-bootloader-effect (Animated Graphic)
\n[github.com/pjanczyk/...](https://github.com/pjanczyk/512B-bootloader-effect)
\n", "date_published": "2016-08-29T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2016/08/29/boot-sector-graphical-programming-tutorial.html" }, { "id": "http://xlogicx.micro.blog/2016/05/11/cactuscon-slides-machining-a-love.html", "title": "CactusCon Slides - Machining - A Love Story", "content_html": "Here is the full ~6Mb image that I used as my slide deck within MS Paint in Windows 3.1 for my CactusCon 2016 presentation: Machining, A Love Story. Below the large image are all the images again, slide-by-slide, with brief notes; so there can be some context. All non-screenshot art done by KRT c0c4!N (my lovely girlfriend), it should be noted that I limited her to 16 colors with a specific pallet.
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/selection-019.png\")
The intro slide:
\n![](\"https://xlogicx.micro.blog/uploads/2026/37754bec72.jpg\")
\n
A slide showing the 2016 CactusCon art in less than 16 colors:
\n![](\"https://xlogicx.micro.blog/uploads/2026/ad386f0322.jpg\")
\n
The 'ToC' slide summing up what's to come:
\n![](\"https://xlogicx.micro.blog/uploads/2026/9644864f2e.jpg\")
\n
As a teenager, I got my first family computer, a 486DX. Playing games on a SNES or SEGA I felt like I was playing games from the 'gods.' But playing games on a computer made me realize I was using the same platform that could allow me to be one of the gods: I wanted to learn to program.
\n![](\"https://xlogicx.micro.blog/uploads/2026/a954283307.jpg\")
\n
I tried QBasic, which was fun at first. But I didn't want an interpreted language. I wanted to write software where I could just run the executable standalone; where the program was the machine code meant for the processor, not an interpreter.
\n![](\"https://xlogicx.micro.blog/uploads/2026/bf9876f172.jpg\")
\n
I wanted to see what a 'real' program looked like. So I dropped a program into Notepad and inspected. Even though I knew this code was not printable, I still had a feeling that if I could understand these characters, and had the right editor, I would have all I needed to write software (this assumption turns out to be correct, it's just too bad I didn't find the answer until way later in life)
\n![](\"https://xlogicx.micro.blog/uploads/2026/ab2b4c494e.jpg\")
\n
I found the nerdiest friend I new in school and asked him:
\n![](\"https://xlogicx.micro.blog/uploads/2026/8e66f054cc.jpg\")
\n
He responds:
\n![](\"https://xlogicx.micro.blog/uploads/2026/939f14c865.jpg\")
![](\"https://xlogicx.micro.blog/uploads/2026/a121c59cb5.jpg\")
\n
So I ask:
\n![](\"https://xlogicx.micro.blog/uploads/2026/f2a1d3f206.jpg\")
\n
He responds:
\n![](\"https://xlogicx.micro.blog/uploads/2026/39137af76c.jpg\")
\n
Remembering my exploration of a program inspected in notepad:
\n![](\"https://xlogicx.micro.blog/uploads/2026/9fb2eb6ae2.jpg\")
\n
He still persists, only knowing what he has heard, with no appreciation that there are lower levels handed to us by the false gods of abstraction:
\n![](\"https://xlogicx.micro.blog/uploads/2026/73cbc77063.jpg\")
\n
I remember this conversation for eternity. It is the moment I start to hate abstractions, to fundamentally know that if something can't be done at the layer of abstraction we are dealing with, one must only go a level deeper and repeat if needed (even though lower levels of abstraction are more difficult to deal with, they always come with more control and power):
\n![](\"https://xlogicx.micro.blog/uploads/2026/e35583a887.jpg\")
\n
This starts my journey to learning programming, assembly language, and machine code. I remember programming in BASIC for this TI-82. But then I learned you can program in assembly for it (Z80 chip). My first program cleared the screen (as intended). My second experiment cleared the memory (it was meant to be 'Hello World'). I gave up on this for a little while.
\n![](\"https://xlogicx.micro.blog/uploads/2026/f5c4df50a4.jpg\")
\n
Then I formally learned assembly (and even machine code) for the Motorola 68HC11 embedded system. For class, we didn't get a text-book. Instead we had a lab manual and the Motorola reference manual for this chip. The reference manual had every instruction and even the corresponding machine code for each instruction. After doing all of the labs, my personal project was to try to write some code that would replicate itself into memory right after itself. This required an appreciation for machine code.
\n![](\"https://xlogicx.micro.blog/uploads/2026/e1f889a2e2.jpg\")
\n
The next architecture I learned assembly for was the Parallax Propeller chip. I wrote a 4-channel wave table based audio driver in assembly. I put the chip in my 4-string bass with a NES controller as input. It was only until later that I experimented with Propeller machine code, only to find out that this architecture is the closest to 1-to-1 between assembly and machine code that I had ever seen. More on this project from the Bass + Computer post
\n![](\"https://xlogicx.micro.blog/uploads/2026/ed6c0d4e5d.jpg\")
\n
I finally learn x86 assembly. I learn it from some SANS GREM (GIAC Reverse Engineering Malware) training that a previous employer sent me to. It was actually a fantastic intro to x86 assembly. It also offered/explained a tool that can be used to convert 'shellcode' into a real executable program under windows. I liked this, but really wanted one for GNU/Linux instead (one did not exist at the time)
\n![](\"https://xlogicx.micro.blog/uploads/2026/e8156f7929.jpg\")
\n
I then read more than 10 books on assembly and all 3 volumes (3,500 pages) of the Intel Manual.
\n![](\"https://xlogicx.micro.blog/uploads/2026/2215256248.jpg\")
\n
I learned that Assembly is too high level. I wont go into too much detail on the next 3 slides; as the deeper explanation of these topics is contained within this same blog (in other posts), and is enough for a dedicated talk...
\n![](\"https://xlogicx.micro.blog/uploads/2026/5e827a6837.jpg\")
\n
My rant on responses I see on stackoverflow (not about the platform itself). Remember, I wanted something like shellcode2exe.py, but for GNU/Linux ELF. To see if there was anything like this, I started with a search, and found someone asked this question:
\n![](\"https://xlogicx.micro.blog/uploads/2026/024ffe9b00.jpg\")
\n
This was the first moronic (and highest upvoted) answer. It is assembly (not machine code, like the question asked for):
\n![](\"https://xlogicx.micro.blog/uploads/2026/19e7f67353.jpg\")
\n
In the comment of that first answer was this (correct):
\n![](\"https://xlogicx.micro.blog/uploads/2026/f56024b932.jpg\")
\n
This is probably the best answer, as it fully satisfies the question of having no headers (PE nor ELF). But there was no proof of concept :(
\n![](\"https://xlogicx.micro.blog/uploads/2026/7e3e404373.jpg\")
\n
Right above (with the moar shit), someone gives an 'example'. It is moar shit because the example is just more assembly (not machine code):
\n![](\"https://xlogicx.micro.blog/uploads/2026/3f1f727499.jpg\")
\n
Then there are these unhelpful tidbits. Being that ELF is not machine code and a.out is not an appropriate alternative to ELF in the context of wanting to do pure machine code.
\n![](\"https://xlogicx.micro.blog/uploads/2026/eed0fe2970.jpg\")
\n
Finally, I create something for my own needs; writing pure machine code / 'shellcode' and being able to run it, albeit in ELF format. It takes a machine code (ascii hex) source file, and makes an ELF executable of it. I respond with my tool and a proof of concept:
\n![](\"https://xlogicx.micro.blog/uploads/2026/bf66d46c15.jpg\")
\n
This is the closest thing to a helpful answer. Not only are we back to the DOS .COM format file (pure machine code, no headers), but there is a proof of concept; the fully functional and executable EICAR antivirus test file. But it wouldn't be stackoverflow if the most helpful answer wasn't the most downvoted and has the most ignorant responses. 'compiler' says that it doesn't look like machine code (it is). 'petersaints' states that this isn't machine code, and that it's just the EICAR test string (it is machine code, it also tests AV). For an in-depth debug of EICAR, see [thestarman.pcministry.com/asm/eicar...](http://thestarman.pcministry.com/asm/eicar/eicarcom.html) (it's elite). Also, my friend did a write-up on the same topic: [www.biebermalware.info/2016/05/p...](http://www.biebermalware.info/2016/05/playing-with-eicar-my-nerdiest-post-ever/)
\n![](\"https://xlogicx.micro.blog/uploads/2026/8ede6d2cd6.jpg\")
\n
So now starts the section where I give various ways to write raw machine code and execute it. Starting with the Windows platform and shellcode2exe.py. The screenshot itself shows how it is run:
\n![](\"https://xlogicx.micro.blog/uploads/2026/c889913905.jpg\")
\n
This ImmunityDBG screenshot is the output of the above shellcode2exe.py command. Note that I used assembly and machine code in the examples above about assembly being too high-level; hence a few ??? dissasemblies.
\n![](\"https://xlogicx.micro.blog/uploads/2026/5f8c0db883.jpg\")
\n
Below is a source file for my m2elf script. I have another blog entry that goes into more depth on these tools in the How to Machine post
\n![](\"https://xlogicx.micro.blog/uploads/2026/f4bf84ee9d.jpg\")
\n
A screenshot showing the running of the script and the executing of the result
\n![](\"https://xlogicx.micro.blog/uploads/2026/0f27852c9c.jpg\")
\n
NASM directives are another way of inserting literal bytes into otherwise assembly source files. The advantage of this is that it allows for 64-bit code (my m2elf script only supports 32-bit). The thing to be aware of is the memory order model, as things can tend to get reversed if you're not paying attention.
\n![](\"https://xlogicx.micro.blog/uploads/2026/1e52da5f37.jpg\")
\n
Another method is to write boot sector code. The slide below outlines the features of coding this way. I wrote a PoC that I call TronSolitare, [github.com/XlogicX/t...](https://github.com/XlogicX/tronsolitare)
\n![](\"https://xlogicx.micro.blog/uploads/2026/2fcd9924fb.jpg\")
\n
And to return a way to write raw machine code without headers, a method I could have used as a teenager, if only I had the right knowledge:
\n![](\"https://xlogicx.micro.blog/uploads/2026/09a8ea0d25.jpg\")
\n
Cheatsheet on how to use DEBUG to write machine-code
\n![](\"https://xlogicx.micro.blog/uploads/2026/f02927b45a.jpg\")
\n
Commented machine code for Hello World (as used in live demo):
\n\n48656c6c6f20576f726c642124 #Hello World!
\nba 0001 #mov 0100 to dx
\nb4 09 #mov 9 to ah
\ncd 21 #API Call
\nb4 4c #mov 4c into ah (exit)
\ncd 21 #API Call
I also wrote a program to interpret commented machine code (like above) and output a .COM file. I demo'd this as well during the talk. Even though this is assembly, I took the machine code from the assembled output and wrote this entire program using debug (in machine code), because I'm a purist...
\n![](\"https://xlogicx.micro.blog/uploads/2026/58d06dba2d.jpg\")
The REP (Repeat String Operation) is a pretty cool prefix; It modifies a single string instruction to repeat until the ECX register reaches zero. As this only applies to one instruction (as apposed to a block of code), ECX needs a way to decrement, REP automatically decrements ECX by 1 each execute of the string operation instruction. So the idea is to set ECX to the amount of times you want the string operation to execute and the run the string operation with the REP prefix. The instructions that REP is supposed to be appropriate for are: INS, MOVS, OUTS, LODS, STOS, CMPS, and SCAS.
\nNow that I described the coloring book, lets color outside the lines. What happens when we try to REP prefix an instruction not in this list. For example:
\n![](\"https://xlogicx.micro.blog/uploads/2026/6de7c3c6b9.jpg\")
And this is in a debugger after executing the last INC.
\n![](\"https://xlogicx.micro.blog/uploads/2026/de34820760.jpg\")
You'll notice that ECX didn't decrement at all, and EAX is only up to '2'; as there were only 2 INC instructions. In other words, the REP prefix was completely ignored. I like this, because gratuitous prefixes can be abused...
\nConsistent Instruction Sizes:
\nRevisiting the concept discussed in the Consistent Instruction Sizes blog post, this can be done with an ironic repetition of REP instructions that don't repeat anything (best phrase ever):
\n![](\"https://xlogicx.micro.blog/uploads/2026/efa67119ec.jpg\")
Just like the previous blog post PoC, this one launches a /bin/sh shell as well. The thing I love so much more about this one is that the 0xF3 prefix (REP) doesn't really change the original meaning of the code (unless it is one of the very few string instructions). In comparison, the 0x66 and 0x67 override prefixes will change the register sizes all over the place and has to be treated carefully. And with the REP prefix, even if it was a string instruction, all you have to do is just make sure to set ECX to 1 before the instruction and it will work like a non-REP as well. But don't just do a normal 'XOR ECX, ECX' with machine code 0x31c9, you should do the full REP version of 0xf3f3f3f3f3f3f3f3f3f3f3f3f331c9
\nRepeating a NOP to \"pause\":
\n![](\"https://xlogicx.micro.blog/uploads/2026/18a12f5f48.jpg\")
The above source file produces the below results in most debuggers/disassemblers.
\n![](\"https://xlogicx.micro.blog/uploads/2026/9fe33194ec.jpg\")
So we take a normal NOP instruction:
\n![](\"https://xlogicx.micro.blog/uploads/2026/f9e1ba7b2e.jpg\")
And put the REP prefix in front of it and get a pause:
\n![](\"https://xlogicx.micro.blog/uploads/2026/d25697daa5.jpg\")
It's really just a cool backwards compatibility hack on Intel's part. PAUSE was introduced with the Pentium 4. But if you used this instruction on an older Intel processor, what would it do. Well like we discovered with using a useless (non-string based) REP prefix, it wouldn't modify the instruction after it, in this case machine code for a NOP. In other words, machine code for a PAUSE on a pre Pentium 4 process would just be a glorified NOP.
\n", "date_published": "2016-02-13T09:00:00-04:00", "url": "https://xlogicx.micro.blog/2016/02/13/assembly-is-too-high-level.html" }, { "id": "http://xlogicx.micro.blog/2016/01/24/080000.html", "title": "Assembly is Too High Level - Redundant Bit commands", "content_html": "Compared to some of the most recent posts in this series, this one is a pretty basic example of a redundancy. This redundancy applies to the bit shifting instructions of: RCL, RCR, ROL, ROR, SAL, SAR, SHL, and SHR.
\nThese instructions can take an 8-bit immediate value, but there is also dedicated encoding for the operand to just be the value '1'. This is a very common operand for these type of instructions anyway, so it makes sense.
\n![](\"https://xlogicx.net/images/bits02.png\")
So the thing is, if we 'rcl eax, 1', there are two ways to encode this, but our assembler will only pick one of them. It sensibly picks the form where the encoding bakes in the implied '1' operand; the other form would require an extra byte of machine code (0x01) for the immediate value.
\nBelow is a screenshot of the collection:
\n![](\"https://xlogicx.micro.blog/uploads/2026/e4d1cbc15d.jpg\")
The main 8 general purpose registers are EAX, ECX, EDX, EBX, ESP, EBP, ESI, and EDI. In that order. You will see this structure in a lot of places. I will give some examples below, but it is in no way exhuastive; I just wanted to show some variety.
\nThere's the B0-B7 and B8-BF MOV instructions where the 2nd hex digit defines which register to receive an immediate value, notice that the registers are in the order described above.
\n![](\"https://xlogicx.micro.blog/uploads/2026/9ba4769413.jpg\")
Registers are also encoded like this in the ModR/M byte. If we wanted to XOR EBX with ECX, we would use the 0xCB byte
\n(click for larger view)
![](\"https://xlogicx.net/images/modrmchart01.png\")
It's the SIB encoding where we start running into some interesting exceptions to this rule. In the format of [Base + Index * Scale + Displacement]: It appears that the Index can be any of the 8 general purpose registers with exception to ESP (the one that would be missing from those), and the Base can be any general purpose register with exception to EBP.
\nBased on these exceptions, we should expect 'xor eax, [esp * 2]' to fail. This is true, there is no way to encode this into machine code and an assembler will give an error. What is interesting is that we CAN do something like this: xor eax, [ebp + eax * 2]. In this case, we are specifying EBP as the base (not allowed?) EAX as the Index with a Scale of 2, and \"no displacement.\" Let's look at the machine code that NASM chose to go with to make this work:
\n![](\"https://xlogicx.micro.blog/uploads/2026/7755de0bfc.jpg\")
Let's work backwards here. 0x00 is not the SIB (otherwise it would mean [eax + eax]), 0x45 is actually the SIB. You can refer to Chart 1, but it appears to be using the [*] item for the Base and EAX * 2 for the Index * Scale. The [*] completely depends on which one of the 4 Mods was used in the ModR/M byte. In the highlighted \"NOTES\" section of Chart 1, you'll see that [*] could either mean just a 32 bit displacement, or it could also mean EBP + a 8-bit or 32-bit displacement. Only Mod 01 and 10 allow us to use EBP.
\n(Chart 1, click to enlarge)
\n![](\"https://xlogicx.net/images/SIBchart031.png\")
This actually starts to explain why we had our 0x00 show up at the end of our machine code, it looks like we are dealing with an 8-bit displacement. Look to Chart 2 for where the ModR/M byte (0x44) falls on this. The [--][--] means we are using a SIB byte. We also see that an 8-bit displacement was selected.
\n(Chart 2, click to enlarge)
\n![](\"https://xlogicx.net/images/SIBchart032.png\")
Knowing this, we could just as well have used machine code of:
\n33 84 45 00 00 00 00
For debuggers and dissasemblers that don't show the displacement when they are a zero value, both forms of this machine code look identical. For example, in Evans Debugger:
\n![](\"https://xlogicx.net/images/scales03.png\")
I'm finding that there is a full playground in the ModR/M encoding, and this post is specifically about a SIB obscurity, only because of the way I see NASM assembling some of my assembly. Then I found other cool things NASM puts up with
\nConsider this code:
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/sibs01.png\")
Functionally, they both result in the same thing. There is even seperate machine-code to accurately represent both (kind of). But if we assemble it, we end up with this:
\n![](\"https://xlogicx.micro.blog/uploads/2026/4426d5e304.jpg\")
Even though we can hand code the machine code to get this:
\n![](\"https://xlogicx.micro.blog/uploads/2026/9439e27bd6.jpg\")
The SIB byte allows us to do complex memory/pointer syntax of [Base + Index*Scale + Displacement], where the Base is a general purpose register, Index is another general purpose register multiplied by 1, 2, 4, or 8 (the Scale), and the Displacement is an immediate value. Becuase of the exceptions found in the encoding table for the SIB byte, any one of the Base/Index/Displacement are optional. You can choose not to have an Displacement, which is actually defined in the ModR/M, not the SIB. You can not have an Index (see chart 1), because \"none\" is an option that takes over the option of ESP. You can also not have a Base (see chart 2), which is a special case that takes over the option of EBP, although this comes with a side-effect of having an offset (if none was selected with ModR/M).
\n(Chart 1, No Index, Click to enlarge):
\n![](\"https://xlogicx.net/images/SIBchart01.png\")
\n
(Chart 2, No Scale, Click to enlarge):
\n![](\"https://xlogicx.net/images/SIBchart02.png\")
That means that 'xor eax, [eax * 2]' isn't exactly a thing that exists. Because we are using the Index and no Base, we happen to be using that special case that requires an offset. So this is more accurately 'xor eax, [eax * 2 + 0x00000000]'. It carries the same meaning, since we aren't arithmetically adding anything extra. But instead of interpretting 'xor eax, [eax * 2]' like I just did, nasm does 'xor eax, [eax + eax]'. This interpretation uses eax as the Base, and eax * 1 as the Index * Scale; this doesn't require an Offset.
\nNow, if I said 'xor eax, [eax + eax * 2]', it would dutifully use my 'eax * 2' Scale.
\nSo there are at least 2 ways to represent [eax * 2]-ish. Nasm picks [eax + eax] because:
![](\"https://xlogicx.micro.blog/uploads/2026/95c1daf75a.jpg\")
(from section 3.3 of the NASM manual)
\nIs it better? It depends on how you look at it. It is better for smaller machine code, as in 'xor eax, eax' has shorter machine code than mov eax, 0 (but effectively has the same result). 'xor eax, [eax * 2 + 0x00000000]' takes more machine code. But then I bench-marked the two versions...
\n![](\"https://xlogicx.micro.blog/uploads/2026/275fcaf50d.jpg\")
Testing on a 32-bit system, the xor eax, [eax * 2 + 0x00000000] form (the one with MORE machine code) tested consistently quicker (and I took a lot of samples). On my 64-bit system, the results were inconsistent; they both took about the same time but varied in which was the quickest.
\nIt's worth noting that you don't have to do any machine code hacking to use the faster (on some systems) version of this, just make sure to include the zero offset (xor eax, [eax * 2 + 0]), or you can even use a nasm feature to over-ride this choice: 'xor eax, [nosplit eax * 2]. And if you assemble my source files and wonder why they seg-fault, you have to hack the permissions of the .text section. It's actually easier than it sounds, just use a hex editor (I like vbindiff) and change the first 0x05 you see to a 0x07.
\nAs a final word on how awesome NASM is, you can do some super ignorant memory addresses, but so long as it is somehow equivilant to something valid, NASM will make attempts. For example, a scale of 5 or even subtraction! Consider:
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/sibs04.png\")
NASM assembles it to:
\n![](\"https://xlogicx.micro.blog/uploads/2026/6bf774437c.jpg\")
![](\"https://xlogicx.micro.blog/uploads/2026/ae18b80dea.jpg\")
The LEA (Load Effective Address) instruction allows us to copy the address of a memory location (in the memory addressing format you would find in ModR/M encoding) into a register. This instruction is also often used as a multiplication math hack used in place of MUL when LEA can be used instead. With the memory (pointer) encoding of the ModR/M byte (and the SIB) bytes, we are able to add 3 different numbers (two of them registers, one of them an immediate), and one of those numbers (one of the registers) can be multiplied by 2,4, or 8. For example, we could use LEA to compute (30 * 8) + 5 + 10. It would look like this:
\n![](\"https://xlogicx.micro.blog/uploads/2026/b59f0ea2dd.jpg\")
The answer in hex is 0xff, which is 255 in decimal; the expected value.
\nThose are some 'effective' ways to use LEA, but let's explore an impossible way to do it (there will be errors). Even though the Instruction format in the manual shows 'LEA r32,m' (assuming the 32 bit version), it still shows the /r for the Opcode section. This implicitly means that we can encode for 'LEA r32, r32/m'; both operands can be encoded as a register. For this LEA instruction to work how it's supposed to, the source operand (2nd one) needs to be a memory address (not a register).
\nAs you probably can guess by the theme of any of these \"Assembly is Too High Level\" posts, we probably can't do this in assembly...
\n![](\"https://xlogicx.micro.blog/uploads/2026/77071eae3e.jpg\")
Not that it will be useful (unless you like having errors thrown in obscure ways), but we will encode the above instruction directly in machine code. Running this instruction will cause an error. The edb debugger shows the 2nd operand as invalid (astute observation) and then you get an illegal instruction fault (true).
\n![](\"https://xlogicx.micro.blog/uploads/2026/c22e11cd80.jpg\")
\n
objdump shows a more interesting output, it splits the operand byte off and interprets it as its own instruction (rolb).
\n![](\"https://xlogicx.micro.blog/uploads/2026/43c25afe1b.jpg\")
Either way you cut it, as advertised, it's not very effective.
\n", "date_published": "2016-01-11T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2016/01/11/assembly-is-too-high-level.html" }, { "id": "http://xlogicx.micro.blog/2016/01/05/assembly-is-too-highlevel-test.html", "title": "Assembly is Too High-Level - TEST r32, r-m32, exists in assembly, but not the machine", "content_html": "...And the TEST r32, r/m32 that exists in assembly is more just kind of a lie...
\nAn interesting thing about instructions that use the ModR/M encoding is that both the source and destination operands can be a register, but not both can be a memory location. When it comes to the registers, this has been the source of a lot of cool redundancies. This post is about a cool memory encoding redundancy though. As you'll note below, it usually takes two different machine encodings of the CMP instruction to use a 32-bit memory location for both the source or destination operands.
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/testmod01.png\")
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/testmod02.png\")
\n
This is what the instructions would look like in assembly:
\n![](\"https://xlogicx.micro.blog/uploads/2026/8f89ff26bf.jpg\")
This is me looking at them in a debugger:
\n![](\"https://xlogicx.micro.blog/uploads/2026/7c0bb8a4da.jpg\")
You'll see both 0x39 and 0x3b encodings in the debugger screenshot (although out of order, that's just because that's the order I wrote them in the assembly source file).
\nEverything looks consistent so far. But now let's look at test...
\nAssembly:
\n![](\"https://xlogicx.micro.blog/uploads/2026/1f5b45ff44.jpg\")
From Debugger:
\n![](\"https://xlogicx.micro.blog/uploads/2026/cffb366b41.jpg\")
\n
What? It's literally the same machine code for both instructions. Why is this? This actually isn't something stupid, but something fairly smart that Intel did. First I'll note that the Intel manual has an entry for this form of TEST:
\n![](\"https://xlogicx.micro.blog/uploads/2026/e4604283ec.jpg\")
\n
However, they do not have a corresponding entry for a 'r32, r/m32' form. But really, is there any reason we need that other form? The result of ANDing 0x55 by 0xAA is the same as ANDing 0xAA by 0x55 (the result is 0x00 for both). This is not the case with CMP, where subtraction is implicitly done, and order of operands would change the result. There are only so many one-byte opcodes to go around, and Intel saves one of them by not making an encoding for the completely redundant ModR/M encoding.
\n", "date_published": "2016-01-05T09:00:00-04:00", "url": "https://xlogicx.micro.blog/2016/01/05/assembly-is-too-highlevel-test.html" }, { "id": "http://xlogicx.micro.blog/2015/12/30/assembly-is-too-highlevel-bswapin.html", "title": "Assembly is Too High-Level - BSWAPin 16-bit Registers", "content_html": "![](\"https://xlogicx.net/images/bswap.png\")
\n\n
As it turns out, the Intel manual is correct in stating that you should use xchg instead of bswap. In practice, it's hard to say the result of this 16-bit bswap is 'undefined;' as it is consistent with what it does each time. Instead of swapping the contents of ah and al 8-bit registers within ax, it actually just clears the register to 0x00. I tried a lot of different values to test this, and it always zero's it out. I also tried fully loading up eax, and bswap'ing any value for ax just cleared the ax part, leaving the upper part of eax intact.
\nSo in practice: bswap reg16 = xor reg16, reg16 = mov reg16, 0 (were both reg16's are the same register in the xor)
\n", "date_published": "2015-12-30T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2015/12/30/assembly-is-too-highlevel-bswapin.html" }, { "id": "http://xlogicx.micro.blog/2015/12/19/assembly-is-too-highlevel-self.html", "title": "Assembly is Too High-Level - Self Modifying Code with Basic Arithmetic", "content_html": "I should say that we are able to do this trick all in assembly, but none of it would make sense without an understanding of machine code.
\nThis post is about simple self-modifying code tricks you can do with addition and subtraction to an instruction to make it another instruction, while also maintaining consistent addressing modes and operands (I.E. adding 8 to the 2nd byte of machine code of 'add bl, 5' would become 'or bl, 5').
\nThis trick is easy for many instructions that share the same first opcode byte. Below is a simple example showing INC and DEC:
\n![](\"https://xlogicx.micro.blog/uploads/2026/66dde23639.jpg\")
![](\"https://xlogicx.micro.blog/uploads/2026/85811bf88c.jpg\")
The /0 and /1 is referring to bits 3-5 of the byte following FE. So if these bits happen to be 000, then it's INC. If the bits are 001, then it's DEC. There's a more detailed breakdown of how this all works in my previous post on redundancies in the \"OP REG, imm\" instruction format. Here are the 2 similar instructions in edb:
\n![](\"https://xlogicx.micro.blog/uploads/2026/d578de19d0.jpg\")
below is the binary representation of those instructions converted from the hex to binary, with the 'instruction' 3 bits highlighted for clarity:
\n11111110 11000000
\n11111110 11001000
Let's take a look at another INC/DEC example:
\n\n
![](\"https://xlogicx.micro.blog/uploads/2026/51416a790e.jpg\")
Even though one instruction is an INC, and the other is a DEC, everything else about the assembly is the same (both to a memory pointer using rcx + the same offset). The only difference is in the 2nd byte of the machine code. You could literally add 8 to that 2nd byte, and turn an INC into a DEC with everything else being the same.
\nAll of these shared-byte instructions are like this, they are +/- away from the next one. So adding 8 to the 2nd byte of a specific type of ADD will render an OR. You add 8 more and get an ADC, again gets SBB, then AND, then SUB, then XOR, and finally CMP. This also means that adding say 32 to the 2nd byte of the SBB would result in a CMP.
\nHere is a video proof of concept of abusing this idea to xor 0x55 with 0xaa while heavily obfuscating that we are actually xoring:
\n[www.youtube.com/watch](https://www.youtube.com/watch?v=iETt65Cnobc)
If you aren't in the mood for video, here is a before and after run of the 4 instructions:
\n![](\"https://xlogicx.micro.blog/uploads/2026/85e902100e.jpg\")
![](\"https://xlogicx.micro.blog/uploads/2026/dd75c56f00.jpg\")
And here is the assembly source:
\n![](\"https://xlogicx.micro.blog/uploads/2026/616ce45ca9.jpg\")
Appendix:
\nIf you would like to know all of the instructions that you can jump around in with simple maths modifications, here they are:
\n0x80 - 1-byte operand: ADD, OR, ADC, SBB, AND, SUB, XOR, CMP
\n0x81 - 4-byte operand: ADD, OR, ADC, SBB, AND, SUB, XOR, CMP
\n0x82 - 1-byte operand: ADD, OR, ADC, SBB, AND, SUB, XOR, CMP
\n0x83 - 1-byte operand: ADD, OR, ADC, SBB, AND, SUB, XOR, CMP
\n0xC0 - 1-byte operand: ROL, ROR, RCL, RCR, SHL, SHR, SAL, SAR
\n0xC1 - 1-byte operand: ROL, ROR, RCL, RCR, SHL, SHR, SAL, SAR
\n0xD0 - 0-byte operand: ROL, ROR, RCL, RCR, SHL, SHR, SAL, SAR
\n0xD1 - 0-byte operand: ROL, ROR, RCL, RCR, SHL, SHR, SAL, SAR
\n0xD2 - 0-byte operand: ROL, ROR, RCL, RCR, SHL, SHR, SAL, SAR
\n0xD3 - 0-byte operand: ROL, ROR, RCL, RCR, SHL, SHR, SAL, SAR
\n0xF6 - 0-byte operand: *TEST, *TEST, NOT, NEG, MUL, IMUL, DIV, IDIV
\n0xF7 - 0-byte operand: **TEST, **TEST, NOT, NEG, MUL, IMUL, DIV, IDIV
\n0xFE - 0-byte operand: INC, DEC
\n0xFF - 0-byte operand: INC, DEC
*operand is actually 1-byte
\n**operand is actually 4-bytes
Adding or subtracting from the 2nd byte of the resulting machine code puts the instructions in each individual list a value of 8 from each other. So if I wanted to convert a CMP to an ADC, that's 5 instructions back * the 8. So subtracting 40 from one of those CMP instructions would effectively make it an ADC with everything else intact. The only exception is that the TEST instructions have different operand sizes then the rest in the list (they are not convertable).
\nAlso, it may go without saying, but I'm going to say it anyway: this is self-modifying code, therefore, wherever this code is running from, it needs to be rwx. Default from assemblers is r-x. Personally, I manually changed the 05 byte of the permissions area of the p_flags item of the ELF header.
\n", "date_published": "2015-12-19T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2015/12/19/assembly-is-too-highlevel-self.html" }, { "id": "http://xlogicx.micro.blog/2015/11/25/followup-on-creating-vmwdqy.html", "title": "Follow-up on creating Vm0wd2Qy - 9000", "content_html": "![](\"https://xlogicx.micro.blog/uploads/2026/fa304e7293.jpg\")
\n
This is referring to my previous post on Vm0wd2Qy, and a clarification of how I got my results. If you repeatedly Base64 encode a string, you will eventually get Vm0wd2Qy as the first part of your string. In my previous post, I have 10,000 characters that you would eventually get as the first part of your string if you keep doing this. My process for getting these 10,000 characters involved a kind of brute force, but with the obvious assistance of scripting and cli stuff.
\n\n
Lets just get Vm0 part of Vm0wd2Qy real quick, form a starting string of 'lol'. We do this by encoding 'lol', then encoding the result of that, and repeating:
\n![](\"https://xlogicx.micro.blog/uploads/2026/a43a5439e1.jpg\")
In our last result, we do see 'Vm0'; we see our magic string starting to form. But as far as brute forcing this goes, I hope you see the problem: how do we know where the magic string ends, and where all of this extra baggage starts? Let's also consider another example of making 8 base64 passes with a different starting 'seed' than 'lol'.
\n![](\"https://xlogicx.micro.blog/uploads/2026/25fdf9f6d9.jpg\")
\n
If you just look at the beginning and end of the final strings from each seed, it looks like they end up being exactly the same. But a closer looks shows that this is not so:
\n\n
Vm0xd1IyRXdOVWhTV0doWVYwZDRWVll3WkZOV2JHeHpWV3hrVm1KR2NIbFdWM1JQVmxaS1ZrNVlWbFpTYkVZelZUTmtkbEJSYnowSwo=
\nVm0xd1IyRXdNVWhTYmtwUFZtMW9WbFl3WkZOV2JHeHpWV3hrVm1KR2NIbFdWM1JQVmxaS1ZrNVlWbFpTYkVZelZUTmtkbE4zYnowSwo=
\nIt looks like they both start with \"Vm0xd1IyRXd,\" But that doesn't mean \"Vm0xd1IyRXd\" is the magic string. If only it were that easy.
\n\n
Instead of working smart though, I worked brute. The scripted idea was to run the string through many passes, with all possible 1 character seeds (64 of them), only output the first 'x' characters, and hope for 'uniq -c' on the result to only return one value. I used all seeds to hopefully avoid the above problem of having non-unique yet invalid magic string properties (no promises that this guarantees the right result, however, just a best effort).
\nHere's an example of the script I was working with:
\n![](\"https://xlogicx.micro.blog/uploads/2026/8b1d06810b.jpg\")
When run, here's a screenshot of the tail end of the output:
\n![](\"https://xlogicx.micro.blog/uploads/2026/31c335c4cd.jpg\")
the uniq command would indeed give me one entry for each line (not what I want). Here's the output I would get from uniq if I changed sprint(\"%.10000s\".... to sprintf(\"%.3s\"... (this line is the 'x' characters cutoff piece).
\n![](\"https://xlogicx.micro.blog/uploads/2026/835cffd49b.jpg\")
This is the kind of output that I'm looking for.
\nIf I want to get a large (over 9000) string, I need to set the sprintf value to truncate at the goal value of %.9000s (I went for 10000). if uniq doesn't come back with just 1 result, then I need to ramp up my $i variable (this variable defines how many base64 passes to make for each starting seed). On the flip side, if I preferred not to make any more base64 passes and just wanted to know how many non-unique characters I had for all 64 strings, I could bring the sprintf number down until uniq -c gave just one result.
\nThere is a limit to how high you can set $i though; your shell would eventually throw a fit. Actually, without 'use warnings;', you would just get the wrong result. Otherwise, you would get something like \"Can't exec \"/bin/sh\": Argument list too long at base64.pl line...\" with a value of $i being too high. Because of this limit, I wasn't able to get much higher than 10,000 non-unique characters in my string without having to do something like recompile the kernel. I forget how high I made $i, but it was one number less than what would give me an error.
\n", "date_published": "2015-11-25T09:00:00-04:00", "url": "https://xlogicx.micro.blog/2015/11/25/followup-on-creating-vmwdqy.html" }, { "id": "http://xlogicx.micro.blog/2015/11/08/assembly-is-too-high-level.html", "title": "Assembly is Too High Level - Jump Near When Short", "content_html": "This article is about a redundancy with short and near jumps. Both of the jumps I will talk about are relative; the immediate data after the jump instruction is a signed offset for how far to jump. The difference between a short and near jump is simple: the 0xeb short jump has a byte for its operand, and the 0xe9 near jump has 4 bytes for it's operand. This means that we can jump -128 through 127 bytes with a short jump and -2,147,483,648 through 2,147,483,647 bytes with a near jump.
\nFirst of all, the assembler I use (nasm) will try and guess which type of jump to use if you don't specify short or near. So if I'm jumping farther than 128 bytes, it will use a near jump for me, and if less than that, a short jump. At a low level, I find this interesting; that the same assembly instruction can have different machine code depending on how far away (in bytes) the label operand is. Of course, different machine code for consistent assembly isn't weird in general, an addressing mode can quickly change which machine code to use. I still find this behavior for the jump instruction interesting though.
\nSay we we're only jumping forward 127 bytes, but for some reason we wanted to use the near jump (0xe9) format. By default, nasm would use a short (0xeb) jump. The short jump range is still a valid range in near jumps (speaking for machine-code encoding). Fortunately, we don't need to do machine code hacks in order to over-ride this; nasm allows us to use 'short' and 'near' arguments to the jmp instruction (to over-ride the default).
\nHere is a source file. the jmp jumps to a label 128 bytes forward, which will require a near jump.
\n![](\"https://xlogicx.micro.blog/uploads/2026/b180b700dc.jpg\")
Here is a debugger screenshot of the machine-code used for the 'jmp.'
\n![](\"https://xlogicx.micro.blog/uploads/2026/90402abbd4.jpg\")
Now let's move our 'end:' label by 1-byte back (to jump 127 bytes, of which a short jump can do):
\n![](\"https://xlogicx.micro.blog/uploads/2026/0bd0a74b12.jpg\")
Here's the debugger output:
\n![](\"https://xlogicx.micro.blog/uploads/2026/f728be517e.jpg\")
So let's over-ride this short jump (we still only want to jump 127 bytes, but with the long 4-byte operand encoding of a near jump):
\n![](\"https://xlogicx.micro.blog/uploads/2026/e24d8559b7.jpg\")
And our result (in debugger):
\n![](\"https://xlogicx.micro.blog/uploads/2026/574b3c2788.jpg\")
\n
\n", "date_published": "2015-11-08T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2015/11/08/assembly-is-too-high-level.html" }, { "id": "http://xlogicx.micro.blog/2015/11/06/vmwdqy.html", "title": "Vm0wd2Qy", "content_html": "
This article will be about 2 encodings/interpretations of binary; ASCII and Base64. ASCII is an 8-bit (debatable I know, but go with it) character encoding, and Base64 is a 6-bit character encoding. Conversions can be made between them:
\n![](\"https://xlogicx.micro.blog/uploads/2026/4ded91c0c5.jpg\")
Not too interesting. This post is more about a string like \"Vm0wd2Qy\":
\n![](\"https://xlogicx.micro.blog/uploads/2026/c4314d2b89.jpg\")
[2nd command is just there to add a graceful newline] The decoded version is smaller, but that's it, this transformation was not as dramatic as the first example. How can this be?
\nConsider that it is possible for the same data to 'mean' the same thing in two different encodings at the same time.
\nLet's look at the binary encodings for ASCII and Base64. We wont do any hexidecimal or decimal conversions or any unnecessary stuff like that; we will just look at what binary produces which printable characters for both systems. I am only going to show the binary encodings of A-Za-z0-9+/ for ASCII, and for Base64 (which happens to be the full base64 character set). To be clear, there are more characters (printable and not) in the ASCII character set. For a full reference on both ASCII and Base64, the Wikipedia pages are more than enough.
\nThis table represents both systems, with the printable character in the middle, and the binary that represents the character for each base. It's not a fancy chart, but it get's the job done:
\n![](\"https://xlogicx.micro.blog/uploads/2026/36d2a548d6.jpg\")
\n
Converting is fairly straight forward, although you have to be mindful that one system is 8-bit and the other is 6-bit. Let's convert the first 4 base64 characters in the example that this post starts with.
\n![](\"https://xlogicx.micro.blog/uploads/2026/242bfdea55.jpg\")
The top (red) is the Base64, and the bottom (blue) is the ASCII. It is the same binary for each. You can look at the conversion table above to see that this binary directly corresponds to the printable characters they are supposed to.
\n\n![](\"https://xlogicx.net/images/conversions3.png\")
This kind of black magic excites me :).
\nIf you decode the (red) Base64, you get the same data, just less characters, because of the 4:3 ratio. If you take the ASCII results (still also valid Base64 characters), and treat it as Base64 and decode it, the same pattern emerges. (in this case, Vm0wd2 would decode to Vm0w). Eventually, we are reduced to nothing.
\n\nSo Vm0wd2Qy is cool, but let's look at an epic 'recursive' Base64 string of 10,000 characters. Same goes for this, you can keep doing 'base64 -d', the string doesn't change, it just shrinks. Even in 10,000 characters, there's no infinitely repeating patterns. That said, the entropy is also very low. Out of all these characters, there are 975 'V's (10%), 556 'W's, 1 'g' and no 'f's, '7's, '+'s or '/'s. There are so many other interesting patterns that emerge when playing with even the simplest of formal systems, but I feel I've already awarded myself with an informal autism diagnosis for this post, so without further delay, over 9,000 of these beautiful characters:
\nVm0wd2QyUXlVWGxWV0d4V1YwZDRWMVl3WkRSV01WbDNXa1JTVjAxV2JETlhhMUpUVmpBeFYySkVUbGhoTVVwVVZtcEJlRll5U2tWVWJHaG9UVlZ3VlZadGNFSmxSbGw1VTJ0V1ZXSkhhRzlVVmxaM1ZsWmFkR05GU214U2JHdzFWVEowVjFaWFNraGhSemxWVm14YU0xWnNXbUZrUjA1R1UyMTRVMkpIZHpGV1ZFb3dWakZhV0ZOcmFHaFNlbXhXVm0xNFlVMHhXbk5YYlVaclVqQTFSMVV5TVRSVk1rcElaSHBHVjFaRmIzZFdha1poVjBaT2NtRkhhRk5sYlhoWFZtMHhORmxWTUhoWGJrNVlZbFZhY2xWcVFURlNNVlY1VFZSU1ZrMXJjRWxhU0hCSFZqRmFSbUl6WkZkaGExcG9WakJhVDJOdFJraGhSazVzWWxob1dGWnRNSGhPUm14V1RVaG9XR0pyTlZsWmJGWmhZMnhXY1ZGVVJsTk5WbFkxVkZaU1UxWnJNWEpqUld4aFUwaENTRlpxUm1GU2JVbDZXa1prYUdFeGNHOVdha0poVkRKT2RGSnJhR2hTYXpWeldXeG9iMWRHV25STlNHaFBVbTE0VjFSVmFHOVhSMHB5VGxac1dtSkdXbWhaTW5oWFkxWkdWVkpzVGs1V2JGa3hWa1phVTFVeFduSk5XRXBxVWxkNGFGVXdhRU5UUmxweFVtMUdVMkpWYkRaWGExcHJZVWRGZUdOSE9WZGhhMHBvVmtSS1QyUkdTbkpoUjJoVFlYcFdlbGRYZUc5aU1XUkhWMjVTVGxOSGFGQlZiVEUwVmpGU1ZtRkhPVmhTTUhCNVZHeGFjMWR0U2tkWGJXaGFUVzVvV0ZreFdrZFdWa3B6VkdzMVYySkdhM2hXYTFwaFZURlZlRmR1U2s1WFJYQnhWV3hrTkdGR1ZYZGhSVTVVVW14d2VGVnRNVWRWTWtwV1lrUmFXR0V4Y0hKWlZXUkdaVWRPU0U5V1pHaGhNSEJ2Vm10U1MxUXlVa2RUYmtwb1VqSm9WRmxZY0ZkbGJHUllaVWM1YVUxWFVraFdNalZUVkd4T1NHRkdRbFppVkVVd1ZtcEdVMVp0UmtoUFZtaFRUVWhDTlZaSGVHRmpNV1IwVTJ0a1dHSlhhR0ZVVnpWdlYwWnJlRmRyWkZkV2EzQjZWa2R6TVZZeVNrZGhNMmhYWVRGd2FGWlVSbFpsUm1SMVUyczFXRkpZUW5oV1YzaHJUa2RHUjFaWVpHaFNWVFZWVlcxNGQyVkdWblJOVldSV1RXdHdWMWxyVW1GWFIwVjRZMGhLV2xaWFVrZGFWV1JQVTBVNVYxcEhhR2hOU0VKMlZtMTBVMU14VVhsVmEyUlVZbXR3YjFWcVNtOVdSbXhaWTBaa2JHSkhVbGxhVldNMVlWVXhXRlZyYUZkTmFsWlVWa2Q0VDFOSFJrZFJiRnBwVmtWVmQxWnRjRWRWTVZwMFVtdG9VRlp0YUZSVVZXaERUbFphU0dWSFJtcE5WMUl3VlRKMGExZEhTbGhoUjBaVlZucFdkbFl3V25KbFJtUnlXa1prVjJFelFqWldhMlI2VFZaWmVWTnJaR2hOTW1oWVdWUkdkMkZHV2xWU2JGcHNVbTFTTVZVeWN6RlhSa3BaVVc1b1YxWXphSEpVYTJSSFVqRmFXVnBIYUZOV1ZGWldWbGN4TkdReVZrZFdibEpPVmxkU1YxUlhkSGRXTVd4eVZXMUdXRkl3VmpSWk1HaExWMnhhV0ZWclpHRldWMUpRVlRCVk5WWXhjRWhoUjJoT1UwVktNbFp0TVRCVk1VMTRWVmhzVm1FeVVsVlpiWFIzWWpGV2NWTnRPVmRTYlhoYVdUQmFhMkpIU2toVmJHeGhWbGROTVZsV1ZYaFhSbFp5WVVaa1RtRnNXbFZXYTJRMFZERk9TRkpyWkZKaVJuQndWbXRXVm1ReFduUmpSV1JXVFZad01GVnRkRzlWUmxwMFlVWlNWVlpYYUVSVWJGcGhVMGRXU0ZKdGNFNVdNVWwzVmxSS01HRXhaRWhUYkdob1VqQmFWbFp1Y0Zka2JGbDNWMjVLYkZKdFVubFhhMXByVmpKRmVsRnFXbGRoTWxJMlZGWmFXbVZXVG5KYVIyaE9UVzFvV1ZkV1VrZGtNa1pIVjJ4V1UySkdjSE5WYlRGVFRWWlZlV042UmxoU2EzQmFWVmMxYjFZeFdYcGhTRXBWWVRKU1NGVnFSbUZYVm5CSVlVWk9WMVpHV2xkV2JHTjRUa2RSZVZaclpGZGliRXBQVm14a1UxWXhVbGhrU0dSWFRWZDRlVlpYTVVkWFJrbDNWbXBTV2sxSGFFeFdNbmhoVjBaV2NscEhSbGRXTVVwUlZsUkNWazVXV1hoalJXaG9VakpvVDFVd1ZrdE5iRnAwVFZSQ1ZrMVZNVFJXVm1oelZtMUZlVlZzVmxwaVdGSXpXV3BHVjJOV1RuUlBWbVJUWWxob1lWZFVRbUZoTWtwSVUydG9WbUpIZUdoV2JHUk9UVlpzVjFaWWFGaFNiRnA1V1ZWYWExUnRSbk5YYkZaWFlUSlJNRlpFUms5VFJrcHlXa1pLYVZKdVFuZFdiWFJYVm0xUmVGZHVVbXBTVjFKWFZGWmFkMDFHVm5Sa1J6bFdVbXh3TUZsVldsTldWbHBZWVVWU1ZXSkdjR2hWTUdSWFUwWktkR05GTlZkTlZXd3pWbXhTUzAxSFJYaGFSV2hVWWtkb2IxVnFRbUZXYkZwMVkwWmthMkpHYkROV01qVkxZa1pLZEZWdWJGaGhNWEJ5Vm1wS1JtVnNSbkZYYkdSb1RXeEpNbFpHV21GWGJWWlhWRzVLWVZJeWFFOVVWekZ2VjFaa1YxVnJaR3ROYTFwSVZqSjRWMVV5U2tkalNFNVdZbFJHVkZSV1dsWmxWMDQyVW14b1UyRXpRbUZXVm1NeFlqRlplRmRZY0doVFJYQldXVlJLVTFOR1ZuRlNiVVpZVm01Q1NWbFZXazlXTVZwSFYyeGtWMkpIVGpSVWEyUlNaVlphY2xwR1pHbGlSWEJRVm0xNGExVXhXWGhWYkdoclUwZFNXRlJXWkRSbFZscFlUVlZrV0ZKcmJETldiWEJUVjJzeFNHRkZlRmROYm1ob1ZqQmFWMk5zY0VoU2JHUlhUVlZ3VWxac1VrTldhelZYVjFob2FsSlhhRzlWYWtwdlZERlZkMVpyZEU1aVJuQXdWRlpTUTFack1WWk5WRkpYVm0xb2VsWnRNVVpsVmxaelZteHdhVmRHU1hwWFYzQkhWakpPVjFSdVVsQldiVkpVV1d4b2IxbFdaRlZSYlVab1RXdHdTVlV5ZEc5V2JVcElaVWRvVjJKSFVrOVVWbHB6VmpGYVdXRkdhRk5pUm5BMVYxWldZV0V4VW5SU2JrNVlZa1phV0ZsVVNsSk5SbHBGVW1zNVZGSnJjSGxYYTFwTFlWWktkVkZ1WkZkaVdGSllWbTB4VW1WR1pIVlZiWEJUVmpGS1dGWkdXbUZrTURGSFZtNVNhMUo2YkZkVmJYaDNUVVpzVmxkc1RsZFdiSEJaV1ZWV1UxWlhTa2RqUjJoV1RVZFNXRlV3V2t0a1IwNUdUbFprVGxaWGQzcFdiWGhUVXpBeFNGSllhR0ZTVjJoVldXdGtiMkl4Vm5GUmJVWlhZa1p3TVZrd1dtdGhNa3BIWWtST1YwMXFWa3haYTFwTFpFWldkV0pHYUdoTldFSjVWbTF3UzFKdFZuTlNia1pZWWtkU2IxUlhlRXBOYkZwSFYyMUdXR0pXV2xoV1J6VkxXVlpKZVdGRk9WVldla1oyVmpGYWExWXhWbkphUjNST1lURndTVlpxU2pSV01WVjVVMnRrYWxORk5WZFpiRkpIVmtaU1YxZHNXbXhXTURReVZXMTRiMVV5UlhwUmJVWlhWbTFOZUZscVJscGxSbVJaWTBkb1ZGSllRbGRYVmxKTFZURk9SMVp1UmxOaVZWcFpWbTAxUTFOV2JGWlhhemxYVFZad1NGWXllR3RXTWtwSVZHcFNWV0V5VWxOYVZscGhZMnh3UjFwSGJHbFNXRUpSVm0weE5HRXhWWGhYV0doV1lrZG9jbFV3WkZOWFJsSlhXa1JTYkZac2NGbFVWbFpyVjBaS2NtSkVUbGRpV0VKVVZqSnplRk5IUmtabFJtUk9ZbTFvYjFacVFtRldNazV6WTBWb1UySkhVbGhVVmxaM1ZXeGFjMVZyVGxkaGVsWllWakZvYjJGc1NsaGhSemxXWVd0d2RsWkVSbFprTVZweVpFVTFhVkp1UVhkV1JscFRVVEZhY2sxV1drNVdSa3BZVm0weGIyVnNXblJOVlZwc1ZteGFlbFp0ZUhkaFZtUkhVMWh3V0ZZelFraFdha3BQVmpGU2RWVnNRbGRpVmtwVlYxZDRiMkl4YkZkYVJsWlNZbFZhYjFSWGRIZFRWbFY1WkVjNVYySlZjRWxhVldSdlZqSktTRlZyT1ZWV2JIQjZWbXBHWVZkWFJrZGhSazVwVW01Qk1WWXhXbGRaVjBWNFZXNVNVMkpyTlZsWmExcGhWMFpzVlZOc1NrNVNiSEJHVlcxek5WWkdTbkpqU0d4WVlURndURmxXV2t0a1ZrWjFXa1prYVZkR1NsbFdiVEI0VlcxV1IxcElWbFppV0VKVVZtcEdTMWRHV2tkWGJVWnJUVVJHU0ZadE5WTmhNVW8yWWtaa1ZtSllhRE5VVlZwelZteGtjMVJzWkZkaVNFSmFWMVpXVjFVeFdsaFRhMlJxVWpKb1YxUlZaRk5YUmxWM1YydDBhMUl3TlVkVWJGcHJWR3hhV0dRemNGZGlXR2hVVlhwQmVGTkdTbGxoUjBaVFZqSm9WbGRYZEd0aU1rbDRWbTVHVW1KVldsaFphMXAzVFZacmQxZHRkR2hOYTNCSVdXdFNUMVl3TVhGV2EzaGFZVEZ3VEZwRldsZGtWMHBIWVVkb1RsZEZTalZXYlRGM1V6RktkRlp1VGxOaWExcFpXV3RrVTJJeFVsaGxSWEJPWWtad1NGWXlNVWRYUjBwWFYyeG9WMUo2Vmt4WFZscEtaVmRHUms5V1ZsZGxhMW95Vm1wR1lXRXhXWGhXYmtwaFVqTlNUMWxVUm5kVFZscHhVMnBTVjAxV1ZqVlZNblJyWVd4T1JrNVdaRnBpUmtwSVZtdGFVMVl4WkhOWGJYaFhUVVJSZVZaWE1UUmlNVlY1VWxod1VtSlZXbGhXYlRGT1pVWnNjVkpzY0d4U2JWSmFXVEJrYjFaR1NsbFJiR1JZVm14S1RGWlVSazlTTVZwMVVteE9hVlpXY0ZwV2JUQXhVVEZPVjJKR1dsaGhlbXhZVkZaYWQxTkdXWGxsUjNSWFRXdHdTVlpIY0ZOV1YwVjVWV3hPWVZac2NHaFpNbmgzVWpGd1NHSkhiRk5YUlVwU1ZtMHdlRTVIUlhoV1dHaFlWMGRvVjFsclpHOWpiRlYzV2taT1dGSnNTbGhYYTFKVFlrWmFjMk5HYkZWV2JGcHlWakJhUzJOdFNrVlViR1JwVjBWS1ZWWnFTbnBsUms1SVVtdGFiRkp0VWs5WmJURnZZakZhY1ZGdFJsZE5helY2V1RCV2IxVXlTa2hWYkdoVlZteGFNMVpYZUdGak1WWnlWR3hrYUdWc1dsbFdha1p2WWpKR2MxTnNhR2hTZW14WFdWZDBkMlJzV2tWU2JGcHJUVlp3ZVZwRlZURmhWa3AxVVZoa1YxSnNjRlJWVkVaaFkyc3hWMWRyTlZkU2EzQlpWbTB3ZUdJeVZuTlhibEpPVmxad2MxWnRlR0ZsYkZwMFpVaGthRlp0VWtoVk1XaDNWMFpaZWxGcmFGZGhhM0JRVm1wR1UyUldWbk5SYkdScFZtdHdWbFl4WkRSaU1rbDRZa1prWVZKc1dsTlpiRlpoWWpGU1dHUklaRlJXYkZZMVdrVmpOVll5U2xaalJXeGhWbGRTZGxacVNrdFRSbFp5VDFaV1YySklRalpXYlhCSFdWWmtXRkpyWkdoU2F6VndWVzAxUWsxV1dYaFhiR1JhVmpCV05GWlhOVk5WTWtweVRsWnNXbUV4Y0doV01GcHpWbFpPYzFOck5WTmlTRUpIVmxjeGVrNVdXa2RUYmtwcVUwZDRXVmxVUm5kVVJteFhWMnQwYTFacldqRlhhMXByWVZaa1IxTnNiRmRpVkVJMFZsY3hWMUl4Y0VsV2JGcHBWMFZLVlZadGNFZFRNV1JIVjJ0a1dHSlZXbkpVVlZKSFUwWmFkRTVXVG1oTlZXOHlXV3RhYTFadFNsbGhSRTVWVmxad2VsWnRlR3RqTVZKeldrWmthVk5GU21GV01WcFhWakZWZUZkc2FGUmhNbEp4VldwS2IxWXhVbFphUms1WVVteFdNMVl5ZERCaE1VbDNUbFZrVldKR2NISldSM2hoVjBkUmVtTkdaR2xYUjJoVlZsaHdRbVZHVGtkVGJHeG9VakJhVkZacVNtOVdiR1JZWkVkMGFVMXJiRFJXYlRWSFZXMUtWbGRzYUZwaE1YQXpWRlphY21ReFpIUmtSMmhPWVROQ1NWZFhkRk5VTVZsM1RWaEdWMkV6YUdGWlZFWjNWRVp3Umxkc1pHdFdNSEJJV1ZWa2IxUnNaRVpUYWxaWFlsUkdNMVY2Umt0a1JscDFWR3hPYVdFeGNGcFhWM1JyVlRKSmVGVnNhR3hTV0VKUFdXdGFkMU5HV1hsTlZXUllVakJ3V0ZZeWVHOVdNVW8yVm10NFdGWnNjRXRhVm1SSFVtczVWMVpzWkd4aE1XOTVWbTF3UjFsWFJYaFhXR2hYWW10d2FGVnFUbE5VTVd4VlVtNWtWRlpzY0hoVk1uQlRWakF4VjFacVZsWk5ibEp5V1ZkNFQxSnJOVmRhUm5CcFVtdHdTVlp0ZEdGVk1WbDRXa2hPV0dKWWFGaFVWVkpTWlZaYVdFMVVVbWxOVmxZMVZXeG9kMVZ0U2xaWGJHaFhZbFJHVDFwVlduTmpWa3B6WTBkNFUySldTbUZYVkVKcllqRmFSMU5zYkZKaVIxSlpWbTE0UzFSR1dsVlNhemxUVFZad01WVnRlRTloVmxwWFkwWndWMkpVUVhoVlZFWlBWakpLUjFkc2FHaGxiWGhaVmtaYVlXUXhUa2RYV0d4c1VqTlNXRlJYZEhkVFZscElZMFpPVjFZd1ZqVldWM2hQV1ZaYWMyTkhhRnBOYm1nelZXcEdkMU5IU2toaVJrNVlVbFZ3VTFadE1IZGxSVFZJVWxob1YxZEhhRmxXTUdSdlZqRnNjbHBIT1dwaVJsWXpWMnRhVDFkR1NuTlRiR2hZWVRGS1ZGbHJXbUZqTWs1SFlrWldWMkpHY0hsV2FrSmhVekpPZEZOclZsVmlSMUp3VmpCV1MxWldXbkZUYm5Cc1VtczFTVlZ0ZEdGaVJrcDBWV3M1V21KVVJuWlpha1poWTFaR2RGSnNaRTVoZWxZMlYxUkNWMkl4VlhsVGEyaFdZa2RvVmxadGVHRk5NVnBZWlVkR2FrMVdXbmxXUjNocllVZFdjMWRzYkZkaGExcDJXV3BLUjJNeFRuTmhSMmhUWlcxNFdGZFdaREJrTWxKelYydFdVMkpHY0hKVVZscDNaVlp3UmxaVVJtaFdhM0F4VlZab2ExWXhTbk5qUmxKV1ZrVmFhRmt5YzNoV01XUnlUbFprVTJFelFscFdiVEIzWlVkSmVWWnVUbGhpYkVwUFZteGFkMk14V25SbFIwWnNZa1p3TUZwVmFHdGhSbHAwVld0b1ZrMVhhRE5XTUZwYVpXeEdjbUZHWkdoaE0wSlJWbTF3UjFVeVVsZFdiazVTWWtkU2NGWnRkSGRXYkZsNFdrUlNhVTFyYkRSWmExcHJXVlpLYzFkc1RscGlSbHBvV1dwR1UxZEhVa2xhUmxKWFlrWlpNVmRyVm1wT1ZsbDVVMnhhYWxKWGVHaFdiR1JUWkd4YWNWTnJkRlJTYkZwNVZERmFWMVl5U2tsUmFscFhZbGhDU0ZkV1dtdFhSa3B5V2tkb1UyRjZWbmRXVnpBeFVXc3hWMWRZYUZoaVIxSmhWbXBDVjA1R1dsaE9WazVXVFd0d2VWUnNXbk5YYlVWNFkwZG9WMDFHY0hwV2JGcFBZekZPY2s1V1RtbFRSVXBJVm14amVHVnJOVmRYYTJSVVltdHdjVlV3WkRSWFZteFZVbTVrVlZKdGVGaFdNblF3WVRGYWNsZHFSbGhoTVhCeVdWWmFhMUl4VG5OaVJtUnBWa1ZKTUZac1kzaFdNVWw0WTBWc1YySkdjSEJXTUZaTFZsWmFkR05GWkZSTlYxSklWakowYTFkSFNsWlhia3BWVmxaS1NGVXdXbUZrUlRWWFZHMW9UbFpYT0hsWFYzUmhZVEZhZEZOc2JHaFNSVFZXVm14YWQyVnNXblJsUjNScVRWWktlbGRyV210aFZrNUdVMjFHVjAxV2NGaFdha1pXWlVaa2MyRkdVbWhOYkVwNFZsZHdTMkl4V1hoVmJGcGhVbXMxV1ZWdGVGZE5NVmw1WkVSQ2FFMVZiRE5VYkZaclZsZEtSMk5JU2xkU00yaG9WakJrVW1WdFRrZGFSMnhZVWpKb1ZsWnNhSGRSYlZaSFZHdGtWR0pIZUc5VmFrSmhWa1phY1ZOdE9WZGlSMUpaV2tWa01HRlZNWEppUkZKWFlsUldTRlpYTVV0V2JHUnpZVVp3YUUxWVFYcFdSbHBoWTIxUmVGcElVbXRTTW1oUFdWUk9RMU5XWkZoa1JrNVZUVlpzTTFSV2FFZFdNa1Y2WVVkR1dsWkZXak5XUlZwM1VteGtjMXBIZEZkTlNFSkpWMVpXYTJJeFVuTmFSVnBVWVd4YVdGbHNVa2ROTVZZMlVtdDBhMUpzY0RGV1IzaFBZVmRGZUdOR2NGaFdNMUp5VmxSS1NtVkdWbk5oUjNoVFYwVktVRmRYZEdGa01VNUhWMWhzVGxaWFVsbFZha0ozVjBaWmVXVkhPVmROVlc4eVZtMTBORmRHV25OalJYUmhWbTFTU0ZWdGN6VldNVnB6V2tkNGFFMVhPVFZXYlRGM1VqRnNXRkpZYUZoWFIyaFlXVzEwZDJGR1ZuRlViRTVWVFZkNFZsVnROV3RXUmxwelkwaG9WazF1UWxSV2FrRjRWakZhY1Zac1drNWliRXA1VjFaa05GUXhTbkpPVm1SaFVtNUNjRlZ0ZEhkVFZscDBaRWRHVmsxV2JEUlhhMmhQVjBkS1dXRkdhRlZXVmtwVFdsWmFZVmRGTVZWVmJXeE9WbXhaTVZaWGVHOWtNVlowVTJ4YVdHSkhhRmhaYkZKSFZERndWbGR1VG1wV2EzQjZXVEJrTkZVeVNsZFRiVVpZVmtWS2NsbHFSbUZTTVU1ellrWkthVkl4U2xwV2JURTBVekZTUjFkc1ZsTmhlbXhVVkZaYWQwMVdWblJsUlRsb1ZteHdXRmt3V25kV01rcFZVVmhvVmxaRldsQldha3BMVWpGa2MyRkhhR3hpV0doYVZtdGFZVmxYVVhoVWEyUllWMGQ0YzFWcVRsTlhSbEpZWkVoa1ZGWnNjRWxaTUZwUFZqRlpkMVpxVmxkV00yaFFWMVphWVdNeVRraGhSbkJPWW0xbmVsWlhjRWRrTVU1SVUydG9hVkpyTlZsVmJGWjNWVEZhZEUxSVpHeFNWRlpKVld4b2IxWXhaRWhoUm14WFRVZFNkbFpxUm5OamJIQklUMWR3YVZKc1dYcFdNblJoVkRGa1IxTnVUbFJpUjJoWldWUkdTMVpHYkhKWGJVWnFUV3MxU0ZscldsZFdNa3BIWTBoc1YyRnJTbWhWZWtwUFpFWk9jbFpzVm1sU01VcDNWbXBDVjFNeFdsZFhia1pVWW01Q2MxVnRjekZUVmxaMFpFZEdhVkpyY0RCV1YzTTFWMjFLVlZKdVdscGhhMXBvV1RGYVIyUkdTbk5h
\n\n", "date_published": "2015-11-06T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2015/11/06/vmwdqy.html" }, { "id": "http://xlogicx.micro.blog/2015/11/05/assembly-is-too-high-level.html", "title": "Assembly is Too High Level - Subtracting by Comparing - Propeller", "content_html": "
If you're familiar with x86, you'd know that a CMP (compare) instruction is the same as a SUB (subtract) instruction, with exception to the destination operand being written to. In other words, CMP is like a subtract, it just doesn't write the value when done (but it does set all of the flags that a subtract would. so CMP is used preceding conditional jmps; as conditional jumps base their conditions on the flags. Although this post will focus on CMP and SUB, the same tricks apply to TEST and AND (this goes for both x86 and Propeller). The main difference with x86 and Propeller in this respect is that x86 has completely different machine-code for these instructions. Not the case for Propeller.
\nIn my previous blog entry on Propeller NOPs, I went into some detail on the instruction format of the Propeller micro-controller. The main parts that are important for this entry are the 6-bit op-code part, and the ZCRI flag section (mostly just the R part of it).
\nLet's compare the CMP and SUB instructions
\nCMP:
\n![](\"https://xlogicx.micro.blog/uploads/2026/27a100fa59.jpg\")
SUB:
\n![](\"https://xlogicx.micro.blog/uploads/2026/d9bd6bfceb.jpg\")
So the op-code (100001) part is the same for both. Really, the only actual difference in the binary that makes up these two instructions is the R field. The R field specifies whether the value/pointer in the -DEST- field will get modified. However, we can override this default behavior within the Propeller assembly language with nr/wr (don't write/do write, respectively). This means we can over-ride a CMP into being a SUB and a SUB into becoming a neutered CMP. So obviously we will do that:
\n![](\"https://xlogicx.micro.blog/uploads/2026/e71710de96.jpg\")
And to see the Machine Code:
\n![](\"https://xlogicx.micro.blog/uploads/2026/d175e773fa.jpg\")
Our encoded instruction is 0x0204FC84. You will see that value repeat twice in a row, because the 'sub' and 'cmp' instructions seen in the assembly are identical in machine code. If you are skeptical that the cmp actually subtracts (because you all are), let's debug (with my favorite debugger/emulator: GEAR):
\n![](\"https://xlogicx.micro.blog/uploads/2026/d16367e207.jpg\")
It is shown as 2 SUBs. The last byte of the 3rd line is our 1-byte \"AVariable\" (Propeller is far from Harvard architecture). So if we subtract 2 from $55, we should have $53:
\n![](\"https://xlogicx.micro.blog/uploads/2026/97ce5de4ce.jpg\")
And we run the 2nd SUB (the assembly CMP) and we get our expected $51 from subtracting 2 again:
\n![](\"https://xlogicx.micro.blog/uploads/2026/0f7aa53242.jpg\")
![](\"https://xlogicx.micro.blog/uploads/2026/2d8861bc92.jpg\")
Oh boy, I love seeing words like these! Even though this post will focus on the AAD instruction, this applies to the below two instructions:
\n![](\"https://xlogicx.micro.blog/uploads/2026/2d5562f74a.jpg\")
![](\"https://xlogicx.micro.blog/uploads/2026/90cf341a79.jpg\")
I particularly love this one; because we get to see an illustration of abstractions being misleading on a few levels (assembly being too abstract, and even a mathematical formula being used too abstractly). I'm about to get all kinds of philosophical up in here!
\nWhen approaching a tool or a system, normal people only look at what it is supposed to do; what it is intended for (and that's even assuming too much for a normal person sometimes). As a hacker, we aspire to look at a system for what it actually does. Sometimes we have to hack around just to discover this. But sometimes it isn't even hidden; it can be well documented. Even so, normal people only care about the useful abstractions, and still ignore what systems actually do.
\nAssembly Abstraction: AAD = ASCII Adjust AX Before Division
\nThis instruction is intended to take two 8-bit BCD values and convert them to one 8-bit 'binary' value. For those that don't know, BCD stands for Binary Coded Decimal. It's a way of representing (only) decimal values in a binary/hex encoding. To represent the decimal number of 79 in hex, it would look like 0x4f (just 1 byte). In BCD, it could look like 0x79. In BCD, we ignore the A-F values of hex, even though we are still using standard 4-bit nibbles and 8-bit bytes. This means we are wasting data space. Even worse, AAD takes an 8-bit value for each digit, so 79 would actually be 0x0709.
For AAD, the first byte (07 in this case) is in AH, and the next byte is in AL (09). After using the AAD instruction, the result is put into AL. The instruction mentions AX because AX is AH:AL (Accumulator High, Accumulator Low). So if AH had 0x07, and AL had 0x09, and we then ran AAD, AL would then have 0x4f (decimal 79). That's what this instruction is supposed to do.
\nLet's look at the machine code for AAD (right next to the assembly that created it):
\n![\"\"](\"https://xlogicx.micro.blog/uploads/2026/screen-shot-2015-10-20-at-5.29.55-pm.png\")
\nD5 is the actual machine-code for AAD. 0A is put there by our assembler for us, it is used for base 10 (notice we didn't say 'aad 10' in our source file). We can't change this value in assembly. As the Intel Manual states, this can only be done in machine code. Let's do a base 2 conversion. AH will be 01, and so will AL. So if AX is 0x0101, AAD (2) should yield 0x03 in AL. This is because 11 in binary is 3 in decimal.
![](\"https://xlogicx.micro.blog/uploads/2026/afb7d22522.jpg\")
As you can see, AL (seen in EAX register) has the value that we expected.
\n![](\"https://xlogicx.micro.blog/uploads/2026/e73f79e80c.jpg\")
So by unlocking this 'base' byte, we can convert from arbitrary bases, as Intel states. But we are not at the bottom of this abstraction stack yet. Converting from any base is what it is supposed to be used for at this level...again, what does it actually do.
\nMathematical Abstraction:
\n![](\"https://xlogicx.micro.blog/uploads/2026/51bfa128f5.jpg\")
So really: AL = AL + (AH * base)
\nWhere you provide the 1 byte base.
This formula absolutely does what it is supposed to do. So we are done, we slap the \"dutifully converts from base\" label on this formula and that is what it is. Abstractions make life so easy on our stupid brains. But converting bases isn't really what it does. It can do that, but what it really does is AL = AL + (AH * base). Just so you don't think I'm splitting hairs like usual. Consider that the 1 byte base value can be any value from 0x00-0xff. So what does it mean to convert 0x0709 from base 1, or base 0 (just so you know: not a thing)? Even base 2 doesn't make sense here, because 7 and 9 are not valid binary characters. This doesn't mean we still can't AL = 9 (7 * 2) and get a value anyway (0x17).
\n![](\"https://xlogicx.micro.blog/uploads/2026/6ea2451b4c.jpg\")
This post is not about x86/64, as the title goes, this is about the Propeller architecture.
\nBut first, here's some x86 (hahaha):
\n![\"xchg\"](\"http://xlogicx.net/wp-content/uploads/2015/09/Screen-Shot-2015-09-27-at-5.42.39-PM.png\")
\nNote that if you encode the XCHG instruction with EAX, EAX, it would just be 0x90; the exact same machine code as:
![](\"https://xlogicx.micro.blog/uploads/2026/79e5c88c51.jpg\")
Sorry to have to put everyone though so much x86 for a Propeller post, but I think there's a very strong likeness here; the propeller chip also does not have dedicated machine-code for the NOP. I find a propeller NOP to be much more interesting.
\n\n
Unlike x86, machine instructions for Propeller are not variable in size; each instruction occupies 32-bits. There are 6 bits that specify which instruction (up to 64 possible different instructions), 2 flag setting bits (Zero and Carry), a bit that specifies if the destination operand gets written to, a bit specifying immediate or memory location mode, 4 bits for flag tests, 9 bits for the destination, and another 9 bits for the source operand. This totals up to 32-bits. EVERY instruction has this structure. It may be complicated at first to divide up these bits, but once you get past that, this architecture is incredibly simple and elegant.
\nBelow is a table that describes the WRBYTE instruction. I picked this one because it is the first binary instruction (000000):
\n![](\"https://xlogicx.micro.blog/uploads/2026/15f25ca53d.jpg\")
Although, for fun, We can look at the last binary instruction (WaitVid):
\n![](\"https://xlogicx.micro.blog/uploads/2026/7a8a44f32d.jpg\")
\n
\n
4 bits isn't that much, let's spell out each of them. Where:
\nZ is Zero Flag
\nC is Carry Flag
\n* is AND
\n! is NOT
\n= is Equal
0001: !C*!Z
\n0010: !C*Z
\n0011: !C
\n0100: C*!Z
\n0101: !Z
\n0110: C!=Z
\n0111: !Cv!Z
\n1000: C*Z
\n1001: C=Z
\n1010: Z
\n1011: !CvZ
\n1100: C
\n1101: Cv!Z
\n1110: CvZ
I skipped 2 special values. 1111 means IF_ALWAYS, most instructions default to this condition if not specified (you will see this above in the tables for WRBYTE and WaitVid. That leaves 0000: IF_NEVER. In Assembly, you can literally put IF_NEVER in front of any instruction you feel like, and it effectively makes it a NOP! In machine code you would just 0 out those 4 bits.
\nAlthough, if you actually write 'NOP' in assembly, it has to pick one of these variations. If you were to assemble a NOP and the disassemble it, it would look like a carefully crafted WRBYTE instruction.
\nLet's look at some propeller Assembly code with a NOP, a couple WRBYTEs and a corresponding machine-code dump. I drew arrows from the assembly to the corresponding machine-code for clarity.
\n![](\"https://xlogicx.micro.blog/uploads/2026/aba1035bff.jpg\")
Note that the memory model is Little-Endian (data goes backward per byte). Let's break apart the 2nd wrbyte instruction into its pecies, as it's the main non-zero instruction in the dump. I will take the hex and separate it out into the INSTR, ZCRI, CON, DEST, and SRC bit fields.
\nHex 0x03063C00 = Convert from Little Endian -> 0x003C0603 = binary 0000 0000 0011 1100 0000 0110 0000 0011
\nClearer grouping = 000000 0000 1111 000000011 000000011
\n000000 = WRBYTE
\n0000 = Don't set Zero or Carry flags, R = 0 means Write in the context of this instruction, R = 1 would be Read, I = 0 means non-immediate value (pointer)
\n1111 = Same as saying if_always
\n000000011/000000011 = This refers to the 3rd (counting from zero) 32 bit value in memory (including instructions!). Looking at the assembly, nop is the 0th, 'wrbyte variable, variable' is 1st, 'wrbyte start, start' is 2nd, and our variable declaration is the 3rd. So that's how this happens. Propeller interestingly does not have a distinct code/data isolation.
\n\n
We see that assembling a NOP produces 0x00000000 in machine code. Let's see what it would take to write some assembly that would produce this same value without using an actual NOP in assembly (spoiler in the above image). I will first break down our zeros into their fields:
\n000000 = WRByte
\n0000 = Don't write flags, already Write mode with 0 bit, and we have to use pointer mode; not immediate
\n0000 = we can only get this set of 0's by specifying the if_never prefix
\n000000000/000000000 = This is the tricky part (kind of). This has to refer to the 0th 32-bit memory value (our first instruction). Turns out that our Start label contains just that (just as it likewise would in x86 assembly). This means that we can use our 'Start' label for the Dest and the Source operands. We end up with 'if_never wrbyte Start, Start.' As seen in the machine dump, this did infact produce our all 0's machine code identical the real NOP.
\nSo many flavors of NOP:
\nIf you set the CON field to 0000 on any instruction (either directly in machine code or by using the if_never), you effectively make it a NOP. A NOP takes 4 clock ticks. Instructions that take otherwise significantly more clock ticks should only take the 4 clock ticks if you shove an if_never into the CON field.
\nPost Disclaimer: None of this is really useful knowledge, it's just fun to hack for hacking's sake.
\n", "date_published": "2015-09-27T08:00:00-04:00", "url": "https://xlogicx.micro.blog/2015/09/27/assembly-is-too-high-level.html" }, { "id": "http://xlogicx.micro.blog/2015/09/19/obscure-fisting.html", "title": "Obscure FISTing", "content_html": "![](\"https://xlogicx.micro.blog/uploads/2026/e5ab1f7525.jpg\")
In the realms of assembly obfuscations, this isn't extremely high in complexity. This is me finding an excuse to use the \"FIST\" instruction. In the context of the PoC, it is being used as a decoder for some encoded shellcode. Before going into the super technical details, below is a video of the PoC in action.
\n[www.youtube.com/watch](https://www.youtube.com/watch?v=e-14WFLCl-M)
\n\nLet's talk about floating point numbers (as it applies to x86). I've said this a ton, but data is meaningless without context. For example 0xfe could be 254 decimal, but if it were a signed integer, it would be -2. The sign is defined by the most significant (left-most) bit, when interpreted as a signed int. Floating point representation has it's own complex structure. In a more standard notation, it's what gives us the ability to represent numbers like 13 * 10^4. However, everything is still represented base 2, so it's more like 1.9837 * 2^16. With this type of notation, we can represent very large and very small numbers (with a loss of precision). In a 32-bit floating point number, we have 1 bit for the sign (and these are not 2's compliment), 8 bits for the multiplier (called the bias), it can represent positive and negative (fractional), and the remaining 23 bits represent the number before modification (multiplying out). If only it were that simple though, this 23 bit number has an implied leading 1. So 1.265 would be stored as 265 and the 1 is assumed. These 23 bits also represent fractional binary.
\n\nLet's talk about fractional binary. We know that each increasing bit represents twice as much as the bit before it. Well after the decimal place, each bit represents half as much. Lets look at a non-fraction to illustrate the first point: 1011. The right most digit represents 1, the next 2, then 4, then 8. We have 1, 2, and 8 'selected', so it's 11 decimal. What is 1011.1011. Starting from left to right after the decimal, we have 1*.50 + 0*.25 + 1*.125 + 1*.0625. The fractional part is .6875, so the entire number would be 11.6875 as a decimal number.
\n\nThe 8-bit bias part of our data rests on 0x7f. larger than 0x7f is a larger exponent, smaller than 0x7f is a fractional exponent.
\n\nLet's encode 11.6875 (decimal) into a floating point number. First we must convert it to binary, of which we already had above; it's 1011.1011. Now we have to push it back a few decimal places to get it to be a 1.xxxx... format: 1.0111011. We had to push this 3 places, so our exponent will be 3. We add this 3 to 0x7f getting us 0x82 for the bias bits. The sign bit will be 0 for positive. As far as representing our binary in 23 bits, we are supposed to remove the leading 1 and pad with 0's until it's 23 bits. It helps me to look at the full 32-bit value in binary before making it hex. In order, we have sign bit (0), the bias (1000 0010 / 0x82), and the number (0111 011 0000000000000000). We combine all of that to get: 01000001001110110000000000000000. In hex this is 0x413b0000. So if 0x413b00000 is interpreted as floating point data, it represents 11.6875.
\n\nThe FPU is a set of 8 additional registers (ST0-ST7). These registers are actually 80-bit each. The FPU is mostly interfaced like a stack; in the sense that we usually push data to it and pop data from it. To push data to the FPU stack, we can use the FLD instruction (floating point load) to take data from a location in memory and place it into ST0. You can then use FST (floating point store) to take the first FPU register (ST0) off of the stack and place it into memory. Both of these instructions assume the data is already encoded as floating point.
\n\nOne cool thing is that you can have your integer data converted into floating point with the FILD instruction (I for integer). This takes an integer from memory, encodes it as floating point, and pushes it to the FPU stack. Likewise, you can take floating point data from the FPU and convert it back to an integer with FIST (again, I for integer). For practical reasons I use FISTP (P for pop). Interestingly, by default FST/FIST accesses the data on the top of the FPU stack without actually removing it (popping). So if you keep pushing with FLD/FILD and not popping, you'll run into problems.
\n\nThe idea is to have a bunch of shellcode encoded into memory as floating point data, only to have FIST decode it back into memory and then execute. It is unreasonable expect to be able to convert every 32-bit instruction into something that equates as a 32-big floating point number. It is far easier (for me) to just use the least significant 2 bytes of the integer from a float as the machine code. This means I need to take some shellcode and break it up into 2-byte chunks. Each chunk needs to be encoded as floating point data. I did this manually...There were some steps in between, but for posterity, here's the scratchpad text file I was working around in:
\n![](\"https://xlogicx.micro.blog/uploads/2026/aaaac27172.jpg\")
The idea is to manually convert 2 bytes into a 4-byte float that will be decoded by FIST where the least significant 2 bytes will be the original 2 bytes we were encoding. Let's look at 'Int 0x80' (this was the last line in my sloppy work screenshotted above). In machine code that is 0xcd80. Because of some Little Endian side effects, we will need to pre-reverse the bytes, so 0x80cd. In binary this is 1000 0000 1100 1101, We then shift this to 1.000 0000 1100 1101. That is 15 shifts, where 1.000 0000 1100 1101 * 2 ^ 15 would get us back to our 0x80cd. So let's encode. It's positive, so the sign big is 0. It's bias is 15, and we add that to the 0x7f, so that's 0x8e (1000 1110). And for the number, we ignore the leading 1 and pad with 0's to the right to get 23 bits, so 00000001100110100000000. All that binary together is 0100 0111 0000 0000 1100 1101 0000 0000 or 0x4700cd00 represented in hex. So if 0x4700cd00 was in ST0, FIST/FISTp would put 0xcd800000 into our memory location. I only end up using those first 2 bytes in my PoC.
\n\nFirst note that this PoC has been modified where .text is rwx (can be modified on the fly), this was done manually in a hex editor (of which is also demonstrated in the video). It already has the encoded shellcode in memory with assembly dq directives and a handy pointer to it with 'data:'. I initialize a looping counter with ECX, specify where our program will end up starting with EDX, and get our data address into EBX. I then load the first encoded data with FLD, then decode it out into our program memory area with FISTP, I increment the pointers (data and program) and decode the next until I am done. When done, I jump to the start of the decoded program. There is nothing spectacular about the decoded program, just the same execve(/bin/sh) thing I always do.
\nBelow is a screenshot of the source:
\n![](\"https://xlogicx.micro.blog/uploads/2026/23725daedd.jpg\")