Unpacking/Unpacking Tech 썸네일형 리스트형 Obsidium 관련 정리 어떻게 하다보니 Obsidium이라는 Protector를 접했다. 처음에는 디버거 조차 붙지 않아서 몇 번의 삽질 끝에 '일단' 디버거는 붙이는 방법을 기재한다. (1) 안티 디버깅 우회0. x64dbg 및 ScyllaHide 플러그인 설치 (혹은 커널 레벨에서의 안티 디버깅 관련 API를 우회하고 싶으면 TitanHide 이용) ScyllaHide : https://github.com/x64dbg/ScyllaHide/releases1. Single Step, Breakpoint, Access Violation, illegal instruction, Divide by zero 예외 무시 처리2. ScyllaHide 옵션을 Obsidium 옵션으로 설정3. Shift + F9로 예외 무시 실행 디버거의 로.. 더보기 VMProtect로 난독화 된 악성코드 분석에 대한 예시 해당 악성코드는 system32 폴더에 악성 DLL을 생성한 후에 winlogon 프로세스에 Injection을 한다.원본 코드는 다음과 같다. 내가 개발한 API 난독화 해제 모듈을 이용하면 다음과 같다. 정상적으로 API 호출이 보이고 파라미터들도 잘 보인다. 하지만 몇 가지 버그가 있어서 함수 Call을 제대로 잡지 못한다. 현재는 수정을 한 상태이다. 더보기 Stub Code 특성을 이용한 OEP 찾기 Visual Studio로 컴파일 되었다면 특유의 CRT 코드가 있다. Stub Code라고도 하는데 GetStartupInfo, GetVersion, GetCommandLine(A/W) 등의 함수를 호출한다. OEP를 찾는 일반적인 방법은 언패킹 또는 복호화 코드가 끝나고 원래의 코드로 점프하는 지점을 찾는 것이다. 하지만 컴파일러마다 삽입하는 Stub Code 특성을 이용해 OEP를 찾을 수 있다. 위에서 설명한 Stub Code에서 호출하는 함수 중 하나를 선택해서 브레이크 포인트를 거는 것인데 여기서는 GetStartupInfo 함수에 걸어보겠다. 실제로 VM Protector로 패킹된 파일의 OEP를 x64dbg를 이용해 찾아보겠다. GetStartupInfo 함수는 프로그램 특성에 따라 A(A.. 더보기 ASProtect UnPackMe 를 실행하면 메세지박스를 띄운다. 이를 이용하기 위해 MessageBox 함수에 BP 를 걸었다. 좀 더 BackTracking 을 하면 CALL 01CC0000 를 확인할 수 있다. 한 가지 재미있는 사실은 01CC0000 함수를 여러번 호출하는데 기존의 API 를 대체한 함수이다. 결론부터 말하면 일종의 API Handler 이다. Step Into 를 하다보면 Stack 에 원래 호출하려던 API 주소를 PUSH 하는데 다음의 JMP 에서 RET 를 통해 원래 API 로 점프한다. IAT 복구 방법은 CALL 01CC0000 를 하나씩 원래 API Call 로 바꾸는 것이다. 하지만 상당한 노가다이므로 자동화 작업이 필요하다. 이건 나중에... 더보기 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 하는 방법으로는 중요한 함수를 찾을 수 없을.. 더보기 Themida 가 사용하는 API Redirect Code 를 잔혹하게 난독화하는 것으로 유명한 Themida 라는 Protector 에서 주로 사용하는 기법은 Virtualization , API Redirect, 그리고 기타 Code Obfuscation 기법이 있겠다. 그 중에서 API Redirect 기법에 대해서 적어보겠다. 사실 API Redirect 기법은 오래 전부터 사용한 기법이다. 예를 들어 CreateFile 함수를 호출하는 프로그램을 Protect 로 Packing 했다고 하자. PeSpin 경우에는 Call CreateFile 대신에 Call 2021453 와 같이 괴상한 주소로 Call 로 바꾼다. 그리고 2021453 으로 점프하면 mov edi,edi push ebp mov ebp,esp 명령이 있고 또 다시 JMP 문이 있.. 더보기 OEP 를 찾는 몇 가지 편법 Unpacking 작업에서 가장 중요하고 첫 번째로 진행하는 과정은 OEP 를 찾는 과정이다. 요즘 Packer/Protector 들의 보호기법이 악랄해지고, 각종 Trap 들을 많이 설치해서 OEP 찾는 과정도 순탄치가 않다. 기본적인 원리를 무시한 상태로 편법만을 쓰는 것을 선호하지 않지만, 구버전의 Packer/Protector 로 Packing 된 바이너리의 OEP 를 빠르게 찾는 방법을 지금까지 공부한 내용만큼 정리해본다. 1.일반적으로 Decode 루틴 진입 전에 PUSHAD 를 해서 기존의 레지스터들을 백업한다. 그 다음은 POPAD 를 이용해서 레지스터들을 복구한다. Hardware Breakpoint 를 이용해서 해당 Stack 에 접근 시도하는 부분을 찾은 다음에 근처에 JMP 명령, .. 더보기 API Redirect 기법이 적용된 Protector 에 대한 교과서적 접근 방법 OEP 찾는 것도 찾는 것이지만 기껏 OEP 찾았더니 주요 API 개미 새끼 한 마리 안 나오는 경우가 있다. 거의 API Redirect 가 적용된 case 이다. 악성코드 분석이나 패치 작업 시에 자주 쓰는 API 를 호출하는 부분을 위주로 분석하면 (예를 들어 시리얼 처리 루틴을 분석하고 싶으면 GetDlgItemText 함수를 호출하는 부분 위주로 분석) 상당히 작업을 단축할 수 있다. 하지만 API 를 모르면 분석 작업이 굉장히 고달파진다. 이처럼 API 를 숨겨주는 기능을 API Redirect 기법이라고 한다. 정확히는 결국 API 호출하는 것은 맞지만 대놓고 해당 API 주소가 있는 IAT 가 아닌 Protector 가 독단적으로 구성한 테이블을 참고해서 호출하도록, 말 그대로 Redire.. 더보기 이전 1 다음
