6/1
昨日の続きで、 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 i に telnet で login できるようになったは良いが、１ユーザしか
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
これで、４本 login できるようになった。
6/3
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 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
いろいろなところから 3fd5f493.1080802@tatsuyoshi.net 宛にメールが来ているようである。
もちろん、そんなユーザはいないので、弾き返すのだが、どんな内容のメールが来ているのか
気になったので、適当なユーザの alias にしてみて、中身を見てみた。見てがっくり。
〜 メーリングリストメンバではありません 〜
あなたは、このメーリングリストのメンバではありません。
このメーリングリストへの質問等は、下記のアドレスまでお願いします。
****@***.biglobe.ne.jp
以上
他のも、 virus の自動返信か何かでしょう。
6/6
バイナリエディタ hi の更新。もう１本、プログラムを作成したのだが、現在 Linux で
テスト中。
6/7
gzip って RFC1952 で定義されているのね…。知らなかった。昨日作ったもう１つの
プログラムはファイルから gzip のヘッダーをみつけるもの。しかし、 RFC を読み
直して、作り直しになった。gzip は
0バイト目 0x1f
1バイト目 0x8b
2バイト目 0x08
で始まる。3 バイト目の bit 3 が 1 だったら、つまり 0x08 との & が 1 だったら
ファイル名が格納されているので、10 バイト目から NULL で終わるファイル名を
抽出することができる。で、良いのかな。あ、違うな、その前に 0x04 との & が 1
だったら、FEXTRA が入っているので、そのあとになるのか。 とりあえず、の
プログラムなので 0x04 は考えないことにしよう…。
6/8
昨日の RFC を読んで、 1f8b.c の修正と公開。久しぶりに C で書き直してみた。
…、なんか、こういきなり C の source ファイルを置くだけ、ということをするから
敷居が高いページって人に言われてしまうのかな…。 dd コマンドだけでも、かなり
敷居が高いらしい。時間があったら、それらの解説ページで作ってみようかな…。
6/9
デジカメ、リコー Caplio G4 レビュー。いつものように写真があるので、別ページです。
1cm マクロって、すごい。
で、こいつを軽く解析してみたのだけど、 Nucleus PLUS - Version ARM6/7/9 1.11.17 で
動いているらしい。なんだかね。
6/10
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
メインのマシンで、 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
バイナリエディタ hi の更新。 undo 機能の追加を行おうと思ったけど、思った以上に
面倒なので、あきらめた。
6/13
IO-DATA WN-AG/BBR のファームウェアの解析をした。本当のことを言うと、最初は
マイクロ総研のファームウェアを解析してた気がするけど、挫折した。マイクロ総研の
ファームウェア、難しすぎ。
6/14
unicode を調べてみた。しかし、調べる前で、私が思いつくものは、ucs2, utf7, utf8
だったのだけど、まだまだ種類があるらしい。ucs2, utf8 ぐらいに対応していれば
なんとかなる感じだけど。こいつらを SJIS と EUC に変換するコードを書かなければ
ならない。面倒だ。その前に、世界の文字コードが混沌としていたので、それを
１つにまとめようと、 unicode を作ったはずなのに、 unicode にこんなに種類が
あったら、全然意味ないじゃん…。
6/15
昨日の続き。親切な方が iconv 関数の存在を教えてくれたので、試してみることに
した。早速 cygwin に iconv 周りを入れて、いざ、コーディングになって…。
バイナリエディタ hi(t) に組み込もうと思っていたのだけど、画面やこれまでの
source の関係などから、１文字ずつの変換。効率が非常に悪いことに気が付いた。
はて、 hi(t) の source をごっそり書き直すか、 utf8 -> sjis の関数を作るか、
どうしよう。
6/16
LINKSYS WRV54G-JP のファームウェアの解析をした。最近 Linux が多いなぁ。ちょっと
変わったことをさせるには、 Linux 使った方が楽なのだろうけど…。
6/17
月曜日から web サーバの出力 log 形式を変更し、Referer と User-Agent もとるように
したのだけど、えらい log が見づらくなった。で、いくつかわかったことが。
・思ったよりも google のキャッシュを使っている人が多い
・同じく、色々なブラウザを使っている
・意外な検索語でも、私のページが出てしまう
ページの内容が内容なので、なるほど、と思ってしまうところもあるけど。しかし、だ、
「toyota bB」で私のページが出るのは、どうかと。
6/18
という訳で、 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
４バイト(オクテット)まであるんだ。で、日本語は３バイトみたいなので、２バイトと
４バイトの文字は無視して良いのかな。 UTF-8 → SJIS の変換表はないみたいなので
(探せばあるかもしれないけど)、 UTF-8 → UCS2 → (JIS →) SJIS とすれば良いのかな。
UTF-8 → UCS2 は
if(３バイト UTF-8 だったら){
ucs2[0] = ((utf8[0] & 0xF) << 4) + ((utf8[1] & 0x3C) >> 2);
ucs2[1] = ((utf8[1] & 0x3) << 2) + utf8[2] & 0xF;
}
こんな感じか。動かしてないから、自身ないけど。
6/19
Persol BSR14 のファームウェアの解析をした。そう言えば、 Yokohama X-VACCINE
って既に活動してないんだよなぁ。これから書くものは Tatsuyoshi Networks に
しようかな。
6/20
ガソリンタンクの錆び落とし with Verity Super TC。ガソリンタンクって、すぐに
錆びるものなので、プラスチック製にして欲しいよなぁ。せめて、もう少し錆びない
素材にして欲しい。というわけで、今回も写真があるので、別ページに。
6/21
バイナリエディタ 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
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
悔しいので 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
昨日の続き。ボーっと 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
NTTE/NTTW Web Caster V100 のファームウェアの解析をした。未だ、
Yokohama X-VACCINE だった。直すの忘れてた…。それにしても、今日は眠い。
眠いので、誤字が多そうだな。
6/26
ガソリンタンクの錆び落とし その２。だいぶ良くなってきた。あと一息と
いうところ。今回は「花咲かＧ」を投入した。明日には、結果が得られると思う。
ここのところ、機会があるとダイソーに寄っている。USB の延長ケーブルを買うため
なのだが、いつも売り切れ状態。前は結構あったのに（それも３種類ぐらい）、無いと
いうことは、人気があるからなのか、製造中止だからなのか…。
ということで、昨日書いた文は、案の定かなり誤記があったので、いくつか修正。
6/27
昨日の続き。黒い錆はほとんど取れなかった。ほとんど、限界なのでしょう。と、
いうわけで、ガソリンを入れてエンジンをかけたが、エンジンはかからず。色々
やると、キャブレタからガソリンが吹き出す。フロートが問題みたい。やっぱり、
キャブレタも分解しないといけないのね…。
6/28
ファイルの途中で gzip ファイルが混じっている場合、先頭は 6月7日 やった
ように見つければ良いとして、終わりを見つけるのが難しい。最後の４バイトは
解凍された状態のファイルのサイズであるので、かなりやっかい。さらにその前の
４バイトは CRC32 が入っている。なので、ファイルの整合性を決める重要な
部分なのである。
ファイルサイズ、解凍した状態が 16M 以下であれば、最後の１バイトは 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
１６進数に直すと、 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
後ろ、８バイトから５バイト目を取り出すと、 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
なので、１６進数で 3B B9 35 C6 となる。 gzip のファイルの中身と一致した。
gzip のファイルの終わりを見つけるプログラムは実用的なスピードになるのか、
時間があったら作ってみようと思う。
6/30
CRC32 の動作について。文字が１文字ずつ増えていくとどのような結果になるのか。
[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
規則性はなさそうだ。同じ文字でもやってみたし、同じ文字数でもじを１つずらして
やってみたけど、やはり規則性はない。つまり、 gzip の終わりをみつけるプログラムを
１文字ずつチェックしていく作りにすると、毎回解凍して、CRC32 の結果を出さなければ
ならない。かなり時間がかかりそう。解凍ファイルサイズが、 16M 以下、の限定で
作ってみようかな…。
久しぶりに、昨日は休んでしまった…。いかんいかん。それに、もう明日から７月
なんだなぁ。
|
