objdump -d를 호출하여 반환 된 어셈블리 결과의 제어 흐름 그래프를 작성하려고합니다. 현재 최선의 방법은 결과의 각 행을 링크 된 목록에 넣고 각 행의 메모리 주소, opcode 및 피연산자를 구분하는 것입니다. 난 objdump 결과의 정기적 인 특성에 의존하여 그들을 분리 해요 (메모리 주소는 각 행을 나타내는 문자열에서 문자 2에서 문자 7까지입니다).Objdump의 결과를 사용하여 제어 흐름 그래프 작성
일단 이것이 끝나면 실제 CFG 명령을 시작합니다. CFG의 각 노드는 시작 및 종료 메모리 주소, 이전 기본 블록에 대한 포인터 및 모든 하위 기본 블록에 대한 포인터를 보유합니다. 그런 다음 objdump 결과를 검토하고 opcode를 x86_64의 모든 제어 흐름 opcode 배열과 비교합니다. opcode가 제어 흐름 인 경우, 주소를 기본 블록의 끝으로 기록하고 opcode에 따라 두 개의 자식 포인터 (조건부 opcode) 또는 하나 (호출 또는 반환)를 추가합니다.
나는 이것을 C로 구현하는 중이며, 제대로 작동하지만 매우 약하다. 누구든지 어떤 제안이나, 내가 고려하지 않은 것이 있습니까?
시간을내어 읽어 주셔서 감사합니다.
편집 :
생각은, 내가 이런 식으로 구축하는 것을 용이하게 바라고 대상 바이너리에 대한 예상 CFG에 대해 DynamoRIO에 의해 생성 된 시스템 호출 스택 추적을 비교하는 데 사용하는 것입니다. A) 나는 그것에 대해 실제로 생각하지는 않았고 B) 그래프를 사용 가능한 데이터 구조로 가져와 경로 비교를 할 수 있어야하기 때문에 사용할 수있는 것을 다시 사용하지 않았습니다. 필자는 여러분이 줄 지어있는 페이지에있는 몇 가지 유틸리티를 살펴볼 것입니다. 올바른 방향으로 나를 안내해 주셔서 감사합니다. 귀하의 의견에 감사드립니다, 정말 고마워!
그럴듯한 전반적인 접근 방식과 비슷합니다. 간접 호출을 볼 때해야 할 일에 대해 생각하고 싶을 수 있습니다. 또한 반환 지시에는 하나의 후임자가있을 것이라고 말하면 - 정확히 말하자면, 여러 발신자가있는 기능의 경우? CFG (예 : LLVM IR)에는 통화 및 반품이 포함되지 않는 경우가 많습니다. "올바른"답변은 CFG를 제작 한 후에 CFG로 무엇을 할 계획인지에 달려 있습니다. –
흥미로운 접근 방법. 소스 코드에서 CFG를 만드는 데 사용할 수있는 몇 가지 도구가 있습니다 (http://en.wikipedia.org/wiki/Call_graph 참조). 사용 가능한 것을 재사용하는 대신이 접근법을 사용하려는 특별한 이유가 있습니까? – Sudhanshu
어떻게 함수 포인터를 해석하고 있습니까? 비슷한 종류의 프로그램을 작성하고 있지만 여전히 함수 포인터를 어떻게 해결할 것인지 궁금합니다. – prap19