zypherion-technologies/unconfuserex안티 태머, 압축기, 상수, 제어 흐름 및 리소스 복구를 지원하는 ConfuserEx2 디난독화 도구입니다.
UnconfuserEx의 향상된 포크로, 최신 ConfuserEx2 변종, 안티탬퍼 복구, 압축기 제거, 제어 흐름 복원 및 리소스 재구성에 대한 지원이 개선되었습니다.
https://github.com/user-attachments/assets/de2c7fd9-6736-4f39-83c0-3c25aa9c1f24
혹시 악성코드 샘플을 다뤄본 적이 있다면, 그중 일부는 ConfuserEx로 난독화되어 있습니다. 저도 최신 버전에 대해 몇 가지 공개된 디난독화 도구를 시도해봤지만 작동하지 않아서, 그 최신 버전에서 작동하던 공개 도구를 포크하여 제 필요에 맞게 수정하기로 했습니다.
이 저장소는 MadMin3r/UnconfuserEx의 포크입니다. 그 분에게도 공을 돌립니다. 원본 프로젝트는 실제 보호를 제거할 수 있는 ConfuserEx2 전용 디난독화 도구를 만드는 어려운 작업을 수행했습니다.
이 프로젝트가 하는 일도 마찬가지입니다. 고정된 순서로 제거기 목록을 실행하고, 가능한 경우 메서드 본문/메타데이터/리소스를 다시 작성한 후 새 어셈블리를 출력합니다. 중요한 것은 순서입니다. 압축기와 안티탬퍼는 먼저 실행되어야 합니다. 나머지 모듈이 아직 실제 IL이 아닐 수도 있기 때문입니다.
업스트림 버전도 유용했지만, 몇 가지 경우가 계속 발생했습니다.
하나는 LZMA 경로였습니다. 일부 샘플은 상수/리소스 페이로드처럼 보이는 바이트를 제공하지만 LZMA 속성이 말도 안 됩니다. 그대로 디코더에 전달하면 터무니없는 사전 크기가 나와 결국 배열 차원이 지원 범위를 초과하는 예외가 발생합니다. 따라서 이 버전에서는 속성을 확인하고, 사전 크기와 압축 해제 크기에 상한을 적용하며, 디코더가 과도한 메모리를 할당하기 전에 중단합니다.
LZMA properties => CE FD 62 5F 9F
Invalid LZMA properties byte 0xCE or unreasonable dictionary size
상수 관련해서는 또 다른 어리석지만 실제로 존재하는 문제가 있었습니다. 많은 리졸버 코드는 getter 호출 앞에 있는 ID가 ldc.i4이기를 기대합니다. 하지만 때로는 단일 명령어가 아니라 작은 산술 표현식입니다.
ldc.i4 0x1234
ldc.i4 0x55
xor
call string <const getter>(int32)
원본 포크는 xor을 보고 GetLdcI4Value()를 호출하다가 xor이 분명 정수 로드가 아니기 때문에 죽습니다. 이 버전은 작은 산술 시퀀스를 거슬러 올라가 스택을 에뮬레이트하고, 이를 하나의 ldc.i4으로 축소한 후 일반 리졸버가 계속 작동하도록 합니다.
따라서 이것을 완전히 다른 상수 보호로 처리하는 대신, 다음과 같이 만듭니다:
ldc.i4 0x1261
call string <const getter>(int32)
그러면 기존의 일반/x86 상수 리졸버 경로가 제 역할을 할 수 있습니다.
제어 흐름은 좀 미묘했습니다.
스위치 제거기는 일반적인 ConfuserEx 스위치 디스패처 형태를 처리할 수 있습니다. 블록을 탐색하고, 다음 대상을 복구하며, 죽은 블록을 삭제하고, 정상적인 메서드 본문을 내보냅니다. 하지만 메서드의 일부만 이해되는 샘플도 있습니다. 메서드 절반을 변경한 후 여전히 난독화되어 있음을 발견하면, 이제 IL이 깨져서 무슨 일이 일어났는지 추론할 수 없기 때문에 출력은 쓸모없거나 더 나쁩니다.
따라서 이 버전은 메서드 본문을 건드리기 전에 스냅샷을 찍습니다:
instructions
exception handlers
디난독화가 실패하거나 메서드가 여전히 난독화된 것으로 보이면 원래 본문이 복원됩니다. 로그에는 여전히 "이 메서드는 해결되지 않았습니다"라고 표시되지만, 메서드 하나에 이상한 디스패처가 있다고 해서 어셈블리가 조용히 손상되지는 않습니다.
점프/트램펄린 제어 흐름도 자체 패스를 얻었습니다. 일부 메서드는 스위치 디스패처가 아니라, 실제 블록에 도달할 때까지 연결된 작은 분기 트램펄린입니다. 이제 이러한 것들이 감지되어 접혀지며, 스위치 전용 경로에 의해 무시되지 않습니다.
압축기 제거기는 다른 모든 것보다 먼저 실행되어야 하는 부분입니다.
ConfuserEx 압축기 스텁은 일반적으로 실제 어셈블리를 압축 상태로 유지하고, 작은 로더를 부팅하여 페이로드를 압축 해제한 후 런타임에 로드합니다.
제거기는 로더 형태를 찾고, 포함된 페이로드를 추출하며, 압축을 풀고 모듈을 실제 어셈블리로 교체합니다. 일반 및 컴팩트 압축기 레이아웃이 모두 처리됩니다.
[+] Compressor detected
[+] Extracted compressed module payload
[+] Decompressed real module
[+] Continuing pipeline on unpacked assembly
안티탬퍼는 이제 두 가지 경로를 가집니다.
일반/동적 안티탬퍼는 보호된 섹션에서 메서드 본문을 해독하고 복원된 본문을 모듈에 다시 씁니다. JIT 안티탬퍼는 더 짜증납니다. 본문이 런타임이 요청할 때 구체화되도록 설계되었기 때문입니다.
대략적인 형태는 다음과 같습니다:
find init
extract keys
find encrypted JIT body section
derive per method key
read body
write CilBody back
여전히 패턴 기반입니다. 스텁이 충분히 변경되면 당연히 놓칠 수 있습니다.
리소스는 상수와 유사하게 처리됩니다: 암호화된 리소스 블롭을 찾고, 키/암호 해독기 형태를 복구하며, 해독하고, 필요한 경우 압축 해제한 후 리소스를 일반 .NET 도구가 예상하는 위치에 다시 배치합니다.
선택적 포함 PE 재구축 경로도 있습니다. 일부 보호된 샘플은 리소스 내부에 관리형 PE를 가지고 있습니다. 재구축이 활성화되면 제거기는 해당 페이로드를 구문 분석하고 다시 쓰려고 시도하여, 외부 어셈블리는 디난독화되었지만 내부 어셈블리는 그대로인 상태를 방지합니다.
UnConfuserEx.exe sample.exe sample.clean.exe --rebuild-embedded-pe
샘플이 리소스 내부에 다른 관리형 어셈블리를 숨기고 있다고 확신할 때 사용하세요. 페이로드가 관리형 PE가 아닌 경우 재구축 경로는 그대로 둡니다.
빌드:
dotnet build .\UnConfuserEx.sln -c Release
실행:
.\UnConfuserEx\bin\Release\net9.0\UnConfuserEx.exe .\protected.exe
또는 명시적 출력 경로 지정:
.\UnConfuserEx\bin\Release\net9.0\UnConfuserEx.exe .\protected.exe .\protected.clean.exe
출력 경로를 지정하지 않으면 입력 파일 옆에 -deobfuscated가 추가된 이름으로 파일이 생성됩니다.
포함된 관리형 페이로드의 경우:
.\UnConfuserEx\bin\Release\net9.0\UnConfuserEx.exe .\protected.exe .\protected.clean.exe --rebuild-embedded-pe
현재 지원 목록입니다. 가능한 모든 ConfuserEx 포크에서 작동한다는 의미는 아닙니다. 파이프라인이 찾는 방법을 알고 있는 형태라는 뜻입니다.
코드에 더 숨겨진 것이 있을 수 있는데 나열하는 걸 까먹었습니다 xD.
유용한 로그는 단순히 출력이 실행되지 않았다는 것이 아니라 어떤 단계에서 실패했는지 알려주는 로그입니다.
수정된 상수 경로의 예:
Constants detected, attempting to remove
Found 3 constant getter(s)
Detected constant decryption type is Dynamic
Decompressed constants blob to 18492 byte(s)
Resolving getter <Module>::???????? as String with 41 call site method(s)
Removed all instances of getter <Module>::????????
의도적으로 그대로 둔 제어 흐름 메서드의 예:
Removing obfuscation from method System.Void Example::Run()
Method System.Void Example::Run() still appears obfuscated after deobfuscation -- left original body intact
Removed obfuscation from 42 methods. Failed to remove from 0 methods. 1 methods left untouched
두 번째 로그는 완벽하지는 않지만, 적어도 정직합니다.
모든 도우미 형태를 변경하는 커스텀 ConfuserEx 포크.
작은 스택 표현식 대신 전체 CF 혼란을 통해 ID를 계산하는 상수 getter.
디스패처가 정적 에뮬레이터가 알지 못하는 런타임 값에 의존하는 CF 그래프.
IL 에뮬레이션 대신 실제 런타임 실행이 필요한 네이티브 도우미.
난독화되기 전에 이미 손상된 어셈블리.
암호화된 본문 레이아웃이 다른 JIT 안티탬퍼 변종.
문제를 유용하게 만들고 싶다면 재현할 수 있는 충분한 데이터를 포함하세요.
샘플을 업로드하기 전에 파일 확장자를 제거하세요.
모든 것을 함께 아카이브하고 다음을 포함하세요:
Command:
UnConfuserEx.exe <target> <optional output>
Failure stage:
- compressor
- anti tamper
- constants
- control flow
- resources
- writing output
- runtime after deobfuscation
Expected result:
Actual result:
Console output:
Archive link:
Notes / investigation:
"작동하지 않음"만 보내면 대답은 아마 "그렇군요"일 것입니다.
크고 거대한 재작성보다는 작고 집중된 수정이 좋습니다.
새로운 보호 형태에 대한 지원을 추가하는 경우 해당 제거기 내에서만 격리하세요. 폴백 동작을 추가하는 경우 실패 시 출력 어셈블리가 손상되지 않도록 하세요. 제어 흐름을 건드리는 경우 수정한 이상한 샘플이 존재하는 유일한 이상한 샘플이 아니라고 가정하세요 :DDD.
도구를 디버깅하기 더 어렵게 만들지만 마세요.
이 프로젝트는 MadMin3r/UnconfuserEx를 기반으로 합니다.
원본 프로젝트는 기반과 대부분의 핵심 디난독화 파이프라인을 제공했습니다. 이 포크는 신뢰성 향상, 추가 보호 변종 지원, 실제 샘플에서 관찰된 엣지 케이스 처리에 중점을 둡니다.
이 프로젝트는 소프트웨어 엔지니어링 연습보다는 실용적인 리버스 엔지니어링 도구로 시작되었습니다. 완벽한 코드 품질보다는 보호된 어셈블리를 안정적으로 복구하는 데 항상 중점을 두었습니다.
이 도구는 승인된 악성코드 분석, 리버스 엔지니어링, 소프트웨어 복구, 상호운용성 및 교육 연구를 위한 것입니다.
사용자는 관련 법률을 준수하고 소프트웨어나 시스템을 분석, 접근 또는 처리하기 전에 필요한 승인을 받을 책임이 있습니다.
Zypherion Technologies는 이 도구의 불법 사용을 승인하지 않으며, 제3자에 의한 오용에 대한 책임을 부인합니다.
이 저장소나 www.zypherion.tech에 있는 어떤 내용도 법률 자문이 아닙니다.