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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

빠밤~~ 미션 컴플릿 !!