반응형


게임 해킹툴 PE 파일들을 분석하다 보면...


확실히 예전에 비해 패킹(프로텍팅)된 파일이 많이 늘어난 것을 알 수 있습니다.


제가 분석하는 파일들의 대부분은 패킹이 되어있는 상태고,


어쩌다가 패킹 안 된 일반 파일을 보게되면 정말~ 감사(?)할 따름이죠...ㅎㅎㅎ



일반적으로는 패킹이 되었다고 하더라도,


메모리에서 실행이 되기 위해서는 패킹된 코드를 원래대로 풀어야하기 때문에


그 시점만 잘 잡아낸다면 패킹되기 전의 원본 코드에 대한 분석이 가능합니다.



지금 언급하는 샘플도 패킹이 되어있기에 메모리에 올려둔 상태로 코드 분석에 들어갔는데...


분명 가상화 코드는 아닌 것이 뭔가 조금 이상하더군요;;;



< 그림 01 > 메모리에 로딩된 코드



0x100020FB ~ 0x10002100PUSH, 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 방식(?)도 있다는 정리차원에서의 포스팅이었습니다.





반응형
AND