Tesla FSD는 8개의 카메라를 이용해 자동차가 알아 볼 수 있는 벡터 공간으로 변환함.
생체 시각 정보를 연구하고 구조를 구현함.
여러 스케일의 카메라 정보들이 서로서로 상호작용하면서 정보가 들어옴.
그리고 이걸 동시다발적으로 해봄. 우린 이걸 HydraNets(히드라넷)이라 부름.
근데 이걸로는 부족한거같아서, 도로의 상황을 자동차가 알아서 추론하는 기능을 넣음.
카메라로 그냥 벡터공간을 그리면 저렇게 깨져있는 점선의 교차로 모습이 나옴.
여러 카메라에 걸쳐서 나오는 데이터가 같은거라도 일부분만 있다보니 이게 뭔지 알아보기 어려움.
그래서 Tesla는 카메라의 왜곡된 정보를 필터링하고 또 여러 정보들을 하나로 합쳐봄.
그렇게 필터링된 데이터를 합치면 왼쪽 하단의 깨진 그림이 아니라 오른쪽 하단 처럼 깔끔한 교차로가 나옴.
카메라를 통해 물체의 2D(평면)만 보고 3D(입체)의 모습을 추론시킴.
정지된 2D(평면)이 아니라 계속 움직이는(Video)의 형태로 학습시키고 있음.
FSD가 앞므로의 도로 모습을 예측하고 주행하는 모습임.
FSD는 모든 시공간의 벡터 정보를 전부 통합해서 주행 함.
도로에선 여러가지 많은 상황들이 발생하게 되는데 그걸 계속해서 예측. (옆의 그래프들)
좁은 길목 에서 마주오는 차량을 발견했을때, 누가 먼저 양보할지 판단하고 상대방의 차량에 대한 상황도 계속 예측시킬거임.
계속된 상황 예측과 판단으로 최적을 계산하고 그곳으로 주행을 할 것임.
이런 개같은 상황에서도 적용될수 있게 노력할것 임.
Tesla 입맛에 맞춘 데이터 라벨링 분석 인프라를 구축했음. (라벨링 : AI 학습데이터를 만들기 위해 원천데이터에 값(라벨)을 붙이는 작업임. 사람이 일일이 데이터에 라벨을 붙여야 해 'AI 눈알 붙이기'라고 함. 그래서 자동화하는데 이거 제대로 하는 회사 별로 없음 ).
시공간 데이터 전부 활용해서 열심히 라벨링함.
각 차량 데이터를 조각조각 모아서 맵을 만듬.
.
Tesla는 지금 어느정도 자동화 라벨링 인프라를 구축했고, 현재 자동화 라벨링 중이며 클라우드 서버 없이 오프라인으로 이정도 처리하고 있음.
당연히 악천후 다 데이터 통합해서 학습시키고 있음.
그 동안 모은 데이터를 바탕으로 가상 시뮬레이션을 만들어서 이걸로 학습시키고 있음.
이 가상 시뮬레이션으로 밤, 낮 등 수천가지 물체 지형 전부 학습할꺼고 실제 상황에서 일어나기 힘든 인위적인 상황도 전부 시뮬레이션 돌 리는 중임.
Elon Musk : Tesla 시뮬레이터 엔진 개쩔어서 이걸로 게임 하나 만들수 있음.
현실 배경을 바탕으로 유사한 배경으로 재구축 가능함. (게임 맵 생성되듯이)
오토파일럿 컴퓨터,클라우드 전부 확장중임. 이거 받쳐주는 하드웨어는??
칩설계 제일 잘하는 사람 스카웃해와서 새로운 칩셋 만들었음.
짜잔 이게 새로만든 D1 칩임. CPU GPU 네트워킹 전부 가능하고 머신러닝 최적화로 만들었음. 테슬라가 자체적으로 설계 공정 전부 다 했다 어떰??
이렇게 지금 도조(Dojo) 컴퓨터 시스템에 쓰고있음.
여러 칩셋들 조온나게 연결해도 병목없이 구축가능하게 만들었음. 분산 컴퓨팅 자급자족.
Tesla 도조(Dojo) 컴퓨터 시스템 핵 빠름 (1.1exaFLOP(엑사플롭) //1초에 100경 처리).
xaasxasxasx.blogspot.com 는 블로그 형태로 있으며 자바스크립트가 추가되어있다.
이 자바스크립트는 한눈에 알아볼 수 없게 구성되어 있다.
hxxps://xaasxasxasx.blogspot.com/p/usama.html
페이지에는 바이너리나 악성 링크가 포함되어 있지 않지만, 소스 코드를 보면 렌더링 하는 동안 페이지에 동적으로 infect 한 압축된 HTML 코드가 나타난다.
이 추가 스크립트는 "mshta" 유틸리티에 의해 실행하도록 설계되었다. "WScript.Shell"은 오브젝트를 만드는 VBScript 코드이다. mshta.exe는 Microsoft HTML 응용 프로그램 (HTA) 파일을 실행하는 유틸리티고 HTA는 Internet Explorer와 동일한 모델과 기술을 사용하지만 브라우저 외부에서 실행되는 독립 실행 응용 프로그램이다.
실행되는 첫 번째 단계에서 unescape를 3번 실행해서 푼다.
VBScript 코드의 StrReverse 함수를 사용하여 난독화 되어 있다.
hxxps://xaasxasxasx.blogspot.com/p/usama.html
4개의 레이어로 구성되어 있고 StrRverse과 splitedsplited 된 변수, 멀티 Wscript 오브젝트 등을 사용하는 vb스크립트가 나온다. mshta hxxp://www.pastebin.com/raw/c3V923PW
hxxp://www.pastebin.com/raw/c3V923PW
Word, Excel, Publisher 및 PowerPoint와 같은 일부 Microsoft Office 프로세스를 종료하는 역할을 한다.
이후 재감염을 위해 persistence를 추가한다. 2단계에서 두 개의 schedule task를 만들고 숨겨진 창을 닫는다.
TTP를 변경하거나 작업에서 킬 스위치를 실행하는 update vector처럼 사용하였다.
hxxp://www.pastebin.com/raw/c3V923PW
첫 번째 pastebin은 4 개의 unescape레이어와 이전의 난독화 방법으로 사용한다.
최종 코드는 숫자로 인코딩 된 Powershell이다.
hxxp://www.pastebin.com/raw/VFUXDF7C
이 디코딩된 텍스트는 IEX 명령어를 통해 Powershell에서 command let으로 실행된다.
hxxp://www.pastebin.com/raw/VFUXDF7C
복호화하면 아래 그림과 같다. 이 코드가 악성코드의 implant 핵심이다. 둘 다 Pastebin에서 서로 다른 HTA 애플리케이션을 호출한다.
hxxp://www.pastebin.com/raw/VFUXDF7C
첫 번째는 NET 프레임 워크의 Reflection Assembly에서 LoadWithPartialName 함수를 사용하여 메모리에서 데이터를 다운로드하고 실행한다. 이 Loader는 dll의 명령과 데이터를 얻기 위해 getstring 메서드를 사용하는 난독화레이어가 있다.
"0rhAppFq”은 Powershell 코드는 payload를 숫자 형식으로 인코딩한다.
난독화된 다른 powershell scrip인 payload를 디코딩하면서 실행 중인 프로세스 메모리에 직접 shell code가 로드된다.
dll은 ConfuserEx (1.0.0.0) 프로텍터로 보호되며 escaped 된 문자열과 레퍼런스 모듈을 볼 수 있다. 이 코드는 Process Hollowing 기술을 통해 대상 프로세스에 payload를 삽입하는 목적을 가진 dynamic linking library이다.
Encbuf는 크기가 다양하며 다음과 유사한 함수로 참조된다. 코드 조각이 실행되는 주소를 결정하는 쉘 코딩 기술이다.
예를 들어 아래 그림과 같이 0x41AFC2에서 call +5를 호출하면 0x41AFC7이 호출된다. encbuf는 반환된 주소 뒤에서 2 바이트를 시작하여 pop 및 retn 명령어를 건너뛴다. 모든 encbuf는 일반적인 x86 함수의 프롤로그처럼 보이는 것으로 시작한다. 결국 이 코드는 실행해서 분석해야 하지 정적 디스어셈블 하면 의미가 없다.
Fake fucntion prologue
일부 문자열들은 스택에서 한 번에 DWORD로 넣어 빌드한다.
Stack-strings obfuscation
C2에 데이터를 보내는 사용자 에이전트 설정을 볼 수 있습니다.
Stack-strings obfuscation urlmon.dll, user-agent
Opera chrome user32 pass32 auth32 login Chome_child_dll
Stack-strings obfuscation
각각 decrypt_func1 및 decrypt_func2와 같은 복호화 기능이다.
Decrypt_func1은 암호화된 데이터를 반복하고 바이트 값에 따라 암호화 된 데이터의 특정 오프셋에서 일반 텍스트 데이터로 일정량의 데이터를 복사한다. decrypt_func2는 덧 샘, 뺄샘뺄샘, RC4으로 총 세 가지 라운드로 나눠진다.
일반적으로 문자열을 체크할 때 strcmp 등의 함수를 사용하는데 이때 문자열이 메모리에 남을 수 있다. 이 formbook은 문자열이 메모리에 흔적을 남기는 것을 최소화하도록 문자열의 CRC32 해쉬 값을 사용하여 특정 문자열 검색과 비교를 한다.
예를 들어 어떠한 API를 Export table 등에서 검색할 때에 문자열 단위의 검색이 아닌 CRC32 해쉬값을 통한 검색을 사용한다. 이러한 방법은 기존 쉘 코드등에서 쉘코드 크기를 줄이고 쉘 코드를 쉽게 리버싱 하지 못하게 하려는 의도로 자주 사용되는 기법이다.
먼저 해시를 포함하는 encbuf가 복호화한다. 여기서는 두 개의 다른 encbuf, 위의 암복호화 기능 및 일부 SHA1 해싱이 필요하다.
Strings hashing
decrypt 된 encbuf에 인덱스를 지정하고 해시를 decrypt 한다.
Anti-debugging은 다음과 같이 구현하였다.
Anti-debugging tricks
감시되는 프로세스 목록, 경로, 사용자 이름 등은 다음과 같다.
formbook의 몇가지 특징적인 기능들을 소개하였다. 처음부터 마지막 페이로드까지 보면 공격자는 많은 준비를 했다는 것을 알 수 있다.
LLVM 프로젝트는 IR (Intermediate Representation) 수준에서 구현되어 프로그래밍 언어 (C, C ++, Objective-C, Ada 및 Fortran)와 CPU (x86, x86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, XCore)등이 호환된다.
여기서 bogus control-flow, control-flow flattening, code tamper-proofing 등을 적용한 것이 OLLVM이고 이 프로젝트는 OpenSource이다.
2018년에 OLLVM이 적용된 놈을 android 보안 솔루션에서 처음 접하여 분석했었는데... PC 악성코드에서 만나니 반가웠다.
히오스 폭리 큐 기다리는 동안 작성 할 수 있는 것이 String Obfuscation 까지라... 여기까지만 정리하겠다.
엔씨소프트의 핵심 캐시 카우 역할을 하던 PC버전 리니지가 모바일버전으로 개발되었다. 2017년 6월 리니지M 출시하여 100일 이지나 매출 6000억 돌파 라는 엄청난 기록을 새운다.
계정 도용 등의 해킹 사건이 일어났었지만 서버 해킹이 아닌 서드파티를 통한 해킹으로 알려져 있다. 2차인증 기기등록으로 정해진 기기에서만 플레이할 수 있게 조치하였다. 따라서 연동된 계정을 해킹한다 하여도 기기등록을 해제해야 접속 할 수 있다.
<Fig2. 기기등록>
모바일 게임 답게 자동사냥(이하 자사)기능을 게임내 자체적으로 기능을 구현하여 알아서 몬스터 처치, 버프, 물약마시기 등등을 한다.
그래서 사냥터까지 플레이어가 이동시키고 자사 켜두고 딴 일 보는 게임이 되어 버렸다. (다마고찌)
<Fig3.게임화면>
일반적인 한국형 모바일게임은 에뮬레이터를 통해 플레이하는 것을 막으려고 하는데 리니지M은 열어놨다. 왜 안했는지 이제 알 것 같다. 이걸 만약 핸드폰으로 했으면 채굴하러 끌려간 그래픽카드 꼴이다..
리니지m 안한 중고폰 사요!
어쨌든 PC 리니지도 레벨업이 엄청나게 힘들었지만 리니지M도 마찬가지다. 아인사하드 없으면 레벨업 못한다. 매일 똑같은 하이네잡밭에 캐릭터를 갔다 놓으면 뭔가 의무적으며........채굴하는 느낌이다. 어느정도 하다 보면 사냥터까지 보내는 것도 귀찮아지며, 물약 사는 것도 엄청나게 귀찮아진다.
<Fig4. 매크로>
게임 봇인 유니크 매크로라는 프로그램이다. 리니지M 매크로 중 엄청나게 많은 기능들을 지원하며 업데이트를 매 패치 마다 해준다.
자동육성 기능이 있어 좋은 변신이 나올때까지 변신뽑기까지만 하고 버리고 하는 작업장이 생겨 결국 NC에선 50레벨 미만은 뽑기를 막아놨다.
로그기반 봇탐지를 회피하기 위해 각 액션 마다 랜덤성을 부여하는 기능도 제공한다고 한다...ㅎㄷㄷ
<Fig5. 작업장>
에뮬레이터를 막지 않아 다중 계정으로 일반 PC에서 최소 4개이상은 돌아가니 집에서도 작업장을 운영할 수 있다 !
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여도 큰 문제는 없다.
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
보드에서 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!>
바이오스 수정해서 올리지 마세요. 벽돌 될 수 있습니다. 전 못고치며 모든 책임은 당신에게 있습니다.
sony malware 분석 내용 : http://kkoha.tistory.com/entry/sony-malware-analysis
2014년 11월 소니픽처스 공격과 2015년 12월 발생한 베트남 은행 공격, 그리고 올해 2월 발생한 방글라데시 중앙은행 공격에서 사용된 악성코드의 비교 결과 파일삭제 기능의 함수 코드 진행 부분이 매우 유사하다는 것이다. 그러나 이번 해킹사건이 북한의 소행이라고 단정 짓기는 어렵다는 게 이슈메이커스랩 측의 설명이다.
이런 내용을 공유할 때는 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 함수로 삭제한다.
