일단 다운로드받은 apk파일을 까서 jeb로 확인해보면 자바코드자체는 매우 단순하게 되어있다.
단순히 JNI로 cook.so파일을 로딩하여 쓰고있는걸 볼 수 있다.
ida로 cook.so를 까서 분석을 해봤다.
일단 java쪽에서 따로 호출하는 네이티브 메소드도 없었고 마침 JNI_OnLoad함수도 존재해서 여기부터 분석을 시작했다.
일단 함수 내부를 봤는데 생각보다 코드가 길었고 시작 부분의 코드부터일단 분석해보기로 했다. 코드를 보면 sub_680이라는 함수의 리턴값을 통해 filename, path 등 여러 변수가 세팅되는걸 볼 수 있다. 이를 통해 sub_680함수가 인자값을 토대로 어떠한 문자열을 리턴하는 함수라는걸 대강 유추할 수 있었고 좀더 상세히 분석하기 위해 해당 함수의 내부로 들어가봤다.
이부분은 분석좀 하다가 넘어갔는데 문제푸는데 큰 지장은 없어서 대충 인자로 들어온값들을 통해 특정문자열이 세팅된 주소를 리턴해 주는 기능을 한다는것만 알고일단 넘어갔다.
이후 JNI_OnLoad 코드를 좀더 보다보면 다음과 같이 어떤 파일명으로 파일을 생성한 다음 해당 파일에다가 dex\n035라는 값이 존재하는 주소부터 0x15a8만큼 더한 주소까지의 바이트값들을 쓰고있는 것을 확인 할 수 있었다.
dex 포맷의 값을 특정 파일에다 쓰고있는 걸 보아 앱 실행 시 동적으로 임의의 dex파일을 만들고 있다는걸 알 수 있었다.
해당 파일의 내용으로 들어갈 byte 값들은 이미 알고있었기 때문에 이 영역의 값들을 긁어다가 dex파일을 임의로 만들어서 어떤 dex파일을 만들어내는지 확인해 보면 될 것 같았다.
먼저 1640~2BE7 까지의 값을 긁어서 새로운 dex파일을 만들었다.
해당 dex파일을 디컴파일해서 확인해봤더니 다음과 같은 코드가 나왔다.
떡하니 flag값이 있길래 이건줄 알았는데 바이트값들을 보니까 아스키로 변환이 안되는 값들이다. 근데 따로 이 값이 사용되거나 하는 곳도 없었다. 여기서 살짝 멘탈이 나갔는데 좀 자세히 보니까 cc라는 메소드가 정의는 되있는데 아무내용이 없는게 눈에들어왔다. 네이티브 메소드도 아닌데 뭐지 싶다가 내가 복구한 dex파일에서 cc메소드 부분이 디컴파일이 제대로 안이루어진 것 같다고 생각해 JNI_OnLoad함수를 다시 분석하기 시작했다.
쭉 보다보니 마지막부분쯤에 동적으로 생성한 dex파일을 삭제한다음 sub_710이란 함수가 호출되는 부분이 있었다.
sub_710함수 내부로 들어가서 뭐하는놈인지 분석을 시작해봤다.
쭉 보다보면 memcpy로 15A0부터 0x90만큼의 바이트들을 xor 0x5A로 돌려서 어떤메모리영역에 쓰고있는걸 볼 수 있었다. 이 영역이 cc함수와 연관되어 있을 거라고 생각했고 동적디버깅을 통해 해당 영역을 확인해보니 동적으로 생성한 dex파일의 0x720영역부터 0x90만큼인 것을 알 수 있었다.
이제 xor 5A한 값을 구하기 위해 일단 스크립트를 짠 뒤 dex파일을 새로만들고 디컴파일을 시도해봤다.
cc메소드가 정상적으로 디컴파일되어 나온것을 확인할 수 있었다.
이제 flag값과 같이 인자로 들어가는 k변수값을 찾아야되는데 이 값은 내가 입력한 값과 특정 byte들을 연산해서 유니코드로 적힌 값과 일치하면 되기때문에 간단히 xor연산해서 값을 구했다.
이제 이 값을 가지고 플래그랑 같이 특문으로된 이상한 메소드를 실행하면 플래그가 나올 것이다.
자바로 소스를 긁어다가 실행시켜서 돌리면 플래그가 나온다.
flag = CTF{bacon_lettuce_tomato_lobster_soul}
