ドンキーコングリターンズ バイナリ解析
■ このスレッドは過去ログ倉庫に格納されています
かつての改造ドンキーを夢見てドンキーコングリターンズのバイナリを解析するスレ
解析っていってもデータの構造を調べるって意味です TXTRはおそらく基本的にはビットマップだと思う
データサイズがピクセル数の倍数になっているものがほとんどだから
ピクセルあたりのデータサイズは最小で4ビットがあるっぽい
そうでなければピクセル数がバイト数を上回る場合を説明できない
画像に詳しい人、吸い出し経験がある人のアドバイスがほしい… 明らかにゲームキューブのテクスチャのフォーマットを採用しているな
devkitProのgxtexconv.exeでビットマップ画像をCMPRフォーマットに変換してみたところ、TXTRに非常に似たバイナリが生成された。
ちょっくらソース参照してコーデック作ってくるわ コーデック作るのに10個のフォーマットに対応しなけりゃいけないのが想像以上に面倒だったので、
ここはマリオカートハックのChadderzのソースを流用することにした。
ライセンス的にはOKなはず 変換できたわ
まだ上下が逆なんで修正したらアップする >>32
ありがとう
テクスチャハックが可能になったら人寄せもしやすくなる…はず
気になるのは、ヘッダの情報に画像フォーマットが含まれていないのではないかということ
ほとんどの画像がCMPRで一部RGB5A3だが、ヘッダに共通性がみられない
さらに一部の画像は未知の形式で、ゲームキューブ・Wiiの形式のどれでも変換不能だった
まあ、どうせ俺の勘違いか間違いで終わるだろうが どうもミップマップが関係してるっぽい
マリオカートやらスマブラで使われているtex0フォーマットは通常画像に加えて、縮小画像を保持している
それと同様に幾つか縮小画像を保持しているならサイズが合わない説明がつく
ちなみに未知の形式といってたやつはRGB5A3でデコードできた。 ひとまずパレットなしの画像の読み書きを実装した
実装したと言ってもコーデックはChadderzのを使い、ビットマップの拡大縮小は.NET Frameworkがやって、俺がしたのはヘッダ情報の記入と
データの圧縮くらいで、手間はかかってない
テストして動作したらデモ動画とTXTRに対応したDKDKをアップするわ
パレット画像は今のところ実装予定なし!
ステージに含まれる枚数的にはかなり少ないし、
Wiiの画像フォーマットで一番優れているのはおそらくCMPRで、ユーザーはそれ一択でおkだから 細かい修正をするのに手間取ったが、一応バグはなくなったと見える
テストは明日か明後日しようと思う 先に言っておくが、画像を開いていくとメモリのドカ食いが起こる
100MBとか余裕で食うんで注意 テストに失敗した。
どういうことかというと、まずファイルロード画面(ドンキーやディディーが左から右へと走る画面)から先に進まなかった
かといってフリーズしたわけではない。
以下、原因の推定
1.内部的にファイルサイズを保持し、ファイルサイズがそれ以上だったらエラーとしてリロードを試みる
これは無い。なぜかというとRASはキチンと読み込み、再生することができたからだ。
2.Riivolutionに問題がある
これも1と同様の理由で否定されるほか、正規のファイルを配置したところキチンと読み込んだ。
これはRiivolutionにファイルサイズの限界があるからだ、といった推測は誤りとなる
3.PAKデータの先頭の16バイトの数字(キーと呼んでいる)が間違っていた
正規のファイルのキーを適当な値にいじって読み込ませたところ、動作した。よってキーの値は適当でも良いことになる
4.DKDKのファイル組み立てが間違っていた
これは微妙であるがオフセットの値がありえないところを指している、といったことがあった場合、ゲームはおそらくフリーズするはずである。
とはいえ、これしか原因はありえない。
テクスチャのミップマップの扱いが怪しいと思う。データサイズが、同じ縦と横、ミップマップの画像数をもつ画像と異なっていた。
よく調べて修正しようと思う。 応援してくれるだけでもいいと思うようになった
ステージ改造が可能になれば多分人は増えるだろうし、それまでの辛抱だと思う
TXTRのリビルドに間違いが見つからない…わからんorz 今週は私用で活動時間がとれない
やめたわけではないのでご心配なく
ところでRiivolutionの速度の遅さが目に余る
どんな実装したら3倍程度の読み込み時間になるんだ ISO直下のファイルがあることに今気づいた
PAKファイルがあったので見てみたが、ステージのPAKとやや構造が異なっていてDKDKの手直しが必要っぽい
こんな所にファイルがあると知っていたならそれに合わせて最初から作ってたのに… テクスチャのサイズがオリジナルと異なっていたのが読み込み失敗の原因だったぽい
なぜだ? RASファイルは問題なく読めたのに、PAKは大きさを揃えないと読めない
ひとまずデモ動画つくるわ だめだ、なぜサイズによって成功不成功が決まるかわからないと進めない、というか進みたくない
読み込みプロセスがわかればヒントがあるかもなー
でも逆汗はしたくねえな
誰か助けてください。 やっとわかりました、読み込みエラーの本当の原因が
答えは単純、データサイズは0x40バイトにアラインしなければならない、という規則を破っていた
データのテーブルを見てみると、データサイズの末尾2バイトが00,40,80,C0のものしかなかった
そこで、データをすべて0x40に揃えたところ、やっと読み込むことができた
これで意気揚々とデモ動画をつくれるぜ 気力があるならどこをハックしたか動画中に説明文いれたほうがわかりやすいかもね >>48
わかりにくいって意見が出たら作ろうかな
まあ、空に大きくHello Worldって出してるから問題ないと思うけど
お次は何をしましょうかね
MREAは最後に回した方がいい気がしてきた
あれはステージを組み立てる設計図みたいなもんだし、いろいろわかってないと難しい
モデルいくか?
ちなみに俺はコード書けるだけで、画像処理やら音楽変換は完全な素人だから常にググってる
言語や知識は問わないからコード書ける人は手伝ってくれるとうれしい
3ヶ月かけてまだRAS(STRM)とTXTRしか実装できてなくて、正直一人じゃ気が遠い 一応TXTRの編集と、ステージ以外のPAKに対応したDKDK最新版(変更はDKUtils,DKUtils.Native,DKUtils.Handlersのみ)
http://www18.atwiki.jp/dkhax?cmd=upload&act=open&pageid=18&file=DKDK.zip
テクスチャハックして動画作って宣伝、知り合いに紹介などどんどんしてください CMDLを現在解析中
モデル関連でわかっていることを挙げると、
CHAR:
モデルの設計図。このキャラの名前は何、モデルは何を使う、アニメーションは何を使う、といったことが記述されている
CINF:
ボーン(開発者はどうやらジョイントと呼んでいたっぽい)の情報
CMDL:
モデルのいろいろ。テクスチャなど
CSKR:
スキンの情報
関係あるかわからないデータ:
CPRM、CSMP、CAUD 難しいな〜CMDL
ていっても一番最初にあるスクリプトっぽいデータだけ難しくて後は単調な配列っぽいから、
最初さえ何とかなれば簡単そうだ
わかってることを書くと、
スクリプトは「データ型」「データサイズ」「データの種類」「データ」の順で並んでいる
データ型にはPASS、INT、CLRがあってPASSはデータのキー、INTは整数を表す。CLRはわからん
データサイズはバイト単位で指定される
データの種類はいろいろあり、CLR(データ型とは別みたい)、DIFF(Diffuse)、RFLV、RFLD、OPAC(Opacity)、TRAN(Transparent? Transformation?)などがある
ただ厄介なのが、データにはデータ型で指定されたもの以外にデータの種類に応じてプロパティが含まれる
これらの意味を一つ一つ理解していかないとモデルのインポート、エクスポートは実現できないだろう
また、スクリプト群の前と、個々のスクリプトの前にそれぞれヘッダが用意されており、それもほとんど意味が分からない
開発者はデータを一般的なモデリングソフト(3DS Maxやらmayaやら)で作成しているだろうからそれらのフォーマットを理解すればこのデータの理解にも役立つと思う
一応呼びかけるけど、3Dモデリングに詳しい人、どんどんご協力ください いちおうCMDLでぐぐってみたら、なんと、メトロイドプライム2はCMDLを使用するらしい
他にも被るデータが大量にあり、おそらくゲームエンジンは同じのを使っている
製作元は両方レトロスタジオ社で、過去の資産を有効に活用してるっぽい
ここらを調べればいろいろわかるかも 俺が一生懸命調べてたのはマテリアルのデータだったらしい
メトロイドプライム2のファイル解析プロジェクトMPxViewer(最新リリースが5月だが)のソースがクソ役立つ
これは解析が捗るわ 今mayaのチュートリアルを見て色々調べてる
RFLVやRFLDは反射が関係してそうだ、とかわかってきた
チラシの裏にでも書いてろって感じですねwww
要は活動してるよってことです MPxViewerの助けでCMDLの構造はほぼ理解してしまった
スキニングやアニメーションは後回しにするから、ひとまずビューワーを作成していこうと思う
そのためにはまず3Dプログラミングを学ぶところから始めなけりゃならないが 構造自体は大体わかったけど所々にある数値の意味が分からない
それに、メッシュデータの1エントリごとのサイズがまちまちで、どこに見分けるためのフラグなり文字列なりがあるかもわからない
一つ朗報なのはバーテックスデータの変換はできるようになった
テストしてみたところ花っぽいものが出てきた 俺が一番嫌いなのはバイナリ中にフラグが含まれている場合なのだが、CMDLはフラグだらけで非常に煩わしい
しかもビット単位でフラグが指定されているから8ビットすべて理解するにはかなり手間がかかる
ドンキー開発者の方は何ら困らないからしょうがないんだけれども… ふとどこかに開発者のデータとかないかなーって思うことあるよね
まぁ頑張れ そうだね
開発者のデータは無いけどWiiに関してはリバースエンジニアリングが進んでいるからその情報を元に推測してる
それにS○Kのドキュメントが流出してるからそれも参照しながらやってる
CMDLの状況だが、フラグは大体わかってきた
それでもまだ理解できていない数字がたくさんある
手伝ってくれるという人がいるなら、現在わかっていることを詳細に書くが…
いい加減しつこいかな wiiマリオみたいにエディターまで出来るのは時間がかかりそうだね
でも応援しているよ まあ、多人数でやってるわけじゃないしな
といってもwiiマリオのエディタも一人だった気がするし頑張ろうと思う
俺の見積もりで最も時間がかかると見たのがRAS音楽で、TXTR画像やCMDLモデルはその次にかかると見ていたから
ここを終えればエディタにだいぶ近づくはず 現在の進捗状況
ヘッダ部:ほぼ解析完了
マテリアル:結構残ってる。CMDL内では統一された数値でもMREAでは違うという値がある(MREAにもマテリアルがあることは前に言ったと思う)
バーテックス:解析完了
ノーマル:解析完了
UV:解析完了
メッシュ:ほぼ解析完了。謎のベクトルあり。ヘッダ部にはマテリアルや幾つかの項目への参照がある あ〜 メッシュがわからん
CMDL先頭のフラグによってメッシュのエントリのバイト数が1〜2バイト変化するが、それら増えたエントリの意味が分からない
そのフラグが付いているCMDLの個数を調べてみたところ、CSKR(スキン)データの個数とほぼ同一となった
面白い事にどのステージデータでもCSKRの個数はフラグonのCMDL数から3引いた数になっている
これらのことから判断して増えた1、2バイトはスキンメッシュアニメーションに関係する値であることは想像できる 「ドンキーコングリターンズ 改造」でググったら俺の動画とこのスレが一ページ目にきた
まあ、そんなキーワードで調べる奴はいないだろうし、あまり人寄には役にたたないな
CMDLのメッシュのエントリの先頭につく1バイトは必ず3の倍数になることがわかった
何を表しているんだろう
1.列挙体
3の倍数にする意味がない
2.データサイズ
なんのデータサイズだろうか? スキンメッシュアニメーションに関連があるという過程からすると、全く的はずれな推測になるが…
3.データの個数
同様に、なんのデータの個数だろうか?
4.オフセット
これはありえない 3の倍数だけ進んだデータはまだ同じエントリ内だから
5.フラグ
ありえる だが、3の倍数が(ry
6.ID
IDであればそれぞれ違う値になるはずだが、同じ数値を持ったエントリが大量にあることからこの推測は否定される
7.数値自体がメッシュの形状やアニメーションに影響する
この場合非常に厄介である。ゲームを動かしてみて実際に実験をしながらやっていくか、アセンブラを読みといて必死に解析するか、
運が良ければ他のモデルフォーマットから相当しそうな値を探し出すことが出来るか
いずれの場合でも非常に手間がかかるのは事実
しかも、「運がよければ」の選択肢である他のモデルフォーマットを参照する、という手段はとうの昔にやっているので残り2つの泥沼しか残っていない
数値自体が影響を与えていないことを願っている
そもそも、この追加の1〜2バイトがメッシュデータ内に存在するかどうか判定するためのフラグやらなんやらがヘッダ内に存在しない
ということは他のデータ部にそれが存在するか、あるいは「このデータが存在するから追加の1〜2バイトも存在する」といったデータ間の関連付けが存在するか
行き詰って行き詰って、もうだめかと思ったけど、スマブラやマリオカートで使用されているmdl0に類似したデータを発見した
というより、もろにCMDLのメッシュデータと同様の構造があった
ちょっとChadderzやKryalのソースコードを覗いてくるわ
これがダメだったら死ねる わかってきた わかってきたぞ
まず、メッシュデータに含まれる謎の1〜2バイトはやはりスキンメッシュアニメーションに関係ある
どう関係があるかはまだ調べてる
スキンメッシュアニメーションを疑い始めてずっと平行してCSKRデータの解析に挑戦してきたがようやくわかってきた
これは挫折せずに済みそうだ CSKRを完全に解析完了したのでフォーマットを書く
ヘッダ
0x0 タグ(ASCII文字列でSKIN)
0x4 バージョン(整数値0x3)
0x8 総エントリ数
エントリ
0x0 子エントリの個数
子エントリ
0x0 ボーンID
0x4 重みの値(浮動小数点数)
エントリのフッタ
0x0 参照カウント(だと思う)
エントリが並んだ後テーブルが2つある
最初のテーブルの先頭にはテーブルのエントリ数があり、符号付き16ビット整数値のエントリが続く
0xFFFFのエントリが含まれるがこれは何も参照していないエントリ
このエントリがバイト境界を合わせるために存在するのか、それとも他の用途があるのかは不明
テーブルのエントリ数は必ずスキンのエントリの個数に等しいことから、これは順番が重要になってくるはず
次のテーブルも同様に先頭にエントリ数があり、後に符号なし8ビット整数値のエントリが続く
これもエントリ数はスキンのエントリ数と等しくなるが、単純に0から1ずつ数え上げるだけなので、意味は不明
構造からしてCSKRのスキンのエントリをCMDLのメッシュデータが参照しているはず
何度も言うとおり、CMDLのメッシュデータは3の倍数になっていて、0〜0x1B、すなわち10段階の値しか取らない
しかしCSKRのスキンのエントリは何十個とある
したがってCMDLのヘッダにある謎の整数値が鍵となってくるはず 考えてみれば非常に簡単なことだ
・メッシュデータの値が10段階の値しか取らない
・メッシュデータはすべてのスキンのデータにアクセスできなくてはならない
この2つのことを考えると、メッシュデータはスキンデータに次のようにアクセスするはずである(というよりそうでなければおかしい)
スキンデータのインデックス=メッシュヘッダの整数値×10+メッシュデータの値÷3 メッシュエントリの解析が完了したのでフォーマットを書く
ヘッダ
0x0 サイズベクトル(多分)
0xC 不明(常に0x8000)
0xE メッシュデータのサイズ
0x10、0x14 パディング
0x18 CSKRエントリインデックスの10の位(>>72参照)
0x1A マテリアルのインデックス
0x1C 不明(常に0xFF)
0x1D CMDL先頭の文字列との対応を表す整数値
0x1E ステージのオブジェクトかどうか(多分)
これ以降はメッシュデータが続く
メッシュデータのヘッダ
0x0 コマンド(WiiのS○KにおけるGX関数のコマンド)
0x1 エントリ数
以下にエントリが続く
エントリは前から言っているように、バイト数が場合によって異なる
すべての内容が揃っている場合
0x0 CSKRエントリインデックスの1の位を3倍した数
0x1 上の数値に0x1E足した数
0x2 バーテックスのインデックス
0x4 ノーマルのインデックス
0x6 UVのインデックス それにしても、まだ見てくれている人はいるのだろうか
最近停滞し続けていたからもう見限られたかなww
残ったマテリアルを解析できればいよいよビューワーの製作に取り掛かれる
一部不明な値を残しつつ来たが、それはエクスポートを実装して実験すればいいし、RAS音楽のように色々入力する必要のない値も存在する
(RASにも音量関係の数値=重要な数値がありそうだと最近思い始めたが) いいんだ、定期的に書き込んでくれればモチベが保てる
欲を言うならDKDKを使ってみての感想やバグ報告なんかをしてくれると嬉しい ここいらでToDoリストを書いとく
・RAS音楽のコーデック作成←済
・TXTRのコーデック作成←パレット付き以外済 パレット付きは実装予定なし
・CMDLのコーデック←50%(把握は80%) CSKRのコーデック←ほぼ済
・CINF(ジョイントデータ)のコーデック
・ANIMデータのコーデック
・CHARデータのコーデック
・PARTデータ及びSWHCデータのコーデック
・MREAデータのコーデック
全体としてみるとスーファミ時代のドンキー並みに改造可能になるまでの道のりのうち半分以下ってところか
とはいえ、最難関の一つと見ていたCMDLの把握がそろそろ完了することを考えると、結構早く終わるかもな
半年以上必要だったら事情でそれ以降は一年以上作業ができないがorz
その場合はDKDKのソースを公開するか… マテリアルわかんねー
わかったことを羅列する
1.マテリアルにはヘッダがあり、フラグ、列挙体等が含まれる
2.ヘッダの後はアトリビュート(属性)とおぼしきものが存在する
3.属性にはCLR(データにキーを持つものとマテリアルの色をRGBAで表現するデータを持つものの場合がある)、TRAN(透過部分を示すテクスチャの情報)、INCA(発光部分を示すテクスチャの情報)
RFLV(反射?)、RFLD(反射?)、RIML(Rim Light、縁どりの光?)、DIFF(Diffuse?)などがある。
ヘッダの内容と属性は少なからず関係していて、因果関係をつかめないことにはインポータ、エクスポータは作れない
この中で特に意味が分からないのはRIMLで、必ず球体(例えばこんなの http://viploader.net/ippan/src/vlippan245103.bmp)が指定されている
この球体を使ってどうやって縁取りを描画しろと言うのだろうか?
そもそも、反射やらDiffuseやらはマテリアル自体に適用されるものであってテクスチャに適用されるものではない。
それなのに、あたかもテクスチャそれぞれに反射光やら拡散光やらを設定してそれを合成することで、マテリアルを構成するかのごとくデータが並んでいるのはどういうことだろう? うん?ちょっとまてよ
例のS○Kのドキュメントにはテクスチャそれぞれに光を設定できるようなことが書いてあるぞ
俺の勉強不足か? ひとまずビューワーを実装中
これが出来ればいろいろ実験できるし、モデルが表示できる事自体が楽しいはず DirectXに関しては全くの初心者なので試行錯誤してようやく三角形のレンダリングまで行えるようになった
モデル表示の基礎部分はできたので、続けて作っていこうと思う どうもモデルデータのフォーマットに間違いがあるっぽい
ドンキーのモデルが穴だらけになってしまった 下らんバグのせいで3、4日悩まされ続けて例のごとく諦めようかと思っていた…
ようやく正しくモデルを読み込めた
まだテクスチャがおかしいのでそこを修正したら画像を上げる 問題はほとんど解決したが、まだ一部問題が残っているので明日画像をアップしようと思う
まあ、ゆったり待っててくれ …絶賛ダウンロードありがとうございます
今のところ解析と関係ないDirectXで詰まってる
その問題が解決したらディディーのテクスチャの以上の原因を調べようと思う いつもの人がダウンロードしてくれたみたいだw
すぐ解決すると思ってたDirectXの問題が思ったより難しい
解決したらまた進捗状況を書くから少々お待ちを テクスチャ座標(UV)には二種類ある
一つは普通に32ビット浮動小数点型で記述されており、そのままUV座標として使える
もう一つは16ビット整数型で、浮動小数点型に変換した後何らかの数で除算するとUV座標に相当する値が算出できる
そして今日はその「何らかの数」を大量のデータから推測、実験して導出することに成功した
その結果がこちら
Kalimba
http://up3.viploader.net/ippan/src/vlippan248647.png
DK
http://up3.viploader.net/ippan/src/vlippan248646.png
DKは一目瞭然、kalimbaの方は一見正常だが、公式サイトで確認したところまだうまくいっていなかった
うーん、わからん 本日の成果
Diddy Kong
http://up3.viploader.net/ippan/src/vlippan248772.png
Donkey Kong
http://viploader.net/ippan/src/vlippan248773.png
単純にテクスチャが上下反対だったみたいだ
ただ、ドンキーのネクタイを見てみればわかるように、部分部分では反転している
もうそろそろテクスチャの基本的なところは終わりそう ドンキー
http://up3.viploader.net/ippan/src/vlippan248868.png
画像が左右反転していた理由が判明した
DirectXにおける座標系は左手座標系だが、Wiiゲームでは右手座標系らしい…
テクスチャの問題だったわけではないということ
ようやく異常がなくなったので、シェーダー作成にとりかかろうと思う
TRANあたりは簡単に実装できると思う TRANの実装が終わったがどうもよろしくない
どうやらTRANで透過する対象のテクスチャがCLRで指定されているもの以外の場合もあるようだ TRANで透過しているものの以外にCLRにアルファチャンネルを含む場合があるようだ…
そこまではわからないのでひとまず置いといて次のシェーダ作りに進むことにする… DirectXの仕様にはCMDLビューワーの実装を始めてから何度となくつまずかされてきたが、
今回テクスチャがまともに表示されない問題の原因をようやく突き止めた
テクスチャが正方形になっていないと自動的に正方形になるよう画像が切り取られるみたいだ…
(まあ、正確にはDirectXというよりD3DXの仕様だが)
まあ、まともに表示できそうなので、近いうちにアニメーションの実装に移る CINFの解析を始めたが例によって難しい
最初にあるものは明らかにジョイントの名前のテーブルだが、そのあとは単なる整数の羅列にしか見えない
しかも複雑なバージョンと単純なバージョンがあって更に複雑にしている …明けましておめでとうございます
このスレを見てる人はどれくらいいるかわからないけどまだ解析続けます
まあ、今年は徐々に厳しくなってくだろうけど >>97
一人でよく頑張るなぁ、なにもしてあげられないけれど
とりあえず、明けましておめでとうございます ここ最近忙しくて解析をしてない
まあ、焦ってもわかるものではないが、4月までくらいしか解析できないから少し頑張ろうかな
4月になったら解析を一年程中断する予定
一年後ヤル気があったらまたスレ立てして解析するかな… >>99
スレ立てしなくても1、2ヶ月くらいに1回保守してスレを再利用したほうがいいよ
1年後にはきっと外人がスマブラレベルの解析してくれてる・・・はず >>100
確かに、再度立て直したら励ましの言葉とかを0にしてしまうからよくないな
どんなに忙しくても保守くらいできるだろうし、そうしようかな もしかしてこのスレまだ生きてる?
3月には再開できるはず… さて三月になったわけだが、もう少し待ってほしい(待っているなら、だが) CINFのフォーマットだがおぼろげながらつかめてきた
0x0 magic
0x4 padding
0x8 numEntries
0xC unknown
0x10~ジョイント名
以降はオフセットではなくサイズ
0x4 padding
0x4 unknown num entries
0x4 unknown num entries2
0x2 padding
ここからジョイントの階層構造を示す1バイトの値のテーブル
0x4 padding
不明データ×エントリ数
0x1 padding
以降3次元ベクトルのテーブル(おそらく上から順にscale,rotation,translation)
直後に各エントリにつき1個の浮動小数点値(重み?)
その後意味不明な値がしばらく続き、各ジョイントのインデックスとおもわれるテーブルがあって最後にパディング 新生活忙しくて作業できない‥
一応3月終わりまで作業を楽にするツールを作ってたんだけど たいして返す言葉もない情けなさww
作業するなら夏になるかなー
3dsで移植が出るらしいから少しは注目集められるかな…? ドンキーの新作が発表されたみたいだね
WiiUの改造が進展したらそっちに移るだろうけど当面はこっちでやる
誰も待ってないだろうしほんとオ○ニーだわ >>113
こんなスレに書き込んでくれるとは…
リアルや他にやってることとの兼ね合いでこっちをやるのは(やるとすれば)かなりあとになると思う イラストレーターで収入が少ないからと30代後半で漫画家になろうとする、ひきこもりのバカ発見。
足立区に住んでいるそうだ
http://inumenken.blog.jp/archives/6609090.html /i/|ii!//|!/!i/´i/ .|i |/ノ i\i!゙、:iヽ|:::| ヽ 'i ! ヾi |'!ヽ::::||::::::/:::::::::::::::::::::ヽ
i i 川i!ハ/" _! | │ 川 ヾ:ii ゙'∨ | ゙ヾiヽヽ;||:::::i':::::::::::::::::::::::::
ノ ノ/リ,,,,,,二三テ=''" ヽノ ル |ノノヽヾ ノ 、,,,ノ,、 iヽ:::||:::::i'::::::::::::::::::::::::::::
/  ̄ ´~~゙'''' ゙''‐- ..,, ,, ‐' `゙ヾミッ、,, ヽ::|::::/::::::::::::::::::::::::::::
,,イ| i' i" `'‐=' `'|/i!:::::i::::::::::::::::::::::::
i | :::::::ヽ::::ヽ::::::ヾ:: ゙、 l 〃::::: i//::::ハ::::::::::::::::::i:::
i i \\\\\ヽ ) ヽ ′′′ / /:::::/:::::::::::::::::::|::::
! | i ,,ィノ < :::: : /:::::/:::::::::::::::::::/::::
i! i i! /i/ ,r''''‐y'''.;、 \ /:::::/:::::/::::::::::::/:::::
゙i! | i /⌒' 、 Y:::::::::''::;;;;'.;.Y'⌒゙i /::::::/::::::/::::::::::::/::::/i
i i ゙! ん、,,__ヽノ:::::::::::::::::::;;;;;{,__,,,r'' /:::::::/::::::/::::::::::::/:::://
゙、ii! ゙| i ノ ゝ;;;:::::::::::::::::::;ノ 。 `i //:::::/:::::/::::::::::::/::::::/:::
ヾ!トl ゙iU i 。l '゛.. ‐ー:::::i | //::::::/::::::/::::::/:::/:::::i!::::::
iiミ! ハ i l ,,,,::: :::;;;;;...{ ° ゙、 //::::://::::/::::::/:::::/::::i::::i/
i!ヾ!i ゙、! , ' |::: ::::ヽ ..} |゙ヽ......,.,.,.,,,///://::://::::/::::://::::i::::リ
!ヽヾi i゙、 ___,,,/ }:: : ;;;::: ::::::::} レWノ'レi/、//::/:://:/:::/::/:::/ 誹謗中傷
ひわいちゅうしょう
脊髄反射
こつずいはんしゃ
十人十色
じゅうにんじゅっしょく
汎用
ぼんよう
鑑
おり
黎明期
そうめいき
市場原理
いちばげんり
満身創痍
まんしんそうしつ
明鏡止水
めいかがみとめみず
毀誉褒貶
めいいうほめなぐさめ
不撓不屈
ふこうふとつで
一期一会
いっきいっかい
仰る
あおる
孕ませる
もませる
貶める
なだめる
蔑む
ひさむ
滞る
おちいる
嵌める
いさめる
宥める
さだめる
棘魚
くさぎょ
暴飲暴食
ばくよくばくいん
弄られる
ほうられる
貶める
けなしめる
餡子
ぎょうざ
贔屓
ぐぐつ /i/|ii!//|!/!i/´i/ .|i |/ノ i\i!゙、:iヽ|:::| ヽ 'i ! ヾi |'!ヽ::::||::::::/:::::::::::::::::::::ヽ
i i 川i!ハ/" _! | │ 川 ヾ:ii ゙'∨ | ゙ヾiヽヽ;||:::::i':::::::::::::::::::::::::
ノ ノ/リ,,,,,,二三テ=''" ヽノ ル |ノノヽヾ ノ 、,,,ノ,、 iヽ:::||:::::i'::::::::::::::::::::::::::::
/  ̄ ´~~゙'''' ゙''‐- ..,, ,, ‐' `゙ヾミッ、,, ヽ::|::::/::::::::::::::::::::::::::::
,,イ| i' i" `'‐=' `'|/i!:::::i::::::::::::::::::::::::
i | :::::::ヽ::::ヽ::::::ヾ:: ゙、 l 〃::::: i//::::ハ::::::::::::::::::i:::
i i \\\\\ヽ ) ヽ ′′′ / /:::::/:::::::::::::::::::|::::
! | i ,,ィノ < :::: : /:::::/:::::::::::::::::::/::::
i! i i! /i/ ,r''''‐y'''.;、 \ /:::::/:::::/::::::::::::/:::::
゙i! | i /⌒' 、 Y:::::::::''::;;;;'.;.Y'⌒゙i /::::::/::::::/::::::::::::/::::/i
i i ゙! ん、,,__ヽノ:::::::::::::::::::;;;;;{,__,,,r'' /:::::::/::::::/::::::::::::/:::://
゙、ii! ゙| i ノ ゝ;;;:::::::::::::::::::;ノ 。 `i //:::::/:::::/::::::::::::/::::::/:::
ヾ!トl ゙iU i 。l '゛.. ‐ー:::::i | //::::::/::::::/::::::/:::/:::::i!::::::
iiミ! ハ i l ,,,,::: :::;;;;;...{ ° ゙、 //::::://::::/::::::/:::::/::::i::::ii::
i!ヾ!i ゙、! , ' |::: ::::ヽ ..} |゙ヽ......,.,.,.,,,///://::://::::/::::://::::i::::リ::
!ヽヾi i゙、 ___,,,/ }:: : ;;;::: ::::::::} レWノ'レi/、//::/:://:/:::/::/:::ハ:i |:: \ ,
、 | ヽ /
\ | x|ー/‐- 、 r‐、
, -―\l_ /`ヽー==ミx、 \ r勺人__
/ / !| \ 丶 l:|;;/;;;;___;;}
/:/ / / / 从 {丶 \ :\弌;;;;/ //
l:/ / / 〃/l/ヽ \\-‐\:::.....lハ: 〉;;三;;(
/ / /| | l|-|‐-、\ト ィ==y!:::::/l::| {又又} x%フ广l
ー=彡イ:::/::. ,.::|::..::Vィ==ミ 、 \ ノ/! |/‘7¬イ /%゚//
|:::l|::::|::|/乂:::::ヾ _, -―1/l|ノ}/ / / //゚//
|:::i|::人| l |≧ァ`` ヘ/ | 八 | / / /ヽ_彡 '
乂l' \/ / ゝ、 \ _,ノ / \/ / / /
/丶{ `≧ァーく( _,> '´ / Xニ⊇:′
/ /⌒ ¬f工¨| /、 \ ./ r「’|
/ / ||__」 レ=≦、 / /「| | l|
/ /l , -―ァ≠¨l | ;/ |\,_/ /}又又i「 - 、
/ / /,,;| /,; 〃ヽノ/, |/ ∠_ ‘7¬イ \
/ / _ /,,;;;l>'´,,,;;;; / / /^l/ /;;;/ `Y | \ 丶
/ / 〈 〈>'´; .;;;;;;;;;;;;;;;;;;;;;;/_/ // /`≧'‐ 、ヽ 〉 丶 |
,':/i ∧_〉,,;;;;;;;;/´ ̄ ̄´ / /ヽ\ `>-'^\ ヽ |
/' | ∨,,;;;;;;;;;/ / / o:} } || | l |
,: | \;;;;;;;| /\./ / .// || | | /
| | \| \ x/ .// || / /'
l 八 ∧ \/\o / /;;\ l/ /
爪 弾 く は 荒 ぶ る 調 べ ! キ ュ ア メ ロ デ ィ ! /i/|ii!//|!/!i/´i/ .|i |/ノ i\i!゙、:iヽ|:::| ヽ 'i ! ヾi |'!ヽ::::||::::::/:::::::::::::::::::::ヽ
i i 川i!ハ/" _! | │ 川 ヾ:ii ゙'∨ | ゙ヾiヽヽ;||:::::i':::::::::::::::::::::::::
ノ ノ/リ,,,,,,二三テ=''" ヽノ ル |ノノヽヾ ノ 、,,,ノ,、 iヽ:::||:::::i'::::::::::::::::::::::::::::
/  ̄ ´~~゙'''' ゙''‐- ..,, ,, ‐' `゙ヾミッ、,, ヽ::|::::/::::::::::::::::::::::::::::
,,イ| i' i" `'‐=' `'|/i!:::::i::::::::::::::::::::::::
i | :::::::ヽ::::ヽ::::::ヾ:: ゙、 l 〃::::: i//::::ハ::::::::::::::::::i:::
i i \\\\\ヽ ) ヽ ′′′ / /:::::/:::::::::::::::::::|::::
! | i ,,ィノ < :::: : /:::::/:::::::::::::::::::/::::
i! i i! /i/ ,r''''‐y'''.;、 \ /:::::/:::::/::::::::::::/:::::
゙i! | i /⌒' 、 Y:::::::::''::;;;;'.;.Y'⌒゙i /::::::/::::::/::::::::::::/::::/i
i i ゙! ん、,,__ヽノ:::::::::::::::::::;;;;;{,__,,,r'' /:::::::/::::::/::::::::::::/:::://
゙、ii! ゙| i ノ ゝ;;;:::::::::::::::::::;ノ 。 `i //:::::/:::::/::::::::::::/::::::/:::
ヾ!トl ゙iU i 。l '゛.. ‐ー:::::i | //::::::/::::::/::::::/:::/:::::i!::::::
iiミ! ハ i l ,,,,::: :::;;;;;...{ ° ゙、 //::::://::::/::::::/:::::/::::i::::ii::
i!ヾ!i ゙、! , ' |::: ::::ヽ ..} |゙ヽ......,.,.,.,,,///://::://::::/::::://::::i::::リ::
!ヽヾi i゙、 ___,,,/ }:: : ;;;::: ::::::::} レWノ'レi/、//::/:://:/:::/::/:::ハ:i |:: ■ このスレッドは過去ログ倉庫に格納されています