LineageM bot(macro) reverse engineering

 


<Fig1. LineageM>

 


하루 60억원 매출 리니지M

 

엔씨소프트의 핵심 캐시 카우 역할을 하던 PC버전 리니지가 모바일버전으로 개발되었다.
2017년 6월 리니지M 출시하여 100일 이지나 매출 6000억 돌파 라는 엄청난 기록을 새운다.

계정 도용 등의 해킹 사건이 일어났었지만 서버 해킹이 아닌 서드파티를 통한 해킹으로 알려져 있다.
2차인증 기기등록으로 정해진 기기에서만 플레이할 수 있게 조치하였다.
따라서 연동된 계정을 해킹한다 하여도 기기등록을 해제해야 접속 할 수 있다.

  

<Fig2. 기기등록>


모바일 게임 답게 자동사냥(이하 자사)기능을 게임내 자체적으로 기능을 구현하여 알아서 몬스터 처치, 버프, 물약마시기 등등을 한다. 

그래서 사냥터까지 플레이어가 이동시키고 자사 켜두고 딴 일 보는 게임이 되어 버렸다. (다마고찌)

 

<Fig3.게임화면>

 

일반적인 한국형 모바일게임은 에뮬레이터를 통해 플레이하는 것을 막으려고 하는데 리니지M은 열어놨다.
 
왜 안했는지 이제 알 것 같다. 이걸 만약 핸드폰으로 했으면 채굴하러 끌려간 그래픽카드 꼴이다..

리니지m 안한 중고폰 사요!

 

 

어쨌든 PC 리니지도 레벨업이 엄청나게 힘들었지만 리니지M도 마찬가지다.
아인사하드 없으면 레벨업 못한다.  매일 똑같은 하이네잡밭에 캐릭터를 갔다 놓으면 뭔가 의무적으며........채굴하는 느낌이다.
 
어느정도 하다 보면 사냥터까지 보내는 것도 귀찮아지며, 물약 사는 것도 엄청나게 귀찮아진다.

 

<Fig4. 매크로>

 

 

게임 봇인 유니크 매크로라는 프로그램이다. 리니지M 매크로 중 엄청나게 많은 기능들을 지원하며 업데이트를 매 패치 마다 해준다.

자동육성 기능이 있어 좋은 변신이 나올때까지 변신뽑기까지만 하고 버리고 하는 작업장이 생겨 결국 NC에선 50레벨 미만은 뽑기를 막아놨다.

로그기반 봇탐지를 회피하기 위해 각 액션 마다 랜덤성을 부여하는 기능도 제공한다고 한다...ㅎㄷㄷ

 

 

<Fig5. 작업장>

 

에뮬레이터를 막지 않아 다중 계정으로 일반 PC에서 최소 4개이상은 돌아가니 집에서도 작업장을 운영할 수 있다 !

 

 

<Fig6. 중국인 작업장>

 

매크로 프로그램이다 LineageM.exe로 프로그램을 실행하여 동작한다.

라이브러리를 자세히 보면 OpenCV가 있다.

 

 

<Fig7. 매크로>


OpenCV(Open Source Computer Vision)은 오픈 소스 컴퓨터 비전 라이브러리이며 인텔이 개발하다 손 뗀 상태다.
패턴인식, 기계학습등에 많이 쓰인다.  게임 봇에 적용하려고 만든게 아님

사물인식, 물체 인식등 이미지 처리 대부분 opencv 써서 개발한다.


 

 <Fig8. OpenCV>

 

opencv로 매크로를 만드는 정성이면 다른걸 만드셔도 잘 만드실 같다.

무료 테스트 기간이 끝나 월 단위로 판다. 1개 12000원 부터 시작해서 100개는 70만원 정도에 팔고 있다.

블로그는 갓카오님께서 폐쇄조치 하여 접속 할 수 없고, 추적 안 당하시려고 텔레그램을 통해 연락해서 계정 등록을 해야 한다.

 

<Fig9. 판매중인 매크로>

 

다 C#으로 개발되어 있어서 분석하기 편하다.

C#은 dnSpy를 따라올 도구가 없다.

https://github.com/0xd4d/dnSpy

 

<Fig10. dnSpy>

 

C#이라 얼마 안 걸릴 줄 알았는데 봇 개발자는 분석 당하지 않으려고 난독화를 적용하셨다....

난독화 적용되어 있을 때는 dnSpy로는 수정할 수 없다....

수정하려면 별 수 없이 assem으로 짜야한다.

결국 +ida로 분석했다

 

<Fig11. 수정불가>

 

보통 매크로 같은 경우 해당 프로세서가 마우스 이벤트를 사용하여 control 한다. 매크로를 돌린 상태에서 컴퓨터를 할 수 없다는 이야기이다. 반면 유니크 매크로는 에뮬레이터에 dll inecjtion 하여 메모리상에서 control 한다.

따라서 프로세스 갯 수 만큼 개별적으로 컨트롤 할 수 있는 넘나 좋은 특징이 있다.

 

<Fig12. 구우조>

 

 

injection 된 dll은 Ucapture1.dll이다.

 

<Fig13. Process explorer>

 

후킹 모듈에 덕지덕지 보안 기능 붙여 놓으면 엄청난 cpu 점유율을 볼 수 있다.

예민한 후킹 모듈이다 보니 packing 등은 적용하지 않았다.  

 

<Fig14. UCapture1.dll>

 

분석해보면 실시간 처리(?)로 초당 스크린샷 찍어 LineageM로 던져 opencv로 상태 확인한다.

 

<Fig15. 매크로 동작>

 

매크로 시작을 클릭하면 매크로 서버에서 현재 아이디가 기간만료인지 남은 기간이 있는지 확인한다.

기간만료 상태면 다음 팝업 창이 뜨며 진행이 되지 않는다.

 

<Fig16. 입금하세요>

 


매크로 서버와 매크로 프로그램은 평문 데이터 통신한다. 아이디와 패스워드가 노출되는 것을 확인할 수 있다.

재미있는 점은 매 실행 시 나머지는 고정이고 붉은 박스는 계속 변경된다.  킁킁 seed 냄새가 나쥬??

 

<Fig17. Network>

 

 

저 붉은 박스는 분석해보니 GetCurrentProcess 함수를 통해 Process ID를 받아오기 때문에 매번 실행 시 변경되는 것이었다.

 

<Fig18. Password>

 

IP주소와 MAC주소 하드디스크 시리얼정보와 매크로 프로세스 ID를 구한뒤 format string으로 IP | MAC | HDDSerial | PROCESSID 형태로 만들고 생성된 정보는 이후 매크로 명령시 암호화 key로 사용된다.

 

 

<Fig19. AES Decrypt 256>

 

 

서버에서 받아오는 데이터 중 <Request_AesResult> .. </Request_AesResult> 필드는 서버에서 인증된 사용자인지 확인 후 전송하는 action이다.

이 내용은 암호화 되어 있으며, AESDecrypt256 함수를 통해 복호화를 수행한다.


AESDecrypt256 함수의 첫번째 파라메터인 InputText가 <Request_AesResult> .. </Request_AesResult> 필드 내용이고 두번째 파라메터인 pw은 클라이언트에서 생성한 "IP | MAC | HDDSerial | PROCESSID" 이다.

이 pw을 통해 pbkdf1로 aes 256 의 key와 salt를 생성한다.

salt 값은 pw의 길이로 생성하는데 보통 pw가 10자리는 넘어 2byte정도 된다.

뭐 어차피 sha1(password+salt) 연산이기 때문에 2byte여도 큰 문제는 없다.


표준 rfc2898를 읽어보면 dkLen > 20,  Salt는 8byte로 명시되어 있다. 

일반적인 경우 데이터 길이가 더 적은 경우 padding을 붙이거나 에러를 출력한다.


C#의 참 독특한점은 PasswordDeriveBytes.GetBytes 로 pseudo 난수 바이트를 생성해준다.

pbkdf1의 return 값은 20byte인데 이 함수를 통해 32byte와 16byte 총 48byte를 생성해 줄 수 있다.


20bye까지는 pbkdf1 연산 결과이고 이후 pseudo 난수인데 어떻게 생성되는지 알아야 python 으로 porting할텐데 이걸 내가 구지 지금 알아야 할까 생각이 들고.. (의도한건가??) 결국 매크로를 수정해서 pw인 connect_info를 항상 고정으로 만들어 버렸다. ^^;;

 

 

<Fig20. 늘 18>

 

 

다시 정리하자면 매크로 서버에서 action은 클라이언트에서 받은 키로 암호화 하여 클라이언트한테 전송한다.


프로그램 실행 -> ( IP | MAC | HDDSerial | PROCESSID ) 정보 전송 -> 매크로 사용 요청 ->


-----------------server-side-------------------

message= action

pw = ( IP | MAC | HDDSerial | PROCESSID )

salt = len(pw)

key,iv =pbkdf1(pw,salt)

ecn= aes.enc(message, key, iv)

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


enc값이 Request_AesResult이다. 클라이언트한테 전송한다.

 

------------------client-side-----------------

message = Request_AesResult 내용

pw = ( IP | MAC | HDDSerial | PROCESSID )

salt = len(pw)

key,iv =pbkdf1(pw,salt)

action = aes.dec(message, key, iv)

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


서버에서 받은 action으로 매크로 기능을 수행한다.

action 값으로 분기를 수행하는 매커니즘이기 때문에 action 값이 중요한 열쇠가 된다.



<Fig21. action 처리 루틴>


우리는 action값을 모른다. 알아내려면 분석량 * action 으로 증가 될 뿐 ㅠ

이걸 crack 하기 위해서 매크로 프로그램 변조를 통해 매 key가 고정으로 생성되게 만든뒤 action값을 적절한 게-씡(유추)하여 암호문을 생성해 요청 시 전달하면 아마....되겠지?


# -*- coding: UTF-8 -*-
from Crypto.Cipher import AES
from Crypto.Hash import SHA as SHA1, HMAC
import base64
import struct
import binascii
import StringIO

def pkcs7encode(text):
        l = len(text)
        output = StringIO.StringIO()
        val = 16 - (l % 16)
        for _ in xrange(val):
            output.write('%02x' % val)
        return text + binascii.unhexlify(output.getvalue())

def pkcs7decode(text):
        nl = len(text)
        val = int(binascii.hexlify(text[-1]), 16)
        if val > 16:
            raise ValueError('Input is not padded or padding is corrupt')
        l = nl - val
        return text[:l]

def encrypt(message, key , iv):
    aes = AES.new(key, AES.MODE_CBC, iv)
    return base64.b64encode(aes.encrypt(pkcs7encode(message.encode("utf-16")[2:])))

def decrypt(encrypted, key , iv):
    aes = AES.new(key, AES.MODE_CBC, iv)
    return pkcs7decode(aes.decrypt(base64.b64decode(encrypted))).decode("utf-16")

def PBKDF1(password, salt, dkLen, count=100):
    pHash = SHA1.new(password+salt)
    digest = pHash.digest_size 
    for i in xrange(count-1):
        pHash = pHash.new(pHash.digest())
    return pHash.digest()


#pw 18|18|18|18
key  = "\xAB\x80\xEE\xCD\x8A\xDF\x30\xAC\x64\x45\x17\x73\xE3\xB0\x55\xD6"
key += "\xC1\x06\x9D\xA8\x35\x60\x3C\x3D\xE3\x34\x52\xA5\x15\x51\x7B\xF3"
iv   = "\x64\x45\x17\x73\xE3\xB0\x55\xD6\x5B\x4E\x87\xD6\x68\xCA\xFB\x10"

text = "게싱실화냐"
enc =  encrypt(text, key , iv)
print enc
dec =  decrypt(enc, key , iv)
print dec

 


 

 

 

다행히 훌륭한 게-씡(유추)으로 성공했다.


 

<Fig22. 매크로>

 

잘돌아간다.

 


1줄 요약. 게임 매크로도 키 생성까지하면서 사용자 인증한다.



<Fig23. 열일하는 NC....봇탐지 회피는 개뿔.....잘가요>

저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 1


RX480 써멀 재도포 이후 팬을 컨트롤하는 놈이 궁금해졌다. 


어떠한 원리로 컨트롤 하는지 알고 싶기 떄문에 RX480을 분석하기로 한다.




<Fig1. Fan Pinout>


RX480의 쿨러는 4PIN을 사용하고 있다. 그림 1과 같이


검은색 = GND

노란색 = +12V

녹색 = Senser

파란색 = Control


으로 구성되어 있다.



<Fig2. signal>


로직 애널라이저로 Sensor pin을 확인하면 Pulse-width modulation (PWM)로 구성되어 있는 것을 확인할 수 있다.


참고 자료 : https://en.wikipedia.org/wiki/Pulse-width_modulation


보드에서 FAN의 속도를 조절하기위해 FAN 전압을 GPU에 sending 한뒤 GPU쿨러의 센서가 현재의 RPM을 response하여 온도관리 한다.

따라서 쿨러의 현재 RPM을 전송하지 못하여도 메인보드에선 전압을 통해 FAN을 제어 하여 지속적으로 전압을 전송하기 때문에 온도 조절이 되지 않아 GPU 가 타는 불상사가 일어날 수 있다.

그렇기 때문에, GPU가 특정 온도 이상 올라가면 자동으로 GPU의 전원을 차단하는데 이는 하드웨어적으로 구현하기에는 상당히 무리가 있어 분명 어딘가에 저장할 것이라고 판단하였다 . 제일 의심 가는 부분은 바로 BIOS다.



<Fig3. BIOS Version>



TechPowerUP 도구를 사용하여 RX480의 바이오스를 추출할 수 있다. 물론 플래싱 까지 가능하다.



<Fig4. BIOS Extract>


해당 바이오스 펌웨어는 당연히 Binwalk에서도 아무것도 할 수 없다.


삽질을 통해 분석한 결과...



<Fig5. BIOS Analysis>


해당 구조로 구성되어 있는 것을 확인할 수 있다.

조금 설명하자면 Little Endian으로 기록되어 있으며, 처음에는 AMD Magic signature로 추정되는 0x55AA가 기록되어 있으며 (linux kernel AMD gpu driver 참고함) 현재의 총 블럭 개수가 기록되어 있다. 이후 식별된 데이터는 Block의 크기가 기록되어 있어 해당 영역은 0x73 * 0x200 = 0xE600 만큼 크기인것을 확인할 수 있다. 이후 확인한 CheckSum이였으며,  계산 원리는 간단하다. 0번지 offset부터 사이즈 만큼 모든 byte를 더한 값이 CheckSum 데이터이다.


또한 온도 기록방식도 특이하였다. 최대 온도를 예를 들어 0x2134 이며 계산 식은 0x2134  / 0x64 = 0x55 (85) 인것을 확인할 수 있다.


RX480의 바이오스는 무결성 확인이 없기 때문에 아무나 수정해서 올릴 수 있다. 따라서 최대 온도와 RPM 온도 등의 설정정보를 범위 이상으로 놓으면 (?).....


온도 관련된 정보들은 어느정도 찾았으니 나머지는 여러분이 분석해보길 바란다.




<Fig6. cool!>


바이오스 수정해서 올리지 마세요. 벽돌 될 수 있습니다. 전 못고치며 모든 책임은 당신에게 있습니다.


import struct

rom_checksum = 0x21
venderid = 0x238
subid = 0x23A
deviceid = 0x24A
subvendorid = 0x238
min_temp = 0x9ED8
med_temp = 0x9EDA
high_temp = 0x9EDC
max_temp = 0x9EE4
max_RPM = 0x9EEB 
max_gpufreq = 0x9C59
max_memory_freq = 0x9C5D
power_control_limit = 0x9C61
shutdown_temp = 0x9F1D 
max_temp_power = 0x9F17

print "################################"
print "# RX480 Bios Analysis v0.01    #"
print "#                              #"
print "#             hacked by koha   #" 
print "################################\n"

f=open("bios.rom","rb")
databuffer = f.read()
f.close()

checksum = struct.unpack("B",databuffer[rom_checksum])[0]
size = struct.unpack("B",databuffer[0x02])[0] * 0x200

check=0
for i in range(size):
    check += struct.unpack("B",databuffer[i])[0]
check = checksum - (check % 0x100)
if checksum == check:
    print "Checksum ok\n"

print "vendor ID : " + databuffer[venderid:venderid+2].encode('hex')
print "Sub ID : " + databuffer[subid:subid+2].encode('hex')
print "device ID : " + databuffer[deviceid:deviceid+2].encode('hex')
print "subvendor ID : " + databuffer[subvendorid:subvendorid+2].encode('hex')+"\n"




저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 0


14나노 핀펫 공정으로 만든 RX480은 래퍼런스 제품이 30만원 밖에(?) 안하는 가격으로 가성비 괜찮은 제품 중 하나인데.... 발열량이 상당하다. 따라서 14,000원만 투자하여 써멀 구리스 재도포를 통해 온도를 낮춰보려고 한다.



<Fig1. RX480>


그래픽 카드 기준으로 옆면 각각 3개의 나사를 제거하면 블로워팬 뚜껑을 딸 수 있다.


<Fig2. rx480 heat sink>


뚜껑 따면 은색의 싸구려 히트싱크를 볼 수 있다.


히트싱크를 분리하려면 보드 뒤편에 있는 브라켓을 분리해야 하는데 이 브라켓을 고정하는 피스 중 하나에 AMD 워런티 씰이 존재한다. 얘 없어지면 3년 무상 a/s 사라진다...


워런티 씰 우회는 드라이기 신공 등 여러 신공이 있지만


<Fig3. warranty seal stickers>


브라켓에서 4개 중 씰 없는 나사 3개 분리 이후 그림4 와 같이 빙빙 돌리면 워런티 씰 보존 상태에서 브라켓 분리가 가능하다. (취.약.점) 당연히 역순으로 조립할 수 있다.


<Fig4. warranty seal stickers >


히트팬 분리하면 기존에 발라져 있던 써멀의 흔적을 볼 수 있다. 말끔히 제거하자.


<Fig5. rrreeemmooovvee>


ARCTIC MX-4 thermal compond (Thermal Conductivity: 8.5 W/mK) 출동!!


<Fig6. MX-4>


GPU 중간에 1자로 도포 한뒤 역 조립한다.



<Fig7. 111111>


동일 환경에서  3d mark fire strike 2번 테스트 한 결과다. fire strike(이하 파스) 보는거 정말 지겹다.


일반 상태에서 재부팅 이후 파스 테스트 시 최소 44도 ~ 최대 90도


<Fig8. Normal>


서멀 교체 이후 파스 테스트 시 최소 39도 ~ 최대 84도


<Fig9. Replace thermal compound>


온도는 내려갔으나 fan speed가 요동을 친다... 음..??


사실상 DIY 종결판 RX480...;;;

저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 0

티몬에서 UHD TV를 싸게 팔고 있어 해피머니 10만원당 93000원에 구매해서 티몬 캐쉬 30만원 충전한뒤 구입하니 더 싸졌다 +_+ 




<Fig1. 득템>



어쨋든 이놈은 태생이 TV인지라 기본으로 Sharp filter가 적용되어 있기 때문에 모니터로 쓰기엔 가독성이 너무 떨어진다. 


구글링을 통해 유출인지 찾은건진 모르겠지만 어떤 능력자가 관리자 모드 (팩토리 모드)를 공개줬다.  


(리모콘에서 메뉴 -> 1147 입력)


<Fig2. 팩토리 모드>




팩토리 모드에서 Sharp filter를 끌 수 있지만 재부팅하면 다시 초기화되는 치명적(?) 약점을 가져 아예 펌웨어 분석한 뒤 디폴트로 Sharp를 없애려고 분석을 시작했다.





<Fig3. 왜 찾질 못하니>



펌웨어 파일은 4메가 정도 되며 펌웨어 구조 분석한 문서가 아무것도 없다. 


또한 binwalk에도 만 가득 출력되서 직접..펌웨어 포맷을 분석하는 방법 밖에 없다....




처음으로 UHD를 샀고.......a/s도 2년 짜리라.........감히 Teardown을 못하겠다......UART를 찾아야 빠른데...... 안돼! a/s받아야돼!!


맨땅에 해딩 ㄱㄱㄱ



<Fig4. UHD로 디아 하면 짱임>



0x22080 부터 file 구조체가 있는 것을 확인할 수 있다. 4byte ADDR, 4byte SIZE, 3byte Type 순으로 기록되어 있는 것을 확인할 수 있다.


<Fig5. Zepa firmware file structure>


구조 파악했으니 얼릉 분리하고 분석 해봐야징 ^^*



<Fig6. Zepa firmware extract>


fig7는 분해된 데이터이며 ZEPA TV 있는 사람이라면 부팅 시 나오는 로고인  DIGITAL LED TV가 00308d10.jpg 파일로 존재하는 것을 확인할 수 있다.


<Fig7. files>



식별 할 수 있는 파일들은 확장자로 구분했다.


해당 TV의 OS는 embedded Linux이며 모든 관리는 커널에서 관리한다.


분석해보니 HDMI 2.0 쓰면 TV에서 알아서 그래픽 모드로 진입해서 SHARP 기능을 끄는 루틴이였다;; 


이후 GTX 970 사서 껴보니 Sharp filter가 자동으로 꺼졌다! ㅎ...........


더 상세한 내용은 저작권(?) 문제가 될 수 있으니, 자세한건 여러분이 분석하세요. 


펌웨어 수정해서 올리지 마세요. 벽돌 될 수 있습니다. 전 못고치며 모든 책임은 당신에게 있습니다.


얘는 크로마 서브샘플링(Chroma subsampling)을 지원하니 출력색은 ycbcr444으로 하세용^^*


import struct

print "##############################################"
print "#           Zepa Firmware Extractor v0.01    #"
print "#                                            #"
print "#             hacked by koha  #"
print "##############################################\n"

f=open("MSD3458_8M.bin","rb")

f.seek(0x22090)
addrl=[]
sizel=[]
for i in range(20):
    addr = f.read(4)
    addrl.append(addr)
    size = f.read(4)
    sizel.append(size)
    unknown = f.read(3)
    print str(i)+" : "+addr.encode('hex') +  " "+size.encode('hex')

for i in range(len(addrl)):
    addr = struct.unpack('>l',addrl[i])[0]
    size = struct.unpack('>l',sizel[i])[0]
    f.seek(addr)
    data = f.read(size)
    fname =  addrl[i].encode('hex')+".bin"
    if data[0] == "\x5D":
        fname =  addrl[i].encode('hex')+".lzma"
    if data[:3] == "\xff\xd8":
        fname =  addrl[i].encode('hex')+".jpg"
    open(fname,"wb").write(data)


저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 0



<Fig1. 보도자료>



2014년 11월 24일에 소니 픽쳐스 엔터테인먼트 공격에 쓰였던 샘플 2종을 분석한 경험이 있는데 기사 본문에서 나오는 코드는 전혀 보지 못했던 코드다....


파일 정보 : https://virustotal.com/ko/file/E2ECEC43DA974DB02F624ECADC94BAF1D21FD1A5C4990C15863BB9929F781A0A/analysis/


파일 정보 : https://virustotal.com/ko/file/4D4B17DDBCF4CE397F76CF0A2E230C9D513B23065F746A5EE2DE74F447BE39B9/analysis/


sony malware 분석 내용 : http://kkoha.tistory.com/entry/sony-malware-analysis


2014년 11월 소니픽처스 공격과 2015년 12월 발생한 베트남 은행 공격, 그리고 올해 2월 발생한 방글라데시 중앙은행 공격에서 사용된 악성코드의 비교 결과 파일삭제 기능의 함수 코드 진행 부분이 매우 유사하다는 것이다. 그러나 이번 해킹사건이 북한의 소행이라고 단정 짓기는 어렵다는 게 이슈메이커스랩 측의 설명이다. 


기사 내용 : http://www.boannews.com/media/view.asp?idx=50617



이런 내용을 공유할 때는 hash 라도 좀 달아주면 좋겠다. 이슈메이커즈랩에서 분석 했다는 소니 악성코드가 변종일 수 있겠지만 FBI 수사 결과 발표에 공유된 놈과는 다르다.



<Fig2. sony>


sony 건의 특이점은 3번의 MBR wipe 기능과 파일 삭제 시 windows, program files 폴더는 예외 처리한뒤 exe파일과 dll파일이 아닌 파일만 WriteFile 함수를 통해 파일 크기만큼 가비 데이터로 덮어쓴 뒤 DeleteFileW 을 사용하여 삭제 하였다.




<Fig3. BBSWIFT>


기사에 나온 파일 정보 : https://virustotal.com/ko/file/AE086350239380F56470C19D6A200F7D251C7422C7BC5CE74730EE8BAB8E6283/analysis/


Bangladesh Bank’s (BB) SWIFT payment system 건 같은 경우 파일 경로명을 인자값으로 받아 해당 경로에 있는 파일을 WriteFile 함수를 통해 파일 크기만큼 0x00 데이터로 덮어쓴다.  

이후 rand 함수로 파일이름을 생성한뒤 (ex c:\1.txt -> c:\qhrsh) 

파일명을 삭제하기 위해 MoveFileA 함수로 파일명 변경 뒤 DeleteFileA 함수로 삭제한다.



구성도 및 분석 내용은 이미 baesystem에서 잘 분석되어 있어서 참고 바람.

전문 http://baesystemsai.blogspot.kr/2016/04/two-bytes-to-951m.html

저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 0



The MIX transformation of RC2; four of these comprise a MIXING round


General

Designers      : Ron Rivest

First published : leaked in 1996, designed in 1987


Cipher detail

Key sizes      : 8–1024 bits, in steps of 8 bits; default 64 bits

Block sizes     : 64 bits

Structure        : Source-heavy unbalanced Feistel network

Rounds          : 16 of type MIXING, 2 of type MASHING



This module implements the RC2 (Rivest's Cipher version 2) encryption algorithm in pure python, specified in RFC 2268.


ECB and CBC modes are supported.


Original source code : https://github.com/0xEBFE/RC2-python/blob/master/rc2.py


Backporting Python 3 Code to Python 2.7.x by koha <kkoha@msn.com>


Quick start


Install from PyPIhttps://pip.pypa.io/en/latest/installing.html


pip install rc2


Example RC2 usage


from rc2 import *

#RC2 ECB encryption.
plaintext = "hello_word_ECB"
key = "test key"

rc2 = RC2(key)
encrypted = rc2.encrypt(plaintext,MODE_ECB)
print encrypted.encode('hex')

#RC2 ECB decryption.
rc2 = RC2(key)
decrypted = rc2.decrypt(encrypted,MODE_ECB)
print decrypted

#RC2 CBC encryption.
plaintext = "hello_word_CBC"
key = "test key"
iv = "\x01\x02\x03\x04\x05\x06\x07\x08"

rc2 = RC2(key)
encrypted = rc2.encrypt(plaintext,MODE_CBC,iv,PADDING_PKCS5)
print encrypted.encode('hex')

#RC2 CBC decryption.
rc2 = RC2(key)
decrypted = rc2.decrypt(encrypted,MODE_CBC,iv,PADDING_PKCS5)
print decrypted


https://pypi.python.org/pypi/rc2

저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 0


온라인 AOS 게임 부정행위 탐지 연구 : 리그 오브 레전드를 중심으로


Research on detect abusing play in AOS game - Focused on League of Legends


AOS 게임은 장르 특성 상 게임 머니가 플레이에 미치는 영향이 적으며, 유저 계정의 랭크 등급이 보다 높은 가치를 가진다. 즉, AOS 게임에서 나타나는 부정행위는 랭크 등급과 연관성을 가지며 자동 레벨 업 BOT이나 대리 랭크 플레이의 형태로 발생한다. 본 논문에서는 BOT과 대리 랭크 플레이의 현황과 특징에 대하여 살펴본 후, 유저의 게임 로그 분석을 통해 부정행위를 탐지하는 방법에 대하여 논할 것이다.



ABSTRACT

In AOS game, rank of user’s game account is much more significant than game money is. As ar result, cheating in AOS game is typically auto level-up BOT or rank abusing.  In this study, we will analyze current states and possible traits of auto level-up BOT or rank abusing and suggest methods to detect those cheating using analysis of user’s game log. 



1. 서론


AOS 게임은 다수의 플레이어가 팀을 이루어 각 플레이어가 하나의 챔피언을 선택하여 상대방의 기지를 파괴하는 것을 최종적인 목적으로 하는 게임이다.

League of Legends(이하 ‘LOL’)은 세계적으로 최다 접속자수를 보유한 AOS 게임이다. LOL에서 유저에게 경쟁을 유발하는 요소는 랭크 등급으로 유저의 실력을 가늠할 수 있도록 하는 요소이다. 아이템의 현금화가 불가능한 LOL의 특성상 게임상 부정행위의 대다수는 랭크 등급과 관련되어 발생한다.

본 논문에서는 랭크 등급과 관련한 부정행위를 예비 단계인 ‘BOT’과 착수 단계인 ‘대리 랭크’로 구분하고 Riot API를 통해 얻은 LOL의 게임 로그 정보를 분석하여 각각의 행위를 탐지하는 방법에 대하여 기술할 것이다.



2. LOL에서 발생하는 부정행위


2.1 LOL의 Rating System의 이해


LOL에서 발생하는 부정행위를 이해하기 위해서 우선적으로 LOL의 랭크 등급을 산정하는 Rating System을 살펴볼 필요가 있다.

LOL의 유저는 게임 플레이를 통해 경험치를 얻고, 유저 계정의 레벨 올리게 된다. 유저는 레벨이 30에 도달한 순간부터 랭크 게임에 참여할 수 있는 자격을 얻게 된다. 최초로 랭크에 참여하게 되는 유저는 등급이 없는 상태로 10번의 랭크 게임을 진행하여 그 게임 결과를 토대로 자신의 랭크를 부여받게 된다.

LOL의 랭크는 Bronze, Silver, Gold, Platinum, Diamond, Master, Challenger 총 7가지 단계로 구분되며 각 랭크가 차지하는 백분위는 [표-1]과 같다.


RANK

Percentile

Bronze

68% 이하

Silver

30% 이하

Gold

11% 이하

Platinum

2.3% 이하

Diamond

0.04% 이하

Master

0.0088% 이하

Challenger

0.0% 이하


[표 1 -  LOL Rating Percentile] 


랭크 등급은 다시 5단계의 하위 등급으로 구분되어 각 Rank별로 1~5등급으로 나뉘게 된다. 랭크 게임의 승패에 따라 유저는 LP(Rank Point)를 얻으며, LP가 100에 도달하면 승급전(3판 2승)자격을 얻게 된다. Bronze-2에 배치된 유저가 Silver-5로 승급하기 위해서는 LP 100을 채운 후 승급전에 성공하여 Bronze-1로 승급한 후 다시 LP 100을 채워 승급전에 성공하여야 한다.


랭크 등급이 유저에게 강한 유인을 발생시키는 원인은 사회학적으로 랭크가 가지는 사회적 지위와 연관되어 있다. Riot은 매 시즌이 끝날 때마다 유저에게 보상을 제공하는데, 이는 다른 유저에게 자신이 지난 시즌에 어떤 랭크에 속했다는 것을 자랑하는 수단이 된다. 즉, 랭크는 게임과 실제 사회 모두에서 유저의 지위를 표창하는 수단으로 작용하는 특성을 가지고 있다.


LOL은 5인 팀플레이라는 게임 특성에 따라 다른 팀원의 실력이나 트롤링 유무가 승패를 좌우하는 경향이 높아 특정 랭크에서 자신의 실력에 해당하는 랭크로 승급하지 못하고 정체되는 구간이 존재한다. 특히 트롤링 유저 비율이 높은 Bronze 구간에서 정체 경향이 강하며, 승리 확률이 50%에 근접한 경우 랭크 상승은 자명하게 불가능하므로 유저의 입장에서는 다음과 같은 선택에 이르게 된다.


첫째로, 새로운 계정을 다시 키워 랭크 게임을 시작하는 방법이다. 60% 이하의 승률을 가진 Bronze 유저의 경우 새로운 계정을 만드는 것이 더 이익일 수 있다.


둘째로, 실력이 뛰어난 타인에게 랭크 게임을 대리 수행하게 하며 계정의 랭크를 상승시키는 방법이다. 금전 거래 형식으로 발생하며, 주로 준 프로게이머들이 대리 랭크 작업에 참여한다.


2.2 LOL의 BOT


앞 절에서 기술한 새로운 계정을 만드는 방법에는 ‘시간’이라는 요소가 비용으로 작용한다. 매 게임을 승리할 경우 유저는 평균적으로 140정도의 경험치를 얻으며 30레벨에 도달하기 위해서는 40000의 경험치가 필요하다. 패배 시의 경험치는 승리시의 절반수준이며, 평균 플레이 시간이 30분 정도인 것을 감안할 때 약 190시간이 소요되어. 하루 3시간을 투자할 경우 2달가량이 필요하다.

BOT은 이러한 과정을 자동화하기 위하여 등장하였다. 




[그림 1 - BOT 클라이언트의 게임 화면] 


[그림 1]과 같이 BOT은 특정한 경로만을 움직이며 사전에 정의된 이벤트에 의해서만 반응하도록 설계되었다. 




[그림 2 - BOT 의심 계정의 게임 로그]


즉, 일반 유저 게임에서 발생하는 예측 불가능한 상황에 대응하지 못하여 [그림 2]의 게임 로그에 나타나는 바와 같이 AI대전만을 플레이하며, 선택 챔피언의 동일성, 장시간의 플레이 같은 사람의 플레이와 구별되는 특징을 가진다.



2.3 LOL의 대리 랭크


LOL의 대리 랭크는 상위 0.1%의 실력에 해당하는 준 프로게이머 급 유저가 요금을 받고 요청받은 랭크에 도달할 때까지 플레이를 대신하는 형태로 진행된다.

플레이어의 랭크 실력을 나타내는 또 다른 요소는 MMR(Match Making Rating)이다. MMR은 상대편을 고르는 기준으로, 게임에서 연승할 경우 급격히 증가한다. MMR에 따라 승리 보상이 지속적으로 증가해, 높은 실력의 유저는 빨리 상위 랭크로 진급하게 되며 요행으로 유저가 연승을 하는 경우를 방지하게 된다.

Master와 Challenger 등급에 속하는 대리 유저는 2000 이상의 MMR을 보유하고 있어 MMR 상승이 승패에 영향을 거의 미치지 않는 플레이 성향을 보인다.





[그림 3  대리 유저의 랭크 게임 로그] 


[그림 3]은 실제 대리 랭크 사이트에서 작업을 의뢰한 계정의 게임 로그이다. 좌측하단에서 상단으로 정렬한 로그를 살펴보면 MMR이 지속적으로 상승함에도 연승 추세가 강하게 보이는 것을 알 수 있다.


대리 랭크에서 나타나는 또 하나의 특징은 듀오 플레이다. 랭크 게임은 유저의 친구와 함께 2인의 파티를 구성하여 플레이 할 수 있으며 이 경우에는 MMR이 더 높은 상대를 만나게 되는 패널티를 받게 된다. 그러나 전술한 것과 같이 MMR이 2000이상인 대리 유저에게는 패널티에 비하여 자신과 비슷한 실력의 유저와 함께 2개의 계정의 대리 랭크를 플레이하는 것이 더욱 효율적이다.


또한 계정의 실제 유저와 대리 랭크 플레이어는 플레이 챔피언에 있어서도 다른 양상을 보인다. 랭크 게임의 목적 자체가 승리에 있으므로 플레이어는 자신에게 익숙한 챔피언을 선택하여 게임을 진행하는 것이 자명하다. 자신의 선호와 관계없는 새로운 챔피언을 통해 연승을 만들어내었다면 그러한 선호를 지속적으로 유지하는 것이 일반 유저에게는 정상적이다.


이를 종합하여 볼 때 대리 게임에서 나타나는 특징은 과도한 랭크 게임의 연승 구간, 파티 플레이의 존재, 연승 구간을 제외한 다른 구간과는 다른 챔피언 선호도로 선정할 수 있다.



3. 로그 수집


본 논문의 연구에서 사용한 로그는 다른 수단을 거치지 않고 오로지 Riot에서 제공하는 API만을 사용하여 수집하였다.


3.1 Riot API


LOL의 제작사인 Riot에서는 LOL의 게임 데이터를 개발자들이 사용할 수 있도록 API 형태로 제공하고 있다. API는 12개의 카테고리로 구성되어 있으며 세부 항목으로 제공되는 API에서 유저와 플레이된 게임에 대한 상세 정보를 얻을 수 있다. 


3.2 로그 수집의 한계


Riot에서 제공하는 로그를 통한 분석은 다음과 같은 한계를 가진다.


1. 유저의 계정과 플레이 게임은 각각 고유한 Ids값을 가진다. Ids값은 연속하지 않은 오름차순 형태로 완전 검색이 시간상 불가능하다.


2. 랭크 게임을 제외한 AI 게임에서는 플레이 유저에 대한 정보를 보존하지 않아 매칭이 불가능하다.


3. 유저가 플레이한 게임 리스트는 특정 개수를 넘기면 새로운 데이터로 갱신된다.


4. 하루에 발생하는 게임의 수가 100만 게임에 달하여 장기간의 데이터 축적이 불가능하다.


다음의 각 장에서는 ‘BOT’과 ‘대리 행위’에 대한 구체적인 데이터 수집 모델과 분석 방법 및 결과에 대하여 제시할 것이다.


4. BOT 탐지


4.1 Feature 선정


BOT 탐지를 위한 Feature는 다음과 같다.

1. 유저가 플레이한 최근 게임의 다수가 AI대전에 속한다.

2. 유저의 플레이 챔피언이 동일하게 반복되는 경향을 보인다.

3. 플레이 시간이 연속적인 경향이 강하다.


4.2 수집 및 분석 모델


본 논문에서는 6월 12일자에 생성된 ID를 기준으로 기준 ID보다 이전에 생성된 ID 176,457개에 대하여 분석을 수행하였다. 일반 게임과 달리 AI대전은 Riot에서 유저 식별 정보를 보존하지 않는 경우가 발생하여 사용자의 최근 게임 로그로 게임 로그를 대체하였다. 최근 게임은 10개 이하로 갱신되어, 정확한 로그 수집을 위해서는 실시간으로 대상 ID의 최근 게임 정보를 수집하여야 하였지만 현실적으로 불가능하여 본 논문에서는 분석 ID의 범위를 넓히는 방향을 선택하였다. 전체적인 흐름도는 [그림 4]와 같으며 상세 과정은 다음과 같다.



[그림 4  BOT 탐지 과정 흐름도]


수집 Clinet는 Riot API를 사용하여 UserIds 통해 계정의 존재 유무와 최근 게임 로그를 다운로드한다. 이후 로그에서 필요한 Feature만을 선별한 후 Profiler에게 전송한다.

Profiler는 전달받은 유저의 게임 로그의 Feature를 시간 순으로 분석 후 추정치를 계산하여 결과를 Result DB에 저장한다.


4.3 분석 알고리즘


전달된 데이터는 두 가지의 조건이 맞을 경우 추정치 계산 대상으로 선정된다.


첫 번째 조건은 계정의 레벨이 16이상 이라는 것이다. 낮은 레벨의 유저인 경우 게임에 대한 이해를 위해 AI대전을 반복하여 플레이하는 경우가 빈번하며 C1을 적용하지 않은 경우 10레벨 미만의 계정이 다수 탐지되어 BOT으로 확정할 수 없다.


두 번째 조건은 AI대전이 아닌 로그가 2개 이상인 계정은 제외시킬 것이다. 유저 당 확보 가능한 로그의 한계치가 10개이므로 이 중에서 2개 이상을 다른 모드로 플레이 한 경우 BOT으로 확정하는 것이 정확도가 떨어진다.

추정치 S를 얻기 위해서 다음과 같은 변수를 설정하였다.


챔피언 반복도(r) : 동일한 챔피언을 선택하는 경우 반복 정도 횟수에 따라 10%의 가중치를 거듭하여 곱한다.

시간 연속성(t) : 연속한 게임의 플레이 사이의 대기 시간이 허용된 오차범위(15분)일 경우 10%의 가중치를 거듭하여 더한다.





4.4 분석 결과 및 검증


수집된 176,457개의 ID에 대하여 위 알고리즘을 적용하여 상위 500등의 추정도를 가지는 계정 목록 확보하여, 해당 의심 계정들의 이후 플레이 형태를 실제 BOT의 플레이를 비교한 결과 [그림 5]와 같이 100개의 계정이 실제 BOT의 추정치와 유사한 값을 나타내었다.



[그림 5 - 상위 500위의 추정치 그래프]




[그림 6 - BOT 의심 유저의 게임 로그]


[그림 6]은 탐지된 유저 중 하나의 플레이 형태로 [그림 3]의 봇 계정과 유사한 로그를 가지고 있음을 확인하였다.



5. 대리 랭크 탐지


5.1 Feature 선정


대리 랭크 탐지를 위한 Feature는 다음과 같다. 

F1. 사용자가 플레이한 랭크 게임 로그 중 승리 수가 평균 이상으로 많은 구간

F2. 해당 구간의 게임에서 KDA 점수

F3. 해당 구간에서 파티 플레이 여부

F4. 해당 구간에서 챔피언 선택의 이질성


5.2 수집 및 분석 모델


본 논문에서는 대리 랭크 탐지를 분석을 위하여 6월 5일부터 6월 12일까지 진행된 1,600,000건의 랭크 게임 로그를 수집하였다. 전체적인 흐름도는 [그림 7]과 같으며 상세 과정은 아래와 같다.




[그림 7 - 대리 랭크 탐지 알고리즘 흐름도]



수집 Client는 Riot API를 사용하여 Match Ids를 통해 DB로부터 게임 로그를 다운로드한다. 이후 로그를 통해 랭크 게임 여부를 판별한 후 분석을 위한 Feature만을 선별하여 Match DB에 저장한다.

Match DB에 저장된 각각의 게임 로그를 파싱하여 게임 참가 유저의 ID를 얻어 ID별로 참여한 게임의 데이터를 SummonerDB에 누적한다.

Profiler는 각각의 ID에 대해 각 ID의 랭크 게임 이력을 분석하여 대리 랭크 추정 결과를 Result DB에 저장한다.


5.3 분석 알고리즘


대리 랭크 분석 알고리즘은 유저의 개의 플레이 기록 중 연속한 개()의 게임 구간을 전수 조사하여 가장 높은 결과를 얻은 추정치를 사용한다.

연승 점수(w) : 승리(1점), 패배(-1점)으로 구간에서 발생하는 연승 및 연패에 대하여 연승 카운트 에 대해 을 추가

KDA 점수(k) : [0-2], [2-3], [3-4], [4-5], [6~]으로 구분하여 가중치 적용. 패배시 1로 세팅

파티 플레이(p) : 파티 플레이어 게임 중 승리 게임에 대하여 0.2의 가중치 적용

챔피언 이질성(r) : 해당 구간을 제외한 나머지 구간에서 해당 챔피언의 빈도에 따라 패널티 부여





5.4 분석 결과 및 검증


수집된 랭크 게임 로그를 통해 총 15,186,307개의 계정에 대한 게임 이력이 확보되었으며 최소 구간의 길이는 10으로 설정하였다.

분석된 추정치 중에서 상위 400개의 계정에 대한 통계는 최댓값 189, 최솟값 47을 나타내었다.  추정치가 높은 상위 400개의 계정에 대한 사후 추적을 위하여 해당 계정의 게임 로그 데이터를 통해 랭크 상승치를 계산한 결과 [그림 8]과 같이 전체 조사된 계정과 다음과 갈은 랭크 상승 폭의 차이를 확인하였다.



[그림 8 - 대리 의심 계정과 정상 계정의 랭크 상승 평균치]


5. 결론 및 추후 연구


본 논문에서는 AOS 장르 게임인 LOL에서 제공하는 대용량 로그를 통해 BOT과 대리 랭크 행위에 대한 탐지를 수행하였으며 각각 한계점을 가지고 있다.

BOT 탐지에서는 유저의 최근 게임을 제외하고는 개별적으로 게임과 유저를 매칭할 수 있는 수단이 없어 유저 집단의 크기와 유저별 로그의 개수 중에서 한쪽을 선택할 수밖에 없었다. 이를 해결하기 위해서는 특정한 레벨 구간(ex. 20~30)에 해당하는 유저로 대상을 특정하고, 초기 수집 과정에서 게임 이력을 통해 BOT으로 의심될 요건을 갖춘 유저를 실시간 수집 대상에 놓는다면 기존의 연구의 유저 집단보다 크면서도 많은 개수의 로그를 확보할 수 있어 참고 사이트를 통해서 추가 확인을 하지 않고도 정확도의 상승을 기대할 수 있다.

랭크 게임의 탐지에서는 하루에 발생하는 랭크 게임과 참여 유저가 너무 많아 장기간에 걸친 로그 분석이 불가능했다. 충분한 기간의 로그를 수집할 수 있는 경우에는 랭크 대리 이전과 이후의 그래프를 직접 구성할 수 있으므로 정확도를 기대할 수 있을 것이다.


REFERENCES


[1] https://developer.riotgames.com/

[2] http://www.op.gg/

[3] http://www.fow.kr



PS


패치 한방으로 쓰던 논문 하나가 날라가 버렸다...


http://event.leagueoflegends.co.kr/preseason2016/ranked-improvements.php

이번 시즌에 랭크 게임 개인/2인전을 ‘자유 팀 대전’으로 변경할 계획입니다. ‘자유 팀 대전’은 기존처럼 혼자서 참여할 수도 있지만, 둘, 셋은 물론이고 다섯 명이서 팀 조합을 완전히 갖춰서 플레이할 수도 있습니다. 인원수 제한 없이 친구들과 함께 랭크 게임 래더에 도전할 수 있는 것이죠. 이제 파티로 랭크 게임을 플레이하는 경우에 불이익이 주어지지 않기 때문에, 친구를 모아서 도전할수록 언제나 더 유리할 것입니다. 


......ㅠ


저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 2

국가정보원이 이탈리아 소프트웨어 기업 '해킹팀(Hacking Team)' 으로부터 구입한 것으로 알려진 '원격조정시스템(RCS)'은 예전부터 스파이앱이라고 소개됬던 RAT(Remote Admin Tool)다.



<Fig1. HackingTeam>


기능은 언론과 블로그를 통해 많이 알려져 있으니 관련 자료를 참고 바람.


안드로이드 분석 내용

http://blog.naver.com/hinehong/220420733870


안드로이드 앱 실행파일들 분석 내용

http://blog.naver.com/hinehong/220421914756


아무리 정교하게 만든 도구라도 설치하지 못하면 말짱 도루묵이다.


기존에 스미싱 같은 경우 단축 URL를 눌러 설치 동의를 눌러야 설치가 가능했다. 그러나 위키리크스에 있는 이메일 송수신내용으로는 단축 URL에만 접속해도 감염된다고 한다. 


즉 기존 PC에서 자바취약점이나 브라우저 취약점등을 통해 임의의 실행파일을 실행하는 drive by download 과 같이 브라우저 취약점(webkit)을 통해 RCS를 설치한다.


RAT이기 때문에 당연히 정보를 보내려면 반드시 C&C서버가 존재할것이다.




위키리크스

https://wikileaks.org/hackingteam/emails/emailid/1031597



<Fig2. wikileak>



위키리크스에는 이메일 송수신 내역이 모두 저장되어서 조회가 가능하며 첨부 파일 까지 다운로드 가능하다.


<Fig3. exploit page address>


v9K0GQ에 대한 분석을 진행하였다.


<Fig4. exploit page>




exploit파일과 installer.apk 파일은 모두 암호화 되어 있다.


<Fig5. installer.apk>


script.js 또한 난독화가 적용되어 있다......



<Fig6. script.js>


방법 없다 난독화 부터 풀어야 한다...



<Fig7. installer.apk decryption>


난독화 풀고 한줄한줄 분석해서 결국 ...




<Fig8. dectypt_installer.apk >


풀어서 apk 파일을 획득했다.



<Fig9. package name >


이 앱의 패키지 명은 com.andorid.dvci 이다. 혹시 핸드폰에 패키지명 중 com.andorid.dvci 이름이 있으면 설치된거다.



<Fig10. dex2jar >


dex2jar로 깔끔하게 풀린다. 그러나..이건 어디서 많이 봤던건데..



<Fig11. dexguard>


윈도우에서 themida급인 dexguard가 적용되어 있다....ㅜ


방법 없다. 풀어야 한다...



<Fig12. dexguard string hacked!!>


정성스럽게 한줄 한줄 풀면서 분석한 결과 assets/cb.data을 열어 C&C 주소를 가져온다.


<Fig13. config file>


assets/cb.data 파일 역시나 암호화가 되어 있다...




<Fig14. cb.data>


또 다시 정성스럽게 한줄 한줄 분석 하여


<Fig15. Encryption API>



풀고 결국 Android RCS Agent configfile decrypter를 만들어 버렸다. @.@


<Fig16. Android RCS Agent config decrypter>




이 샘플의 C&C서버 주소는 hualhope.mooo.com다.



Android_RCS_Agent_config_decrypter_v0.1.zip



등록 코드를  kkoha@msn.com으로  메일로 보내주셔야 사용이 가능합니다.




저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 0




<Fig1. JTBC>


최초 기사 : 오마이뉴스 - 국정원, '무료 앱' 미끼로 일반인 전방위 사찰 의혹

http://www.ohmynews.com/NWS_Web/View/at_pg.aspx?CNTN_CD=A0002127936&PAGE_CD=ET001&BLCK_NO=1&CMPT_CD=T0016


이후 JTBC 보도 : 무료앱에 숨은 감청SW…국정원, 불특정 다수 위치추적

http://news.jtbc.joins.com/article/article.aspx?news_id=NB10965936



기사 내용 : <오마이뉴스>가 16일 김광진 새정치민주연합 의원실로부터 단독 입수한 자료를 분석한 결과, 이 블로그의 운영자는 '김동현'(DONG-HYEON KIM)이라는 사람이다. 김씨는 이 블로그 계정을 통해 구글 플러스를 이용했다. 그는 구글 플러스로 안드로이드 스마트폰용 TV, 영화, 애니메이션, 일본드라마 앱을 소개하는 사이트를 공유했다. 


오마이뉴스와 JTBC에서 주장하는 논리라면 이 사람도 같은 인물이다.


https://www.virustotal.com/ko/user/devildevil1004/



<Fig2. JTBC>



기사 내용 : 겉보기에는 일반 앱으로 보이지만, 속에는 무서운 기능이 숨어 있다. 김광진 의원실이 컴퓨터 공학 전문가와 함께 이 앱 사이트에 올라온 앱 중 '영화천국'을 다운받아 분석한 결과, 이 앱에는 ▲ GPS 현재위치 좌표 추적 ▲ 오디오 녹음 ▲ 카메라 촬영 ▲ 데이터를 특정한 주소로 송신할 수 있는 스파이웨어가 숨어 있었다.



<Fig3. blog link>



기사 내용 : 익명을 요구한 이 전문가는 <오마이뉴스>와 한 통화에서 "앱을 살펴보니 리버싱(소스코드 분석)을 방어하기 위해서 스파이웨어 코드를 철저하게 위장해놨다"며 "스파이웨어 소스코드를 분석한 결과 이 앱이 설치된 스마트폰은 실시간 위치 정보를 특정한 주소로 전송하게 돼 있었다"고 밝혔다. 


또한 그는 "언제든지 누구나 스파이웨어가 숨어 있는 스마트폰으로 실시간 녹음을 할 수 있고 카메라도 주기적으로 찍어서 특정 서버로 전송하게 돼 있다"고 설명했다.




<Fig4.  trace GPS>




<Fig5.  영화천국 1.5.1>



직접 수집한 샘플


파일 이름 : movie-v1.5.1.apk

파일 크기 : 2,785,810 byte

파일 MD5 : e6463c3e4c53addf7daf77e91fbee9c4


AndroidManifest.xml 내용 (PC로 보세요)




	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
			
				
				
				
				
			
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
			
				
				
			
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
		
	


안드로이드 보안 아키텍처상 앱에 권한이 설정되지 않으면 관련 데이터를 가져올 수 없다.


GPS관련 데이터를 사용하려면 ACCESS_FINE_LOCATION 가 필수적으로 선언되어야 한다.


http://developer.android.com/reference/android/Manifest.permission.html



<Fig6.  GPS permission>


주장하는 샘플에는 어딜봐도 해당 권한이 없다.


판단은 알아서

저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 4

EvtxCarv

2015.02.04 09:17 from 분류없음

EvtxCarv

by Chanung Pak, Jaeman Park, HyeonGyu Jang


EvtxCarv is a tool for fragmented Evtx files forensics.


Supported platforms


  • Windows (VS 2010) C++

Usage

Execute EvtxCarv to analyze an image file

EvtxCarv.exe (-r|-c) 'target image path' 'output path'
Options
    --record   (-r)    : Recover by record
    --complete (-c)    : Recover by chunk

Examples of usage

EvtxCarv.exe -c c:\\image.raw c:\\output\\
EvtxCarv.exe -r image.raw output

License

DFRC@KU

Feedback

Please submit feedback via the EvtxCarv tracker

Author: Chanung Pak (kkoha@msn.com)


Download

https://github.com/kkoha/EvtxCarv/

저작자 표시
신고
Posted by kkoha 트랙백 0 : 댓글 0