티스토리 뷰

반응형

요약

1. IDA Pro, Hex Rays
2. CFF Explorer
3. API Monitor
4. WinHex
5. Hiew
6. Fiddler
7. Scylla
8. Relocation Section Editor

9. PEiD

10. BinNavi


1. IDA Pro, Hex Rays

IDA Pro 는 가장 널리 사용되는 리버스 엔지니어링 소프트웨어 도구 중 하나입니다. 명령 언어( IDC )가 내장되어 있고 다양한 프로세서 및 운영 체제에 대해 여러 실행 가능한 형식을 지원하는 대화형 디스어셈블러입니다. IDA Pro에는 또한 디스어셈블러의 기능을 더욱 확장할 수 있는 수많은 플러그인이 있습니다.

IDA Pro의 주요 장점은 표시된 데이터의 모든 요소를 ​​대화식으로 변경할 수 있다는 것입니다.

  • 함수, 변수, 데이터 구조 등에 이름을 지정합니다.
  • 데이터 표현 변경(숫자, 다양한 인코딩의 문자열, 데이터 구조)
  • 디스어셈블된 코드의 이해를 단순화하기 위해 다이어그램 및 코드 흐름 그래프 작성
  • 인수와 변수의 이름이 자동으로 지정되도록 C++의 함수 인수 및 구조 정의에 대한 유형 정보 사용
  • 어셈블러 코드에서 표준 라이브러리 함수를 자동으로 인식하고 이름 지정
  • 그리고 훨씬 더
스크린샷 1. IDA Pro 인터페이스

디스어셈블러 자체 외에도 일부 IDA 플러그인을 자세히 살펴보겠습니다.

Hex-Rays 디컴파일러

이 플러그인은 네이티브 프로세서 코드를 더 읽기 쉽고 C와 유사한 버전으로 바꿀 수 있습니다. Hex-Rays Decompiler는 인간 리버스 엔지니어가 생성한 것과 비교할 수 있는 다소 정확한 C 코드를 생성합니다. 아키텍처에 관계없이 다양한 C++ 컴파일러에서 생성된 코드를 올바르게 디컴파일합니다. 그러나 Hex-Rays Decompiler는 인라인 어셈블러를 추가하여 원본 코드를 특별히 수정하거나 일부 수동 최적화를 수행한 복잡한 어셈블러 코드를 처리하는 데 문제가 있을 수 있습니다. 

등대

이 플러그인을 사용하면 디스어셈블러 내에서 실행 경로를 표시할 수 있습니다. 결과적으로 어떤 코드 조각이 실행에 참여하고 있는지, 어떤 알고리즘이나 기능에 관련되어 있는지 이해할 수 있습니다.

기본적으로 이 플러그인은 코드 커버리지 도구에 대한 보고서를 IDA 데이터베이스에 로드하고 실행 횟수에 따라 코드 조각을 표시합니다. 이렇게 하면 디스어셈블리를 탐색하는 동안 코드의 어느 부분이 주의할 가치가 있는지 명확해집니다.

ClassInformer

이 플러그인은 Visual Studio에서 빌드한 바이너리에서 사용하기 위한 것으로 실행 파일의 데이터 섹션에 저장된 RTTI 정보를 검색합니다. RTTI 정보를 통해 플러그인은 C++ 클래스의 클래스 이름과 가상 메서드를 찾고 사용자를 위해 이름을 지정할 수 있습니다. 또한 ClassInformer는 발견된 클래스 목록을 제공할 수 있습니다.

zynamix의 BinDiff

이 도구는 IDA 엔진을 사용하여 바이너리를 바이트 스트림 대신 어셈블러 코드로 비교합니다. BinDiff는 추가, 제거 또는 대체된 명령어 목록으로 동일한 프로그램의 두 버전 코드(특정 기능의 변경 사항까지)의 차이점을 정확히 찾아낼 수 있습니다. 변경 사항은 코드 흐름 그래프로 나타낼 수도 있습니다.

IDA-Function-Tagger

이 플러그인은 가져온 함수와 이를 호출하는 함수를 분석한 다음 암호화 관련, 레지스트리 관련, 네트워크 관련 등의 태그별로 그룹화합니다. 이러한 그룹화를 통해 특정 작업을 담당하는 코드 부분을 더 쉽게 찾을 수 있습니다.

ida-x86emu

이 플러그인은 디버거에서 분석 중인 애플리케이션을 실행할 필요 없이 디스어셈블된 코드의 실행을 에뮬레이트합니다. 이 플러그인을 사용하면 시스템에서 무언가를 수정할 위험 없이 코드의 일부를 실행한 결과를 에뮬레이트할 수 있습니다. CPU 레지스터의 시작 값을 지정하기만 하면 됩니다. 그런 다음 단계별 실행을 수행할 수 있습니다.

 

2. CFF Explorer

CFF Explorer 는 다음을 포함하는 PE(이식 가능한 실행 파일) 편집을 위한 도구 모음입니다.

  • PE 및 HEX 편집기
  • 리소스 편집기
  • 편집기 가져오기
  • 서명 스캐너
  • 주소 변환기
  • 분해기
  • 종속성 분석기
  • 그리고 더
스크린샷 2. CFF 탐색기 인터페이스

 

3. API Monitor

API Monitor 는 앱 및 서비스에서 수행되는 API 함수 호출을 가로채기 위한 응용 프로그램입니다. 이 도구는 입력 및 출력 데이터도 표시할 수 있습니다. 

기본적으로 API 모니터에는 13,000개 이상의 API 함수와 1,300개 이상의 COM 인터페이스 메서드에 대한 정의가 포함되어 있습니다.

스크린샷 3. API 모니터의 API 캡처 필터 인터페이스

 

4. WinHex

WinHex 는 Windows용 다양한 기능과 개발 도구를 제공하는 16진수 편집기입니다. 

WinHex는 일반 텍스트 편집기가 할 수 없는 체크섬 또는 소프트웨어 파일 코드를 표시할 수 있습니다.

스크린샷 4. WinHex 인터페이스

 

5. Hiew 

Hiew 는 코드 작업에 중점을 둔 바이너리 파일 편집기입니다. x86, x86-64, ARM용 디스어셈블러와 x86 및 x86-64용 어셈블러가 내장되어 있습니다.

Hiew의 주요 기능은 다음과 같습니다.

  • 논리 및 물리 드라이브 보기 및 편집
  • 템플릿으로 어셈블러 명령 검색
  • 키보드 매크로
  • 내장 64비트 계산기
  • 사용자 정의 플러그인을 만드는 도구
스크린샷 5. Hiew 인터페이스

 

6. Fiddler

Fiddler는 애플리케이션과 서버 사이를 이동하는 HTTP/HTTPS 트래픽을 가로채서 모니터링하고 분석하는 데 사용할 수 있는 프록시입니다. Fiddler는 시스템 전체에서 HTTP/HTTPS 트래픽을 가로챌 수 있습니다. 또한 플러그인(예: wbxml을 디코딩할 수 있는 wbxml 보기)을 추가하고 다른 보기에서 요청/응답을 표시할 수 있습니다.

스크린샷 6. Fiddler 인터페이스

Fiddler에는 16진수 편집기가 내장되어 있으며 선택한 요청을 기반으로 요청을 생성하거나 사용자 지정 요청을 생성할 수 있습니다. 또한 Request to Code 플러그인 을 사용하면 C#, Visual Basic 또는 Python에서 요청을 실행하는 코드를 준비할 수 있습니다.

 

7. Scylla

Scylla 는 실행 중인 응용 프로그램 프로세스를 덤프하고 PE 가져오기 테이블을 복원하는 응용 프로그램입니다. 그것의 도움으로 운영 체제에서 실행할 수 있는 완전히 복원된 PE 파일을 얻을 수 있습니다.

스크린샷 7. Scylla 인터페이스.   이미지 크레디트:   스택 익스체인지

 

8. Relocation Section Editor 

Relocation Section Editor  는 PE 파일의 재배치 테이블을 편집하는 데 사용되는 응용 프로그램입니다. 이 도구의 주요 목적은 재배치 가능한 코드 조각을 패치하는 경우 재배치 테이블을 수정하는 것입니다. 그러나 보호된 파일을 복원할 때 재배치 테이블을 완전히 제거하는 데 자주 사용됩니다.

보호된 파일에는 실제로 unpacker 코드에 대한 재배치 테이블만 포함됩니다. 실제 코드에 대한 재배치 테이블은 일반적으로 언패커 데이터 내에 숨겨져 있습니다. 따라서 덤프가 복구되는 경우 실제 코드에 대해 누락된 재배치 테이블을 복원하는 두 가지 방법이 있습니다. 

  1. 애플리케이션이 두 개의 서로 다른 기본 주소에 로드되도록 한 다음 덤프를 비교하여 코드의 어느 부분이 패치되고 있는지 확인하고 새 재배치 테이블을 만드십시오.
  2. 재배치 테이블을 완전히 제거하고 PE 파일 헤더에 파일을 재배치할 수 없음을 지정합니다.
스크린샷 8. 재배치 섹션 편집기 인터페이스

 

9. PEID

PEiD는 패커를 감지하는 최고의 리버스 엔지니어링 도구 중 하나입니다. 엔트로피를 분석하여 PEiD는 애플리케이션이 패킹되었는지 여부를 감지할 수 있습니다.

PE 파일을 분석하는 데 도움이 되는 다양한 유용한 플러그인도 있습니다. 예를 들어 KANAL(PEiD용 크립토 분석기) 플러그인 은 알려진 암호화 알고리즘이 있는지 PE 파일을 분석합니다.

스크린샷 9. PEiD 인터페이스

이것은 Apriorit의 리버스 엔지니어가 Windows 리버싱 프로젝트에서 작업할 때 자주 사용하는 9가지 도구입니다. 보시다시피 리버스 엔지니어링을 위한 이러한 각 소프트웨어는 매우 독특하고 특정한 작업 세트를 해결합니다. 다음 섹션에서는 Windows 반전에서 이러한 각 도구의 역할과 중요성을 보여주는 실용적인 예를 제공합니다.

 

10. BinNavi

BinNavi는 디스어셈블된 코드에서 취약점을 찾는 취약점 연구원을 지원하기 위해 구축된 바이너리 코드 리버스 엔지니어링 도구입니다.
BinNavi는  내장 정적 코드 분석 기술을 사용하여 디스어셈블된 x86, ARM, PowerPC 및 MIPS 코드를 분석할 수 있습니다. 정적 코드 분석이 충분하지 않은 경우 내장 디버거를 사용하여 분석 중인 프로그램에 대한 실시간 보기를 얻을 수 있습니다.
개발사인 zynamics는 2011년 구글에게 인수되었습니다. 유료화 되었지만, 5.x 버전의 소스를 공개되어 있습니다. 
Github : https://github.com/google/binnavi
<주요 피처>

  • 디스 어셈블된 x86, ARM, MIPS 및 PowerPC 코드의 제어 흐름 기반 코드 분석 수행
  • 함수에서 중요하지 않은 코드를 제거 하여 복잡성을 줄입니다.
  • 강력한 원격 디버거 를 사용 하여 다양한 운영 체제에서 프로그램 디버그
  • 차등 디버깅을 사용 하여 관련 코드를 빠르게 찾습니다 .
  • 중요한 기능과 기본 블록 을 표시하기 위한 사용자 정의 태그 생성 및 할당
  • 고급 코드 분석 알고리즘 을 사용 하여 데이터 및 코드 추적
  • 하나의 중앙 데이터베이스 에서 모든 리버스 엔지니어링 프로젝트 관리
  • 특정 목표를 달성하기 위해 BinNavi를 확장하는 스크립트 및 플러그인 작성
  • 변수와 함수 의 이름을 바꾸고 주석을 달아 이해하기 쉽게 만듭니다.
  • REIL 메타 언어를 사용하여 플랫폼 독립적인 프로그램 분석 코드 작성
BinNavi 3.0 기본 창
BinNavi 그래프 창
디스어셈블된 코드에서 호출 지침 강조 표시
레지스터 및 메모리 값을 기록하는 디버그 추적

 

Cisco 2600 라우터 디버깅(GDB 에이전트 사용, 아래 참조)
스크립트를 사용하여 디스어셈블리 데이터 액세스
플랫폼 독립적인 중간 언어 REIL 사용

 


리버스 도구 작업의 실제 예

이러한 각 도구를 사용하여 Windows 응용 프로그램을 조사하는 방법을 살펴보겠습니다. 예를 들어 직접 다운로드하여 분석할 수 있는 테스트 응용 프로그램 을 사용할 것입니다.

1. 조사한 실행 파일을 IDA Pro로 열기

테스트 애플리케이션을 IDA Pro에 로드해 보겠습니다. 다음 메시지가 수신됩니다.

스크린샷 10. IDA Pro에서 표시되는 오류 메시지

 

이것은 응용 프로그램에 문제가 있음을 의미합니다. 가져오기 테이블을 찾을 수 없습니다. 이 시점에서 OK 버튼만 누르면 됩니다. 그렇게 하면 IDA Pro는 다음과 같은 애플리케이션 분석 결과를 제공합니다.

스크린샷 11. IDA Pro의 애플리케이션 분석 결과

 

스크린샷 12. 애플리케이션의 가져오기 테이블 테스트

 

보시다시피 가져오기 테이블은 거의 비어 있습니다. 상단 부분은 작은 코드 조각(파란색 부분)을 감지할 수 있음을 보여주고 왼쪽 부분은 어떤 기능이 감지되었는지 보여줍니다(우리의 경우 매우 적음). 

시작 기능 위에도 감지되지 않은 바이트 세트가 있습니다. 애플리케이션이 일부 패커를 통해 패킹되었다고 가정합니다. PEiD는 사용된 패커를 결정하는 데 도움이 됩니다.

 

2. PEiD로 패커에 대한 정보 얻기

이제 PEiD에 애플리케이션을 로드해야 합니다.

스크린샷 13. PEiD에 표시된 애플리케이션 정보

 

위의 스크린샷 13에서 진입점이 UPX1 섹션에 있는 것을 볼 수 있습니다. 그러나 이 사실만으로는 많은 것을 알 수 없으므로 스캔을 실행해야 합니다. 

스캔 프로세스를 시작하려면 옵션 으로 이동하여 하드코어 스캔 을 선택 하고 저장 을 클릭 합니다 .

스크린샷 14. PEiD에서 스캔 프로세스 구성

 

그런 다음 응용 프로그램이 있는 폴더를 선택합니다. 스캔이 완료되면 다음과 같은 결과가 나타납니다.

스크린샷 15. PEiD로 애플리케이션 스캔 결과

스크린샷 15에서 볼 수 있듯이 응용 프로그램은 UPX 도구를 사용하여 압축됩니다. 압축을 풀기 위해 CFF Explorer를 사용할 것입니다.

 

3. CFF Explorer로 애플리케이션 압축 풀기

CFF Explorer로 샘플 애플리케이션의 압축을 풀려면 CFF Explorer의 주 메뉴에 있는 UPX 유틸리티 페이지로 이동하여 압축 풀기 버튼을 눌러야 합니다.

스크린샷 16. CFF 탐색기에서 애플리케이션 압축 풀기

 

그런 다음 이미 압축을 푼 애플리케이션을 IDA Pro에 업로드하고 어셈블러 코드를 복원할 수 있습니다.

우리는 우리의 응용 프로그램을 IDA Pro에 다시 한 번 업로드하고 시스템이 서버에서 기호를 업로드할지 여부를 묻는 메시지에 동의합니다. IDA Pro의 애플리케이션 분석 결과는 다음과 같습니다.

스크린샷 17. 압축을 푼 애플리케이션에 대한 IDA Pro 분석 결과

 

스크린샷 18. 압축을 푼 애플리케이션의 가져오기 테이블

 

스크린샷 17에서 읽을 수 있는 코드, 감지된 기능 및 가져오기 테이블이 있음을 알 수 있습니다(스크린샷 18). 이 시점에서 애플리케이션을 실행하고 IDA Pro에서 디버그할 수 있습니다. 디스어셈블러에서 디버거 > 디버거 선택 > 로컬 Win32 디버거 를 선택한 다음 F9 키를 누릅니다 . 그 후 다음과 같은 경고 메시지가 나타납니다.

스크린샷 19. 디버거 감지 메시지

 

테스트한 애플리케이션에서 디버깅된 것으로 감지되었습니다. 분석을 계속하려면 먼저 디버거 감지를 비활성화해야 합니다.

가져오기 표를 참조하세요.

스크린샷 20.   NtQueryInformationProcess   함수

 

한 번에 NtQueryInformationProcess 함수를 확인할 수 있습니다. 그것을 클릭하면 다음과 같은 외부 참조 기능 목록이 표시됩니다.

스크린샷 21.   NtQueryInformationProcess   함수의 외부 참조 함수

 

함수를 클릭하면 호출된 위치를 볼 수 있습니다. 세 번째 매개변수는 출력 매개변수입니다. 1이면 디버거가 애플리케이션에 연결된 것입니다. 0이면 앱에 연결된 디버거가 없습니다.

이 함수의 결과가 어디에 기록되는지 봅시다:

스크린샷 22. NtQueryInformationProcess 함수 분석

 

스크린샷 22에서 볼 수 있듯이 세 번째 매개변수에는 로컬 변수(var_8)의 주소가 포함됩니다. 함수 호출 후 함수의 결과를 확인합니다(test eax, eax). 그런 다음 var_8의 값을 확인하고 0이 아니면 byte_131443C 변수에 값을 씁니다.

byte_131443C 변수가 이 함수의 다른 곳에서 사용되는지 확인합시다:

스크린샷 23. byte_131443C 변수가 어디에 사용되는지 확인

 

우리는 끝에서 시작할 것입니다. 이 값은 al (하위 바이트)의 결과를 포함합니다. 그 전에 esi 결과는 eax 에 기록되고 1 은 esi 에 기록됩니다 . 위에서 ecx + 2가 0과 같지 않은 경우 1을 esi 에 쓰는 조건을 볼 수 있습니다 . ecx 의 값 은 fs:30h(그리고 +2)가 큽니다. 디버거의 존재가 IsDebuggerPresent 함수(문서화되지 않은 PEB 구조의 필드)를 우회했는지 확인합니다. 

이 변수의 이름을 바꾸겠습니다. 이렇게 하려면 N 을 누르 거나 함수를 마우스 오른쪽 버튼으로 클릭하고 이름 바꾸기 를 선택 합니다. 

이제 g_isDebbugerPresent 변수가 다른 곳에서 사용 되는지 확인해야 합니다 .

스크린샷 24.   g_isDebbugerPresent   변수 세부정보

 

끝에 "..."가 있으므로 이 변수는 여러 곳에서 사용됩니다. 커서를 그 위에 놓고 X 를 클릭하거나 마우스 오른쪽 버튼을 클릭하고 피연산자에 대한 외부 참조로 점프를 선택합니다 .

스크린샷 25.   g_isDebbugerPresent   변수가 사용되는  위치

 

우리는 이미 이 변수가 사용되는 처음 네 곳을 알고 있지만 마지막 곳은 모릅니다. 그것을 찾자:

스크린샷 26.  IsDebuggerPresent  함수 사용 에 대한 세부 정보

 

스크린샷 26에서 변수가 esi 가 0인지 확인하고 그렇지 않으면 디버거가 있다는 메시지를 받습니다.

다행스럽게도 이 확인을 제거할 수 있습니다. 나중에 Hiew 도구 로 작업할 때 이를 수행하는 한 가지 방법을 고려할 것 입니다.

IDA Pro가 메모리와 코드 패치도 허용한다는 점은 주목할 만합니다. 필요한 코드를 빠르게 찾기 위해 Hiew에서와 동일한 오프셋을 얻기 위해 IDA Pro에서 Rebase 프로그램을 실행합니다. IDA Pro에서 편집 > 세그먼트 > Rebase 프로그램 을 선택 하고 열린 창에 값 0x400000을 입력합니다.

스크린샷 27. IDA Pro의 Rebase 프로그램

비교를 수행하는 코드의 주소를 알아봅시다. 아래 스크린샷 28에서 볼 수 있듯이 주소는 0х401329입니다.

스크린샷 28. g_isDebbugerPresent   변수 값   을 비교하는 코드

나중에 Hiew에서 사용할 것이기 때문에 이 주소를 기록해 두어야 합니다.

 

4. Hiew에서 실행된 문장 수정하기

이제 Hiew에서 애플리케이션을 로드해야 합니다. 먼저 다음과 같이 보입니다.

스크린샷 29. Hiew에서 테스트 애플리케이션 보기

 

F4 > Decode 를 눌러 디코딩 모드로 전환할 수 있습니다 . 이제 IDA Pro에서 받은 주소인 0х401329를 찾아야 합니다. F5 키 를 누르고 주소를 다음과 같이 설정합니다.

스크린샷 30. Hiew에서 코드 주소 설정

 

이 시점에서 우리는 g_isDebbugerPresent 변수의 값을 비교하는 코드를 얻습니다.

스크린샷 31. g_isDebbugerPresen   t 변수   를 비교하는 코드

 

이제 이 코드를 특정 주소에 대한 jmp 로 대체 하여 이 조건이 절대 충족되지 않도록 할 수 있습니다(실제 응용 프로그램에서는 응용 프로그램을 즉시 닫는 것은 예외일 수 있음).

F3 키 를 누른 다음 F2  를 눌러 편집 모드로 전환합니다. if 다음에 다음 명령의 주소를 입력하십시오. 추가하다 "." 주소의 시작 부분에 있으므로 상대적입니다.

스크린샷 32. g_isDebbugerPresent   변수    에 대한 코드 변경

 

편집 후 수정된 명령은 노란색으로 강조 표시됩니다. F9 키 를 눌러 응용 프로그램을 업데이트하고 저장합니다.

지금 테스트 애플리케이션을 실행하려고 하면 충돌합니다.

어셈블러 코드를 볼 때 새 jmp 는 코드 아래에서 esi 를 호출 하고 esi 는 MessageBox 함수 주소 대신 가비지를 포함한다는 것을 알 수 있습니다. 주소 401330을 건너뛰고 있으므로 mov esi, ds: MessageBox를 건너뜁니다. 따라서 esi 는 초기화되지 않으며 응용 프로그램은 401366에서 충돌합니다.

스크린샷 33. 애플리케이션이 충돌하는 코드 부분

 

따라서 jmp 와 MessageBox 주소를 esi 에 두는 mov 명령어를 바꿔봅시다 . 이제 jmp 의 상대 주소 를 14로 설정해야 하지만 명령이 우리가 하려는 명령에 더 가까워졌기 때문에 더 이상 1E로 설정해서는 안 됩니다.

스크린샷 34.   jmp  에서 상대 주소 설정하기

 

이제 jmp 를 만들기 위해 MessageBox 주소를 esi 에 저장해야 합니다 .

IDA Pro를 다시 실행하고 g_isDebbugerPresent 변수의 주소로 이동합니다.

스크린샷 35. IDA Pro에서   g_isDebbugerPresent   변수의 주소

 

스크린샷 35에서 무조건 점프가 있음을 알 수 있습니다. 디버거를 통해 응용 프로그램을 실행하면 이전 명령에 절대 주소가 포함되어 있기 때문에 응용 프로그램이 충돌하고 응용 프로그램이 시작된 후 로더는 재배치 테이블을 전달하고 각 값에 델타를 추가하여 모든 주소를 유효하게 만듭니다. 지금 해야 할 일은 재배치 테이블에서 이 값을 제거하는 것입니다.

원본 파일을 IDA Pro에 로드하고 cmp (이전에 삭제됨)를 찾은 다음 IDA에서 바이트 표현으로 명령을 표시하는 옵션을 활성화하겠습니다. 이렇게 하려면 옵션 > 일반 을 선택합니다 .

스크린샷 36. 바이트 표현으로 명령을 표시하도록 IDA Pro 구성

 

이것은 우리가 얻는 것입니다:

스크린샷 37.   cmp   데이터 IDA Pro

 

cmp 는 1329로 시작하는 더블바이트 명령이고 주소는 132B로 시작합니다. jmp 가 1바이트 명령이고 주소가 상대적이라는 것을 알 수 있습니다(즉, 재배치 테이블에 있어서는 안 됨).

스크린샷 38.   IDA Pro의   jmp 데이터

 

따라서 재배치 테이블에서 132A 값을 제거해야 합니다. 그렇게 하려면 Relocation Section Editor로 테스트 애플리케이션의 현재 버전을 열어야 합니다.

 

5. 재배치 섹션 편집기로 재배치 테이블에서 값 삭제

먼저 테스트 애플리케이션을 로드하고 대상 값인 0x0040132A를 찾습니다.

스크린샷 39. 재배치 섹션 편집기에 표시된 애플리케이션 값

다음으로 목표 값을 제거하고 테스트 애플리케이션을 저장합니다.

지금 응용 프로그램을 실행하면 여전히 충돌하므로 IDA Pro로 돌아가야 합니다. 

재배치 테이블에서 132A를 제거하고 jmp / mov 를 교체한 후 이전에 mov 를 가리키고 있었고 이제 jmp 를 가리켜야 하는 값을 편집하지 않았기 때문에 응용 프로그램도 충돌합니다 . CFF Explorer는 이 문제를 해결하는 데 도움이 될 수 있습니다.

6. CFF Explorer로 재배치 테이블의 값 수정

이제 CFF Explorer에서 테스트 애플리케이션을 열 차례입니다. MessageBox의 델타가 추가된 값인 1332를 찾았습니다.

스크린샷 40. MessageBox 델타를 추가하기 위한 값

값 1332를 MessageBox를 찾을 수 있는 새 오프셋인 값 132B로 바꾸겠습니다. 지금 테스트 애플리케이션을 실행하면 감지된 디버거에 대한 경고 메시지가 표시되거나 충돌이 발생하지 않습니다.

다음으로 MessageBox 함수 호출 작업으로 이동합니다.

 

 

7. API Monitor

이 프로그램은 API 호출을 모니터링하는 데 사용되며 모니터링할 수 있는 여러 알려진 API 기능을 포함합니다. API Monitor에 고유한 기능을 추가하고 이 도구를 사용하여 네트워크 기능 호출을 모니터링하고 전달된 매개변수를 조사할 수도 있습니다(물론 트래픽이 암호화되지 않은 경우).

애플리케이션을 모니터링합시다. MessageBox 함수에 대한 호출을 찾으려고 합니다.

스크린샷 41. MessageBox 함수 호출

메시지 창을 표시할 수 있는 API 함수에만 관심이 있습니다. 따라서 User32.dll에서만 선택합니다.

API Monitor에서 File > Monitor New Process 를 선택 하고 파일 경로를 설정합니다. 프로세스를 실행하면 호출된 함수 목록이 표시됩니다. MessageBox를 찾아 보겠습니다.

스크린샷 42. API Monitor 분석 결과의 MessageBox 함수

API 모니터는 MessageBox 함수에 전달된 매개변수를 보여줍니다. 또한 함수에 대해 다른 중단점을 설정할 수 있습니다.

스크린샷 43. API 모니터의 함수 중단점 옵션

파일 모니터링을 실행하면 다음 결과를 얻을 수 있습니다.

스크린샷 44. API Monitor에서 애플리케이션 모니터링 결과

스크린샷 44는 MessageBox 함수에 전달된 매개변수도 보여줍니다.

 

8. WinHex

이제 이전에 IDA Pro 및 API Monitor로 감지한 코드를 찾을 수 있도록 바이너리 작업으로 이동합니다. 그러나 바이너리를 탐색하기 전에 16진 편집기로 그 유형을 결정해야 합니다. 이 예에서는 WinHex를 사용합니다.

WinHex로 파일을 엽니다.

스크린샷 45. WinHex의 애플리케이션 데이터

오프셋이 0인 MZ 서명은 PE 형식 파일(실행 파일 또는 공유 라이브러리)에 해당하므로 exe 파일 또는 dll입니다. 대부분의 파일 형식에는 고유한 서명이 있습니다. 예를 들어 WinHex에서 덤프 파일은 다음과 같이 표시됩니다.

스크린샷 46. WinHex가 처리하는 덤프 파일의 예

 

9. Scylla

Scylla로 작업하는 방법을 보여주기 위해 다시 한 번 패킹된 애플리케이션을 사용할 것이지만 이번에는 압축을 풀지 않을 것입니다. 대신 메모리를 덤프하고 실행하려고 합니다.

이를 위해 IDA Pro에서 압축된 실행 파일을 엽니다. 이번에 는 패커의 진입점이 아닌 애플리케이션에 대한 원래 진입점 (OEP) 을 찾아야 합니다 .

스크린샷 47. IDA Pro로 애플리케이션의 원래 진입점 검색하기

pusha 명령 은 범용 레지스터를 스택에 저장합니다. 결국 저장된 레지스터 값을 푸시하는 popa 명령이 있어야 합니다. popa 명령 뒤에는 원래 진입점에 대한 jmp 가 있습니다 . Alt + T 를 누르고 popa 명령 을 찾아 텍스트 검색 옵션을 사용할 수 있습니다 .

스크린샷 48.   popa   명령

popa 명령 아래에는 jmp 40A191 이 있으며 결국 원래 진입점으로 이동합니다.

jmp 에 중단점을 넣고 디버거를 실행해 보겠습니다 .

이제 jmp 를 따라갈 수 있습니다 . 그러나 IDA Pro는 다른 경고 메시지를 표시합니다.

스크린샷 49. IDA Pro에 코드 경고 메시지 없음

이 메시지는 우리가 가고자 하는 지점에 코드가 없다는 것을 의미합니다. 따라서 IDA는 EIP(Extended Instruction Pointer)가 가리키는 바이트를 기반으로 디스어셈블된 목록에 명령을 생성합니다.

스크린샷 50. 애플리케이션의 원래 진입점 주소

0x00971A91은 응용 프로그램을 메모리에 압축 해제한 후 원래 진입점의 주소입니다.

이제 IDA Pro를 닫지 않고 Scylla를 열어 응용 프로그램의 덤프를 만들고 응용 프로그램의 가져오기 테이블을 복원합니다.

프로세스 목록에서 애플리케이션을 선택하고 OEP 주소를 필드에 입력합니다. 그런 다음 먼저 IAT 자동 검색 을 선택한 다음 가져오기 가져오기 를 선택 합니다. 결과적으로 Scylla는 가져오기 테이블이 발견되었음을 표시합니다.

스크린샷 51. Scylla로 테스트 애플리케이션 처리하기

응용 프로그램 덤프를 만들어 보겠습니다. Dump를 누르고 덤프 를 저장한 다음 Fix Dump 를 클릭 하고 이전에 저장한 응용 프로그램을 선택합니다.

지금 애플리케이션을 실행하면 충돌이 발생하므로 재배치 테이블을 제거해야 합니다. 이렇게 하려면 CFF 탐색기에서 수정된 덤프 파일(_SCY 접두어 있음)을 엽니다.

스크린샷 52. CFF 탐색기에서 수정된 애플리케이션 덤프 파일 작업

재배치 디렉터리 RVA 필드에 0을 설정합니다.

다음으로 ImageBase가 메모리에 로드된 응용 프로그램과 동일한지 확인해야 합니다. 

스크린샷 53. CFF 탐색기에서 응용 프로그램의 ImageBase 데이터

Edit > Segments > Rebase program 으로 이동하여 IDA Pro에서 ImageBase 값을 찾을 수 있습니다 .

스크린샷 54. ImageBase 분석을 위한 IDA Pro 구성

테스트 애플리케이션을 저장하고 실행해 봅시다. 이제 포장된 것처럼 실행됩니다.

 

 

원문 : https://www.apriorit.com/dev-blog/366-software-reverse-engineering-tools

반응형
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/04   »
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 29 30
글 보관함