API Backtrace 를 이용한 API 역난독화, 과연 만능일까?

 요즘 API Deobfuscation 에 관심이 많고 관련 논문과 발표 자료들을 연구하는 중이다. 이 참에 DBI 에 대해서도 알게 되었고. 하지만 한 가지 의문이 들었는데 바로 기존의 API 를 쓰지 않고 동작하는 함수를 난독화하면 어떤 기준으로 backtrace 할 것인가에 대한 주제이다. 

 예를 들어 랜섬웨어가 있다고 하자. 제작자가 문서 파일을 암호화하기 위해서 OpenSSL 이나 기타 암호 라이브러리를 쓰는 게 아니라 독자적으로 xor 연산등을 이용해서 암호화 함수를 만들었고 함수의 이름을 Encrypt 라고 하자.

 만약 Packer 가 기존 API 뿐 만 아니라 Custom 함수까지 난독화 시킨다면 더 이상 API 를 호출하는 루틴을 backtrace 하는 방법으로는 중요한 함수를 찾을 수 없을 것이다.

핵심 루틴은 Encrypt 인데 API 호출 추적만으로는 죽었다 깨어나도 찾을 수 없을 거다.  결국 최소 암호화 루틴이 존재한다는 사실 조차 파악하지 못한 채 그냥 파일을 손상시킨다고 결론짓고 끝낸다면 비극이 아닐 수 없다. (물론 극단적인 예를 들었다는 점 양해바란다.)

 혹자는 다음과 같은 방법을 생각할 수도 있겠다. 

 문서를 암호화 하기 위해서는 먼저 문서를 열어야 할 것이다. OpenFile 이라는 API 를 사용할텐데 요즘은 OpenFile 같이 공개된 API 가 아니라 최소 한 단계 이상의 Native API 를 사용하는 추세다. OpenFile 함수를 뚫어지게 봐도 OpenFile 이 실제로 호출하는 ZwOpenFile 함수를 바로 호출하면 소용없다. 또한 Stolen Byte 를 응용해서 API 코드 몇 줄을 미리 가져다가 자체적으로 실행하고 다음 부분을 Call 한다면 mov esi, esi 라던가 push ebp 등 첫 번째 코드에 BP 를 걸어도 넘어가게 될 것이다. 뭐 어쨋든 ZwOpenFile 호출 부분을 찾았다고 치자. 그리고 몇 번 Step 을 실행하면 암호화 루틴인 Encrypt 함수 호출을 알 수 있지 않냐고.

 하지만 외관상 어떤 행동을 하는지 전혀 파악되지 않는 악성코드 또는 악성 행위를 하기 위해서 어떤 API 가 사용되는지 전혀 파악이 안 된다면 힘들 것이다. 뭐 어차피 모든 API 호출을 추적한다면 수상쩍은 API 들을 골라서 분석하는 방법도 있을 거 같다.

 그리고 API 코드 전체를 코딩해서 Custom 함수로 박아버리는 미친놈이 있다면 어떻게 대응할 것인지도 고민이다. 어쨋든 핵심은 패커가 난독화를 할 때 API 뿐 만 아니라 사용자가 만든 함수까지 난독화하면? 이러한 내 생각들이 개짓거리 밖에 되지 않을 수 있다.  어쨋든 API 함수 주소로 점프하는 구간을 Tracing 하는 방법을 이용하면 Custom 함수 등 API 함수 주소를 이용하지 않은 함수에 대해서 어떻게 접근할 것인가에 대한 관점이 본 포스팅의 주제였다. 근데 생각해보면 악성행위에 핵심 API 를 호출하는 건 마찬가지일테니, API 만 어떻게든 보이면 추적자체는 어렵지 않을 듯 싶다. 연구가 진행됨에 따라 이에 대한 의문도 풀릴 수도 있고 과거에 왜 이런 병신같은 생각을 했을까? 하는 생각도 들지도.