セーブコードについてみんなで話し合う場所1

tomato-0809

あんまり暗号化とかに耐性のない仕組みかもしれませんが、こういう方法はどうでしょうか。
1. データをリストか何かに入れる。
2. そのリストの中のデータを同じデータ同士でくっつけておく。(「あああいいいいいいいいいいいうえお」を「あ_3_い_11_う_1_え_1_お_1_」みたいに)
3. 符号の数字をアルファベットに変換する。アンダーバーもなくす。(「あ_3_い_11_う_1_え_1_お_1_」を「あCいKうAえAおA」みたいに)
4. 文字を別の文字に置き換える。(あCいKうAえAおAをaCiKuAeAoAみたいに)
5. ユーザー名を暗号に変換する。(tomato-0809を12345123456789067890みたいな感じに)
6. 4.で作成した暗号を5.の鍵で暗号化する。(5906340jdfgw9140lo¥3eみたいに)
こうすればほぼチートされないと思います。
そんなコードを暗号化できるのかも復元できるかも謎ですけど。

l___coconut___l

セーブコード暗号化….何重にもたくさんの文字に変換するのが最適なのでは? Money・1000000 = あいうえおかき = キカオエウイア = 木蚊尾絵宇胃亜みたいな

newmomizi_txt

ただ単に文字を置き換えるだけだと、簡単に破られます。
大昔にそのような方法を使用した暗号があったのですが、
文字の数の割合(この文字は多く使われる、この文字はあまり出ない、など)をもとに破られていました。
セーブコードだとこの方法は使えません。ですが、スコアを1変えた時にセーブコードのどの桁が変わるかを確かめるなどすれば、解析できます。

というか、Scratchではプログラムは誰でも見ることが出来るので、100%偽造できないセーブコードを作ることはほぼ不可能です。
中を見て、セーブコードの生成システムを見れば解読できます。
一応、難読化という方法(?)はありますが…

Last edited by newmomizi_txt (Aug. 24, 2022 08:54:51)

r4010

元々のデータに、ユーザーネームを使って鍵をかける方法は、このような方法があります。
①まず、自分のユーザーネームを数値化する。2桁ずつだと全ての文字を数値化できる。
例：r4010→28,04,00,01,00
②データを2桁ずつに分け、①の数値をそれぞれ足し、100で割った余りを並べる。（①の長さが足りなければ繰り返し用いる・データが奇数桁なら最初に0をつける）
例：データが78452387523245→ 78,45,23,87,52,32,45
+28,04,00,01,00,28,04
06,49,23,88,52,60,49←完成!
解読するときは、②の足し算を引き算にする

Last edited by r4010 (Aug. 24, 2022 08:50:35)

akku--n11

セーブコードに暗号化やユーザー名を入れてもプロジェクトの中に入って変数を書き換えてセーブコード生成の定義を呼ばれたら意味がなくなってしまいますね…
これの対策についてなにかいいアイディアはありますか？

上にほぼ同じ内容の投稿がありました…

Last edited by akku--n11 (Aug. 24, 2022 08:58:48)

yukku

>> #388

チート版をリミックスとして共有すれば、それはだいたい原作でも同じセーブコードが使用可能でしょう。
そういうことを考えると無理にセーブコード書き換えを禁止してしまうのはリミックス文化に反してしまう気がします。
私はセーブコード改造されてもあまり問題ないとは思います。
面白いじゃないですか。セーブコード弄ってみるの。

Last edited by yukku (Aug. 24, 2022 09:03:06)

akku--n11

例えば、クラウド変数にハイスコアを記録するゲームなどにセーブコード機能をつけると、
セーブコード改造により不正な世界記録を作ることが出来てきまします。
クラウド変数をAPIから直接いじるとかは考えないことにしましょう

inoking

#1 に書かれているのですが
「チートした状態でセーブしてからロードすることによって正規の記録として使うといったこと」
をされればセーブコードを改造しなくてもチートは出来てしまいます。

#388 で言っているのはそういうことでしょうか。

yucca42

akku--n11 wrote:
セーブコードに暗号化やユーザー名を入れてもプロジェクトの中に入って変数を書き換えてセーブコード生成の定義を呼ばれたら意味がなくなってしまいますね…
これの対策についてなにかいいアイディアはありますか？

中を見るから定義を呼ばれることの対策
この対策だけならいくらかやりようはあります。

中を検知した時に、セーブ、ロードに不可欠な情報を削除することで、
セーブ、ロードが理論上不可能になるという方法です。

簡単な例で言うと、
セーブコードを暗号化、複合化するときのキーを最初から変数に保存しておきます。
（プログラムで初期化するのではなく、作者があらかじめ保存しておく）
「中を見る」を検知した時に、その変数を空にする。
など。

〔対策できること〕
- 中からセーブ、ロードをしようとしても理論上不可能。
- クラウド変数を使用していないためクラウドAPIは意味がない。

〔弱点〕
- 「中を見る」検知器依存。yuyuyuyukkuriさんのものがかなり高性能だと思いますが、どこまで対策できるかわかりません。
- プロジェクトのjsonの閲覧、ハッキング。検知器の部分を削除されると無力化します。

結局どの手法をとってもAPIとjsonは対策しきれません…
ですが、APIはクラウド変数を使わなければ完全に対策でき、
jsonはこのアイデアを応用し、難読化することである程度対策することができます。

jsonまで解読しようとする人はさすがにいないでしょう…という最後は性善説です。

newmomizi_txt

#391
「中を見る対策」だと、リミックスを禁止することに繋がりますし、
Turbowarp又はブラウザ拡張機能の一時停止ボタンを使用することで回避できます。
難しそうですね

newmomizi_txt

私が考えた、破ることが難しいセーブコードシステムを書いておきます。

セーブコードは、スコアやクリア状況などを、ほぼそのまま入れます。
そして、クラウドリストに、セーブコードのハッシュ値を保存します。
セーブコードを読み込む時は、そのハッシュ値がクラウドリストに保存されているものと一致するかを確認し、一致するなら読み込みます。

【利点】
・クラウドリストに全保存するよりも、容量を削減できる
・ほぼ確実にズルすることはできない

【欠点】
・「他人から借りたセーブコードで遊ぶ」ということはできない
・仮にユーザー名を37桁にエンコードし、ハッシュ値を3桁まで絞ったとしても、一人当たり40桁。クラウド変数を全部使っても64人分しか保存できない
(そもそも3桁のハッシュ関数なんてほぼ確実に衝突多いですよね…)
・偽造がしにくいかはハッシュ関数次第。衝突が多い、特定しやすいと、簡単に偽造される
・クラウド変数を外部からいじられたら全てが終わる(追記)

最初はいい考えのように思っていましたが、書いてみると欠点が大きすぎますね…

Last edited by newmomizi_txt (Aug. 27, 2022 00:32:51)

yucca42

クラウドAPIを無視した場合ですか？

tomato-0809

全然方法思いつかないです。
やっぱり100%チートできないものを作るのは無理なのかもしれないです。
中を見たら動かなくするにしても、json読めばバレてしまいます。
なにかいい方法ないですかね…

tabakenn

#395
テキストで動く部分を作っておいて、中見たら全削除というのは？
中見ないとダウンロードできませんし、ターボワープとかがないと見られなくなるので、普通にマナー的に良くない気もしますけど。

yucca42

#391 の応用的な考えと言えますが、
プロジェクトjsonに関しては

https://mv-ezproxy-com.ezproxyberklee.flo.org/internalapi/project/{project_id}/get/

のようにAPIで直接ダウンロードできてしまうので、見ることは簡単でしょう。

しかし動くコードのようなものを難読化しておけば、簡単に読み取ることは防止できると思います。

tabakenn

#393
同じこと考えていたのですが、ちょっと違うので書きます。
まず、393の案は3桁のハッシュですが、セーブデータの簡単に変えられる部分を順番にいじって行くプログラムを使えばすぐに破られてしまいます。（今は長いセーブデータを効率的に認証することを話していて、例えばペットの名前の部分を順番に変えていけば、999分の1の確率でハッシュが衝突する）（欠点のところで書いてあったのはこういうこと？）

で、
393の案
クラウドに　ユーザ名　と　セーブデータのハッシュ　を保存
新案
クラウドの　テキトウな場所に　セーブデータ＋クラウドの保存場所＋ユーザ名のハッシュ　を保存

こうすれば、まずセーブデータのクラウドの保存場所を読んで、そこのハッシュを取り出して認証すれば、ユーザ名がいりません。

これで8桁のハッシュで保存します。ハッシュは計算に1秒くらいかかるようにしておけば、期待値1回ハックするのに3年かかる計算になります。
8桁だと320人分保存できて、ユーザ名の制限をとると320回となります。僕は自分のプロジェクトが300参照超えるのが珍しいので実用的ですw

newmomizi_txt

確かに、ユーザー名はクラウドリストに保存しないようにして、クラウドリストの番号(?)をパスワード側に入れておけば、容量も削減できるしパスワードの譲渡ができない問題も解決できますね

00giri

確実に不正を防止するためには、サーバー又はそれに代わるものを作り、クラウド変数を使って通信することが最も確実だと思います。暗号化の処理をサーバー側で行えば、不正は大変困難になります。しかし、この方法ではNewScratcherがセーブできなくなってしまうことや、コスト面などがデメリットになります(私はここまでして不正を防止することに価値を感じません)。

inoking

00giri wrote:
確実に不正を防止するためには、サーバー又はそれに代わるものを作り、クラウド変数を使って通信することが最も確実だと思います。暗号化の処理をサーバー側で行えば、不正は大変困難になります。しかし、この方法ではNewScratcherがセーブできなくなってしまうことや、コスト面などがデメリットになります(私はここまでして不正を防止することに価値を感じません)。

というか処理をすべて外部サーバーでやれば絶対にチートできないものは作れるでしょう。

もはや Scratch のプロジェクトとは呼べないでしょうが。。

yucca42

クラウド変数を使うとクラウドAPIの対策ができないと思いますが、それは考えないのですか？
まあそこまでやる人はいないだろうということだと思いますが…

Discuss Scratch