본문 바로가기

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 문제를 풀게되면 선언 순서가 중요해집니다.

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

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

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

  • 김똘똘 2013.07.15 23:20

    그건 헥스레이가 거꾸로 출력해주는게 아니라, 컴파일러가 순서를 바꾼 걸 겁니다.
    헥스레이는 소스를 모릅니다. 그저 변수의 메모리 위치에 따라 디컴파일을 해줄 뿐이죠.
    만약 소스와 헥스레이 내용이 반대라면, 그건 헥스레이가 뭘 잘못 출력했다기 보다
    컴파일러가 순서를 바꿔 컴파일 했기 때문일 겁니다.

  • p0p0pret 2013.08.23 21:39 신고

    ? 제 말은 컴파일러는 원래 저 순서로 메모리에 올리는데 헥스레이는 컴파일러가 메모리를 올리는 순서에 맞게 되있지 않다는 것 뿐입니다.