VxLang 개발 기록(3)

새로운 기능이 생각났다. 기존 난독화와 가상화를 섞는 방법이다. 일단...

---

엄밀히 말하면 이 것은 개인 프로젝트로, 비공개 상태였으며 프로젝트가 터지기 전부터 개발한 내용이다.

내가 개인적으로 PoC 하던 패커는 크게 2가지 방법이었다. 하나는 DLL 모듈을 EXE와 통합하는 방법이며, 다른 하나는 이전과 동일하지만 쉘 코드에서 모든 코어 기능을 수행하는 방법이다.

일단 DLL을 병합하는 패커는 개발이 정말 편했다. 그냥 DLL을 작성하면, 패커 코어에서 이를 분해하여 EXE 위에 DLL을 덮는 방법이었다. 시스템 적인 문제(TLS/Exception/Etc.)가 한 번에 해결된 것이다.

다만 조금 문제가 있었다. 나는 개발하는 중간중간 특정 리버싱 사이트들에 간단한 게임(Crack-me)을 vxlang/vxil이라는 이름으로 만들어 제출했는데, DLL 병합의 경우 여러모로 진입점부터 추적이 되는 문제가 있었다. 실력 좋은 리버스 엔지니어는 그렇다 치고, 프리다(Frida)라는 도구에 매우 취약했기에 빠르게 다음 패커를 준비하게 되었다.

다음 방법은 쉘 코드를 띄우고, 메모리 속성을 변조하지 못하게 하는 방식이었다. 결론적으로 진입점을 기준으로 추적은 어려웠기에 이 방향을 채택하게 되었다. 하지만 이 방식은 여전히 유지/보수 문제가 있었기에 확장 모듈이라는 개념을 두어 쉘 코드 중간에 고급 언어를 사용할 수 있게 하였다. 이를 통해 패커를 사용자가 편하게 커스텀 가능하게 한 것이다.

패커가 대충 완료된 후, 가장 큰 난관이 시작되었다.
제3의 코드 난독화 도구를 내재화하는 것이었다. 코드 난독화는 패커와는 또 다른 어려움이며, 패커가 자생할 수 있는 필수적인 요소였다.

우선 이전에 언급한 고정 크기의 더미 코드를 삽입하는 방식을 수정하였다. 코드 간의 거리를 랜덤 하게 벌리고, 어셈블러를 만들어 패킹 타임에 코드가 생성되도록 하였다. 이후, 원본 인스트럭션을 읽기 어렵도록 다른 코드로 대체하는 데 성공했다. 계속 문제가 되었던 부분에 변화를 줄 수 있게 된 것이다. 내가 발견한 문제가 모두 해결된 후, PoC에서 발견된 내용을 넌지시 공유하였다.

이걸 굳이 내재화해야 할까?

별다른 관심은 없어 보였다. 단지 돌아온 것은 여러 질문뿐이었다. "얼마 되지도 않는 솔루션", "검증되지 않은 도구", 여기에 또 새로운 제3의 난독화 도구 적용까지. 내가 할 말은 더 없었다.

더 슬픈 건 좌초된 프로젝트는 여전히 잘 되어 간다는 것으로 위에 보고되었다. 결국 나는 패킹 타임에 랜덤 한 더미 코드까지 생성되도록 하여 회사 저장소에 올리게 되었고, 원본 브랜치는 VxLang이란 이름으로 개발하게 되었다.

---

여담 1.
이 시기는 국내외 대형 게임 회사에서 자사의 기술로 만들어진 패커/난독화 도구를 통해 다양한 코드-난독화 형태가 적용되던 상태였다. 내가 이걸 해내더라도 1년 이상은 뒤처진 기술력인 것이다.

여담 2.
내제화가 되지 않는다면, 하나의 도구에 대한 분석 방법이 나오면 대처가 불가능하다. 또, 예외 처리와 동작 속도, 파일 크기 등에 대한 최적화도 해결이 불가능하다.

여담 3.
이 내용 이후로 여기서 무엇인가 하는 것은 포기했다.

---

Believe you can and you’re halfway there.