1월, 2020의 게시물 표시

[리버싱] 메모장 시간/날짜 표시 순서 변경

이미지
메모장을 유용하게 사용 할 때가 있었다. 윈도우 기본 메모장에는 f5키를 누르면 날짜와 현재 시간을 찍어 출력해주는데, 순서가 불편했다. 오후 4:13 2020-01-24 이런 식으로, 날짜가 뒤에 나오는 것이 불편하여 호기심에 이걸 바꿔보고 싶어 리버싱을 시작했다. x32dbg로 열어, 함수 목록을 찾아보았다. f5를 눌렀을 때 시간 정보를 가져오니까 Get가 써진 함수중에 time이 붙은 함수가 있길래 bp걸고f5를 눌렀더니 멈췄다. 이 곳이 f5를 눌렀을 때의 이벤트 핸들러 함수가 있는 장소라고 생각했다. 함수를 쭉 둘러보고 몇 번 실행해 보며 관찰했다.  함수가 끝나는 부분 전에 핸들러의 edit박스를 수정하는 함수를 호출하고, 마무리짓고 끝낸다. 그리고 그 위를 보면 반복해서 뭘 호출하는데, 저 호출하는 함수가 문자열을 잇는 함수더라. 반복해서 나오는 ebp-338의 공간은 memset함수를 호출하고 난 뒤 빈 공간이 되는 것을 볼 수 있다. 할당된 메모리의 주소임을 알 수 있고, 위에서 반복해서 호출하는 것을 보아 저 주소에 시간 정보들을 복사할 것이다. 함수를 보면 차례로 GetLocalTime함수와, GetDateFormatW, GetTimeFormatW를 호출하는데, 뒤의 두 개는 무시해보고서라도 localtime을 먼저 호출하여 구하는 것 자체가 먼저 시간을 구했다는 것을 유추할 수 있다. 그리고 이 부분을 자세히 보면, ebp-338을 반복적으로 사용하는데 다른 주소의 인자를 같은 순서에 따라 두 번 넣는 것을 볼 수 있다. ebp-a4와, ebp-3d8이다. ebp-a4와 ebp-3d8이 참조하는 주소에는 시간 정보와 날짜 정보가 담긴 구조체나 텍스트 데이터가 저장될 것이다. 저 코드가 담긴 위치의 ebp-a4와 ebp-3d8을 반대로 수정하면 어떻게 될까. 아마도 날짜 텍스트가 먼저 ebp-338의 주소에 적히지 않을까?  바로 수정해 보았다. 명령어의 순서를 단지 바

[리버싱] 과연 이게 될까? Ch.1

이미지
인라인 코드 패치를 실습 후 리버싱 핵심 원리 책을 정독 중, pe header 공부를 하는 챕터에서 Dos Stub를 유심히 살펴 보았다. pe header의 스펙에 따르면, 각 섹션은 characteristics라는 엑세스 권한 비트를 가지고 있다. 그러나 pe header가 메모리에 올라갔을 때의 엑세스 권한은 알려져 있지 않은것 같은데, 디버거로 메모리 맵을 살펴보면 읽기 권한만이 부여되어 있는 것을 볼 수 있다. pe header는 프로그램을 실행할 때 pe 로더가 메모리를 정해주고, 프로그램의 스펙이 어떻게 되어 있는지 나와있는 중요한 곳이기 때문에 보호받아야 한다. 아마도 pe 로더가 pe header가 메모리에 올라갈 때 읽기 엑세스만 주어진 것으로 보인다. Dos Stub는 16비트 이하에서만 실행되는 코드라고 했다. 가변의 길이인 Dos Stub를 무시하고 pe 로더가 스펙으로 보게 되는 PE시그니처의 위치는 e_ifanew에 담겨있다. 만약에, Dos Stub을 쓰기 위한 공간을 코드나 읽기전용 데이터로라도 사용할 수 있을까? 문자열 패치를 할 때, data섹션을 사용하지 않고도, 패치를 시킬 수 있을까? Dos Stub에 실행코드가 담겨있다면, 그것을 읽어 코드 섹션에 다시 쓴 다음 사용할 수 있을까? 한 번 시도해 보기로 했다. 이전의 인라인 코드 패치 실습에서부터 시작한다. https://terria1020.blogspot.com/2020/01/code-cave-patch.html 코드 케이브가 담긴 프로그램으로부터, 실험을 해 본다. 프로그램의 Dos Stub는 이 만큼의 크기를 가지고 있다. 그리고 패치를 위한 문자열의 주소는 data섹션의 끝에 이렇게 담겨있다. 이 문자열을 data섹션에서 사용하지 않고, dos stub에서 사용 할 것이다. 그대로 복사해서, dos stub에 붙여넣어보자. 위에서 dos stub의 메모리, pe header가 담기는 메모리는 읽기

인라인 패치 실습 - Code Cave patch

이미지
인라인 패치 실습으로 Code Cave를 해 보도록 하겠다. abex crackme1의 MessageBoxA 함수에 인자로 들어가는 문자열을 패치시킬 것이다. 참고로 abex crackme1은 ASLR이 적용되지 않은 프로그램이다. 일단 abex crackme1을 x32dbg로 열었다. 틀렸을 때의 분기로 점프해서 넣는 인자(문자열)의 주소는 각각 402035, 402038이다. 이 주소에 각각 새로운 문자열을 써 넣어 볼 것이다. 새 문자열은 Code Cave?!와 Code Cave Patched!!이다. Code Cave를 하기 전에 이 파일의 pe 구조를 보아야 한다. 섹터가 어디부터 이루어져있는지를 봐야 하기 때문이다. Pe Backpack과 HxD로 열어서 구조를 확인 해 보았다. 코드 섹션의 파일 옵셋은 600이다. hxd에서 봤을 때 정확히 600에서 시작한다. PE 구조를 보면 파일에서 데이터 섹션의 크기는 200으로 되어있는데, 실제로 파일에서 사용하는 크기는 70밖에 되지 않는다. VirtualSize는 1000이며, 파일에서의 200의 크기가 다 올라간다고 해도 200 - 70 = 190만큼의 코드 영역이 남는다. 이 영역을 코드를 씌워서 Code Cave의 영역으로 사용 할 것이다. 그리고 문자열의 섹션을 봐 보자. 이 곳도 메모리에 올라가는 크기에 비해 사용하는 크기가 작다. 이 공간에 문자열을 패치시킬 것이다. 우선 문자열을 패치시켜보자. 이렇게 패치시키면 문자열은 메모리에 적재될 것이다. 다음으로, 코드를 패치시켜보자. 문자열을 복사하여 원래 위치의 문자열을 덮어 씌우려고 했지만, 문자열과 문자열 사이의 공간이 빽빽하다. 문자열을 덮어 씌우는 것 대신, 원래의 push 코드를 아예 바꿔 보려고 한다. 디버거로 다시 실행시켜보자. 다시 실행시켰을 때, push의 opcode를 확인하면서 메모리에 문자열이 잘 적재된 것까지 확인을 하였다. 68 0x주소 형