Hey there!
Anti-Cheat Toolkit(ACTk)을 구입해 주셔서 대단히 감사합니다.
Unity를 위한 종합적인 치트 방지 솔루션!
DISCLAIMER:
이 플러그인에 사용된 치트 방지 기술은 가장하지 않습니다.
100% 안전하고 깨지지 않도록(불가능 클라이언트 측에서)
대부분의 사기꾼이 시도하는 것을 중지해야 합니다.
그래도 앱을 해킹하려면 명심하십시오: 동기 부여가 잘 됨
숙련된 해커는 무엇이든 부술 수 있습니다!
Installation and setup
새 버전을 프로젝트로 가져오기 전에 다음을 방지하기 위해
이전 버전을 완전히 제거하는 것을 고려하십시오.
새 버전에서 가능한 파일 및 폴더 구조 변경으로 인한 모든
문제.
프로젝트에 플러그인을 가져온 후 추가 설정 및 제어를 위한
새 메뉴를 찾을 수 있습니다:
• Tools > Code Stage > Anti-Cheat Toolkit
• GameObject > Create Other > Code Stage > Anti-Cheat Toolkit
플러그인 기능, 모범 사례 및 힌트에 대해 자세히 알아보려면
이 문서를 읽으십시오.
Settings window
Editor Preferences 섹션을 사용하여 디버깅 및 디버깅을 위한
감지기 및 조건부 컴파일 기호를 구성합니다. 호환성 목적. 모
든 설정은 프로젝트의 "ProjectSettings/ACTkSettings.asset"에
저장됩니다.
ACTk 설정을 열려면 Tools > Code Stage > Anti-Cheat Toolkit
> Setting 메뉴 명령을 사용하십시오.
여기에서 다음과 같은 항목을 볼 수 있습니다.
• 프로젝트에서 사용 중인 ACTk 버전
• 유용한 링크 및 바로가기(홈페이지, 포럼, 지원, 리뷰, 본 매
뉴얼, API 참조, about)
• IL2CPP는 친구 섹션입니다. - 치트 방지 관점에서 Mono보
다 IL2CPP의 장점을 설명하고 쉽게 현재 플랫폼이 지원하는
경우 IL2CPP로 전환하십시오.
• Injection Detector 설정 섹션 – 관리되는 DLL 주입 감지 장
에서 세부 정보를 참조하십시오.
• 코드 해시 생성기 – 코드 무결성 검사 장에서 자세한 내용을
참조하십시오.
• WallHack 감지기 설정 섹션 - Wallhack 감지 장에서 자세한
내용을 참조하십시오.
• 다양한 디버그 및 호환성 조정, 로그 및 그런.
플러그인 기능 심도
메모리 부정행위 방지 비디오 튜토리얼
[https://www.youtube.com/watch?v=QiznofE8xD4&index=2&list=PLbTYvIYxIXSj5p9qn3lcsoUc1R9KnSOIb]
중요: regular type을 obscured 로 교체하는 동안 주의하십
시오. inspector 값이 reset 됩니다!
이것은 다양한 플랫폼에서 가장 인기 있는 부정 행위 방법입
니다. 사람들은 특별한 도구를 사용하여 메모리에서 변수를
검색하고 그들의 가치를 바꾸십시오. 일반적으로 돈, 건강, 점
수 등입니다. 몇 가지 예: 치트 엔진, 아트머니(PC), 게임 CIH,
게임 가디언(안드로이드). 이러한 플랫폼과 다른 플랫폼을 위
한 다른 도구도 많이 있습니다
메모리 치트 방지 기술을 활용하려면 일반 유형 대신
ObscuredInt, ObscuredFloat, ObscuredString 등(모든 기본
유형 + 몇 가지 Unity 특정 유형이 포함됨) ...
이러한 유형은 다음과 같이 일반 내장 유형 대신(및 함께) 사
용할 수 있습니다.
// place this line right at the beginning of your .cs file!
using CodeStage.AntiCheat.ObscuredTypes;
int totalCoins = 500;
ObscuredInt collectedCoins = 100;
int coinsLeft = totalCoins - collectedCoins;
// will print: "Coins collected: 100, left: 400"
Debug.Log("Coins collected: " + collectedCoins + ", left: " + coinsLeft);모든 int <-> ObscuredInt 캐스트는 암시적으로 수행됩니다.
다른 가려진 유형도 마찬가지입니다!
그러나 일반 int와 ObscuredInt 사이에는 한 가지 큰 차이점
이 있습니다. 치터는 쉽게 찾을 수 없으며 ObscuredInt로 메
모리에 저장된 값을 변경합니다. 일반 int에 대해 말할 수 없
는 것!
음, 사실, 당신은 사기꾼이 그들이 찾고 있는 것을 찾고 부정
행위 시도에서 그들을 잡을 수 있도록 허용할 수 있습니다.
실제 가려진 값은 다음과 같은 경우에도 여전히 안전합니다.
그들이 하기를 바랍니다 ;)
이러한 부정 행위 시도 감지에는 아래 설명된
ObscuredCheatingDetector를 사용하십시오.
obscured type 에 대한 추가 단어
"Examples/API Examples" scene 에서 obscured type 사용 예
를 찾을 수 있으며 직접 속일 수도 있습니다. 플러그인과 함께
제공됩니다.
Obscured types pro-tips:
• 모든 단순 Obscured 유형에는 공용 정적 메서드
GetEnctypted() 및 SetEncrypted()가 있어 작업할 수 있습니다.
가려진 인스턴스의 암호화된 값. 사용자 정의 저장 엔진을 사
용하려는 경우 도움이 될 수 있습니다.
• 어떤 경우에는 사기꾼이 소위 "알 수 없는 값" 검색을 사용하
여 모호한 변수를 찾을 수 있습니다. 그들이 할 것이라는 사실
에도 불구하고 암호화된 값을 찾고 모든 부정 행위(치트 엔진
에서 정지 또는 메모리 편집기에서 변경)를 감지합니다.
ObscuredCheatingDetector, 그들은 여전히 그것을 찾을 수 있
습니다. 이를 완전히 방지하기 위해 모든 기본 모호한 유형 -
RandomizeCryptoKey(). 변수가 변하지 않는 순간에 사용하여
변경 원래 값을 그대로 유지하는 암호화된 표현. 사기꾼은 변경
되지 않은 값을 검색하지만 실제로는 값을 찾습니다.
변수 찾기를 방지하기 위해 변경됩니다.
• GenerateKey() API를 사용하여 Encrypt(value, key) 메서드에 대
한 임의의 암호화 키를 생성할 수 있습니다. 잊지 마세요
나중에 값을 Decrypt()하기 위해 해당 키를 저장합니다
IMPORTANT:
• 현재 ObscuredString, ObscuredBool, ObscuredInt, ObscuredUInt,
ObscuredFloat, ObscuredLong, ObscuredULong, ObscuredDouble,
ObscuredVector2, ObscuredVector3, ObscuredDecimal,
ObscuredVector2Int, ObscuredVector3Int, ObscuredQuaternion.
regular 를 obscured type 로 교체시 주의 – inspecter 값이 리셋됩
니다!
• 여전히 매우 빠르고 가벼우면서도 가려진 유형은 일반적으로
일반 것들. 업데이트, 루프, 거대한 배열 등에서 가려진 변수를 멀리
유지하고 계속 주시하십시오. 특히 모바일 프로젝트에서 작업할 때
프로파일러.
• LINQ 및 XmlSerializer는 현재 지원되지 않습니다.
• 바이너리 직렬화가 기본적으로 지원됩니다.
• JSON 직렬화는 다음과 같은 경우에도 가능합니다.
• ISerializable 구현(예제) 또는 변환기(mcmorry의 예)를 사용하는
.NET용 Newtonsoft Json
• ISerializationCallbackReceiver의 도움으로 Unity의 자체
JsonUtility(예시).
• 일반적으로 고급 작업을 수행하고 캐스트하기 위해 모호한 변수를
일반 변수로 캐스팅하는 것이 좋습니다. 잘 작동하는지 확인하기
위해 그 후에 다시 돌아갑니다.
파일 부정 행위 방지
https://www.youtube.com/watch?v=JCNEl1xQ0WE&list=PLbTYvIYxIXSj5p9qn3lcsoUc1R9KnSOIb
Obscured File
파일은 저장된 게임 및 기타 민감한 정보 저장을 위한 일반적인
장소입니다.
그러나 적절한 보호가 없으면 파일은 다음 위협에 취약합니다.
• 바이너리가 아닌 파일에서 민감한 데이터 식별(게임 변수, 자
격 증명, 게임 내 개발자 치트 등).
• 데이터 수정(100에서 999999 등으로 돈을 속이기 위해).
• 다른 사기꾼과 파일 공유를 속이거나 수정했습니다.
ObscuredFile은 다음과 같은 모든 위협을 다룹니다.
• 선택적으로 데이터를 암호화하여 호기심 많은 눈에서 숨길 수
있습니다.
• 변조 감지 기능이 내장되어 있어 데이터 수정 사항을 탐지할 수
있습니다(암호화 파일과 일반 파일 모두).
• 선택적으로 다른 장치에서 공유된 파일을 감지하기 위해 장치
ID 또는 사용자 정의 ID로 데이터를 잠급니다. 기기 잠금 보기
더 많은 것을 알기 위한 메모.
ObscuredFile은 원시 바이트 배열만 읽고 쓸 수 있습니다. 사용
자 친화적인 PlayerPrefs는 아래 ObscuredFilePrefs를 확인하십
시오 - 비슷한 API.
설정 및 사용법은 매우 간단합니다.
// place this line right in the beginning of your .cs file
using CodeStage.AntiCheat.Storage;
// create new instance with default settings
var secureFile = new ObscuredFile();
// write data
var writeResult = secureFile.WriteAllBytes(abstractBytes);
if (writeResult.Success)
Debug.Log($"Data saved to {secureFile.FilePath}");
else
Debug.LogError($"Couldn’t save data: {writeResult.Error}");
// read data
var readResult = secureFile.ReadAllBytes();
if (readResult.Success)
// process readResult.Data;
else if (readResult.CheatingDetected)
// punish cheaters, check DataFromAnotherDevice \ DataIsNotGenuine readResult properties
else
Debug.LogError($"Something went wrong while reading data: {readResult.Error}");위의 예에서 abstractBytes는 기본 설정으로 저장 및 로드되지만
파일 경로 및 ObscuredFileSettings API를 사용하여 이름, 암호화
설정, 장치 기능 설정에 대한 잠금 및 변조 방지
ObscuredFile을 구성하고 사용하는 방법에 대한 자세한 내용은
API 설명서 및 사용 예를 참조하십시오.
Examples\API Examples\Scripts\Runtime\UsageExamples\
ObscuredFilePrefsExamples.cs
IMPORTANT:
• UnityApiResultsHolder.InitForAsyncUsage(true)를 호출합니다.
가려진 파일로 작업하기 전에 메인 스레드에서 백그라운드 스
레드에서.
• ObscuredFile은 추가 암호화로 인해 일반 파일에 비해 느리게
작동합니다. 만들다 뜨거운 경로에서 사용하지 마십시오.
Obscured File Prefs
이것은 매우 사용하기 쉬운 일반 API를 가진 정적 ObscuredFile
래퍼입니다. 다양한 환경 설정을 읽고 쓸 수 있습니다. 유형(모든
기본 C# 유형, byte[], DateTime 및 몇 가지 Unity 유형이 지원됨).
ObscuredFile과 같은 기능을 모두 가지고 있으며 부정 행위로부
터 보호되는 ObscuredFile에 prefs를 저장합니다. 다음은 간단한
사용 예입니다.
// place this line right in the beginning of your .cs file
using CodeStage.AntiCheat.Storage;
// init with default settings
ObscuredFilePrefs.Init();
// listen for cheating
ObscuredFilePrefs.NotGenuineDataDetected += OnDataCheat;
ObscuredFilePrefs.DataFromAnotherDeviceDetected += OnLockCheat;
// write pref
ObscuredFilePrefs.Set("pref key", data);
// read pref
data = ObscuredFilePrefs.Get("pref key", defaultValue);
// alternatively, specify data type and omit defaultValue argument
// data = ObscuredFilePrefs.Get<T>("pref key");
// get all pref keys to iterate then needed
var keys = ObscuredFilePrefs.GetKeys();ObscuredFile 예제와 유사하게 기본 설정이 사용되었으며 필요에
따라 ObscuredFilePrefs를 구성할 수 있습니다.
ObscuredFileSettings API 사용
IMPORTANT:
• UnityApiResultsHolder.InitForAsyncUsage(true)를 호출합니다.
가려진 파일로 작업하기 전에 메인 스레드에서 백그라운드 스
레드에서.
• ObscuredFilePrefs는 추가 작업으로 인해 일반 File 또는
PlayerPrefs에 비해 느리게 작동합니다. 암호화. 뜨거운 경로에
서 사용을 피하십시오.
Preventing Player Prefs cheating
https://www.youtube.com/watch?v=Hf0MOct9rDQ&index=3&list=PLbTYvIYxIXSj5p9qn3lcsoUc1R9KnSOIb
Unity 개발자는 종종 PlayerPrefs(PP) 클래스를 사용하여 소량의
민감한 데이터(돈, 게임 진행 상황 등)를 저장하고,
그러나 거의 노력 없이 찾아내고 변경할 수 있습니다. 이것은
regedit를 열고 그것을 탐색하는 것만 큼 간단합니다.
예를 들어 Windows의 HKEY_CURRENT_USER\Software\
Your Company Name\Your Game Name
이것이 내가 이 툴킷에 ObscuredPrefs(OP) 클래스를 포함하기로
결정한 이유입니다. 평소와 같이 데이터를 저장할 수 있지만 유지
보기와 변경으로부터 안전합니다. 정확히 우리가 저장한 내용을
부정 행위 방지로 유지하는 데 필요한 것입니다! ☺
다음은 간단한 예입니다
// place this line right in the beginning of your .cs file
using CodeStage.AntiCheat.Storage;
ObscuredPrefs.Set<float>("currentLifeBarObscured", 88.4f);
var currentLifeBar = ObscuredPrefs.Get<float>("currentLifeBarObscured");
// will print: "Life bar: 88.4"
Debug.Log("Life bar: " + currentLifeBar);보시다시피 사용 방법에는 변경 사항이 없습니다. 모든 것이
기존의 좋은 일반 PlayerPrefs 클래스와 동일하게 작동하지만
이제 귀하의 저장은 사기꾼(대부분의 사기꾼)으로부터 안전
합니다!
추가 기능:
• NotGenuineDataDetected 이벤트를 구독할 수 있습니다.
저장된 데이터 무결성 위반에 대해 알 수 있습니다.
일부 변조된 데이터를 읽는 즉시 한 번(전체 세션에 대해) 실
행됩니다.
• OP는 일반 PP에 비해 많은 추가 데이터 유형을 지원합니다.
모든 기본 C# 유형, byte[], DateTime 및 몇 가지 Unity유형.
• 장치 잠금 기능이 지원됩니다. 자세한 내용은 장치 잠금 참고
사항을 참조하십시오.
ObscuredPrefs pro-tips:
• PP에서 OP로 쉽게 마이그레이션할 수 있습니다. 프로젝트의
PP 항목을 OP로 바꾸기만 하면 됩니다. 그러나 ACTk 클래스
에서 PP를 OP로 바꾸지 마십시오)! OP는 PP로 저장된 모든
데이터를 자동으로 암호화합니다. 첫 번째 읽기. 원래 PP 키는
기본적으로 삭제됩니다. PreservePlayerPrefs 플래그를 사용하
여 보존할 수 있습니다. 에이러한 경우 PP 데이터는 평소와 같
이 OP로 암호화되지만 원래 키는 유지되므로 다음을 사용하여
다시 읽을 수 있습니다. PP. API 예제 장면에서 동작하는 보존
플레이어Prefs를 볼 수 있습니다.
• 일반 PP와 OP를 혼합하여 사용할 수 있습니다(단, 다른 키 이
름을 사용해야 합니다!). 가려진 버전을 사용하여 저장하십시오.
민감한 데이터. 마이그레이션하는 동안 프로젝트의 모든 PP 호
출을 교체할 필요가 없으며 일반 PP가 OP에 비해 더 빠르게 작
동합니다.
• OP를 사용하여 로컬 순위표, 플레이어 점수, 돈 등과 같은 적절
한 양의 데이터를 저장하고 저장에 사용하지 마십시오.
맵 배열, 자체 데이터베이스 등과 같은 데이터의 거대한 부분 -
이를 위해 ObscuredFile 또는 ObscuredFilePrefs를 사용하십시오.
• 예를 들어 ArrayPrefs2와 같이 일반 PlayerPrefs를 확장하는 데
큰 기여를 했습니다. OP 수이러한 클래스에서 PP를 쉽게 대체하
여 저장된 모든 데이터를 안전하게 만듭니다.
IMPORTANT:
• OP는 모든 데이터를 암호화 및 복호화하므로 일반 PP에 비해
느리게 작동한다는 점에 유의하십시오. 일부 추가 리소스를 소
비합니다. Performance Obscured Tests 구성 요소를 사용하여
직접 확인하십시오. API 예제 장면의 PerformanceTests 게임 개
체.
• 내부를 적절하게 지우려면 PlayerPrefs.DeleteAll() 대신
ObscuredPrefs.DeleteAll()을 사용하여 모든 기본 설정을 제거하
십시오.
그리고 DeleteAll() 호출 후에 가려진 새 환경설정을 저장할 때
데이터 손실을 방지합니다.
ObscuredPrefs / PlayerPrefs editor window
ACTk includes helpful Editor Window – Prefs Editor.
Use it to edit your PlayerPrefs and ObscuredPrefs in Unity Editor.
Open it via menu command:
Tools > Code Stage > Anti-Cheat Toolkit > Prefs Editor as Tab
(utility window mode also available)
빠른 둘러보기:
• "+" 버튼: add new pref - 유형 선택, 선택적으로 암호화 활성화,
키 및 값 설정, 확인 버튼 누르기
• "새로 고침" 버튼: 모든 기본 설정 및 업데이트 목록 다시 읽기
• "Key Descending" - 정렬 유형, 기타 가능한 값: Key Ascending,
Type, Obscurance
• 검색 필드 - 입력을 시작하기만 하면 지정된 텍스트가 포함된
이름의 레코드를 필터링합니다.
• 페이징이 있는 ObscuredPrefs 및 PlayerPrefs 목록(페이지당 50
개의 레코드 표시)
• 기록 분석:
• "X" 버튼 - 기본 설정에서 레코드 삭제
• "S" 버튼 - 변경 사항을 prefs 저장소에 저장합니다.
• "E" / "D" 버튼 - 기본 설정 암호화/복호화(가려진 기본 설정은
녹색으로 표시됨)
• "..." 버튼 - 클립보드에 기본 설정 복사와 같은 추가 작업
• 키 및 값 필드를 통해 pref의 키 및/또는 값을 변경할 수 있습니
다(pref에 편집 가능한 유형이 있는 경우).
• 유형 레이블은 기본 유형을 표시합니다.
• 그룹 작업을 위한 하단의 일부 버튼(명확한 이름 포함)
• 덮어쓰기 확인이 있음
• 엄청난 양의 prefs(1k 이상)로 작업하는 경우 prefs 구문 분석 진
행률 표시줄이 있습니다.
• Win, Mac, Linux에서 작동
Prefs Editor는 Unity가 필요에 따라 사용하는 몇 가지 표준 환경
설정(예: UnitySelectMonitor, UnityGraphicsQuality 등)을 무시합
니다.
Windows에서 편집기 및 독립 실행형 플레이에 저장된 환경설정
에 유의하십시오.
Common Device Lock feature notes
ObscuredPrefs, ObscuredFile 또는 ObscuredFilePrefs와 함께 장치
잠금 기능을 사용할 때 다음 사항을 고려하십시오.
• DeviceLockSettings 속성을 사용하면 저장된 데이터를 현재 장치
에 잠글 수 있습니다. 이것은 저장을 방지하는 데 도움이 될 수 있
습니다
한 장치에서 다른 장치로 이동하는 게임(100% 게임 진행 또는 구
매한 게임 내 상품으로 저장 예시).
경고: iOS에서는 위험할 수 있습니다! iOS에서 영구 장치 ID를 얻
는 안정적인 방법은 없습니다. 따라서 사용을 피하거나
DeviceIdHolder.DeviceId와 함께 사용하여 고유한 장치 ID(예: 사용
자 이메일)를 설정합니다.
세 가지 다른 수준의 데이터 잠금 엄격성을 지정할 수 있습니다.
없음: 잠긴 데이터와 잠금 해제된 데이터를 모두 읽을 수 있으며 저
장된 데이터는 잠금 해제된 상태로 유지됩니다.
소프트: 잠긴 데이터와 잠금 해제된 데이터를 모두 읽을 수 있지만
저장된 모든 데이터는 현재 장치에 잠깁니다.
Strict: 현재 장치 데이터에 잠긴 읽기만 가능합니다. 저장된 모든 데
이터는 현재 장치에 잠깁니다.
자세한 내용은 API 문서의 DeviceLockSettings 설명을 참조하세요.
Android 사용자: 이 기능을 사용하지 않는 경우 아래 문제 해결 섹션
을 참조하세요.
• DataFromAnotherDeviceDetected 이벤트를 수신하여 다른 장치에서
데이터를 감지합니다. ObscuredPrefs에서 호출
ObscuredFile \ ObscuredFilePrefs에서 한 번(세션당) – 파일을 읽을
때마다 호출합니다.
• DeviceLockLevel.Strict를 사용하면 기본적으로 다른 장치에서 저장한
내용을 읽을 수 없습니다. 당신은 줄일 수 있습니다
DeviceLockSettings.DeviceLockTamperingSensitivity를 낮음(탐지 이
벤트가 계속 실행됨) 또는 비활성화됨(이벤트가
해고되지 않음). 장치 ID가 예기치 않게 변경된 경우 데이터를 복원하
는 데에도 사용할 수 있습니다.
• 장치 ID에 처음 액세스하면 일부 플랫폼에서 CPU 스파이크가 발생하
여 처음으로 데이터를 로드하거나 저장합니다. 이를 방지하려면
DeviceIdHolder.ForceLockToDeviceInit()를 호출하여 첫 번째 데이터
로드 시 스파이크를 방지하십시오.
/ 장치 잠금이 활성화된 상태로 저장합니다. 표시하는 동안 원하는 시
간에 장치 ID를 강제로 가져오려면 이 방법을 사용하십시오.
로딩 페이드 또는 스플래시 화면과 같은 정적입니다.
• DeviceIdHolder.DeviceId 속성을 사용하여 장치 ID를 명시적으로 설정
합니다. 이것은 고유한 사용자 ID로 저장을 잠그는 데 유용할 수 있습
니다.
(또는 이메일) 서버 측 승인이 있는 경우. 일관된 장치 ID를 얻을 수 있는
방법이 없기 때문에 iOS에 가장 적합합니다(iOS에서 7+), 우리에게 있는
것은 공급업체 및 광고 ID뿐이며 둘 다 변경될 수 있고 제한 사항이 있습
니다.
Code obfuscation and overall code protection notes
ACTk는 소스 코드를 난독화하거나 보호하지 않으므로
모든 ACTk 기능을 사용하고 있습니다.
따라서 가능하면 좋은 코드 난독화 도구와 IL2CPP 스크립팅
백엔드를 모두 사용하는 것이 좋습니다.
컴파일된 애플리케이션 코드를 분석하고 변경하기가 훨씬
더 어렵습니다.
IL2CPP는 Mono의 IL 바이트코드가 모든 IL 역전 도구를 쓸모
없게 만드는 경우 대신 메타데이터가 포함된 원시 바이너리
코드를 생성합니다.
(dnSpy와 같은) 메소드 바디의 좋은 디컴파일을 얻는 것을
훨씬 더 어렵게 만듭니다.
비싸고 사용하기 쉽지 않은 네이티브 디스어셈블러 및 디컴
파일). 부수적으로, 그것은 또한 완전히 방지
Mono ApplicationDomain에 관리되는 어셈블리의 주입.
메타데이터는 제한된 반사 목적으로 생성되며 메서드 코드
없이도 IL 어셈블리를 구성할 수 있습니다.
그러나 모든 네임스페이스, 클래스, 필드 등과 함께 치터는
IL2CPP Dumper와 같은 도구를 적극적으로 사용하여 IL을
재구성합니다.
전체 코드 구조를 보기 위한 어셈블리.
그렇기 때문에 이름 난독화 기능이 있는 우수한 코드 난독화
기로 IL2CPP를 보완하는 것이 매우 중요합니다.
Unity의 빌드 프로세스에 통합되어 있으며 IL2CPP가 빌드하
기 전에 코드를 난독화합니다. 그러한 경우
대부분의 IL2CPP 메타데이터는 쓸모없는 이름으로 엉망이 되
어 재구성된 IL 어셈블리를 리버스 엔지니어링 및 분석하기 매
우 어렵게 만듭니다.
무료 코드를 포함하여 주변에 좋은 코드 난독화 도구가 많이
있지만 다음과 제대로 통합되지는 않습니다.
Unity, 그렇기 때문에 Asset Store에서 Obfuscator 플러그인을
살펴보는 것이 좋습니다(이 플러그인에 대해 더 읽어보기
타사 섹션에서).
또한 특정 플랫폼 및 사용 사례에 대한 많은 기본 보호기가
있습니다. 네이티브 사용을 고려하십시오
가능한 경우 보호 계층을 추가하여 해커 기술에 대한 요구 사
항을 증가시킵니다.
애플리케이션을 편집하거나 리버스 엔지니어링하려고 합니다
(예: Denuvo, VMProtect 등).
어쨌든 민감한 부분이 있는 경우 코드가 정품이고 변조되지 않
았는지 항상 확인하는 것이 좋습니다.
클라이언트 측의 코드(즉, 해커가 도달할 수 없는 서버 측이 아
님) 및 ACTk는 다음을 사용하는 데 도움이 됩니다.
코드해시생성기.
코드 무결성 검증
중요한:
• 현재까지는 Android 및 Windows PC 빌드만 지원됩니다.
• 고급 Unity 개발자의 경우 대부분 추가 코딩이 필요하므로
코드 무결성 검증 이면의 일반적인 아이디어는 코드의 고유한
지문(해시)을 만드는 것입니다. 이 지문은 다음과 같이 변경됩
니다.
지문을 얻은 후 코드가 변경되는 즉시 해당 지문을 현재 지문
과 비교하기 위해 런타임 애플리케이션에 있는 지문입니다.
초보 치터를 상대해야 할 때 가장 간단한 방법으로 애플리케
이션에서 바로 비교하는 것으로 충분합니다.
경우에 따라 초보 치터가 눈치채지 못할 가능성이 높으므로
간단한 해시 비교부터 시작할 수 있습니다.
애플리케이션의 C# 코드에 있습니다.
그러나 치료의 특성으로 인해 고급 사기꾼에 의해 수표도 변경
될 수 있으므로 더 C# 코드 외부에서 유효성 검사를 수행하는
데 안전합니다. 여기에서 최선의 선택 - 서버 측 검증을 수행하
십시오. 당신은 현재를 보내 서버에 해시하고 처음에 생성된(허
용 목록에 있는) 해시와 비교하여 코드가 변경되지 않았는지 확
인합니다.
따라서 유효성 검사 절차는 일반적으로 참조 해시 가져오기, 실
제 런타임 해시 가져오기, 해시를 비교합니다. 아래에서 각 단계
에 대한 자세한 내용을 읽으십시오.
중요한:
• 해시 생성 작업(편집기 또는 런타임 모두)은 빌드의 각 파일에
대한 파일별 해시를 생성하고 가져옵니다.
해당 파일의 요약 해시.
• 따라서 파일별 해시는 편집기(CodeHashGeneratorPostprocessor
에서 가져옴)와 런타임(CodeHashGenerator에서 가져옴), 요약
해시는 경우에 따라 다를 수 있습니다(예: 런타임 앱이 AAB 번
들의 일부이며 내부에 플랫폼별 파일이 거의 없음).
• 권장 해시 비교 전략: 요약 해시를 먼저 비교하고 일치하지 않
으면 모든 런타임 확인 사전 생성된 파일별 해시 화이트리스트
에 대한 파일별 해시(그리고 알 수 없는 해시를 빌드 변경으로
처리 방아쇠).
CodeHashGenerator후처리기
이 편집기 스크립트를 사용하면 결과 빌드 파일에서 코드의 참조
해시를 생성할 수 있습니다.
HashesGenerated 이벤트를 수신하여 각 빌드 후에 결과 해시를
얻을 수 있습니다.
이 이벤트를 활성화하려면 ACTk 설정에서 "Generate code hash
on build completion" 옵션을 활성화하십시오. 결과
해시는 에디터 콘솔에도 출력됩니다(이벤트를 구독하지 않은 경
우에도).
내장 메뉴 항목을 통해 수동으로 외부 빌드 코드 해시를 가져올
수도 있습니다 : Tools > Code Stage > Anti-Cheat Toolkit
> Calculate external build hashes
또는 동일한 결과에 대해 Editor 코드에서 직접
CalculateExternalBuildHashes()를 호출할 수 있습니다.
이 포스트 프로세서는 런타임에 빌드를 실행하지 않고 해시를 생
성하도록 만들어졌습니다.
편집기 해시 생성에 문제가 있거나 Unity 빌드를 마친 후 코드를
후처리하는 경우 런타임에 참조 해시를 생성하려면 정품 빌드에
서 CodeHashGenerator를 사용하십시오.
사용 예를 참조
"Examples/Code Genuine Validation/Scripts/Editor"
CodeHashGenerator
이 런타임 스크립트를 사용하면 실행 중인 앱에서 바로 참조 또는
런타임 해시를 생성할 수 있습니다.
정적 이벤트 HashGenerated를 구독하고 Generate() 메서드를 호
출하여 해시 생성을 시작합니다. 기본 해시생성 코드는 플랫폼마
다 다르지만 일반적으로 다음과 같은 경우 별도의 스레드 또는 코
루틴에서 작동합니다.
생성 프로세스를 원활하게 만들고 CPU 스파이크를 방지하여 전반
적인 앱 성능 저하를 방지할 수 있습니다.
코드 무결성을 검증하기 위해 런타임에 참조 해시를 생성하여 나
중에 런타임 해시와 비교할 수 있습니다.
"Examples/Code Genuine Validation/Scripts/Runtime" 및
"Examples/Code Genuine"에서 사용 예를 참조하십시오.
Validation/GenuineValidator' scene.
일반적인 감지기 기능 및 설정
ACTk에는 다양한 치트를 감지하고 그에 따라 대응할 수 있도록
다양한 감지기가 포함되어 있습니다.
모든 감지기에는 몇 가지 공통 기능과 설정 프로세스가 있습니다.
일반적으로 감지기를 설정하고 사용하는 세 가지 방법이 있습니
다.
• Unity 에디터를 통한 설정
• 코드를 통한 설정
• 혼합 모드
Unity 에디터를 통한 설정
먼저 장면에 감지기를 추가해야 합니다. 이에 대한 두 가지 옵션
이 있습니다.
1. GameObject > Create Other > Code Stage > Anti-Cheat Toolkit
메뉴를 사용하여 장면에 감지기를 빠르게 추가합니다.
감지기가 있는 "Anti-Cheat Toolkit Detectors" 게임 개체가 장면
에 생성됩니다(존재하지 않는 경우).
이것은 감지기를 설정하는 데 권장되는 방법입니다.
2. 또는 다음을 통해 선택한 기존 게임 개체에 감지기를 추가할 수
있습니다.
Component > Code Stage > Anti-Cheat Toolkit 메뉴
다음 단계 – 추가된 감지기를 구성합니다. 모든 감지기에는 구성할
몇 가지 공통 옵션이 있습니다.
다음은 예를 들어 새로 추가된 주입 감지기입니다(일반적인 옵션
외에 다른 옵션이 없기 때문에).
Auto Start : 장면 로드 후 감지기가 자동으로 시작되도록 활성화합
니다. 그렇지 않으면 다음에서 명시적으로 시작해야 합니다.
코드(아래 세부 정보 참조). 이 기능을 사용하려면 아래에 설명된
감지 이벤트를 구성해야 합니다.
Auto Dispose : 탐지기가 치트 탐지 후 자동으로 스스로를 폐기하고
자체 구성 요소를 파괴하도록 합니다. 그렇지 않으면 감지기가 중지
됩니다.
Keep Alive: 감지기가 새로운 레벨(장면) 로드를 견딜 수 있도록 활
성화합니다. 그렇지 않으면 감지기는 새로운 수준의 부하에서 자동
처리됩니다.
Detection Event: 치트 감지 시 감지기가 실행하는 표준 Unity 이벤트입
니다.
권장 설정 – 모든 옵션을 활성화 상태로 유지하고 탐지를 위해
적절한 이벤트를 설정합니다.
이러한 경우 장면을 통해 이동하는 감지기가 항상 작동하고 감지 후
자체적으로 파괴됩니다. 감지 콜백이 있는 스크립트를 감지기가 있는
동일한 게임 개체에 첨부할 수 있습니다.
둘 다 장면 재장전에서 살아남을 것입니다.
Setup through the code
코드에서 설정하는 것을 선호하는 경우 - 모든 감지기의 정적
StartDetection(callback) 메서드를 어디에서나 한 번만 호출하면
됩니다.
기본 매개변수를 사용하여 해당 감지기를 실행하는 코드입니다.
감지기는 자동으로 장면에 추가됩니다. 존재하지 않습니다.
옵션을 조정하려면 정적 인스턴스 속성을 사용하여 구성 가능한
모든 필드와 속성에 바로 연결하십시오.
감지기 시작(장면에 이러한 감지기가 없으면 인스턴스가 null이
됨).
오버로드된 인수를 통해 초기 구성에 일반적으로 사용할 수 있는
감지기 옵션에 대한 일부 특정 StartDetection() 메서드, 초기 조
정에 사용할 수 있는 옵션을 파악하려면 감지기에 대한 API 문서
를 참조하세요.
다음은 주입 감지기의 예입니다.
// place this line right at the beginning of your .cs file!
using CodeStage.AntiCheat.Detectors;
// starts detection with specified callback
InjectionDetector.StartDetection(OnInjectionDetected);
// this method will be called on injection detect
private void OnInjectionDetected() { Debug.Log("Gotcha!"); }
Mixed setup
감지기를 사용하면 검사기의 구성과 수동 실행을 결합하여 혼합
방식으로 설정할 수 있습니다. 코드.
감지 이벤트를 유지하면서 Unity 편집기를 통한 설정 항목에 설
명된 대로 장면에 감지기를 추가할 수 있습니다.
설정에 설명된 대로 StartDetection(콜백) 메서드를 사용하여 코
드에서 수동으로 시작합니다. 코드 주제.
이 방법을 사용하면 감지기가 시작되어야 하는 순간을 제어할 수
있고 둘 다에서 감지기를 구성할 수 있습니다.
Inspector 및 시작하기 전에 Instance 속성을 통해 코드에서.
이러한 접근 방식을 사용하려면 감지기의 검사기에서 자동 시작
옵션을 비활성화해야 합니다.
또한 검사기에서 감지 이벤트를 채우고 StartDetection() 메서드(인
수 없이)를 사용하여 감지기를 시작할 수 있습니다.
[obscured type] 부정 행위 감지
Anti-Cheat Toolkit의 Obscured Cheating Detector를 사용하면
ObscuredPrefs를 제외한 모든 숨겨진 유형의 부정 행위를 감지
할 수 있습니다. (다음 섹션에서 다루는 자체 감지 메커니즘이
있음).
실행 중일 때 이 탐지기는 가려진 변수가 사기꾼을 위한 허니팟
으로 암호화되지 않은 가짜 값을 사용할 수 있도록 합니다. 그들
은 될 것입니다
원하는 값을 찾을 수 있지만 값을 변경하거나 고정하면 부정 행
위 감지를 트리거하는 것 외에는 아무 것도 하지 않습니다.
모든 감지기의 설정 및 공통 기능에 대한 자세한 내용은 위의 공
통 감지기 기능 및 설정 항목을 참조하십시오.
Epsilon: 치트 시도가 감지되기 전에 가짜와 실제 암호화된 변수
간의 최대 허용 차이.
기본값은 대부분의 경우에 적합하지만 사례에 맞게 자유롭게 조
정할 수 있습니다(일부 항목에 대해 거짓 긍정이 있는 경우 이유).
중요한:
• 부정 행위 탐지가 작동하지 않으며 탐지기가 작동하지 않는 동
안 가짜 암호화되지 않은 변수가 메모리에 존재하지 않습니다.
달리기. 따라서 ObscuredCheatingDetector를 사용하지 않거나
검사기에서 자동 실행을 비활성화하고 실행하지 않으면
코드에서 - 값이 메모리 검색기에 전혀 표시되지 않습니다.
스피드핵 감지
https://www.youtube.com/watch?v=I5EUjVbLaNY&index=4&list=PLbTYvIYxIXSj5p9qn3lcsoUc1R9KnSOIb
이러한 유형의 부정 행위는 사용하기가 정말 쉽고 주변의 모든
어린이가 시도할 수 있기 때문에 매우 인기가 있고 꽤 자주 사
용됩니다.
당신의 게임. Speed Hack을 사용하면 간단한 클릭 몇 번으로 다
양한 치트 도구에서 게임 속도를 높이거나 낮출 수 있습니다.
Anti-Cheat Toolkit의 Speed Hack Detector를 사용하면
Speed Hack 사용을 감지할 수 있습니다(Cheat Engine,
GameGuardian 등). 사용법도 정말 간단해요 ;)
모든 감지기의 설정 및 공통 기능에 대한 자세한 내용은 위의 일반
감지기 기능 및 설정 항목을 참조하십시오.
Interval: 감지 기간(초). 추가 오버헤드를 방지하려면 이 값을 1초 이
상으로 유지하는 것이 좋습니다.
Threshold: 가속 및 감속 모두에 대해 허용되는 속도 배율입니다. 가
능한 거짓을 줄이기 위해 도입되었습니다.
하드웨어 다양성으로 인해 타이머가 약간 더 빠르거나 느린 드문 경
우에 긍정적입니다. 기본값 0.2는 둘 다 허용
일반적으로 충분히 안정적이며 대부분의 알려진 타이머 문제를 해결
해야 하는 1.2x 및 0.8x 게임 속도.
Max False Positives: 매우 드문 경우(시스템 클럭 오류, OS 결함 등)
감지기가 가양성을 생성할 수 있습니다.
이 값을 사용하면 치트에 반응하기 전에 지정된 양의 스피드 해킹 감
지를 건너뛸 수 있습니다. 실제 과속 해킹 시 적용됨 – 감지기가 모든
검사에서 이를 감지합니다. 빠른 예:
Interval을 1로 설정하고 Max False Positives를 다음으로 설정했습니다.
5. 어플리케이션에 과속 해킹이 적용된 경우, 감지기는 그 후 ~5초 후
에 감지 이벤트를 발생시킵니다(Interval * Max False Positives +
time left until next check).
Cool Down: 연속으로 지정된 양의 성공적인 샷 후에 내부 가양성 카운
터를 재설정할 수 있습니다. 앱에 드물지만 주기적인 오탐지가 있는 경
우(예: 일정한 OS 타이머 문제의 경우) 유용할 수 있습니다.
오탐 카운터를 천천히 증가시키고 잘못된 스피드 핵 탐지로 이어집니다.
냉각 기능을 완전히 비활성화하려면 값을 0으로 설정하십시오.
귀하의 정보를 위해 "내부에서" 발생하는 몇 가지 예를 보여드리겠습니다.
다음 매개변수를 사용합니다.
Interval = 1, Max False Positives = 5, Cool Down = 30
Ex. 1: 응용 프로그램은 속도 해킹 없이 작동합니다. Detector는 1초마다
내부 검사를 실행합니다(간격 == 1). 만약 어떤 것이가 잘못되고 타이머
가 동기화되지 않으면 가양성 카운터가 1만큼 증가합니다. 30초 후(Interval
* Cool Down)
원활한 작업(OS 문제 없이) 거짓 긍정 카운터가 다시 0으로 설정됩니다.
원하지 않는 감지를 방지합니다.
Ex. 2: 애플리케이션이 시작되고 얼마 후 Speed Hack이 애플리케이션에
적용됩니다. Detector는 내부 검사를 실행합니다. 1초마다 가양성 카운터
를 1씩 올립니다. 5초 후(Interval * Max False Positives) 치트가 감지됩니다.
치터가 탐지를 피하려고 시도하고 3초 후에 스피드 해킹을 중지하면 30초
를 더 기다려야 합니다. 치트를 다시 적용하기 전에. 꽤 짜증난다. 그리고
Cool Down을 최대 60(1분 기다림). 그리고 치터는 Cool Down에 대해 전혀
알고 있어야 사용할 수 있습니다.
SpeedHackProofTime API
SpeedHackDetector와 함께 안정적인 타이머를 사용하기 위해
SpeedHackProofTime 클래스를 사용할 수 있습니다.
일반적으로 속도 해킹으로 고통받는 Unity의 Time.* 타이머.
고정* 물리 API를 제외한 Time.* API를 모방합니다.
SpeedHackDetector가 실행 중일 때만 작동하며 실제 속도 해킹
이 감지될 때까지 Unity의 타이머로 대체됩니다.
애니메이션 및 내부 시간 관련 계산이 감지된 속도 해킹에 영향
을 받지 않도록 하는 데 사용합니다.
"Examples/API Examples/Scripts/Runtime/InfiniteRotatorReliable"
스크립트 및 "API Examples" Scene.
중요한:
• SpeedHackProofTime은 경우에 따라 작동하지 않을 수 있습니
다. 신뢰할 수 있는 타이머에 도달할 법적 방법이 없을 때
(Chrome 브라우저의 프로세스와 같은 샌드박스 프로세스에서
발생할 수 있음)
Time cheating detection
플레이어는 종종 이러한 유형의 부정 행위를 사용하여 건물 진행
상황과 같은 게임의 일부 장기 프로세스 속도를 높입니다.
에너지 냉각 \ 몇 시간 또는 며칠 동안 복구합니다. 모든 부정 행
위자는 이러한 부정 행위를 활용하기 위해 수행해야 합니다. 변경
만 하면 됩니다.
게임을 "생각"하게 만드는 시스템 시간 또는 그가 새 항목을 만들
기 시작한 후 몇 시간이 지났습니다.
Anti-Cheat Toolkit의 Time Cheating Detector를 사용하면 온라인
타임서버를 사용하여 이러한 부정 행위를 감지할 수 있습니다. 당
신은 필요 이 감지기를 사용하려면 인터넷 연결이 필요합니다.
모든 감지기의 설정 및 공통 기능에 대한 자세한 내용은 위의 일반
감지기 기능 및 설정 항목을 참조하십시오.
URL: HEAD 또는 GET 요청에 올바른 날짜 응답 헤더 값을 반환할
리소스에 대한 절대 URL입니다.
WebGL에서 실행할 때 CORS 제한을 피하기 위해 필요한 경우
URL이 자동으로 현재 도메인으로 변경됩니다.
Method: 사용할 요청 메서드입니다. 헤드는 더 빠르고 적은 트래픽
을 사용하지만 일부 웹 서버는 HEAD를 너무 자주 처리할 수 있습
니다. 봇 활동 및 임시 차단 클라이언트로서의 요청. 문제가 있는 경
우 호환성이 더 높은 Get 메서드를 사용합니다.
Timeout Seconds: 요청을 중단하기 전에 서버 응답을 기다리는 시간.
Interval: 감지 기간(분). 트래픽을 줄이고 추가 시간을 줄이기 위해
너무 짧은 간격(1분 미만)을 사용하지 마십시오. 리소스 사용.
Real Cheat Threshold: 온라인과 오프라인의 두 후속 측정 간의 최대
허용 차이 시차(분). 차이가 이 값을 초과할 때 등록된 실제 치트입니
다.
Wrong Time Threshold: 온라인 시간과 오프라인 시간 사이에 허용되
는 최대 차이입니다. 차이가 이것을 초과할 때 확인 결과와 함께 값,
콜백 또는 이벤트 발생(스크립팅에서만 구독할 수 있음):
TimeCheatingDetector.CheckResult.WrongTimeDetected
중요한:
• 추가 이벤트인 CheatChecked를 구독하면 부정 행위 확인 결과에
대한 전체 정보를 얻을 수 있습니다. 감지를 시작할 때 스크립팅을
통해 설정할 수 있는 모든 콜백에 동일한 대리자가 사용됩니다.
• 치팅 여부를 확인하는 동안 인터넷이 없으면 CheckResult.Error와
함께 CheatChecked 이벤트가 발생합니다. 결과 인수 및
ErrorKind.OnlineTimeError 오류 인수, 검사는 건너뛰고 재시도를
위해 예약됩니다. 다시 지정된 간격. Detector는 인터넷 연결이 좋
지 않거나 때때로 연결되어 있는 장치에서 제대로 작동해야 합니다.
• 이 탐지기는 인터넷이 필요하기 때문에 분명히 모바일 플랫폼에서
다음과 같은 추가 권한 요청을 생성합니다. Android에 대한 인터넷
권한(일반적으로 자동 부여됨). 이 감지기가 필요하지 않고 제거하
려는 경우
추가 권한은 ACTk 설정 창에서
ACTK_PREVENT_INTERNET_PERMISSION을 확인하십시오.
• 현지 UTC 시간과 온라인 UTC 시간의 차이로 이어지는 수동 시스템
시간 변경은 부정 행위로 처리되지만 대신 잘못된 시간으로 처리됩
니다.
• ForceCheck* 메소드를 사용하여 수동으로 치팅 검사를 실행하고
결과를 얻을 수 있습니다(이러한 메소드의 API 문서 참조).
사용 예). 0 간격과 결합하여 감지기를 완전 수동 모드로 전환할 수
있습니다. 원하는 순간에 수동으로 검사를 실행합니다.
Wallhacks detection
https://www.youtube.com/watch?v=xSZkQv7TAgU&index=5&list=PLbTYvIYxIXSj5p9qn3lcsoUc1R9KnSOIb
일반적으로 "wall 해킹"으로 언급되는 몇 가지 다른 치팅 방법이
있습니다. 플레이어는 이를 통해 볼 수 있습니다.
투명하거나 와이어 프레임 벽은 유령처럼 벽을 통과할 수 있고
벽을 통해 쏠 수 있습니다.
ACTk에는 이 모든 것을 다루는 WallHack Detector가 있습니다.
그것은 몇 가지 다른 모듈로 구성되어 있으며, 각각은 다른 종류
의 치트를 감지합니다.
WallHack Detector는 실행하는 동안 장면에 서비스 컨테이너
"[WH Detector Service]"를 생성하고 이를 가상 3x3x3 큐브 내의
샌드박스에서 설정에 따라 다른 항목을 생성합니다.
모든 감지기의 설정 및 공통 기능에 대한 자세한 내용은 위의 공
통 감지기 기능 및 설정 항목을 참조하십시오.
Rigidbody: 이 모듈을 활성화하여 Rigidbody 해킹을 통해 만들어진
"벽을 뚫고 걸어가는" 종류의 치트를 확인합니다. 장애를 입히다
캐릭터에 Rigidbody를 사용하지 않는 경우 리소스를 절약할 수 있
습니다.
Character Controller: 이 모듈을 활성화하여 Character를 통해 만들
어진 "벽을 뚫고 걸어가는" 종류의 치트를 확인합니다.
컨트롤러 해킹. 캐릭터 컨트롤러를 사용하지 않는 경우 일부 리소스
를 저장하지 않도록 설정합니다.
Wireframe: 이 모듈이 셰이더 또는 드라이버 해킹을 통해 만들어
진 "벽을 통해 들여다보는" 종류의 치트를 확인하도록 활성화합니다.
(벽은 와이어프레임, 알파 투명 등이 되었습니다.) 그런 것에 신경 쓰
지 않는 경우를 대비하여 일부 리소스를 저장하지 않도록 설정하십
시오. 치트.
참고: 런타임에 제대로 작동하려면 특정 셰이더가 필요합니다. 아래
에서 자세한 내용을 읽으십시오.
Wireframe Delay: 와이어프레임 모듈 검사 사이의 시간(1초~60초)입
니다.
Raycast: 이 모듈을 활성화하여 Raycast 해킹을 통해 만들어진 "벽을
뚫고 쏘는" 종류의 치트를 확인합니다. 비활성화
그러한 치트에 신경 쓰지 않는 경우를 대비하여 리소스를 절약하십
시오.
Raycast Delay: Raycast 모듈 검사 사이의 시간(1초에서 최대 60초).
Spawn Position: 장면에서 3x3x3 빨간색 와이어프레임 큐브로 표시
되는 동
적 서비스 컨테이너의 세계 좌표 (탐지기가 있는 게임 개체를 선택
하면 표시됨).
Max False Positives: 실제 감지 전에 연속으로 감지할 수 있습니다.
각 모듈에는 자체 감지 카운터가 있습니다. 그것 모든 치트 감지 시
증가하고 해당 모듈의 첫 번째 성공 샷에서 재설정됩니다(치트가 아
닌 경우 감지됨). 이러한 카운터 중 하나가 Max False Positives 값보
다 크면 감지기가 최종 실제 감지를 등록합니다.
와이어프레임 모듈 셰이더 설정
Wireframe 모듈은 후드 아래에 Hidden/ACTk/WallHackTexture 셰
이더를 사용합니다. 따라서 이러한 셰이더가 포함되어야 합니다.
런타임에 존재하도록 빌드에 넣습니다.
Hidden/ACTk/WallHackTexture가 없으면 런타임에 로그에 오류가
표시됩니다. 셰이더가 포함되어 있고 셰이더가 포함되지 않은
WallhackDetector를 실행할 때 편집기에 포함하라는 메시지가 표
시됩니다.
ACTk 설정 창을 통해 셰이더를 쉽게 추가하거나 제거할 수 있습니
다.
"자동 포함" 버튼을 눌러 Hidden/ACTk/WallHackTexture 셰이더를
Always Included에 자동으로 추가합니다. 셰이더 목록.
또한 두 번째 버튼("수동으로 포함")을 눌러 프로젝트의 그래픽 설
정을 열고 셰이더를 추가할 수 있습니다.
항상 포함된 셰이더 목록을 수동으로
목록에 셰이더를 수동으로 추가하려면:
• 목록에 요소를 하나 더 추가합니다.
• 비어 있는 새 요소 옆에 있는 전구를 클릭합니다(아래 이미지의
빨간색 화살표 참조).
• 열린 창에서 "wallhack"을 검색하고 두 번 클릭하여
WallHackTexture를 선택합니다. 이것이 와이어프레임 모듈 설정을
위한 것입니다.
WallHack Detector and IL2CPP notice
IL2CPP로 빌드할 때 Unity 엔진 스트리핑이 시작되어 때때로
오탐지로 이어지는 WallHack Detector에 의해 사용되는 것들을 제거
하십시오. 이를 방지하려면 자동 link.xml을 활성화해야 합니다.
ACTk 설정에서 생성(WallHack Detector 섹션 아래):
중요한:
• Wallhacks는 일반적으로 데스크톱 FPS 게임에 적용되는 아주 특정한
종류의 치트이므로 게임에 문제가 생길 수 있습니다.
탐지에는 상당한 양의 추가 리소스가 필요하기 때문에 탐지기를 사용
하기 전에 그들로부터.
• ACTk 설정에서 ACTK_WALLHACK_DEBUG 조건부 컴파일 기호를 활성
화하여 서비스 개체의 렌더러를 게임에서 볼 수 있습니다. 또한 결과
텍스처의 OnGUI 출력을 활성화합니다.
와이어프레임 모듈. 이 기호는 개발 빌드 또는 편집기에서만 작동합니
다.
• 서비스 컨테이너 내의 모든 개체는 "Raycast 무시" 레이어에 배치되며
기본적으로 렌더러를 비활성화합니다.
• 3x3x3 서비스 샌드박스의 충돌을 피하기 위해 Spawn Position을 비어
있고 격리된 공간으로 설정하는 것이 중요합니다.
오탐으로 이어지는 개체와 개체 오작동.
• 또한 감지기가 지속적으로 객체를 생성 및 이동할 수 있고 물리학을 사
용하고 다른 설정에 따라 실행 중 샌드박스에서 계산.
Managed DLL Injection detection
https://www.youtube.com/watch?v=xrJbzvG7WJo&index=6&list=PLbTYvIYxIXSj5p9qn3lcsoUc1R9KnSOIb
중요 #1: Mono Android 및 Mono PC 빌드에서만 작동합니다!
중요 #2: IL2CPP 빌드에서는 어셈블리 주입이 불가능합니다. 전용 코드
보호 섹션에서 자세히 읽어보세요.
중요 #3: 오탐을 유발하는 특정 어셈블리로 인해 Editor에서 비활성화되
었습니다. ACTK_INJECTION_DEBUG 기호를 사용하여 Editor에
서 강제 실행합니다.
경고: 대상 장치에서 앱을 테스트하고 주입 감지기에서 오탐지가 없는지
확인하십시오. 그러한 문제가 있는 경우 시도하십시오.
감지된 어셈블리를 화이트리스트에 추가합니다(아래에서 다룹니다).
이러한 종류의 치팅은 다른 사람들만큼 인기가 없지만 Unity 앱에 여전히
사용되므로 무시할 수 없습니다. 구현 이러한 주입, 치터는 고급 기술이
필요하므로 많은 사람들이 숙련된 사람들로부터 치트 인젝터를 구입합니
다.
특수 포털. 무언가를 주입하는 가장 쉬운 방법 중 하나는 모노 어셈블리
주입기 또는 유사한 소프트웨어를 사용하는 것입니다. 일부 견과류 녀석
들이를 위해 Cheat Engine의 Auto Assemble을 사용하십시오. 치트엔진
이 얼마나 멋진지 보이시나요? ☺
Anti-Cheat Toolkit의 주입 감지기를 사용하면 관리되는 어셈블리(DLL)를
앱에 주입할 때 반응할 수 있습니다.
런타임에서 사용하기 전에 ACTk 설정에서 활성화해야 합니다(모노 주입
감지기 지원 확인란 추가). 모든 감지기의 설정 및 공통 기능에 대한 자세
한 내용은 위의 일반 감지기 기능 및 설정 항목을 참조하십시오.
이 감지기에는 일반적인 옵션을 제외하고 조정할 추가 옵션이 없습니다
(참고, 코드에서 시작하면 문자열 인수를 받아들이는 콜백 – 감지 원인).
고급 치트를 감지하는 간단한 방법!
주입 감지기 내부(고급)
몇 가지 통찰력을 제공하기 위해 중요한 주입 감지기 "under the hood"
주제에 대해 몇 마디 말씀드리겠습니다.
일반적으로 모든 Unity 앱은 세 가지 어셈블리 그룹을 사용할 수 있습니
다.
• 시스템 어셈블리: System.Core, mscoree, UnityEngine 등
• 사용자 어셈블리: DOTween.dll과 같은 타사 어셈블리를 포함하여 프로
젝트에서 사용할 수 있는 모든 어셈블리(어셈블리
훌륭한 DOTween 트위닝 라이브러리) 또는 외부 패키지의 어셈블리 +
어셈블리 Unity 생성
귀하의 코드 - Assembly-CSharp.dll, 어셈블리 정의 어셈블리 등
• 런타임 생성 및 외부 어셈블리. 일부 어셈블리는 리플렉션을 사용하여
런타임에 생성되거나 로드될 수 있습니다. 외부 소스(예: 웹 서버)에서.
이것은 일반적으로 드문 경우입니다.
주입 감지기는 앱에서 외부 어셈블리를 감지하기 위해 신뢰할 수 있는
모든 유효한 어셈블리에 대해 알아야 합니다. 자동으로 처음 두 그룹을
다룹니다. 마지막 그룹은 수동으로 다루어야 합니다(아래 참조).
Detector는 허용된 어셈블리를 건너뛰기 위해 화이트리스트 접근 방식
을 활용합니다. 빌드할 때 자동으로 이러한 목록을 생성합니다.
응용 프로그램을 만들고 빌드에 포함합니다(ACTk 설정에서 주입 감지
기 활성화 확인란을 선택한 경우). 창문).
이 화이트리스트는 두 부분으로 구성됩니다.
• 프로젝트에 사용된 어셈블리의 동적 화이트리스트(첫 번째 및 두 번째
그룹 포함)
• 사용자 정의 화이트리스트(세 번째 그룹, 아래 세부 정보 참조).
대부분의 경우 설정에서 주입 감지기 지원을 활성화하고 장면에서 설정
하는 것 외에는 아무 것도 해서는 안 됩니다.
\ 코드가 제대로 작동하도록 합니다.
그러나 프로젝트가 외부 소스에서 일부 어셈블리를 로드하는 경우(이러
한 어셈블리가 프로젝트 자산) 또는 런타임에 어셈블리를 생성하는 경우
탐지기에 이러한 어셈블리에 대해 알려야
거짓 긍정. 이러한 이유로 사용자 정의 화이트리스트 편집기가 구현되었
습니다.
사용자 정의 화이트리스트를 채우는 방법
화이트리스트에 어셈블리를 추가하려면 다음의 간단한 단계를 따르십시
오.
• "Tools > Code Stage > Anti-Cheat Toolkit > Injection Detector White
list Editor" 메뉴를 사용하여 화이트리스트 편집기를 열거나
설정 창의 "허용 목록 편집" 버튼:
• 단일 파일("어셈블리 추가"), 재귀 폴더 스캔("어셈블리 추가")의 세 가지
가능한 옵션을 사용하여 새 어셈블리를 추가합니다.
폴더에서"), 수동 추가 - 전체 어셈블리 이름 채우기("수동으로 어셈블리
추가").
그게 다야!
감지된 어셈블리를 수동으로 추가하고 전체 이름을 모르는 경우 주입 감지
기에서 디버그를 활성화하기만 하면 됩니다. ACTk 설정 창에서
ACTK_INJECTION_DEBUG를 확인하고 감지기가 어셈블리를 포착하도록 합
니다. 당신은 전체를 볼 수 있습니다 콘솔 로그의 이름, "[ACTk] 주입된 어셈
블리 발견:" 문자열 뒤. 이 기호는 개발 빌드 또는 편집자.
화이트리스트 편집기를 사용하면 목록에서 어셈블리를 하나씩 제거할 수 있
습니다(어셈블리 이름 옆에 작은 "-" 버튼 있음). 전체 화이트리스트도 지웁
니다.
사용자 정의 화이트리스트는 다른 모든 설정과 함께
ProjectSettings/ACTkSettings.asset 파일에 저장됩니다.
중요한:
• 원하는 경우 주입 예에 대한 인보이스 ID를 이메일로 보내주십시오(이 문서
끝에 있는 지원 연락처 참조). 야생에서 InjectionDetector를 사용해보십시오.
• ACTk에서 ACTK_INJECTION_DEBUG_VERBOSE 및
ACTK_INJECTION_DEBUG_PARANOID 옵션을 확인할 수 있습니다.
추가 디버그 정보에 대해 이러한 컴파일 기호를 활성화하는 설정 창. 이 기호
는 다음에서만 작동합니다. 개발 빌드 또는 편집기.
타사 플러그인 통합 및 참고 사항
중요한:
ACTk를 지원하는 일부 타사 플러그인은 프로젝트에 ACTK_IS_HERE 조건부 기
호가 필요할 수 있습니다. ACTk 설정에서 활성화할 수 있습니다.
Obfuscator
Anti-Cheat Toolkit은 부정 행위를 방지하고 감지하는 다양한 방법을 제공합
니다. 또한 ACTk를 우수한 코드 보호로 보완하여 설정을 완료할 것을 강력히
제안합니다. 다음은 코드 리버스 엔지니어링의 난이도를 높이기 위해 제안하
는 두 가지 첫 번째 단계입니다.
• 가능하면 Mono 대신 IL2CPP를 사용하는 것이 좋습니다. 이렇게 하면 사기
꾼이 검사하고 분석하기가 더 어렵습니다. 당신의 코드. IL2CPP 빌드에는
일반적으로 ILSpy 등에서 디컴파일하는 IL 바이트코드가 없습니다. 그렇지만
사기꾼은 여전히 모든 코드(네임스페이스, 클래스 이름, 메서드 이름 등)의
메타데이터를 가지고 있습니다. 나쁜 데 사용. 그래서 두 번째 단계가 존재
합니다.
• obfuscator를 사용하여 클래스 이름, 메서드, 필드 등을 부정 행위자에게 의
미 없는 혼란으로 만드는 것을 고려하십시오. 그것은 것이다
코드 리버스 엔지니어링의 난이도를 극적으로 증가시킵니다.
고맙게도 상점에는 격차를 채우고 코드를 쉽고 원활하게 보호할 수 있는 멋
진 자산이 있습니다. Obfuscator, 갑자기 =) Unity용으로 만들어졌기 때문에
Unity 이벤트, 메시지, 코루틴 등에 대해 "knows" 있으므로 사용자가
ACTK_EXCLUDE_OBFUSCATION 기호를 적용해야 합니다(아래에서 이 기호에
대한 세부 정보 참조).
플레이메이커
현재 ACTk는 PlayMaker(PM)를 부분적으로 지원합니다. 패키지에서 사용할
수 있는 PM 작업은 거의 없습니다. 통합/PlayMaker.unity 패키지.
PM Actions Browser에 새 작업을 추가하려면 프로젝트로 가져오세요.
Scripts/PlayMaker/Examples 폴더에서 몇 가지 예를 참조하십시오.
ObscuredPrefs 및 ObscuredFilePrefs가 완전히 지원됩니다. 의 PlayerPrefs
섹션에서 Obscured * 작업을 찾을 수 있습니다. 액션 브라우저.
• ObscuredCheatingDetector를 제외한 모든 탐지기가 완전히 지원됩니다.
Anti-Cheat에서 탐지기 작업을 찾을 수 있습니다.
Actions Browser의 툴킷 섹션.
• PM에 대한 Basic Obscured 유형은 현재 지원되지 않습니다. PM은 새로운
변수 유형을 추가하는 것을 허용하지 않습니다. 하지만 그것은
손으로 통합할 수 있습니다. kreischweide의 예와 설명이 있습니다.
Behavior Designer
현재 ACTk는 Opsive Behavior Designer(BD)를 완벽하게 지원합니다.
BD 작업이 거의 없습니다(액션 및 조건부)
패키지에서 사용 가능한 SharedVariables:
Integration/BehaviorDesigner.unitypackage. Anti-Cheat Toolkit을 BD와
통합하려면 프로젝트로 가져오세요.
Scripts/BehaviorDesigner/Examples 폴더에서 몇 가지 예를 참조하십시오.
Other third-party plugins with ACTk support
There are some other third-party plugins with ACTk support:
• Mad Level Manager: ACTk is used as storage backend.
• Stan’s Assets: Android Native Plugin and Ultimate Mobile plugins.
Please, let me know if you wish to see your plugin here.
Troubleshooting
• 업데이트 후 오류가 있습니다.
업데이트 문제를 방지하려면 이전 버전
(전체 CodeStage/AntiCheatToolkit 폴더) 업데이트된 ACTk 패키
지를 프로젝트로 가져오기 전에.
• 탐지기 중 하나에 대해 오탐지 또는 기타 오작동이 있습니다.
코드를 통해 장면 감지기에서 기존을 시작하는 경우
StartDetection() 메서드를 사용하고 있는지 확인하십시오.
Awake 또는 OnEnable 단계가 아니라 MonoBehaviour의 Start()
단계에서. InjectionDetector를 제외한 모든 검출기
(원인이 있는 콜백이 있기 때문에)
ACTK_DETECTION_BACKLOGS 플래그를 활성화하면 감지에 대한
세부 정보를 인쇄합니다.
ACTk 설정 창. 이 플래그를 사용하여 개발 빌드에서 생성된 로그
와 함께 잘못된 긍정을 보고하십시오. 가능하면 활성화됩니다.
• InjectionDetector 오탐지가 있습니다.
게임에서 사용하는 모든 외부 라이브러리를 화이트리스트에 추
가했는지 확인하십시오(메뉴: Tools > Code Stage > Anti-Cheat
Toolkit > Injection Detector Whitelist Editor). 이 화이트리스트
를 채우는 방법은 사용자 정의 화이트리스트를 채우는 방법 섹션
을 참조하십시오. 위에. 도움이 되지 않으면 저에게 연락하십시오.
• WallHackDetector 오탐지가 있습니다.
감지기의 생성 위치를 올바르게 구성했는지 확인하고 감지기의
서비스 개체가 게임의 모든 개체와 교차합니다. 또한 Ignore
Raycast 레이어가 레이어에서 자신과 충돌하는지 확인하십시오.
Edit > Project Settings > Physics의 Collision Matrix.
WallHackDetector는 모든 서비스 객체를 Ignore에 배치합니다.
Raycast 레이어는 게임 개체와의 불필요한 충돌을 피하고 각 개
체와 이러한 개체를 충돌시키는 데 도움이 됩니다.
다른. 그렇기 때문에 Ignore Raycast 레이어가 자체적으로 충돌
하는지 확인해야 합니다.
• WallHackDetector에서 '클래스 *가 존재하지 않기 때문에 컴포
넌트를 추가할 수 없습니다' 오류가 발생합니다.
WallHackDetector는 BoxCollider, MeshCollider, CapsuleCollider,
Camera, Rigidbody, CharacterController, MeshRenderer. 이러한
오류는 해당 구성 요소 중 하나가 제거될 때 나타날 수 있습니다.
~에 의해
IL2CPP 스트립 엔진 코드 옵션. 구성 요소가 벗겨지는 것을 방지
하기 위해 모든 장면의 모든 게임 개체에 구성 요소를 추가할 수
있습니다.
빌드에 있거나 이러한 link.xml 파일을 Assets 폴더의 아무 곳에나
넣습니다.
<linker>
<assembly fullname="UnityEngine">
<type fullname="UnityEngine.BoxCollider" preserve="all"/>
<type fullname="UnityEngine.MeshCollider" preserve="all"/>
<type fullname="UnityEngine.CapsuleCollider" preserve="all"/>
<type fullname="UnityEngine.Camera" preserve="all"/>
<type fullname="UnityEngine.Rigidbody" preserve="all"/>
<type fullname="UnityEngine.MeshRenderer" preserve="all"/>
<type fullname="UnityEngine.CharacterController" preserve="all"/>
</assembly>
</linker>
ACTk는 이 경우를 자동으로 처리하고 재생 모드에서 감지하여
경고하고 가능한 설정을 엽니다. 자동 link.xml 파일 생성을 활성
화합니다(ACTK_WALLHACK_LINK_XML 조건부 컴파일 기호 사용).
• Android에서 READ_PHONE_STATE 권한 요구 사항을 제거하려
면 어떻게 해야 합니까?
ObscuredPrefs / ObscuredFile / ObscuredFilePrefs에서
Device Lock 기능을 사용하지 않고 Android를 빌드하는 경우
응용 프로그램을 제거하려면 ACTk 설정 창에서
ACTK_PREVENT_READ_PHONE_STATE를 확인하는 것이 좋습
니다.
Android에서 READ_PHONE_STATE 권한이 필요합니다. 그렇지
않으면 ACTk를 잠그려면 이 요구 사항이 필요합니다. 장치에
저장합니다.
• Android에서 인터넷 권한 요구 사항을 제거하려면 어떻게 해
야 합니까? TimeCheatingDetector를 사용하지 않는 경우
ACTk에서 ACTK_PREVENT_INTERNET_PERMISSION을 확인하
는 것이 좋습니다.
Android에서 인터넷 권한 요구 사항을 제거하는 설정 창. 그렇
지 않으면 이 요구 사항이 ACTk가 시간 속임수를 감지하도록
합니다.
• ACTk를 사용할 때 obfuscator가 Unity 빌드를 중단합니다.
Unity의 메시지, Invoke() 및
이름으로 메서드를 지정하고 난독화 도구가
System.Reflection.ObfuscationAttribute 속성과 호환됩니다.
부담 없이
ACTk 설정 창에서 ACTK_EXCLUDE_OBFUSCATION을 확인하
여 [Obfuscation(Exclude = true)] 속성을 추가합니다.
그러한 방법. 도움이 되지 않으면 저에게 연락하십시오.
• 아주 오래된 버전에서 ACTk를 업데이트했는데 이제
ObscuredPrefs를 읽을 수 없습니다. ObscuredPrefs를 사용
중이고 ACTk를 업데이트하려면 다음을 고려하십시오.
ACTk >= 1.4.0은 데이터를 해독할 수 없습니다.
ACTk < 1.2.5에서 ObscuredPrefs로 저장되므로 버전 <
1.2.5에서 해당 버전으로 직접 점프하지 않도록 하십시오.
>= 1.4.0. prefs를 새 형식으로 자동 변환하거나 암호 해독을
받으려면 그 사이의 모든 버전을 사용해야 합니다.
코드를 추가하고 ACT >= 1.4.0에 대한 추가 폴백으로 가져옵
니다. 마이그레이션에 문제가 있는 경우 언제든지 문의하십시오.
저와 제가 원활하게 도와드리겠습니다.
• Assets/Resources/fndid.bytes 파일에 대한 병합 충돌이 있습
니다.
프로젝트에 버전 제어를 사용하고 있고 InjectionDetector를
사용하는 경우 병합 충돌이 발생할 수 있습니다. 그것의 좋아,
그 파일을 VCS의 무시 목록에 추가하기만 하면 됩니다.
fndid.bytes는 자동으로 다른 기계 생성
• 콘솔에 StackOverflowException 오류가 표시됩니다.
이러한 메시지가 표시되는 경우:
StackOverflowException: 요청한 작업으로 인해 스택 오버플로가 발생했습니다.
CodeStage.AntiCheat.ObscuredTypes.ObscuredPrefs.HasKey(System.String 키)(at
*CodeStage/AntiCheatToolkit/Scripts/ObscuredTypes/ObscuredPrefs.cs:*)
실수로 클래스뿐만 아니라 ACTk 클래스에서도 모든
PlayerPrefs.* 호출을 교체했을 가능성이 큽니다.
프로젝트에서 ACTk를 제거하고 다시 가져오기만 하면 문제가 사라집니다.
• ObscuredString.GetEncrypted() \ EncryptDecrypt() 메서드의
결과로 문자열이 잘리거나 너무 짧습니다. 가려진 문자열은 암
호화되는 동안 줄 바꿈, 줄 끝 등과 같은 특수 문자를 포함할 수
있습니다. 그래서 깨져 보일 수 있지만,
그러나 길이와 실제 내용은 여전히 괜찮습니다.
• 1.5.8.0 또는 이전 버전에서 ACTk를 업데이트한 후 손상된
ObscuredFloats / ObscuredDoubles가 표시됩니다.
이러한 유형은 1.6.0에서 새로운 형식을 얻었으며 저장되거나
직렬화된 모든 인스턴스는 새 형식으로 마이그레이션해야 합니다.
이렇게 하려면 다음을 사용하십시오.
• Unity 직렬화된 인스턴스 마이그레이션을 위한 메뉴 명령: 도구 > Code Stage > Anti-Cheat Toolkit > Migrate *
• GetEncrypted()로 저장된 런타임 API: ObscuredFloat/ObscuredDouble.MigrateEncrypted()
• 런타임을 활성화하기 위한 ACTk 설정 창의 조건부 컴파일 플래그 ACTK_OBSCURED_AUTO_MIGRATION
새 값으로 다시 작성될 때까지 인스턴스를 확인하고 자동 마이그레이션합니다. 감소
ObscuredFloat/ObscuredDouble 비트의 성능
1.5.1.0 또는 이전 버전에서 업데이트하는 경우 에 추가된 추가
마이그레이션 단계를 수행해야 합니다. 1.5.2.0 첫 번째 형식 변
경 후. 전체 *.*.*.* - 1.5.2.0 - 1.6.0을 만들 수 있도록 이전 ACTk
버전을 요청하십시오. 이주.
• 이전 Android에서 Time Cheating Detector의 로그에 오류 응
답 코드: 0 또는 java.io.EOFException 오류가 표시됩니다.
장치(Android 6 이전).
UnityWebRequest에는 오래된 Android 기기에서만 재현되는
알려진 버그가 있습니다. 요청 방법 설정 시도
이 버그를 해결하려면 HEAD 대신 GET을 사용하세요.
• Android 또는 WebGL의 StreamingAssets에서 ObscuredFile 또
는 ObscuredFilePrefs를 읽거나 쓸 수 없습니다. 이것은
이러한 플랫폼의 StreamingAssets 특성으로 인해 예상되는 동작
입니다(자세한 내용은 Unity 매뉴얼 참조). 일하다 이 경우
StreamingAssets 폴더에서 File.IO 액세스 가능한 위치
(예: Application.dataPath)로 파일을 복사하십시오.
ObscuredFile을 사용하여 읽기 전에 아이디어를 보여주기 위해
만든 이 간단한 예제와 같이.
호환성
아래 나열된 몇 가지 예외를 제외한 모든 기능은 알려진 플랫폼에서 완전히 작동해야 합니다.
• InjectionDetector는 Android Mono 및 독립 실행형 Mono 빌드에서만 작동합니다.
• CodeHashGenerator는 Android 및 Windows 독립 실행형 빌드에서만 작동합니다.
• ObscuredFIle는 지원 중단으로 인해 UWP .NET에서 작동하지 않습니다(UWP IL2CPP 지원).
플러그인은 독립 실행형(Win, Mac, Linux, WebGL), iOS, Android, UWP 변형 플랫폼에서 테스트되었습니다. 또한 고객은 다음 작업을 수행하는 것으로 보고했습니다. Windows Phone 8, Apple TV(thx atmuc). 특정 플랫폼에서 플러그인이 작동하지 않는 경우 알려주시면 도와드리고 수정하겠습니다. Apple 암호화 수출 규정 호환성 다음 ACTk 기능은 기본적으로 Apple의 수출 규정과 호환되지 않습니다.
• ObscuredFile 및 ObscuredFilePrefs
• ObscuredLong, ObscuredULong, ObscuredDouble 및 ObscuredDecimal 유형 앱에서 사용하는 경우 Apple App Store에 게시할 때 암호화를 사용하고 있음을 선언해야 합니다. 조건부 컴파일 기호 설정에서 ACTK_US_EXPORT_COMPATIBLE 옵션을 사용하여 이를 방지할 수 있습니다. 대칭 암호화를 위해 56비트를 초과하는 키 생성을 방지하므로 더 이상 해당되지 않습니다. 산업 보안국 상업 통제 목록의 범주 5 파트 2, 2.a.1.a의 암호화 정의, 수출 규정과 완벽하게 호환되므로 ACTk는 귀하가 애플리케이션에서 암호화를 사용하고 있다고 선언하도록 강요하지 않습니다. Apple App Store에 게시할 때. 그러나 다음과 같은 부작용이 있습니다. • 128비트 키가 있는 AES에서 RC2로 전환하여 ObscuredFile 및 ObscuredFilePrefs 암호화 강도 약화 56비트 키(데이터는 여전히 암호화되어 읽을 수 없음). • 부분 ObscuredLong, ObscuredULong, ObscuredDouble 및 ObscuredDecimal 가려짐이 약화되어 그렇지 않습니다. 일부 드문 경우에 완전히 암호화됩니다. ObscuredCheatingDetector는 어쨌든 그들을 주시할 것입니다.
ProGuard 공지
어떤 방식으로든 네이티브 바이너리를 변경하는 최적화
프로그램, 최소화 프로그램 및 난독화 프로그램을 사용하
는 경우 다음을 확인하십시오.
ACTk 네이티브 Android 라이브러리를 무시에 추가합니다.
예를 들어 다음 줄을 ProGuard 구성 파일에 추가합니다.
-클래스 net.codestage.actk를 유지합니다.** { *; }
'프로그래밍 > Unity' 카테고리의 다른 글
| Unity - Obfuscator 메뉴얼 (0) | 2021.12.30 |
|---|---|
| 스크롤 뷰 (Scroll View) 만들기 (0) | 2021.12.27 |
| Unity - n초 마다 실행시키기 매니저 (0) | 2021.11.19 |
| Unity 어드레서블 통빌드(풀빌드) 시 주의 (0) | 2021.10.28 |
| Unity 일정 시간 동안 목표 위치까지 이동 (0) | 2021.10.05 |
댓글