Lamiyi

RiP Dev は、Kali で採用されているいくつかのテクニックとそれが iPhone 開発者にどのように役立つかについての詳細な説明を掲載しています。

-----
Kaliのアンチパイラシー発表以来、iPhoneアプリのクラッキング防止システムに関して、多くの質問、コメント、そしてその他のフィードバック（Ripdevチームへの非難の声も含む）が寄せられています。そこで、この記事ではKaliが採用している技術の一部と、Kali、その開発者、そしてRipdevで実際に何が起こっているのかを解説します。

まず、現在のiPhoneアプリケーションクラッキングシステムの仕組みについてご紹介します。これにより、私たちが直面する問題をご理解いただけます。クラッカーはApp Storeでアプリケーションを購入し、iPhoneで起動します。当初、アプリケーションの実行コードはAppleのDRMシステムによって保護されています。しかし、アプリケーションが起動すると、システムはすべてのキーを読み取り、保護されていないアプリケーションをRAMにロードします。

次に、クラッカーはデバッガーを使ってRAM内のアプリケーションを「停止」し、デバイスのRAM（暗号化されていないプログラムがロードされている場所）のイメージを作成します。次に、RAM情報を含むこのイメージをコンピュータにダウンロードし、クラッカーはIPAファイル（暗号化キーなしで動作する実行可能なiPhoneアプリ）を作成します。

Kali APには3つのモジュールがあり、それぞれがアプリ保護の独自のセグメントを担当しています。1つ目は「アンチデバッグ」です。これは、アプリケーションがデバッガ上で実行されないよう保護するサブシステムです。Kaliがアプリでデバッガの使用を検知した場合、アプリケーションはクラッシュする可能性があります。

しかし、クラッカーがデバッガーでアプリケーションを実行できたと仮定しましょう。すると、別のKaliサブシステムが「アンチダンプ」というアクションに突入します。前述のように、アプリケーションがAppleのDRMのみで保護されている場合、RAM上では基本的に保護されていない状態で実行されるため、アプリのコードをダンプするのは簡単です。しかし、アプリがKaliで保護されている場合、RAM上のコードは完全に完全な状態ではありません。実行コードは複数の段階を経て、最初に変更され、その後再びアセンブルされます。このプロセスは保護の整合性チェックと高度に統合されているため、たとえクラッカーがRAMイメージを入手したとしても、深刻な損傷を受け、プログラムは動作しなくなります。

既に述べたように、Kaliの3つ目のサブシステムである保護整合性チェックは、クラッキング攻撃を監視します。このサブシステムは、自身、アプリケーション全体、そしてアプリの様々な要素の3段階で動作します。後者を実現するために、Kaliは保護への侵入を防ぐ様々なチェックモジュールをランダムに統合します。

これらのサブシステムの緊密な統合により、Kaliはそれを利用するアプリケーションに対して一定レベルの保護を提供できます。だからこそ、Hackulousフォーラム（Kaliを利用するRipdevのアプリ「iPref」を試した後）で「保護性能は実際には悪くないようだ。一見したところでは、当分の間は突破口が見つからないだろう」という意見を読んだのは嬉しかったです。

Kaliを開発した開発者たちは、破られないシステムは存在しないことを十分に理解しています。ある人が書いたものでも、別の人が解読できる可能性があるのです（時間とリソースの問題です）。そのため、時間を持て余した10代の天才がKaliを解読する可能性は十分にあります。だからこそ、Kaliのコードは絶えず変化し、進化し続けているのです。Kaliを採用するアプリはそれぞれ異なる暗号化方式やその他の要素を採用しており、Crackulousのような自動ツールの開発は非常に困難な作業となるでしょう。

さて、Kaliの実装プロセスについてお話しましょう。いくつか懸念点がありましたが、Kaliはソースコードを必要としないため、心配する必要はありません。開発者がアプリケーションを作成し、App Storeへの提出準備が整うと、リリースバージョンをビルドし、Kali処理サーバーにアップロードします。Kaliサーバーでは、スクリプトによってアプリケーションが処理され、アプリを解析し、Kaliの要素を統合して保護されたバージョンがビルドされます。その後、開発者は署名を行い、App Storeにアップロードできます。Kaliで保護されたアプリケーションは、Appleの審査プロセスを経て承認されます（iPrefはその一例です）。

一部の開発者が懸念しているもう1つの問題は、Kaliで保護されたアプリケーションがユーザーのiPhoneでどのように動作するかということです。Kaliは完全に自律的なソリューションであり、サーバーを実行する必要がないため、ライセンスを確認したり、展開をカウントしたりするためにサーバーに電話をかけません。iPhoneから情報を転送することもありません（ユーザーの個人データを含む）。さらに、Kaliはクラックされたアプリケーション内から自分自身を検出した場合、何のアクションも実行しません（アプリはCrackulousによって処理された後、おそらくまったく実行されません）。つまり、KaliはユーザーのデータやiPhoneに損害を与えません。正当なユーザー（App Storeでアプリを購入した）にとって、このプロセスは他の正当なアプリと同様に完全にシームレスで透過的であり、アプリに保護されていることにまったく気付くことはありません。Kaliは基本的にアプリケーションのパフォーマンスに影響を与えず、実行には96KBのRAMのみを使用します。

もちろん、開発者たちはKaliが実際にクラックされた場合の対応を懸念しています。開発者がKaliを注文する際に署名する契約書には、Kaliは100%のクラック防止を保証するものではないと記載されていますが、一体誰がそんな保証をするのでしょうか？ ;) Ripdevが保証できるのは、Kaliを使用している特定のアプリケーションがクラックされた場合、システムは速やかに更新され、開発者は新しいバージョンのアプリケーションで更新されたKaliを使用できるということです（ただし、ハッカーが再びクラックするにはかなりの時間が必要です）。

Ripdevは甘い考えではなく、 Kaliがソフトウェアの著作権侵害を撲滅できるとは考えていません。多くの開発者がアプリケーションの売上を公開したり、Ripdevが要求するわずかな割合でさえもアプリの売上から得られる収益を分配したくないため、Kaliを使用しない選択をするのは明らかです（Kaliの価格設定に関するこちらのPDFをご覧ください）。そのため、依然として多くのアプリがクラックされ、インターネット上で共有されることになります。Kaliを使用しているアプリの中には、既にApp Storeに提出されているものもあります（ただし、アプリ名は公表できません）。また、Kaliを使用している弊社のアプリ「iPref」は、依然としてハッカーを困惑させています（一部のサイトで「クラック済み」として投稿されましたが、iPhoneにコピーしても動作しません）。Ripdevは、クラックされたアプリが「無料広告」として機能するという理論には賛同していません。「Lite」版のアプリは数多くありますが、あまり役に立ちません。したがって、開発者は他のアプローチを取るべきであり、Kaliはその一つとなる可能性があります。ぜひ Kali を詳しくご覧になり、今すぐアプリを保護するためにお試しください。
-----

続きを読む