임베디드 장치에 동적 리버스 엔지니어링을 사용하는 방법

블로그

홈페이지홈페이지 / 블로그 / 임베디드 장치에 동적 리버스 엔지니어링을 사용하는 방법

May 21, 2024

임베디드 장치에 동적 리버스 엔지니어링을 사용하는 방법

IoT의 확산은 보안 취약점의 확산을 동반합니다. 확인하지 않은 채로 놔두면 악의적인 공격자는 이러한 약점을 이용하여 조직의 시스템에 침투할 수 있습니다. 정기적인

IoT의 확산은 보안 취약점의 확산을 동반합니다. 확인하지 않은 채로 놔두면 악의적인 공격자는 이러한 약점을 이용하여 조직의 시스템에 침투할 수 있습니다.

오랫동안 보안 모범 사례로 인식되어 온 정기적인 침투 테스트는 보안 팀이 내장형 장치의 취약성과 약점을 식별하고 완화하는 데 도움이 됩니다. 그러나 많은 조직에서는 침투 테스트를 네트워크 및 인프라 조사로 제한합니다. IoT 장치는 간과되는 경우가 많습니다.

사이버 위험 및 금융 서비스 컨설팅 회사인 Kroll의 수석 부사장인 Jean-Georges Valle는 보안 팀이 임베디드 장치 펜 테스트에 대한 최신 정보를 얻을 수 있도록 Practical Hardware Pentesting: Learn Attack and Defense Techniques for Embedded Systems in IoT 및 기타 장치를 작성했습니다. .

10장의 다음 발췌문에서 Valle은 침투 테스터가 동적 리버스 엔지니어링을 사용하여 임베디드 장치에서 실행되는 동안 코드가 어떻게 작동하는지 확인하는 방법을 자세히 설명합니다. Valle은 코드 작동 방식을 관찰하는 동안 발생할 수 있는 문제를 침투 테스터에게 보여주기 위해 동적 역엔지니어링의 예를 제공합니다.

Valle가 사용하는 일반적인 테스트 단계, 임베디드 펜 테스트의 어려움, 오늘날 조직이 임베디드 장치를 얼마나 잘 보호하는지에 대한 그의 의견을 포함하여 임베디드 침투 테스트에 대한 Valle의 인터뷰를 읽어보세요.

편집자 주: 다음은 Practical Hardware Pentesting, Second Edition의 초기 액세스 버전에서 발췌한 것이며 변경될 수 있습니다.

나는 우리에게 몇 가지 과제를 제기할 이전 예제의 변형을 준비했습니다. 두 경우에 필요한 노력의 양을 비교할 수 있도록 이러한 문제를 정적 및 동적으로 극복하는 방법을 보여 드리겠습니다.

동적 접근 방식과 정적 접근 방식을 비교할 때의 경험 법칙은 99%의 경우 동적 접근 방식이 더 쉽고 가능하다면 우선순위를 부여해야 한다는 것입니다(JTAG/SWD 또는 기타 접근 방식에 액세스하지 못할 수도 있다는 점을 잊지 마십시오). 온칩 디버깅 프로토콜).

이 섹션에서는 우리가 원하는 부분을 중단하는 방법, GDB로 메모리를 검사하는 방법, 그리고 이 모든 좋은 것들을 배울 것입니다!

대상 프로그램은 복제한 폴더의 ch12 폴더에 있습니다.

먼저 Ghidra에 로드하여 표면적으로 살펴보겠습니다. Ghidra의 로딩 창에서 올바른 아키텍처와 기본 주소를 설정하는 데 주의를 기울이세요(설정 방법이나 기본 주소 값을 기억하지 못하는 경우 이전 장을 참조하세요).

언뜻 보기에 main 함수는 이전 장의 main 함수와 매우 비슷해 보입니다. 이전 장에서처럼 PASSWORD 문자열을 검색하여 main 함수에 대한 참조를 찾고 그 구조를 분석하면 알 수 있습니다.

이전 장에서 습득한 기술을 활용하여 다양한 기능을 찾아보도록 하겠습니다. 이 실행 파일에서 다음을 다시 찾을 수 있습니다.

구조의 유사성은 이번이 처음이기 때문에 의도적인 것입니다. 이전 장에서와 똑같은 단계를 반복한다면 새로운 것을 배울 수 없을 것입니다. 그렇죠?

이제 시스템과의 동적 상호 작용을 통해 이 비밀번호 확인을 우회하는 여러 가지 방법을 살펴보겠습니다. 우리는 여러분이 집중력을 유지하고 노하우를 습득할 수 있도록 가장 복잡한 것에서 가장 단순한 것으로 갈 것입니다. (당신이 나와 같은 사람이라면, 무언가를 우회할 수 있는 쉬운 방법이 있다면, 왜 어려운 길을 갈까요?)

우리가 할 첫 번째 일은 테스트를 통과하는 비밀번호를 생성하는 방법을 이해하기 위해 비밀번호가 어떻게 검증되는지 살펴보는 것입니다.

Ghidra가 출력하는 유효성 검사 함수에 해당하는 C 코드를 살펴보겠습니다.

흠... 이것은 매개변수에 직접적으로 아무 것도 하지 않습니다. 이는 0x47(71) 길이의 정적 바이트 배열의 내용을 RAM에 복사한 다음 이를 함수로 호출합니다.

이건 이상해.

아니면 그럴까요?

이는 코드를 위장하는 매우 일반적인 기술입니다(물론 매우 간단한 버전입니다). opcode의 명확한 버전이 .bin 파일에 없으면(따라서 MCU 플래시에도 없으면) Ghidra와 같은 리버스 엔지니어링 도구는 그것이 코드인지 감지할 수 없습니다! 여기에는 두 가지 가능한 접근 방식이 있습니다.