THINK-PRO BLOG

소프트 브레이크포인트(Soft Breakpoint)는 명령을 실행하는 CPU를 일시 중지시키는데 사용되며 애플리케이션을 디버깅할 때 가장 흔하게 사용되는 형태의 브레이크포인트다. 소프트 브레이크포인트는 한 바이트 명령을 사용해 디버깅 대상 프로세스의 실행을 중지시킨다. 프로세스의 실행이 중지되면  디버거의 브레이크포인트 예외 핸들러가 제어권을 전달받는다. 이 작업이 어떻게 수행되는지 이해하려면 x86 어셈블리 언어에서의 명령과 opcode의 차이점을 이해하고 있어야 한다.

어셈블리 명령은 CPU를 실행시키기 위한 명령을 하이레벨 수준으로 표현한 것이다. 예를 들면 다음과 같다.

이 명령은 CPU가 EBX 레지스터에 있는 값을 EAX 레지스터에 저장하라는 의미로, 상당히 간단하다. 하지만 CPU는 사실 이 명령을 어떻게 해석해야 하는지 모른다. 따라서 어셈블리 명령은 opcode라는 형태로 변환되어야 한다. opcode는 바로 CPU가 실행하는 기계어 명령이다. 위의 어셈블리 명령을 opcode로 변환하면 다음과 같다.

보다시피 어떤 의미인지 파악하기 힘든 매우 난해한 형태로 변환되었다. 하지만 이런 형태로 CPU와의 대화가 이루어진다. 어셈블리 언어를 DNS 주소에 비유해 생각하면 이해가 쉬울 것이다. CPU가 실행하는 opcode(IP 주소)를 모두 기억하는 것은 어렵다. 따라서 기억하기 쉽게 변환한 것이 어셈블리 명령(DNS 주소)이다. 디버깅 시에 opcode를 사용해야 하는 경우는 거의 없다. 하지만 소프트 브레이크포인트를 이해하려면 중요하다. 예를 들어 0x44332211 위치의 opcode와 어셈블리 명령이 다음과 같다고 생각해보자.

이는 주소의 opcode, 어셈블리 명령을 보여준다. 이 주소의 위치에 소프트 브레이크포인트를 설정해 CPU를 일시중지시키려면 2바이트 opcode인 8BC3 중에서 1바이트를 교체해야 한다. CPU를 일시 정지시키기 위해 새롭게 교체되는 1바이트는 인터럽트 3(INT 3) 명령의 opcode다. opcode 0xCC로 교체되는 것이다. 다음은 소프트 브레이크포인트 설정 전과 설정 후의 상태를 보여준다.

브레이크포인트를 설정함에 따라 8B가 CC로 교체된 것을 확인할 수 있다. CPU가 이 바이트를 만나게 되면 INT 3 이벤트를 발생시킨다. 디버거는 자체적으로 이 이벤트를 처리할 수 있다. 따라서 디버거를 자체적으로 제작하려면 디버거가 이 이벤트를 어떻게 처리하는지 이해해야 한다. 디버거는 특정 주소에 브레이크 포인터를 설정하라는 명령을 받으면 해당 주소의 첫 번쨰 opcode바이트를 읽어 그것을 저장하고 그 위치에 CC 바이트를 써 넣는다. CC opcode로 인해 CPU가 브레이크포인트나 INT 3 이벤트를 발생시키면 디버거는 그 이벤트를 전달받는다. 그러면 디버거는 EIP 레지스터(instruction register)가 자신이 이전에 설정한 브레이크포인트 주소를 가리키고 있는지 확인한다. EIP 레지스터가 가리키는 주소가 디버거 내부의 브레이크포인트 리스트에 존재하면 디버거는 실행이 다시 재개될 때 올바로 실행되게 하기 위해 이전에 저장해 두었던 원래의 opcode 바이트를 해당 주소 위치에 써 넣는다.

디버거는 소프트 브레이크포인트를 처리하기 위해 많은 일을 수행해야 한다. 소프트 브레이크포인트는 두 가지 종류가 있다. 하나는 일회성 브레이크 포인트(One-shot breakpoint)이고, 다른 하나는 지속적인 브레이크포인트(persistent breakpoint)다. 일회성 브레이크포인트는 한 번 브레이크포인트 이벤트가 발생하면 디버거의 내부 브레이크포인트 리스트에서 해당 브레이크포인트 정보가 제거되는 것이다. 이는 단 한 번만 브레이크포인트를 발생시키고자 할 때 안성맞춤이다. 지속적인 브레이크포인트는 브레이크포인트가 발생하고 CPU가 원래의 opcode를 실행한 다음에 다시 브레이크포인트 설정을 수행하는 것이다. 따라서 브레이크포인트 리스트의 정보는 계속 유지된다.

소프트 브레이크포인트는 한 가지 단점이 있다. 그것은 메모리 상의 실행 바이너리의 바이트를 변경하기 때문에 CRC(Cyclic Redundancy Check) 체크섬 값이 변경된다는 것이다. CRC는 데이터가 변경되었는지 확인하기 위해 사용되는 방법이며, 파일, 메모리, 텍스트, 네트워크 패킨, 기타 모든 종류의 데이터에 적용가능하다. CRC는 특정 범위의 데이터 영역으로부터(이 경우에는 프로세스의 메모리 영역) 그것의 해쉬 값을 산출해 낸다. 그리고 데이터가 변경되었는지 확인하기 위해서 해당 데이터 영역의 원래 CRC 체크섬 값과 비교한다. 체크섬값이 서로 틀리면 데이터가 변경된 것이다. 악성 코드는 흔히 실행되고 있는 자신의 메모리상 코드에 대한 CRC 체크섬 값을 확인한다. 그리고 자신의 코드가 변경됐다는 것이 확인되면 스스로 종료해버린다. 이렇게 하면 악성 코드는 자신을 리버스 엔지니어링하는 것이나 소프트 브레이크포인트를 설정해 분석하는 것을 효과적으로 차단할 수 있다. 따라서 결국엔 악성 코드의 행위만을 동적 분석할 수박에 없다. 이런 한계점을 극복하려면 하드웨어 브레이크 포인트를 사용해야 한다.

▲ 위와 같이 실행 코드를 일시 중지시키는 기능의 '브레이크포인트'

실행 중인 디버깅 대상 프로세스를 멈추게 하려면 브레이크 포인트를 설정한다. 브레이크포인트에 의해 프로세스가 일시 중지되면 중지된 시점의 변수나 스택 파라미터, 특정 메모리 위치의 값들을 조사해 볼 수 있다. 프로세스를 디버깅할 때 가장 흔히 사용하는 기능이 바로 브레이크포인트다. 브레이크포인트는 세 가지 종류가 있는데, 1) 소프트 브레이크포인트, 2) 하드웨어 브레이크포인트, 3) 메모리 브레이크포인트다. 세 가지 브레이크포인트 모두 유사한 동작을 수행하지만 구현되는 방법은 완전히 다르다.