我是目前研究出海投放&變現(xiàn)業(yè)務(wù)的SL。《金鎖銀關(guān)護(hù)正道，秘法奇謀斷妄行》最近重溫了《三俠五義》，說話古風(fēng)古氣的，哈哈。抽空又來更新了，越來越懶了，而且感覺也沒得寫了，之后可能有空更新一下！最近看了粉絲們的評(píng)論區(qū)和私信，發(fā)現(xiàn)大家在防護(hù)驗(yàn)證的知識(shí)體系還是缺少一些基本功。除了我們內(nèi)部自己的平臺(tái)驗(yàn)證之外，其實(shí)不同的應(yīng)用商店也都提供了一些基礎(chǔ)功能幫助我們驗(yàn)證流量。我們可以用起來。對(duì)于營銷小伙伴了解一些也是很不錯(cuò)的。所以這期總結(jié)一下目前常見的平臺(tái)都如何配置這些套件和功能，這個(gè)功能可以自己做，也可以交給MMP（如果你沒有這個(gè)精力和資源的話，算是省心省力，沒有打廣告哦）。分三個(gè)平臺(tái)講：Google Apple AmazonGoogle License Verification Library（LVL）Google License Verification Library (LVL) 的主要作用是驗(yàn)證應(yīng)用的合法授權(quán)，以防止未經(jīng)授權(quán)的安裝。為了防作弊，Google LVL通過Google Play License Server進(jìn)行授權(quán)驗(yàn)證，應(yīng)用啟動(dòng)時(shí)會(huì)調(diào)用LVL，請(qǐng)求GP服務(wù)器進(jìn)行授權(quán)驗(yàn)證。在GP的服務(wù)器返回驗(yàn)證結(jié)果（LICENSED、NOT_LICENSED或ERROR）后，應(yīng)用會(huì)根據(jù)驗(yàn)證的結(jié)果決定是否允許此次運(yùn)行。https://developer.android.com/google/play/licensing/server-side-verificationhttps://developer.android.google.cn/google/play/licensing/client-side-verification.html#app-publishing為了防止破解或偽造授權(quán)信息，LVL采用了以下安全措施：(1) 響應(yīng)數(shù)據(jù)簽名Google Play的服務(wù)器返回的授權(quán)響應(yīng)帶有數(shù)字簽名，使用Google私鑰加密。作弊渠道無法偽造服務(wù)器響應(yīng)，因?yàn)樗麄儫o法偽造Google的簽名。在本地應(yīng)用中，LVL 需要用GP提供的公鑰驗(yàn)證簽名的真實(shí)性。
String signedData = response.getSignedData();?//?Google Play 返回的授權(quán)數(shù)據(jù)String signature = response.getSignature(); ?//?Google Play 返回的簽名boolean isValid = verifySignature(signedData, signature, PUBLIC_KEY);if?(isValid) {? ? // 授權(quán)通過}?else?{? ? // 可能是偽造的授權(quán)信息，拒絕訪問}
(2) 隨機(jī)化驗(yàn)證請(qǐng)求Google LVL在每次請(qǐng)求時(shí)會(huì)加入隨機(jī)數(shù) (nonce)，防止重放攻擊（Replay Attack）。這樣，即使作弊渠道試圖緩存上一次的授權(quán)響應(yīng)并重復(fù)使用，系統(tǒng)仍然能檢測到。
long?nonce =?new?SecureRandom().nextLong();?sendLicenseRequest(nonce);
Google LVL采用了Base64編碼和一定的混淆技術(shù)，防止黑客直接篡改授權(quán)數(shù)據(jù)。攻擊者不能直接修改響應(yīng)，否則簽名驗(yàn)證會(huì)失敗。ProGuard/R8：LVL推薦使用ProGuard或R8來混淆代碼，防止黑客反編譯應(yīng)用并繞過授權(quán)驗(yàn)證。自定義驗(yàn)證邏輯：Google 建議開發(fā)者不要直接使用 LVL 提供的默認(rèn)實(shí)現(xiàn)，而是修改和混淆授權(quán)邏輯，使得破解難度提高。除了LVL自帶的機(jī)制，我還建議開發(fā)者結(jié)合Google Play Integrity API進(jìn)行更嚴(yán)格的安全檢查。當(dāng)然MMP平臺(tái)也提供了一些簡化版本的服務(wù)，我們以Appsflyer為例：廣告主需要將配置好的property同步給Appsflyer的CSM。Appsflyer的CSM將會(huì)開啟測試模式（只標(biāo)記不檢出），如果數(shù)據(jù)穩(wěn)定的話，就可以同步到正式版了。1.Appsflyer需要購買Protect360服務(wù)后才能夠開啟驗(yàn)證。2.Appsflyer將這類型Fraud標(biāo)記的原因算作Bots。https://support.appsflyer.com/hc/en-us/articles/17329535522961-Setting-up-the-Google-License-Verification-Library-LVLApple App Store install validation官方說法如下：Apple App Store Install Validation是一種驗(yàn)證iOS應(yīng)用的安裝來源和合法性的機(jī)制，主要用于防止盜版、偽造安裝、未經(jīng)授權(quán)的運(yùn)行等情況。它可以確保應(yīng)用只在 App Store下載和安裝，而不是通過越獄設(shè)備、第三方商店或企業(yè)簽名的方式繞過授權(quán)。蘋果沒有提供SDK，Apple是利用自己的生態(tài)完成驗(yàn)證。主要包括以下三個(gè)環(huán)節(jié)：（1）Receipt Validation（收據(jù)驗(yàn)證）每個(gè)應(yīng)用都有一個(gè)receipt，用于驗(yàn)證應(yīng)用來源以及是否合法安裝，以及是否有合法的內(nèi)購。該收據(jù)包含設(shè)備ID、購買信息、Bundle ID等信息，并由Apple簽名。我們可以在應(yīng)用啟動(dòng)時(shí)驗(yàn)證收據(jù)，確保應(yīng)用是從Apple下載的，而不是從第三方來源sideload安裝的。一般收據(jù)會(huì)存儲(chǔ)在這里：
/var/mobile/Applications/{App?UUID}/StoreKit/sandboxReceipt
那么我們就可以用服務(wù)器在線驗(yàn)證：
import?requestsimport?base64
# 讀取 receipt 文件with?open("receipt",?"rb")?as f:? ? receipt_data = base64.b64encode(f.read()).decode()
# 發(fā)送到 Apple 服務(wù)器驗(yàn)證response = requests.post("https://buy.itunes.apple.com/verifyReceipt", json={? ??"receipt-data": receipt_data,? ??"password":?"your_shared_secret"})
# 解析返回的 JSON 結(jié)果print(response.json())
(2) App Store Server API（防止假安裝 & 內(nèi)購欺詐）用于檢測應(yīng)用安裝來源，并防止黑客利用偽造安裝數(shù)據(jù)獲取獎(jiǎng)勵(lì)（如廣告歸因作弊）。Apple提供App Store Server API，我們可以使用getTransactionHistory或getRefundHistoryAPI 來檢查用戶是否真的從應(yīng)用下載并購買了應(yīng)用或訂閱。這個(gè)API不會(huì)被篡改，可以有效檢測假裝安裝或偽造支付信息的情況。(3) Device Integrity Checks（設(shè)備完整性檢查）用于檢查設(shè)備是否越獄（Jailbroken），并檢測是否運(yùn)行在模擬器或被 Hook。
func?isDeviceJailbroken() -> Bool?{? ??let?paths = ["/Applications/Cydia.app",?"/Library/MobileSubstrate/MobileSubstrate.dylib",? ? ? ? ? ? ? ? ?"/bin/bash",?"/usr/sbin/sshd",?"/etc/apt"]? ??for?path?in?paths {? ? ? ??if?FileManager.default.fileExists(atPath: path) {? ? ? ? ? ??return?true? ? ? ? }? ? }? ??return?false}
Amazon Digital Rights Management APIAmazon沒有直接對(duì)應(yīng)Google License Verification Library (LVL)的官方SDK，但Amazon提供了Appstore SDK，其中的DRM (Digital Rights Management) API可以實(shí)現(xiàn)類似的功能。它允許廣告主檢查應(yīng)用是否是通過Amazon Appstore合法下載的，并防止盜版或未經(jīng)授權(quán)的使用。（可以重點(diǎn)防治某家！?。。?/span>首先，我們需要集成Amazon Appstore SDK，在應(yīng)用中添加 Amazon 提供的Appstore SDK（可從 Amazon Developer Console 下載）。https://developer.amazon.com/zh/docs/appstore-sdk/integrate-appstore-sdk.html然后在代碼中調(diào)用DRM API，就可以實(shí)現(xiàn)通過LicenseVerifier進(jìn)行驗(yàn)證了：
import?com.amazon.device.drm.LicensingService;import?com.amazon.device.drm.model.LicenseResponse;import?com.amazon.device.drm.LicensingListener;
public?class?MyActivity?extends?Activity?{? ??@Override? ??protected?void?onCreate(Bundle savedInstanceState) {? ? ? ??super.onCreate(savedInstanceState);? ? ? ??LicensingService.verifyLicense(new?LicensingListener() {? ? ? ? ? ??@Override? ? ? ? ? ??public?void?onLicenseValidated(LicenseResponse licenseResponse) {? ? ? ? ? ? ? ??if?(licenseResponse.getLicenseStatus() ==?LicenseResponse.LicenseStatus.LICENSED) {? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? } else {? ? ? ? ? ? ? ? ? ? // 未授權(quán)（盜版、無效賬戶等）? ? ? ? ? ? ? ? }? ? ? ? ? ? }? ? ? ? });? ? }}
之后把我們的應(yīng)用已上傳到Amazon Appstore，并啟用了DRM保護(hù)，就完成了全部操作啦。為了防止破解或偽造授權(quán)信息，DRM采用了以下安全措施：Amazon DRM服務(wù)器的響應(yīng)包含簽名數(shù)據(jù)，并使用Amazon的私鑰加密。應(yīng)用必須用Amazon提供的公鑰驗(yàn)證返回?cái)?shù)據(jù)的真實(shí)性，防止偽造授權(quán)信息。DRM授權(quán)信息與用戶的Amazon賬戶綁定，而不是僅僅存儲(chǔ)在本地設(shè)備上。每次驗(yàn)證時(shí)，Amazon服務(wù)器會(huì)檢查當(dāng)前設(shè)備是否屬于該賬戶，防止拷貝授權(quán)數(shù)據(jù)到其他設(shè)備使用。(3) 授權(quán)數(shù)據(jù)加密&反篡改Amazon DRM SDK會(huì)加密存儲(chǔ)授權(quán)信息，并采用校驗(yàn)機(jī)制，防止作弊渠道手動(dòng)修改本地授權(quán)數(shù)據(jù)。如果檢測到數(shù)據(jù)被篡改，應(yīng)用可以拒絕運(yùn)行。當(dāng)然，如果要驗(yàn)證IAP的話，也可以用Amazon IAP (In-App Purchasing) 進(jìn)行二次授權(quán)檢查，確保購買驗(yàn)證的安全性。關(guān)注我，獲取更多廣告投放變現(xiàn)知識(shí)！
