1q

11번 문제를 보면, 9번 문제랑 똑같습니다. 다만, 9번 문제는 Stolenbyte만을 답으로 구했다면, 11번 문제는 앞에 OEP와 함께 붙여서 답을 입력하라는 것입니다. http://suspected.tistory.com/entry/codeEngn-Basic-RCE-level09위의 링크는 9번 문제를 풀이한 것입니다. 참고하시고, OEP부분만 설명 드리겠습니다. Stolenbyte부분은 모두 찾을 것이라 생각하고 진행하겠습니다. OEP부분을 많은 사람들이 착각 하는게, OEP로 점프한 부분 0040100C 부분이 OEP라고 모두 생각을 합니다. 그런데, Stolenbyte를 NOP에 복구를 해보면 OEP는 0040100C -> 00401000으로 바뀌게 됩니다.

level10의 문제를 보면 OEP와 정답으로 가는 분기점 OPCODE를 구하라고 하네요. 실행을 해보면 입력을 받지 않을 뿐더러 밑에 등록되지 않았고, 다시 해보라고 하는 문자열이 출력됩니다. 일단, 한번 디버깅을 해봐야 될 것 같습니다. Exeinfo PE로 보면 패킹이 되어있습니다. 근데, 평소와 다르게 UPX로 되어 있지 않고 Aspack v2.0으로 패킹이 되어있습니다. UPX보다는 난이도가 있는 패킹문제라고 생각하시면 됩니다. 디버깅을 해보면 초기화면은 UPX와 다르지 않게 PUSHAD가 위치하고 있습니다. 하지만 UPX는 맨 마지막 코드에 JMP문을 타고 OEP로 가는 것이였다면, ASPACK은 다릅니다. 맨 마지막 코드인데, 패킹된 코드만 나올 뿐, JMP문은 보이지 않습니다. 이제부터 M..

level09의 힌트를 보시면 stolenByte를 구하라고 나옵니다. 낯선 단어이기에 설명하고 들어가겠습니다. ----------------------------------------------------------------------Stolenbyte-> Stolenbyte는 패커가 위치를 이동시킨 코드로써 보호된 프로그램의 코드의 윗부분(보통은 엔트리 포인트의 몇 개의 명령어)입니다. 이 부분의 명령어는 이동된 곳 이나 할당 받은 메모리 공간에서 실행됩니다. 보호된 프로세스의 메모리가 덤프되었을 때 Stolenbyte를 복구하지 못한다면 덤프된 실행파일은 작동하지 않을 수 있습니다.-----------------------------------------------------------------..

level08은 OEP를 구하면 됩니다. 즉, 패킹을 풀라는 거죠. 실행 화면입니다. 뜬금없이 계산기가.. Exeinfo PE를 실행했더니, UPX로 패킹이 되어 있습니다. 디버깅을 시작했더니, PUSHAD 다들 아시죠? 패킹이 되어있다는 뜻입니다. 저번 문제와 똑같이 JMP를 통해 풀어봅니다. 이게 꼼수로 푸는 것은 맞는데 정석으로 풀면 하나하나 트레이싱 하면 결국 이 JMP부분을 만나게 됩니다. 그냥 쉽게 맨 아래 JMP에 BP를 걸면 편합니다. 한번 답을 가릴테니 풀어보세요. OEP 코드 부분입니다.

level07의 문제의 힌트를 보면 컴퓨터 C 드라이브의 이름이 CodeEngn일 때 시리얼 생성? 흠.. 유추해 볼 수 있는 것은 C드라이브의 이름을 CodeEngn을 바꿔서 비교하는 루틴으로 가보면 될 것 같습니다. 실행을 해본 결과 아래의 오류를 출력합니다.Exeinfo PE로 둘러보면 패킹이 안되어 있고, 컴파일된 것을 보니 TASM/MASM 같은 어셈블러로 코드를 짠 것 같네요. 정상적인 메인입니다. 문자열을 입력을 GetDlgItemTextA로 가져옵니다. 이 부분에 BP를 걸어서 입력을 받아 보겠습니다. 일단, CodeEngn으로 입력하고 디버깅 해보겠습니다. 바로 밑의 함수는 GetVolumeInformation() API 함수인데, 그냥 현재 사용하는 드라이브를 가져오는 역할을 합니다. ..

level06의 힌트를 보시면 OEP와 시리얼을 원하네요. 정답을 입력할 때 주의할 것이 OEP값 맨 앞에 00을 빼먹는 분들이 많더라구요. 유의해서 입력하시길 바랍니다. 실행을 해보면 시리얼을 원하는 크랙미 입니다. 어느정도 몇 개 풀어보다보면 시리얼 구하는 크랙미는 프로그램 안에 들어가서 비교하는 루틴에 있으니 너무 겁먹지는 마세요. 답은 안에 있습니다. OEP를 구하라 해서 뭔가 했더니, UPX로 패킹이 되어있네요. UPX 툴로 풀어서 하는게 더욱 깔끔합니다. 하지만 정석으로 풀어보겠습니다. level05에서도 봤듯이 똑같은 루틴이네요. 맨 맡의 JMP문에 BP를 찍고 OEP로 넘어가봅시다. 이 주소 부분이 OEP입니다. Original Entry Point라고 합니다. 분석을 해보겠습니다. 메시지..

level05의 힌트를 보면 등록키를 물어보네요. 실행을 하면 인증과정이 나옵니다. 일단, 등록되지 않은 사람과 시리얼 키 값이 입력이 되있고 등록을 해보면 False가 나옵니다. 유추를 해보자면 정확한 user와 registration key를 가져와서 입력해야 하는 루틴이 있을 겁니다.Exeinfo PE로 본 결과 UPX로 패킹이 되어있네요. UPX의 대명사 PUSHAD가 보입니다. 이런 UPX는 쉽게 우회할 수가 있습니다. 코드가 짧기 때문에 맨 밑을 보면 JMP가 있을 겁니다. 그 부분을 BP걸고 들어가 봅시다. 메인 화면이 나오네요. 여기서부터 분석을 시작하면 되는데, 하다가 오류나면 처음부터 다시 해야하니까 스냅샷을 찍는 것을 추천드립니다. 또한 덤프를 뜨는 방법도 추천드립니다. 아까 오류창에..

level4의 힌트를 보시면 디버거를 탐지하는 함수를 찾으라고 합니다. 실행을 해보면 "정상"이라는 문자열이 계속 뜹니다. 디버거를 탐지하는 것 같네요. Exeinfo PE로 확인. 00408454 부분에서 디버거를 탐지하기에 들어가봅니다. 들어왔더니 점프를 합니다. 이부분이 디버거를 탐지하는 부분인 것 같은 냄새가 진동합니다.