언패킹

패킹은 프로그램의 실제 코드를 압축하거나 암호화한 뒤 작은 스텁으로 감쌉니다. 실행 시 스텁은 원래 코드를 메모리에 언패킹하고 실행합니다.

악성 코드 제작자는 시그니처 탐지를 피하고 정적 분석을 방해하기 위해 패킹을 사용합니다.

패킹된 바이너리에는 문자열과 가져오기 항목이 적고 엔트로피가 높게 나타납니다. 의미 있는 코드는 스텁이 실행될 때까지 숨겨져 있습니다.

언패킹은 원래 코드를 복원하므로 정적으로 분석하고 실제 IOC를 추출할 수 있습니다.

Detect It Easy(DIE) 및 PEiD와 같은 도구는 시그니처를 통해 알려진 패커를 식별합니다. 높은 엔트로피와 매우 작은 가져오기 테이블도 강력한 단서입니다.

일반적인 패커로는 UPX, ASPack, Themida가 있습니다.

UPX는 자체 도구로 되돌릴 수 있는 일반적인 비악성 패커입니다. -d 옵션은 바이너리를 원래 형태로 압축 해제합니다.

실제 샘플 중 다수가 UPX 또는 약간 수정된 UPX를 사용하므로, 이는 자주 시도하는 첫 번째 방법입니다.

사용자 지정 패커는 도구로 되돌릴 수 없습니다. 대신 스텁이 메모리에서 스스로 언패킹하도록 한 다음 그 결과를 캡처합니다.

계획은 다음과 같습니다. 디버거에서 샘플을 실행하고, 언패킹이 끝난 직후 멈춘 다음, 이제 드러난 코드를 덤프합니다.

원래 진입점(OEP)은 언패킹이 끝난 후 실행이 이동하는 지점입니다. OEP에 도달했다는 것은 실제 코드가 이제 메모리에 있다는 뜻입니다.

이를 찾는 방법으로는 스텁에서 빠져나가는 원거리 점프를 지켜보거나, 스텁이 기록한 후 실행하는 메모리에 중단점을 설정하는 방법 등이 있습니다.

일반적인 방법은 스택에 하드웨어 중단점을 설정하는 것입니다(스텁은 OEP로 점프하기 직전에 레지스터를 복원하는 경우가 많습니다). 또는 언패킹된 코드가 사용하는 일반적인 API 호출에 중단점을 설정할 수도 있습니다.

OEP에서 중단점이 적중하면 원래 코드가 완전히 디코딩된 상태입니다.

OEP에서 프로세스 메모리를 새 파일로 덤프하십시오. Scylla(x64dbg에 내장됨) 또는 PE-sieve와 같은 도구가 언패킹된 이미지를 캡처합니다.

이제 덤프에는 실제 명령어가 들어 있지만, 아직 단독으로 실행되지 않을 수 있습니다.

패커가 실행 중에 가져오기 항목을 확인했기 때문에 덤프 후에는 가져오기 주소 테이블이 손상되는 경우가 많습니다. Scylla는 덤프된 파일을 분석할 수 있도록 IAT를 재구성할 수 있습니다.

가져오기 항목을 수정하면 정리된 덤프를 Ghidra 또는 IDA에 불러올 수 있습니다.

악성 코드는 패킹 외에도 실행 중 복호화되는 암호화된 문자열, 의미 없는 명령어, 제어 흐름 평탄화, 안티디버깅 검사 등 다양한 난독화 기법을 사용합니다.

이러한 기법은 대개 동적 추적과 끈기 있는 정적 읽기를 결합하여 사례별로 무력화합니다.

덤프하고 가져오기 항목을 재구성한 후 정적 분석을 다시 실행하여 성공 여부를 확인하십시오. 이제 훨씬 더 많은 문자열과 채워진 가져오기 테이블이 보여야 합니다.

엔트로피가 정상으로 돌아오고 API가 보인다면 언패킹이 성공했으며 실제 코드를 분석할 준비가 된 것입니다.

수동 언패킹에서 OEP가 의미하는 바를 떠올려 보십시오.

이제 언패킹을 이해하셨습니다.

• 패킹은 실제 코드를 숨깁니다. DIE/PEiD, 높은 엔트로피, 적은 가져오기 항목으로 이를 탐지할 수 있습니다.
• UPX와 같은 알려진 패커는 도구로 언패킹합니다(upx -d).
• 사용자 지정 패커의 경우 디버거에서 실행하고 OEP를 찾은 다음 Scylla로 덤프하고 가져오기 항목을 재구성하십시오.
• 기타 난독화(암호화된 문자열, 안티디버깅)는 사례별로 처리합니다.

악성 코드 리버스 엔지니어링 과정을 모두 마치셨습니다.