일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Blind Sql Injection
- SQL Injection
- 웹 해킹
- 테이블명 수집
- 로그 분석
- 게시판 만들기
- 파일 다운로드 취약점
- 포렌식
- 시스템 해킹
- 해커팩토리
- 해커팩토리 8번
- Burp Suite Intruder
- CTF-d
- 해커 팩토리
- 웹해킹 실습
- 레나 튜토리얼
- ftz
- 해커팩토리 7번
- 리버싱
- Burp Suite
- 디스크 포렌식
- 해커팩토리 10번
- 리버싱 기초
- 보안
- union sql injection
- SANS
- 부트스트랩
- python flask
- 해커 팩토리 6번
- 네트워크 포렌식
- Today
- Total
Cha4SEr Security Study
[레나 튜토리얼] - 3. nag 제거하기 with PE 분석 본문
레나 튜토리얼 실습파일을 3번을 풀어봅시다.
이번시간의 핵심은 PE 구조에 대한 기초적인 이해와 nag 제거 입니다.
우선 PE 구조를 분석할때 기본적으로 많이 쓰이는 것은 PEview 라는 툴 입니다.
PEview는 인터넷 검색을 통해 쉽게 찾을 수 있습니다.
https://www.aldeid.com/wiki/PEView
PEView - aldeid
DRAFT This page is still a draft. Thank you for your understanding. Description INCOMPLETE SECTION OR ARTICLE This section/article is being written and is therefore not complete. Thank you for your comprehension. Installation Download PEView from following
www.aldeid.com
여기서 다운받으시면 되구요 설치까지 해줍시다.
설치하면 이런 돋보기 모양 아이콘의 파일이 나오는데 클릭해서 열어봅시다.
파일을 열면 파일 오픈하는 창이 나오는데 일단 이건 닫아주시고
우리가 실습할 3번 폴더의 파일을 드래그해서 열어봅시다.
오늘 실습할 파일은 3번 폴더에 있는 RegisterMe.exe 입니다.
열어보면 이런식으로 구성되어있습니다.
자세히 살펴보면
RegisterMe.exe 라는 파일이 무엇으로 구성되어있는지 볼 수 있고 (PE 파일의 구조)
파일은 Byte들로 이루어져 있는데, 왼쪽에 있는 디렉토리 별로 바이트를 볼 수 있습니다.
디렉토리들을 보면
보시면 크게 두 가지로 나눌 수 있는데, HEADER 와 SECTION 부분 입니다.
헤더들은 파일의 모양이 어떻게 정의되어있는지, 메타데이터 같은 느낌이구요,
주요 내용들은 SECTION들에 들어있습니다.
간단하게 헤더부터 살펴보고 갑시다.
가장 위에는 IMAGE_DOS_HEADER 입니다.
DOS는 옛날에 콘솔창만 뜨는 윈도우가 있었는데, 도스 환경에서도 쓸 수 있는 exe 파일이 있었습니다.
현재는 잘 쓰지 않는데 그때 사용하던 헤더가 DOS 헤더 입니다.
보시면 시그니처가 5A4D 로 시작하고, 번역하면 MZ라는 단어로 시작한다는 뜻입니다.
실제 바이트를 봐도 MZ로 시작한다는 것을 알 수 있습니다.
+ EXE 파일 앞에는 MZ라는 헤더가 붙습니다.
여기서 보시는 정보들도 시그니처를 제외하고는 옛날 파일들에 대한 정보라서 딱히 볼 건 없습니다.
그렇다면 옛날에 쓰던걸 왜 아직도 쓰냐는 의문이 들 수 있는데,
이 부분은 옛날부터 쭉 쓰던 부분이라 호환성을 위해서 계속 유지를 하다보니 이 부분이 아직 있는것 입니다.
MS-DOS Stub Program 은 DOS 모드에서 사용할 수 있는지를 알려주는 부분입니다.
오른쪽 문자열을 보시면 "This program cannot be run in DOS mode" 라고 적혀있는데,
이 파일은 도스 모드에서는 실행되지 않는다 라는 것을 의미합니다.
다음은 IMAGE_NT_HEADERS 입니다.
이 헤더는 새로 만들어진 헤더이구요, 예전 헤더인 IMAGE_DOS_HEADER의 마지막 오프셋을 보시면
새로운 헤더의 위치를 가르쳐 줍니다. 해당 부분은 0000003C 을 가리키고 있는데
IMAGE_NT_HEADERS의 바이트를 보시면 해당 위치부터 시작하는 것을 알 수 있습니다.
오른쪽에 문자열에 PE라고 적혀있는데, 이곳이 바로 PE 라는 헤더를 가지고 있는 부분입니다.
왼쪽에 보시면 PE 헤더가 세 가지 구조체로 이루어져있다는 것을 볼 수 있습니다.
시그니처는 위에서 보신것 처럼 PE가 박혀있구요,
이 PE가 없으면 EXE 파일이 동작하지 않습니다.
다음 밑에는 IMAGE_FILE_HEADER 부분입니다.
크게 세 부분으로 볼 수 있는데,
Machine -> 32비트에 돌아가는지 or 64비트에 돌아가는지
Time Date Stamp -> 프로그램이 만들어진 날짜
Characteristics -> 프로그램의 특징
등을 알 수 있습니다.
다음은 IMAGE_OPTIONAL_HEADER 입니다.
기본적으로 컴파일 버전 정보, 코드의 사이즈 (올리디버거로 열었을 때 코드 영역의 크기가 얼마냐를 나타냄)
등을 볼 수 있는데,
이번시간에 가장 중요하게 봐야될 부분이 바로 엔트리 포인트와 이미지 베이스 입니다.
엔트리 포인트는 1000 번지, 이미지 베이스는 40만 번지를 가리키는데,
우선 이해를 위해 이 파일을 올리디버거로 열고 메모리 창을 열어봅시다.
메모리 창은 올리디버거에서 청록색으로 표시된 알파벳 버튼 중에 M 버튼을 클릭하시면 볼 수 있습니다.
일단 40만번지를 보시면, 오른쪽에 PE header가 올라와 있는 것을 알 수 있습니다.
여기서 다시 엔트리 포인트를 보시면 1000번지를 가리키는데 이는 실제로
이미지 베이스로부터 1000바이트 다음 주소에 진입 지점이 있다는 뜻입니다.
따라서 프로그램을 실행하면 401000 번지의 주소부터 시작을 하겠다 라는 말이 되는거죠.
실제로 올리디버거에서 보면
401000 번지의 주소에서 시작한다는 것을 볼 수 있습니다.
정리하자면 Address of Entry Point와 Image Base를 더하면 프로그램 시작 지점을 예측할 수 있습니다.
이 외에 알 수 있는 정보들은 이미지 사이즈 (EXE 파일 자체가 이미지 입니다.), 헤더의 사이즈, 체크섬(데이터의 문제가 있는지 확인하는 용도) 등이 있습니다.
다음은 섹션 헤더인데, 섹션 헤더는 밑에 나오는 섹션들에 대한 정보를 가지고 있습니다.
안에 내용으로는 섹션의 이름이 있고, Size of Raw Data와 Virtual Size가 있는데,
PE 파일은 기본적으로 메모리에 적재될 때 사이즈가 늘어나게 됩니다.
여기서 Size of Raw Data는 원래 데이터의 사이즈이고, Virtual Size가 메모리에 적재될 때 늘어난 사이즈 입니다.
밑에 나오는 Characteristcs는 읽기나 쓰기 같은 권한을 가지고 있는 것을 나타냅니다.
일단 PE 구조는 이정도로 알아보고, 이제 문제로 넘어가도록 하겠습니다.
RegisterMe.exe 파일을 실행했을 때 어떻게 되는지부터 살펴봅시다.
클릭하면 레지스터 프로그램에서 nags 를 제거해달라는 메시지가 출력됩니다. OK버튼을 누르면
패치를 해서 nag를 삭제해 달라고 합니다.
여기서 말하는 nag는 쉽게말해서 경고창을 없애달라는 말입니다.
올리디버거로 프로그램을 켜봅시다.
2번째 라인에 보시면 핸들을 가져오는 함수를 실행을 하는데, 하게 되면 결과값으로 400000이 나오게 되고 EAX에 저장하게 됩니다. (40만은 엔트리 포인트가 있는 곳으로, MZ 헤더가 있는 곳입니다.)
근데 밑에 보시면 CMP 명령으로 EAX와 0이 같은지 비교를 하고, 같다면 점프를 하게 되는데, 만약 점프를 하지 않게 되면 nag를 제거하라는 메세지가 출력됩니다.
사실상 점프를 할 수 없는 구간인데, 임의로 점프를 하게 만들어야 하는 구간이죠.
저번시간에 배운 내용으로 직접 JMP 명령어로 수정해서 갈 수도 있겠지만,
이번에는 엔트리 포인트를 변경해서 진행해보도록 하겠습니다.
보시면 우리가 점프해서 도착해야 할 지점은 401024 지점입니다.
따라서 엔트리 포인트를 401024로 바꿔서 프로그램 시작을 401000 부터 시작하지 않고 401024 부터 시작하도록 바꾸는 것 입니다.
우선 그 전에 밑에 또 잔소리를 하는 구간이 있는데, 이 부분은 강제로 JMP 할 수 있는 부분이 없으니 NOP으로 채워줍시다.
이 부분을 드래그 해서 우클릭 후 Binary -> Fill with NOPs 를 클릭해줍시다.
잔소리 부분을 NOP으로 채웠습니다.
이제 다시 엔트리 포인트를 바꿔보도록 합시다.
아까 봤던 'M' 버튼을 클릭 해 메모리 창으로 가봅시다.
원래 엔트리 포인트였던 40만 번지가 있는 곳에 더블 클릭을 해서 들어갑니다.
더블 클릭 후 나오는 창을 확대해 보면
이런 창이 나옵니다.
여기서 쭈우우욱 내려 보면..
4000C0 구간에 PE 시그니처가 있는 것을 볼 수 있습니다. 위에서 PEview에서 보던 것을 올리디버거로 보는 셈이죠.
좀더 내려 보면
4000E8 자리에 엔트리 포인트가 보입니다!
여기서 잠깐 PEview를 보시면
도구 창에서 표시된 부분 (VA) 을 클릭 하고
엔트리 포인트 위치를 보면 가상 메모리에 올라와 있는 곳의 주소를 알 수 있습니다.
여기에 나와있는 엔트리 포인트의 위치 4000E8 을 보니 올리디버거와 매칭이 될 수 있다는 것을 알 수 있습니다.
이제 다시 올리디버거의 덤프 창으로 가서 확인해보도록 하겠습니다. 'C' 버튼을 클릭하시면 됩니다.
덤프창에서 컨트롤 + G 누르고 4000E8번지를 검색합니다.
리틀 엔티안 방식이라 실제는 00 00 10 00 바이트 인데, 젤 마지막 00 바이트 부분을 클릭하고 스페이스를 누른 다음
24로 바꿔주시면 됩니다.
그 이유는 바로
위에서 JE 명령을 통해 원래 점프 후 도착해야하는 구간이 401024 였고,
원래 프로그래 시작점은 401000 이었습니다. (400000 + 1000)
때문에 E8 구간에 저장되어있던 00 10 00 00 (실제 읽을 때는 00 00 10 00) 이 바로 1000 이 들어가 있었고,
24 10 00 00 으로 바꿔줌으로써 00 00 10 24 즉 1024가 들어가서 프로그램 시작 지점이 401024로 바뀌는 것 입니다.
일단 이때까지 수정했던 부분만 해서 저장을 해봅시다.
덤프 창에 마우스 우클릭 -> Copy to executable file -> 새로 뜨는 창에 다시 마우스 우클릭 ->save file -> save
저장하고 실행하면 전에 나왔던 경고 창이 안뜨고 바로 흰색 화면이 나온 것을 볼 수 있습니다.
하지만 X 버튼을 누르니 경고창이 하나 남아있네요.
아마 바뀐 부분 동시에 저장하는 과정에서 문제가 생겼나 봅니다.
crack 파일을 다시 올리디버거로 불러온 다음 경고창을 띄우는 곳을 다시 NOP 로 바꿔준 다음 crack_2로 새로 저장해봅시다.
실행하면 시작했을 때와 X를 눌렀을 때 둘 다 사라졌는 것을 볼 수 있습니다.
RegisterMe.exe 파일은 이것으로 해결이 되었고, 3번 실습파일 보시면 RegisterMe.Oops.exe 파일이 또 있습니다.
이 파일은 어떤 건지 올리로 한번 올려보면
에러 창이 떠버리고
아까와는 전혀 다른 주소 공간이 보입니다.
디버깅을 하기 어려운 곳으로 온 것 같습니다.
이럴때는 두 가지 분석 방법이 있습니다.
첫 번째는 PE 구조를 보고 엔트리 포인트를 직접 보는 것이고,
두 번째는 현재 에러는 PE 구조가 이상해서 에러가 났기 때문에, PE 구조를 수정해서 에러를 잡는 방법이 있습니다.
가장 쉬운 방법은 401000 번지 주소를 찾는 것인데, 우선 컨트롤 + G 로 찾아가봅시다.
일단 프로그램 시작 지점이 401000이 아니기 때문에 저 위치에 브레이크 포인트를 걸어주고 F9를 눌러 401000 까지 오게 만들어 줍시다.
이제 여기까지 왔기 때문에 위에서 했던 분석 과정을 똑같이 해주시면 됩니다.
두 번째는 PE 구조 수정인데,
우선 두 개의 파일을 비교하기 위해 PEview를 두개 열고 RegisterMe와 RegisterMe.Oops를 각각 열어봅시다.
왼쪽이 RegisterMe, 오른쪽이 RegisterMe.Oops 입니다.
한눈에 보기에도 Oops는 없는 부분이 많은 것으로 보이는데, 이 파일은 올바른 PE 구조가 아닙니다.
그렇다고 해서 윈도우에서 PE 파일을 실행할 때 모든 구조를 검사하고 실행하는 것이 아니기 때문에 실제로 파일을 클릭해서 실행해 보면 RegisterMe와 똑같이 실행되게 됩니다.
하지만 올리디버거를 통해 실행해보면 제대로 실행되지 않죠.
한번 수정을 해보도록 합시다.
일단 위에서 엔트리 포인트와 이미지 베이스 등 중요한 정보를 가지고 있는 IMAGE_OPTIONAL_HEADER가 Oops 파일에는 보이지 않습니다. 그래서 이것으로는 PEview를 통해 분석할 수 없습니다.
대신에 HxD 를 사용해서 보도록 하겠습니다.
https://mh-nexus.de/en/downloads.php?product=HxD20
Downloads | mh-nexus
Downloads Note: Starting with HxD 2.3, the portable edition is available as separate setup program, and can be run with minimal privileges (no admin rights required). For the portable edition, the setup program writes only into the selected folder (e.g., U
mh-nexus.de
여기서 다운로드 하시면 되구요 현재 우리가 실습하고 있는 윈도우 XP는 영문판이라서 한국어 버전보다 영문버전을 다운받는 것이 좋을 것 같습니다.
일단 RegisterMe 하나를 열어 보시고 위에 도구 창에
Analysis -> Data comparison -> Compare 를 클릭해봅시다.
밑에 비교 대상 파일을 Oops 파일로 설정한 다음 OK를 누릅니다.
그러면 이런식으로 한 화면에 두 파일이 비교되어 나타나고, 다른 부분을 자동으로 Search 해줍니다.
위에 사진 보시면 이미 다른 부분이 하나 나와있고, 단축키로 F6을 누르시면 다음 다른 부분을 자동으로 찾아줍니다.
우선 처음 다른 곳을 살펴보면
000000DF 의 위치에 있는 데이터가 정상파일에서는 00이지만 Oops 파일에서는 40 입니다.
이 부분에 대해서 좀 더 보기위해 PEview를 살펴보면
Size of Code 의 부분입니다.
정상 파일은 Size of Code가 00 04 00 00 (00 00 04 00) 인데, Oops 파일은 00 04 00 40 (40 00 04 00) 이 되어버린 것이죠.
이제 정상파일 처럼 고쳐 봅시다.
오른쪽 Oops 파일에서 다른 부분에 00을 입력해서 수정해줍니다.
수정한 부분은 붉은색으로 표시가 되었습니다. 위와 같은 방식으로 F6을 눌러 다른 부분을 찾고, 정상 파일과 같은 값으로 모두 바꿔주면 RegisterMe.exe와 똑같은 파일이 되고, PEview나 올리디버거에 올려봐도 정상적으로 나오는 것을 볼 수 있습니다.
3번 문제도 해결!
'Reversing > 레나 튜토리얼' 카테고리의 다른 글
[레나 튜토리얼] - 2. 라이센스 키 알고리즘 분석하기 (0) | 2020.04.22 |
---|---|
[레나 튜토리얼] - 1. 라이센스 루틴 지나가기 (0) | 2020.04.19 |
[레나 튜토리얼] - 0. 실습 준비 (1) | 2020.04.16 |