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

Sony malware analysis

2014.12.24 20:20 from 분류없음


<Fig1. Hacked by #GOP 사진 원본 >


2014년 11월 24일에 소니 픽쳐스 엔터테인먼트가 사이버 테러를 당했다.

FBI는 소니 픽처스 엔터테인먼트 해킹 사건의 책임이 북한 정부에 있다는 수사 결과를 발표했다.


전문 : http://www.fbi.gov/news/pressrel/press-releases/update-on-sony-investigation


As a result of our investigation, and in close collaboration with other U.S. government departments and agencies, the FBI now has enough information to conclude that the North Korean government is responsible for these actions. While the need to protect sensitive sources and methods precludes us from sharing all of this information, our conclusion is based, in part, on the following:

우리 수사의 결과로, 또 다른 미국 정부 부처와 기관들과의 긴밀한 협력을 통해서, FBI는 이제 북한 정부가 이런 행위들에 대한 책임이 있다는 결론을 내리기에 충분한 정보를 가지고 있다. 민감한 정보원들과 방법들을 보호할 필요성이 있어 우리가 이 정보를 모두 공유할 수는 없지만, 우리 결론은 부분적으로 다음과 같은 사항들에 근거하고 있다 : 


Technical analysis of the data deletion malware used in this attack revealed links to other malware that the FBI knows North Korean actors previously developed. For example, there were similarities in specific lines of code, encryption algorithms, data deletion methods, and compromised networks.

이번 공격에 쓰인 데이터 삭제 맬웨어의 기술적 분석 결과, 북한측 행위자들이 이전에 개발한 것으로 FBI가 알고 있는 다른 맬웨어에 대한 연관이 드러났다. 예를 들어, 특정 코드 라인, 암호화 알고리즘, 데이터 삭제 방법, 침해를 당한 네트워크들 등에 유사성이 있었다.


The FBI also observed significant overlap between the infrastructure used in this attack and other malicious cyber activity the U.S. government has previously linked directly to North Korea. For example, the FBI discovered that several Internet protocol (IP) addresses associated with known North Korean infrastructure communicated with IP addresses that were hardcoded into the data deletion malware used in this attack.

FBI는 또 이번 공격에 쓰인 인프라스트럭처와, 미국 정부가 북한에 직접적으로 연관시킨 바 있는 다른 악성 사이버 활동 사이에 상당히 많은 겹침이 있다는 사실을 관찰했다. 예를 들어 FBI는 알려진 북한 인프라와 연관된 몇 개의 인터넷 프로토콜(IP) 주소들이 이번 공격에 쓰인 데이터 삭제 맬웨어 내에 하드코딩된 IP 주소와 교신했다는 사실을 발견했다.


Separately, the tools used in the SPE attack have similarities to a cyber attack in March of last year against South Korean banks and media outlets, which was carried out by North Korea.

별도로, SPE 공격에 사용된 도구들은 작년 3월 남한 은행들과 언론매체들에 대한 사이버 공격과 유사성이 있는데, 당시 공격은 북한에 의해 이뤄졌다.


자 그럼 소니 악성코드를 들여다 보자

파일 정보 :

<Fig2. PEiD >


오예 패킹 하나도 안되어 있다.!!



<Fig3. GetModuleFileNameW >


GetModuleFileNameW 를 통해 경로 확인 파라메터가 없을 시 새로운 프로세스 생성한다.

즉 최초 실행 시 –i 옵션으로 다시 실행한다.



<Fig4. CreateServiceW >

이후 옵션이 –i 으로 실행되어 있는지 확인한다.

-i 옵션이 아니라면 그림과 같이 brmgmtsvc 라는 이름으로 서비스 등록하여 실행한다.


결론적으로 악성 행위를 하기 위해선 최초 실행 -> -i 옵션으로 실행 -> -k 옵션으로 서비스 등록 단계를 거쳐 악성 행위 단계로 넘어간다.



<Fig5. inet_addr >

203.131.22.102:8080

217.96.33.164:8000

88.53.215.64:8000


Send SYN packet!



<Fig6. ???? >

뭔지 모름 날짜 같은데 사용하지 않음



<Fig7. 0x927C0 == 600000 Sleep>


-k 옵션으로 실행 되어있는지 확인한다. 이때 -k 옵션이라면 10분 동안 Sleep (자동분석 ㅃ2)



<Fig8. taskhost%s.exe>


이후 rand 함수를 통해 알파벳 2글자를 생성하여 <현재경로>\taskhost%s.exe 자기 자신 복사하여 파라메터 -w 주고 실행한 뒤 파라메터 -d 와 -m 으로 총 3개의 파일을 생성하고 실행한다. 이때 각 파일명은 랜드함수를 쓰기 때문에 다르다.


ex ) 

taskhostko.exe -w

taskhostha.exe -d

taskhostsu.exe -m


-d 옵션으로 모든 드라이브에 있는 파일 삭제( Windows와 Program Files 폴더는 제외 ) 


<Fig9. File Delete>


-w 옵션으로  iissvr.exe 파일을 드롭하여 실행한다.


termservice 종료하기 위해 cmd.exe /c net stop termservice /y 명령어를 실행한다.


이후 %Windows%폴더에 iissvr.exe 파일을 드롭한다. 이 파일은  PE 리소스 섹션에 XOR 연산한 값으로 저장되어 있다.



<Fig10. html>


이 드롭되는 파일의 리소스 영역에는 JPG, HTML, WAV 파일이 있으며, XOR 키 값은 고정으로 박혀있다.


파일 정보 :


<Fig11. Drop iisvr.exe>


-m 옵션은 usbdrv3.sys 파일을 드롭하여 드라이버를 등록한다.


%TEMP%폴더에 usbdrv3.sys 파일을 드롭하며 마찬가지로 PE 리소스 섹션에 드롭되는 파일이 XOR 연산되어 저장되어 있다.


파일 정보 :


<Fig12. Drop usbdrv3.sys>


드라이버 드롭 후 드라이버 등록한 다음  MBR wipe 작똥!



<Fig13. Drop usbdrv3.sys>


MBR을 파괴시키기 위해 랜덤데이터를 생성한다.


<Fig14. rand>


그림과 같이 rand 함수를 통해 0x10000 만큼 랜덤 데이터를 먼저 생성한다.



<Fig15. Wipe>


이후 MBR 영역에 0x10000 만큼 AAA ....(0xAA, 0xAA ... ) 로 채워 0x41번 루프문을 돌아 덮어 쓴 이후 (총 0x410000) UUUU .... (0x55, 0x55 .. )로 0x41번 루프문을 돌아 덮어 쓰고 (총 0x410000)  이후 아까 생성한 랜덤 데이터로 다시 0x41번 루프문을 돌아 덮어 쓴다. (뭐이리 많이...)



<Fig16. CreateThread 300!!!!!>


그다음 또 wipe 스레드를 무려 0x12C ( 300) 개나 생성하는데....




<Fig17. end>

아..앙대




<Fig18. LANG_KOREAN>


mfc로 제작되어 있으며 다이얼 박스에서 언어팩이 korean으로 되어 있는 것도 확인 할 수 있다.




아까 지나갔던 XOR연산으로 파일 복호화하는 알고리즘은....키 생성이 간단한것 같지만 생각보다 많이.. 귀찮음...ㅠㅠ


결론적으로 리소스 사이즈로 1차 키 생성하고 이후 3번의 돌면 xor 키가 생성되어 풀게된다.



<Fig19. Decrypt>



논리 이해하겠다고 무식하게 파이썬으로 포팅해서 첫번째 0x06는 생성함 ^^V 

향후 추가적으로 분석 의향 없음 ㅠㅠ



size = 0x5ED8
ESI = size
EAX = 0x55555556
EAX = EAX * ESI
EDX = EAX >> 32
EAX = EDX
EAX = EAX >> 0x1F
EDX = EDX + EAX 
EBX = EDX
EDI = 0x90ABCDEF
EAX = 0xFE268455
ESI = 0xC2B45678
for i in range(EDX):
    ESI = ESI ^ EDI
    EDI = EAX ^ EDI
    EAX = EAX ^ ESI
EDX = EDI
A = ESI | EDX
B = EDI | EAX
C = EAX | A
EAX = A
EAX = EAX >> 0x9
EAX = EAX & 1
ESI = EAX ^ 0
EAX = A
EAX = EAX >> 0x1
EAX = EAX ^ A
EAX = EAX >> 0x1
EAX = EAX ^ A
EAX = EAX >> 0x3
EAX = EAX ^ A
EDX = A & 0x3FFFF
EDX = EDX + EDX
EAX = EAX >> 0xD
D = EDX
EAX = C
EDX = C
EAX = EAX >> 0x1
EAX = EAX ^ EDX
EAX = EAX >> 0x3
EAX = EAX ^ EDX
EAX = EAX >> 0x1
EAX = EAX ^ EDX
EDX = EDX & 0x3FFFFF
EAX = EAX >> 0x11
EDX = EDX + EDX
EAX = D
ECX = EDX
EDX = B
ECX = ECX ^ EDX
ECX = ECX ^ EAX
EAX = ECX
EDX = ECX
EAX = EAX >> 0x18
EDX = EDX >> 0x10
EDX = EDX&0xFF
EAX = EAX ^ EDX
EDX = ECX
EDX = EDX >> 0x8
EDX = EDX & 0xFF
EAX = EAX ^ EDX
ECX = ECX & 0xFF
EAX = EAX ^ ECX
print "%X" % EAX




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

티스토리 툴바