이번 문제는 ELF 파일구조에 대한 문제였다. 

ELF 파일 리버싱은 익숙하지 않기도 하고, 도대체 익숙한건 뭔지- -,  말로만 듣던 난독화 기법 중 가상머신이 적용된 내용이라 사전학습이 좀 필요했다. 개념을 잡기에 괜찮은 사이트를 하나 발견했는데 아래에 주소를 적어놓았으니 관심있는 사람은 한번쯤 읽어볼만 하다. 

간단히 가상머신 기법에 대한 설명을 하자면,

실행 프로그램안에 별도의 OPCODE를 정의하고 해당 OPCODE가 동작할 수 있는 기반을 마련하여 개발자가 정의한 OPCODE로 프로그램을 동작하는 것이다. 그러기 위해선 일단 사용자가 정의한 OPCODE가 동작할 수 있는 메모리(스택, 레지스터 등)가 필요하고 정의한 OPCODE가 어떻게 동작하는 지에 대한 정의는 필수적이다. 

그럼 문제풀이를 시작하도록 하겠다. 

우선 문제를 동작시키면 아래와 같은 형태로 실행된다. 여러 다른 문제들과 같이 프로그램 내에 정의된 값을 맞추는 것이다. 

내부를 보기 위해 디스에셈블러를 이용하여 한번 열어보았다. 그러니 아래처럼 툴이 정상적으로 캐치를 하지 못한다. 

처음부터 호락호락하지 않은 문제구나 싶었다. :( 

왜 그럴까 싶었는데 프로그램의 EP가 프로그램 헤더에서 정의한 영역을 벗어나서 그런거 같았다. 그래서 현재 EP에 있던 명령어를 실행한 뒤 상태로 만들어놓고 EP를 수정한 뒤 다시 로드하니 아래처럼 인식을 하게 되었다. 

근데 저 위에 로직은 문제 해결에 핵심적인 부분은 아니다. 이는 문제를 생성하기 위한 기반을 만드는 로직인 것 같다. 뭐 메모리를 할당하고 해당 메모리에 별도의 실행 로직을 만들고 파기했다가 어쩌구 저쩌구 한다. 이런저런 행위가 지나고 나면 프로세스는 0x8048000-0x804a000 범위로 IP를 옮기게 된다.  

위에서 언급한 메모리를 덤프떠서 디스어셈블러 툴에서 열어보면 흐름을 파악할 수가 있다. 

대충 핵심만 얘기해보자면 프로세스는 자식 프로세스를 생성하고 생성된 자식 프로세스에서 Input: 에 입력된 값과 OPCODE 셋을 부모 프로세스에게 전달해준다. 이를 전달받은 부모 프로세스는 OPCODE 셋에 특정 연산을 한 뒤 저장하고 이를 활용하여 자신만의 OPCODE를 실행하게 된다. 

바로 위 두개의 캡쳐가 이번 문제를 풀기 위한 핵심이다. 위 부분을 잘 분석하면 답을 얻을 수 있다. 

짜잔 ~ 

가상머신 난독화 기법에 대한 개념을 잡아보기에 좋은 문제인 것 같다. 좋은 경험이었다 :)

Reference

[1] Reversing Engineering Virtual Machine Protected Binaries, 

    http://resources.infosecinstitute.com/reverse-engineering-virtual-machine-protected-binaries/

이번 문제는 닷넷 리버싱 관련 문제이다. 이전에도 닷넷 문제가 있었으나 블로깅은 하지 않았다. 

보통 닷넷 문제는 디컴파일러를 이용해서 문제를 해결한다. 이번 문제도 물론 디컴파일러(JetBrains dotPeek)를 이용했다. 하지만 이번 문제는 디컴파일러로만 해결할 순 없었다. 이와 더불어 디어셈블러(ILDasm.exe), 헥스에디터(Hxd)도 활용했다. 

CSHARP은 여러가지 방법으로 접근해서 문제를 해결할 수 있었다. 

우선 문제가 어떤식으로 출제됬는지 확인한 뒤 다시 논하도록 하겠다. 

프로그램을 실행시키면 위와 같은 화면이 뜨고 문자열을 입력한 뒤 Check를 입력할 경우 "Correct!!" 또는 "Wrong" 팝업을 띄운다. 그럼 디컴파일러를 이용하여 로직을 살펴보도록 하자.

우선 생성자 부분을 확인해보도록 하겠다. 

생성자 부분에서는 "MetMett" 함수 바디에서 MSIL 바이트를 배열 단위로 가져온 뒤 byte[] 에 삽입한다. 그 뒤에 반복문과 특정 값 대입을 실행한 뒤 InitializeComponent 함수를 호출한다. 해당 함수는 화면 구성과 이벤트 핸들러 등록 등 그닥 살펴볼 부분이 없기 때문에 넘어가도록 하겠다. 

MetMett 함수의 몸체는 아래와 같이 디컴파일에 실패한다. 

그 뒤 "MetMetMet" 함수가 존재하는데 프로그램에서 "Check" 버튼을 눌렀을 때 발생하는 함수다. 여기서 어셈블리가 동적으로 생성된다. 닷넷 프로그램에서 사용되는 어셈블리라는 개념은 흔히 사용하는 어셈블리 언어와 개념은 다르나 여기서는 크게 유념치 않아도 될 것 같다. 여기서는 단순히 하나의 동적 함수를 생성한다 정도로만 받아드리면 될 듯 하다(정확한 의미는 아님).

바로 위의 캡쳐를 잘보면 Form1 클래스의 생성자에서 생성된 Form1.bb 배열을 이용하여 메소드를 생성한다. 여기까지만 보면 대충 느낌이 오지 않는가 ?! 

위에서 문제를 풀 수 있는 방법에 대해 언급하다만 내용을 다시 얘기해보겠다. 

크게 두가지 방법으로 접근해서 해당 문제를 해결할 수 있겠다. 

첫 번째, MetMett 함수의 hex 값을 가져와서 수동으로 변조한 뒤 바이너리 파일의 hex 값을 덮어쓰는 것 

두 번째, 디버거를 이용하여 동적 어셈블리가 생성되어 호출될 곳에 BP를 걸고 분석하는 것 

각 방법에 대한 자세한 방법은 따로 기재하지 않겠다. 

우선 첫 번째 방법을 이용하여 hex 값을 수정한 뒤 디스어셈블러를 이용해 불러보면 아래와 같이 나타난다. 

그리고 두번째 방법을 이용하여 접근했을 경우는 이렇다. 

문자열 비교 로직은 여지껏 진행해 온 문제들과 다르지 않다. 한가지 정도 다른데 다들 눈치챘을거라 생각하고 ~슥 

빠밤~~ 미션 컴플릿 !!

이번 문제는 64비트에서 실행되는 것 외에는 특별한게 없었던 문제였다. 

문제를 풀기 전에 알아야 할 건 64비트에서는 어떻게 함수에 파라미터를 전달하느냐 정도이다. 64비트 프로그램은 기존 방식과 다르게 총 4개의 레지스터를 사용하여 파라미터를 전달하고 그 이상 파라미터가 존재할 경우 스택을 이용한다. 

사용되는 레지스터 (순차적으로)

 - 정수형 : RCX, RDX, R8, R9 

 - 실수형 : XMM0, XMM1, XMM2, XMM3

그럼 문제풀이를 진행해보도록 하겠다. 

문제는 문제 이름을 보면 알수있듯이 랜덤으로 생성되는 6개의 수를 맞추는 것(또는 우회)이다. 

그럼 퀵하게 한번 보도록 하겠다. 

우선 문제를 시작하면 아래와 같이 동작한다. 여기서 숫자는 내가 임의로 입력한 값이다. 

로직을 살펴보도록 하겠다. 아래 보이는 부분은 wscanf_s 함수를 호출하는 부분이다. 

특별한 건 없고 어디에 내가 입력한 값이 저장되는지 정도만 확인하고 넘어가자.

아래 캡쳐는 6개의 수가 어떻게 생성되는지 나타낸다. rand 함수를 호출하고 곱셈, 쉬프트 연산 등등을 이용해서 값을 생성해낸다. 

아래 부분은 단순히 내가 입력한 값과 바로 위에서 생성된 값을 비교한다. 총 6번 비교를 진행한다. 

머 어찌저찌 위 비교 로직을 통과하게 되면 문제에 대한 해답을 나타내주는 부분이 진행된다. 

여기선 따로 분석을 진행하지 않겠다.

위 부분이 쭉쭉 지나고 나면 답을 출력해준다. 

Clear!