私はゲームで取り組んでいます。私が使用している健全な資産の使用許諾契約書の要件の1つは、それらをエンドユーザーがアクセスできない方法で配布することです。だから、私はそれらをフラットファイルに集約し、それらを暗号化することを考えています。問題は、私が使用しているサウンドライブラリ（Hekkus Sound System）が 'char *'ファイルパスのみを受け入れ、ファイルの読み込みを内部的に処理することです。だから、もし私がそれを使い続ければ、私は暗号化を処理するためにstdioファイル関数をオーバーライドするか、何をするかを決める必要があります。これは可能だが、それは私を心配している。ウェブを見る私は心配しているプラットフォーム（Win32、Android、iOS）でこれをやっている不思議な不満の問題に遭遇している人々を見ている。cライブラリファイル関数をオーバーライドしますか？
これに対応するクロスプラットフォームライブラリが存在しますか。あなたが推奨するより良いアプローチがありますか？
通常のファイルの代わりに名前付きパイプを使用するオプションがありますか？そうであれば、読み込み用のファイルとしてサウンドライブラリにパイプを提示することができ、データを解読してパイプに書き込むことができます。問題はありません。 （名前付きパイプの説明については、Beej's Guideを参照してください。）
いいえ、char *のみ... – Vigabrand
わかりません。サウンドデータをライブラリに渡す代わりに、ファイル名を渡す必要があると言われています。この場合、名前付きパイプ（FIFOとも呼ばれます）が解決策になります。名前付きパイプは、ファイルシステム内のファイルとして表示されるため、読み取り用にファイルを開くものは、ディスク上のファイルを読み取るのではなく、パイプの受信側で検索されます。したがって、プログラムは名前付きパイプを作成し、パイプの_ファイル名をサウンドライブラリに渡し、復号化されたオーディオデータを書き込んでパイプの末尾に書き込むことができます。 –
Unix上の名前付きパイプは、通常のファイルのように開くことができるファイルなので、その名前は通常の 'char *'です。オーディオライブラリには問題がありません。ただし、プログラムの別のスレッドなどでmkfifo関数を使用して作成し、書き込む必要があります。そうでなければ、fopenはブロックされます（http://stackoverflow.com/questions/580013/how-do-i-perform- a-non-blocking-fopen-on-a-named-pipe-mkfifo） – SirDarius
問題の解決策は、ラムディスクです。 http://en.wikipedia.org/wiki/RAM_drive RAM内のメモリをディスクのように使用します。 これに利用できるソフトウェアもあります。ラムのデータベースをキャッシュすることが普及しています。
そして、ユーザーが簡単にアクセスできるようにファイルがディスク上に残らないようにします。
Androidで？ iPadですか？ –
ゲームやアプリケーションが実行中に新しいドライブをシステムに追加した場合、私は本当に気に入らないでしょう。また、移植可能なソリューションがあるかどうかはわかりません。おそらくroot /管理者権限が必要です。 – interjay
ファイルの読み込み機能をオーバーライドするよりもはるかに優れています。 –
stdioをオーバーライドして、どのように動作するかわからないlibが、開発者が気にしていない方法で正しく動作するようにしてください。それは本当に簡単ではないので、私は別のオーディオライブラリを検索することをお勧めします。
Hekkus Sound System私が見つけたのは、1人でビルドされ、2012年に最後に更新されたものです。ソースを共有せずに1人の人間しか作業していないlibに依存しません。
私のアドバイスでは、適切なサウンドライブラリを探すのに時間を費やしてください。
あなたの話が聞こえます。しかし、Hekkusとは別に、この人物の仕事にもかかわらず、Hekkusは非常に高品質の機能が完全で使いやすいライブラリであることが証明されており、プラットフォームIとのクロスプラットフォームなので、残念です。気にする。なぜあなたはstdioを上書きするのが難しいと言いますか？単純な解読を実行する薄いレイヤーを追加するのは難しくありません。実際の関数をオーバーライドしている限りはそうです。 – Vigabrand
そうかもしれないし、それはまったくあなたの決定だ。正直なところ、プラットフォームに依存しない方法でstdioを上書きする方法はわかりません。例えば、 Windows用のソリューションは、名前付きパイプを作成することです。任意のstdioファイル関数で開くことができる名前付きパイプへのパスを構築できます。 Linuxにも同様の仕組みがありますが、iPhoneやAndroidなど他のプラットフォームでも同じであるかどうかはわかりません。名前付きパイプを作成するWindowsでは、Windows APIのCreateFileを使用できます。私が知る限り、まだプラットフォームに依存しない名前付きパイプライブラリはありません（まだ）。 –
"stdioを無効にする"とは、* nixとそれに相当する（hmmはそこにありますか？）のdlsymを使ってfopen/fread/etcをオーバーライドしていたことです。 – Vigabrand
1つの可能性は、encrypted loopback filesystem（追加リソースについてはGoogle）を使用することです。
この仕組みは、実際に単純なファイルに格納されている暗号化されたファイルシステムにアセットを置くことです。このファイルシステムはループバックデバイスとしてどこかにマウントされます。パスワードはアタッチ/マウント時に指定する必要があります。マウントされると、すべてのファイルは通常のファイルとしてソフトウェアに提供されます。しかし、それ以外の場合、ファイルは暗号化されてアクセス不能になります。
別のUNIXベースのアプローチ：
環境変数LD_PRELOADはに実行ファイルがに対してリンクされているすべての共有ライブラリを上書きするために使用することができます。 LD_PRELOADに記載されているライブラリによってエクスポートされたすべてのシンボルは、open,read、およびcloseのようなlibc関数の呼び出しを含めて、そのライブラリに解決されます。 libdlを使用すると、ラッピングライブラリが元の実装にコールスルーすることも可能です。
したがって、LD_PRELOADが適切に設定されている環境でHekkusサウンドシステムを使用するプロセスを開始するだけで、必要な操作をファイルに加えることができます。
ただし、ユーザーがデータをアクセスできないようにする方法は絶対にありません。アクセスできる必要があるということです。チェーン内のすべてのソフトウェアが暗号化を使用していて、ユーザーがハードウェアをハッキングしたくない場合でも、オーディオ出力ジャックをオーディオ入力ジャックに接続するのは難しくありませんか？あなたはユーザーにイヤホンを使用することを禁じることはできません。もちろん、カーネルは暗号化されていないすべてのオーディオ出力を見ることができ、他の場所にコピーを送ることができます。
面白いオプションのように見えますが、私も窓をサポートしなければなりません。あなたの第2のポイントについては、音は個別に演奏されず、音楽や複数の音が出ているので、あまり役に立たないでしょう。 – Vigabrand
私は好きなことをやったことはありませんが、オリジナルのサウンドをリバースエンジニアリングする方法を考えることはできますが、それらは厳密には複雑ではありません...しかしもちろん、音楽ソースが元のファイルを暗号化していれば、とにかく音楽を抽出する可能性に満足している、問題はないようです。インターネット上に音楽ファイルが表示されたら、彼はあなたを訴えることができません... – cmaster
デコードして、デコードできないファイルを/ tmpファイルに書き込んでから開き、開いている？ Hekkus内のファイル記述子は、開いた後でも有効なままです。 （編集：以下のRAMディスクのアイデアは良いと思われます） –
"アクセス不可"を定義してください。ユーザーのシステムでサウンドを再生している場合、それは私にはかなりアクセス可能なように聞こえます。とにかく、ヘクサス・サウンド・システム（Hekkus Sound System）に関して、著者のウェブサイトには、興味を持った人たちの情報源があります。したがって、最も簡単なのはおそらくソースコードを入手してパッチを当てることでしょう。それはサウンドライブラリがそれにデータを取得する方法を抽象化していない奇妙です。 – n0rd
Cで予約識別子を再定義しないでください。定義されていない動作が呼び出されます。 [...] [...] プログラムは、標準の ヘッダーを使用するのではなく、ライブラリ関数自体を宣言しようとします。これは、次の条件では定義されていません。（Annex J、J.2節）宣言には外部リンケージはありません（7.1.2）。 7.1.4（7.1.3）で許可されている以外の予約済み識別子を宣言または定義しています。** –