2014.12.30 23:44

분석 돌려놨는데 심심해서 또 씀.

자가보호기능 위주로 씀.

 

기본적으로 치트엔진 등을 탐지하는 루틴엔 별다른 보호기능이 없다. 수정하기도쉽고 VM이 걸려있지도 않음.

리턴값만 슥- 해주면 신경쓸게 없는 정도.

 

헌데 자기 자신을 리버싱하려는 시도엔 매우 민감하게 대응해놨음.

 

1. CRC

스스로 중요한 함수 부분이나 모듈 전체에 대한 체크섬을 뜨고 여기저기에서 실행하고 여기저기에다 저장하고, 일부는 서버로 보낸다.

이걸 다 우회하려고 한다면 아마 20개 가까운 CRC를 속여야 할 거다.

일부는 VM안에서 실행되거나 더미다 VM 핸들러를 보호하는 CRC인 경우도 있고, 시간차 공격 CRC, 서버사이드 CRC도 있다.

솔직한 감상으로, 이 부분은 어느정도의 정신병을 각오하고 분석하길 바람.

2. ehsvc.dll의 리버싱 시도가 탐지 됐을때의 대처

모올래 메모리 어딘가에 감지됐다는 플래그를 셋팅(모든 코드는 vm안에서 실행됨)

그 후 vm 내부에서 프로세스 강제종료 시도나 서버에서 요청이 오면 "나 해킹당했어요"하고 대답하는 상태가 된다.

CRC만 아니면 이부분만 조져도 된다. 헌데 쉽진 않을거임. 다 vm이거든 ㅋ

3. 디버그레지스터, 디버거, vm 체크 등

기본적이면서 강력한 방식 위주로 구성돼있음

디버그레지스터 부분은, 조금만 더 신경썼으면 뚫기 상당히 까다로웠을 텐데, 라는 생각이 든다.

그거이외엔 본인 실력에 달렸다.

몇가지는 VM 안에서도 call된다. 그것만 주의하면 끝.

안티덤프나 안티디버깅 등의 기능은 더미다에 크게 의존하는 경향이 있다. 더미다는 런타임에서는 알기만 하면 의외로 쉽게 무력화가 되기 때문에, 경험에 달렸다.

최신버전은 좀 짜증난다.

4. 모니터링 서버로 정보 전달

해킹 시도가 감지되면 입력된 아이디를 모니터링 서버로 전송하는 것 같은데, 매우 무섭다. 이러지 말자.

 

 

다음 글은 슈도 kernel32.dll을 이용한 api 후킹 방어 기능에 대해서 중점적으로 설명해볼 생각

매우 씽크빅하면서도 강력하기에, 포스트 하나를 꽉 채울 정도의 가치를 하는 기능임!

Posted by 라이에