Week 14 — Tigress and Diversification¶

Click inside the slides and use the arrow keys; use the button at the bottom right of the slides or the link above for full screen.

# WSL / Linux (Windows'ta WSL kullanın)
cd week-14/01-kaynaktan-kaynaga
sh tigress-hatti.sh

0. Before we start¶

This section prepares you for the week. It first briefly recalls the earlier topics this week builds on; it then defines each of this week's concepts in one sentence and links it to the section where it is explained in full. Background knowledge not covered in earlier weeks is explained from scratch under the "Background" headings.

What we bring from earlier weeks¶

• Source code, compiler, and binary file — the program text a human writes (source code) being translated by a compiler into machine code and turned into an executable binary (Week 9, Background). This week we extend the same chain by passing the source through an obfuscation tool first, then the compiler.
• Code obfuscation — a countermeasure that makes code hard for a human to understand without changing its behaviour, raising the attacker's cost (Week 9, §1). Week 9 applied these rules by hand; this week we see the automatic (Tigress) counterpart of the same rules.
• Week 9's obfuscation rules (K-01–K-12) — opaque predicates, arithmetic encoding, control-flow flattening, string encoding, variable splitting, virtualisation, and the other hand-applied rules (Week 9, §5, §6, §7). Section 3 maps each of them onto a Tigress transform.
• Control flow graph (CFG) — a diagram that turns basic blocks into nodes and transitions into edges (Week 9, Background). Week 9 drew this graph from source code by hand and counted nodes/edges; this week we automate the same count with objdump on a compiled binary (see "Background" below).
• Symbolic execution — automated analysis that solves program paths as mathematical constraints (e.g., KLEE) (Week 9, §10). This week we reuse it in section 7 as the tool for measuring resilience.
• Diversification — the idea of producing behaviourally equivalent, structurally different binaries from the same source (Week 9, §8). This week we automate it in section 6 with Tigress's --Seed flag.
• CI (continuous integration) and the build pipeline — the system that runs build/test steps automatically on every code change, and the ordered sequence of steps from source to product (Week 4, §13). This week, section 9 adds obfuscation and diversification as further steps in that same pipeline.
• Build identity and the hash value — the record of exactly which binary/source/hash triple was evaluated/deployed (Week 1, §19). This week, section 9 adds a seed field to that record, because diversification can deliberately produce different binaries under the same version label.

This week's concept map¶

Background: Tigress's vocabulary¶

None of the terms below were taught in earlier weeks; all of them are needed to understand this week's tool, Tigress, and its command line. The definitions are given in an order that builds on itself.

Source-to-source transforms, pipelines, and seeds¶

This week's subject is source-to-source obfuscation: the input is a C source file, and the output is C source again — just obfuscated; this new source is then compiled with your normal compiler (gcc/clang).

A single obfuscation operation applied to the source is called a transform (for example, flattening control flow). A tool usually offers many transforms; you decide which one applies to which function. Applying several transforms in sequence is called a transform pipeline; each transform is applied to the source the previous one produced, which is why order matters (section 4).

Most transforms include some amount of randomness (e.g., which constant an opaque predicate is built from). The starting number that governs this randomness is called a seed: running the same transform pipeline with a different seed produces a different obfuscated output — this is exactly the tool behind section 6's diversification (see "What we bring from earlier weeks" above).

Working with a CLI and unit tests¶

Tigress runs from a CLI (Command-Line Interface), an interface where you run things by typing commands: you type a line such as tigress --Transform=... file.c, and the tool produces the obfuscated source. A small, automated test that checks a function works correctly is called a unit test; this week's rule is that unit tests written before obfuscation must still pass after it — behaviour must be preserved (section 2).

Two Tigress-specific details: the environment flag and transform dependency¶

The --Environment flag tells Tigress the target platform: processor architecture, operating system, and compiler version (in the demo script, --Environment=x86_64:Linux:Gcc:11 → 64-bit Intel/AMD, Linux, GCC 11). Some transforms (especially virtualisation and low-level opaque-predicate kinds) must know compiler-specific details; source generated with the wrong environment information may fail to compile on the target machine, or may behave incorrectly.

Some transforms can only run if another transform has already run first; this is called a transform dependency (example: AddOpaque needs InitOpaque — we will see this in detail in section 3). This means section 4's "order matters" rule is sometimes not just about improving the result, but about being a precondition for the transform to work at all.

Measuring and comparing cost: objdump, diff, cmp¶

This week's demo script (tigress-hatti.sh) uses a tool called objdump to measure how much a single function inside a binary has grown: a command-line tool that opens a binary file (.exe, ELF, ...) and dumps the assembly instructions inside it in human-readable form (part of the GNU Binutils package; comes preinstalled on Linux/WSL). objdump -d file ("disassemble") converts the binary's code section from machine code to assembly and prints it; the instruction count is how many lines of instructions appear in a function's assembly output (each line is a single processor instruction such as mov, cmp, or add), and the branch/call count is how many of those instructions are a jump (jmp, je, jne, ... starting with j) or a call — that is, how many points exist where the program decides to "go somewhere else."

The measurement function in the demo script (olc()) does exactly this:

objdump -d "$f" | awk '/<erisim_ver>:/{a=1;next} /^$/{a=0} a{n++; if($0 ~ /\t(j|call)/)b++} END{printf "%d komut, %d dal/cagri", n, b}'

Line by line, this is what it does: objdump -d converts the whole binary to assembly; the awk script reads only the section that begins with the <erisim_ver>: label (the a=1 flag), and stops when it reaches a blank line (the end of the function, a=0); it adds every line it reads to the n counter, and if a line has j... or call after a tab, it also increments the b counter. Result: how many instructions belong to that function, and how many of them are branches/calls.

This number is the automatic, finer-grained counterpart of the basic-block and CFG node/edge count we measured by hand in week 9: week 9 drew this graph from source code by hand and counted nodes/edges (Week 9, Background — the denetim function example: 3 nodes, 2 edges); here we count the same idea on the compiled binary, automatically, with a tool. Both ask the same question: "how much work is it to read/analyse this function?"

There are two different ways to compare the numbers we measure (clean/obfuscated version): cmp compares two files byte by byte, and only tells you "same or different" (and, optionally, the location of the first difference) — it gives a single result for the whole file. diff compares two text/source files line by line, and lists in detail which lines were added/removed/changed; for text broken into lines, such as assembly output, it is more informative than cmp. Section 6's flow of "a coarse check with cmp first, then a targeted verification with objdump+diff" rests on the idea that these two tools complement each other: cmp is fast but coarse, diff is slow but detailed.

Quick glossary: this week's new English terms¶

The following are added this week to week 9's glossary (Obfuscation, Reverse engineering, Decompiler, ...); you will meet these terms by these English names in Tigress's official documentation and on the command line:

1. What is source-to-source obfuscation?¶

In week 9 we applied obfuscation rules by hand: opaque predicates, flattening, string encoding, dead branches. Manual obfuscation is instructive, but it has three problems: (1) it is error-prone — hand-written obfuscation code can break behaviour; (2) it is hard to maintain — the source becomes unreadable; (3) it cannot be diversified — you cannot differentiate every copy by hand. The solution is to have a tool do the obfuscation.

Let's unpack the history a little more¶

• 1993 — Cohen, "program evolution": Fred Cohen (the researcher who also gave the computer virus concept its academic definition) showed that a program's structure could be changed automatically without changing its function; this is the academic origin of the idea that "every copy should look different" — this week's diversification.
• 1997 — Collberg, Thomborson, Low: they published the five-family taxonomy we use in week 9 today (layout, data, control flow, preventive, virtualisation) and the potency/resilience/stealth/cost framework; this paper is still the field's reference point, and it is the basis of this week's mapping table (section 3).
• 2013 — Obfuscator-LLVM (O-LLVM): an open-source obfuscation pass added to the LLVM compiler infrastructure; it applies techniques such as flattening and opaque predicates at compile time, without a separate source-to-source step (week 9, K-11). Its difference from Tigress is that it operates on the compiler's intermediate representation (IR) rather than on source code — so you cannot view O-LLVM's output as "C source again"; it produces a binary directly.
• 2010s — Tigress: Christian Collberg and his team turned the 1997 taxonomy into a working source-to-source tool; it became the de facto test platform for academic resilience research (including the Banescu study below) — so learning Tigress this week means learning not just a tool, but the field's shared measurement language.
• 2016–2017 — Banescu et al.: they systematically broke the transforms Tigress produces using KLEE, and measured how long each transform combination took to solve; this is the experimental evidence for the "resilience ↔ cost" relationship we will revisit in section 7 this week.

These five points are, in fact, parts of a single line: idea (1993) → classification (1997) → two different implementation routes: compiler-based (2013) and source-to-source (2010s) → the scientific testing of that implementation (2016–2017). This week we apply the last two steps of that line (using Tigress, and understanding how to evaluate it with Banescu's method — section 7).

Source-to-source obfuscation means a tool takes C source as input and produces C source again; the generated source is behaviourally identical but far harder to read, and it is compiled with your normal compiler. The best-known tool for this approach is Tigress.

The important difference: you keep and maintain the readable source; obfuscation runs as an automatic step in the build pipeline. This largely solves week 9's "every obfuscation brings a maintenance cost" problem: the maintenance cost stays with the readable source, while the distributed source is obfuscated.

What is Tigress, and where does it fit?¶

Tigress is a source-to-source C obfuscator and diversifier developed by Christian Collberg and his team at the University of Arizona. Its place in this course:

• It is the automatic counterpart of week 9's manual rules: flattening, opaque predicates, data encoding, virtualisation — each as a transform.
• It is cross-platform (Linux, macOS, Windows, Android; Intel/ARM/WebAssembly) and works with GCC/Clang/MSVC.
• Its current version is v4.

Why a tool, not by hand?¶

How much obfuscation for which code? (decision flow)¶

Obfuscating every function is both unnecessary and expensive: it increases size and running time, and makes debugging harder. The decision is made with two questions. First, is it sensitive — code that interests an attacker, such as license checking, key handling, or payment logic? If not, obfuscation isn't needed. If it is sensitive, how valuable is it — for medium-value code, constant obfuscation, arithmetic transforms, flattening, and opaque predicates are enough; for a high-value, small core, virtualisation is added on top (virtualisation is slow, so it's applied only to small sections). In every case the result is diversified, measured, tested, and the reasoning for the decision is written into the S9/S15 records.

Worked example: let's compare the same function by hand and with a tool¶

In week 9, when we applied rule K-07 (string encoding) by hand, the source code itself changed: instead of a constant string, we wrote XOR'd bytes and a decode loop. Let's now do the same idea with a source-to-source tool — the input and output are still both C, but you don't write the output, the tool produces it.

int erisim_ver(const char *jeton) {
    if (jeton_gecerli(jeton)) return IZIN;   /* a single branch, a single return: an easy target */
    return RED;
}

int erisim_ver(const char *jeton) {
    /* IZIN and RED are no longer plain constants; they pass through a decode step at runtime.
       The idea is identical to K-07 from week 9 (see the 0x41 XOR 0x5A example); the difference
       is that the decode code was produced by the TOOL, not by YOU. */
    if (jeton_gecerli(jeton)) return _cozul_sabit_0x9F2A();  /* == IZIN, but IZIN doesn't appear in the source */
    return _cozul_sabit_0x117C();                            /* == RED */
}

The second block is not real Tigress output — the generated code changes with the version, compiler, and --Seed value; it is only meant to show the idea of EncodeLiterals (just like this document's other "conceptual flow" blocks show the syntax of the commands without claiming to be real output). The important difference is this: in week 9, you would write a function like _cozul_sabit_0x9F2A() by hand, test it by hand, and write it again each time you moved to the next function. Here, the tool applies this step automatically to every function you mark with --Functions=erisim_ver.

How much time does it save? A rough comparison (hypothetical)¶

Let's also look at the why-a-tool question from a time perspective. The numbers below are hypothetical, meant only to show the order of magnitude:

The real gain here is a difference that grows not linearly, but multiplicatively: as the number of functions increases, the manual method's cost grows proportionally, while the tool method's cost stays almost constant. This is the practical reason behind section 9's recommendation to "add an obfuscation step to CI in S15."

Worked example: a one-year maintenance scenario (hypothetical)¶

Let's spread the "how much time does it save?" table over a year. Say a product releases 12 versions in 12 months, and on average 3 functions newly become sensitive with each release (e.g., a new payment flow, a new license check):

This table is hypothetical, but it correctly reflects two real trends: (1) the manual method's cost grows linearly with the number of functions and releases, while the tool method's cost stays almost constant (the scaled-up version of the first table above); (2) in the manual method, the "risk of forgetting" is a real security vulnerability — if a newly sensitive function skips obfuscation and it goes unnoticed in code review, it can ship completely unprotected; in the tool method, this risk is reduced because the --Functions list is itself an auditable document.

2. Basic flow: obfuscating a program step by step¶

Tigress runs from the command line: you tell it which transforms to apply, to which functions, and in what order; the output is an obfuscated C file. Conceptual flow (the syntax may change with the version — verify against the official documentation):

# input: temiz.c  → output: gizli.c  (then compiled normally)
tigress --Transform=Flatten --Functions=erisim_ver \
        --out=gizli.c temiz.c
cc -o program gizli.c

The three ideas here are the foundation of all Tigress usage:

1. --Transform=... says which transform to apply (Flatten = control-flow flattening, week 9 K-04).
2. --Functions=... says which functions the transform applies to — because we apply obfuscation only to sensitive functions (the cost rule).
3. The output is C again; you compile it with your own compiler. Obfuscation is a step added to the build pipeline.

Why is --Functions so important? Let's compare selective and blanket obfuscation¶

A flag like --Functions=erisim_ver means "apply only to this function." Let's consider the opposite — obfuscating every function in a file — and compare the two approaches:

End to end: let's read the tigress-hatti.sh script line by line¶

To make the conceptual flow concrete, let's read this week's real demo script (code/week-14/01-kaynaktan-kaynaga/tigress-hatti.sh) from start to finish, step by step. The script consists of four steps; let's go through all of them without skipping any.

Step 0 — Setup. The script first moves into the folder it's running from (cd "$(dirname "$0")") and picks a compiler (CC=cc, falling back to gcc if not found). This guarantees that the script will be self-sufficient no matter which machine it runs on — an example of the "resolve environment differences inside the script" habit we have seen since week 1.

STEP 1 — Build and run the clean version.

"$CC" -O2 -o ornek_temiz ornek.c && ./ornek_temiz "CEN429-OK" && ./ornek_temiz "yanlis"

This line compiles ornek.c (the actual file containing the erisim_ver function we defined in section 0) with no obfuscation applied, and runs it twice: once with the correct token (CEN429-OK), once with the wrong token (yanlis). Expected output:

erisim_ver("CEN429-OK") = IZIN
erisim_ver("yanlis") = RED

This is the reference behaviour before obfuscation — the correctness of every obfuscation done in section 3 and after is tested by comparing it against these two lines (was the behaviour preserved?).

STEP 2 — Checking for Tigress and the transform pipeline. The script first checks whether Tigress is installed with command -v tigress. There are two paths:

tigress --Environment=x86_64:Linux:Gcc:11 \
        --Transform=EncodeLiterals --Functions=erisim_ver \
        --Transform=EncodeArithmetic --Functions=erisim_ver \
        --Transform=Flatten --Functions=erisim_ver \
        --Transform=InitOpaque --Functions=main \
        --Transform=AddOpaque --Functions=erisim_ver --AddOpaqueKinds=call \
        --out=gizli.c ornek.c

ADIM 2 - Tigress KURULU DEGIL.
  Tigress'i resmi siteden indirin: https://tigress.wtf
  Lisans: kar amaci gutmeyen (akademik) kullanim UCRETSIZ; ticari icin Arizona Univ. lisansi.
  Kurulumdan sonra 'tigress' PATH'te olunca bu betik hatti otomatik uygular ve olcer.

  Tigress olmadan bile: ayni kurallarin EL ILE surumu ve olcumu week-09'da CALISIR:
    cd ../../week-09/01-manuel-gizleme && sh demo.sh

STEP 3 — Verify behaviour. If Tigress was found, the script does this:

[ "$(./ornek_temiz CEN429-OK)" = "$(./ornek_gizli CEN429-OK)" ] && echo "  ✓ ayni cikti" || echo "  ✗ FARK"

It compares whether the clean and obfuscated versions produce the same output for the same input. If ✓ ayni cikti isn't printed, the obfuscation pipeline has broken the behaviour — this is the script's counterpart of section 4's "order and test rule."

STEP 4 — Diversification. Two separate binaries are produced with two different seeds (--Seed=1001, --Seed=2002) and compared byte by byte with cmp -s A B; if the two differ, the script prints ✓ iki tohum farkli ikili uretti. This is the subject of section 6.

--out, and obfuscating several functions at once¶

The --out=gizli.c flag specifies which file the generated obfuscated source is written to; if not specified, Tigress uses a default name (verify against the official documentation). All the examples we've seen this week have focused on a single function (erisim_ver); but --Functions can take a list. Say your project has, alongside erisim_ver, a function called anahtar_turet, and both are sensitive:

tigress --Transform=Flatten --Functions=erisim_ver,anahtar_turet \
        --Transform=AddOpaque --Functions=erisim_ver,anahtar_turet \
        --out=gizli.c proje.c

--Functions=erisim_ver,anahtar_turet (a comma-separated list) applies the same transform to both functions. This is the concrete syntax for section 1's "applying the same rule to 10 functions" comparison: in the manual method you'd have to write separate encoding for each function; here it's enough to add one more name to a single flag.

3. Transform families and mapping onto week 9's rules¶

Tigress transforms correspond to the obfuscation families we saw in week 9. The table below gives the most commonly used transforms and their counterparts in the course (transform names should be verified against the official documentation; there may be small differences between versions):

Worked example: let's map K-01 onto a Tigress transform, step by step¶

Let's not leave the mapping table abstract; let's connect K-01 (week 9, opaque predicate/loop) end to end to Tigress.

1. Week 9's definition (reminder): K-01 is adding a bogus branch with a condition (opaque predicate) whose truth value is constant but looks uncertain to the attacker — the ((x*(x+1)) & 1) == 0 example and why it is always true were worked through in Week 9, §5.
2. Its counterpart in Tigress is two steps, not one: as seen in the demo script's real command, first --Transform=InitOpaque --Functions=main runs, then --Transform=AddOpaque --Functions=erisim_ver --AddOpaqueKinds=call. InitOpaque prepares the hidden state variables the opaque predicates will rely on (usually initialised inside main, as we saw in section 2); AddOpaque uses that state to add the real opaque conditions to the target function (erisim_ver). --AddOpaqueKinds=call selects the kind of opaque predicate to add (here, a "call"-based kind).
3. Result: K-01's definition of a "constant-true but uncertain-looking condition" matches exactly the conditions AddOpaque produces; InitOpaque shows the fact that K-01 isn't enough on its own — it requires a preparation step.

Worked example: let's map K-07 onto EncodeLiterals¶

Let's repeat the same steps for K-07 (string encoding), since this rule is also used in the demo script:

1. Week 9's definition (reminder): K-07 means not leaving a string like "CEN429-OK" as plain text in the binary; storing it with a reversible encoding such as XOR and decoding it only at the moment of use — the 0x41 ^ 0x5A example, traced bit by bit, was worked through in Week 9, §6.
2. Its Tigress counterpart: --Transform=EncodeLiterals --Functions=erisim_ver. This transform encodes the constant strings and numeric constants in the target function, and generates code that decodes them at run time — the automated counterpart of K-07's "hand-written" form (the "BEFORE/AFTER" example in section 2).
3. Verification: a strings check like the one in the demo script (as in week 9's demo) verifies that the text CEN429-OK is no longer visible in the obfuscated binary; this is K-07's "success criterion."

These two examples (K-01 → InitOpaque+AddOpaque, K-07 → EncodeLiterals) show how to read the rest of the table too: for each row, first recall week 9's definition, then find which flag(s) produce it, then identify a way to verify it.

Worked example: let's see how Flatten applies K-04, in code¶

After K-01 and K-07, let's make the table's most powerful control-flow transform — Flatten — concrete at the code level. Let's take section 2's erisim_ver as our base:

int erisim_ver(const char *jeton) {
    if (jeton_gecerli(jeton)) return IZIN;
    return RED;
}

int erisim_ver(const char *jeton) {
    int _durum = 7341;          /* scattered, unpredictable initial state */
    int _sonuc;
    while (1) {
        switch (_durum) {
            case 7341:
                _durum = jeton_gecerli(jeton) ? 2098 : 5560;   /* the decision is hidden here */
                break;
            case 2098:
                _sonuc = IZIN;
                _durum = 9999;
                break;
            case 5560:
                _sonuc = RED;
                _durum = 9999;
                break;
            case 9999:
                return _sonuc;
        }
    }
}

This second block, too, is not real Tigress output; it only shows the idea of Flatten. Note three points:

1. The original if/return structure is gone; in its place is a switch dispatcher inside a single while(1) loop. In a decompiler, this loop is not instantly readable the way if (jeton_gecerli(...)) was.
2. The state constants (7341, 2098, 5560, 9999) are scattered, not sequential — this is the concrete counterpart of the earlier note that "values should be produced with K-02, or as random, scattered constants"; sequential constants (1, 2, 3, 4) are instantly recognised in a decompiler as the signature of "a flattened dispatcher."
3. The branch count increased: the original had a single if (1 branch point); the flattened version has 4 cases inside the switch and the transitions between them — this is exactly the source of the "branch count only jumps at Flatten" observation in sections 5 and 7.

Let's unpack the transforms one by one: the idea behind each row¶

Let's unpack the table's ten rows in order, referring back to their week 9 definitions. For each one we answer three questions: what it does, which K rule it automates, and when it's preferred.

1. Flatten — control-flow flattening. Turns a function's if/else/loop structure into a switch dispatcher inside a single while loop; every original block becomes a case, and transitions between blocks are done by changing the case number. It is the exact automatic counterpart of week 9's K-04 (section 5, "RULE K-04 — Control-flow flattening"). As we saw in section 5's erisim_ver example, it's a moderate-cost, moderate-to-high-potency first step for easy targets like "single branch, single return."

2. InitOpaque / AddOpaque / UpdateOpaque — the opaque predicate family. The automatic form of K-01 (opaque predicate/loop). Splitting it into three separate commands is deliberate: InitOpaque prepares (sets up state variables, usually in main), AddOpaque adds (places the real conditions into the target function), and UpdateOpaque is used to update/diversify opaque structures that have already been added (across multiple obfuscation rounds). We detailed this above.

3. EncodeArithmetic — arithmetic encoding (MBA). The automatic form of K-02 (week 9, section 6: "encoding arithmetic instructions"); it turns a simple operation like a + b into a mixed boolean-arithmetic expression that gives the same result but is hard to read (recall week 9's (a^b) + 2·(a&b) = a+b example). It is low cost; but week 9's warning that "MBA can be undone with simplifiers" applies here too (section 7).

4. EncodeLiterals — constant and string encoding. The automatic form of K-07 (string encoding); we covered it in detail above. Very low cost, but weak on its own (it is exposed in memory while running — week 9's "obfuscation does not store a key" warning).

5. EncodeData — variable representation encoding. The closest automatic counterpart of K-09 (week 9, section 6: "variable splitting, merging, and array restructuring"); it changes a variable's representation in memory (e.g., a split/encoded structure instead of a single 32-bit integer). The goal is that the value does not appear directly in a memory dump.

6. Split / Merge — function splitting/merging. Part of K-06 (week 9, section 5: "hiding function calls and external library dependencies"); Split breaks a function into several smaller pieces, Merge combines several functions into one large function. Both blur the function's boundaries — in a decompiler, this makes the question "is this a single logical operation or a combination of several?" harder to answer.

7. Virtualize — virtualisation-based obfuscation. The automatic form of K-10 (week 9, section 7); it turns a function into a custom virtual machine's bytecode. It is the most expensive row in the table (the "tens of times slower" warning in the "Families and cost" box above); it is applied only to small, critical functions (the decision flow from section 1, "Step 5" in section 5).

8. Jit — run-time code generation. The conceptual counterpart of K-12 (week 9, section 7: "self-modifying code and dynamic encryption"); part of the code is generated at run time, not compile time. Week 9's warning for K-12 (that it can conflict with the operating system's memory protections — DEP/NX, W^X) applies here too; that's why it's marked "(concept)" in the table — it is not applied in this course, only recognised.

9. AntiBranchAnalysis / AntiAliasAnalysis / AntiTaintAnalysis — the anti-analysis family. The direct automatic counterpart of week 9's "preventive" family (one of the five families in section 2); these three respectively target and make harder the tools that perform branch analysis, alias analysis, and taint analysis (techniques used by a decompiler or a symbolic executor). Concrete examples of K-06's note that "targeting the analysis tools themselves is more laborious."

10. RandomFuns / RndArgs — random function/parameter addition. As we'll see in section 6's "Diversification" note, these don't serve a single K rule on their own — they serve diversification and K-06's "bogus parameter" idea: RandomFuns adds random, functionless (but real-looking) functions; RndArgs adds bogus parameters to existing functions. Both, when combined with a seed, differentiate every copy.

Worked example: how EncodeData splits a variable (conceptual)¶

Let's make EncodeData, the automatic counterpart of K-09 (week 9: variable splitting/merging), concrete. Say there is an "attempt counter" variable inside erisim_ver:

int deneme_sayaci = 0;
...
deneme_sayaci++;
if (deneme_sayaci > 3) return KILITLI;

struct { unsigned char alt; unsigned char ust; } _sayac_parcalari = {0, 0};
...
/* the counterpart of deneme_sayaci++: increment the low byte, update the high byte on overflow */
_sayac_parcalari.alt++;
if (_sayac_parcalari.alt == 0) _sayac_parcalari.ust++;
/* the counterpart of deneme_sayaci > 3: merge the two pieces and compare */
if (((_sayac_parcalari.ust << 8) | _sayac_parcalari.alt) > 3) return KILITLI;

In a memory dump (e.g., pausing the program with a debugger and reading memory), instead of appearing as a single, whole 32-bit integer, deneme_sayaci sits as two independent bytes, scattered inside a struct — this matches exactly section 0's goal that "the value should not appear directly in a memory dump."

Worked example: how Split divides a function (conceptual)¶

Let's make the Split transform concrete too. Say erisim_ver performs two logical steps back to back: a length check and a content comparison (exactly what the real erisim_ver in ornek.c does — the code in section 0).

int erisim_ver(const char *jeton) {
    if (strlen(jeton) != strlen(GECERLI)) return 0;
    unsigned fark = 0;
    for (unsigned i = 0; i < sizeof GECERLI - 1; i++)
        fark |= (unsigned)((unsigned char)jeton[i] ^ (unsigned char)GECERLI[i]);
    return fark == 0;
}

static int _adim_a(const char *jeton) {          /* length check only */
    return strlen(jeton) == strlen(GECERLI);
}
static unsigned _adim_b(const char *jeton) {      /* difference computation only */
    unsigned fark = 0;
    for (unsigned i = 0; i < sizeof GECERLI - 1; i++)
        fark |= (unsigned)((unsigned char)jeton[i] ^ (unsigned char)GECERLI[i]);
    return fark;
}
int erisim_ver(const char *jeton) {
    if (!_adim_a(jeton)) return 0;
    return _adim_b(jeton) == 0;
}

The result is two new, generically named helper functions (_adim_a, _adim_b); a decompiler now sees three separate symbols (recall the "symbol table" definition in section 0), and erisim_ver itself is now just two calls — the actual logic has been spread across other functions. Merge does the exact opposite: it combines several small functions into a single, large function; the result makes the question "is this one operation, or the sum of several?" harder in the reverse direction.

4. Transform pipeline: combining several transforms¶

Week 9's most important rule was "not a single technique, but together." In Tigress this means applying transforms in sequence (as a pipeline). Every --Transform is applied to the previous one's output; order matters.

Signing comes last (obfuscate first, sign after); after every pipeline, test the behaviour and measure the cost.

tigress \
  --Transform=EncodeLiterals --Functions=erisim_ver \
  --Transform=EncodeArithmetic --Functions=erisim_ver \
  --Transform=Flatten        --Functions=erisim_ver \
  --Transform=AddOpaque      --Functions=erisim_ver \
  --out=gizli.c temiz.c

This pipeline first encodes the constants/strings of a single check (erisim_ver), then encodes its arithmetic, then flattens it, then strengthens it with opaque predicates. The result is the automatic version of what week 9's K-04 called "reinforced flattening."

Let's concretely compare two different orders¶

Let's not leave the sentence "order matters" abstract. Let's think through the same four transforms (EncodeLiterals, EncodeArithmetic, Flatten, AddOpaque) in two different orders, and trace what covers what in each order. The rule is simple but its consequences differ: a transform can only transform what already exists in the source at the moment it runs; it cannot see the new code a transform coming after it produces.

Order 1 (this section's pipeline, the order the demo script uses):

EncodeLiterals → EncodeArithmetic → Flatten → AddOpaque

Because EncodeLiterals runs first, it only encodes the constants/strings in the original source (ornek.c). When Flatten runs third, EncodeLiterals can no longer see the new state constants (case 1, case 2, ...) that the flattened switch dispatcher produces itself — because that step has already passed. This is not a problem, because Flatten already produces its own state values as scattered/unpredictable (the note in section 5: "values should be produced with K-02, or as random, scattered constants" — here that job falls to Flatten itself). The gain in this order is this: by the time Flatten runs, the arithmetic inside every case of the dispatcher has already been complicated (thanks to EncodeArithmetic) — that is, the flattened code is hard to read both in structure and in content.

Order 2 (structural transforms first, encoding transforms after):

Flatten → AddOpaque → EncodeArithmetic → EncodeLiterals

Here EncodeLiterals is the last step; it can now see and encode not only the constants in the original source, but also the state constants Flatten produced and the opaque condition constants AddOpaque added — a wider scope. But it has a cost: since EncodeArithmetic also runs fourth, it must now encode arithmetic spread across Flatten's dispatcher logic and AddOpaque's added conditions, not just a single small function's arithmetic — the transform's job grows, and so does the generated code and cost.

Takeaway: there is no single "correct" order; order is a scope/cost trade-off. This week we take Order 1, the one the demo script uses, as our baseline because it is simple and predictable; but if you try a different order in your own project, don't say "this order is better" without running section 7's measurement steps separately for each order and comparing them — this is exactly what the "order and test rule" above means in practice.

Worked example: what happens if the signing order breaks?¶

Let's test the "signing comes last" rule with a concrete scenario. Say a developer accidentally reversed the order:

1. temiz.c is compiled → program (unsigned).
2. program is signed → program.imzali (a digital signature, bound to the file's current byte content).
3. Then the "forgotten" obfuscation step is noticed; gizli.c is produced from temiz.c, recompiled, and the resulting new binary is copied over the old signed file.

Result: the new binary produced in step 3 is different from the byte content signed in step 2 (obfuscation can change every byte of the file — recall the instruction count increase in sections 5/7). The verifying party (e.g., a loader, a store) finds the signature invalid and rejects the program — in a production environment, this means "the release could not ship."

5. Step-by-step example: reinforcing a check (synthetic)¶

Let's take a single synthetic access check and reinforce it layer by layer. The goal is to see what each step adds, and how much it costs.

int erisim_ver(const char *jeton) {
    if (jeton_gecerli(jeton)) return IZIN;   /* a single branch, a single return: an easy target */
    return RED;
}

Takeaway: each step makes the attack a little more expensive; but each step also adds a cost. You decide where to stop based on the value of the protected asset and the cost you measure (section 4). Step 5 (Virtualise) is unnecessary for most checks; it's applied only to the most critical, small functions.

Let's trace the step-by-step cost increase with a numeric example (hypothetical)¶

Let's fill the table above with numbers. The instruction/branch counts below are hypothetical (a real measurement can't be taken while Tigress isn't installed); they are meant only to show the order of magnitude of each step and how the arithmetic is verified. For real numbers, run tigress-hatti.sh while Tigress is installed and read the objdump output the script prints (recall the "instruction/branch counting" definition in section 0).

Three observations:

1. The branch count only jumps at Flatten (2 → 5): this is expected, because flattening logic, by nature, builds a multi-way switch dispatcher instead of a single if (the direct source of section 7's "potency" metric).
2. The cumulative increase is not the sum of the step increases — each percentage is added multiplicatively on top of the previous one (36.4% followed by 53.3% gives a total of 109.1%, not 36.4%+53.3%=89.7%). This is a common arithmetic mistake when computing percentages; compute each row with its own denominator (the previous step's number).
3. A large cumulative number like 359% is the expected result of stacking four transforms on top of each other; it should not be confused with the cost of a single transform (the real 82% measured in week 9's hand-applied Flatten+AddOpaque example) — here four transforms are counted together.

Worked example: a single transform, or four transforms together? A numeric comparison¶

Let's test section 1's rationale for "using them together" against the numbers above. What would have happened if we'd applied only a single transform to the same erisim_ver function, versus what happened when we applied four transforms together — let's put the two side by side (the numbers are taken from the table above/hypothetical):

The last column is the real point: applying only EncodeLiterals neutralises just one of the attacker's tools (strings); the attacker can still read the control flow directly. Applying four transforms together requires the attacker to defeat four different analysis techniques at the same time and in a mutually dependent way (the numeric rationale for week 9's rule that "two weak layers together are stronger than one layer").

6. Diversification: different binaries from the same source¶

Recall week 9's "Rule 2 — break automation" principle: if an attacker can crack one copy and distribute the attack to every copy, one crack opens everything. Diversification means producing behaviourally identical but structurally different binaries from the same source. Tigress does this with a seed: if you run the same transforms with different seeds, the opaque predicates, bogus branches, and flattening states vary from copy to copy.

tigress --Seed=1001 --Transform=Flatten --Transform=AddOpaque \
        --Functions=erisim_ver --out=gizli_a.c temiz.c
tigress --Seed=2002 --Transform=Flatten --Transform=AddOpaque \
        --Functions=erisim_ver --out=gizli_b.c temiz.c
# gizli_a.c and gizli_b.c do the same job; their machine code differs

Two kinds of diversification (from week 9):

• Diversification in space: distributing copies produced with different seeds to different users/devices. An automated attack written against one copy does not work on another.
• Diversification in time: producing every release with a new seed. An attack found against an old release breaks on the new one. This works together with your week 10 key/version renewal policy.

Worked example: let's compare the binaries produced with two seeds, step by step¶

The demo script's STEP 4 does exactly this: it produces two separate erisim_ver builds from the same ornek.c with --Seed=1001 and --Seed=2002, compiles them, and compares them byte by byte with cmp -s A B. Let's trace the steps one by one:

1. Same source, two commands:

tigress --Seed=1001 --Transform=Flatten --Transform=AddOpaque --Functions=erisim_ver --out=a.c ornek.c
tigress --Seed=2002 --Transform=Flatten --Transform=AddOpaque --Functions=erisim_ver --out=b.c ornek.c

Note: the --Transform list is exactly the same in both (Flatten, AddOpaque); the only difference is the --Seed value. 2. Compile: a.c and b.c are compiled with the same compiler and flags (-O2) into two separate binaries (A, B). 3. Compare behaviour (this first!): both binaries must be run with the CEN429-OK input and verified to give the same output (IZIN) — diversification must never change behaviour (section 4's rule applies here too). 4. Compare structure: cmp -s A B compares the two files byte by byte; if $? (the exit code) is 0, the files are identical (bad — it means diversification didn't work), if it's 1, they are different (the expected result).

Let's quantify the difference ratio (hypothetical, in a form similar to week 9's real 66.4% example). Say the flattened + opaque-predicate version of erisim_ver takes up 160 bytes in both binaries; comparing byte by byte, we measured that 96 bytes came out different:

diff_ratio = changed_bytes / total_bytes × 100
           = 96 / 160 × 100
           = %60

Interpretation: 60% of the two copies are different, 40% is shared (likely parts the compiler keeps fixed, such as function entry/exit — the same reason for the remaining 33.6% in week 9's 512-byte example). The 66.4% measured in week 9's manual diversification and the 60% Tigress produces this week with --Seed are the same order of magnitude — this is expected, because both apply the same idea (changing structure with random choices); the exact number will, of course, differ between hand-written and tool-generated code.

Worked example: let's compare the target function directly instead of cmp¶

Let's apply the correct method the "common mistake" box above recommends. cmp -s A B only says "different/same"; to see whether the target (erisim_ver) itself is different, we apply section 0's objdump method to both binaries and compare only that function's section:

# Extract only what's under the <erisim_ver>: label from both binaries
objdump -d A | awk '/<erisim_ver>:/{a=1} a{print} /^$/{if(a)exit}' > erisim_A.asm
objdump -d B | awk '/<erisim_ver>:/{a=1} a{print} /^$/{if(a)exit}' > erisim_B.asm
diff erisim_A.asm erisim_B.asm | wc -l    # if 0, the target function stayed the SAME

If diff's output is empty (line count 0), this means the two seeds produced no difference at all in erisim_ver — that is, section 6's claim (diversification happened) is false, and the difference cmp found across the whole file was only in an insignificant spot (e.g., a compile timestamp). If diff's output is non-empty, the target function itself has really changed — only then can we say "diversification is proven." This two-step verification (first "is something different?" with cmp, then "is the target itself different?" with objdump+diff) completes the demo-script account at the start of section 6.

How many users, how many seeds? Let's think about diversification in space at scale (hypothetical)¶

Let's make the "diversification in space" definition from the start of section 6 concrete with a deployment scenario. Say a mobile application has 10,000 users, and a different seed is used for every install:

The calculation in the third row is simple: even if an attacker cracks a single copy and produces a byte patch specific to that copy, the patch only works on binaries produced with the same seed; if every user has a different seed, the patch works on no other copy. These numbers are hypothetical (the real impact also depends on how well the attacker can generalise the patch — e.g., a patch that targets only a specific byte offset has an even narrower effect, while one based on a behavioural pattern might be a bit wider); the goal is only to show the relationship that "as the number of seeds grows, a crack's spreading surface shrinks."

Worked example: let's trace diversification in time on a timeline (hypothetical)¶

Let's also make diversification in time, the twin of the "diversification in space" example above, concrete with a release calendar. Say a product releases a new version every month, and every release is obfuscated in CI (section 9's rule) with a new seed:

The "lifetime" of February's crack lasted only one month (from v1.1's release date to v1.2's release date) — this is the numeric counterpart of section 1's "Rule 3 — buy the other layers time" principle. If the product had never changed the seed (no diversification in time) and kept the same obfuscation structure even while adding new features every month, February's crack would have stayed valid indefinitely.

This cycle's cost is nearly zero, because section 9's CI skeleton runs obfuscation + measurement + signing automatically on every release (recall section 2's "tool or by hand" comparison); if diversification had been done by hand, obfuscation would have had to be rewritten by hand every month — which would not have been sustainable in practice at all.

7. Measuring obfuscation and diversification¶

In week 9 we learned to measure obfuscation along four dimensions (potency, resilience, stealth, cost). Tigress's greatest teaching value is that it lets you make these measurements concrete: you obfuscate the same program and measure it before/after.

Cost measurement (easy and mandatory)¶

Measure the following for every transform pipeline and write them into S9/S15:

size ./program_temiz ./program_gizli        # size difference
# time: run N times with the same input, compare the average

Resilience measurement (advanced, conceptual)¶

In week 9 we said resilience is "a measured quantity, not a claim." Tigress is at the centre of academic work on this: the study by Banescu and colleagues measures how much Tigress's transforms resist symbolic execution (like KLEE). The finding is an important rule for this course:

• A single transform (Flatten alone) can usually be undone with symbolic execution.
• Combining transforms and growing the state space (tying opaque predicates to structures that are expensive to solve) can make the solver's job exponentially harder.
• But this also raises the cost. That is, resilience and cost trade off exactly as we said in week 9.

Let's complete the size and time measurement: adding to section 5's numbers¶

In section 5 we traced, step by step, the increase in a single function's (erisim_ver) instruction and branch counts (a hypothetical 359.1% cumulative instruction increase, going from 2 branches at step 0 to 7 branches at step 4). Let's now distribute these numbers across Collberg's four metrics (the table above) and also add size and time.

Potency, using week 9's cyclomatic complexity formula (branch_count + 1):

Step 0 (clean)        : 2 branches + 1 = 3
Step 4 (full pipeline): 7 branches + 1 = 8
Increase              : (8 − 3) / 3 × 100 ≈ %166,7

Cost, the instruction-count increase from section 5: we already computed it, 359.1% (cumulative, four transforms together).

Size: an important warning is needed at this point.

Time: a similar warning applies to time — a single call to such a small function takes far less time than the operating system's timer resolution (usually sub-millisecond); to see a meaningful time difference, you need to call the function a large number of times (e.g., a million) in a loop and measure the total time:

# Pseudocode: the real measurement tool varies by platform (e.g. `time`, a benchmarking loop)
for i in $(seq 1 1000000); do ./ornek_temiz CEN429-OK >/dev/null; done   # time is measured
for i in $(seq 1 1000000); do ./ornek_gizli CEN429-OK >/dev/null; done  # time is measured and compared

Note: the loop above actually also measures the cost of starting a new process each time (fork/exec), which can overshadow the real function time; in a real measurement, the function is called millions of times inside a loop, in the same process, and only that loop's duration is measured. This distinction — "the cost of starting a process" versus "the function's own time" — is a point that is often confused in small demos.

Let's gather the four metrics in a single table¶

Let's make resilience a bit more concrete: how does symbolic execution break the condition AddOpaque produces?¶

The section above said "resilience measurement (advanced, conceptual)" and referred to the Banescu et al. study; week 9 walked through this mechanism step by step on a classic opaque predicate (((x*(x+1)) & 1) == 0). Let's apply the same reasoning to a tool-generated opaque predicate — this week's subject (one of the conditions Tigress's AddOpaque adds, conceptually):

1. A symbolic execution tool (like KLEE) runs the program not with concrete values, but by keeping the input as an unknown symbol.
2. When it reaches a branch AddOpaque has added, the question the tool has to ask is the same: "does this condition give the same result for every value of the input, or is there an input that breaks it?"
3. It hands this question off to a constraint solver (an SMT solver). If the condition AddOpaque produces rests on a mathematically simple, well-known pattern, like week 9's x*(x+1) example, the solver solves it in seconds and proves that branch is "dead" (never runs).
4. Result: being tool-generated does not automatically make an opaque predicate more resilient — the mathematical structure of the generated condition is still what determines this. This shows that week 9's warning that "not every technique resists every tool equally" also applies to Tigress's own output.

Connection to week 12's measurement/evidence discipline¶

Week 12 taught that a security claim must be backed only by a test result (S16), that a "result, not a plan" is expected; the same discipline applies here. This week's four-metric table (potency, resilience, stealth, cost) should appear in your S9/S15 document not as a standalone claim, but as a result tied to its own evidence (a measurement table, cmp output, a symbolic-execution attempt). Don't forget to also add to week 12's TOE identity (section 0) which seed and which transform pipeline produced the binary this measurement table belongs to — otherwise an evaluator cannot tell which measurement describes which binary.

Worked example: let's conceptualise the stealth metric¶

Recall week 9's entropy example (section 0: [0x41,0x41,0x41,0x41] is low-entropy, [0x3F,0xA1,0x08,0xC7] is high-entropy). Stealth asks whether obfuscated code is statistically distinguishable from normal code — and this distinguishability often comes precisely from a difference in entropy/density.

A hypothetical example: say a tool scanning a binary file measures the branch-instruction density in every 256-byte window:

Interpretation: the obfuscated erisim_ver's branch density is statistically markedly different from the file's other ordinary functions. Without having to scan the whole binary, an attacker can go straight to erisim_ver just by looking for "abnormally branch-dense regions" — this means "stealth is dropping": while potency and cost increase (section 7's first table), stealth has decreased.

A numeric example: hypothetical solver time for different transform combinations¶

Let's show the shape of Banescu et al.'s method (not their real numbers) with a table; the times below are entirely hypothetical, meant only to show the shape of the relationship "more layers = longer time for the solver":

The last row is the reflection, on the resilience metric, of section 6's rule that "diversification doesn't raise potency, it prevents scaling": the hours-scale solver effort spent on one copy must be spent again from scratch for the next copy — because a different seed produces different opaque-predicate constants.

8. In-class flow: obfuscate, compare, measure, diversify¶

This week's exercise is done on the student's own small program, on the student's own machine (they download Tigress themselves from the official site). The flow is entirely defensive in purpose: you protect your own code and measure the cost of protecting it.

1. Setup: write a small, synthetic program (e.g., an erisim_ver check). Show that it works correctly with unit tests.
2. Obfuscate: apply a transform pipeline (EncodeLiterals → EncodeArithmetic → Flatten → AddOpaque).
3. Verify behaviour: run the same unit tests against the obfuscated version — the result must be exactly the same. If not, the pipeline is wrong.
4. Compare: compare the clean and obfuscated versions' control flow in a decompiler (e.g., Ghidra/objdump); note the increase in basic block count.
5. Measure: measure binary size and running time before/after.
6. Diversify: run the same pipeline with two different seeds; show that the two binaries are different.
7. Report: write the findings into a table (transform, size, time, block count, seed difference) — this table goes directly into S9/S15.

Common mistake: skipping step 3 (verify behaviour) and going straight to step 5 (measure)¶

Under time pressure, some students run the transform pipeline, immediately measure the binary size, and jump to the conclusion "obfuscation worked" — without ever doing the behaviour verification (step 3). This is dangerous because a function that is larger but broken also looks "successful" on the size metric; the real question is not size, but whether correctness was preserved.

Worked example: let's trace the seven steps in a real student scenario (hypothetical)¶

Let's summarise, with a short record table, how a student applied these seven steps to their own small "PIN verification" function (the numbers are hypothetical, meant only to show the shape of the process):

This table format is a template you can copy directly into your term project's S9/S15 section; you just need to replace the numbers with your own measurements.

Worked example: how skipping one step breaks the chain (hypothetical)¶

Let's make the seven-step flow's warning that "skipping a step makes the rest of the chain meaningless" concrete with a table:

This table shows that none of the seven steps is optional: each row points to which later step is made meaningless by skipping the one before it — just like in section 4's transform pipeline, here too the idea of a "pipeline" is applied to the process itself.

9. Placing obfuscation into the build and deployment pipeline (S15)¶

Obfuscation should not be "a job done by hand at the very end," but a step in the build pipeline. Your project's S15 section, after the midterm, documents exactly this:

• Only sensitive functions are obfuscated (--Functions); the rationale is written down.
• Every release is diversified with a seed; the seed and the build identity are recorded.
• Signing happens after obfuscation; the build identity and hash values (week 12's TOE identity) stay consistent.
• The pipeline runs in continuous integration (CI); unit tests + size/speed measurement run automatically on every release.

Let's read the S15 pipeline step by step¶

Let's unpack the four boxes in the figure (h14-07) (obfuscation, signing, build identity, CI) into a sequential list — each step is the input to the next, just like in section 4's transform pipeline:

1. Build (clean): temiz.c (the readable source) is compiled normally; unit tests are run against this build.
2. Obfuscate: the agreed transform pipeline (section 7) is applied only to the sensitive functions marked with --Functions; a new --Seed is generated (section 6's "always record the seed" rule kicks in here — CI must write the seed it used to a log/artefact).
3. Rebuild (obfuscated): gizli.c is compiled normally; the same unit tests are run against this build as well (the CI counterpart of section 2's STEP 3 — if behaviour hasn't changed, the tests pass; if it has, CI must fail).
4. Measure: size/instructions/branches (sections 5, 7) are measured automatically and compared against the previous release; a sudden, unexplained deviation (e.g., unexpectedly shrinking) can point to a bug.
5. Sign: only the binary that passes the test + measurement steps is signed — the CI counterpart of section 4's "signing comes last" rule.
6. Record the build identity: the seed used, the transform pipeline, the hash value, and the signature are written together into a record (the S15 document) — this is a direct application of week 12's TOE identity definition (version + binary + source + hash); the difference is that a fifth field (the seed used) is added to the four components here, because the same source+version label can produce deliberately different binaries with different seeds (recall the "build identity and hash value" definition in section 0).

Let's write these six steps as a CI script's conceptual skeleton (not the syntax of a specific CI product, but pseudocode showing the order of the steps):

stage derle_temiz:
    cc -O2 -o out/temiz temiz.c
    run_unit_tests out/temiz

stage gizle:
    seed = new_random_seed()
    tigress --Seed=$seed --Transform=... --Functions=... --out=gizli.c temiz.c
    save seed -> log/release-$RELEASE.txt

stage derle_gizli:
    cc -O2 -o out/gizli gizli.c
    run_unit_tests out/gizli   # CI STOPS if it fails

stage olc:
    objdump -d out/gizli | olc_komut_dal erisim_ver >> log/release-$RELEASE.txt

stage imzala:
    sign out/gizli -> out/gizli.signed

stage kaydet_surum:
    digest = sha256(out/gizli.signed)
    save RELEASE, seed, digest, transform_pipeline -> TOE-record-$RELEASE.txt

Every line of this skeleton corresponds to a section from this week: derle_temiz → section 2, STEP 1; gizle → section 4 (pipeline) + section 6 (seed); the test step of derle_gizli → section 2, STEP 3; olc → sections 0/5/7; imzala → this section's "signing last" rule; kaydet_surum → week 12's TOE identity.

Worked example: a TOE record across three releases¶

Let's make the "build identity + seed" idea from section 0 and this section concrete with a filled-in record table for three consecutive releases (hypothetical):

This table is the S15-document counterpart of section 6's "diversification in time" example: each row proves exactly which binary that release is (via seed + pipeline + hash), and that binary is signed and tested. The "pipeline change" in v1.2 (RandomFuns added) is also recorded — this is the information week 12's "delta evaluation" (re-evaluating only the changed part) needs: an evaluator can read directly from this table what changed from v1.1 to v1.2, without having to compare the source code line by line.

10. Term project: this week (S9 advanced + S15 pipeline)¶

1. Choose a transform pipeline and write it into S9: which functions, which transforms, in what order, why.
2. Measurement table: size, time, and (if available) block count — before/after.
3. Diversification: production with two seeds and the difference metric; if you won't apply it, the rationale.
4. The S15 pipeline: document the obfuscation + signing + build identity steps with a diagram.
5. Evidence of behaviour: show that the obfuscated version passes the unit tests (the link to S16).

A filled-in example: the "RULE" template for S9/S15¶

Week 9's section 4 taught writing every protection decision with the template "What it protects / How / Cost / Limit." Let's fill in the same template for this week's Tigress pipeline:

What does it protect? : The logic of the synthetic access check (which token counts as valid);
                         delays it against reverse engineering.
How?                   : Tigress --Transform=EncodeLiterals,EncodeArithmetic,Flatten,InitOpaque,AddOpaque
                         (the full command in section 2, STEP 2); a new --Seed is generated every release (section 6).
Cost                   : ~%359,1 instruction increase, ~%166,7 complexity (potency) increase (section 7,
                         hypothetical demo numbers; real numbers are measured with `tigress-hatti.sh`).
Limit                  : Resilience and stealth were not measured in this demo (section 7); a whitebox-level
                         protection is not claimed without Virtualize on its own (compare with week 11).

Repeat this filled-in example in your own project, with your own function and your own measured numbers; none of the template's four lines should be left blank.

An example filled-in mini-report (a starting template for S9/S15)¶

Let's combine all of this week's pieces (transform pipeline, measurement, diversification, S15 pipeline) into one example report. The text below is a starting point you can carry directly into your S9/S15 section by replacing the numbers with your own measurements (all numbers are consistent with this week's hypothetical examples):

Function          : erisim_ver
Why sensitive?    : Synthetic token check (the decision flow in section 1: sensitive + medium value)
Transform pipeline: EncodeLiterals -> EncodeArithmetic -> Flatten -> InitOpaque(main) -> AddOpaque
Seed (release 1.0): 1001
Behaviour proof   : The clean and obfuscated versions gave the same output for the CEN429-OK / yanlis inputs (ADIM 3: ayni cikti)
Cost              : Instructions 22->101 (%359,1), branches 2->7, complexity (potency) 3->8 (%166,7)
Diversification   : Binaries produced with Seed=1001 and Seed=2002 showed a %60 byte difference (cmp: different)
Resilience        : Not measured this round; will be tested with KLEE in the next iteration (section 7)
Stealth           : Not measured this round; a branch-density map will be produced (section 7)
S15 status        : In CI, the obfuscate->test->measure->sign->record steps are defined; release record TOE-record-1.0.txt
Limit             : No whitebox-level protection is claimed on its own (compare with week 11)

Every line of this template corresponds to a section from this week (read it together with the "A filled-in example: the RULE template" section above): Function/Why sensitive → section 1; Transform pipeline/Seed → sections 4, 6, 9; Evidence of behaviour → section 2, STEP 3; Cost → sections 5, 7; Diversification → section 6; Resilience/Stealth → section 7; S15 status → section 9; Limit → sections 1, 9, 11.

The week's big picture: how do the sections connect?¶

After seeing so many new terms and examples, it can become hard to see them all as a single chain. The table below summarises this week's eleven sections in order; each row explains what it adds to the one before it:

This table gives a quick answer to "which section did I forget?" when preparing for an exam or a project: if you can't explain what a section adds to the one before it, reread that section; if one link in the chain is missing, the rest loses its meaning too — just like in section 4's transform pipeline.

11. Self-check¶

12. Resources and further reading¶

• The Tigress official site and worksheets (tigress.wtf) — transforms, syntax, current version (v4), and license. Students verify the current version and terms here.
• C. Collberg, J. Nagra, Surreptitious Software — the obfuscation taxonomy and measurement framework (shared with week 9).
• S. Banescu, C. Collberg et al. — measuring the resilience of Tigress transforms to symbolic execution (KLEE).
• Obfuscator-LLVM (O-LLVM) — an alternative to compiler-based obfuscation (week 9, K-11).