少し前まで、無料でジェイルブレイクをしなくてもアプリ内購入のアクティベーションに関するニュースは騒々しかった。 アイデアは簡単です。SSL証明書がシステムにインストールされ、カスタムDNSサーバーが登録されます。これにより、Appleサーバーにクラッカーサーバーにリクエストが送信されます。 クラッカーサーバーは購入を確認し、デバイスで正常にアクティブ化されます。 ニュースが発表された後、多くのパニックがあり、Appleは何かをして開発者にアプリケーションを保護する方法を伝える必要さえありました。 実際、問題は新しいものではなく、ジェイルブレイクされたデバイスでは、アプリ内購入を長期間無料で有効化することがすでに可能でした。 問題の解決策も新しいものではなく、Appleのドキュメントに記載されていますが、実際の実装に悩む人はいません。 このような保護の私のバージョンについては、以下で説明します。
アプリ内購入の仕組み
2つの可能なシナリオがあります。 シンプル：
デバイスは、開発者サーバーの追加の検証および参加なしで、アップルサーバーを介して購入をアクティブ化します。
複雑な：
開発者サーバーは、次のように購入プロセスに参加できます。
- 可能な購入のリストを送信します（ステップ2）。
- pokeyチェックを検証します（ステップ10〜11）。
- 追加のコンテンツへのアクセスを提供します（ステップ13〜14）。
手順10〜11に関心があるのは、 アップルサーバーによってチェックが書き込まれたのか、それとも偽物であるのかをデバイスが判断するのを支援できるのは、彼らのおかげです。
ここでは、Apple記事のソースがアプリケーションから直接チェックを検証するのに役立つことを追加する必要がありますが、この保護は信頼できない 検証サーバーへのリクエストをクラッカーサーバーのアドレスにリダイレクトすることを誰も気にせず、期待される応答を返します。
検証
Appleのサーバーでのみ購入領収書を検証できます。 これを行うには、HTTP POST要求内でbase64でエンコードされたチェック付きのJSONを送信します。
{
"receipt-data" : "(receipt bytes here)"
}
Appleサーバーの1つに：
- sandbox.itunes.apple.com/verifyReceipt-サンドボックスからのテスト購入用
- buy.itunes.apple.com/verifyReceipt-AppStoreからの購入用。
応答として、サーバーは検証ステータスを返し、検証が成功した場合は、チェックのデコードされたフィールドを返します。
{
"status" : 0,
"receipt" : { (receipt here) }
}
理論から実践へ
上記のメカニズムを理解すると、検証要求をAppleサーバーの1つに転送するプロキシアプリケーションをrubyで記述することは難しくありませんでした。 すぐに使用できるアプリケーションコードをGitHubに投稿しました。 私は改善とプルリクエストを喜んでいます。 リポジトリからのテストチェックを使用して、heroku（ https://receiptValidator.heroku.com/validate）でそれに触れることもできます。 チェックボックスサンドボックスを使用すると、正しい答えが表示され、それがない場合はエラーコードが表示されます。
アプリケーションでは、サーバーの応答を分析し、組み込み関数をアクティブにするか、疑わしいチェックで無視できるかを決定します。 興味があれば、次の記事でアプリケーション内の保護について書きます。
乾燥した結果
- サーバーを介した購入の検証により、アプリケーションが「特別」になり、ユニバーサルクラッカーが機能しなくなります。
- アプリケーションのハッキングは引き続き可能ですが、そのためにはアプリケーションを中断する必要があります。
- 誰かが時間を費やして購入をハッキングする場合、サーバーとの通信に暗号化を追加できます。
- Herokuでは無料で、便利なルビーホスティングとhttps暗号化を利用できます。
PS少し不un慎な自己PR：この防御は、 Galileo Offline Maps専用に作成され、昨日の朝AppStoreに登場したバージョン2.2で正常にテストされました。