我は知を探求する者なり!(10)


業者は本当にスパムメールを電話番号に対してしらみ潰しに送っているのか?FOMAからmovaにSMS(ショートメール)を送った場合どうなるのか?


送れない。また、その場合は、課金されない。だから、しらみ潰しに送って問題ない。


FOMAからSMSを送信するのに本当にFOMAのボタンに半田付け等が必要で、かつ1通の送信に15秒前後かかるというのならばFOMAだとわかっている番号にだけに送信することは出来ないのか?


FOMAの存在する番号が書かれた名簿があれば出来る。


その番号名簿はどうやれば用意できるのか?


FOMAmovaと区別すれば良い。たとえば、FOMAからテレビ電話を発信すれば良い。相手がmovaであれば、接続は拒否されるはずだ。


番号名簿を作成するためにテレビ電話の発信しなくてはならないとして、そのために改造FOMAが必要になるのだとしたら本末転倒ではないか?


そうではない。テレビ電話発信に改造FOMAは必要ない。なぜなら、P900iに付属のCDのOBEXのドライバでメールの送信が出来ないことは実証済みだが、テレビ電話の発信ならばCOMポートのドライバさえあればATコマンドでテレビ電話発信は出来るだろう。ATコマンドはP900iに付属のマニュアルに一覧が載っているしリザルトも容易に得られる。この方式ならば、USBケーブルさえあればいいだけだ。このとき改造FOMAは必要ない。必要なのはUSBケーブルのみだ。


ATコマンドでテレビ電話発信を行ない、リザルトを得ようとした場合、実際にコールしてしまわないか?


1コールないし2コールしてしまうだろう。


その場合、その番号の携帯に着信履歴が残らないか?


残るだろう。非通知で発信は出来るが..。(ヒロシが、昨年「私の携帯に非通知でテレビ電話が掛かってきます。…私に一体何を求めてるのですか…ヒロシです」というネタを披露していたが、それは、これが原因だ。)


着信履歴を残さずにFOMAmovaかを判別することは出来ないのか?


出来る。FOMAからmovaにかけたときは100ms以内に通話中音が鳴る。FOMAからFOMAにかけたときは、500ms以上の無音時間があって、そのあと呼び出し音が鳴る。つまり、100ms以内に判定できるし、その間に接続を切ってしまえば相手の携帯には着信履歴は残らない。


それは音声認識をしないといけないのではないか?


いや、ガボア変換(id:yaneurao:20040814)ぐらいで十分だろう。


その場合、サウンドカードを複数接続する必要があるのではないか?そんなことが出来るのか?


出来る。まともなPCIサウンドカードを使えばPCIスロットの数までならば同時にマイク端子から入力することが出来る。(id:yaneurao:20041013,id:yaneurao:20041114で実証済み)


では、業者はそのような方法でFOMAの番号を洗い出しているのか?


それは考えられない。COMポートを使うのとでは実装コストが違いすぎる。


本当に業者はFOMAの番号の洗い出しのためにFOMAを用いているのか?


用いていないかも知れない。テレビ電話の通信規格はCCITT(現在のITU-T)によって勧告されている。よって、INS回線網を通じてテレビ電話発信することだって可能だ。INS1500ならば、23回線を同時に扱えるので、月々の回線使用料が31,000円だから1回線あたりのランニングコストは1,348円。これは明らかにFOMAの基本使用料より安い。だから業者がINS1500を使っていてもおかしくはない。


送信している業者は本当に一つなのか?


(゜Д゜)! そうか。業者は一つではないだろう。この暗号を送ってくるスパムに書かれているURLをしらみ潰しに調べたところ、最後のcheck sumをcheckしていないサイトがあった。また、「ILOVEHACKR」に含まれない文字(たとえばB,D,F,G,..)を0として扱っているサイトもあった。すなわち受け側のphpは製作者が異なると考えるのが自然だ。


だとしたら、送信側を作った者は、なるべく受け側のphpが作りやすいようにわかりやすい暗号を採用したのだとは考えられないか?


かも知れない。しかし、それならばcheck sumを100で割った剰余にするだとか簡単な方法で冗長性を省くことは十分に可能だったはずだ。それをしなかったのには、何か別の意図があったのだと思われる。


100で剰余することすら受け側の業者に説明するのが面倒だったということは?


それは考えられない。いくつかILOVEHACKR方式の暗号を調べたときにcheck sumが合致しないものがあった。それらは、暗号化係数として定数倍して100万で剰余したものをcheck sumとしてつけてあった。(id:alea:20050623#1119469027) すなわち、最初から100万での剰余は必要なわけで、この100万という定数をもっと小さな定数にすることにより冗長性を回避できたはずだ。それをしなかったのはこの暗号を解析しやすくする意図があったのと、また、この各文字のweight(係数重み付け)にこだわったからに他ならない。


では、なぜ業者はそこまでしてこのweightにこだわる必要があったのか?
(つづく)