ゲームのデータファイルについて語るスレ

1 ：01/11/18 〜 最終レス ：2012/04/24

ゲームのデータファイルについて語るスレです
データファイルの種類（画像、ＢＧＭ、効果音、音声など）は問いません
データファイルのフォーマット、圧縮、プロテクトなど語りましょう

2 ：

[ヘッダ2byte][チェックサム2byte][データ2byte]

3 ：

とりあえずフォーマットあたりから
ゲームを作るときには当然
データファイルのフォーマットも考えなければなりません
ちなみにいくつかのＷＩＮのゲームのデータファイルを見てみると
だいたい下記のような感じになってますね
・ヘッダー情報（識別ＩＤ、ファイル内のデータの数など）
　ファイル先頭に（必ずといっていいほど）ある
　特にはじめの４バイトが識別ＩＤになってるものが多い（？）
・データ情報（データの識別名、位置、サイズなど）
　たいてい、ヘッダー情報の後にこれが配列される
　この数はヘッダー情報にある
・実際のデータ
　データ情報の配列の後に来る
　（ヘッダー情報のサイズ＋データ情報×配列数の後）
私もゲームのデータファイルはこうしてますが、
他にもよく使われるフォーマットありますか？

4 ：

追加
＞　特にはじめの４バイトが識別ＩＤになってるものが多い（？）
例えばＹＳ�UＥのデータファイル（monde.ys2）は
初めの４バイトは"YS2E"が
メモオフ（***.dat）は"lnk"が識別ＩＤとして入ってます

5 ：

可変長データのストアにはどんな構造使ってる？
俺はRIFF-WAVEみたいに、
DWORD ID
DWORD size
BYTE data dup(size)
のチャンク構造でやってるけど。

6 ：

>3,4
コンパイラが（というかＣＰＵが）３２ビットごとに
アクセスしたほうがパフォーマンスがいいから
Cで書くと
struct data
{
　　long sign;
　　long width;
　　long height;
　　...
}
という風に宣言しておくのはよくやるみたい。
CGの横幅なんか２バイトで十分そうでも４バイトとるし。

7 ：

ところで、先頭の4バイトの識別子は、
magicが一般的ですか？

8 ：

　MAGファイルから直接DirectDrawのサーフェスに
読み込ませてる俺はDQNですか？

9 ：

このスレなぁ、今んとこプログラマの好みの問題にみえるべ。

10 ：

参考資料
http://www.wotsit.org/

11 ：

>10
おお、こんなところ知らなかった。便利だ、感謝。
画像ファイルとかって、皆どうやって扱ってるのかな。
俺はMAGっぽい独自フォーマットで圧縮して、何十枚かまとめて
一つのファイルにしてる。ヘッダにオフセットのサイズの情報を
書いておいて、適宜抜き出してるけど。

12 ：

圧縮ならS3TCが扱いやすい。
固定長マンセー

13 ：

s/オフセットのサイズ/オフセットとサイズ/

14 ：

暗号化だが、
http://info.isl.ntt.co.jp/
のEPOC PSEC Camelliaはどうか。
特にCamellia。

15 ：

>>11
俺はMAGそのまんまだ。拡張子もMAG（ｗ
　昔のエロゲなんかでMAGのヘッダ潰して拡張子変えただけ
ってのもあったらしいが。

16 ：

オレは画像にはPNG使ってる
データはアーカイブにして、すべてを一つにまとめてる。
データのフォーマットは
struct header {
u32l sign;
u32l size;
u32l crc32;
};
あとは簡単な暗号化を施したカタログ情報と、
その後に圧縮データが続く。

17 ：

MAGフォーマットってフリーの規格なの？
俺もほぼパクリで使ってるけど、なんかそのまま使うと怖いような。

18 ：

マルチペイントのマニュアルには
同人ソフトなどでMAGフォーマットのデータを使ったりしても
いいですよ。みたいな事が書いてあった。

19 ：

ＭＡＧフォーマットですか・・・
知りませんでした・・・
ちなみにＭＡＧフォーマット検索してたら
こんなページ見つけました
〜　圧縮法入門　〜
http://www.ingnet.or.jp/~kojif/mu/comp/index.htm

20 ：

追加
http://www.gavo.t.u-tokyo.ac.jp/~hosoyama/report/ex2b6.html

21 ：

鮪の前身であるMAKIフォーマットが完全なフリーをコンセプトに
開発されたものだから、当然MAGも自由に使えます。
適度な圧縮率と展開の速さ＆容易さで今でも便利なMAG萌え。

22 ：

ついでに、MAGの仕様は「MAGBIBLE」で検索かけると見つかると思われ。

23 ：

>>14
おお国産ですな。暗号化はAESしかしらないですなぁ
ブロック長より鍵長のほうが重要だと思うんですが AES 互換を全面に出した
ということですかな。Rijndaelより高速で256bit-keyが使えるなら使いたい。。
問題は Optimize されたレベルでより高速かということですが。。。

24 ：

メッセージデータは当然圧縮なり暗号化なりするだろうけど…1byteずらして
ごまかすってのはダメ？(w
というかゲームデータを隠すのに128bit暗号も使わないて。

25 ：

>>23
そういうのってすごい気になるけど、データの鍵は
プログラムがもってるわけ？
鍵とデータを一緒に配布するって馬鹿くせえとおもったが・・・

26 ：

どの部分が鍵かなんて逆アセでもしないと解らないと思うけど。

27 ：

逆汗すりゃわかるんでしょ。

28 ：

圧縮の方の技術だけど、
ブロックソート後のデータもほとんど暗号と変わらんよ。
ゲームに使うなら十分でしょ

29 ：

http://www.interq.or.jp/www-user/enra/rina/
こんなのどう？

30 ：

たかがゲームデータ抜きたさに逆汗するヴァカがいるか！

31 ：

とりあえず貼っとくか。
http://www.jisyo.com/viewer/faq/mag_tech.htm
MAG仕様書（原文） もちろん日本語ね。

32 ：

>>30
結構いる

33 ：

>>29 作者がドキュン

34 ：

>>29 waveletにはちょっと興味あるけど。

35 ：

解析を楽しむページ
ttp://ku-www.ss.titech.ac.jp/~yatsushi/Ryze.html
参考までに。

36 ：

基本的に、解析クン一人にでも負けたらツールばら撒かれて終わりだからなあ(藁

37 ：

>>25
鍵とデータが一緒になきゃ復号できないじゃん。
勘違いしてるのかもしれないけどこれはゲームの話で、実際に暗号を
使う場面では利用者がそれぞれに鍵を持っているので一緒も糞もない。

38 ：

TIM2ってどうよ？

39 ：

>38 PS2の開発なんてやったことも機会もなさそうだしなぁ…
PCで使う意義もないし。

40 ：

Camelliaのコードをみましたが、8bitASIC系に特化されてて
16,32bitの最適化ソースが公開されていないようですね。
最適化ソースが無いのでRijndaelには速度で勝てないでしょう。残念ながら。
Feistel回数が比較して多いのとFeistelとSBOXの手間が他の方式と比べて
煩雑です。Feistelを何回か回すだけでも簡単な暗号系になりますから
それでもいいんですけどね。

41 ：

>>37
そりゃそうだ。
しかしどんなに強力な暗号化を使っても、鍵と一緒に配布されてるんじゃなあ(藁

42 ：

たかがゲーム（失礼）のデータを、そこまで暗号化しなくても
と思うのは、俺だけか？

43 ：

俺もそう思う。どうせ>>35のリンク先のようなレベルのにかかったら
何やったって解析されてしまうんだから無駄無駄。
シェアウェアのクラック問題にも似てるけど。

44 ：

>>42
同感。
複雑な暗号化は速度的にも不利なうえに鍵添付じゃあ、その鍵で
暗号化を解除してくださいとクラッカーに言ってるようなもの。
暗号化にかける時間があったら他のことやったほうがよい。

45 ：

>>43
あのリンク先程度じゃ、変形算術圧縮とか、TripleDES掛けただけでも解析できなくなるだろ

46 ：

まぁしばしばルーチンの解析なんかしないで、ルーチンごと
ブッこぬいて使ったりするけどね。

47 ：

複雑になればなるほど、所詮手動の解析では手間がかかる。
つまり、複雑度を限りなくあげてやればよい。

48 ：

結局、複合化後のデータを抜き出すようなコード書けば
意味無いんじゃないの？
ネトゲなんかで課金がからむと真面目にやったほうがいいんだろうが、
普通のオフラインゲームであんまり気張ってもなぁ｡

49 ：

暗号化アルゴリズムをどう複雑にしたって、たとえば
bool decrypt(byte *out, byte *in, int len);
みたいな関数の入り口見つけられたら、そこからそのまま
ひっこぬかれておしまい。
アルゴリズムではなくてプログラムを複雑にすると
今度はプログラムが単に汚くなる。

50 ：

>>49　かぶった。結婚する？(ﾜﾗ

51 ：

こういう暗号化は、暗号化アルゴリズムをいかに
複雑にして解読を防ぐかじゃなくて、復号ルーチンを
どうリバースエンジニアリングから守るかだよ。

52 ：

皆さんソフトにリバースエンジニアリングを防ぐ建設的な手法を使って
いらっしゃいますか？（結局理論的には解析可能だから対策をしないと
いうのはとても簡単なことですが…）
>>51
>暗号化アルゴリズムをいかに複雑にして解読を防ぐかじゃなくて
おおむね同意します。でも暗号アルゴリズムなんてXORでもない限り
複雑なものを導入しても大してコストはかからないですよ。感覚としては
XORをかけるならAESかけるのもさして違いはないです。

53 ：

>XORでもない限り
すみません "s/XORでもない限り/"

54 ：

XORとAESってそうとう違うような・・・

55 ：

どうせ鍵を同梱するなら、XORでももっと凝った暗号でも
防御力は一緒だと思ってたんだけど、違うの？

56 ：

>>55
鍵と暗号済みのデータがあれば、解読できるわけ？

57 ：

ゲームを普通に起動して、
メモリ上に展開された解読済みデータを
ReadProcessMemory で抜き取るとか。

58 ：

>>49
グローバルなレジストフラグをプログラム全体に散りばめておいて、
レジストチェックルーチンの中でそのフラグを直接操作する。
こうすることで、レジストチェックルーチンをスキップしただけでは
動作しないようになる。
あとはひたすらチェックルーチンを冗長に複雑にする。
例えば、チェックルーチンは仮想マシンコードで実装する。
これによって直接の逆アセンブラは防げる。
あとは、そのルーチンを圧縮して、展開コードを仮想マシンで書いて
インタプリタで動かして、無駄なコードをつけまくって、ひたすら頑張る。
一度このシステムを作れば、プログラムにフラグを生めこむだけなので再利用はきくよ。

59 ：

なんか話がいつのまにかレジストチェックルーチンの話に
すりかわってますぜ旦那・・・

60 ：

みんなサウンドやBGMのコーデックに何使ってる？

61 ：

>>59
暗号化も鍵を隠すという点ではにたようなものでしょうが。

62 ：

>>60
OggVorbis

63 ：

暗号の鍵を暗号化する？ｗ まぁがんばれや
ネットゲーの場合はときどきサーバからあたらしい
アルゴリズムの復号化DLLが送られてくる、とかで
結構なんとかなるかな。

64 ：

>>60
漏れもOggVorbis使ってる

65 ：

普通のゲームの場合、暗号化されたデータと鍵と復号ルーチンを全部配布してるわけで、
その辺が普通の暗号解読とは違う。
個人的にはあんまりむきになっても仕方ないと思ってるんだけど

66 ：

鍵と金庫を一緒にユーザにしてんのに、
南京錠だろうがIDカードだろうが同じことだと思う今日この頃。
シェアウェアなら、パスワードにデータの解除キー混ぜたり
できるかもしらんけどどのみち気休めでんな。

67 ：

s/してんのに/渡してんのに/

68 ：

age

69 ：

OggVorbis 重くない？
これ入れてから FPS が激減しちゃったんだけど・・。

70 ：

MP3 2%, OGG 5%, APE 15%, MPC 1%, AAC 15% (Celeron450MHz@Winamp における負荷調べ)
どこぞから拾ってきた参考資料
多少は重いかも

71 ：

www.din.or.jp/~glit/TheOddStage/Progs/audioplayer/
こんなのがある。CPU使用率調べ。

72 ：

>>71
やっぱ、mp3もoggも遅いマシンだと負荷は馬鹿にならないなー。

73 ：

いやそのページのPenIIIマシンが遅いという気はないんだが。にんともかんとも

74 ：

OggVorbis RC3 早くでないかな・・・。

75 ：

＞７４
でまして。

76 ：

OggVorbis RC3 すごく音がいいぞ

77 ：

>>29,33
去年の話でなんですけど、閉鎖ということでご勘弁を。

78 ：

>>76
160kbpsとか？

79 ：

プレイ中のゲームの変数改竄方法と対策について語り合ってるスレはないですか？

80 ：

プレイ中のゲームの変数改竄方法と対策について語り合ってるスレはないですか？

81 ：

>プレイ中のゲームの変数改竄方法と対策について語り合ってるスレはないですか？
プログラムコードを書き換えることで、変数改竄をするパターンが
多いです。なので、これに対する対策は、全てのアプリケーションデータを
プログラムコード全領域をキーとする暗号をかけてしまうことです。
こうすれば、プログラムコードを変化させようものならば、
アプリケーションデータも解凍時に支障が起きます。
プログラムコードが変更するたびにデータも作成しなければならないという
点がデメリットと、絶対に常駐するコード領域をキーにするというのが
必要条件です。
もっとも気休め程度の暗号なのですが。

82 ：

>>81
結局、コード書き換えされればいつかは改造されるのか。
オフラインなら良いかもしれないんだけど、ネットゲーだと致命的だよな。
課金とか絡んでくるし。
チートキャラだらけのネトゲに金払うなんてバカバカしいってことで
ゲームの存続にもかかわってくるから結構重要な問題かと…

83 ：

プレイ中にプログラムを切り替えてターゲットゲームの変数の増減を検索して
何の値であるか推定し、書き換えるアプリがありますね。
プロセスの切替時の各パラメータチェックサムの変化で書き換えを検出
できそうですが、いずれ高度な書き換えソフトが出ないとも．．．

84 ：

折れは男らしく全部ビットマップ
ダブルキュリックで中身が見える親切設計だ折れもユーザーも大ハッピー。まいったか

85 ：

ネットだと結局、改竄してもらっては困るデータ（能力値等）をサーバーに、
改竄してもどうでもいいデータ（テクスチャ）を置いて、完全にクライアント
とサーバーを分割するしかない。　というか、それでオケな気もする。

86 ：

　

87 ：

>84
まいった。
ｱﾅﾀ最強でつ。

88 ：

おお、このスレまだあったんだなぁ・・・（涙

89 ：

ねぇ3Dのデータ扱うのに「これ使っとけヽ(｀Д´)ﾉｺﾞﾙｧ!!」って感じの
フォーマット教えて下さい……

90 ：

自作

91 ：

xsi

92 ：

いややっぱしtmd使っとけ

93 ：

いやrokだろう

94 ：

>91>92>93
ありがとうございます、試してみます。
でもみんな>90みたいに自作の独自フォーマット使ってたら(((( ;゜Д゜））））ガクガクブルブル

95 ：

マジレスすると世間では基本的に自作フォーマットだ。がんがれ

96 ：

>>66
個別に違う鍵を渡すなら漏洩元を特定でるるから無意味でもないのでは？

97 ：

保守あげ

98 ：

　　　　　　　　　　　　ｏ.
　　　　　　　　　　　 /　￣￣￣￣￣￣￣￣￣￣ /
　　　　　　　　　　　/　　　このｽﾚは見苦しく.　　/
　　　　　　　　　　 /　　終了いたしました　　　 /
　　　　　　　　　　/　ありがとうございました　 /
　　　　　　　　　 /　　　　　　　　　　　　　　　　/
　　　　　　　　　/　　　 モララーより　　　　　/
　　　　　　　　 /￣￣￣￣￣￣￣￣￣￣￣/
　 ∧＿∧　　/　　　　　　　　　　　　　　　　/∧＿∧
　（　･∀･）　/　　　　　　　　　　　　　　　　/（･∀･　）
　（　　　　）つ　　　　　　　　　　　　　　　⊂（　　　　）
　｜ ｜ ｜　　　　　　　　　　　　　　　　　　 ｜ ｜ ｜
　（_＿）＿）　　　　　　　　　　　　　　　　　　（＿（＿_）

99 ：

データは全部変数に代入してコンパイラすればいいんではないか
というのはだめか？

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

パチンコゲームって (193)
衝突力 (102)
お、俺って天才！って思った瞬間 (158)
反社会的ゲームの製作 (191)
WinXPでのネットやろうぜの動かし方について (103)
子供ツクール (189)
--log9.info------------------
★ドラム器材統合スレッド12セット目★ (136)
【泣く子】Bogner・ボグナーアンプ【黙る】 (100)
L'Arc〜en〜Cielの音を真面目に考える Part50 (366)
どうでもいいことばかり報告するスレ 16レポ目 (161)
【AriaPro�U】アリアについて語ろう　16本目【AP】 (111)
【Fender】メキシコ製フェンダー総合#19【Mexico】 (958)
VOX アンプ (622)
島村楽器 part.22 (485)
名古屋近郊の楽器屋スレその10 (527)
【Guitar】SCHECTER・シェクター・17本目【Bass】 (102)
聖飢魔�U (915)
手が小さいギタリスト７ (103)
テスト用 (738)
ギターの弾き方　初心者編82 (874)
♪チェロって素敵♪23 (698)
バンドのオリジナル曲作った (101)
--log55.com------------------
1日１０００ｈｉｔだけどアクセス解析入れました。
IE7.0が出たら付けて欲しい機能
おいおまえら、俺をｽｰﾊﾟｰﾊｶｰにして下さい。
おまいらIEの文字のサイズは何ですか？
ディレクトリ構成どうしてる？
【UD→BIONC】白血病・がん患者を救え！7【@web】
CSSデザインのサイトを評価するスレ
素材屋やる上で気をつけること２