내가 리버스 엔지니어링에 관심을 가지게 된 건 리눅스를 쓰기 시작하면서부터인 것 같다. 이 시궁창 같은 나라의 현실에서는 윈도에서만 되는 것이 너무 많았기 때문에, 리눅스에서도 그에 해당하는 무언가를 이루어 내기 위해서 프로그램의 핵심 부분만 어떻게 알아낸 다음 똑같거나 비슷하게 구현하여 쓰는 것이다.

리버스 엔지니어링을 하기 위해서 프로그램을 따거나, 장치와 통신하는 프로그램의 경우에는 장치와의 통신 신호를 잡아내기도 한다. 프로그램의 내부 구조를 들여다보려면 어셈블리어를 할 수 있어야 하며, 디버거 같은 것을 사용할 줄 아는 것이 좋다. 장치와의 통신을 캡처하려면 USB 버스의 신호를 캡처하는 프로그램이 필요하다. 내 개인적으로는 IDA와 SnoopyPro 같은 툴을 사용한다.

IDA Pro

SnoopyPro. 오래되긴 했어도 아직도 쓸만하다.

프로그램이나 버스 신호를 따 낸다고 해서 끝나는 것은 아니다. 어셈블리만 있다고 해서 완성된 프로그램이 나오는 것은 아니기 때문이다. 똑같은 로직을 이를 들여다보고 다시 구현하는 방법이 있지만 저작권 문제 때문에 이를 사용하는 일은 거의 없다. 클린 룸 엔지니어링이라는 방법은, 누군가가 소스 코드를 들여다보고 스펙을 작성한 다음, 그 스펙을 기반으로 제 3자가 코드를 짜는 방법이다. 저작권 문제를 피할 수 있기 때문에 이 방법을 많이 사용한다.

블랙박스 DLL이 있고 이를 호출해서 원하는 결과를 얻어야 한다면 이 DLL을 호출하는 프로그램을 다시 짜야 하고, 프로그램의 로직 그 자체가 필요하면 그것을 다시 짜야 한다. 내가 관심이 많은 윈도 DLL을 리눅스에서 호출하는 것은 WINE 라이브러리로 좀 까다롭게 할 수 있다. WINE 라이브러리를 기존 리눅스 코드에 섞는 것은 어렵지 않지만, 실제 프로그램을 짜서 테스트를 하는 동안 문제가 발생한다면 WINE 라이브러리를 쓰는 래퍼 프로그램 하나와 그 프로그램과 통신하는 다른 프로그램으로 쪼갤 필요가 있다.

이러한 과정을 통해서 프로그램을 다른 OS 상에서 똑같이 작동시키는 순간 짜릿함을 느낄 수 있다. 대부분의 사람은 변환이 귀찮다고 하지 않는 휴대폰에 MP3 집어넣기를 리눅스 상에서 통신사의 크고 더럽고 무겁고 엿같은 프로그램을 쓰지 않고 성공시키는 것만큼 짜릿한 느낌을 받기는 힘들 겄이다. 이것이 리버스 엔지니어링을 하게 되는 원동력 같다.

WINE 라이브러리로 윈도 DLL 호출하기

막상 이렇게 리버스 엔지니어링을 다 해 두었다고 해도 이를 마음대로 공개했다가는 변호사들의 밥이 되기 쉽다. 한국의 컴퓨터프로그램보호법 제12조의2의 1은 리버스 엔지니어링을 할 수 있는 부분을 명확하게 정의해 두었다. 그러나 그 결과를 제 3자에게 제공하는 등의 행위는 법 위반이기 때문에 결과를 다른 사람과 공유하려면 어둠의 방법밖에 없다. 그러나 이 조항이 개선되기는 힘든 것이 프로그램 원 제작자의 저작권 보호와 상충되는 측면이 있기 때문이다. 그래도 미국의 DMCA 같은 싸이코스런 조항보다는 낫지만. (아래 그림의 출처로 가기)

DMCA의 부작용.

이 세상의 모든 프로그램이 자유 소프트웨어가 되지 않는 한 리버스 엔지니어링을 하려는 사람과 이를 막는 사람은 계속 대결 구도를 이룰 것이다.