Obfuscation: Growing Forest to Hide a Leaf

What a fiendish cipher it must be, to talk about it left, right, and center!
— from Cyberiad by Stanislaw Lem —

With all those considerations which we discussed over the course of last 2 posts, an obvious question of “how to use it in practice” arises. To illustrate those points I’ve made, I wrote a pure C++ template-based obfuscation library, and placed it to Github [rabbit_cite id="NoBugs"]. Note that it is a pure C++ solution, i.e. without an external code generator; while abilities of the pure C++ are limited compared to the code generator-based solutions, I was surprised how much it is possible to achieve while staying entirely within bounds of C++.¹

DISCLAIMER: as of now, library is in pre-alpha stage; while I am reasonably confident that if it compiles, it will produce consistent results (i.e. output with obfuscation will be the same as output without obfuscation), chances of it failing to compile in certain use cases are still pretty high <sad-face />. Still, as a proof-of-concept it IS interesting to see the results which can be obtained even with a pure in-language solution.

¹ C++17, to be exact; don’t even try it without MSVC2017, or without /std:c++latest. While support for modern Clang is hopefully possible, it is not there yet.

Basic Idea

As it was discussed above –

I am a Big Fan™ of automated randomized code generation.²

In other words – the idea is NOT to write obfuscations manually. Instead – we should just declare which-things-we-want-to-obfuscate, and then obfuscation library should take care of the rest.

Example: factorial() function

To illustrate “how ithare::obf can be used to obfuscate things”, we’ll use the following very simplistic factorial() function:

//Listing 29.factorial.orig
__declspec(noinline) int64_t factorial(int64_t x) {
if(x<0)
throw MyException(“Negative value of factorial!”);

int64_t ret = 1;
for(int64_t i=1; i <= x; ++i) {
ret *= i;
}

return ret;
}

Note: above, __declspec(noinline) is used merely to isolate our factorial() function from the rest of code, to see what is going on more clearly. With a few very narrow exceptions, noinline SHOULD NOT be used for production code (leave alone obfuscated production code).

Baseline

After compiling the code above in Release x64 mode, we get the following assembly (as shown by IDA Pro; other disassemblers may provide less information, but we should be ready to the attacker using the-best-available-tools):

;; Listing 29.factorial.orig.asm
;; single-; indicates comments by IDA Pro
;; double-;; indicate my own comments
var_38 = byte ptr -38h ;; offset identifier created by IDA Pro

sub rsp, 58h
mov rdx, rcx
test rcx, rcx
js l1
mov eax, 1
mov ecx, eax
cmp rax, rdx
jg l2
nop dword ptr [rax + rax + 00000000h] ;; aligning instructions

l3: 
    imul rax, rcx
    inc rcx
    cmp rcx, rdx
    jle l3

l2: 
    add rsp, 58h
    retn

l1: 
    lea rcx, [rsp + 58h + var_38]
    call sub_2
    lea rdx, [__TI1?AVMyException@@] ; throw info for 'class MyException'
    lea rcx, [rsp + 58h + var_38]
    call _CxxThrowException

sub_2:
    push rbx
    sub rsp, 20h
    lea rax, off_1400036F90
    mov rbx, rcx
    mov [rcx], rax
    lea rdx, aNegativeArgume ; "Negative argument to factorial!"
    add rcx, 8
    call sub_3
    mov rax, rbx
    add rsp, 20h
    pop rbx
    retn

It is very short, and is rather clear even in asm. NB: as we can see, MyException name is visible in the .exe – that’s in spite of me disabling RTTI (RTTI seems to be enabled at least for classes-being-thrown regardless of /GR- option being fed to MSVC compiler ).

Even better for the potential attacker (and worse for us), is that if we feed this code to the IDA Pro decompiler, our intentions will be even more obvious:

// Listing 29.factorial.obf.decompiled.c
signed __int64 __fastcall sub_1(signed __int64 a1) {
    signed __int64 v1; // rdx
    signed __int64 result; // rax
    signed __int64 i; // rcx
    char v4; // [rsp+20h] [rbp-38h]

    v1 = a1;
    if (a1 < 0) {
        sub_2(&v4);
        CxxThrowException(&v4, &_TI1_AVMyException__);
    }

    result = 1i64;
    for (i = 1i64; i <= v1; ++i)
        result *= i;
    return result;
}

_QWORD *__fastcall sub_2(_QWORD *a1) {
    _QWORD *v1; // rbx

    v1 = a1;
    *a1 = &off_140036F90;
    sub_3(a1 + 1, "Negative argument to factorial!");
    return v1;
}

Aren't you amazed at capabilities of IDA’s reverse engineering? I certainly am; it indeed looks extremely close to the original code, and our intentions are indeed very clear. Even if we wouldn’t give away that obvious clue with our “Negative argument…” error string – the attacker still won’t have much problems realizing that our sub_1() is a function which calculates factorial (that for(i) loop in sub_1() gives it away almost-instantly).

This is the point where our obfuscation task starts…

Obfuscated-but-Still-Readable-and-Debuggable?

As it was stated above, our goal is to obfuscate the binary code, while keeping our source code as-readable-as-possible. Let’s see how ithare::obf from library [rabbit_cite id="NoBugs"] deals with it.

To enable automated randomized obfuscation, we have to say which variables and which literals we want to obfuscate, and to what extent (leaving generation of the actual obfuscation code to the library and compiler). Let me show it on example of our factorial() function:

// Listing 29.factorial.obf
__declspec(noinline) OBF6(int64_t) factorial(OBF6(int64_t) x) {
    if (x < 0)
        throw MyException(OBF5S("Negative value of factorial!"));

    OBF3(int64_t) ret = 1; // we could obfuscate literal '1' too,
                           // but for such common literals it rarely makes sense
    for (OBF3(int64_t) i = 1; i <= x; ++i) {
        ret *= i;
    }

    return ret;
}

That’s it! As you can see, we didn’t do any real obfuscation here, merely declaring which variables have to be obfuscated (in fact, we’re replacing types-to-be-obfuscated with their obfuscated counterparts).

About those digits within OBF6() and OBF3(). In ithare::obf there is a convention that this-digit-after-OBF means “how much we want to obfuscate this type/literal”: OBF0() means “obfuscate using no more than 1 CPU cycle”, OBF1() – “using no more than 3 CPU cycles”, OBF2() – “no more than 10 CPU cycles”, and so on. More generally, OBFX() means “obfuscate using no more than 10^(X/2) CPU cycles”, so OBF6() is allowed to eat up to 1000 CPU cycles.

Obfuscating Parameters and Return Values

In our example above, we obfuscated not only internal variables, but also input parameters and return values of our factorial() function (and moreover, we used MUCH more severe obfuscation on entry and on exit, than inside). The reason for it is that

We want to obfuscate not only the nature of the function, but also its interfaces.

This provides two very significant benefits:

When debugging, attacker cannot really see real values of the function parameters (he will see only those obfuscated values). As call stack is one of major tools used by attackers, making it less obvious (and we’ll be making it much less obvious – see decompiled examples below) certainly qualifies a Good Thing™.
Even if the attacker knows what our function does, to invoke the function properly he still needs to deobfuscate the API
Even if the attacker knows what our function does, to invoke the function properly he still needs to deobfuscate the API (i.e. reverse-engineer current randomized incarnation of the code). And as this obfuscation changes automagically on each build (more on it below) – it means that each successful-attack-which-uses-this-API, still has to be rewritten for each new release of our Client. Sounds as a lot of tedious mundane work for the attacker – and this is certainly another Good Thing™ for us as defenders.³

² That is, for obfuscation purposes.

³ Of course, in theory this process can be automated, but for the time being – there are no such tools. Moreover – even in theory there are limits to such automation, especially as boundaries between real code and obfuscation are far from being obvious(!). Those reverse-engineering guys I spoke to, when faced with such automation, were referring to using SAT solvers for this task, and with SAT solvers being NP-complete – well, it is a pretty hopeless mechanism of dealing with sizeable problems.

Debugging

As we can observe, our source code is not too obfuscated. Moreover, if we compile it for debugging (i.e. without ITHARE_OBF_SEED being defined) – it will stay debuggable too; here is a screenshot from MSVC with our factorial() function being debugged:

debugging obfuscated code in Visual Studio

As we can see, in this mode (without ITHARE_OBF_SEED), all the variables look more or less as their counterparts (that added ‘val=’ to the value is not TOO bad debugging-wise). Of course, we won’t be debugging our obfuscation this way – but when debugging our app-level logic, we have to assume that whatever-obfuscation-we-have works flawlessly anyway.⁴

⁴ BTW, even now, in pre-alpha, I am reasonably confident that as soon as obfuscated code compiles – it does work properly (and bugs causing compile failures, are being steadily ironed out).

Compile for Production: Enter ITHARE_OBF_SEED

Now, let’s try to compile the very same Listing 29.factorial.obf for production; to do it – we have to recompile exactly the same source code but with ITHARE_OBF_SEED #defined to be a large random number.⁵

At this point, we get an executable, which is functionally equivalent to the original one – but is randomly and severely obfuscated. Let’s see what current (as of January 2018) version of the ithare::obf will do with our factorial() function.

From assembler, the following can be observed:

Our “Negative value of factorial!” literal is no longer easily visible (it doesn’t show in “Strings” view of IDA Pro, and is not really easily detectable until the moment we decide to use it).
Our simplistic factorial() function now takes whopping 2 kilobytes(!).

As it is sooooo large (and is not-so-easy-to-comprehend) – I will provide only a portion of it (specifically the inner loop) here:

;; Listing 29.factorial.obfuscated.asm.InnerLoopOnly
loc_140002430:
    mov     r9, r15
    mov     r10d, 1Fh
    sub     r9, rax
    imul    rax, rcx, 1Fh
    mov     r8d, r9d
    sub     r10, rax
    and     r8d, 0FFFF0000h
    movzx   eax, r9w
    add     r8d, eax
    mov     eax, r9d
    sub     r8, rax
    add     r8, r9
    imul    r10, r8
    mov     edx, r10d
    movzx   eax, r10w
    and     edx, 0FFFF0000h
    add     edx, eax
    mov     eax, r10d
    sub     rax, rdx
    mov     rdx, cs:qword_14003FAA0
    sub     rax, r10
    add     rax, r15
    movzx   r8d, byte ptr [rdx+2]
    imul    r8, -1Fh
    imul    rdx, rcx, -1Fh
    add     r8, rbx
    mov     rcx, r8
    mov     r8d, 1Fh
    inc     rdx
    imul    rcx, rdx
    imul    rdx, rcx, 1Fh
    sub     r8, rdx
    cmp     r8, r11
    jle     short loc_140002430

As we can see – it is far from being obvious; while we do have an imul operation within – it doesn’t give up much, as actually we have six of such imuls, and it isn’t obvious whether they’re part of obfuscation, or not.

And even if we look at the our obfuscated factorial() function through the prism of almighty IDA Pro’s decompiler – all we get is the following:

// Listing 29.factorial.obf.decompiled.c
_DWORD *__fastcall sub_1(_DWORD *a1, __int64 a2) {
    int v2; // er14
    __int16 v3; // ax
    int v4; // er9
    int v5; // er11
    __int16 v6; // r10
    int v7; // er13
    int v8; // eax
    unsigned __int64 v9; // r8
    unsigned __int64 v10; // rax
    signed __int64 v11; // rcx
    int v12; // er8
    int v13; // er11
    int v14; // edi
    int v15; // edi
    int v16; // er11
    unsigned __int64 v17; // r11
    int v18; // er10
    unsigned int v19; // ebx
    int v20; // edi
    int v21; // er11
    unsigned __int64 v22; // rsi
    unsigned __int64 v23; // r10
    int v24; // er9
    unsigned int v25; // edi
    int v26; // ecx
    int v27; // er10
    int v28; // er9
    int v29; // er11
    unsigned __int64 v30; // rdx
    _DWORD *result; // rax
    unsigned __int64 v32; // rdx
    __int16 v33; // ax
    int v34; // er8
    __int64 v35; // r8
    _DWORD *v36; // [rsp+48h] [rbp-51h]
    char v37; // [rsp+50h] [rbp-49h]
    char v38; // [rsp+54h] [rbp-45h]
    char v39; // [rsp+58h] [rbp-41h]
    char v40; // [rsp+5Ch] [rbp-3Dh]
    char v41; // [rsp+60h] [rbp-39h]
    __int64 v42; // [rsp+70h] [rbp-29h]
    __int64 v43; // [rsp+78h] [rbp-21h]
    char v44; // [rsp+80h] [rbp-19h]
    unsigned int v45; // [rsp+A8h] [rbp+Fh]
    int v46; // [rsp+ACh] [rbp+13h]
    unsigned int v47; // [rsp+B0h] [rbp+17h]
    int v48; // [rsp+B4h] [rbp+1Bh]
    int v49; // [rsp+B8h] [rbp+1Fh]
    int v50; // [rsp+BCh] [rbp+23h]
    unsigned int v51; // [rsp+C0h] [rbp+27h]
    unsigned int v52; // [rsp+C4h] [rbp+2Bh]

    v36 = a1;
    v2 = -256 * BYTE5(a2) - ((unsigned __int16)(15 - HIWORD(a2)) << 16) - BYTE4(a2) + 31;
    v3 = (unsigned __int64)((unsigned int)(unsigned __int16)(HIWORD(v2) - (-256 * BYTE5(a2) - BYTE4(a2) + 31) * (-256 * BYTE5(a2) - BYTE4(a2) + 31)) - 15 + (v2 << 16)) >> 16;
    v4 = (((unsigned __int16)(HIWORD(v2) - (-256 * BYTE5(a2) - BYTE4(a2) + 31) * (-256 * BYTE5(a2) - BYTE4(a2) + 31)) - 15 + (v2 << 16)) << 16)
        + (unsigned __int16)(v3 - (HIWORD(v2) - (-256 * BYTE5(a2) - BYTE4(a2) + 31) * (-256 * BYTE5(a2) - BYTE4(a2) + 31) - 15) * (HIWORD(v2) - (-256 * BYTE5(a2) - BYTE4(a2) + 31) * (-256 * BYTE5(a2) - BYTE4(a2) + 31) - 15));
    v5 = (unsigned __int16)((HIWORD(v4) << 8) + (((HIWORD(v4) >> 8) - HIWORD(v4)) & 0xFF))
        + ((((unsigned __int8)(3 - 15 * ((unsigned __int16)(v3 - (HIWORD(v2) - (-256 * BYTE5(a2) - BYTE4(a2) + 31) * (-256 * BYTE5(a2) - BYTE4(a2) + 31) - 15) * (HIWORD(v2) - (-256 * BYTE5(a2) - BYTE4(a2) + 31) * (-256 * BYTE5(a2) - BYTE4(a2) + 31) - 15)) >> 8)) << 8) + 65521 + (unsigned __int8)(v3 - (BYTE2(v2) - (31 - BYTE4(a2)) * (31 - BYTE4(a2)) - 15) * (BYTE2(v2) - (31 - BYTE4(a2)) * (31 - BYTE4(a2)) - 15))) << 16);
    v6 = (unsigned __int16)(31 - ((unsigned __int8)-HIBYTE(v5) << 8) - (unsigned __int8)(3 - BYTE2(v5))) >> 8;
    v7 = ((_DWORD)a2 << 16) + (unsigned __int16)(WORD1(a2) - a2);
    v8 = (unsigned __int64)(v7 + (unsigned __int16)(WORD1(a2) - a2 - 3) - (unsigned int)(unsigned __int16)(WORD1(a2) - a2)) >> 16;
    
    // Additional calculations here...
    
    return result;
}

This is all what the-best-available-decompiler was able to infer from our automagically-obfuscated code

Not much if you ask me <wink />; figuring out what this function does - is very non-obvious to say the least (of course, it still does compute factorial, it is just that finding it out will take some hours - if not days). And the function-which-deals-with-our-exception (and which previously gave away the “Negative…” literal) now looks as follows:

//Listing 29.factorial.obf.sub_3.decompiled.c
_QWORD *__fastcall sub_3(_QWORD *a1, unsigned __int64 *a2)
{
unsigned __int64 *v2; // rbx
_QWORD *v3; // rdi
unsigned __int64 v4; // rdx
unsigned __int64 v5; // rcx
unsigned __int64 v6; // rdx
unsigned __int64 v7; // rax

v2 = a2;
v3 = a1;
*a1 = &off_140037FC0;
sub_6(a1 + 1);
v4 = v2[3];
if ( v4 >= 0x10 )
{
v5 = *v2;
v6 = v4 + 1;
if ( v6 >= 0x1000 )
{
if ( v6 + 39 <= v6 || v5 & 0x1F || (v7 = *(_QWORD *)(v5 - 8), v7 >= v5) || v5 - v7 - 8 > 0x1F )
sub_7();
v5 = *(_QWORD *)(v5 - 8);
}
sub_8(v5);
}
v2[2] = 0i64;
v2[3] = 15i64;
*(_BYTE *)v2 = 0;
return v3;
}

We can see no literal in plain sight anymore - which is certainly a Good Thing(tm)...

In addition, none of the code in our factorial() function is relatively-easily-detectable “dead code”: all the code can be executed (and the code along those branches which don’t raise exceptions, is executed during normal operation of the program).

Bottom line:

While it is not 100% incomprehensible (nothing is), we did manage to obtain a very poorly readable machine code out of our rather-readable source.

This means that using this type of obfuscation, we’re creating an asymmetry in our favour – while we’re taking relatively limited efforts on our side, we’re increasing the attacker’s efforts by orders of magnitude. This kind of asymmetrical efforts is exactly what-good-protection should do.

Ever-Changing Binary Code

But wait – we’re still not done with the benefits of ithare::obf. On each subsequent release build of our Client, we should use different ITHARE_OBF_SEED.⁶

Using this technique, for each Client release, we’ll generate different (but still functionally equivalent) obfuscation code; this, in turn, will make a large chunk of attacker’s-efforts-coming-from-previous-build, useless.⁷

Let’s compare two decompiles of the exactly same source code, but with different ITHARE_OBFUSCATION_SEEDs (screenshot from https://www.diffnow.com/):

Difference between two obfuscations generated from exactly the same source code

As we can see, obfuscated code on both sides uses the same principles, but the code itself is very different; this, in turn, means that for each new Client build at least a significant portion of reverse engineering efforts should be repeated.

Moreover,

If we manage to release new versions of our Client faster than attacker can reverse engineer our automagically-generated stuff – bingo! We won!⁸

Once again, what we’re trying to do here – is to create an asymmetry, when something-which-comes-to-us-for-free (namely, automagically generated different obfuscation for each build) causes significant trouble to the attacker.

⁵ currently – only 64-bit seeds are supported, but in the future, I hope to extend seeds to 128-bit ones.

⁶ Ideally – we should use crypto-strength random number as our ITHARE_OBF_SEED.

⁷ Among other things, techniques such as F.L.I.R.T. and F.L.A.R.E. are rendered useless for the seriously-obfuscated functions.

⁸ Well, we’ll also have to integrate our obfuscations into our Client-Server protocol, which can be not-so-trivial (but still doable), more on it in [[TODO]] section below.

Caveats

Of course, as any tool of this kind, there are certainly caveats (in addition to any bugs-due-to-such-complicated-library-being-pre-alpha).

Still Security-by-Obscurity

First, most importantly, all-the-information-attacker-needs, is still in the code <sad-face />; what we’re doing, is merely hiding things, which cannot be really secure. This means that as-a-way-to-protect-your-intellectual-property (~=”your offline program from being pirated”), this method still isn’t likely to work⁹ (not to mention that motivation for most of such protections is controversial).

Still, in the context of MOGs, IMNSHO there is considerable value in hiding things in the manner described above (especially if such obfuscation is applied consistently across lots of the code). In particular, as we noted above, if attackers cannot cope with the pace of our new releases – it means that we won’t have problem with bot fighters/cheaters anymore. Sure, at some point they will invent tools-which-can-automagically-deobfuscate-our-stuff, but first, it will take time, and second – after they do it, we’ll be in position to readjust (enabling us to go into arms race with the attackers, which is already a tremendous improvement over the current state of affairs); moreover – my gut feeling is that in this battle we do have an upper hand (just because the attacker has to solve an inverse problem compared to us solving forward problem, and solving inverse problems tends to be much more complicated than solving forward problems).

⁹ OTOH, if speaking about programs which go online at least occasionally – this technique can be used to make hacks much more difficult (how – is beyond the scope of this book, but a requirement for a program to go online will allow…)

Performance

As for performance – of course, convoluted obfuscated binary code does take its toll; that’s exactly why all the obfuscation primitives are supposed to mention maximum-number-of-CPU-cycles-we-can-spare. And of course, for 3D vertex-level code using any obfuscation is a fallacy.

On the other hand – it is well-known that 5% of code take 95% of CPU time (and conversely, 95% of code take only 5% of CPU time); this tends to stand for games too (in particular, script engines tend to be much less optimized than 3D graphics). As a result, our solution is rather obvious: let’s obfuscate non-performance-critical code.

Moreover,

It is non-performance-critical-code which tends to be of the most interest to the attackers(!)

Indeed, trying to extract usable information (such as “opponent is at 11 o’clock”) from vertex-level manipulations is a gargantuan task; it is usually much easier to get the opponent’s coordinates right after the network-packet-with-these-coordinates is parsed; however – as this parsing doesn’t happen too often, it can be obfuscated without causing too much of the performance penalty.

Let’s make a quick calculation. Our non-obfuscated factorial() function (when called to calculate factorial(20)), takes about 10ns of time. Our seriously-obfuscated version shown above, takes about 200ns – which is whopping 20x longer. However, let’s not be hasty to write it off on this “20x slower” basis. If we’re using some-function-obfuscated-in-a-similar-manner to parse our network packets – we’ll have to call it only once per network tick, i.e. 20 times per second; under these conditions – adding 200ns per network tick will take only 4 microseconds out of each second, or mere 0.0004%. In other words –

we can easily use as many as 10000 such-obfuscations-as-factorial()-above-uses per each network packet – and performance penalty will still be unnoticeable.

Sure, we DO need to be very careful about performance – but the division between “high-performance code” and “code in need for obfuscation” is there, so it is possible to exploit it.

Open Source Obfuscation is NOT an Oxymoron

how can we possibly both obfuscate things and make them 100% public at the same time?

At the first glance, saying “open source” and “obfuscation” in the same breath sounds as an oxymoron; how can we possibly both obfuscate things and make them 100% public at the same time? However, as soon as we say that we're using randomized code generation – it starts to make sense.

While ithare::obf itself is open-source (and therefore can be validated by lots of people(!)), ITHARE_OBF_SEED parameter which was used to compile each of the builds, is certainly intended to stay out of sight, so that the attacker won't know what exact obfuscation was generated for the executable he's dealing with. This, in turn, means that

It IS possible to have ALL the code open, just ITHARE_OBF_SEED private - and still enjoy some protection provided by obfuscation

In a sense - it is similar to having encryption algorithms completely public, with just their keys being secret; here - ithare::obf plus our obfuscated-source-code is our public algorithm, and ITHARE_OBF_SEED is our key.

In particular (as we’ll discuss in [[TODO]] section below) we can try to use similar obfuscation to obfuscate Client-2-Server protocols in a 100%-open-source game (just not publishing specific ITHARE_OBF_SEED used for building a specific Server+specific Clients). This, in turn, would allow anybody to compile and run their own Server+Client; it is just that ITHARE_OBF_SEED will be unknown for each such Server+Client pair - so while all such Servers+Client pairs are functionally the same (and play the same game) - protocols for each such pair will be different, with the automagically-generated obfuscation code providing non-trivial protection from cheaters and bots (and moreover, for each such Server+Client pair obfuscation will need to be broken separately).

In addition, even now ithare::obf has a modular structure, where it is rather easy to add your own primitives (and ithare::obf-with-your-own-primitives is no longer 100% open source, which may both provide additional protection and give you more peace of mind). In the future, I expect to provide an “official” way to expand ithare::obf with your-own-primitives without the need to modify its source code.

Summary on ithare::obf

To summarize our findings so far:

It is possible to have a code which is both rather readable in source, and pretty much unreadable in binary
- As a side benefit – it is possible to re-generate our binary code on each build at virtually zero cost for us, (while making the life of attackers much more complicated)
ithare::obf library is currently immature (and certainly NOT production-ready), but it does provide proof-of-concept implementation for these things
- Even current state-of-the-art IDA decompiler is no match for even-current rather-basic implementation of ithare::obf
It is still not a silver bullet – but can be used as a building block to build very serious protection from cheaters (in fact, most of anti-cheater protection techniques would benefit from this kind of randomized obfuscation code).
Performance-wise, we can do A LOT of obfuscation per network tick
Performance-wise, we can do A LOT of obfuscation per network tick
- And apparently, it is rather-performance-non-critical stuff which is the easiest to attack, so it is exactly the thing which we should obfuscate (alongside with any anti-cheating routines we want to have)
Open-source obfuscation is possible (as long as we keep seed out of sight); in a sense - it is about the same as having crypto-algorithm public, while keeping its key secret (with our ithare::obf directly corresponding to the crypto-algorithm, and our seed corresponding to the key).

[[To Be Continued...

This concludes beta Chapter 29(h) from the upcoming book "Development and Deployment of Multiplayer Online Games (from social games to MMOFPS, with social games in between)".

Stay tuned for Chapter 29(i), where we'll discuss issues related to protocol obfuscation (including versioning)]]

[rabbit_references]

[rabbit_ref id="NoBugs" name="C++ Code+Data Obfuscation Library with Build-Time Polymorphism" author="'No Bugs' Hare" url="https://github.com/ITHare/obf"]

[/rabbit_references]

6IT Hare

Tagged With: Overload

Single-Threading: Back to the Future?