encryption disk (2)
Table of Contents
User-Agent
以前にちょっと目を付けていたのを忘れていたので、プチ調べてみた。 Web Browser Fingerprint解説ページ
広義の指紋のうちの、すぐに出来そうなのを試す。だって、底が深そうだからね。 【User-Agent】2024年3月29日時点のユーザーエージェント
下記スクリプトを起動しといて http://localhost:8080
from http.server import BaseHTTPRequestHandler, HTTPServer class RequestHandler(BaseHTTPRequestHandler): def do_GET(self): # ヘッダーから User-Agent を取得 user_agent = self.headers.get('User-Agent') # レスポンスを作成 self.send_response(200) self.send_header('Content-type', 'text/plain') self.end_headers() # クライアントに User-Agent を返す response_message = f"Your User-Agent is:\n{user_agent}\n" self.wfile.write(response_message.encode('utf-8')) # サーバー側で User-Agent を出力 print(f"User-Agent: {user_agent}") def run(server_class=HTTPServer, handler_class=RequestHandler, port=8080): server_address = ('', port) httpd = server_class(server_address, handler_class) print(f"Starting server on port {port}...") httpd.serve_forever() if __name__ == '__main__': run()
世界共通語のpythonならChatGPTでも一発変換。オイラーはpythonをこんな風に使うのさ。 自分から積極的に使おうとは思わないぞ。
Webサーバの仕組みについて入門してみた(Python実装)
思わず、応援したくなるぞ。
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0 Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0 w3m/0.5.3+git20230718 URL/Emacs Emacs/29.4 (TTY; x86_64-unknown-openbsd) curl/8.10.1
上から順番にWindows 10のEdg、Chrome、Firefox 次からはOpenBSD 7.6のFirefox、w3m、eww なブラウザーになっている。お菓子は、カール、って、そんな歌が有ったような。。。 昔haskellの読書会でご一緒した時に、カールおじさん とエイリアスされてる人がおられた。 ご本人が公認されてた。今どうされてるかな? 風の噂では、キャピキャキなおねーちゃん達の 先生をやっておられるって聞いたんだけどな。
近頃の仮想マシン
i386用の仮想マシンが下記のようなdisk使用状況になっている。
i3$ df -h Filesystem Size Used Avail Capacity Mounted on /dev/sd0a 2.8G 1.1G 1.5G 44% / /dev/sd1a 6.8G 2.5G 3.9G 40% /mnt
qemu,Rとかが大物。特にRは、gcc-8.4.0p25、g95-8.4.0p25、clisp-2.49p6やらを 引き連れてやってくるからね。gccはg95と言うFortranの為かな? gccを単独で使いた かったら、
i3$ egcc -v Using built-in specs. COLLECT_GCC=egcc COLLECT_LTO_WRAPPER=/mnt/local/bin/../libexec/gcc/i386-unknown-openbsd7.6/8.4.0/lto-wrapper Target: i386-unknown-openbsd7.6 Configured with: --with-as=/usr/local/bin/gas : --disable-gtk-doc Thread model: posix gcc version 8.4.0 (GCC)
そのくせ、man gccが通用するんだよな。古いとは言えccのマニュアルより重宝しそう だな。覚えておこう。
言語系では、go、rust を入れた。上のpython例なら、容易にgoに変換できるだろうけど rustはどうなんだろう? 面白さで天秤にかけると、オイラーの場合rustに傾くんだ けど、どうよ? rustは標準ライブラリィー少な目がポリシーだからなあ。
The Rust community’s crate registry
make encryption disk
FAQにある奴をやってみる。
ob# dd if=/dev/urandom of=/dev/rsd1c bs=1m dd: /dev/rsd1c: end of device 1915+0 records in 1914+0 records out 2006974464 bytes transferred in 335.618 secs (5979936 bytes/sec) ob# fdisk -iy sd1 Writing MBR at offset 0. ob# disklabel -E sd1 Label editor (enter '?' for help at any prompt) sd1*> a a offset: [64] size: [3919808] FS type: [4.2BSD] RAID sd1*> w sd1> q No label changes. ob# bioctl -c C -l sd1a softraid0 New passphrase: Re-type passphrase: softraid0: CRYPTO volume attached as sd2
ob# dd if=/dev/sd2c of=output bs=1 count=84640 84640+0 records in 84640+0 records out 84640 bytes transferred in 0.443 secs (190891 bytes/sec)
使い終ったらデタッチしてるけど、再利用する時は、どうするの?
break password
OpenBSD フルディスク暗号化 (on VirtualBox)
に習って、amd64版をインストールしてみた。その目的は、OpenBSD破れたりの確認。 そう、世界で一番使われているパスワードなら、OpenBSDと言えども簡単に パスワード・クラッキングできるかの確認ってか追試です。
eq$ dd if=/mnt/my/mydisk of=out bs=1 count=84640 eq$ openbsd_softraid2john.py out >seed eq$ cat seed out:$openbsd-softraid$144$9dbf50a0cc137dfd78f72978767218b9def86511a6d248 : 8891805b389ba43c117e51b$becf00ef7bf5ee860806c52048a367f5ae0ed5d3$3
前回python2用の openbsd_softraid2john.py
をpython3用にコンバートしたんで、
それを利用して、パスワード情報をseedに抽出した。そして、それをjohnに喰わ
せてみる。
eq$ ./john ~/seed Using default input encoding: UTF-8 Loaded 1 password hash (OpenBSD-SoftRAID [PBKDF2-SHA1 128/128 SSE2 4x2]) Cost 1 (kdf) is 3 for all loaded hashes Cost 2 (iteration count) is 144 for all loaded hashes Proceeding with single, rules:Single Press 'q' or Ctrl-C to abort, almost any other key for status Warning: Only 2 candidates buffered for the current salt, minimum 8 needed for performance. : Warning: Only 5 candidates buffered for the current salt, minimum 8 needed for performance. Almost done: Processing the remaining buffered candidate passwords, if any. Proceeding with wordlist:./password.lst, rules:Wordlist 123456 (out) 1g 0:00:15:35 DONE 2/3 (2024-12-11 07:13) 0.001069g/s 0.8853p/s 0.8853c/s 0.8853C/s 2828..1234567890
15分かかって、パスワードを推測してくれた。辞書に登録されてるのを順番に試行 してくんだけど、多少は抵抗しているなあ。気になるのは、SHA1って弱い暗号が 利用されてるっぽい事。親分、これで良いのでしょうか?
virtual disk
暗号化diskの前に、大きな疑問が湧いてきたんで、ChatGPTに聞いてみる。
Q: VirtualBox等での仮想化Diskについて質問します。仮想diskの元は、dd if=/dev/zero of=mydisk bs=1m count=2000 の様にして作成したプレーン・ファイルです。それが 仮想環境の中では、/dev/sd0 の様にデバイスとして扱われます。mknodとかのシステム コールとかで、ファイルをデバイスの様に見せかけているのでしょうか?
A: はい、その理解は概ね正しいです。VirtualBoxや他の仮想化環境では、ホストOS上の 通常のファイル(たとえば`mydisk`のようなファイル)を仮想マシン内でディスク デバイス(例: `/dev/sd0`)として扱えるようにする仕組みがあります。 この背後には以下のような動作が関与しています。
—
### 1. 仮想ディスクファイルの役割 仮想ディスクファイル(例: `mydisk`)は、実際には通常のファイルですが、仮想化ソフト ウェアにとっては「仮想ディスクイメージ」として解釈されます。仮想化ソフトウェアは このファイルを直接読み書きすることで、仮想マシン内でディスク操作をシミュレートします。
—
### 2. 仮想デバイスのエミュレーション 仮想化ソフトウェアは、仮想マシン内でのデバイス(例: `/dev/sd0`)をエミュレートします。 これには以下のようなプロセスが含まれます:
- ホストOS上でのファイル操作 仮想化ソフトウェアは、ホストOS上のファイル操作(例: `read()`や`write()`)を 通じて、仮想ディスクファイル(例: `mydisk`)を直接操作します。
- 仮想マシン内でのデバイスとしての提供 仮想化ソフトウェアが、仮想マシン内の仮想ハードウェア(例: SATA、IDE、SCSI コントローラー)をエミュレートします。仮想マシンのカーネルは、これを物理デバイス として認識します(例: `/dev/sd0`)。
—
### 3. `mknod`の役割 `mknod`自体は、ホストOS上でデバイスファイルを作成するコマンドですが、仮想マシン内の 仮想デバイスがどのように実現されているかとは直接関係しません。
仮想化ソフトウェアは、仮想マシンの起動時に仮想デバイスをエミュレートします。 このため、仮想マシン内でデバイスファイル(例: `/dev/sd0`)が見えるのは、 エミュレーションによって仮想カーネルが自動的にデバイスを認識している結果です。
—
### 4. ホストOSと仮想環境の間の橋渡し 仮想化ソフトウェアがホストOS上のファイルを仮想デバイスに見せるプロセスには、特定の カーネルモジュールや仮想化API(例: QEMUでは`/dev/kvm`)が使われます。 これにより、ホストファイルシステムと仮想マシンの間のデータのやり取りが実現されています。
—
### 簡潔に言えば: ホスト上のファイルをデバイスとして扱うために、仮想化ソフトウェアが間に入って仮想的な ハードウェアをエミュレートしています。このエミュレーションが、仮想マシン内で`/dev/sd0` のようなデバイスを認識させる鍵となっています。仮想化ソフトウェアがその役割を担うため、 ホスト側で`mknod`を使う必要はありません。
Q: 上記の 2.2 について、詳しく説明してください。可能なら、コードで概要を示して ください。
A: 仮想化ソフトウェアが仮想マシン内で仮想デバイスを提供する仕組みについて、さらに詳しく説明し、コード例で概要を示します。
—
### 仮想デバイス提供のプロセス 仮想マシン内での仮想デバイス(例: `/dev/sd0`)の提供は、以下のようなプロセスを通じて行われます。
- ホストOSでの準備 仮想化ソフトウェアは、ホスト上の仮想ディスクイメージ(通常のファイル)を操作対象として準備します。これを後で仮想マシンの仮想ディスクとしてマッピングします。
- 仮想ハードウェアのエミュレーション 仮想化ソフトウェアは、仮想マシンのカーネルが認識できるよう、SATA、IDE、またはSCSIコントローラーのエミュレーションを行います。このコントローラーが、仮想ディスクイメージへのアクセスを実現します。
- 仮想マシンのカーネルとの連携 仮想化ソフトウェアは、仮想マシンのカーネルに対して、エミュレートされたデバイスを提示します。仮想マシン内のOSカーネルは通常のデバイスとしてそれを認識します。
—
### コードでの概要
以下に、仮想化ソフトウェアの仮想ディスクエミュレーションの一部をシンプルなコードで示します。以下は、概念を説明するための擬似コードです。
#### 仮想化ソフトウェア側
import os # 仮想ディスクイメージファイルをオープン disk_image_path = "mydisk" disk_fd = os.open(disk_image_path, os.O_RDWR) # 仮想ディスクコントローラーをエミュレーション class VirtualDiskController: def __init__(self, disk_fd): self.disk_fd = disk_fd def read_sector(self, sector_num, sector_size=512): """仮想マシンからの読み込み要求を処理""" os.lseek(self.disk_fd, sector_num * sector_size, os.SEEK_SET) return os.read(self.disk_fd, sector_size) def write_sector(self, sector_num, data, sector_size=512): """仮想マシンからの書き込み要求を処理""" os.lseek(self.disk_fd, sector_num * sector_size, os.SEEK_SET) os.write(self.disk_fd, data) # 仮想マシンのI/Oリクエストを処理 controller = VirtualDiskController(disk_fd) # 仮想マシンからのリクエスト例 sector_num = 10 # 読み込みたいセクター番号 data = controller.read_sector(sector_num) print(f"Sector {sector_num}: {data}")
—
#### 仮想マシン側(カーネル視点) 仮想化ソフトウェアが提供する仮想デバイスは、仮想マシンのカーネルから見ると通常のデバイスとして認識されます。以下は、Linuxカーネルでのデバイス認識の例です。
カーネル内でSATAやSCSIコントローラーのデバイスドライバが以下のように動作します。
// 仮想SATAデバイスを検出し、初期化するカーネルモジュールの一部 int virtual_sata_probe(struct pci_dev *pdev, const struct pci_device_id *id) { // PCIデバイスを初期化 struct device *dev = &pdev->dev; // 仮想化ソフトウェアが提供するメモリマッピングを取得 void __iomem *mmio_base = pci_iomap(pdev, 0, pci_resource_len(pdev, 0)); // 仮想SATAコントローラーを登録 register_sata_controller(mmio_base); printk(KERN_INFO "Virtual SATA controller initialized\n"); return 0; }
このようにして、仮想化ソフトウェアが提供するエミュレートされたデバイスが、仮想マシン内で通常のデバイスとして認識されます。
—
### ポイント
- **仮想化ソフトウェアはホストOS上でファイル操作を行い、仮想マシンへのI/Oを処理します**。
- **仮想マシンのカーネルは、それを通常のハードウェアデバイスとして扱います**。
この仕組みにより、ホスト上の通常ファイルが仮想マシン内でディスクデバイスとして機能します。
real vs. virtual disk
現実と仮想でdiskが、どう扱われるか確認。まずは現実から。
ThinkPad SL510 (OpenBSD 7.6)
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2 ahci0: port 0: 3.0Gb/s ahci0: port 1: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: <ATA, HITACHI HTS54502, PB2Z> naa.5000cca5e7cd4ce8 sd0: 238475MB, 512 bytes/sector, 488397168 sectors : vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (4a2f0a6c27eb2522.a) swap on sd0b dump on sd0b
次からは仮想の代表として、qemuとvmdで確認。
QEMU (FreeBSD 14.1) on OpenBSD 7.6
atapci0: <Intel PIIX3 WDMA2 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 ,0xc040-0xc04f at device 1.1 on pci0 ata0: <ATA channel> at channel 0 on atapci0 ata1: <ATA channel> at channel 1 on atapci0 : da0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: <QEMU HARDDISK 2.5+> ATA-7 device ada0: Serial Number QM00001 ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 40960MB (83886080 512 byte sectors)
vmd (OpenBSD 7.6) crypt mode
virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio1 scsibus1 at vioblk0: 1 targets sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, > sd0: 1024MB, 512 bytes/sector, 2097152 sectors : vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets sd1 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006> sd1: 1023MB, 512 bytes/sector, 2096560 sectors root on sd1a (5576836c7209b6a6.a) swap on sd1b dump on sd1b
この時のvmdの様子。
eq$ ps awx | grep vmd 77152 ?? Ip 0:00.01 /usr/sbin/vmd 1291 ?? Ic 0:00.00 vmd: priv (vmd) 38335 ?? Ipc 0:00.00 vmd: control (vmd) 87582 ?? IpUc 0:00.01 vmd: vmm (vmd) 43535 ?? Ipc 0:00.00 vmd: agentx (vmd) 45980 ?? Ipc 0:55.61 vmd: amd64 (vmd) 96606 ?? Ipc 0:03.32 vmd: amd64/vioblk0 (vmd)
README
5年ぶりぐらいに、都会へ出かけた。記念にRustの本を購入した(go本は既に所有 してるから)。Python本は山の様に あるのに、golangやRustの本は、極めて僅か。おかげで選択が楽だった。でも一応 コンペしたよ。最終選考に残ったのは、Rustで作るプログラミング言語だった。けど、 こちらはオイラーに取って、内容がトンガリすぎていると思ったので、下記にした。
お茶屋さんで、少々眺めてみた。最終章が盲腸のごとく、バックエンドエンジニアに なるための採用面接対策に当てられていた。思わず笑ってしまったぞ。いや笑うなよ。 実技試験で簡単なコード作成問題が出題された時、計算量まで考えておきましょうって、 激同意します。帰りの汽車の中で、最初から読み初めた(ああ、汽車なんて昭和の 香りがプンプンするな)。
上の案内では、第1章が丸ごと掲載されてた。オイラーはGC無しってのがgolangに 比べて非常に優位なポイントだと思う。それを実現する為の仕掛けも斬新だと思うぞ。 それから、これはオイラーの感触なんだけど、rustは何となくhaskellに似ていて、 かっこいいと思う。
2章は、ご多分に漏れず環境構築の説明になってる。そして、editorは当り前の様に、 VS Codeを選択している。喰わず嫌いは頭の硬い証拠と見做されるので、Windows10に、 Rustの環境を作ってみるかな。もうオイラーの心の中では、Windowsなんてどうなっても いいと思っているんで、おっかなびっくりは無しで、やりたい放題できるぞ。
そんな心を見透したように、こんなのが出てきた。 デスクトップアプリを開発しよう! 「Rust」と「Tauri 2.0」の基本情報と環境整備の仕方を解説
Windowsにベッタリみたいなので、好都合だぞ。 やり始めたのはいいけど、Windows用のコンパイラーを入れておけって所で、放棄した。 インストールに無茶苦茶時間がかかるから。苦労して入れてもwindowsのしきたりに 馴染むのは無駄、とも思った。将来を見据えると、Windowsはフェードアウトさせる 予定。ならば、みんなのUbuntu/WSLがいいだろう。Rustの人達も推しているみたいだし。