본문 바로가기

Memo

아이다 헥스레이 디컴파일러 문제점(IDA hexray decompiler problem)

오랜만에 포스팅을 하게되었습니다. 잡글로 찾아뵙게 되네요..ㅠ

 

IDA 디컴파일시 보통 아래와같이 디컴파일이 이루어집니다.

char dest; // [sp+12h] [bp-202h]@1
char len1; // [sp+212h] [bp-2h]@1
char len2; // [sp+213h] [bp-1h]@1

 

주석을 보면 먼저 h는 16진수를 의미하니 10진수로 변환하면 다음과 같습니다.

dest는 [sp+18][bp-514]

len1은 [sp+530][bp-2]

len2는 [sp+531][bp-1]

할당된 공간 514byte중 char형 변수 2개를 빼면 dest[512]가 되겠습니다.

 

따라서 위의 주석대로라면 현재 위 변수들이 스택에 올라왔을때의 상황은 아래와 같습니다.

[ len2 1 byte] 높은주소

[ len1 1 byte]      |

[dest 512 byte] 낮은주소

 

하지만 C/C++ 변수의 경우 선언 시 스택에는 아래와 같이 쌓입니다.

int a;

int b;

int c;

 

위와같이 선언되었다 가정하면

[     r  e   t     ] 높은주소

[     s  f  p     ]

[ 더미&guard ] //더미와 방어기법은 컴파일러의 종류나 버전에 따라 차이가 납니다.

[        a        ]       |

[        b        ]

[        c        ] 낮은주소

 

이렇게 나중에 선언된 변수가 낮은주소가 됩니다.

 

즉, IDA는 디컴파일시에 변수순서를 거꾸로 출력해줍니다. (주석만 제대로 써주고 츤츤..)

보통 선언된 순서야 별 상관없지만 BOF 문제를 풀게되면 선언 순서가 중요해집니다.

그대로 디컴파일한 결과를 문제와 똑같은 소스라고 믿었다간 골룸.

주석에는 스택구조대로 잘 나오지만 그렇다고 소스를 그대로 복붙해서 쓸땐 참고하세요.

모두 쓰시면서 혼동하거나 낚이는 일이 없도록 합시다.

'Memo' 카테고리의 다른 글

어셈블리어 상태 레지스터(assembly status register)  (0) 2012.10.11
외국 Wargame 사이트 목록  (0) 2012.09.23
간편한 RSA 인증  (0) 2012.09.22