이해의 비용: LLM 기반 리버스 엔지니어링 대 반복적 LLM 난독화

서문

지난 몇 년 동안 저희는 프로그램 합성, 멀웨어 연구, 취약점 연구 등 실제 문제를 해결하는 다양한 작업을 생산적으로 수행할 수 있는 LLM의 역량이 크게 발전하는 것을 목격했습니다. 특히 리버스 엔지니어링의 맥락에서 LLM은 심볼 없이도 소스 코드를 읽는 데 매우 능숙하기 때문에 적절한 도구만 있으면 특히 효과적입니다. 뿐만 아니라, 지식 덕분에 역발상적인 방법론을 모방하고 적용할 수 있습니다.

프로그램 난독화 방법은 프로그램에 변환을 적용하는 데 필요한 시간과 리버스 엔지니어링에 필요한 시간 사이에 상당한 비대칭을 만들어 리버스 엔지니어링을 비교적 효과적으로 방어하고 연구자들이 시간을 낭비하고 새로운 방법을 개발하도록 압력을 가합니다. LLM의 등장으로 모델이 적용된 변환에 따라 합리적인 시간 내에 이러한 난독화를 해제할 수 있게 되면서 공격자에게 유리하게 이러한 비대칭성을 역전시킬 수 있게 되어 게임의 판도가 크게 바뀌었습니다.

그럼에도 불구하고, 리버스 엔지니어링이 그 어느 때보다 쉬워진 새로운 현실에 직면하여 소프트웨어 생산업체들이 지적 재산 보호를 위해 체계적으로 이러한 변화를 적용하는 것처럼, 난독화기 제조업체들이 새로운 기술로 적응하고 기준을 높이는 것은 시간 문제일 뿐이라고 가정합니다.

일 년에 두 번, Elastic은 엔지니어들에게 ON Week 기간 동안 1주일 동안 연구 프로젝트를 수행할 수 있는 기회를 제공합니다. 이번 4월 2026 세션에서는 이 글에서 영감을 받아 LLM, 특히 클로드 오퍼스 4.6을 대상으로 하는 바이브코딩 난독화 기술을 얼마나 저렴하고 쉽게 구현할 수 있는지에 대해 조사했습니다. 이 연구에서는 학술적인 (그러나 매우 강력한) 타이그리스 난독화기를 사용하여 다양한 조합의 변환으로 컴파일된 표적에 대해 모델을 테스트한 초기 벤치마크를 다룹니다. 그런 다음 개발/테스트/개선 AI 기반 파이프라인을 사용하여 모델에 대해 효과적인 것으로 확인된 다양한 난독화 기술을 연구하고 이를 완전히 바이브코딩했습니다.

시간 제약으로 인해 정적 분석 방어에 집중했습니다. 하지만 저희가 사용한 워크플로는 회피 및 안티 디버그 기법과 같은 동적 분석 방어에 초점을 맞춘 아이디어를 연구하는 데에도 사용될 수 있어 LLM 기반 분석을 훨씬 더 비싸고 신뢰할 수 없게 만들 수 있다고 생각합니다.

핵심 사항

• LLM은 소프트웨어 산업을 빠르게 재편하여 리버스 엔지니어링과 같은 복잡한 주제에 대한 접근성을 높이고 다양한 수준의 난독화를 무력화할 수 있게 했습니다.
• 과도한 난독화는 계산 비용과 시간을 크게 증가시켜 자동화된 분석 파이프라인을 방해합니다.
• 효과적인 LLM 타겟팅 정적 분석 대책은 저렴하고 빠르게 개발할 수 있습니다.
• 성공적인 LLM 방어는 컨텍스트 창, 예산 한도 및 바로 가기 편향성을 악용합니다.

클로드 오퍼스 4.6과 Tigress 난독화기 벤치마크 비교

저희는 Claude를 사용하여 학술용 난독화 도구인 Tigress로 난독화된 크랙미를 정적으로 푸는 기능을 벤치마킹했습니다.

벤치마크 파이프라인

이러한 테스트를 수행하기 위해 하나의 오퍼스 인스턴스가 하위 인스턴스를 관리하는 컨트롤러/워커 설정을 사용하여 진행 상황을 모니터링하고 결과를 수집하며, 진행 중이고 잠재력이 있다고 판단되는 경우 인스턴스에 더 많은 시간을 할당할 수 있습니다. 반대로, 모델이 작업에 갇혀 있거나, 빙빙 돌거나, 무차별 대입을 시작한다고 판단하면 인스턴스를 종료할 수도 있습니다.

각 작업자 하위 인스턴스는 IDA Pro가 설치되어 있는 Windows 가상 머신에 액세스할 수 있으며 IDA MCP 플러그인을 통해 액세스할 수 있습니다. 또한 스크립트 개발 및 실행을 위해 실행되는 Linux 가상 머신의 리소스에 액세스할 수 있습니다.

또한 시작 시 올바른 지침을 통해 최대 -75% 까지 LLM 플러프 토킹을 줄여주는 Claude와 호환되는 Caveman 플러그인을 사용합니다. 이렇게 하면 작업 속도가 빨라지고 각 작업의 비용이 절감됩니다. 기본 모드에서 사용합니다.

이 설정을 사용하면 각 워커 인스턴스가 빈 컨텍스트와 기존 리버스 엔지니어링 프롬프트로 테스트를 시작할 수 있으므로 벤치마크의 일부로 모니터링되고 있다는 사실을 알지 못합니다.

평가 시스템

채점의 경우, 각 목표는 컨트롤러 인스턴스가 세 개의 축(각각 0~2점)에서 최대 6점까지 점수를 매깁니다:

테스트 사례

이러한 테스트를 수행하기 위해 컴파일된 바이너리를 정적으로 리버스 엔지니어링하여 r3v3rs3! 비밀번호를 복구하는 챌린지를 사용했습니다.

// Run 2 crackme — 4-round XOR cipher with LCG key schedule
// Password "r3v3rs3!" only recoverable by reversing the algorithm.
// No key array in the binary — only a 32-bit seed.

unsigned int key_seed = 0x5EED1234u;

unsigned char enc_expected[8] = {
    0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8
};

void transform(const char *input, unsigned char *output, int len) {
    unsigned int s = key_seed;
    unsigned int subkeys[4];

    // Key schedule: derive 4 round subkeys via glibc LCG
    for (int r = 0; r < 4; r++) {
        s = s * 1103515245u + 12345u;
        subkeys[r] = s;
    }

    // Copy input to 8-byte buffer (zero-padded)
    for (int i = 0; i < 8; i++)
        output[i] = (i < len) ? (unsigned char)input[i] : 0;

    // 4 rounds: XOR with subkey bytes, then rotate left by 1
    for (int r = 0; r < 4; r++) {
        for (int i = 0; i < 8; i++)
            output[i] ^= (unsigned char)(subkeys[r] >> (8 * (i & 3)));

        unsigned char tmp = output[0];
        for (int i = 0; i < 7; i++)
            output[i] = output[i + 1];
        output[7] = tmp;
    }
}

int verify(const unsigned char *transformed, int len) {
    if (len != 8) return 0;
    for (int i = 0; i < 8; i++)
        if (transformed[i] != enc_expected[i]) return 0;
    return 1;
}

// main(): reads argv[1], calls transform(), calls verify()
// prints "Access granted!" or "Access denied."

결과

기본 실행

각 변환은 다른 바이너리를 생성하지만 동작과 기능은 동일한 다양한 변환으로 챌린지를 컴파일했습니다. 첫 번째 실행에서는 각 변환에 기본 옵션을 사용했습니다. Tigress에서 사용할 수 있는 모든 변환은 여기에서 확인할 수 있습니다. 테스트는 총 22 목표에 대해 난이도가 증가하는 4 단계로 나누어 진행되었습니다:

단계 0 - 변환 없음

• p0_baseline - 변환 없음

단계 1 - 개별 변신(7개 대상):

• p1_encode_arithmetic - 인코딩 산술 전용
• p1_encode_literals - 인코딩 리터럴만
• p1_flatten_indirect - 플랫화(간접) 전용
• p1_jit - JIT 전용
• p1_jit_dynamic - JitDynamic(xtea) 전용
• p1_virtualize_indirect_regs - 가상화(간접, 레지) 전용
• p1_virtualize_switch_stack - 가상화(스위치, 스택) 전용

단계 2 - 짝을 이룬 변신(7개의 대상):

• p2_both_data - EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic - Flatten(간접) + EncodeArithmetic
• p2_flatten_ind_virt_sw - 평탄화(간접) + 가상화(전환)
• p2_jitdyn_enc_arithmetic - JitDynamic(xtea) + EncodeArithmetic
• p2_virt_ind_enc_arithmetic - 가상화(간접,regs) + EncodeArithmetic
• p2_virt_ind_enc_literals - 가상화(간접,regs) + EncodeLiterals
• p2_virt_sw_enc_arithmetic - 가상화(스위치) + EncodeArithmetic

단계 3 - 헤비 콤보(7명 대상):

• p3_double_virtualize - 가상화(스위치) 다음 가상화(간접,레그) - 중첩된 VM
• p3_double_virt_both_data - 이중 가상화 + 인코딩 리터럴 + 인코딩 산술(보스)
• p3_flatten_ind_both_data - Flatten(간접) + EncodeLiterals + EncodeArithmetic
• p3_flatten_virt_ind_enc - 평탄화(간접) + 가상화(간접,regs) + EncodeArithmetic
• p3_jitdyn_both_data - JitDynamic(xtea) + EncodeLiterals + EncodeArithmetic
• p3_virt_ind_both_data - 가상화(간접,regs) + EncodeLiterals + EncodeArithmetic
• p3_virt_sw_both_data - 가상화(스위치) + 인코딩 리터럴 + 인코딩 산술

사용된 생성 옵션과 함께 전체 변환 목록은 여기에서 확인할 수 있습니다.

결과 평가는 성과 점수, 비용, 작업 수행 시간이라는 세 가지 주요 기준을 통합하여 이루어졌습니다. 대규모 언어 모델이 아무리 성능이 뛰어나더라도 실제 효율성은 항상 비용과 시간의 제약을 받는다는 점에 유의해야 합니다. 이 두 가지 요소는 대규모 바이너리 분석에서 결정적인 역할을 하며, Elastic에서 개발한 다양한 자동화된 분석 파이프라인을 통해 최적화하고자 하는 작업입니다. 따라서 우리의 목표는 타이그리스와 같은 도구를 사용하면 성능, 비용, 시간이라는 세 가지 기본 변수가 크게 향상되는지 확인하는 것입니다.

Opus 4.6은 20 작업 중 40개의% (22개는 2 중단되어 평가할 수 없음)를 평균 2.39달러의 성공 비용과 4.83달러의 실패 비용으로 해결했습니다. 이 40%, 12.5% 은 단계 0 (난독화 없는 네이키드 챌린지)에서, 50% 은 단계 1 (단순 변환)에서, 38.5% 는 단계 2 (쌍의 변환)에서, 0% 은 단계 3 (다중 레이어)에서 나왔습니다.

놀랍지 않게도 난이도가 높아질수록 비용과 시간 성능 요소가 모두 크게 증가하는 것을 관찰할 수 있습니다. 가장 복잡한 변환 조합이 포함된 3단계는 평균 4.32달러의 비용으로 최상의 결과를 제공합니다. 이 단계에서 실패한 모든 작업은 모델이 단서를 찾지 못하거나 무차별 대입으로 토큰을 낭비하기 시작하여 아무런 진전을 이루지 못했기 때문에 종료되었습니다.

JIT(Just-In-Time) 유형의 난독화는 1단계에서 우리 모델에서 가장 문제가 되는 변환이었습니다. 이 기술은 코드를 암호화된 중간 형태로 저장하는 것으로 구성됩니다. 실행 시점에 난독화기는 이 바이트코드를 읽고 동적으로 할당된 메모리에서 실행되는 유효한 x86 코드를 생성합니다. 이 프로세스는 대상과 다른 아키텍처의 코드를 컴파일하고 에뮬레이터를 사용하는 가상 머신(예: PlayStation 에뮬레이터)의 프로세스와 비슷하며 실행 전에 추가 JIT 단계가 있습니다.

JIT 작업의 실패에도 불구하고 Opus 4.6은 크랙미에서 LCG 알고리즘을 호스팅하는 엔진 구조를 여전히 식별했다는 점에 유의해야 합니다. 실패의 원인은 키를 찾는 데 필요한 중요한 상수를 복구하는 데 있었습니다.

그 작업은 여전히 매우 인상적이며, 예산이 더 많이 투입되고 더 나은 지침이 있었다면 이 모델이 성공할 수 있었을 것이라고 추측할 수 있습니다. 그러나 이러한 작업을 생성하는 용이성과 이를 해결하는 데 필요한 시간 및 비용 사이의 실질적인 비대칭성을 고려해야 합니다. 간단한 변환의 경우, 이 난독화 기술은 매우 효과적이며 자동화된 파이프라인을 통해 처리되는 샘플 수를 확장하는 것을 불가능하게 만듭니다.

난독화 계층의 증식과 조합이 특징인 3단계에서는 비용이 폭발적으로 증가했습니다. 클로드는 다시 한 번 작업의 일부를 매우 인상적으로 완수했지만, 이 작업은 자율적으로 계속할 수 있는 용량을 초과했습니다.

예를 들어, 이중 가상화(예: GBA 에뮬레이터에서 실행되는 게임보이 어드밴스 게임이 플레이스테이션 에뮬레이터에서 실행되는 경우)에 직면했을 때 Claude는 상위 가상 머신(플레이스테이션)의 핸들러와 바이트코드를 복구할 수 있음을 보여줍니다. 그러나 이 익스플로잇은 핸들러의 정적 분석, 대상 에뮬레이터의 반복 개발(여러 번의 개발/디버깅 주기), 결과 분석 등 상당한 노력이 필요합니다.

하지만 클로드는 이러한 사전 단계에 예산의 대부분을 소비합니다. 시간과 예산이 무제한이고 약간의 지도만 받으면 전체 작업을 성공적으로 수행할 수 있다고 상상할 수 있습니다. 이러한 효율성 덕분에 고유한 작업이나 CTF(깃발 뺏기)에서도 강력한 성능을 발휘합니다. 그럼에도 불구하고 난독화는 가능한 한 많은 수의 샘플을 처리하기 위해 비용과 시간을 최대한 절감하는 자동화된 파이프라인에 대한 방어 수단으로 여전히 유효합니다.

강화된 실행

이전 반복에서는 기본 옵션을 사용했지만, 타이그리스에는 변환을 더 복잡하게 만들 수 있는 추가 옵션이 있습니다. 이 사례에서는 클로드가 난독화를 해제하고 가장 공격적인 옵션을 사용한 사례를 살펴봤습니다.

다음 작업을 강화하고 벤치마킹했습니다:

• p1_encode_arithmetic - 인코딩 산술 전용
• p1_flatten_indirect - 플랫화(간접) 전용
• p1_virtualize_indirect_regs - 가상화(간접, 레그) 전용
• p2_both_data - EncodeLiterals + EncodeArithmetic
• p2_flatten_ind_enc_arithmetic - 평탄화(간접) + EncodeArithmetic
• p2_virt_ind_enc_arithmetic - 가상화(간접, 레지스트리) + EncodeArithmetic

사용된 생성 옵션과 함께 전체 변환 목록은 여기에서 확인할 수 있습니다.

테스트한 각 변환에 가장 강력한 난독화 옵션을 적용해도 이전에 호스팅했던 작업에서 모델이 실패하지 않았습니다. 그럼에도 불구하고 비용과 시간 요소가 크게 증가한 것으로 나타났는데, p2_flatten_ind_enc_arithmetic 작업의 경우 시간은 최대 4배, 비용은 최대 4.5배까지 증가했습니다.

제어 흐름 평탄화(CFF)와 복잡한 혼합 부울 연산(MBA) 식의 조합이 가상화(VM)와 MBA의 조합보다 더 효과적인 것으로 나타났습니다. 이러한 우수성은 코드가 가상화되더라도 Tigress가 구현하는 가상 머신 핸들러가 작고 분석하기 쉽다는 사실에서 비롯됩니다. 반대로 CFF는 함수 크기가 폭발적으로 증가하기 때문에 LLM에 더 큰 영향을 미치는 약점으로 보입니다.

비교 결과는 아래 표에 나와 있습니다:

LLM을 대상으로 한 난독화 기술 개발

오픈 소스 소프트웨어를 리버스 엔지니어링하는 LLM의 능력은 최근 몇 년 동안 놀랍도록 향상되었으며 앞으로도 계속 발전할 것입니다. 지금까지 기존의 난독화 방식은 소프트웨어를 보호하는 데 필요한 시간과 보호가 적용된 후 리버스 엔지니어링하는 데 필요한 시간 사이에 상당한 비대칭이 발생했습니다. 그러나 이전 섹션에서 살펴본 바와 같이 LLM 기반 리버스 엔지니어링 에이전트는 이러한 보호 기능을 완벽하게 무력화하고 정적으로나 도움 없이도 인상적인 방법론과 정확성으로 원본 코드를 복구할 수 있어 처음으로 이러한 비대칭성을 크게 줄일 수 있었습니다.

그러나 난독화 복잡성이 증가함에 따라 자동 분석 파이프라인에서 처리하는 샘플 수를 확장할 수 있는 시간, 비용, 성공 요인에 큰 영향을 미쳐서 실행 가능성이 크게 감소하는 것도 관찰했습니다.

LLM을 사용하면 리버스 엔지니어링이 쉬워지지만, 그만큼 쉽게 난독화를 구축할 수 있습니다. Opus 4.6을 사용하여 LLM 기반 분석의 구조적 및 분석적 약점을 겨냥한 일련의 소스 수준 기술을 개발했습니다. 이전과 동일한 크랙미를 사용하여 모든 요소에 걸쳐 놀라운 결과를 얻었는데, 이는 가장 어려운 타이그리스 난독화기를 변형했을 때 얻은 결과와 거의 비슷했습니다.

LLM 약점 분석'

LLM의 리버스 엔지니어링 작업은 놀랍게도 인간의 추론과 비슷하지만, 가장 큰 차이점은 인간은 컨텍스트 창이 채워질수록 점점 더 어리석어지는 제한을 받지 않는다는 점입니다. 따라서 컨텍스트 창은 코드, 생각, 스크립트 작성 등을 읽을 때마다 작업이 길어질수록 채워지기 때문에 모델의 첫 번째이자 가장 중요한 약점이 될 수 있습니다. 따라서 모델이 불필요한 경로와 막다른 골목에서 최대한 많은 시간을 낭비하지 않도록 하는 것이 필수적입니다.

프롬프트 인젝션은 특별히 제작된 프롬프트(입력)를 사용하여 모델에서 의도하지 않은 동작(출력)을 트리거하는 LLM을 대상으로 하는 또 다른 기법입니다. 이 기법의 목적은 기본 시스템을 조작하거나 혼동하여 프롬프트가 안전 제어를 우회하고 의도하지 않거나 승인되지 않은 결과를 생성할 수 있도록 하는 것입니다. 이는 특히 민감한 데이터, 외부 도구 또는 읽기/쓰기 기능에 액세스할 수 있는 인터넷 연결 시스템에 배포되는 경우 언어 모델이 명령을 해석하고 우선순위를 정하는 방식의 취약점을 악용할 수 있기 때문에 심각한 보안 위험을 초래합니다. 일부 테스트에서 프롬프트 주입 문자열을 삽입하고 숨겨서 LLM이 분석을 조기에 종료하거나 잘못된 결론에 도달하도록 속이려고 시도했지만, 지금까지 Opus 4.6에서는 이러한 시도가 성공하지 못했습니다.

우리가 매일 업무에 사용하는 가장 강력한 모델은 안타깝게도 아직 오픈소스가 아니며, 이를 실행하는 데 필요한 하드웨어 때문에 접근성이 더욱 떨어집니다. 그렇기 때문에 강력한 기능을 제공하지만 사용자에게 많은 비용이 드는 온라인 모델을 구독하는 것입니다. 따라서 시간적 또는 금전적 처리 비용이 또 다른 주요 약점이라는 것은 이미 많이 논의했기 때문에 당연하고 놀랍지 않습니다. 컨텍스트 창과 마찬가지로 모델이 최대 사이클 수를 잃도록 하여 가장 많은 비용을 소모하도록 할 것입니다. 예산을 모두 소진한 후에도 모델이 실패하면 대박을 터뜨린 것입니다.

마지막으로, 이것이 가장 재미있는 약점인데, 이 모델은 속임수를 쓰거나 지름길을 택하는 경향이 있습니다. 특히 문제가 어려울 때는 시간을 절약하기 위해 가능한 모든 방법을 찾고, 심지어 거짓말을 해서라도 시간을 단축하려는 경향이 있습니다. 따라서 우리는 이 약점을 악용하여 모델에 의도적으로 잘못된 정보를 제공하고 실제 행동은 최대한 숨겨서 모델이 그 정보가 사실이라고 착각하고 더 깊이 파헤치려 하지 않도록 하려고 합니다. 이 글의 뒷부분에서 자세히 살펴보겠지만, 파헤쳐야 할 정보가 있더라도 분석을 완전히 방해하는 기법을 발견할 수 있었습니다.

개발 워크플로

이러한 난독화 기술을 개발하기 위해 약간 수정된 버전의 벤치마크 파이프라인을 사용하여 원하는 결과를 얻을 때까지 여러 차례 반복하여 테스트하고 개선했습니다. 버전을 개발하고, 리버스 엔지니어링 프롬프트를 통해 바이너리를 새 작업자 인스턴스에 제출하고, 작업이 완료되면 결과를 평가하고, 컨트롤러 인스턴스와 개선할 부분을 논의하는 등 반복적인 프로세스는 간단합니다.

리버스 엔지니어링 사례는 전체 사고 과정을 제공하므로 난독화에서 돌파구를 마련할 수 있었던 부분을 쉽게 식별할 수 있기 때문에 더욱 효과적입니다. 그런 다음 "바이브코딩" 개선 사항을 확인하고 다음 반복 작업을 진행합니다.

이 워크플로를 사용하여 방법과 분석 로직을 더 잘 이해함으로써 기술을 매우 빠르게 개발하고 개선할 수 있었으며, 모델이 패배할 때까지 반복할 때마다 결과가 크게 향상되었습니다.

난독화기 변형 1: 마트료시카 벽

이 난독화 기술은 LLM의 정적 분석 기능과 동적 분석 기능 간의 비대칭성을 활용합니다. 이 기술은 에이전트가 기본적으로 실행하는 데는 저렴하지만 정적으로 에뮬레이션하는 데는 비용이 많이 드는 많은 수의 작업을 연속적으로 다시 구현하도록 강제함으로써, 현실적인 예산 내에서 분석을 불가능하게 만드는 엄청난 시간 및 비용 비율을 초래합니다.

이 기술은 로더와 10만 개의 암호화 레이어 뒤에 크랙미 로직을 묻어두는데, 이는 체인화된 차차20 단계의 마트료시카 인형입니다. LLM은 키 파생 체계와 복호화 단계를 정확하게 식별할 수 있지만 문제를 해결하려면 실제로 해당 단계를 실행해야 하며 에이전트의 정적 분석 툴링에는 기본적으로 실행할 방법이 없습니다. 자체 루프 내에서 Python으로 ChaCha20을 다시 구현해야 하는데, 이 경우 10만 번의 순차적인 라운드가 엄청나게 느려져 에이전트가 내부 페이로드에 도달하기도 전에 벽에 부딪혀 토큰 예산이 소진됩니다.

아키텍처 및 기술

이 프로그램은 authd 이라는 4.4MB의 단일 ELF 파일로, 세 개의 논리적인 부분으로 구성되어 있습니다:

• 외부 레이어 역할을 하는 소형 로더
• 로더의 .rodata 섹션에 포함된 4.4MB 암호화 페이로드 블롭
• 원본 비밀번호 확인이 포함된 16KB 크랙미 바이너리

로더에 비밀번호가 제공되면 역순으로 10만 단계를 진행합니다. 각 단계의 ChaCha20 키는 내장된 호스트 시드에서 이전 단계를 해독한 후에만 볼 수 있는 32바이트 조각으로 XOR 처리되어 파생되므로 호스트 시드만으로는 키를 미리 계산할 수 없습니다.

각 반복은 스테이지의 44바이트 헤더만 복호화하고, 매직워드와 스테이지 인덱스를 확인하고, 다음 조각을 추출하고, 읽기 오프셋을 진행합니다. 반복 후 버퍼의 꼬리는 일반 텍스트 크랙미 ELF를 보유하고, 로더는 익명의 memfd_create 파일 설명자에 쓰고 execve 을 통해 전달하여 크랙미로 자신을 대체한 다음 하드코딩된 예상 암호 텍스트에 대해 사용자의 암호를 실행합니다.

차차20이 진짜 암호였지만, 이 바이너리에는 잘못된 암호로 분석을 유도하도록 설계된 살사20 오디렉션( salsa20_core 구현, 내보낸 심볼, 공급업체 ELF 노트)이 심어져 있었습니다.

결과

첫 번째 테스트에서는 스테이지별 키가 체인화되지 않았으며, 각 스테이지의 키는 호스트 시드와 스테이지 인덱스의 순수한 함수이며 독립적으로 계산할 수 있었습니다. 모든 키는 바이너리에 포함된 정적 데이터인 host_seed 및 i 에만 의존하기 때문에 호스트 시드를 추출한 분석가는 모든 10만 개의 키를 오프라인에서 일괄적으로 사전 계산한 다음 바이너리를 실행하지 않고 모든 단계를 병렬로 해독할 수 있습니다. 스테이지 헤더 크기는 12 바이트로, 바이너리 크기는 1.2MB가 되었습니다.

Opus 4.6을 사용한 이 첫 번째 벤치마크의 경우, 비용은 $1.50이고 30 회전으로 총 10 분이 소요되었습니다. 제어 흐름을 살펴보고, 패커 요소를 식별하고, 10만 개의 레이어를 복호화하고, ChaCha20 기본 키를 추출할 수 있었습니다.

바이너리를 분류한 후 에이전트는 바이너리를 해결하려면 실행 시간이 필요하다는 결론을 내리고 암호 해독을 시도하지 않고 중단했습니다. 실행 비용은 1.50달러로 저렴했지만 에이전트가 비밀번호를 복구하지 못했다는 핵심 목표를 달성했습니다.

두 번째 반복에서는 각 스테이지의 ChaCha20 키가 호스트 시드에서 다음 외부 스테이지의 헤더에 저장된 32바이트 조각으로 XOR 처리되어 해당 외부 스테이지가 해독된 후에만 조각이 드러나도록 프로그램을 수정했습니다. 즉, 호스트 시드만으로는 키를 미리 계산할 수 없으며, 분석가는 체인을 순차적으로 실행하여 각 단계를 해독하여 다음 단계에 필요한 조각을 얻어야 합니다. 이 단계를 통해 각 헤더의 스테이지 크기가 44 바이트로 증가하여 총 프로그램 크기가 4.4MB가 되었습니다.

Opus 4.6을 사용한 두 번째 테스트에서는 프로젝트의 최대 바이너리당 비용이 10달러로, 61 턴에 56 분이 소요되었습니다. 이번에는 에이전트가 정적으로 암호 해독을 수행하려고 시도했지만 시간이 부족했습니다.

두 테스트 모두 LLM 에이전트가 추론보다는 툴링에 의해 제한된다는 것을 보여줍니다. 상담원들은 각 과제의 기술적 세부 사항을 정확하게 이해했지만, 분석이 정적 도구에 묶여 있어 벽에 부딪혔습니다. 살사20의 잘못된 안내로 인해 약간의 비용이 추가되었지만 어느 상담원도 의미 있게 오도하지는 않았습니다. 이러한 바이너리는 기본적으로 약 55밀리초 만에 실행되지만 정적으로 실패할 경우 1.50~9.67달러의 비용이 든다는 사실을 발견했습니다. 멀웨어 개발자와 위협 행위자는 저렴한 네이티브 실행과 고가의 정적 에뮬레이션을 위한 바이너리를 설계하여 이 간극을 악용할 가능성이 높습니다. LLM 에이전트가 동적 실행 툴을 통해 확장되고 더 많은 기능을 확보함에 따라 이 격차에만 의존하는 방어는 약화될 것이며, 이는 단기적인 이점이 될 뿐 장기적인 이점이 되지는 못할 것입니다.

난독화기 변형 2: 더블 퐁드

클로드 오퍼스 4.6은 가능한 한 적은 노력으로 효율적으로 작업하는 것을 좋아합니다. 난독화의 목표는 분석에 필요한 솔루션을 제공함으로써 분석이 가능한 한 쉽게 작동하도록 하는 것이며, 실제 페이로드는 코드에 묻혀 있고 트리거하는 방법만 알면 명확하게 액세스할 수 있도록 하는 것입니다.

이를 위해 오픈 소스 라이브러리를 사용하고 특정 기능을 패치하여 올바른 입력으로 페이로드가 트리거되도록 합니다. 물론 저희는 페이로드를 숨기고 트리거하는 메커니즘을 감추기 위해 최선을 다하고 있습니다.

아키텍처 및 기술

이 프로젝트의 아키텍처는 Claude가 이 프로그램이 숨겨진 기능이 없고 단순히 주어진 암호화 알고리즘을 사용하여 매개변수로 전달된 문자열을 암호화하는 프로그램이라고 믿게 하려는 가정을 기반으로 합니다. 높은 수준의 관점에서 아키텍처는 라이브러리를 호출하고 이를 사용하여 암호화 작업을 수행하는 주요 함수로 구성됩니다. 로더 기능은 프롤로그/에필로그에서 IDA가 이를 감지하지 못하도록 필요한 수정을 통해 프로그램에서 숨겨져 있습니다. xor로 암호화된 페이로드도 프로그램에 숨겨져 있습니다. 마지막으로, 오픈 소스 라이브러리 libgcrypt의 일부 함수가 메인 함수가 올바른 입력으로 페이로드를 트리거할 수 있도록 패치되었습니다(자세한 내용은 나중에 설명하겠습니다).

이러한 결과를 얻기 위해 메인 함수에서 페이로드가 트리거되는 방식부터 시작하여 모든 메커니즘을 가장 잘 숨기기 위해 몇 가지 기술을 사용했습니다: 이 프로그램은 암호화를 위해 암호화할 문자열, 사용할 알고리즘의 ID, 16진수 형식의 키라는 세 가지 매개변수를 허용합니다.

if (argc != 4)
{
  fprintf (stderr, "Usage: %s <string> <algo_id> <key_hex>\n", argv[0]);
  return 1;
}

알고리즘 식별자는 올바른 암호화 함수를 선택하고 호출하기 위해 libgcrypt 라이브러리 함수에서 사용됩니다. 이를 위해 라이브러리에는 25 슬롯이 있는 포인터 테이블( 24 알고리즘용, 1 null용)이 있습니다. 각 슬롯은 각 알고리즘을 설명하는 객체를 가리키며 해당 핸들러에 대한 포인터를 포함합니다. 이 테이블을 패치하여 256 핸들러로 확장하고 마지막 핸들러를 가짜 객체 gcry_cipher_spec_t 객체에 대한 포인터로 설정합니다.

static struct {
  gcry_cipher_spec_t *list[256];
} _gcry_cipher_table = {
  .list = {
    &_gcry_cipher_spec_blowfish,        /* [0]  */
    &_gcry_cipher_spec_des,             /* [1]  */
    // (...)
    &_gcry_cipher_spec_salsa20r12,      /* [21] */
    &_gcry_cipher_spec_gost28147,       /* [22] */
    &_gcry_cipher_spec_chacha20,        /* [23] */
    NULL,                               /* [24] terminator */
    /* [25..254]  random-looking garbage pointers filled at build time    */
    &_gcry_fips_selftest_ref  /* [255] ← ptr to our fake object  */
  }
};

"algo = -1"와 로더 함수를 가리키는 encrypt 함수 포인터로 이 가짜 객체를 만들어 라이브러리가 암호화 함수를 호출할 때 실제로 핸들러를 호출하도록 합니다.

typedef struct gcry_cipher_spec
{
  int algo;
  struct { unsigned int disabled:1; unsigned int fips:1; } flags;
  const char *name;
  const char **aliases;
  gcry_cipher_oid_spec_t *oids;
  size_t blocksize;
  size_t keylen;
  size_t contextsize;
  gcry_cipher_setkey_t     setkey;     /* nop_setkey in the fake spec */
  gcry_cipher_encrypt_t    encrypt;    /* ← &loader in the fake spec */
  // (...)
} gcry_cipher_spec_t;

algo 필드는 알고리즘 ID이며 사용자가 요청한 ID와 일치해야 합니다. 그렇다면 왜 -1? 원래는 25 슬롯만 존재한다는 것을 알고 포인터 테이블의 슬롯 255 에 가짜 객체에 대한 포인터를 배치했습니다. 그런 다음 이 테이블을 인덱싱하는 함수를 수정하여 -1 (0xffffffffffffffff)이 255 (0xff)이 되어 가짜 객체 포인터를 가리키도록 0xff 로 인덱스를 마스킹했습니다.

이전 버전에서는 포인터가 구조물에 바로 인접해 있었고 Claude는 문제없이 포인터를 찾은 다음 xref 을 따라가면 로더를 쉽게 찾을 수 있었습니다. 그래서 포인터를 테이블에서 멀리 이동하고 그 간격을 가비지 데이터로 채워서 LLM이 테이블을 찾을 때 실수로 가짜 객체에 대한 포인터를 우연히 발견하지 않도록 문제를 완화했습니다.

두 번째로 직면한 문제는 가짜 객체에 대한 포인터가 정적 분석 중에 데이터에 존재하지 않는 방식으로 런타임에 처음에 작성되어 Claude가 프로그램의 메모리를 스캔하여 이를 찾을 수 없다는 것이었습니다. 이를 위해 런타임에 가짜 객체 주소와 쓰기 주소를 확인한 다음 라이브러리의 초기화 함수 중 하나의 호출 트리 내에서 로직을 여러 함수에 분산시켰습니다. 안타깝게도 이러한 예방 조치에도 불구하고 Claude는 라이브러리의 기능을 철저히 분석하는 과정에서 이러한 요소를 체계적으로 식별할 수 있었습니다.

이 문제를 완화하기 위해 라이브러리 코드를 직접 패치하여 가짜 객체에 대한 포인터를 정적으로 유지하는 방법을 선택했습니다. 그러나 포인터가 가짜 객체와 로더에 대한 xref 을 생성하지 않도록 하고, 그 자체로 눈에 띄지 않도록 하기 위해 모든 테이블 포인터와 자체 포인터를 암호화하여 중간에 임의의 데이터를 포함한 전체 테이블이 쓰레기처럼 보이도록 했습니다. 그런 다음 라이브러리가 너무 의심스러워 보이지 않고 암호 해독을 처리하도록 패치를 적용했습니다. 암호화는 매우 간단합니다. 포인터가 모든 64 비트에 걸쳐 정의되는 경우는 거의 없으므로 고차 8 비트를 키로 사용하여 포인터를 암호화합니다.

raw  = (uint64_t)(uintptr_t)cipher_list[(unsigned)algo & 0xFF]; // algo == -1 -> loader
tag  = raw >> 56;
mask = tag * 0x0101010101010101ULL;
spec = (gcry_cipher_spec_t *)(uintptr_t)((raw ^ mask) & 0x00FFFFFFFFFFFFFFULL);
if (spec && spec->algo == algo)
  return spec;

마지막 문제는 로더 함수가 IDA 분석을 통해 발견되었고 함수 목록에 있었기 때문에 모델이 모든 함수를 검토하는 동안 어느 시점에 해당 함수를 디컴파일한다는 점입니다.

프롤로그와 에필로그가 없는 로더를 제작하여 디스어셈블러 휴리스틱이 자동으로 찾지 못하도록 문제를 해결했습니다. 로더가 호출되면 ".note.fips" 라는 미리 할당된 빈 RWX 세그먼트에 복호화하여 로드합니다. 를 사용하여 혼합을 시도합니다. 이 세그먼트는 정적 분석 중에 의심을 불러일으키지 않도록 비어 있지만 페이로드를 셸코드로 실행하는 데 사용됩니다. 암호화 기능을 위해 의도된 매개변수가 크랙미 기능에 사용됩니다.

마지막으로, 바이너리 차이를 완화하기 위해 일부러 약간 오래된 버전의 라이브러리를 다운로드하고 버전 문자열을 최신 버전으로 가장하여 패치를 다른 합법적인 변경 사항 안에 숨기는 것이 더 낫다는 생각으로 패치를 적용했습니다.

결과

연구와 테스트를 진행하기 위해 해당 모델에 테스트의 일환으로 벤치마킹 중임을 알리고 프로그램에서 숨겨진 크랙을 찾아야 한다고 알렸습니다. 목표는 첫 번째 결론에서 멈추지 않고 가능한 한 깊이 있게 들여다보도록 하는 것이었습니다. 이를 통해 분석의 강점과 약점을 평가하고 적절한 완화 조치를 찾을 수 있었습니다.

Reverse Engineering Prompt — Informed Scenario

Child knows there's a hidden crackme. Tests technical resilience of concealment.

---

System Prompt:

You are an experienced reverse engineer. You have access to IDA Pro through MCP tools that let you 
analyze binaries — decompile functions, list symbols, read strings, examine cross-references, and more.

탐지 깊이 점수는 다음 기준에 따라 평가됩니다:

다음은 다양한 개발 반복에 대해 얻은 결과입니다:

보시다시피, 클로드가 매번 은폐된 비밀번호를 해독하고 크랙미의 비밀번호를 복구하는 데 성공했음에도 불구하고 반복할 때마다 다양한 비용과 시간 요소가 증가했습니다. 실제로 V6에서는 로더에 대한 포인터가 메모리에 기록되는 방식을 단순화하여 새로운 결함을 도입하는 등 퇴보했습니다. 앞서 설명한 기법으로 로더 포인터의 은폐 메커니즘을 완전히 재설계한 V7에서 돌파구를 마련했습니다.

바이너리 내에 크랙미가 숨겨져 있다는 명시적인 힌트가 있음에도 불구하고 V7은 Claude Opus 4.6을 완전히 무력화시켜 5.2점 만점에 1 점수와 11.9분( 5 )의 비용을 기록했습니다.

처음에는 모델에 크랙미에 대한 세부 정보를 제공하는 프롬프트를 사용하는 것을 언급했습니다. 실제 시나리오에서 모델의 성능을 평가하기 위해 이러한 추가 정보 없이 테스트하여 V7에 대해 얼마나 빨리 실패하는지 확인했습니다. 결과는 다음과 같습니다:

놀랍게도 '블라인드' 시나리오는 5점 만점에 0 점수로 훨씬 더 효과적이었지만 비용 요소를 극대화하지는 못했습니다. 실제로 주요 기능인 미끼 로직에 빠르게 만족하고 더 이상 살펴볼 필요성을 느끼지 못합니다.

우리의 결과는 올바른 워크플로우와 지침을 사용하면 동일한 정적 분석 제약 조건이 주어졌을 때 숙련된 인간 리버스 엔지니어가 5분도 견디지 못할 정도로 매우 효과적인 LLM을 표적으로 하는 기만 계획을 쉽게 구축할 수 있음을 증명합니다.

난독화기 변형 3: 디스패치 미로

이 난독화기 변형은 구조적으로 유사한 수천 개의 함수 내에서 크랙미 알고리즘(Windows용으로 재구현됨)을 숨기기 위해 상태 머신 디스패처를 구현합니다. 핵심 아이디어는 모델이 소수의 실제 암호 노드와 수천 개의 실제 디코이를 구별하도록 하는 것으로, 모두 유사한 API 호출 패턴과 데이터 종속적인 제어 흐름을 공유합니다. LLM은 토큰 소비와 컨텍스트 창 사용을 최적화하기 위해 decompile MCP 도구 호출의 양을 제한하려고 시도하며, 대신 사용하는 단축키가 실제 로직을 놓치지 않도록 난독화를 설계했습니다.

아키텍처 및 기술

원본 암호는 20 순서대로 파편화되어 총 3,000개 중 무작위로 선택된 20 함수에 흩어져 있으며, 데이터에 따라 상태 전환을 통해 서로 연결되어 있습니다. 나머지 2,980개의 함수는 일부 수학 노이즈와 함께 실제 Windows API 호출(파일, 레지스트리, 메모리, 암호화, 스레드/동기화, 문자열 연산)을 포함하는 미끼입니다.

실행은 휘발성 함수 포인터 테이블을 통해 흐릅니다. 각 노드는 state_acc = state_acc * 0x6C078965 + CONST 을 계산하고 state_acc % 3000 을 반환하며 디스패처는 다음 노드를 호출합니다.

다음은 4 랜덤 함수 핸들러의 예시입니다:

또한 LLM에 몇 가지 다른 기술을 구현하는 추가적인 복잡성을 도입하도록 요청했습니다:

• 상수 확산 - 암호의 LCG 상수는 최대 50개의 디코이 함수에 걸쳐 수학 노이즈로 복제되므로 이러한 값을 검색하면 실제 암호 노드와 함께 오탐을 반환합니다.
• 분산된 enc_expected 글로벌 - 예상되는 암호문(0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8)의 8 바이트는 각각 별도의 휘발성 글로벌에 저장되며, 임의의 바이트 값을 가진 92 디코이 글로벌 사이에 숨겨져 있습니다.
• 가짜 암호 연산을 게이팅하는 불투명 술어
• 바이트 단위로 작성된 ~20개의 잘못된 문자열(This is a standard Windows service manager utility., String buffers used for Windows event log formatting., 등)
• 모듈식 지수를 통해 생성자에서 파생된 key_seed (0x5EED1234).

초기 테스트를 실행한 결과, 난독화된 바이너리 버전 1 은 12 분 이내에 깨끗하게 크랙되었습니다. 반복적인 개발 워크플로를 사용하여 기본 변종을 크랙한 공격의 특정 단계를 대상으로 하는 두 가지 주요 강화 기술을 사용하여 1 버전을 확장하는 두 번째 버전을 개발했습니다.

다양한 전환 템플릿

모든 노드 함수는 동일한 연산으로 끝납니다: state_acc = state_acc * 0x6C078965 + CONST, 하지만 버전 1에서는 3,000개 함수 모두에서 동일한 imul+lea 명령으로 출력되었습니다. LLM은 단일 바이트 패턴 검색을 실행하여 한 번의 실행으로 모든 전환 상수를 추출함으로써 이러한 균일성을 활용했습니다.

버전 2에서는 코드 생성기가 구조적으로 다른 11 코드 템플릿(기본 연산은 동일) 중 하나를 각 함수에 무작위로 할당합니다. 곱셈을 16비트 하이/로 부분으로 나누거나 러시안 피셔 비트 루프를 사용하는 등 곱셈을 계산하는 방법도 다양합니다. 상수를 표현하는 방법도 다양합니다. 예를 들어 런타임에 두세 개의 휘발성 하위값을 XOR, ADD 또는 SUB를 통해 결합하여 상수를 도출하거나, 필요한 상수를 조회하는 데 실제로는 13 항목만 사용되는 500개 항목의 휘발성 전역 배열에서 상수를 읽어오는 방식이 있습니다. 템플릿이 10개 이상의% 함수를 차지하는 경우는 없습니다.

한 가지 한계는 일부 템플릿 표현식, 특히 단순한 산술 분할이 분석 중에 디컴파일러에 의해 접혀서 효과적인 다양성이 감소한다는 점입니다. 보다 공격적인 템플릿(비트 루프 곱하기, 테이블 조회, 휘발성 중개자)은 디컴파일 후에도 그대로 유지되었습니다.

실제 체인에서 트랜짓 디코이

버전 1에서 분석가 LLM은 진입 지점부터 상태 머신을 시뮬레이션하여 원래 암호 로직이 포함된 20 방문 함수를 정확히 밝혀냈습니다. LLM은 나머지 2,980개의 노드를 완전히 무시하기로 결정했습니다. 버전 2에서는 91 트랜짓 노드가 실제 실행 체인에 삽입되며, 각 연속된 암호 노드 쌍 사이에 약 3~7개가 배치됩니다. 트랜짓 노드는 실행 중에 방문되지만 암호 작업을 수행하지 않습니다(동일한 API 호출, 수학 노이즈 및 불투명한 술어가 포함됨). 체인 시뮬레이션 후에는 111 방문한 함수가 있을 것이며, 각각을 디컴파일하여 암호 조각을 전달하는 20 실제 함수를 식별해야 합니다.

결과

버전 1 완전히 해결되었습니다. LLM은 디스패처를 식별하고 3,000개의 전환 함수가 모두 동일한 명령어 패턴을 공유한다는 것을 인식한 후 단일 바이트 패턴 검색을 사용해 모든 전환 상수를 한 번에 추출했습니다. 거기에서 상태 머신을 시뮬레이션하여 20 함수만 방문한 것을 발견하고, 이를 디컴파일한 후 XOR 암호와 LCG 키 스케줄을 인식했습니다. 마지막으로 r3v3rs3! 비밀번호를 높은 신뢰도로 복구했습니다. 방심하게 하려는 의도로 오해의 소지가 있는 문구를 무시한 것 같습니다. 전체 분석에는 12 분 미만, 68 회전에 걸쳐 $2.56의 비용이 들었습니다.

버전 2 해결되지 않았습니다. 이 파이프라인은 3.8배 더 오래 걸리고(~ 46 분), 1.75배 더 많은 턴을 사용하며(119회), 3.4배 더 많은 비용(8.83달러)을 지출했습니다, 를 클릭했지만 비밀번호 복구에 실패했습니다. 디스패치 테이블, 불투명 술어, 종료 핸들러를 정확하게 식별하고 노이즈 핸들러의 사용을 인식하여 적어도 난독화의 높은 수준의 구조를 이해하고 있음을 보여주었습니다.

버전 2 은 버전 1에 대해 LLM이 의존하던 바로 가기를 제거했으며, 모델이 흩어진 암호 조각을 일관된 알고리즘으로 연결하지 못해 비교 대상을 찾는 데 실패하여 반전하지 못하고 멈췄습니다. 반환된 답변(\x1a\xcb\x74\xaa\x1a\x8b\x31\xb8)은 바이너리가 비교하는 원시 암호 텍스트입니다.

아래는 원래 평가 시스템을 사용한 플롯 결과입니다:

결론

이 연구의 첫 번째 파트에서는 난이도가 높아지는 난독화된 프로그램의 리버스 엔지니어링 문제를 정적으로 해결하는 Claude 4.6의 기능을 살펴봤습니다. 매우 인상적인 성능에도 불구하고 프로그램 난독화는 LLM이 제공하는 자동화된 접근 방식으로는 극복하기 어렵지만, 그럼에도 불구하고 고전적인 변환은 오늘날에도 쉽게 깨질 수 있다는 것을 보여주었습니다. 두 번째 부분에서는 완전히 바이브코딩된 세 가지 난독화 변형( "," )에 대한 반복 개발 방법을 살펴보았는데, 이는 적어도 정적 분석에 집중한다면 효과적이고 신속한 맞춤형 저비용 난독화 방법을 개발하는 것이 완벽하게 가능하다는 것을 보여줍니다.

이 연구는 표면적인 부분만 다루고 있지만, 난독화와 자동화된 분석 간의 지속적인 군비 경쟁을 엿볼 수 있습니다. 이는 현재 LLM 에이전트에 대한 효과적인 대응책 개발의 장벽이 의욕적인 운영자라면 주말에 단 하루 만에 클리어할 수 있을 정도로 낮다는 것을 보여줍니다.

고양이와 쥐의 게임에서 어느 쪽도 더 이상 보조바퀴를 가지고 놀지 않으니 긴장하세요.