임베디드 시스템에 탑재되는 소프트웨어에 대한 감정은 탑재된 바이너리 코드를 생성하는 소스 코드를 대상으로 진행하는 것이 합리적입니다. 그러나 소스 코드가 없고 임베디드 시스템의 소프트웨어가 내장된 바이너리 코드가 전부일 경우가 많습니다.
이러한 감정 대상물의 경우 극히 제한된 범위 내에서 그 유사성 여부를 판단할 수 있습니다. 즉, 하드웨어와 소프트웨어를 거의 변경하지 않고 그 외형이나 칩이나 보드의 형태 등 제조 과정의 개선이나 상품의 외형의 변형이 있는 것과 같이 마이크로컨트롤러와 주변회로 또는 소프트웨어가 일부 변경된 경우에만 가능할 것입니다.
이러한 특수한 경우에 대해 감정이 진행될 경우라도 마이크로컨트롤러의 감정과 마찬가지로 하드웨어의 호환성 여부가 반드시 선행되어야 하며, 호환성이 만족될 때 바이너리 코드의 추출 가능성이 문제가 됩니다. 일단 바이너리코드가 확보되면 역어셈블을 통해 부분적으로나마 유사도를 측정할 수 있으나, 그 유효성은 극히 제한된 영역에서만 가능할 것입니다.
가. 바이너리 코드의 생성과 역어셈블
임베디드 시스템에서 사용자로부터 시스템 제어에 대한 명령을 받아 실제 제어 동작을 수행하도록 하는 것은, 시스템의 프로그램에 해당하는 바이너리 OP코드에 의해서 결정됩니다. 시스템 프로그램은 주로 롬 등에 저장된 바이너리 코드들은 일반적인 데스크톱 컴퓨터의 하드 디스크에 저장되어 있으면서 사용자의 명령에 따라 실행되는 프로그램 코드와 같다고 볼 수 있습니다.
이러한 롬 프로그램은 퍼스널 컴퓨터에서 실행되는 실행 프로그램과 같이 소스 프로그램으로부터 컴파일러와 링커(또는 어셈블러)에 의해 각 마이크로프로세서에서 실행 가능한 바이너리 프로그램 코드로 번역됩니다. 흔히 실행 코드(executable code) 또는 실행 파일(execution file .exe로 표시됨)로 불리는 실행 프로그램이 퍼스널 컴퓨터에서 하드디스크등에 저장되듯이 감정 대상 제품인 마이크로프로세서 기반 제어 시스템에서는 주로 롬, EP롬에 저장되어 실행됩니다.
이런 이유로 소스 프로그램이 동일하더라도 바이너리 코드를 생성하기 위해 사용된 컴파일러가 다르면 생성되는 바이너리 실행 코드는 다를 수 있고, 같은 컴파일러가 사용되더라도 컴파일 할 때 주어지는 컴파일 옵션에 따라 바이너리 실행 코드는 달라지게 됩니다. 따라서 롬으로부터 얻어진 바이너리 코드의 유사성 비교는 롬에 수록된 바이너리 코드의 비교보다는 원래 롬에 수록될 바이너리 코드를 생성시키는 소스프로그램에 대하여 유사성을 비교하는 것이 가장 객관적이고 정확할 것입니다.
그러나 제품의 임베디드 보드의 롬에서 추출한 바이너리 코드만이 감정 대상물로 제출되는 경우가 많은데, 이런 경우의 감정에서는 소스 코드의 비교보다는 정확도가 낮으며, 아울러 유사도 측정에 한계가 있습니다.
감정대상물이 롬 소자 또는 롬 소자를 내장한 시스템 또는 제품이 제출되었을 경우, 롬 소자로부터 바이너리 코드를 획득하여 역어셈블(disassemble)과정을 통해 어셈블리 코드로 구성된 프로그램을 생성하고 이 프로그램 코드를 각각 비교하여 롬에 수록된 소프트웨어의 유사성을 측정합니다.
나. 감정 대상 영역 설정
일반적으로 8비트 또는 16비트 마이크로 컨트롤러의 프로그램 영역에 저장된 바이너리 파일은 일반적으로 크게 프로그램 영역과 데이터 영역으로 나뉘는데, 프로그램 영역은 마이크로프로세서의 실질적인 프로그램 실행 영역의 OP코드영역이며 데이터 영역은 프로그램에 필요한 각종 데이터를 저장하는 곳입니다. 프로그램 영역은 다시 크게 프로그램 구조에 따라 인터럽트 처리 루틴, 메인 루틴, 서브루틴으로 구분되고, 데이터 영역은 각 프로그램이 실행되는 과정에서 필요한 데이터들 즉, 상수, 화면 표시용 문자열, 프린터용 문자 코드표, 각종 함수 변환 테이블 등이 수록됩니다.
프로그램 실행 중 연산과정에서 발생하는 데이터는 램에 저장되지만 롬에 저장된 데이터는 프로그램실행에 필요한 불변 데이터를 수록하고 있습니다. 데이터영역에 저장된 내용도 프로그램의 일부이므로 유사도 비교 대상이지만, 단순히 바이너리 수치만으로 그 데이터의 의미를 파악하기 어렵으므로, 감정의 유사도 측정대상에서는 제외하는 것이 타당합니다. 프로그램의 속성상 데이터 영역에는 다수의 데이터들이 수록되어 있고 프로그램 영역과 확연이 구별되므로 이 부분을 제외한 나머지 부분에 대해 역어셈블하여 프로그램을 추출합니다.
롬에서 추출되는 내용은 단순히 2진수로 표시된 수치에 불과하기 때문에 그 내용이 무엇인지 판별하기 어렵습니다. 관행적으로 프로그램 코드는 어드레스 앞쪽 영역에 주로 존재하고 데이터영역은 뒤쪽에 존재하는 점과, 앞서 살펴본 바와 같이 데이터 영역의 내용이 ASCII 문자열로 번역해 보았을 때 의미 있는 단어 등이 구성되는 점으로 미루어 프로그램 영역과 데이터 영역을 분할할 수 있습니다.
다. 어드레스 불일치 상쇄
바이너리 프로그램 코드는 일반적인 C언어나 JAVA등의 고급 프로그래밍 언어의(또는 어셈블리 언어로 작성된) 소스 프로그램과는 다르게 원시 프로그램으로부터 컴파일 되거나 어셈블 되는 과정에서 바이너리 내용의 일부가 각 OP코드가 저장되는 위치에 따라 바뀌게 됩니다. 예를 들면 점프(JUMP)나 서브 함수 호출은 해당 OP 코드 후에 오는 바이너리 값이 각각 점프해야할 곳의 위치에 대한 어드레스 정보가 저장되게 되는데 이 어드레스 값은 컴파일 또는 어셈블 되는 과정에서 결정되는 정보입니다. 소스 프로그램에 한두 줄의 프로그램 라인을 삽입하면 그 삽입된 코드에 의해 그 이후 작성된 프로그램에 해당하는 위치 정보가 전부 바뀌게 되므로 동일한 컴파일러와 컴파일 옵션을 사용한다 하더라도 컴파일된 바이너리 OP코드의 상당 부분이 다른 바이너리 정보로 채워지게 됩니다.
이와 같은 이유에서 소스 프로그램의 유사성 비교는 작성된 프로그램의 원시 소스코드를 비교함으로써 측정 가능하지만 롬에 저장된 바이너리 프로그램 코드의 비교는 그 유사성 측정에 있어 한계가 있습니다.
롬에 저장된 프로그램 코드는 코드 자체의 직접적인 비교보다는 역어셈블(disassemble), 또는 역컴파일(discompile)된 상태의 프로그램의 비교에 의해서 보다 객관적이고 정확한 복제 또는 유사성 여부를 판단 할 수 있으나 완벽한 역컴파일러의 구현은 어렵습니다. 역어셈블 과정은 역컴파일에 비해서 상대적으로 구현이 쉽고 대부분 마이크로프로세서의 바이너리 프로그램 코드에 대한 역어셈블러는 공개 프로그램으로 쉽게 입수가 가능하므로 역어셈블된 어셈블리 코드간의 그 유사성을 측정하는 것이 현실적으로 가능한 방법입니다.
이 방법 역시, 소스 프로그램의 유사성 비교에 비해서는 정확도가 떨어지지만 어느 정도의 객관적 유사도 측정으로서는 의미가 있을 것으로 판단되나 역어셈블러는 단순히 바이너리 프로그램 코드를 코드와 일대일로 대응되는 어셈블리 프로그램 코드로 변환하기 때문에 프로그램 내에 존재하는 논리적인 내용(각종 레이블, 서브루틴 이름 등..)과 프로그램 흐름에 대한 각종 부가 정보를 재대로 재현해 내기 어렵습니다.
이와 같이 역어셈블도 그 한계성에 의해 앞서 언급한 어드레스 정보의 불일치는 완전히 극복할 수 없으므로 이러한 문제를 해결하기 위하여 유사성 비교를 위한 상대 위치를 공통 레이블로 변환시키는 방법 등을 통해 위와 같은 불일치 현상을 유사성 비교 대상에서 제외시키도록 합니다.
정회목 변호사
댓글 없음:
댓글 쓰기