securityfirst_jo

완전 쉬운 nspack....이걸 써야할지 말아야할지 생각도 안하고 ..그냥 올려본다..

해당 특징이라하면 특정 어셈 명령어에 대한 지식을 알면 쉽게 이해 할수 있다.

누구나 아는 upx에서 pushad 의 어셈명령이 무엇인지 기억하는가? 모든 레지스터에 대한 값을 저장하는것이였다.

여기서는 pushfd를 쓴다. PUSHFD 는 'push flags double-word' 의 약어로, 플래그를 

출처 : http://index2014.tistory.com/126

-----------------------------------------------------------------------------

자 여기까지가 이 팩에 대한 알아야할 기본 지식이다. 이 팩에서는 pushfd, pushad를 연속으로 씀으로써 플래그값 및 레지스터 정보를 다 저장하였다가 언팩하여 jmp 할때 해당 레지스터값을 복원하여 동작한다. 

nspack 확인

nspack에서 ep부분에 보이는 pushfd와 pushad 값을 확인할 수 있다. 

아래 보면 popad, popfd 후에 jmp를 하는것을 알 수 있다.

참고로 보면알겠지만 그냥 ctrl+f 눌러서 popfd하면 바로 나온다;; jmp에 bp걸고 ㄱㄱ 하면 끝 

이상 매우 쉬운 nsunpack에 대한 확인 및 언팩이였다....너무쉽다ㅣ

참조 : http://mylabs.tistory.com/m/post/17

여기서 중요한점은 

[ 디스어셈블 하고자 하는 드라이버의 EP부터 트레이싱 하기 위한 방법 ]
    - EP의 첫 바이트를 CC(int 3)으로 변경, checksum 을 수정 (커널 드라이버 로드시, 체크섬값 검사)
    - breakpoint 가 설정된 곳에서 멈추면, 해당 바이트를 다시 원래 코드로 수정
    - Trace 시작~!

 자, 감염된 상태의 시스템에서 로드된 NDIS가 악성인지 아닌지 어떻게 알수 있을까?!
 가장 간단하게 섹션의 정보 부터 확인해보자.

에서 드라이버를 분석하기위해 ep부분에 cc로 변경 후 다시 원래 바이너리로 수정하는거

---------------------------------------------------------------------------------

 작성한 6월 보안칼럼에서 ndis.sys를 변조시키는 악성코드에 관해서 언급했었다.

 당시 Sality 파일바이러스 심층분석으로 골머리를 썩고있는 상황이어서, 미루고 미뤄두었던 악성코드이다.
 CodeEngn 2009에서 고흥환님께서 발표하신 내용중에 일부이기도 한 악성코드이다. 
 간단하게 분석한 내용을 적어본다.

 [ Win32.Protector.A ~ C ]
 정상파일을 변조시키는 행동은 파일바이러스와 일맥상통하는 부분이지만, 추가적인 2차 감염을 발생시키지는 않는다.
 Virut 파일 바이러스들 중 일부가 ndis.sys 커널 드라이버를 변조시키는 사례가 많이 발생됐었다.
 그리고 최근에 다시 이슈화 된 AntiVirus 2010 계열의 허위백신은 같은 골격으로 ntfs.sys를 변조시키며,
 해외와 국내에 agp440.sys도 변조되고 있는 상황이다.

 커널드라이버 악성코드는 윈도우시스템에 필수 드라이버 파일인 ndis.sys 와 ntfs.sys 등 여러 드라이버를 타겟으로 하고있으며, 이는 여타 다른 드라이버파일도 안전할수 없다는 것을 의미한다.
 변조된 악성코드는 정상 드라이버의 이름을 가지고 있기때문에 커널 로드시 악성코드가 그대로 같이 메모리에 올려진다.
 커널에 로드된 악성 ndis.sys는 정상 ndis와는 확연히 다른 형태의 PE인것을 한눈으로 확인이 가능하며, 실행되어진 상태의 메모리 모습이기 때문에 최종으로 복호화 되어진 HEX값 역시도 확인 가능하다.

 변조된 드라이버 파일을 이용하여 시스템을 감염시켜보자.

 아래의 [그림1] 은 

 변조된 드라이버파일이 로드된 시스템을 windbg 커널 디버그 모드로 Attach 시킨 후에 로드된 NDIS 주소값이다.  
   [그림1] kernel에서의 NDIS드라이버가 로드된 주소값

 
 ndis.sys 의 EP(Entry Point) 부터의 어셈블리코드
   [그림2] Disassembly EP : f839c500

[ 디스어셈블 하고자 하는 드라이버의 EP부터 트레이싱 하기 위한 방법 ]
    - EP의 첫 바이트를 CC(int 3)으로 변경, checksum 을 수정 (커널 드라이버 로드시, 체크섬값 검사)
    - breakpoint 가 설정된 곳에서 멈추면, 해당 바이트를 다시 원래 코드로 수정
    - Trace 시작~!

 자, 감염된 상태의 시스템에서 로드된 NDIS가 악성인지 아닌지 어떻게 알수 있을까?!
 가장 간단하게 섹션의 정보 부터 확인해보자.

 먼저 정상 NDIS의 섹션정보를 보자.
  [그림3] 정상 NDIS의 섹션정보

 정상 ndis는 위와 같은 섹션 정보를 헤더에 가지고 있지만, 감염된 상태의 ndis는 확연히 차이나는 섹션구조를 가지고 있다.

  [그림4] 변조된 NDIS의 섹션정보
 [그림4] 는 windbg에서 커널에 로드된 상태의 헤더부분이지만, 실제 변조된 ndis 파일의 헤더정보도 위와 동일한 형태를 취하고 있다. (변종에 따라 INIT 섹션이 있는 경우도 있다.)


 이 글을 포스팅하기 한참전에 로직은 이미 완성된 상태였다. 최초엔 진단명을 특정 드라이버파일만을 변경한다는 의미에서 
Mndis, Mntfs 등으로 만들었지만,,, 동일한 감염로직으로 최근 다른 드라이버들도 피해를 보고있는 실정이다. 
 그래서 보편적으로 사용하고 있는 Protector 진단명으로 변경하게 되었다. Protector 진단명은 최초 카스퍼스키에서 만든것으로 추정되며, 진단명은 악성코드의 디버그 정보를 참조한 것 같다.
  - Conficker 도 그랬고, 대부분의 악성코드 제작자가 Release 버젼이 아닌 debug버젼으로 컴파일해서 배포를 하는듯 한데, 그 과정에서 파일상에 정보가 조금씩 남는 경우가 많다.

  [그림5] 파일상에 남아있는 디버그 정보
 

 [ Protector 주요 특징 ]

[그림6] 메모리상에 복호화된 정상 NDIS
 [그림1] 에서 로드된 드라이버 메모리를 잘 살펴보면, 또 하나의 PE 파일이 붙어있는 것을 볼수 있다. 눈으로 확인 가능한 것은 암호화된 내용이 메모리에는 복호화 되어 올라가기 때문이다. ( 커널에서 로드시에 이미 해당 루틴들을 다 수행한 상태이기 때문 )

빨간색으로 표시해둔 부분이 주요 코드 부분이다.

 복호화에 필요한 로컬 변수들을 초기화 하고, 구하는 루틴들을 포함하고 있으며, EP부터 조금 아래 부분을 살펴보면 똑같은 함수를 호출하는 부분을 볼 수 있다.
 바로 그 두번의 호출이 복호화 루틴인 것이다.

 복호화 로직은 아주 간단하며, 어셈을 조금만 공부하면 간단하게 풀수있는 로직이다.

 복호화는 두번의 호출로 정상 driver와 악성 driver를 복호화 하며, 특히 ndis.sys가 변조된 파일의 악성 driver는 IoCallDriver를 Hook하는 루틴을 포함하고 있다. 이는 안티바이러스 제품들의 접근을 회피하기 위한 방법으로 사용된다. 
 AntiVirus2010 에 의해서 변조되는 ntfs.sys 와 agp440.sys 는 IoCallDriver Hook 루틴이 없으며, 일반적인 로직으로 접근 및 원복이 가능하다.

 일반적인 Winapi로 파일을 접근할 시엔 감염된 상태를 정상적인 상태로 보여주면서 진단을 회피하게 된다.
  
 [그림7] 변조된 드라이버파일의 코드
 

  // 분명히 스킨부분의 소스를 고쳐서 글자색을 검은색으로 했는데,, 언제부턴가 회색으로...@.@
      다시 다 검은색으로 바꾸는 엄청난 작업을... 
      Tistory 어렵네요... 괜찬은 팁이 있으신 분은 알려주세요~! ㅠ

Exe32Pack 1.4x

Exe32Pack 1.4x (Unpacking).rar

해당 html문서를 보면 이미지와 내용으로 어느정도 알수 있다.

처음 ep부분에서 esp레지스터 값을 하드웨어 브레이크 포인트로 엑세스에 dword값으로 4바이트를 설정한 후 f9를 누르면 jmp eax 값이 뜬다. 해당 eax가면 oep가 되는것이다. 

이그림은 처음 올리디버거에 올라왔을때 ep 부분이며, 해당 esp값을 보면 0012ffc4로 되어있다. 해당 주소를 hex값으로 위에말한대로 bp를 걸고 f9로 진행한다

진행하다보면 최종적으로 JMP EAX값으로 뛰는 코드부분이 존재하며, 결국 해당 언팩된 OEP로 주소이동을 하게된다. 

(원래 문서나 다른팩에서는 바로 나오는데 여기선 f9 두번에 f8 3번정도 진행했더니 oep값이 나왔다 즉 바로 안나온다고 당황하지말고 좀더 코드를 따라가보면 된다)

이팩은 옛날거라 쉽다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

http://sandsprite.com/CodeStuff/scdbg_manual/MANUAL_EN.html

쉘코드 분석 툴

PDF에서 JS 코드 쉘 실행코드 부분인것같은데 이걸로 쉽게 분석했따고 하니....좋은것같군요 기능도 많고 

VS_LIBEMU-master.zip