Guide SCP: SL Anti-Cheat Analysis — Reversing SLAC & HWID Spoofing

[byte_corvus]

Anyone else bored enough to look at SLAC (SCP: Secret Laboratory Anti-Cheat) lately? It is basically a Themida wrapper with some of the most primitive logic I have seen in a while. If you are digging into the binaries, here is the technical breakdown of how they handle (or fail to handle) security.

Binaries involved:

1. SCP-SL.exe — The main game executable. Handles auth and initial HWID gathering.
2. SLAC.dll — The heart of the anti-cheat. Packed with Themida, but they left RTTI in, making reversing a breeze.

The Flaws

1. RTTI and Primitive Detections
Despite being virtualized, the RTTI is present. You can easily map out their detections in IDA. They are using basic WinAPI for signature scans and kernel pool tags — no inlined syscalls or Nt-level stealth here.

2. VTable Design
Every detection routine uses a VTable, but Themida is not checking their integrity. Since the VTable layout is identical across all detections (using a pure virtual base class), hooking them is trivial.

3. The Curl Bypass
This is the funniest part. Their backend communication (

You cant view this link please login.

) has certificate verification OFF. If you redirect traffic to a local script returning a 200 OK status, the AC thinks everything is fine.

Communication & Encryption

They use OpenSSL (AES256CBC) for backend JSON data. You can find the keys by hooking EVP_EncryptInit_Ex or just enabling their debug mode by creating a file at %APPDATA%/SCP Secret Laboratory/slac_debug.txt.

std::string key_hex = "e43f7ba2b97ee287e63e14f5cc567fea70cc841f751bc54dd2d41ab8f4c1cbdf";
std::string iv_hex = "5810706fa51b2663db8b17768f92e4a4";

HWID & Shuffling Algorithm

SCP:SL gathers quite a bit of data: Steam tickets, product keys, MAC addresses, Disk serials, and even your processor string. However, they use a custom xor-to-byte (key 0xAD) and a shuffling algorithm to hide the strings in the packets.

Spoiler: Unshuffle Logic

std::vector<int> generateSequence(int n)
{
    std::vector<int> seq;
    if (n <= 7) { for (int i = 0; i < n; i++) seq.push_back(i); return seq; }
    int m = (n - 1) / 7;
    int primary = m + 1, secondary = m;
    int countPrimary = n - 7 * m;
    std::vector<bool> used(n, false);
    for (int s = 0; s < n; s++)
    {
        if (used[s]) continue;
        int x = s; seq.push_back(x); used[x] = true;
        for (int j = 0;; j++)
        {
            int candidate = x + (j < countPrimary ? primary : secondary);
            if (candidate >= n || used[candidate]) break;
            x = candidate; seq.push_back(x); used[x] = true;
        }
    }
    return seq;
}

Bypassing Integrity Checks

Themida handles their anti-debug and integrity, but since they do not use inlined syscalls, you can restore debugging with standard NT hooks. To bypass the game's integrity check, you can use a naked hook to point the source to a shadow copy:

__attribute__((naked))
void hkInteg() // 0x14072052B
{
 __asm
 {
  push rbp
  mov rbp, rsp
  push rsi
  push rdi
  push rcx
  mov rsi, [rbp + 18h]
  mov rsi, shadow_copy // Redirect to clean copy
  mov rdi, [rbp + 10h]
  mov ecx, [rbp + 20h]
  rep movsb
  mov rsi, [rbp + 18h]
  add rsi, [rbp + 20h]
  pop rcx
  pop rdi
  pop rsi
  leave
  retn 18H
 }
}

Essentially, the AC is extremely weak against external manipulation and emulation. They rely almost entirely on Themida's default protection without any custom hardening.

anyone else digging into their backend lately?