본문 바로가기

Protector 가 사용하는 난독화가 IAT 만 참고하는가? Packer는 기본적으로 IAT 를 파괴한다. 정확히는 압축을 위해서 원래의 IAT 를 희생하면서까지 크기를 줄이고 실행 중에 Packer 에서 자체적으로 IAT 를 만든다고 할 수 있겠다. Protector를 Packer + 각종 난독화 기능이 추가된 Packer로 생각하면 어떻게 접근하겠는가? 아래 글에서 API 를 쓰지 않은 사용자 함수 (XOR 로 이루어진 디코딩 함수) 를 난독화한다고 하자. Protector 에서는 이걸 어떻게 난독화 시키겠는가? 시스템 API 는 user32.dll kernel32.dll 등 코어 DLL 에 포함되어있다. 가장 쉬운 방법으로는 1. Packing 하기 전 파일의 IAT 를 싸그리 조사해서 어떤 함수를 사용하는지 확인한다.2. Packing 과정에서 원본 IAT.. 더보기
Hooking 과 난독화(Obfuscation) 의 관계 Hooking 도 엄밀히 보면 Stolen Byte 와 흡사하다. 예를 들면 Target 이라는 함수를 Hooking 할 때 첫 5바이트를 Hooking 작업을 위한 함수를 Call 하고 5바이트 이후의 코드로 흐름을 바꿀 것이다. 5바이트를 내가 이미 뽀려간다는 점에서 Stolen Byte 와 흡사하다. 또한 API Redirect 와 유사한 행위를 한다. 생각해보자. API Redirect 란 원래 API 주소를 자신의 테이블로 박아둔다음 한 번 내지 수십 번의 Call 을 호출해서 실제 API 주소가 적힌 테이블로 점프하는 것이다. Hooking 도 엄밀히 말하면 자신이 Custom 한 함수 (Hooking 해서 작업을 수행하는 함수) 를 타고 원래의 함수로 점프하는 것이다. 이처럼 Unpackin.. 더보기
API Backtrace 를 이용한 API 역난독화, 과연 만능일까? 요즘 API Deobfuscation 에 관심이 많고 관련 논문과 발표 자료들을 연구하는 중이다. 이 참에 DBI 에 대해서도 알게 되었고. 하지만 한 가지 의문이 들었는데 바로 기존의 API 를 쓰지 않고 동작하는 함수를 난독화하면 어떤 기준으로 backtrace 할 것인가에 대한 주제이다. 예를 들어 랜섬웨어가 있다고 하자. 제작자가 문서 파일을 암호화하기 위해서 OpenSSL 이나 기타 암호 라이브러리를 쓰는 게 아니라 독자적으로 xor 연산등을 이용해서 암호화 함수를 만들었고 함수의 이름을 Encrypt 라고 하자. 만약 Packer 가 기존 API 뿐 만 아니라 Custom 함수까지 난독화 시킨다면 더 이상 API 를 호출하는 루틴을 backtrace 하는 방법으로는 중요한 함수를 찾을 수 없을.. 더보기