logo
code:Haemophilus influenzae

ここに書かれていることは無保証です。同じことを行って問題が発生しても、 龍義は責任をとりません。

2003年9月
2003年10月
2003年11月
2003年12月
2004年1月
2004年2月
2004年3月
2004年4月
2004年5月
アイコンの説明

6/1
LivingGate
昨日の続きで、 kernel の作成。今度は 2.4.26 の kernel でやってみた。適当に
make menuconfig で選んで、コンパイル。

[toyota@kashyyyk]% make zImage
〜snip〜
sh3-linux-gcc -D__KERNEL__ -I/home/toyota/kernel/linux-2.4.26/include -Wall -Wst
rict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame
-pointer -ml -m3 -pipe   -nostdinc -iwithprefix include -DKBUILD_BA
SENAME=mach_hp600  -c -o mach_hp600.o mach_hp600.c
mach_hp600.c:31: `hd64461_inb' undeclared here (not in a function)
mach_hp600.c:31: initializer element is not constant
mach_hp600.c:31: (near initialization for `mv_hp620.mv_inb')
mach_hp600.c:32: `hd64461_inw' undeclared here (not in a function)
mach_hp600.c:32: initializer element is not constant
mach_hp600.c:32: (near initialization for `mv_hp620.mv_inw')
mach_hp600.c:33: `hd64461_inl' undeclared here (not in a function)
mach_hp600.c:33: initializer element is not constant
mach_hp600.c:33: (near initialization for `mv_hp620.mv_inl')
〜snip〜
mach_hp600.c:149: `hd64461_irq_demux' undeclared here (not in a function)
mach_hp600.c:149: initializer element is not constant
mach_hp600.c:149: (near initialization for `mv_hp690.mv_irq_demux')
make[1]: *** [mach_hp600.o] Error 1
make[1]: Leaving directory `/home/toyota/kernel/linux-2.4.26/arch/sh/kernel'
make: *** [_dir_arch/sh/kernel] Error 2

ファイルを検索したりして、 mach_hp600.c に asm/io_hd64461.h を include して
解決したが、さらに別な問題が。

[toyota@kashyyyk]% make zImage
〜snip〜
make CFLAGS="-D__KERNEL__ -I/home/toyota/kernel/linux-2.4.26/include -Wall -Wstr
ict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-
pointer -ml -m3 -pipe " -C  arch/sh/kernel
make[1]: Entering directory `/home/toyota/kernel/linux-2.4.26/arch/sh/kernel'
make[1]: *** No rule to make target `7751setup_se.o', needed by `kernel.o'.  Sto
p.
make[1]: Leaving directory `/home/toyota/kernel/linux-2.4.26/arch/sh/kernel'
make: *** [_dir_arch/sh/kernel] Error 2

先が長くなりそうなので、寝ることにする。

6/2
LivingGate
LivingGate i に telnet で login できるようになったは良いが、1ユーザしか
login できない。

[toyota@kashyyyk]% telnet calamari
Trying 10.1.0.80...
Connected to calamari.
Escape character is '^]'.
telnetd: All network ports in use.
Connection closed by foreign host.

だそうだ。で、 netkit の source を見てみたら、

    pty = getpty();
    if (pty < 0)
        fatal(net, "All network ports in use");

となっており、getpty 関数は openpty を叩いているようである。簡単に言うと、
pty が足りない。LivingGate i に login して、 /dev を見てみた。

bash-2.04# ls /dev/pty*
/dev/ptyp0

あらら。ということで、増やすことにした。

bash-2.04# cd /dev
bash-2.04# mknod ptyp1 c 2 1
bash-2.04# mknod ptyp2 c 2 2
bash-2.04# mknod ptyp3 c 2 3

で、 login してみる。

[toyota@kashyyyk]% telnet calamari
Trying 10.1.0.80...
Connected to calamari.
Escape character is '^]'.
telnetd: /dev/ttyp1: No such file or directory
.

Linux 2.4.0-test1+sh-patch+w
Kernel 2.4.0-test1 on a sh
Connection closed by foreign host.

で、接続が切れてしまった。早速 ttyp の作成。

bash-2.04# mknod ttyp1 c 3 1
bash-2.04# mknod ttyp2 c 3 2
bash-2.04# mknod ttyp3 c 3 3

これで、4本 login できるようになった。

6/3
LivingGate
5/31 の続き。 kernel を作り直しても、うまく反映されない。試しに、 Makefile の
Version を書き換えてみた。zImage を LivingGate i にコピーして、再起動してみた。
ダメ。

bash-2.04# uname -r
2.4.0-test1

と、変わらない。 flash から起動しているのかなぁ…。試しに zImage を削除してみた。

bash-2.04# rm /boot/zImage

これで、再起動。問題なく、起動するし。ということは、別の kernel 書き換え方法を
考えなくてはいけないのか。

6/4
LivingGate
LivingGate i の起動 kernel の書き換え方を探る。とりあえず、フラッシュに
アクセスできるかチェック。それらしきデバイスを探す。

bash-2.04$ ls /dev
DAC          full  hda8     nvram     ptyp4  ram4    tty1   ttyp0   urandom
DAC-old      hda   hda9     powerctl  ptyp5  random  tty2   ttyp1   zero
LED          hda1  hde      ppp       ptyp6  rtc     tty3   ttyp2
WAW_RTC      hda2  initctl  ptmx      ptyp7  stderr  tty4   ttyp3
access_type  hda3  initrd   pts       ram    stdin   tty5   ttyp4
ccdc         hda4  kmem     ptyp0     ram0   stdout  tty6   ttyp5
console      hda5  log      ptyp1     ram1   tap0    ttyS0  ttyp6
fd           hda6  mem      ptyp2     ram2   tty     ttyS1  ttyp7
flash        hda7  null     ptyp3     ram3   tty0    ttyS2  update

それらしきものを cat で読み出してみる。

bash-2.04$ cat /dev/flash > flash
bash-2.04$ cat /dev/nvram > nvram
bash-2.04$ cat /dev/update > update

サイズを見てみる。

bash-2.04$ ls -la
〜snip〜
-rw-r--r--    1 test     root        36864 Jun  4 00:37 flash
-rw-r--r--    1 test     root          114 Jun  4 00:36 nvram
-rw-r--r--    1 test     root      4153344 Jun  4 00:38 update

nvram を見てみたが、 0x00 と 0xFF の繰り返しのファイル。コレは、違う。
flash も違うなぁ。試しに中を見てみたら、 admin のパスワードなどが格納されて
いた。 CF 無しで起動したときも、共通に使用したいものが入っているようである。

最後の望みが update か。中を見たけど、よくわからない形式。 strings を通しても
何も吐き出されないし。 kernel ソースを読め、ということか。先はまだまだ長い。

6/5
Network
いろいろなところから 3fd5f493.1080802@tatsuyoshi.net 宛にメールが来ているようである。
もちろん、そんなユーザはいないので、弾き返すのだが、どんな内容のメールが来ているのか
気になったので、適当なユーザの alias にしてみて、中身を見てみた。見てがっくり。

〜  メーリングリストメンバではありません  〜

あなたは、このメーリングリストのメンバではありません。

このメーリングリストへの質問等は、下記のアドレスまでお願いします。

****@***.biglobe.ne.jp

以上

他のも、 virus の自動返信か何かでしょう。

6/6
Other
バイナリエディタ hi の更新。もう1本、プログラムを作成したのだが、現在 Linux で
テスト中。

6/7
Other
gzip って RFC1952 で定義されているのね…。知らなかった。昨日作ったもう1つの
プログラムはファイルから gzip のヘッダーをみつけるもの。しかし、 RFC を読み
直して、作り直しになった。gzip は

0バイト目 0x1f
1バイト目 0x8b
2バイト目 0x08

で始まる。3 バイト目の bit 3 が 1 だったら、つまり 0x08 との & が 1 だったら
ファイル名が格納されているので、10 バイト目から NULL で終わるファイル名を
抽出することができる。で、良いのかな。あ、違うな、その前に 0x04 との & が 1
だったら、FEXTRA が入っているので、そのあとになるのか。 とりあえず、の
プログラムなので 0x04 は考えないことにしよう…。

6/8
Other
昨日の RFC を読んで、 1f8b.c の修正と公開。久しぶりに C で書き直してみた。
…、なんか、こういきなり C の source ファイルを置くだけ、ということをするから
敷居が高いページって人に言われてしまうのかな…。 dd コマンドだけでも、かなり
敷居が高いらしい。時間があったら、それらの解説ページで作ってみようかな…。

6/9
Other
デジカメ、リコー Caplio G4 レビュー。いつものように写真があるので、別ページです。
1cm マクロって、すごい。

で、こいつを軽く解析してみたのだけど、 Nucleus PLUS - Version ARM6/7/9  1.11.17 で
動いているらしい。なんだかね。

6/10
GATEWAY Profile
Profile[bespin] に ntp サーバの機能を持たせていたのに、気が付くと繋がらない。
port scan をしてみたのだけど、返ってくるのは ssh と dns のサーバだけ。はて、
と調べてみたら、 ntp サーバが死んでた。と言うか、

[toyota@bespin]% ps -ef | grep Z
  118 root            Z   [syslogd]
  159 root            Z   [busybox]
  242 root            Z   [ntpd]
  370 root            Z   [sshd]
  371 root            Z   [tcsh]
  496 root            Z   [ssh]
  746 root            Z   [sshd]
  747 root            Z   [tcsh]
  825 root            Z   [sshd]
  826 root            Z   [tcsh]
  845 root            Z   [sshd]
  846 root            Z   [tcsh]
  855 root            Z   [slogin]
  963 root            Z   [ssh]
 1506 root            Z   [sshd]
 1507 root            Z   [tcsh]
 1557 root            Z   [ssh]
 1616 root            Z   [sshd]
 1626 root        368 S   grep Z

…。駄目ジャン。昨日、 initrd を作り替えようとして、 /tmp を溢れさせた
影響かなぁ…。とりあえず、 ntpd だけ再起動して、 ntpq で動作の確認はした。
で、外から nmap で port scan をしたのだけど…、応答がない。試しに ntpdate で
指定してみたら、問題なく応答した。そうか udp は応答しないのか…。

[root@kashyyyk]% nmap -sU -p1-200 bespin

PORT    STATE SERVICE
53/udp  open  domain
123/udp open  ntp

これで、反応した。問題ないようである。本当は、再起動させて、残りのゾンビを
綺麗にしたかったのだが、このマシン、キーボードがないと起動しない。つまり、
再起動するには、後ろのコネクタにキーボードを差し込まなければならないのである。
なんで、面倒だし、問題なく named も ntpd も sshd も動いているみたいだから、
見なかったことにしようかと。あ、 syslogd が動いていないのは問題だから、
syslogd の再起動だけしておこう。

6/11
Network
メインのマシンで、 web 巡回をしていたのだけど、急に接続エラーが出た。はて、
と ping を打つが、家の router からも応答がない。これはやばい、と router を
見に行ったのだが、問題なく動いている。で、机の奥にある 10/100 の 8port HUB を
見てみたら、link-up LED がナイトライダーの如く、点滅している。あ、壊れたな、
と直感的にわかって、止められないサーバだけ 10/100/1000 の 4port HUB に繋ぎ
直したら、その瞬間に 8port HUB が復活した。はて、問題だったのは、 8port HUB か、
それとも、その HUB に接続していたマシンなのか。不明なので、とりあえず、様子を
見ることにした。ちょっと怖いな。さっさと、 24port HUB に繋ぎ直そうかな…。

6/12
Other
バイナリエディタ hi の更新。 undo 機能の追加を行おうと思ったけど、思った以上に
面倒なので、あきらめた。

6/13
Network
IO-DATA WN-AG/BBR のファームウェアの解析をした。本当のことを言うと、最初は
マイクロ総研のファームウェアを解析してた気がするけど、挫折した。マイクロ総研の
ファームウェア、難しすぎ。

6/14
Network Other
unicode を調べてみた。しかし、調べる前で、私が思いつくものは、ucs2, utf7, utf8
だったのだけど、まだまだ種類があるらしい。ucs2, utf8 ぐらいに対応していれば
なんとかなる感じだけど。こいつらを SJIS と EUC に変換するコードを書かなければ
ならない。面倒だ。その前に、世界の文字コードが混沌としていたので、それを
1つにまとめようと、 unicode を作ったはずなのに、 unicode にこんなに種類が
あったら、全然意味ないじゃん…。

6/15
Network Other
昨日の続き。親切な方が iconv 関数の存在を教えてくれたので、試してみることに
した。早速 cygwin に iconv 周りを入れて、いざ、コーディングになって…。
バイナリエディタ hi(t) に組み込もうと思っていたのだけど、画面やこれまでの
source の関係などから、1文字ずつの変換。効率が非常に悪いことに気が付いた。
はて、 hi(t) の source をごっそり書き直すか、 utf8 -> sjis の関数を作るか、
どうしよう。

6/16
Network
LINKSYS WRV54G-JP のファームウェアの解析をした。最近 Linux が多いなぁ。ちょっと
変わったことをさせるには、 Linux 使った方が楽なのだろうけど…。

6/17
WWW Network
月曜日から web サーバの出力 log 形式を変更し、Referer と User-Agent もとるように
したのだけど、えらい log が見づらくなった。で、いくつかわかったことが。

・思ったよりも google のキャッシュを使っている人が多い
・同じく、色々なブラウザを使っている
・意外な検索語でも、私のページが出てしまう

ページの内容が内容なので、なるほど、と思ってしまうところもあるけど。しかし、だ、
「toyota bB」で私のページが出るのは、どうかと。

6/18
Network
という訳で、 UTF-8 から SJIS に変換したいので、色々と調査。 RFC でも決まっている
みたいで、 RCF3629 をざっくりと眺める。元は RFC2279 だったのか。

Char. number range  |        UTF-8 octet sequence
   (hexadecimal)    |              (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

4バイト(オクテット)まであるんだ。で、日本語は3バイトみたいなので、2バイトと
4バイトの文字は無視して良いのかな。 UTF-8 → SJIS の変換表はないみたいなので
(探せばあるかもしれないけど)、 UTF-8 → UCS2 → (JIS →) SJIS とすれば良いのかな。
UTF-8 → UCS2 は

if(3バイト UTF-8 だったら){
  ucs2[0] = ((utf8[0] & 0xF) << 4) + ((utf8[1] & 0x3C) >> 2);
  ucs2[1] = ((utf8[1] & 0x3) << 2) +   utf8[2] & 0xF;
}

こんな感じか。動かしてないから、自身ないけど。

6/19
Network
Persol BSR14 のファームウェアの解析をした。そう言えば、 Yokohama X-VACCINE
って既に活動してないんだよなぁ。これから書くものは Tatsuyoshi Networks に
しようかな。

6/20
Other
ガソリンタンクの錆び落とし with Verity Super TC。ガソリンタンクって、すぐに
錆びるものなので、プラスチック製にして欲しいよなぁ。せめて、もう少し錆びない
素材にして欲しい。というわけで、今回も写真があるので、別ページに。

6/21
Other Network
バイナリエディタ hi に UTF-8 対応を施してみた。まだ、コーディング中なので、全く
動作しないのだけど。変換するときに使っている元テーブルは unicode.org にあった
JIS0208.TXT で、こいつを配列にいれたのだけど、結構なサイズ。とりあえず、
コンパイルしてみた。環境は cygwin 。

[toyota@geonosis]% ls -la hi.exe
-rwxr-xr-x    1 fe03007  なし       564037 Jun 21 14:46 hi.exe
[toyota@geonosis]% strip hi.exe
[toyota@geonosis]% ls -la hi.exe
-rwxr-xr-x    1 fe03007  なし       346624 Jun 21 14:46 hi.exe

こんなサイズ。組み込む前は

[toyota@geonosis]% ls -la hi.exe
-rwxr-xr-x    1 fe03007  なし       301864 Jun 21 14:49 hi.exe
[toyota@geonosis]% strip hi.exe
[toyota@geonosis]% ls -la hi.exe
-rwxr-xr-x    1 fe03007  なし        84480 Jun 21 14:49 hi.exe

unicode の変換テーブル、恐るべし、だな。このまま実装をするか、最適化をするか
考え中。

6/22
Terminator K7-DDR
jffs2 のイメージファイルをマウントしたいので、 Linux kernel の作成し直し。
kernel 2.4.26 をダウンロードして、make menuconfig を行い、 File systems  --->
以下を明らかに関係ないもの以外を除いて全てチェックする。で、 bzImage を
/boot に置いて、 grub.conf をちょっといじって、再起動。実は、network device の
指定を間違えて、どうにもならない状態になったので、モニタとキーボードを繋いで
再度 kernel を作成し直したり。しかし、モニタ&キーボード無しのマシンは辛い。

で、結果は

[toyota@kashyyyk]% cat /proc/filesystems
nodev   rootfs
nodev   bdev
nodev   proc
nodev   sockfs
nodev   tmpfs
nodev   shm
nodev   pipefs
nodev   binfmt_misc
        ext3
        ext2
        cramfs
nodev   ramfs
        minix
        umsdos
        msdos
        vfat
        iso9660
        vxfs
nodev   nfs
nodev   smbfs
        ntfs
        ufs
        romfs
nodev   autofs
nodev   devpts
        jfs
        xfs

となったが、 jffs/jffs2 が出てこない。もちろん、マウントもできない。しばし、
調査。どうやら MTD を有効にしないと、選択肢がでないらしい。なので、

Memory Technology Devices (MTD)  --->
[*] Memory Technology Device (MTD) support
[*]   MTD partitioning support (NEW)

と MTD を有効にした。すると、

File systems  --->
[*] Journalling Flash File System (JFFS) support
(0) JFFS debugging verbosity (0 = quiet, 3 = noisy)
[ ] JFFS stats available in /proc filesystem
[*] Journalling Flash File System v2 (JFFS2) support
(0) JFFS2 debugging verbosity (0 = quiet, 2 = noisy)

と、出てきた。チェックをして、 kernel を作り直して、コピーして再起動。

[toyota@kashyyyk]% cat /proc/filesystems
〜snip〜
        ufs
        jffs
        jffs2
        romfs
〜snip〜

うまくいったようなので、イメージファイルをマウントしてみる。

[toyota@kashyyyk]% mount -o loop imagefile /mnt/test -t jffs
mount: 間違ったファイルシステムタイプ、不正なオプション、
       /dev/loop0 のスーパーブロックが不正、或いはファイルシステムのマウント
       が多すぎます
[toyota@kashyyyk]% mount -o loop imagefile /mnt/test -t jffs2
mount: 間違ったファイルシステムタイプ、不正なオプション、
       /dev/loop0 のスーパーブロックが不正、或いはファイルシステムのマウント
       が多すぎます

再度調査。どうやら、 -o loop としてはマウントできないようである(自信なし)。
別の方法を考えることにする。

6/23
Terminator K7-DDR
悔しいので jffs2 の解析。参考になったのは、このページ。
http://sources.redhat.com/jffs2/jffs2-html/node3.html
思ったよりも簡単かも。ついでに http://www.linux-mtd.infradead.org/ のページから
mtd のツールをダウンロードしてきた。そこの mtd/util で make すると jffs2dump
なんてコマンドが出来たので、使ってみた。

[toyota@kashyyyk]% ./jffs2dump imagefile

無反応。はて。-h と、 source を眺めた結果から

[toyota@kashyyyk]% ./jffs2dump -c imagefile

としてみた。結果は(少々編集)

Dirent node at 0x00000000, totlen 0x0000002b, #pino 1, version 0, #ino  2, nsize 3, name bin
Inode  node at 0x0000002c, totlen 0x00000044, #ino  2, version 1, isize 0, csize 0, dsize    0, offset 0
Dirent node at 0x00000070, totlen 0x0000002b, #pino 1, version 1, #ino  3, nsize 3, name dev
Inode  node at 0x0000009c, totlen 0x00000044, #ino  3, version 1, isize 0, csize 0, dsize    0, offset 0
〜snip〜

とダダダーと結果が出てきた。このコマンドで取り出すことは出来ないみたい。改造
しようと思ったけど、 cygwin でコンパイルできないので、仕事中できないし…。
続きは今度、時間があるときにしよう。

6/24
Terminator K7-DDR
昨日の続き。ボーっと jffs2dump の source を眺めていて、いじろうかどうか悩んで
いたのだけど、ふと見ると、 jffs2reader.c なんてファイルを発見。ファイル自体は
jffs2dump.c と同じ場所にあるのだが、 Makefile にはコメントされてコンパイル
されないようになっている。で、早速コンパイルしてみた。

[toyota@kashyyyk]% gcc -o jffs2reader -lz jffs2reader.c

あっさりと、バイナリができてしまった。で、実行してみる。

[toyota@kashyyyk]% ./jffs2reader imagefile
drwxrwxr-x 1    0        0                0 Apr  7 12:55 /dev/
drwxrwxr-x 1    0        0                0 Apr  7 12:55 /dev/pts/
crw-r--r-- 1    0        0         202,   1 Mar 14 2003 /dev/vodspa1
crw-r--r-- 1    0        0         201,   7 Mar 14 2003 /dev/kudp7
〜snip〜

ls の動作。なんだ、作る必要なかった。で、ファイルを見ることもできるみたい。

[toyota@kashyyyk]% ./jffs2reader -f /etc/inittab imagefile
#
::sysinit:/etc/init.d/rcS
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init

::once:/etc/init.d/rc.startup
::askfirst:/bin/sh

リダイレクトを使えば、バイナリの中身も取り出せるようである( EOF がおかしい
みたいな感じもするけど)。ということで、明日はとあるルータの解析ができそう。
あ、でも、飲み会だったな。そんなに酔ってなかったら、だな。

6/25
Network
NTTE/NTTW Web Caster V100 のファームウェアの解析をした。未だ、
Yokohama X-VACCINE だった。直すの忘れてた…。それにしても、今日は眠い。
眠いので、誤字が多そうだな。

6/26
Other
ガソリンタンクの錆び落とし その2。だいぶ良くなってきた。あと一息と
いうところ。今回は「花咲かG」を投入した。明日には、結果が得られると思う。

ここのところ、機会があるとダイソーに寄っている。USB の延長ケーブルを買うため
なのだが、いつも売り切れ状態。前は結構あったのに(それも3種類ぐらい)、無いと
いうことは、人気があるからなのか、製造中止だからなのか…。

ということで、昨日書いた文は、案の定かなり誤記があったので、いくつか修正。

6/27
Other
昨日の続き。黒い錆はほとんど取れなかった。ほとんど、限界なのでしょう。と、
いうわけで、ガソリンを入れてエンジンをかけたが、エンジンはかからず。色々
やると、キャブレタからガソリンが吹き出す。フロートが問題みたい。やっぱり、
キャブレタも分解しないといけないのね…。

6/28
Network Other
ファイルの途中で gzip ファイルが混じっている場合、先頭は 6月7日 やった
ように見つければ良いとして、終わりを見つけるのが難しい。最後の4バイトは
解凍された状態のファイルのサイズであるので、かなりやっかい。さらにその前の
4バイトは CRC32 が入っている。なので、ファイルの整合性を決める重要な
部分なのである。
ファイルサイズ、解凍した状態が 16M 以下であれば、最後の1バイトは 00 に
なる。私が扱うファイルは、ほとんどサイズが小さいので、かなり重要な事項
である。しかし、これだけで、判断するのは無理。ということで、 gzip ファイル
の最後を、 CRC32 の結果も使って探すプログラムを作ろうかと考えた。
で、 RFC1952 を読むと

CRC32 (CRC-32)
   This contains a Cyclic Redundancy Check value of the
   uncompressed data computed according to CRC-32 algorithm
   used in the ISO 3309 standard and in section 8.1.1.6.2 of
   ITU-T recommendation V.42.  (See http://www.iso.ch for
   ordering ISO documents. See gopher://info.itu.ch for an
   online version of ITU-T V.42.)

と書いてある。つまり、解凍したあと、 CRC32 の計算をしなければならない。
ファイルの終わりを見つけるだけのために、そんなことできないよなぁ。
簡単なテストをしてみた。

[toyota@kashyyyk]% echo test > a

中身は、以下の感じ。

00000000  74 65 73 74 0a

これの、 CRC32 を計算してみた。

[toyota@kashyyyk]29% cksum a
935282863 5 a

16進数に直すと、 37 BF 48 AF である。 gzip をしてみて、中身を見てみた。

[toyota@kashyyyk]% gzip a

このときの中身は、

00000000  1f 8b 08 08 62 4f e0 40 00 03 61 00 2b 49 2d 2e
00000010  e1 02 00 c6 35 b9 3b 05 00 00 00

後ろ、8バイトから5バイト目を取り出すと、 36 EE F6 3B なので、
3B EE F6 36 。さっきの cksum の結果と違う。何故だろう。ちょっと、調べて
みた。
どうやら cksum は CRC32 の結果ではないようである。しょうがないので、
プログラムを組んでみた。ファイルの I/O は面倒なので、省略して、 zlib を
使って(これを使ったら、意味が無いような気もするけど)作ってみた。

[toyota@kashyyyk]% cat crc32.c
#include <zlib.h>
main(){
char buffer[6]={0x74,0x65,0x73,0x74,0x0a,0};
unsigned long crc=crc32(0L,Z_NULL,0);
crc=crc32(crc,buffer,5);
printf("%ld¥n",crc);
}

結果は。

[toyota@kashyyyk]% gcc crc32.c -o crc32 -lz
[toyota@kashyyyk]% ./crc32
1001993670

なので、16進数で 3B B9 35 C6 となる。 gzip のファイルの中身と一致した。

gzip のファイルの終わりを見つけるプログラムは実用的なスピードになるのか、
時間があったら作ってみようと思う。

6/30
Network Other
CRC32 の動作について。文字が1文字ずつ増えていくとどのような結果になるのか。

[toyota@kashyyyk]% cat crc32.c
#include <zlib.h>
main(){
char buffer[5]={0x74,0x65,0x73,0x74,0};
unsigned long crc=crc32(0L,Z_NULL,0);
crc=crc32(crc,buffer,2);
printf("%lu %lx¥n",crc,crc);
crc=crc32(0L,Z_NULL,0);
crc=crc32(crc,buffer,3);
printf("%lu %lx¥n",crc,crc);
crc=crc32(0L,Z_NULL,0);
crc=crc32(crc,buffer,4);
printf("%lu %lx¥n",crc,crc);
}

結果は…。

[toyota@kashyyyk]% gcc crc32.c -o crc32 -lz
[toyota@kashyyyk]% ./crc32
928136154 37523bda
2101323514 7d3fa6fa
3632233996 d87f7e0c

規則性はなさそうだ。同じ文字でもやってみたし、同じ文字数でもじを1つずらして
やってみたけど、やはり規則性はない。つまり、 gzip の終わりをみつけるプログラムを
1文字ずつチェックしていく作りにすると、毎回解凍して、CRC32 の結果を出さなければ
ならない。かなり時間がかかりそう。解凍ファイルサイズが、 16M 以下、の限定で
作ってみようかな…。

久しぶりに、昨日は休んでしまった…。いかんいかん。それに、もう明日から7月
なんだなぁ。


21st projects Tatsuyoshi Networks Prompt Works
by Tatsuyoshi
since 2003