'Wargame/reversing.kr'에 해당되는 글 21건

7문제 남았다. 나머지 문제들은 풀기에 현재 내지식이 너무 부족하단 느낌을 받았다. 빡세게 공부 더 하고 다시 와서 풀어봐야겠다. 

해당문제의 바이너리를 실행하면 crc체크에 걸려서 exe corrupted이라는 문자열을 출력한다.

에러 문자열 상단의 crc 체크를 진행하는 함수 내부를 진행해보면 다음과 같은 반복문이 나온다.

해당 코드에 대해 분석해보면 CALL AHK2.00458C2D 함수를 통해 파일의 처음부터 1바이트씩 값을 가져와 이 값을 토대로 CALL AHK2.00450F95 함수에서 crc 체크섬값을 만든다. 이 때 반복문이 탈출하는 값이 아래와 같이 32A1F란 값인데 이 값이 파일의 전체크기인가하고 헥스에디터로 열어서 확인하니 마지막 4바이트값은 포함이 안되있는걸 볼 수 있었다. 

왜 마지막 4바이트값은 포함이 안되었을까 생각해보다가 일단 넘어가서 이후로직을 분석하기 위해 구해진 체크섬값과 AAAAAAAA를 xor한 값을 통해 최종적으로 구한 값을 EBP-10영역의 값과 비교할 때 그 이유를 알게되었다. EBP-10의 값을 보면 39A64194라는 값이 존재하는데 이전의 체크섬 계산시 사용하지 않았던 파일의 마지막 4바이트값이었다.

여기까지 분석한 후 이 값만 맞춰주면되겠다 생각하고 EBP-10영역의 값을 522D85D4로 맞춰 JNZ에서 점프하지 않도록 진행하면 끝이겠거니 했는데 그대로 exe corrupted가 발생하는걸 보니 이후로직도 분석이 필요한 것 같았다.

해당부분은 처음에 계속 분석해봐도 감이 잡히지 않아 AHK1의 해당영역과 AHK2의 해당영역을 비교하면서 분석해봤다. 그 결과 정상적인 흐름으로 진행되려면 [EBP+EAX-34]의 16바이트 값과 [EBP+EAX-24]의 16바이트 값이 동일해야 했고 [EBP+EAX-24] 영역의 16바이트 값은 AHK1와 AHK2가 동일하게 박혀있었는데 [EBP+EAX-34] 값을 AHK2에서 가져오지 못하는걸 볼 수 있었다.

처음엔 CALL AHK2.00458D16 , CALL AHK2.00458C2D 함수를 분석하지 않고 적당히 flag변조해서 00450A04주소의 반복문으로 진입해 [EBP+EAX-34] 영역에 비교하는 값을 강제로 삽입하고 진행해봤는데 역시나 exe corrupted 메시지가 발생하였다.

어쩔 수 없이 위의 두 함수를 분석해본 결과 첫 CALL AHK2.00458D16 함수 호출 시 AHK1과 달리 AHK2에서 다음과 같은 에러가 발생하는걸 볼 수 있었고 해당 에러에 대해 찾아보니 SetFilePointer 함수 호출 시 새로운 파일 포인터 위치가 음수일 경우 발생하는 에러인걸 알 수 있었다. 참고(http://nimto.tistory.com/574)

CALL AHK2.00458D16 함수가 SetFilePointer과 같은 역할을 하는 함수라 추측했고 함수인자를 확인해보니 두번째 인자인 파일포인터를 옮길 지점의 값이 파일의 전체크기보다 훨씬 큰 값으로 세팅되어있는걸 볼 수 있었다.      

이 값때문에 일단 에러가 발생한거라고 생각했고 AHK1에서 이 값이 어떻게 들어가는지 확인해보니 32800이란 값이 들어가고 있는걸 확인할 수 있었다. 이후 DC9A8390을 일단 32800으로 변경하여 함수를 호출해보니 에러가 발생하지 않았고 이후 함수인 CALL AHK2.00458C2D 호출 후 871a80영역에 정상적으로 871a90영역과 동일한 값이 세팅되는걸 볼 수 있었다. 세팅된 값을 어떻게 가져오는거지하고 몇번 더 트레이싱해본결과  CALL AHK2.00458D16 함수를 통해 파일 포인터를 새로 지정한 뒤 해당 파일 포인터를 기준으로 CALL AHK2.00458C2D 함수를 호출하여 16바이트값을 가져와 871a80 영역에 저장하고 871a90의 값과 비교하는 형태인 것 같았다.

여기까지 진행하고 실행해보면 다음과 같이 문제가 나왔고 이 문제의 답을 구글링하면 정답을 구할 수 있었다.

문제를 풀면서 느낀점은 기본실력이 너무 부족하다는 것이었다. AHK1과 비교하면서 어찌어찌 풀긴했지만 문제자체를 완벽히 이해하지 못하고 풀었다는 생각이 들고 AHK1과 비교하지 않고 AHK2 바이너리만 가지고 풀었다면 과연 풀 수 있었을까 라는 생각이 들었다. 반성할 부분이 많고 더 열심히 공부해서 실력을 꾸준히 늘린 후에 다시한번 풀어보면서 그때는 완벽히 문제를 이해하고 풀어보도록 하겠다.

간단한 AutoHotkey 문제다.

문제에서 요구하는건 DecryptKey와 EXE's Key다.

AutoHotkey는 AutoHotkey 언어로된 소스코드를 exe로 컴파일할 때 디컴파일방지를 위해 나름대로 패스워드를 지정해서 디컴파일 시 이 패스워드를 정확히 입력해줘야 디컴파일이 정상적으로 이루어지게 된다. 이 디컴파일 시 필요한 패스워드가 위에서 요구하는 DecryptKey이고 Exe's Key는 디컴파일된 소스코드내에서 사용자에게 요구하고 있는 값으로 소스코드만 볼 수 있으면 찾아낼 수 있다.

DecryptKey같은 경우 바이너리가 실행될 때 메모리상에서 평문형태로 존재하고있어 쉽게 찾을 수가 있다.

어려운 문제는 아니었는데 처음에 UPX로 패킹되어있는걸 언팩한 바이너리로 분석을 하다가 미궁에 빠졌었다. 언팩한 파일을 실행하면 crc 체크 영역에 걸려서 에러루틴으로 빠지는데 이 부분을 분석하기 시작한게 문제였다. 결론적으로 내가 했던 행위는 AutoHotkey2 문제를 풀기위한 행위였고 AutoHotkey1에서 원하는 요구사항을 이루는데는 전혀 상관이없는 행위었다.

이걸 뒤늦게 깨닫긴 했는데 어차피 AutoHotkey2 문제도 풀어보게될 거니까 그때 도움이 될거라 생각한다. 쨋든 패킹된 바이너리를 실행해서 OEP까지 간다음 crc체크를 통해 에러가 터졌을때 출력되는 문자열 영역을 기준으로 바로 위에있는 crc체크 함수 내부를 분석하다보면 다음과 같이 Hash처리된 값하나가 ebx에 박히는걸 볼 수 있었다.   

요게 DecryptKey고 이걸가지고 exe2ahk.exe를 통해 디컴파일을 수행하면 다음과 같이 소스코드 내에서 exe's Key를 확인할 수 있다.

요거 두개를 md5 복호화해주는 사이트에서 돌려주면 정답을 구할 수 있다.

정체불명의 패커로 패킹되어 있었음. 일단 OEP까지 가야됬는데 언패킹과정에서 PEB.ProcessHeap을 통한 Static 안티 디버깅이 2회 존재했었음. 이거 우회하고 언패킹해서 OEP에서 메모리 덤프뜬다음 본격적으로 시작.

언패킹된 코드에도 NtQueryInformationProcess를 통한 Static 안티디버깅이 3회 존재하였음. 여기까지 우회하면 본격적으로 키값을 비교하는 루틴들이 나오는데 분석하기 귀찮게 하려고 여기저기 코드를 쓸데없이 꼬아놓고 키값들을 비교함. 꾸역꾸역 따라가서 xor해주는 값들을 통해 원본패스워드값 구해주면됨.

1월달에 풀어보려고 했을때 하루정도보고 멘탈나가서 접어놨었는데 한달사이에 그래도 실력이 조금 늘긴한듯.