게임 해킹툴 PE 파일들을 분석하다 보면...
확실히 예전에 비해 패킹(프로텍팅)된 파일이 많이 늘어난 것을 알 수 있습니다.
제가 분석하는 파일들의 대부분은 패킹이 되어있는 상태고,
어쩌다가 패킹 안 된 일반 파일을 보게되면 정말~ 감사(?)할 따름이죠...ㅎㅎㅎ
일반적으로는 패킹이 되었다고 하더라도,
메모리에서 실행이 되기 위해서는 패킹된 코드를 원래대로 풀어야하기 때문에
그 시점만 잘 잡아낸다면 패킹되기 전의 원본 코드에 대한 분석이 가능합니다.
지금 언급하는 샘플도 패킹이 되어있기에 메모리에 올려둔 상태로 코드 분석에 들어갔는데...
분명 가상화 코드는 아닌 것이 뭔가 조금 이상하더군요;;;
< 그림 01 > 메모리에 로딩된 코드
0x100020FB ~ 0x10002100 의 PUSH, CALL 명령은 분명 정상적인 코드인데...
0x10002105 부분의 코드가 조금 미심 쩍고... 그 이후는 이상합니다..
( 어셈에 익숙해지면 어느 정도 눈으로 판단이 가능하달까요..^^;;; )
그리고 0x1000211E 부터 나오는 MOV, PUSH, LEA 명령은 또 정상적인 코드입니다...
해킹툴 자체는 정상적으로 실행이 되고 있으니 저게 잘못된 코드는 아닐텐데 @_@??...
디스어셈블 된 내용만 보면 아무리봐도 정상적으로 실행이 가능할 것 같지는 않죠...
( 디버거에서 디스어셈블을 맞게 해줬다는 전제하에.... )
처음엔 CALL 명령 부분은 패커에서 API Redirection 같은 걸 처리하기 위해 했겠거니 하고,
대수롭지 않게 보고 넘겼는데...
혹시나 싶어서 CALL 명령쪽으로 들어가보니... ㅎㅎㅎ 이런게 있더군요;;
< 그림 02 > 0x1410004 의 내용
INC 명령은 대상 값을 + 1 시켜주는 명령입니다.
여기서는 [ESP] 의 값에 대해 + 1 해주고 있네요... ( 이거였습니다...!!!! @_@?? )
< 그림 01 > 에서 0x10002100 에 있는 "CALL 01410004" 명령이 실행될 때...
CALL 명령의 특성상 다음에 리턴될 주소를 [ESP] 에 넣게 됩니다...
< 그림 02 > 의 0x01410004 의 코드가 실행될 때 [ESP] 에는 0x10002105 가 들어가있는 상태죠...
그런데 [ESP] 의 값을 INC 명령으로 + 1 을 해주게 되면 [ESP] 의 값은 0x10002106 이 되고...
리턴될 주소 역시 0x10002106 이 되는거죠...
정리하면 0x10002105 의 한 바이트는 실행과는 무관한 더미코드라는 얘기입니다..
더미코드를 NOP 으로 바꿔보니 다음과 같이 보기 쉽게 출력이 되네요...
< 그림 03 > 더미코드 NOP 처리
뭐~ 이런 Anti-Disasm 방식(?)도 있다는 정리차원에서의 포스팅이었습니다.
'Reverse Engineering' 카테고리의 다른 글
shutdown 을 방어하라~! (4) | 2012.06.08 |
---|---|
2012 ~ 코드엔진 컨퍼런스 안내 (0) | 2012.06.04 |
2011~ 코드엔진 컨퍼런스 안내. (3) | 2011.06.14 |
같은 명령어, 다른 헥사코드~? (4) | 2011.02.13 |
Windows7 에서의 올리디버거 플러그인 셋팅~ (2) | 2010.03.27 |