ウェットウェアは使わないと性能が低下しまくると言われます。
　が。
　ブルートフォース解析の仕上げに使うのはやっぱりヘボいので。

　そこで、ちょっとした思い付きツールを作ってみる。バイトデータのヒストグラム生成だ。
　例によってPerlで秒殺してみる。

@histogram = (0) x 256;

while (<>) {
  for my $i ( 0 .. length()-1 ) {
    $histogram[ ord( substr $_, $i, 1 ) ]++;
  }
}

@histogram{ 0 .. $#histogram } = @histogram;

foreach my $key ( sort { $histogram{$a} <=> $histogram{$b} } keys %histogram ) {
  printf "0x%02x: $histogram[$key]\n", $key;
}

　こんな感じだな。
　ASCII入力で読み込んじゃうけど誤差だから気にしない。本当は気になるから書き直したけど、ついでに色々手を入れて長くなってしまったので。

　早速、色々と実験してみる。
　ふむふむふむ。シフトJISの日本語テキストでは0x82が断然多いのか。全角ひらがな英数の頭だな。
　そこから大幅に減って、二位争いになるのが0x81と0x83。前者は全角記号、後者は全角カタカナ。0x81が大優勢なことが多いけど、文書の傾向によって0x83が大逆転したりするっぽい。それほど調べてないけど。カタカナはもっと出てくると思ってた。
　HTMLでもそんな感じ。タグ記号の0x3cと0x3eが多いかと思ったが、0x81-0x83に比べたら全然。改行コードといい勝負な程度。あとHTMLだと0x3cと0x3eの数が同じだった。スクリプトとか埋まってなければ当然か。>とか書かないで手抜きしたり、preタグ入ったりすると分からんが。
　ゲームのスクリプトなんかだと、0とかが異様に優勢になったり。例の会社のスクリプトもそうだし、アルフレッドもそうだった。命令コードの類も少なくはないが、やはり0x82に比べたら全然。

　うーん、0x81の多さがやっぱり気になる。
　最初は句読点で地味に稼いでるのかなあと思ったけど、句読点を極力排除した特殊な文章でも0x81優勢。謎。
　んじゃ文字単位のヒストグラムを作ってみるか。当初の目的を明らかに外れ始めているが。

@histogram = (0) x 65536;

sub is_dbc_head ($) { # 対象コードセットで2byteコードの1バイト目なら真を返す
  my $c = shift;
  return ( $c >= 0x81 and $c <= 0x9f ) or ( $c >= 0xe0 and $c <= 0xef );
}

foreach my $file ( @ARGV ) {
  next unless -f $file;

  open IN, $file;
  binmode IN;
  local $/ = undef;
  $_ = <IN>;
  close IN;

  for ( my $i = 0; $i < length(); ++$i ) {
    my $o = ord( substr $_, $i, 1 );
    $o = $o * 256 + ord( substr $_, ++$i, 1 ) if is_dbc_head $o;
    $histogram[$o]++;
  }
}

@histogram{ 0 .. $#histogram } = @histogram;

foreach my $key (
  sort {
    $histogram{$a} <=> $histogram{$b}
    or $a <=> $b
  } keys %histogram )
{
  next if $histogram{$key} == 0;
  my $c = chr( $key % 256 );
  $c = sprintf "\\x%02x", $key unless $key >= 0x20 and $key <= 0x7e;
  $c = chr( $key / 256 ) . chr( $key % 256 ) if $key >= 256;
  printf "$c(%02x): $histogram[$key]\n", $key;
}

　こんな感じで。
　結局、ASCII入力対策版を貼ってる訳だが。同時進行でblog書いてるからこんなことに。

　で、ヒストグラム生成開始。
　さすがに文書によって傾向が大幅に変わる。旧日記2004年版だと、

1. r(72): 2163
2. >(3e): 1980
3. <(3c): 1980
4. \x0d(0d): 1948
5. \x0a(0a): 1948
6. b(62): 1921
7. 。(8142): 1870
8. い(82a2): 1596
9. な(82c8): 1512
10. の(82cc): 1321
11. か(82a9): 1290
12. 、(8141): 1265
13. と(82c6): 1216
14. て(82c4): 1130
15. し(82b5): 1101
16. で(82c5): 1084
17. に(82c9): 1055
18. た(82bd): 1020
19. っ(82c1): 1005
20. ー(815b): 975
21. 　(8140): 956

　こんなん。

　なるほど、全角スペースが0x8140か。超納得。
　でも音引きの方が多いのな。
　何しろ若者だからな。

　これが某ゲームのバイナリスクリプトだと、音引きも全角空白も句読点も全然出てこない。でもスクリプトの都合で多用されてる全角記号があるせいか、0x81優勢。
　アルフレッドも全角空白、句読点、三点リーダ、カギ括弧が超強力。
　ゲームのシナリオテキストって何気に厳しいルールに沿ってること多そうだよな。窓狭いからなあ。

　とまあ、0x81の優勢になる理由がバラバラなことは分かった。
　むしろ0x83が安定してて、0x81が暴れ馬なのか。

　んじゃ次は生BMPのヒストグラムでも作ってみるか（笑）。
　と、冗談半分に試してみたら、0がやはり強かった。0xffも絵によっては強い。でも、さすがに絵の傾向で大きく変わるだろうからなあ。

　圧縮データでやってみるか。
　…0がかなりの勝率で一位じゃん。一位にいないと思ったらビリだったり。まあ0って便利だしな。素直にフォーマット作ると0が多くなるのか。

　こんなところか。
　日本語だと踊る人形の解読は難しそうだなあ、と思った。記号以外では「い」「の」が強い傾向みたいだけど。いやエロゲンガーの人じゃなくて。