アカウント名:
パスワード:
スマホゲームにはよくあること。画像データとかステータスデータを吸いだして転載されるとか。
こういう問題を起こすのは、スマホ用だからと軽量化を優先して暗号化とかを省略して開発してるんじゃないかと。
それと、トラブルを起こすのは、また別問題。
データをローカルに置く割合はスマホゲームのほうが少ない。パソコン向けのフラッシュゲームやオンラインゲームは大半のデータがローカルにダウンロードされるしゲーム機向けのゲームなら９割以上はローカルに保存されるはず。
そんなことないと思います。知ってる限り、データをローカルに置くスマホゲーは多いですよ。セガのアレとか、スクエニのアレとかも、確かローカルに置いてたはず。
ローカルに置いてかまわないデータはローカルに置くべき。サーバ管理のほうが大変になるだろ。
問題はキャッシュクリアで消えるようなところに置いてたこと。
ローカルにおかないというのは、プレイ中の戦闘データなどのことでは。これは改ざんされないようローカルに保持せずサーバに置くのが主流ですね。
画像データとかマップデータのようなものは通信負荷を考えてローカルに置いちゃってるはずです。
でも暗号化してても解析されちゃうとなると、もうどうしようもないのか。
この前画像データをローカルにダウンロードして、その際にいわゆる「通信の最適化」のせいでデータ不整合を起こしたと言う話がありましたね。
仮に暗号化されていたとしても、Javaで書かれた暗号化コードはリバースエンジニアリングが容易ですからねぇ。ネイティブ言語で書かれていれば少し面倒ですが、それでもリバースエンジニアリングは可能です。
リバースエンジニアリングを避けるためには、カスタム仮想マシンやchunked packingなどのモダン(*)な難読化手法が必須でしょう。
* (主にマルウェアで使われている)
補足。Javaで書かれたAndroidアプリのリバースエンジニアリングがどれだけ簡単かは、apk2gold [github.com]というAndroidアプリ用逆コンパイラを試せば分かります。難読化ツールもありますが、どれもいまいちな感じ。
大丈夫。俺が書いたプログラムなら、ソースコードレベルで最初から難読だ。
大丈夫、一度コンパイルしてからデコンパイルしたら（最適化などで）読みやすくなるよ。
>大丈夫。俺が書いたプログラムなら、ソースコードレベルで最初から難読だ。
難読すぎてCPUが誤読してしまいエライことに・・・
ネタのつもりかもしれませんが、実際のところ、機械的に難読化したコードよりも素に難読なコードの方が読みにくいはず。
あまりの惨さにhpガリガリ削られる奴か。。ウンコードなんてあったけど、あれ生温いレベルの何回見たことか。。。#今日も見てて、すてたくて仕方ない
コンパイラが最適化したものを逆コンパイルしたら元のコードより読みやすいものになってしまったり…？
> スマホ用だからと軽量化を優先して暗号化とかを省略して開発してるんじゃないかと。端末に置くデータの暗号化は常に気休め。重い軽いというのはほぼ存在しない。なぜなら暗号鍵長と違って強度が「どれだけ解読者が気づきにくいか」という評価できない要素に依存するから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
シナリオデータが解析されてGitHub に上げられた模様 (スコア:1)
Re:シナリオデータが解析されてGitHub に上げられた模様 (スコア:0)
スマホゲームにはよくあること。画像データとかステータスデータを吸いだして転載されるとか。
こういう問題を起こすのは、
スマホ用だからと軽量化を優先して暗号化とかを省略して開発してるんじゃないかと。
それと、トラブルを起こすのは、また別問題。
Re: (スコア:0)
データをローカルに置く割合はスマホゲームのほうが少ない。
パソコン向けのフラッシュゲームやオンラインゲームは大半のデータがローカルにダウンロードされるしゲーム機向けのゲームなら９割以上はローカルに保存されるはず。
Re: (スコア:0)
そんなことないと思います。知ってる限り、データをローカルに置くスマホゲーは多いですよ。セガのアレとか、スクエニのアレとかも、確かローカルに置いてたはず。
Re: (スコア:0)
ローカルに置いてかまわないデータはローカルに置くべき。
サーバ管理のほうが大変になるだろ。
問題はキャッシュクリアで消えるようなところに置いてたこと。
Re: (スコア:0)
ローカルにおかないというのは、プレイ中の戦闘データなどのことでは。
これは改ざんされないようローカルに保持せずサーバに置くのが主流ですね。
画像データとかマップデータのようなものは通信負荷を考えてローカルに置いちゃってるはずです。
でも暗号化してても解析されちゃうとなると、もうどうしようもないのか。
Re: (スコア:0)
この前画像データをローカルにダウンロードして、その際にいわゆる「通信の最適化」のせいでデータ不整合を起こしたと言う話がありましたね。
Re: (スコア:0)
仮に暗号化されていたとしても、Javaで書かれた暗号化コードはリバースエンジニアリングが容易ですからねぇ。
ネイティブ言語で書かれていれば少し面倒ですが、それでもリバースエンジニアリングは可能です。
リバースエンジニアリングを避けるためには、カスタム仮想マシンやchunked packingなどのモダン(*)な難読化手法が必須でしょう。
* (主にマルウェアで使われている)
Re:シナリオデータが解析されてGitHub に上げられた模様 (スコア:1)
補足。Javaで書かれたAndroidアプリのリバースエンジニアリングがどれだけ簡単かは、apk2gold [github.com]というAndroidアプリ用逆コンパイラを試せば分かります。
難読化ツールもありますが、どれもいまいちな感じ。
Re:シナリオデータが解析されてGitHub に上げられた模様 (スコア:5, おもしろおかしい)
大丈夫。俺が書いたプログラムなら、ソースコードレベルで最初から難読だ。
Re:シナリオデータが解析されてGitHub に上げられた模様 (スコア:1)
大丈夫、一度コンパイルしてからデコンパイルしたら（最適化などで）読みやすくなるよ。
Re:シナリオデータが解析されてGitHub に上げられた模様 (スコア:1)
>大丈夫。俺が書いたプログラムなら、ソースコードレベルで最初から難読だ。
難読すぎてCPUが誤読してしまいエライことに・・・
Re: (スコア:0)
ネタのつもりかもしれませんが、実際のところ、機械的に難読化したコードよりも素に難読なコードの方が読みにくいはず。
Re: (スコア:0)
あまりの惨さにhpガリガリ削られる奴か。。
ウンコードなんてあったけど、あれ生温いレベルの何回見たことか。。。
#今日も見てて、すてたくて仕方ない
Re: (スコア:0)
コンパイラが最適化したものを逆コンパイルしたら元のコードより読みやすいものになってしまったり…？
Re: (スコア:0)
> スマホ用だからと軽量化を優先して暗号化とかを省略して開発してるんじゃないかと。
端末に置くデータの暗号化は常に気休め。重い軽いというのはほぼ存在しない。
なぜなら暗号鍵長と違って強度が「どれだけ解読者が気づきにくいか」という評価できない要素に依存するから。