오늘의 샘플 분석
Posted 2007. 6. 16. 01:13, Filed under: Study/Computer Science악성 코드가 루프를 돌면서 반복적으로 시스템에 관련된 데이터나 계정 정보를 파라미터로 해서 반복적으로 호출하는 루틴의 경우에 하나하나 꼼꼼하게 따져보기 보다는 대충 어떤 일을 하는지 판단하는게 좋은 것 같다.
특정 위치에 쓰는 루틴이면 어디에 어떤 내용을 기록하는지. 비교하는 루틴이면 어떤 문자열과 뭘 비교해서 조건이 만족될 경우 어떤 작업을 수행하는지.
혹은 복호화 루틴을 수행해서 메모리 상에 쓰는 경우도 있는데, 특정 문자열을 파라미터로 받아서 루프를 돌고 자기 자신의 코드섹션에 기록할 경우에 이럴 가능성이 크다.
리소스 섹션에 기록하는 경우는 드랍퍼일수도 있고.
사용자가 정의한 함수가 반복적으로 호출될 경우에는 파라미터가 뭔지, 레지스터상의 어떤 값이 변하는지, 메모리 상의 어느 위치에 기록되는지를 우선 파악할 것.
외부로 전송하기 위한 데이터를 작성하는 경우에는 특정 필드를 어떤 규칙적인 값으로 채워놓고 AND 연산을 통해 데이터를 덮어쓰면 나름대로 마스킹을 통한 암호화가 되는 듯.
특정 필드를 규칙적인 값으로 도배하는 부분이 나오면 외부로의 데이터 전송을 의심
(오늘 봤던 Agent 가 요런 짓을 하고 있었음)
그리고 결정적인 부분에서는 결국 API 를 사용할 수 밖에 없으므로 의심가는 부분은 무조건 확인해야 한다
디스어셈블리 코드만 쳐다보고 있으면 머리 아프다 -_-
----------
실행 압축이 되어있는 경우에는 올리에서 자체 지원하는 unpacking 기능을 사용하거나
unpacker의 패턴을 보고 판단.
실행 압축을 해제할 때도 중요한 포인트는 결국 실행 가능한 코드를 어딘가에 쓴 다음에 거기로 뛴다는거. (OEP) 그리하여 이승원 선임님의 명언 - unpacking 은 근성이다 -_-;
실행 압축을 푸는 과정은 필연적으로 루프와 점프로 도배가 되어있다.
JMP 코드가 있는 부분을 주의 깊에 보면서 루프인지,. 빠져나가는 루틴인지 확인
그리고 막판에 PUSH, RETN 코드가 나오면 빙고~
PUSHAD로 레지스트리 상태를 백업하면서 시작하는 실행 압축 (ex: UPX) 의 경우에는 POPAD 하게 되는 메모리 직접 주소에 하드웨어 BP를 거는 것도 한가지 방법.
------------
요런 거 적으면 회사 사람들한테 혼날라나요..;;
뭐 누가 보겠노 ;;