セーブコードについてみんなで話し合う場所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みたいに)
こうすればほぼチートされないと思います。
そんなコードを暗号化できるのかも復元できるかも謎ですけど。

Uncaught TypeError: Cannot read properties of undefined (reading ‘signature’) at <signature> 1:1
Scratch is a Coding Community, Not a KidsSNS. See more: https://scratch.mit.edu/about
Trends are not ranking or anything. It's just a statistics. You can also choose other choices. See more: https://scratch.mit.edu/discuss/post/5457685
f4f is Optional, Not required. See more: https://scratch.mit.edu/discuss/post/3948284
This signature was created by ダサい署名ジェネレーター(link) and Rainbow Post Generator(link).

この文字が見えた方は、国産でFirefoxベースのFloorpをぜひ試してみてください。
あなたが使っているであろう、そのブラウザ拡張機能もしっかりと使えますよ;

l___coconut___l

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

依頼受け付けてます。

newmomizi_txt

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

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

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

ここから下は署名(しょめい)と言います。(最終更新 2024/02/01 JST)

1973年（昭和48年）12月、愛知県宝飯郡小坂井町（現・豊川市）を中心に「豊川信用金庫が倒産する」というデマが流れたことから取り付け騒ぎが発生し、短期間（二週間弱）で約14億円もの預貯金が引き出され、倒産危機を起こした事件である。
警察が信用毀損業務妨害の疑いで捜査を行った結果、女子高生3人の雑談をきっかけとした自然発生的な流言が原因であり、犯罪性がないことが判明した。デマがパニックを引き起こすまでの詳細な過程が解明された珍しい事例であるため、心理学や社会学の教材として取り上げられることがある。

(Wikipedia「豊川信用金庫事件」より引用、2024年2月1日閲覧。)

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)

このような今だからこそ、r4010をフォローするべきだと、私は考えています。なので、皆さんはr4010をフォローするべきだと思います。
みなさんも、「自分はr4010をフォローするべきだ」と考えるのであれば、r4010をフォローするべきだと思います。
r4010をフォローする

akku--n11

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

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

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

この線から下は署名(しょめい) です

ｶﾜｲｿｽ ಥ_ಥこれで傾向乗りたい

適当ポストカウント:
Found 1032 posts.

yukku

>> #388

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

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

↑こういう線の下に宣伝とか書いてる人がよくいるけど、こういう線より下の文章には「署名」って名前がついていて、設定を行うと自動で投稿にくっついてきます。詳しいこととか設定方法はこのページにあるので確認してみてください。
この「署名」以外で関係ないこととかをするのは基本禁止なのでそういうことやりたいと思ったら署名でやってください。

日本語フォーラムの使い方っていうプロジェクトを作ったのでどうぞ。

akku--n11

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

この線から下は署名(しょめい) です

ｶﾜｲｿｽ ಥ_ಥこれで傾向乗りたい

適当ポストカウント:
Found 1032 posts.

inoking

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

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

これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
　つまり「子ども SNS」ではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている

yucca42

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

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

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

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

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

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

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

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

RPGのスクロールシステムを研究してます。

今はRPGを簡単に作れるアプリを作っています(^^) まだ未完成

スクラッチをコードで書きたいですか？→Scratch Codeがあります

newmomizi_txt

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

ここから下は署名(しょめい)と言います。(最終更新 2024/02/01 JST)

1973年（昭和48年）12月、愛知県宝飯郡小坂井町（現・豊川市）を中心に「豊川信用金庫が倒産する」というデマが流れたことから取り付け騒ぎが発生し、短期間（二週間弱）で約14億円もの預貯金が引き出され、倒産危機を起こした事件である。
警察が信用毀損業務妨害の疑いで捜査を行った結果、女子高生3人の雑談をきっかけとした自然発生的な流言が原因であり、犯罪性がないことが判明した。デマがパニックを引き起こすまでの詳細な過程が解明された珍しい事例であるため、心理学や社会学の教材として取り上げられることがある。

(Wikipedia「豊川信用金庫事件」より引用、2024年2月1日閲覧。)

newmomizi_txt

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

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

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

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

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

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

ここから下は署名(しょめい)と言います。(最終更新 2024/02/01 JST)

1973年（昭和48年）12月、愛知県宝飯郡小坂井町（現・豊川市）を中心に「豊川信用金庫が倒産する」というデマが流れたことから取り付け騒ぎが発生し、短期間（二週間弱）で約14億円もの預貯金が引き出され、倒産危機を起こした事件である。
警察が信用毀損業務妨害の疑いで捜査を行った結果、女子高生3人の雑談をきっかけとした自然発生的な流言が原因であり、犯罪性がないことが判明した。デマがパニックを引き起こすまでの詳細な過程が解明された珍しい事例であるため、心理学や社会学の教材として取り上げられることがある。

(Wikipedia「豊川信用金庫事件」より引用、2024年2月1日閲覧。)

yucca42

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

RPGのスクロールシステムを研究してます。

今はRPGを簡単に作れるアプリを作っています(^^) まだ未完成

スクラッチをコードで書きたいですか？→Scratch Codeがあります

tomato-0809

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

Uncaught TypeError: Cannot read properties of undefined (reading ‘signature’) at <signature> 1:1
Scratch is a Coding Community, Not a KidsSNS. See more: https://scratch.mit.edu/about
Trends are not ranking or anything. It's just a statistics. You can also choose other choices. See more: https://scratch.mit.edu/discuss/post/5457685
f4f is Optional, Not required. See more: https://scratch.mit.edu/discuss/post/3948284
This signature was created by ダサい署名ジェネレーター(link) and Rainbow Post Generator(link).

この文字が見えた方は、国産でFirefoxベースのFloorpをぜひ試してみてください。
あなたが使っているであろう、そのブラウザ拡張機能もしっかりと使えますよ;

tabakenn

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

yucca42

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

https://projects.scratch.mit.edu/internalapi/project/{project_id}/get/

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

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

RPGのスクロールシステムを研究してます。

今はRPGを簡単に作れるアプリを作っています(^^) まだ未完成

スクラッチをコードで書きたいですか？→Scratch Codeがあります

tabakenn

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

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

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

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

newmomizi_txt

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

ここから下は署名(しょめい)と言います。(最終更新 2024/02/01 JST)

1973年（昭和48年）12月、愛知県宝飯郡小坂井町（現・豊川市）を中心に「豊川信用金庫が倒産する」というデマが流れたことから取り付け騒ぎが発生し、短期間（二週間弱）で約14億円もの預貯金が引き出され、倒産危機を起こした事件である。
警察が信用毀損業務妨害の疑いで捜査を行った結果、女子高生3人の雑談をきっかけとした自然発生的な流言が原因であり、犯罪性がないことが判明した。デマがパニックを引き起こすまでの詳細な過程が解明された珍しい事例であるため、心理学や社会学の教材として取り上げられることがある。

(Wikipedia「豊川信用金庫事件」より引用、2024年2月1日閲覧。)

00giri

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

inoking

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

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

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

これは署名と呼ばれるもので投稿本文とは関係ありません。
Scratch は「世界最大の子ども向けコーディングコミュニティーで、シンプルなビジュアルインターフェースを持ったコーディング言語」
　つまり「子ども SNS」ではない
・「傾向」とは単に一定の基準で作品を並びかえただけのもので、ランキングでもなんでもない、ナンバーワンよりオンリーワンを目指してみては？
・「フォロー」とは他の Scratcher が何をしているかを簡単に確認するためのもので、「フォロワー」は「ファン」ではない
・「スタジオ」とは特定のテーマに沿って作品をまとめたり、共同制作したりするための場所
・「星」や「ハート」などを何かの見返りとすることは Scratch チームによって禁止されている

yucca42

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

RPGのスクロールシステムを研究してます。

今はRPGを簡単に作れるアプリを作っています(^^) まだ未完成

スクラッチをコードで書きたいですか？→Scratch Codeがあります

Discuss Scratch