Deobfuscating Arxan in Elden Ring

2026-09-19T12:13:38+05:30

Introduction</a></h1>
Maybe you, like me, wanted to debug a game that was (without knowing) protected by Arxan</a> a commercial anti-tamper suite. So naturally, you boot up the game, crack your knuckles, place a breakpoint on an address, and- wait it crashed. Strange, well.. anyways maybe it was a fluke, let's try this time with a hardware breakpoint- it crashed again. Ok, fine, let's see what's going on.
And quickly as an aside: your configuration of Arxan could be different in some ways depending on the game.

Decrypting</a></h1>
Okay, so one thing we noticed is that we crash when we place a hardware breakpoint. Thanks to Momo</a> we have an idea of how we should attack this. Can we just set breakpoint on GetThreadContext</code>? Yeah, works like a charm. We continue until the function returns. This seems like a good point to stop and load this up into IDA to see how this anti-debug routine works. We load it into IDA, rebase, go to the return address, and wait?.. it's just a bunch of random bytes.
.text:00007FF75B7EA7F2 dd 7FA51FC9h .text:00007FF75B7EA7F6 db 71h .text:00007FF75B7EA7F7 db 0E4h .text:00007FF75B7EA7F8 dq 9A4230B6ADF4714Ah .text:00007FF75B7EA800 db 95h, 0F2h, 30h, 0D2h, 89h .text:00007FF75B7EA805 dq 2FA49E50931EEE54h .text:00007FF75B7EA80D db 38h, 0D3h, 10h</code></pre>
Yeah, so part of Arxan's suite is the ability to keep some functions encrypted while they're not in use, but once invoked will decrypt then re-encrypt afterwards, so even if you dumped the game at runtime these protected functions will still be encrypted. Unfortunately before we can actually get to the deobfuscation part, we'll need to decrypt these routines. I'll show the process briefly, but this has been extensively documented in the me3 blog</a>, which resulted in dearxan</a>. So, let's do that, but before we start: Arxan has 'hooked' the __security_init_cookie</code> procedure that is ran immediately after the entry point so that it runs some code that makes the .text</code> section RWX among other things.
Stubs</a></h2> When Arxan obfuscates a routine it creates its own stub that saves the context onto the stack and makes sure the stack is aligned, it looks like this (without obfuscation): 52 push rdx 41 51 push r9 41 50 push r8 41 52 push r10 51 push rcx 50 push rax 53 push rbx 41 53 push r11 48 8D 64 24 A0 lea rsp, [rsp-60h] 66 0F 11 1C 24 movupd [rsp+0A0h+var_A0], xmm3 66 0F 11 54 24 10 movupd [rsp+0A0h+var_90], xmm2 66 0F 11 4C 24 20 movupd [rsp+0A0h+var_80], xmm1 66 0F 11 44 24 30 movupd [rsp+0A0h+var_70], xmm0 66 0F 11 64 24 40 movupd [rsp+0A0h+var_60], xmm4 66 0F 11 6C 24 50 movupd [rsp+0A0h+var_50], xmm5 6A 10 push 10h 48 F7 C4 0F 00 00 00 test rsp, 0Fh 0F 85 BE DB 3C FE jnz loc_7FF756096EE4 E9 8A 49 3C FE jmp loc_7FF75608DCB5 loc_7FF75608DCB5: 6A 18 push 18h E9 28 92 00 00 jmp loc_7FF756096EE4</code></pre> Then it proceeds to call into the actual target routine, and of course when that routine returns it restores the registers and continues. This is important to note because, again, all obfuscated functions are called from a stub, and having the entry point of the obfuscated function is necessary for deobfuscation, more on that in the next section. Nevertheless, to decrypt protected functions we need to find specific stubs that lead to the decryption of those functions. In essence the steps to finding those functions are: find every stub, we can look for test rsp, 0Fh</code>, which works for both obfuscated and unobfuscated stubs, then emulate the stub, then pattern match, once matched log where and what it's decrypting, profit. With that being said, by using a modified version of their library</a> translated to python, I'm able to decrypt most of the binary statically in IDA, which is important for our next step. Alternatively you can try arxan-static-patcher</a> out. While I haven't tried it personally it's a wrapper over dearxan and should accomplish our goals. Deobfuscation</a></h1> Alright, now equipped with a decrypted binary, let's talk about how it's obfuscated. Now, we can go back to the return address of the GetThreadContext</code> call, but that would be in the middle of the obfuscated routine, and like I mentioned earlier we can't actually recover the full routine from a random starting point in the function, I'll explain further in a second. Another thing to note is that if you actually go to the address in IDA you'll notice that it's just a single basic block, and.. uh.. where is the call to GetThreadContext</code> exactly? returned_after_getthreadcontext proc near var_18= qword ptr -18h var_10= qword ptr -10h var_8= qword ptr -8 mov rax, [rbp+48h] test rax, rax mov [rsp+var_8], rsi lea rsp, [rsp-8] mov rsi, offset sub_7FF75B839E83 xchg rsi, [rsp+8+var_8] mov [rsp+8+var_10], rax lea rsp, [rsp-8] mov [rsp+10h+var_18], rcx lea rsp, [rsp-8] mov rax, [rsp+18h+var_8] mov rcx, offset sub_7FF75B19490A cmovnz rax, rcx mov [rsp+18h+var_8], rax lea rsp, [rsp+8] mov rcx, [rsp+10h+var_18] lea rsp, [rsp+8] mov rax, [rsp+8+var_10] lea rsp, [rsp+8] jmp [rsp+var_8]</code></pre> So to figure out what's going on here let's begin from the start of the stub that calls into this routine. We can do this by cross-referencing returned_after_getthreadcontext</code> and its referrer, and cross referencing the referrer's referrer, so on and so forth until we get to the stub, you can, of course, automate this with a script and have it print the path. Now that we're here let's actually go inside of the call to the obfuscated routine and talk about how we can start recovering the original CFG. Recovering the CFG</a></h2> So the way that Arxan works is that, it will obfuscate the instructions in every basic block of a routine, and its control flow. The basic blocks of said routine are scattered throughout the binary. Because of this, the initial appearance of a seemingly normal block of code looks like a procedure to IDA, and will erroneously auto-analyze as one. Now let's start with the first block of the routine and figure out how we can find its successor. When it comes to obfuscated stubs it's important to realize that they don't start off with the context saving, they start off with a few initial blocks first. This in combination with the fact that all basic blocks are scattered is the reason why we need to start from the top of the stub in order to recover the whole function. So let's look at the first block see how we can get the successor and then I'll explain what's going on. 48 89 54 24 F8 mov [rsp+var_8], rdx 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8D 15 7B B0 6F FB lea rdx, loc_7FF7568869A6 48 89 44 24 F8 mov [rsp+8+var_10], rax 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8B 44 24 08 mov rax, [rsp+10h+var_8] 48 89 54 24 08 mov [rsp+10h+var_8], rdx 48 89 C2 mov rdx, rax 48 8B 04 24 mov rax, [rsp+10h+var_10] 48 8D 64 24 08 lea rsp, [rsp+8] 41 53 push r11 4C 8D 1D DD A8 59 00 lea r11, sub_7FF75B726231 50 push rax 48 8B 44 24 08 mov rax, [rsp+18h+var_10] 4C 89 5C 24 08 mov [rsp+18h+var_10], r11 49 89 C3 mov r11, rax 58 pop rax C3 retn</code></pre> So this is the first block in the stub. Let's trace through the instructions 48 89 54 24 F8 mov [rsp+var_8], rdx 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8D 15 7B B0 6F FB lea rdx, loc_7FF7568869A6 48 89 44 24 F8 mov [rsp+8+var_10], rax 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8B 44 24 08 mov rax, [rsp+10h+var_8] 48 89 54 24 08 mov [rsp+10h+var_8], rdx 48 89 C2 mov rdx, rax 48 8B 04 24 mov rax, [rsp+10h+var_10] 48 8D 64 24 08 lea rsp, [rsp+8]</code></pre> so ultimately all this does, is it carefully uses rdx</code> and rax</code> to put 0x7FF7568869A6</code> on the stack, at rsp-8, often this does nothing and is never used, however, sometimes it's a continuation address. More on that later. 41 53 push r11 4C 8D 1D DD A8 59 00 lea r11, sub_7FF75B726231 50 push rax 48 8B 44 24 08 mov rax, [rsp+18h+var_10] 4C 89 5C 24 08 mov [rsp+18h+var_10], r11 49 89 C3 mov r11, rax 58 pop rax C3 retn</code></pre> Now, and this is important for us, this actually dispatches to the successor. What this does is the same thing we've seen before, but this time it puts 0x7FF75B726231</code> at [rsp]</code> and then returns, popping that successor block into rip</code>. With this knowledge acquired we can now recover unconditional jumps, and we'll use the "find the last address in the block" heuristic for the recovery. That's the general pattern for unconditional jumps, it does some computation at the start of the block, and at the end of the block it computes the next target using a mechanism like how we just saw. There are some variations too, and some exceptions that we will cover later. Now we can keep using this method to traverse the graph further down until we meet our first conditional jump (note: generally things aren't very eventful until the context save block that you're about to see, however, sometimes it will place a continuation address on the stack, more on that later). Let's continue on! 4C 89 44 24 F8 mov [rsp+var_8], r8 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 14 24 mov [rsp+10h+var_10], rdx 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 1C 24 mov [rsp+18h+var_18], rbx 48 89 4C 24 F8 mov [rsp+18h+var_20], rcx 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8D 64 24 F8 lea rsp, [rsp-8] 4C 89 1C 24 mov [rsp+28h+var_28], r11 48 8D 64 24 F8 lea rsp, [rsp-8] 4C 89 0C 24 mov [rsp+30h+var_30], r9 48 89 44 24 F8 mov [rsp+30h+var_38], rax 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8D 64 24 F8 lea rsp, [rsp-8] 4C 89 14 24 mov [rsp+40h+var_40], r10 48 8D 64 24 A0 lea rsp, [rsp-60h] 66 0F 11 1C 24 movupd [rsp+0A0h+var_A0], xmm3 66 0F 11 44 24 10 movupd [rsp+0A0h+var_90], xmm0 66 0F 11 4C 24 20 movupd [rsp+0A0h+var_80], xmm1 66 0F 11 6C 24 30 movupd [rsp+0A0h+var_70], xmm5 66 0F 11 64 24 40 movupd [rsp+0A0h+var_60], xmm4 66 0F 11 54 24 50 movupd [rsp+0A0h+var_50], xmm2 6A 10 push 10h 48 F7 C4 0F 00 00 00 test rsp, 0Fh 4C 89 6C 24 F8 mov [rsp+0A8h+var_B0], r13 48 8D 64 24 F8 lea rsp, [rsp-8] 49 BD 79 7C 28 56 F7 7F 00 00 mov r13, offset sub_7FF756287C79 4C 87 2C 24 xchg r13, [rsp+0B0h+var_B0] 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 04 24 mov [rsp+0B8h+var_B8], rax 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 0C 24 mov [rsp+0C0h+var_C0], rcx 48 8B 44 24 10 mov rax, [rsp+0C0h+var_B0] 48 B9 54 D9 33 56 F7 7F 00 00 mov rcx, offset sub_7FF75633D954 48 0F 45 C1 cmovnz rax, rcx 48 89 44 24 10 mov [rsp+0C0h+var_B0], rax 48 8B 0C 24 mov rcx, [rsp+0C0h+var_C0] 48 8D 64 24 08 lea rsp, [rsp+8] 48 8B 04 24 mov rax, [rsp+0B8h+var_B8] 48 8D 64 24 08 lea rsp, [rsp+8] 48 8D 64 24 08 lea rsp, [rsp+8] FF 64 24 F8 jmp [rsp+0A8h+var_B0]</code></pre> So finally we get to here, and it should look a little familiar, it's the exact same template from before where it saves the cpu context onto the stack, the only difference of course being that this is the obfuscated form. But what we care about is the ending of this block. 48 F7 C4 0F 00 00 00 test rsp, 0Fh 4C 89 6C 24 F8 mov [rsp+0A8h+var_B0], r13 48 8D 64 24 F8 lea rsp, [rsp-8] 49 BD 79 7C 28 56 F7 7F 00 00 mov r13, offset sub_7FF756287C79 4C 87 2C 24 xchg r13, [rsp+0B0h+var_B0] 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 04 24 mov [rsp+0B8h+var_B8], rax 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 0C 24 mov [rsp+0C0h+var_C0], rcx 48 8B 44 24 10 mov rax, [rsp+0C0h+var_B0] 48 B9 54 D9 33 56 F7 7F 00 00 mov rcx, offset sub_7FF75633D954 48 0F 45 C1 cmovnz rax, rcx 48 89 44 24 10 mov [rsp+0C0h+var_B0], rax 48 8B 0C 24 mov rcx, [rsp+0C0h+var_C0] 48 8D 64 24 08 lea rsp, [rsp+8] 48 8B 04 24 mov rax, [rsp+0B8h+var_B8] 48 8D 64 24 08 lea rsp, [rsp+8] 48 8D 64 24 08 lea rsp, [rsp+8] FF 64 24 F8 jmp [rsp+0A8h+var_B0]</code></pre> This is of course a variation of the obfuscation we've been seeing except this time we have a conditional mov</code>, which is predicated on the test</code> in the first line, notice how nothing inbetween the test and the cmov</code> alter the cpu flags. So we can manually trace and see that it's conditionally moving 0x7FF756287C79</code> or 7FF75633D954</code> into a stack slot , and then it jumps to that target at the end of the block. So the heuristic we use is simply if we have a basic block that has a cmov</code> then we take the last two immediates and set those as the successors. def find_possible_targets(instructions): out = [] for instruction in instructions: v = None if instruction.mnemonic in (iced.Mnemonic.LEA, iced.Mnemonic.MOV): if is_rip_relative(instruction, 1): # here we match, for example: lea r12, loc_7FF7582A368C. if instruction.mnemonic == iced.Mnemonic.LEA: v = instruction.memory_displacement # we match, for example: mov rcx, offset sub_7FF75B235B57 elif instruction.op1_kind in (iced.OpKind.IMMEDIATE64, iced.OpKind.IMMEDIATE32, iced.OpKind.IMMEDIATE32TO64): v = instruction.immediate(1) # we want to make sure that the actually leads to code. if v and is_executable(v): out.append(v) return out if get_last_cmov_condition(instructions) and len(candidates) >= 2: # get the last two candidates from the list of possible targets. succs = remove_duplicates([candidates[-1], candidates[-2]])</code></pre> The final thing we have to look out for is a call to a function. Let's continue until we find the call to GetCurrentThread</code> C7 45 30 10 00 10 00 mov dword ptr [rbp+30h], 100010h 48 8B 05 50 A0 C4 FF mov rax, cs:GetCurrentThread 48 8D 64 24 F8 lea rsp, [rsp-8] 4C 89 2C 24 mov [rsp+8+var_8], r13 4C 8D 2D D2 E6 66 00 lea r13, sub_7FF75B520C86 FF 34 24 push [rsp+8+var_8] 4C 89 6C 24 08 mov [rsp+10h+var_8], r13 4C 8B 2C 24 mov r13, [rsp+10h+var_10] 48 8D 64 24 08 lea rsp, [rsp+8] 50 push rax C3 retn</code></pre> Now this is the general template for all calls to functions. This is the usual push-ret thing that we've seen before, except the minor difference with this one being that it pushes the return address first and then the address of the target function. Where rax</code> contains the successor which is the target function and the return address, 0x7FF75B520C86</code>, which is placed right below it. Naturally when the called function returns from execution it will pop the return address placed here into rip</code>. So our heuristic for this is we look for a push <register></code> followed by a ret</code> if we find that we look what was last moved into the pushed register for the successor, and we just look for the last immediate for the return address. def recover_call(instructions): if len(instructions) < 2: return term = instructions[-1] # the block always ends with a ret. if term.flow_control != iced.FlowControl.RETURN: return None prev = instructions[-2] # the penultimate instruction always, at least as far as I'm aware, is a push. if prev.mnemonic != iced.Mnemonic.PUSH or prev.op0_kind != iced.OpKind.REGISTER: return None # save the register that holds the call target. push_reg = prev.op0_register call_target = None return_address = None for instruction in instructions: # grab the instruction that moves the call target into the pushed register. if instruction.mnemonic == iced.Mnemonic.MOV and instruction.op0_kind == iced.OpKind.REGISTER and instruction.op0_register == push_reg and is_rip_relative(instruction, 1): slot = instruction.memory_displacement if is_iat_slot(slot): call_target = slot else: # sometimes it's a pointer to the function. ptr = ida_bytes.get_qword(slot) if is_executable(ptr): call_target = ptr elif is_executable(slot): call_target = slot # grab the instruction that moves the return address into a register. if instruction.mnemonic == iced.Mnemonic.LEA and is_rip_relative(instruction, 1): pret = instruction.memory_displacement if is_executable(pret): return_address = pret if call_target and return_address: return (call_target, return_address) return None</code></pre> and also something to mention is because of the way Arxan obfuscates code it doesn't really have a normal fall-through edge, so when we represent basic blocks we don't stop collecting instructions for a block if the branching instruction is a conditional jump, we do it when it's an unconditional jump or a ret, etc. ... jnz <addr> jmp <addr></code></pre> for example. Now that we understand the gist of how Arxan calculates successor blocks (there is still something we need to touch on soon), let's actually try to write a script that will recover the CFG of the function. First attempt</a></h2> What I tried at first was to use IDA's microcode to figure out what the possible successors were. Let me show you the idea with a conditional block. So take this block for example: 48 8B 45 48 mov rax, [rbp+48h] 48 85 C0 test rax, rax 48 8D 64 24 F8 lea rsp, [rsp-8] 4C 89 24 24 mov [rsp+8+var_8], r12 49 BC 93 72 85 5B F7 7F 00 00 mov r12, offset sub_7FF75B857293 48 89 44 24 F8 mov [rsp+8+var_10], rax 48 8D 64 24 F8 lea rsp, [rsp-8] 48 8B 44 24 08 mov rax, [rsp+10h+var_8] 4C 89 64 24 08 mov [rsp+10h+var_8], r12 49 89 C4 mov r12, rax 48 8B 04 24 mov rax, [rsp+10h+var_10] 48 8D 64 24 08 lea rsp, [rsp+8] 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 0C 24 mov [rsp+10h+var_10], rcx 48 8D 64 24 F8 lea rsp, [rsp-8] 48 89 14 24 mov [rsp+18h+var_18], rdx 48 8B 4C 24 10 mov rcx, [rsp+18h+var_8] 48 BA 3F 87 65 5B F7 7F 00 00 mov rdx, offset sub_7FF75B65873F 48 0F 45 CA cmovnz rcx, rdx 48 89 4C 24 10 mov [rsp+18h+var_8], rcx 48 8B 14 24 mov rdx, [rsp+18h+var_18] 48 8D 64 24 08 lea rsp, [rsp+8] 48 8B 0C 24 mov rcx, [rsp+10h+var_10] 48 8D 64 24 08 lea rsp, [rsp+8] 48 8D 64 24 08 lea rsp, [rsp+8] FF 64 24 F8 jmp [rsp+var_8]</code></pre> alright, cool. Now, let's look at the microcode (MMAT_LVARS): 1.BLT_2WAY 1. 1 7FF75AFD34F4 mov &($sub_7FF75B857293{1}).8, rcx1.8 2. 2 7FF75AFD3503 jz [ss.2{2}:(rbp0.8+#0x48.8){3}].8, #0.8, @3 2.BLT_1WAY 2. 1 7FF75AFD3503 mov &($sub_7FF75B65873F).8, rcx1.8 3.BLT_1WAY 3. 1 7FF75AFD3523 mov icall cs.2,rcx1.8<fast:_QWORD rcx0.8,_QWORD rdx0.8> => __int64 .8, result.8</code></pre> it's way easier to see what's going on here, and on top now we have 3 blocks in the graph. So if we go to the last block here, and we see what register we're calling, we can know what value that register will be depending on which block we came from. This works pretty well, but unfortunately Arxan does many things that will just break the decompiler, or make it so that there are too many variations in the microcode to generically handle this, by using xchg</code>s instead for example, etc. I even tried using different maturities of the microcode for different things, depending on the block, but it was all just too finicky. Man, if only there were another way that was even simpler... Solution</a></h2> I mentioned shortly what I do when describing the obfuscation, and yeah, for most blocks we just use simple heuristics and it seems to work fine. there are cases where they don't work though, for example if we only use our simple heuristics we can build the CFG all the way up until this point, for example: In this last block there's nothing left to glean. That's of course because the jump target was placed on the stack further up the CFG: According to our simple static heuristics there's nothing we can do here, we're going to need more. There're quite a few ways to solve this, e.g. using something sophisticated like Pushan</a>'s CFG recovery method, or what have you. But for us simply emulating from the entry point to the "unresolved" block, executing its terminator and seeing where RIP is does the trick. Now, once we combine both these together, we have decently quick and complete CFG recovery. Awesome, and with this alone we can achieve a pretty legible decompilation, so long as we of course fix the terminators of each block to be direct targets, and add call</code> instructions to the 'call' blocks. Here's an example from the decompilation: // ... v13 = __readeflags(); if ( (v13 & 0x100) == 0 && !NtCurrentPeb()->BeingDebugged ) { v22.ContextFlags = 0x100010; CurrentThread = GetCurrentThread(); GetThreadContext(CurrentThread, &v22); if ( !v22.Dr0 && !v22.Dr1 && !v22.Dr2 && !v22.Dr3 ) { // ... } }</code></pre> Though you'll notice scattered throughout the decompilation it will have things like: v36 = a4; v35 = a1; v34 = sub_7FF75B5D458D; v33 = v6; v32 = v7; v31 = a3; v29[1] = 0x7FF7560011F9LL; v8 = v30; v9 = sub_7FF756037B44;</code></pre> variables assigned which are never read, that's just because of the same stack nonsense we've seen before where Arxan will put something on to the stack like a continuation address but in order to do this it uses registers which it stores on to the stack, but in order to preserve them it does the whole song and dance of putting them somewhere for a second and then restoring them later. The Stack</a></h2> Arxan abuses rsp</code> in its obfuscation, like we've seen before rsp</code> is used for various different things like pushing continuation blocks, in some instances fake continuation blocks, frequently changed mid block, etc. From what I've seen variables are pretty much exclusively referenced through rbp</code>, for example when we call a windows function we pass out</code> parameters relative to rbp</code> rather than rsp</code>. Case study on some anti-debug routines</a></h3> Now that we've created our deobfuscator we can finally investigate what we set out to: let's see what made us crash, then we'll go over a couple other detections. __int64 (__fastcall *__fastcall func1(__int64 a1, __int64 a2))() { __int64 v2; // rbp __int64 v3; // rdi __int64 v4; // r10 __int64 (__fastcall *result)(); // rax __int16 v6; // kr00_2 __int64 v7; // rbp bool v8; // zf __int64 v9; // rax bool not_being_debugged; // zf DWORD64 P1Home; // rcx int v12; // ecx int v13; // eax __int64 (__fastcall *v14)(); // rcx __int64 v15; // rdx __int64 v16; // rcx __int64 (__fastcall *v17)(); // [rsp-598h] [rbp-BA8h] struct _CONTEXT thread_context; // [rsp-560h] [rbp-B70h] BYREF char *v19; // [rsp-88h] [rbp-698h] _QWORD *v20; // [rsp-80h] [rbp-690h] HANDLE CurrentThread; // [rsp-78h] [rbp-688h] BOOL v22; // [rsp-6Ch] [rbp-67Ch] __int64 v23; // [rsp-60h] [rbp-670h] __int64 v24; // [rsp-58h] [rbp-668h] __int64 (__fastcall *v25)(); // [rsp-50h] [rbp-660h] BYREF _QWORD v26[19]; // [rsp-48h] [rbp-658h] BYREF __int64 v27; // [rsp+50h] [rbp-5C0h] __int64 (__fastcall *v28)(); // [rsp+58h] [rbp-5B8h] __int64 v29; // [rsp+60h] [rbp-5B0h] __int64 v30; // [rsp+68h] [rbp-5A8h] __int64 v31; // [rsp+80h] [rbp-590h] __int64 v32; // [rsp+5E8h] [rbp-28h] v27 = v4; v28 = sub_7FF75BAD9EF6; v26[18] = &loc_7FF758176924; result = sub_7FF75B4761E9; v26[17] = a1; v26[16] = &loc_7FF756D81948; v26[15] = sub_7FF75B46A729; v26[14] = sub_7FF75B4761E9; v26[13] = a2; v26[11] = v3; v26[12] = sub_7FF75B4E30DB; v25 = sub_7FF75B4E30DB; if ( ((unsigned __int64)v26 & 0xF) != 0 ) { v24 = a1; v23 = v2; v25 = (__int64 (__fastcall *)())&sub_7FF75ACA9F5D; v19 = (char *)sub_7FF75B895D6E - *(unsigned int *)sub_7FF75604B848; v17 = sub_7FF75B895D6E; v22 = v26[0] == 24; v20 = &v26[(v26[0] == 24) - 1]; v20[23] = *(_QWORD *)sub_7FF756781EE8; // check trap flag. v6 = __readeflags(); if ( (v6 & 0x100) != 0 ) goto LABEL_3; not_being_debugged = NtCurrentPeb()->BeingDebugged == 0; P1Home = thread_context.P1Home; if ( !not_being_debugged ) P1Home = 0x7FF75B19490ALL; thread_context.P1Home = P1Home; if ( !not_being_debugged || (thread_context.ContextFlags = 0x100010, CurrentThread = GetCurrentThread(), GetThreadContext(CurrentThread, &thread_context), LODWORD(v17) = v12, thread_context.Dr0) || thread_context.Dr1 || thread_context.Dr2 || thread_context.Dr3 || (v20[22] = *(_QWORD *)sub_7FF756200098, (NtCurrentPeb()->NtGlobalFlag & 0x70) == 0x70) ) { LABEL_3: v20[22] = *(_QWORD *)sub_7FF756200098; thread_context.P1Home = (DWORD64)&v25; report((unsigned int)v17); v7 = v29; *(_DWORD *)(v29 + 1264) = 0; v8 = *(_DWORD *)(v7 + 1264) == 0; v9 = v31; if ( *(_DWORD *)(v7 + 1264) ) v9 = 0x7FF756AE7584LL; v31 = v9; if ( !v8 ) return (__int64 (__fastcall *)())v32; v30 = v9; } else { benign_report(*(unsigned int *)sub_7FF7561297A8); v7 = (__int64)v28; *((_DWORD *)v28 + 308) = 0; v13 = *(_DWORD *)(v7 + 1232); v29 = 0x7FF75B06AA61LL; v28 = v14; v27 = v15; v16 = 0x7FF75B06AA61LL; if ( !v13 ) v16 = 0x7FF75B69A753LL; v29 = v16; if ( v13 ) return (__int64 (__fastcall *)())v32; } *(_DWORD *)word_7FF756409A2A = *(_DWORD *)sub_7FF755F78F9A; *(_QWORD *)(*(_QWORD *)(v7 + 1248) + 8LL * *(_QWORD *)sub_7FF7562553B8) = unk_7FF7564AB10F; return (__int64 (__fastcall *)())v32; } return result; }</code></pre> There is a lot of nonsense like we've mentioned earlier and it's possible to clean this up automatically if you lift and optimize™, after we recover the CFG, and do some fixups of course, but for the sake of this article I don't believe it's necessary. Anyways, manually cleaning it up results in: __int64 (__fastcall *__fastcall func1(__int64 a1, __int64 a2))() { // ... // check trap flag. v6 = __readeflags(); if ( (v6 & 0x100) != 0 ) goto LABEL_3; not_being_debugged = NtCurrentPeb()->BeingDebugged == 0; thread_context.ContextFlags = 0x100010; CurrentThread = GetCurrentThread(); GetThreadContext(CurrentThread, &thread_context); if ( !not_being_debugged || thread_context.Dr0 || thread_context.Dr1 || thread_context.Dr2 || thread_context.Dr3 || (NtCurrentPeb()->NtGlobalFlag & 0x70) == 0x70 ) { LABEL_3: // this will actually report with code 12. report((unsigned int)v17); v7 = v29; v8 = *(_DWORD *)(v7 + 1264) == 0; if ( !v8 ) return (__int64 (__fastcall *)())v32; } else { // this doesn't do a "real" report, it calls the function with code 8. benign_report(*(unsigned int *)sub_7FF7561297A8); v7 = (__int64)v28; v13 = *(_DWORD *)(v7 + 1232); if ( v13 ) return (__int64 (__fastcall *)())v32; } // ... return (__int64 (__fastcall *)())v32; }</code></pre> There are a few things we can see immediately. This seems like only really an anti-debug routine, it doesn't seem to do anything more than just check if we're running a debugger. As for the detections, we can see in this routine they check the trap flag</a>, Peb()->BeingDebugged</code>, Peb()->NtGlobalFlag</code> which will be non-zero</a> if the process was created with a debugger, and if any of the debug registers set (to check for hardware breakpoints). While the routine we're looking at here is pretty barebones, the same pattern can be found in other more complex routines. In another anti-debug routine we can see this, deobfuscated: // ... dword_7FF7564D91ED = 0; handle = AddVectoredExceptionHandler(1u, sub_7FF75AE050BD); CloseHandle((HANDLE)0xDE42345); RemoveVectoredExceptionHandler(handle); v37 = RemoveVectoredExceptionHandler(handle); if ( !v37 && *(_DWORD *)dword_7FF7560947EA != 0x847FEF39 ) { // non-detected path. } report(/* ... */) // ...</code></pre> We can see that it registers an exception handler, then immediately closes handle value which will always be invalid (which it must be for this to work), you see normally this would only return a 0</code> if the handle is invalid and there's no debugger, however, if there's a debugger running it will actually invoke the exception handler with the exception code 0xC0000008</code>, going to the handler at sub_7FF75AE050BD</code>, which is also obfuscated so here's the deobfuscation: __int64 __fastcall handler(_EXCEPTION_POINTERS *a1) { void *v1; // rbp _UNKNOWN *retaddr; // [rsp+38h] [rbp+0h] retaddr = v1; if ( a1->ContextRecord->Dr0 || a1->ContextRecord->Dr1 || a1->ContextRecord->Dr2 || a1->ContextRecord->Dr3 ) { dword_7FF7564D91ED = 0xB8F243D7; return 0xFFFFFFFFLL; } else if ( a1->ExceptionRecord->ExceptionCode == 0xC0000008 ) { dword_7FF7564D91ED = 0xB8F243D7; return 0xFFFFFFFFLL; } else { return 0; } }</code></pre> Aha! Okay now if we go back to the routine that sets the handler: if ( !v37 && *(_DWORD *)dword_7FF7560947EA != 0x847FEF39 )</code></pre> The decompilation for this is a little misleading, really it's just comparing the values of two dwords together, dword_7FF7560947EA</code> and dword_7FF7564D91ED</code>. 8B 05 88 5B 7D FA mov eax, cs:dword_7FF7564D91ED 8B 15 7F 11 39 FA mov edx, dword ptr cs:dword_7FF7560947EA 3B C2 cmp eax, edx</code></pre> The thing is, is that dword_7FF7560947EA</code> is set to 0xB8F243D7</code> by default and dword_7FF7564D91ED</code> is set to 0x847FEF39</code> by default (which is why IDA shows that value in the decompilation) but is set to 0 earlier on in the function. We can see that if it goes through the handler it will set dword_7FF7564D91ED</code> to the same value making the predicate return false and continuing down the detected path. And, for fun let's go over one more: memset(&heap_entry, 0, sizeof(heap_entry)); ProcessHeap = GetProcessHeap(); handle = ProcessHeap; if ( HeapLock(ProcessHeap) ) { while ( 1 ) { if ( !HeapWalk(handle, &heap_entry) ) { HeapUnlock(handle); goto exit; } if ( heap_entry.wFlags == 4 ) break; } v16 = HeapUnlock(handle); if ( !v16 ) goto exit; if ( *(_DWORD *)((char *)heap_entry.lpData + heap_entry.cbData) == 0xABABABAB ) { goto detected; } // remember, not an actual "real" report. benign_report(*(unsigned int *)sub_7FF756793758); // ... } exit: *(_DWORD *)v9 = 0; return v9; } </code></pre> This is another classic</a> anti-debug check. One more thing to note is that a lot of these checks from as far as I can trace back seem to be on a timer, set with a random interval, one example: if ( *(float *)&timer <= 0.0 ) { decrypt_stuff(&v6); // ... anti_debug_check_stuff(); // ... *(float *)&timer = *(float *)&timer + random_range(v5, 30.0, COERCE_DOUBLE(0x42700000)).m128_f32[0]; }</code></pre>Conclusion</a></h1> The source code for the deobfuscator is here</a>. Admittedly, the obfuscation itself was a lot more interesting than the anti-debug. There are still other checks that it performs, but the focus really is on the deobfuscation. Anyways, this is the end of the blog, I hope you enjoyed reading it, because I had a lot of fun on this project. There's still a lot more that can be done and I'm looking forward to improving whatever I can, when I get the chance. If that happens I'll be writing a part II! Goodbye!

Polymorphic

Deobfuscating Arxan in Elden Ring