레나 듀토리얼 - 3

With 보안프로젝트

 

 

내그 제거

 

PE 구조 분석

 

nag를 없애기 실습

 

첫번째 nag를 제거(EP 수정)

두번째 nag를 제거 (nop 패치)

 

 

Oops의 Entry Point 쫓아가서 BP 잡는 방법 설명

 

Oops의 올리에서 제대로 실행되지 않는 이유를 분석

 

 

 

 

 

Pe 구조를 보기위해서는 peview를 많이 사용하게된다.

 

 

그래서 레나듀토리얼 3번 파일을 peview로 켜봅니다.

 

 

 

 

 

주요내용은 section 부터 들어가게됩니다.

 

 

 

 

앞에 헤더들은 어떤모양을하고있고 어떻게 올라가 있고 이정도라고 생각하면됩니다.

이 파일은 어떤거고 라고 설명하는 거라고 생각하면된다.

 

dos 헤더는 옛날에 사용하던 그것이지만

현재는 그냥 호환성을 위해서 냄겨두는 거라고 생각하면됩니다.

 

Offset to EXE Header에서 새로운 헤더에 대한 위치를 알려주고있다.!

 

도스모드에서 사용하지 못하는 것을 알수있습니다.

 

 

 

 

NT HEADERS가

있는데 이거는 새로운 헤더라고 생각하면됩니다.

실제로 c0위치에 새로운 헤더가 위치해 있습니다.

 

 

PE 헤더를가지고있고

 

 

 

 

FILE_HEADER에서는

이게 32비트또는 64비트에서돌아가는지

 

컴파일된 이프로그램이 만들어진시기,

 

어떤 특징을 가지고있는지를 알려줍니다.

 

 

OPTIONAL_HEADER에서는

 

NT_OPTIONAL_HDR 어떤 매직정보를 넣는데 그렇게 중요하지않다

 

그리고 밑에는 버전에대한 내용이 나온다

 

Major Linker Version , Minor Linker Version

어디에서컴파일됬는지 알수있다 EXE파일이 어디에서 컴파일되있는지에 대한정보 

 

 

Size of Code는

코드의 양이얼마냐~ 라는것 

사용하는 커맨드영역이 400 바이트라고 써있다.

 

 

 

Size of Initialized Data

데이터영역은 초기화했을때 A00바이트에대한내용

 

 

Address of Entry Point

1000이 적혀있는데 

 

 

 

 

image Base에서는 

가상메모리 400000번지에 올라간다.

 

 

40만번지에 가면 PE Header가 올라가있고

exe파일이 40만 번지에 올라가있는것!

 

 

 

 

그래서

Address of Entry Point

1000이 적혀있는데 

 

image Base에서는

가상메모리 400000번지에 올라간다.

 

즉 이게 무슨말이냐면

 

 

이미지베이스 (40만번지)에 1000바이트(Entry Point) 쯤에 진입점이있고

 

프로그램을 시작하게되면 401000 부터 시작을 하겠다! 라는 의미라고 볼수있었습니다.

 

 

 

 

Base of Code

 

코드가 올라가는 영역

명령어가 1000바이트 부터 올라왓는데

size of code가 400바이트밖에되지않았는데 401000번지에올라온다 라는 것입니다.

 

 

여기서 알수있는 사실은

 

40만 1000번지이면은 

 

 

Section Alignment 

 

1000바이트씩 짤라서 배치하겠다 라고 써있습니다.

파일 크기보다 조금더 커지면서 1000바이트 맞춰지면서 올라간다.

 

 

 

File Alignment는

 

200고

Section Alignment는 1000 이지만 1000바이트씩 짤라서 올라가는거고

 실제 파일자체로 존재할때는 200바이트씩 짤려서 존재합니다.

 

 

Size of Image

 

이미지의 사이즈는 얼마인지

 

exe파일 자체가 이미지인데

exe파일의 이미지 사이즈가 얼만지 헤더의 사이즈가 얼마인지 라는것을 이야기하는것

 

 

 

 

 

Checksum은

 

전체파일 데이터에 문제가있는지 확인하는 것

 

 

 

Subsystem

 

윈도우에 여러가지 서브시스템이있는데 

 

 

 

 

Number of Data Directories 뒤부터는 이제

 

데이터가 어떻게 헤더데이터들이 배치되있는지 

 

가 장중요하게 보는 것은 EXPORT Table 과 IMPORT Table 정도라고 생각합니다.

 

 

 

 

section header 쪽은 이 섹션들이 어떤 특징들을 가지고있는지 설명해줍니다

 

 

Name

 

이름

 

 

Virtual Size

 

가상메모리는 400인데 올라갈때는 21A로 올리겠다

라는 의미가 담겨있고

 

 

Characteristics는

권한에 대한 내용을 이야기하고있다.

실행가능한권한을가지고있다 읽기 가능한 권한을 가지고 있다

EXECUTE,   READ

 

 

 

 

이제 파일을 켜보게되면 

이 레지스터라는 프로그램에서 nag를 제거해달라 라는 의미입니다.

 

 

nag를 패치해서 삭제를 해라 라는 의미의 메세지박스가 나옵니다.

 

nag모냐면 그냥 경고창을 없애라!!!

 

 

 

 

 

이것을 올리디버거에 열어봅시다 이제

 

 

 

 

 

 

 

GetModuleHandle

 

을 사용하고있는데

현재의 모듈이 핸들을 얻는 방법인데 그다지 쓰이는 방법이아닌거같다

 

 

 

 

 

CALL을 하고 eax에서 나온값을 살펴보면

 

EAX 에 40만이 있다

모듈에대한 핸들 값을 얻으면 40만번지가 나오는 것이다

올라와있는 구조 

 

 

 

Hex에서 40만번지로 가게되면

MZ 헤더가 있고 PE헤더가 잘위치하게되는 것입니다.

 

 

 

 

그다음 CMP EAX,0 에서 절대로 0이 될수 없다는 것을 알수있으니까

 

점프 할일이 절대로 존재하지않는다.

 

그이유는 아까 EAX에 40만이나왔는데 0이랑 비교해서 비교한 값이 같아서

제로플레그가 1으로 올라갈 확률이 없기 때문이다

 

 

JE 

값이 전보다 작으면 점프해란 의미로 점프를 하게되는데

 

그래서 점프를 할수가없다.

 

하지만 점프를 해줘야하는데 점프를 하는게 불가능합니다.

 

점프를 바꿔주거나 그래야하는데

 

 

우리는 Entry point를 수정해서 풀어봅니다.

 

 

 

401000번지로 되어있는 entry point를 (진입점) 401024에서 시작을 하게 만들면

 

점프를 수정하지않아도가능하다

 

하지만 밑에부분에

 

 

 

 

 

 

뒤쪽에는 이런내용이나오는데 점프를 할수있는 방법이 없으니까

 

NOP으로 실행하지 않게 바꿔줍니다.

 

 

 

즉이렇게 바꿨고

 

Binary -> Fill with NOPS

 

 

이제 JE는 직접들어가서 수정을 해봅시다.

 

 

 

JE를 들어가면

 

위창에 M을 누른다.

 

메모리에 직접들어가는거.

 

 

 

 

이부분을 더블클릭을들어가면

 

 

peview에서 봤던것을 올리디버거에서 보는 느낌이라 생각하면된다.

 

 

 

 

이렇게 볼수가 있고

 

 

여기에 entry point에 대한 내용을 볼수있다

 

 

즉 entrypoint가 4000e8번에 존재를 한다.

 

 

 

 

그래서 peview로 가서 확인을 해봅니다.

 

 

VA 즉 가상 어드레스에 대한내용

 

 

 

 

여기서도 Entry point가 4000E8번에 있다는 것을 알 수 있습니다.

 

 

 

다시 올리디버거로 가서 덤프창에서 따라가봅시다.

 

 

C버튼을 누르게되면 다시돌아오게되고

 

 

 

돌아올수있고

 

 

 

 

 

 

4000E8번의 주소를 검색하니 리틀인디안 방식으로

 

1000 이였던게 00 10 으로 들어가 있게됬습니다.

 

 

00앞에있는부분을 

ctrl+ e를 진행해서

 

24로 바꾸게되면

 

entrypoint 가 1024 니까

 

 

우리가원했던 entry point 를 00401024 번지로 바꿀수있다

 

 

우리가 바꾼

 

NOP 에대한 내용과 우리가 원했던 00401024 번지로 Entry point를 저장을 합니다.

 

 

 

파일을 저장을 하기위해 누릅니다.

 

 

 

 

파일을 저장합니다!

이름을 crack 으로 바꿧습니다.

 

 

 

우리가 변경한 크랙파일을 키게되면

첫메세지박스가 이걸로 바뀌게 되었습니다.

 

 

 

 

그전에봤던  이 내용이  우리가 크랙을 만들게 되서

 

 

사라지게 됬습니다.

 

하지만

 

 

 

이 잔소기는 사라지지가 않았으니까

 

 

NOP을 저장을 안하게된 것입니다.

 

 

Copy to executable -> All modifications

 

 

copy all을 누르고

 

 

저장하기

 

 

 

저장을 마지막으로 합니다

 

 

그럼이제 이거 하나만 뜨게됩니다!

 

 

 

 

 

 

==============================================

 

 

 

 

 

 

Oops의 Entry Point 쫓아가서 BP 잡는 방법

 

1. Entry Point 직접 가서 잡는다.

 

2. Pe 구조가 이상해서 에러 ~ PE 구조 수정

 

 

 

 

 

 

 

 

 

 

Peview를 두개열어줍니다.

 

 

두개의 파일을 비교하기위해서

 

 

이미지 헤더를

잘보니까 Oops 파일은 어느순간부터 짤렸습니다. 

 

애는 올바른 pe구조가아닙니다

 

윈도우가 실행할때 모든것을 가지고 해석해서 실행하는게 아니라 실행해도 똑같이 나옵니다.

 

올리디버거를 통해서 실행하는 경우에는 제대로 실행되지않습니다.

 

올바른 pe구조가 아니기때문입니다

 

 

 

 

 

 

PE 도 잘잡는 것을 알 수 있습니다.

 

 

File Header에서도 동일하게 유지가 되고있습니다.

 

 

하지만 optional header 부터는 아예 읽지도 못하고 있습니다.

 

여기서는 동일한 분석을 할수없습니다.

 

pe구조가 온전히 있을때만 확인할 수있는데

 

불가능 하니까 

 

 

 

 

 

HXD 프로그램을 사용합니다.

 

 

 

 

HXD에 원본파일인 RegisterMe.exe를 엽니다.

 

 

덤프창에 있는것처럼 보여준다 올리디버거에서 본것처럼

 

 

 

 

analysis -> compare가 존재하는데

 

데이터비교 -> 비교를 누릅니다.

(한국어는)

 

 

 

이렇게 원본파일과 Oops 파일을 비교합니다.

 

 

 

이렇게 f6을 계속눌러주면 다른적을 계속 찾아줍니다.

 

 

 

 

 

잘보면 entry 가 40만번지에 올라가야 하지만 정상파일은 그렇지가 않습니다.

 

 

 

여기서는 

 

 

그리고 sizeofcode 가 임의로 변경이됬습니다 (Oops)에서는

 

 

 

원래는 

 

00000400을 리틀 인디언 방식으로

 

00 04 00 00 으로 되야하지만

00 04 00 40 으로 변경되있다는 뜻입니다.(Oops파일)

이렇게 변경이된거는 엄청나게 커진 것입니다.

왜냐 리틀인디언 방식으로하면

 

00000400

-> 변형되서

40000400 이기때문입니다.

 

 

 

이부분을 수정을 해줍니다.

 

00 04 00 40->

 

00 04 00 00으로

 

바꿔줌

 

 

 

 

 

 

 

 

 

 

 

 

 

이부분을 보니까

 

00 0A 00 00 

->

00 0A 00 40 으로 변경이 됬습니다

(Oops파일)

 

 

peview에서 찾아보니까 Size of Initialized Data였고

 

 

00000A00

->

40000A00 이렇게 변경됬으니까

 

다시바꿔줍니다.

 

 

00 0A 00 40

->

00 0A 00 00 으로

 

 

 

 

 

 

 

 

 

 

 

 

 

그리고 또 000000EF 부분이 또 바뀌게됬습니다.

 

그래서보니까

Base of Code 부분을 또 수정한 것입니다.

 

코드의 베이스가 어디냐 라는 의미인데

 

즉

 

코드가 어디에 올라가냐 라는 의미입니다.

 

 

 

 

이부분이 바뀌게 된것이고

 

00 10 00 00 

->

00 10 00 40 으로 변형

 

 

즉

 

00001000 

->

40001000

으로 엄청나게 변형이됬습니다.

 

그래서 이부분을 또 수정

 

 

 

 

 

 

 

 

 

 

다음을 가도 또 바뀌어있어서 수정을 합니다

 

수정완료

 

 

 

 

 

 

 

 

 

 

 

 

또 비교하니까 이친구는 오히려 사이즈가 줄었습니다.

 

즉 10에서 -> 4로 줄었다.

 

 

그래서 뭔지 궁금해서 peview로 찾아보니까

 

 

오히려 크기를 줄여서 뒤에따라오는 데이터 디렉토리들을 없애 버린 것입니다.

 

 

 

총 10개인데 4개만 있게되는것입니다. 디렉토리 10개에서 4개로 줄였기 때문에 

10개로 똑같이 만듭니다.

 

 

 

그래서 10 으로 수정 완료

 

 

 

 

00000010

이 

40000010

으로 바뀌어있습니다.

 

 

10 00 00 00 

->

10 00 00 40

으로 바뀐것

 

 

여기까지 number of directories의 것이기때문에

 

10 00 00 40을

 

10 00 00 00으로 바꿔준다

 

 

 

 

 

 

 

여기서는 00 00 00 00

->

00 00 50 00 으로 바뀌었습니다.

 

00000138 부터 시작이므로

 

 

 

EXPORT Table이 또 변경됬었고

 

 

이제 전부 다 f6으로 비교하면서 바꿔줍니다.

 

 

 

 

 

 

그다음꺼로 가서

 

이거를

00으로 수정하니

 

이제 비교할 것이 없어졌기 때문에 원본을 다 살린것 같은 느낌이다.

 

 

 

 

 

 

이렇게 peview로 수정한 파일을 열어보니까

 

이제 이 파일의 헤더가 잘나오게되고 잇습니다.

PE 구조를 복구했습니다.

 

그 전에는 다 짤려서 나왔기 때문입니다.

 

 

 

 

 

이제 올리디버거에서 이제 열수가 있게됬다 PE구조가 복구됬기 때문이다.

 

 

 

 

내그를 제거하고 

PE 구조를 분석했고 (거기서 Entry point의 위치를 알수 있었고)

메모리에 데이터가 올라간다라는거 약속된 것들이있고

 

이런게 잘못되면 올리디버거에 인식하지못하고 peview도 인식이 불가능하고

 

마지막으로 pe 구조를 복구까지 진행 해봤습니다.