http://korea.gnu.org/manual/release/gdb/gdb.html

아직도 gdb를 모르는게 많다..

키를 체크하는 알고리즘을 ida에서 디컴파일한 모습입니다.

입력값을 byte[5][4]라고 생각하고 행끼리 더해준 값이 0xdeadbeef로 나오면 되는 간단한 알고리즘입니다.

체크 알고리즘에 bp를 걸고 우회해 보았으나 플래그를 출력하는 과정에서 입력값을 사용하기에 아마 0xdeadbeef를 만들어주는 입력값을 실제로 입력해야 하는 것 같습니다.

(python -c 'print "\x01\x01\x01\x01"*4+"\xeb\xba\xa9\xda"';cat)|./task9_x86_64_46d01fe312d35ecf69c4ff8ab8ace75d080891dc

0x00을 넣을 수 없기 때문에 파이썬 스크립트와 파이프를 이용해서 0x01 네바이트를 네번 넣어준 후 0xdeadbeef-0x04040404을 넣어주니 플래그가 출력되었습니다.

2015 인코그니토 inside out 문제 풀이입니다.

확장자를 exe로 바꿔서 실행시켜 보았습니다.

인사이드 아운 애니메이션 캐릭터들이 등장하는 프로그램이군요.

플래그가 있는곳의 단서를 찾기 위해 PEview로 열어봤습니다.

data 섹션에 수상한 문자열이 있습니다. 대회때 눈이 돌아가서 알카노이드만 붙잡고 씨름하다 보니 write up을 보고나서 이 문제를 접해서 저부분이 플래그인 것을 미리 알아버리긴 햇지만...ㅋㅋ

모르고 봤어도 저부분이 인코딩된 플래그일 것이라고는 반드시 의심했을 것 같네요. 비트맵으로 보이지도 않고 일반적인 정보를 인코딩해서 data 섹션에 박아넣을 이유도 없으니까요.

IDA로 해당 부분을 찾아냈습니다. XREF하는 부분을 따라가 봅시다.

bp로 지정한 부분에서 해당 섹션에 접근하고 있습니다.

코드를 다 볼 필요 없이 call 위주로 살펴보면 memset과 strlen이 호출되는군요.

그렇다면 이 다음에 jmp하는 13C182D부분에서 플래그를 디코딩 할 확률이 매우 높아 보입니다.

점프한 부분에 bp를 걸고 동적분석을 해보았습니다.

쓸데없어 보이는 복잡한 코드가 많지만 핵심 동작은 매우 단순합니다.

먼저 013C1841부분까지 코드를 넘겨서 ecx에 들어가는 str[eax]가 아까 찾은 의심스런 문자 배열인 것을 확인했습니다.

[ebp+6A8]이 count 역할을 하는 메모리 영역이고 eax에 넘겨서 매번 루프를 돌때 마다 eax+1을 해준 되 다시 받아옵니다.

[ebp+6b4]부분은 0x29값을 가지고 있고 변하지 않습니다. 이 0x29를 edx에 전달한 후 거기에서 카운터 값인 [ebp+6A8]을 빼줍니다. 

그 후에 ecx와 edx를 xor 연산하여 다시 ecx로 넣어줍니다. 하지만 이 ecx는 다음 루프에서 바로 덮어씌우지고 어디론가 전달되거나 출력되지 않는군요.

xor연산 직후에 ECX값을 ascii값으로 생각하고 받아쓰며 유의미한 값이 나오는지 보았습니다.

처음에 전체 흐름을 파악하기 위해 한바퀴 돌려서 t는 놓쳤지만 이정도 찍어보니 the flag is ~~ 로 나올것으로 보이는군요. 이제 다 풀었습니다.

위 코드와 같은 알고리즘으로 디코딩해주는 간단한 프로그램을 만들어서 플래그를 찍어보겠습니다.

플래그는 B1NG_B0NG_is_a_Friend_oF_ours 였습니다.