반응형

 

 

 

 


 

디버거에서 EP 코드 부분을 확인하니 패킹이 되어 있는 것 같다.

 

 

UPX 언패킹을 해주고

 

 

EP 부분을 확인하니 원래의 EP 부분이 나왔다.

 

하나 특이한 점은 40100C 주소 위의 주소들의 명령들이 전부 nop이라는 것이다.

 

이 문제의 동작이나 풀이는 https://sean.tistory.com/214?category=978374 글에서 확인할 수 있다.

 


풀이

 

StolenByte란 훔친 byte란 의미로 일종의 안티디버깅 기법이라고 한다.

 

StolenByte는 패커가 이동시킨 코드의 윗부분을 말한다.

 

프로그램의 코드 한 부분을 훔쳐 다른 부분으로 옮겨진 코드인데, 정확히는 프로그램의 원래 코드 윗 부분을 UPX1으로 이동시켜서 UPX0에 덤프되지 않는 코드를 말하는 것이다.

 

StolenByte를 적용하는 이유는 원래 언패킹을 할 때 OEP를 찾아서 덤프를 뜨는데, StolenByte가 적용된 패킹 파일은 OEP 이전에 코드의 일부가 존재하기 때문에 OEP를 찾아서 덤프를 떠도 프로그램이 정상적으로 실행하지 못한다.

 

즉, 언패킹을 방해하는 것이다.

 

대표적으로 OEP로 점프하기 전에 값을 PUSH 하고, OEP로 점프한 뒤 CALL 명령어로 함수를 호출하는 방법이 있다.

 

 

원래 UPX 패킹의 특성은 EP 코드가 PUSHAD와 POPAD로 둘러싸여 있고, POPAD 다음에 바로 OEP로 가는 jmp 문이 있는데 위의 사진은 StolenByte로 인해 popad와 jmp 사이에 PUSH 명령어를 통해 후에 OEP로 이동 후 호출할 함수에서 사용될 인자들을 스택에 넣는다.

 

40736E부터 40737E 주소의 push 명령어들은 원래 아래의 사진에서 nop에 위치한 명령어들이다.

 

 

위의 사진을 보면 MessageBoxA() 함수를 호출하는데 MessageBoxA() 함수의 인자들을 스택에 넣은 것이다.

 

 

StolenByte를 복구하는 방법은 위와 같이 PUSH 명령어들만 MessageBoxA() 함수 호출 전의 nop 부분에 옮겨주는 것이다.

 

그리고 문제의 답은 NOP 부분으로 옮긴 PUSH 명령어들의 OP Code를 합친것이다.

6A0068002040006812204000
반응형

'전쟁 > codeengn' 카테고리의 다른 글

[codeengn] Basic RCE 11  (0) 2022.07.28
[codeengn] Basic RCE 10(OEP로 이동 후 덤프)  (0) 2022.07.28
[codeengn] Basic RCE 08  (0) 2022.07.28
[codeengn] Basic RCE 07  (0) 2022.07.28
[codeengn] Basic RCE 06  (0) 2022.07.28

+ Recent posts