'Wargame'에 해당되는 글 454건

xcz.kr PROB:17번 문제다.

점수는 100 point.

짱게임이란 놈한테 xcz.kr에 있는 비밀번호를 해킹당한거 같다.

패킷파일이 있고 이를 확인해보면 될 것 같다.

먼저, 열어보니 패킷양이 상당하다. 필터링을 해야할 것 같다. 먼저 비밀번호가 xcz.kr에 있기 때문에 xcz.kr에 접근했을 거라 생각하고 xcz.kr ip를 필터링 해봤다.

아직 양이 상당하다. 좀더 패킷을 필터링해야 할 것 같다.

이 떄 보면 xcz.kr를 대상으로 하나의 사설아이피가 지속적으로 패킷을 보내는데 이게 아마 사용자의 PC IP 인 것 같다. 또한 지문에서 주어진 정보를 잘 생각해보면 사용자와 서버 사이의 http 통신 중에 패킷을 스니핑 당하거나 세션 하이재킹이 있었을 것으로 추측된다.

양이 꽤 많이 줄었다.

마지막으로 사용자가 ZZANGGAME이라 했으니 id가 이와 비슷할거라 유추된다. 이를 좀 완화시켜 패킷에 ZANG을 포함하는 것만 따로 필터링한다.

5개의 패킷을 하나씩 Follow TCP Stream 해보면 다음과 같이

 Join Success라는 성공창을 보여주는 패킷의 pw값이 비밀번호라는 걸 알 수 있다.

성공!

xcz.kr PROB:13번 문제다.

점수는 150point.

네트워크 관련 복구 문제인 것 같다.

확장자를 알 수 없는 파일을 하나 주는데 네트워크 문제인 만큼 파일이 pcap형식의 파일일 거라고 생각하고 hex 에디터로 열어봤다.

근데 pcap의 시그니처 헥스 값인 D4 C3 B2 A1가 아니고 처음보는 이상한 값이 나와있다. 흠..

무슨 파일의 시그니처 값인지 찾아보니 pcapng의 시그니처 헥스 값이었다. pcapng는 pcap에서 조금

더 확장된 버전정도로 생각하면 될 것 같다. 

확장자를 바꿔서 파일을 열어봤다.

27.255.67.44라는 서버가 172.30.1.6이라는 사용자IP에게 대량의 응답패킷을 보내주는걸 봐서 http 통신을 하고있는 것 같다.

다음과 같이 필터링해봤다.

treasure1, treasure2, tresure3이라는 서버자원을 지속적으로 요청하고 서버가 이에 png파일 형식으로 응답해주는걸 볼 수 있다.
실제로 Follow tcp stream을 해보면 서버가 png파일 형식으로 응답해 주는걸 확인할 수 있다.

확장자명 밑에 헥스값들을 추출해 이미지를 복원할 수 도 있지만 귀찮은 작업이기 때문에 와이어샤크에 객체 추출 기능을 사용하기로 했다.

treasuer1,2,3에 대해 png확장자명을 주고 열어보았다.

별게 없다. 2,3번째 파일은 아예 파일이 열리지도 않는다.

흠..2,3 번째 파일의 바이트 값들을 확인해보니 3번째 파일의 맨 마지막에 다음과 같은 PNG 파일의 푸터 시그니처가 보인다. 즉, 3개의 파일이 나누어 진 것을 알 수 있다.

3개의 파일을 합친 후 실행시켜봤다.

성공!

파일을 실행해보면 간단한 총게임이 하나 나오고 펭귄들을 죽일 수 있다.

Ollydbg로 까서 실행한 후에 문자열을 확인해 보니 다음과 같이 성공문자열이 있었고 메시지 박스 내에 이상한 문자들이 박혀있는게 보였다. 이 부분에 하드웨어 BP걸고 돌려봤다.

쭉 트레이싱 하다보니 해당부분에서 멈춰서 분석을 해보니 캐릭터 별로 EAX에 특정 값(0x00~0x32)이 할당되어 있고 이 값을 토대로 계산된 ECX+1199190 주소에 각 캐릭터의 피 값이 담겨있었다. 이 부분이 0이하가 되면 XOR BYTE PTR DS: [EAX+1197028],CL 구문에 의해 성공문자열에 담겨있던 이상한 문자들이 복호화되어 나타나는 것을 확인할 수 있었다.이 때 EAX에는 각 캐릭터의 번호가, CL에서 캐릭터 번호*4의 값이 있는 것을 확인할 수 있었고 이를 토대로 코드를 짜서 돌렸다.

잘나온당.

파일을 실행시켜 보면 이미지를 그리라하고 아무거나 그려넘기면 틀렸다고 나온다.

내가 그린 그림의 대한 어떤 값과 해당 파일이 가지고 이름 그림에 대한 값이 비교될 것이고 그 해당값을 알아내면 끝.

위의 루틴을 보면 ECX에 있는 값과 EAX+ECX에 있는 값을 15F90(90000)번 비교한 후 실패메시지로 넘어가는 것을 볼 수 있다.
해당 메모리 주소로 가보면 ECX에는 내가 그린 이미지에 대한 값이, EAX+ECX에는 내가 그린 이미지에 대한 값이 저장되어 있다.
그렇다면 EAX+ECX메모리 주소에서 15E90만큼의 값을 구해오면 된다.
 

맨 처음 EAX+ECX 메모리 주소값인 0047E060에서 15E90을 더한 00493FF0 까지의 값을 구해온 뒤 내가그린 값인 ECX부터 ECX + 15E90까지의 값에 정답 값을 넣어주고 실행시켜봤다.

뭔가 정답이 나올줄 알았는데 틀렸다는 메시지만 안나올뿐 아무런 반응이 없었다. 그렇다면 이 값을 가지고 어떠한 이미지 파일을 만들면 될 것 같았다. 그래서 해당 코드부터 위쪽을 좀 봤더니 요런게 있었다.

CreateCompatibleBitmap이란 함수로 가로 200 세로 150짜리 bitmap 이미지 파일을 생성한 것을 볼 수 있었다. 그렇다면 이 실행파일은 위의 크기의 bitmap파일에 기존에 비교했던 값들을 담고 있었다고 생각해봤다. 그래서 그림판으로 bitmap 파일을 하나 만든 후 hexeditor로 정답값에 대한 binary값을 넣어봤다.

만들어진 bitmap 파일을 열어보니 정답이 나왔당.

파일 실행 후 아무값이나 넣어보면 Wrong이라는 문자열과 함께 작동이 중지됬다고 나온다.

Ollydbg로 실행해보니 다음 MOV BYTE PTR DS:[EAX],90 이 부분에서 violation이 발생해 더이상 진행이 안되고 있었다. 90(NOP) 값을 넣는 EAX부분이 60160646 이라는 값인걸 보니 존재하지 않는 주소에다 NOP를 박으려고 에러가 났다.
임의의 주소값 아무거나 넣고 트레이싱해보니 요런 루틴으로 넘어왔다.

SetDIgItemTexTA 함수를 통해 어떤 문자열을 세팅하는데 그 위의 JMP구문이 있어서 무조건 이 부분을 지나치게 된다. 요상한 ascii 문자열 값이 담기는데 뭔지 궁금해서 jmp구문 수정해서 일단 해당 부분으로 넘어가게 해봤더니 Correct!란 값이 떳다. 이루틴으로 들어갈 수 있게 해야 될 것 같다.

그렇다면 JMP 구문을 어떻게든 패치를 해야되는데 이전에 에러 발생을 시켰던 특정 주소값에 NOP 코드를 박는 부분을 활용하면 될 것 같다. 일단 테스트 해보자.

EAX값에 JMP 코드가 있던 주소값을 박아서 넘기니 실제로 NOP처리가 되서 성공루틴으로 가는걸 볼 수 있었다. 그럼 내가 입력한 값을 통해 이를 가능하게 해야되는데 내가 입력한 값이 EAX값에 어떠한 영향을 주고있는지 테스트해봤다.

1넣었을때 601605CC , 2넣었을떄 601605CD가 나온걸로봐선 601605CB라는 base값에 내가 입력한 값을 16진수로 변환해서 더하고있는걸 알 수 있었다.
그렇다면 601605CB + 입력값 = 00401071 요렇게 나와야하기 때문에
100401071 - 601605CB 한 16진수값을 10진수로 바꿔 넘기면 끝이당.

파일을 실행해보면 다음과 같이 뜬다.

ollyDbg로 까서 보면 첫번째 비교 루틴을 통해 두번째 값 a(61)인 것을 확인.

두 번째 비교 루틴에서 00401150 함수를 콜해 5y와 입력한 값의 3,4번째 값을 비교한다. 이를 통해 3,4번째 값 5y확인.

세 번째 비교 루틴에서 R3versing과 5번째부터 마지막글자까지 비교한다.

마지막으로 첫 번째 글자가 E(45)인지 비교한 후 성공 문자열 띄운다.

해당 문제의 exe파일 다운로드 후 실행하면 다음과 같이 빈화면이 하나 뜨고 아무런 반응이 없다.

peid 열어보니 뭘로 패킹이 되어있는지 알 수가 없다.

Ollydbg로 연 다음 쭉 트레이싱 하다보면 packing 된 프로그램 특성상 unpacking 과정을 거치기 위해 암호화 된 코드들을 풀어주는 복호화 루틴을 거치게 되고 실제로 여러 구간에서 이러한 복호화 작업들이 이루어지고 있다. 최종적으로 복호화가 모두 끝나면 언패킹 된 코드의 OEP로 점프한당.

실제로 가보면 OEP가 나온당.