カスペルスキーのハッシュの元の名前を教えてくれ的なやつ [プログラミング]
コードを書こうかと思ったが、よく読んだら書くまでもなかった
https://www.securelist.com/en/blog?weblogid=208193781
アメリカとイスラエルが開発したとされるスパイウェア「Gauss」のハッシュがわからんので教えてくれというのが発端
Validation
・%PROGRAMFILES%にあるフォルダを列挙する
大抵は「c:\Program Files」 のUnicode
・1文字目が0x007A以下は除外
Unicodeで'z'を表す。つまりASCII以外の文字を含むフォルダだけをターゲットとする
AMDとかWindows~というのは除外される
・パス+フォルダ+Salt を作る
Saltは16バイトでハードコードされている?
Unicodeだけだと半分は0になっているので解読されやすいかもしれないのでそれを考慮してSaltを追加?
・md5を1万回計算する
hash = md5(hash)
1回だけだとすぐバレるので追加。
MD5を使っているのは実装が簡単、軽量だから?
・ハードコードされた値と一致したらOK
復号のほうもにたようなもん。なぜかWindowsのAPIを使ってるが、理由は不明。
で、パスとフォルダで何百万という組み合わせをためしたがダメだった。のでわかったら教えてくれというのが課題。
まあ、普通の人なら自作コードでサンプルが一致するのを確認するのがせいぜいだろう。
サンプルが確認できるコードを書いて、元ネタのパスを探すのがいかに難しいかをまとめると夏休みの自由研究にはいいかもしれない。
https://www.securelist.com/en/blog?weblogid=208193781
アメリカとイスラエルが開発したとされるスパイウェア「Gauss」のハッシュがわからんので教えてくれというのが発端
Validation
・%PROGRAMFILES%にあるフォルダを列挙する
大抵は「c:\Program Files」 のUnicode
・1文字目が0x007A以下は除外
Unicodeで'z'を表す。つまりASCII以外の文字を含むフォルダだけをターゲットとする
AMDとかWindows~というのは除外される
・パス+フォルダ+Salt を作る
Saltは16バイトでハードコードされている?
Unicodeだけだと半分は0になっているので解読されやすいかもしれないのでそれを考慮してSaltを追加?
・md5を1万回計算する
hash = md5(hash)
1回だけだとすぐバレるので追加。
MD5を使っているのは実装が簡単、軽量だから?
・ハードコードされた値と一致したらOK
復号のほうもにたようなもん。なぜかWindowsのAPIを使ってるが、理由は不明。
で、パスとフォルダで何百万という組み合わせをためしたがダメだった。のでわかったら教えてくれというのが課題。
まあ、普通の人なら自作コードでサンプルが一致するのを確認するのがせいぜいだろう。
サンプルが確認できるコードを書いて、元ネタのパスを探すのがいかに難しいかをまとめると夏休みの自由研究にはいいかもしれない。
使わなかった技術シリーズ2 ラムダ式 [プログラミング]
前回のFibreが1で、今回が2と勝手にやってみる。
匿名関数がやっぱり話題になった時期があった
何が嬉しいかというと、わざわざ関数宣言を書くまでもない場合に関数のように振る舞えるオブジェクトをさくっと書けることなんだと思う。
テスト用のプログラムなんかでちょっと試しに追加や削除したい場合なんかはありかもしれない。
C#3.0に追加されてそれまでdelegateとして書く必要があったところが必要なくなり、表現が簡潔になったことから話題になった。
が、ほとんど
・場当たり的なコードしか書かない
・理論的に完結になる要素がない
・C#を使わない
・0からやる仕事が無い
という理由からまったく使わなかった。
実際Fibreとかラムダ式はスクリプト系言語なら導入されてたりするんだが、未だにC言語ぐらいしかやらないような職業なのでどうしてもこういう新しい要素とは疎遠になってしまう。
1年で1言語どころかいつまでもC言語という危機感を感じずにはいられない今日この頃である。
匿名関数がやっぱり話題になった時期があった
何が嬉しいかというと、わざわざ関数宣言を書くまでもない場合に関数のように振る舞えるオブジェクトをさくっと書けることなんだと思う。
テスト用のプログラムなんかでちょっと試しに追加や削除したい場合なんかはありかもしれない。
C#3.0に追加されてそれまでdelegateとして書く必要があったところが必要なくなり、表現が簡潔になったことから話題になった。
が、ほとんど
・場当たり的なコードしか書かない
・理論的に完結になる要素がない
・C#を使わない
・0からやる仕事が無い
という理由からまったく使わなかった。
実際Fibreとかラムダ式はスクリプト系言語なら導入されてたりするんだが、未だにC言語ぐらいしかやらないような職業なのでどうしてもこういう新しい要素とは疎遠になってしまう。
1年で1言語どころかいつまでもC言語という危機感を感じずにはいられない今日この頃である。
スレッドとファイバ [プログラミング]
並列処理を実現するのにはWindowsではスレッドを作るのが一般的・・・というわけでもないので少し戦略的に考えてみる。
・ユーザがボタンを押して処理を実行し、その処理がすぐ終わる類のものはベタっとイベントハンドラを書けば良い
・処理がすぐ終わらないものについてはスレッド化しないといけない
ところが、スレッドを作成するといくつか問題がある
・同期の問題
非同期処理にしないとスレッドを作る意味が無いが、データを共有するのにMutexなどで適切に動機を行う必要がある。
・効率の問題
CPUの個数に依存する。まあそもそも大抵はスレッドは1つあれば足りるのであまりこれが問題になることはないと思うが。ゲームではかなり重要かも。
・効率の問題2
タスクスケジューラがスレッドを切り替える事自体がかなりオーバーヘッドが高いので、並列処理させたいスレッド同士が独立性が高くない場合に切り替えコストが高くなる場合がある。
・効率の問題3
スレッドとCPUの個数には密接な関係があり、特にCPUのキャッシュラインサイズを意識する必要がある
とスレッドを導入して効果を出そうとすると考えることは多い。
特に意識しないといけないのはメインスレッドとサブスレッドの関連性。特にゲームではメイン処理部分とサウンド処理であればかなり独立性は高いと思うが、メイン処理の一部にCPUのアルゴリズムだったりキー入力だったりがあったりした場合はかなり密結合になると思う。
でタスク切り替えのオーバーヘッドが少なくスレッドのように扱えるものとしてFibre、マイクロスレッドやコルーチンと呼ばれるものが数年前の流行り。
キーワードはyield。スレッドでは意図的に別のスレッドに所有権を渡したい場合はsleep(0)だが、Fibreの場合、実質的なスレッドは1つしかないので、自分の中でスレッド切り替えを明示的に行う必要がある。それがyield。yieldで別処理を行い、処理が終わるか途中の段階でまた所有権を戻してもらう。こうすることで、マルチスレッドのように見えていて実際はマルチスレッドではないFibreを実現する。
MSはちゃんとAPIでFibreを導入している。というか、大抵IT関係で話題があると、新しいWindowsにはこっそり導入されてたりする。
http://msdn.microsoft.com/en-us/library/ms682661%28VS.85%29.aspx
で、自分の場合は最初に書いたようにスレッド一個作れば足りるような仕事しかしていないので、これの使い道が無くちゃんと調べないでそのままだった。
また、Linuxの場合だとそもそもスレッドを作ること自体が皆無でforcになってしまうのか。Linuxのユーザランドでマルチスレッドの必要性があるものを作ったことがない。カーネルだと勝手にマルチスレッドになってしまっていたり、カーネルスレッド作るのがデフォだったりするので、自分で意識的にどうこうする必要もない。
ゲームだったりパフォーマンスが要求されるような場合で、スレッドを作ってみたけど無駄が多いなと思われるような場合に試してみようと思うがまずそういうことはないだろうw
・ユーザがボタンを押して処理を実行し、その処理がすぐ終わる類のものはベタっとイベントハンドラを書けば良い
・処理がすぐ終わらないものについてはスレッド化しないといけない
ところが、スレッドを作成するといくつか問題がある
・同期の問題
非同期処理にしないとスレッドを作る意味が無いが、データを共有するのにMutexなどで適切に動機を行う必要がある。
・効率の問題
CPUの個数に依存する。まあそもそも大抵はスレッドは1つあれば足りるのであまりこれが問題になることはないと思うが。ゲームではかなり重要かも。
・効率の問題2
タスクスケジューラがスレッドを切り替える事自体がかなりオーバーヘッドが高いので、並列処理させたいスレッド同士が独立性が高くない場合に切り替えコストが高くなる場合がある。
・効率の問題3
スレッドとCPUの個数には密接な関係があり、特にCPUのキャッシュラインサイズを意識する必要がある
とスレッドを導入して効果を出そうとすると考えることは多い。
特に意識しないといけないのはメインスレッドとサブスレッドの関連性。特にゲームではメイン処理部分とサウンド処理であればかなり独立性は高いと思うが、メイン処理の一部にCPUのアルゴリズムだったりキー入力だったりがあったりした場合はかなり密結合になると思う。
でタスク切り替えのオーバーヘッドが少なくスレッドのように扱えるものとしてFibre、マイクロスレッドやコルーチンと呼ばれるものが数年前の流行り。
キーワードはyield。スレッドでは意図的に別のスレッドに所有権を渡したい場合はsleep(0)だが、Fibreの場合、実質的なスレッドは1つしかないので、自分の中でスレッド切り替えを明示的に行う必要がある。それがyield。yieldで別処理を行い、処理が終わるか途中の段階でまた所有権を戻してもらう。こうすることで、マルチスレッドのように見えていて実際はマルチスレッドではないFibreを実現する。
MSはちゃんとAPIでFibreを導入している。というか、大抵IT関係で話題があると、新しいWindowsにはこっそり導入されてたりする。
http://msdn.microsoft.com/en-us/library/ms682661%28VS.85%29.aspx
で、自分の場合は最初に書いたようにスレッド一個作れば足りるような仕事しかしていないので、これの使い道が無くちゃんと調べないでそのままだった。
また、Linuxの場合だとそもそもスレッドを作ること自体が皆無でforcになってしまうのか。Linuxのユーザランドでマルチスレッドの必要性があるものを作ったことがない。カーネルだと勝手にマルチスレッドになってしまっていたり、カーネルスレッド作るのがデフォだったりするので、自分で意識的にどうこうする必要もない。
ゲームだったりパフォーマンスが要求されるような場合で、スレッドを作ってみたけど無駄が多いなと思われるような場合に試してみようと思うがまずそういうことはないだろうw
カレログの現状(「不正指令電磁的記録に関する罪」の問題点) [プログラミング]
夜中に急にRTが連発されていたので、何かと思ったらセキュリティ専門家の高木先生が夜中にRTしまくっていたが、その内容が「他人の行動はトレースできて当然」という人たちだったので、これは証拠集めだなと思っていたが、その後の話の展開からしてその通りだろう。 ちなみにこの事象自体も証拠(後述)
高木先生は証人喚問とかでもしつこくしつこく質問していた。
「不正指令電磁的記録に関する罪」で、「プログラムが意図しない動作を第三者が悪用した場合に作者が罪に問われるのか?」
これに対しての法務省の見解は「作者が悪用されるのがわかってて放置した場合はありうる」。つまり「内心どう思っているか」に依存している。
包丁に例えると、「誰かが殺人をする可能性を考えてましたね?」と言われて「ハイ」と答えたら有罪になる。あと有名な会社だったら訴えられない(by岡山県警)。「常識的にありえないでしょう」とどや顔で言う検事や裁判官の顔が眼に浮かぶようだ。
カレログはストーカー行為を助長する目的で作ってるのは間違いないのだが、トップページに二十未満は使っちゃダメとか、相手の合意がいるとか責任逃れのことをたくさん書いてある。
で、最初の話になる。「カレログが必要だ」という人は「相手のプライバシー侵害のことは毛程も考えていない」人しかいない。自分がみられるのは困るけど人のは見たい。そんな人達のツイートを高木先生はサンプルとして集めていた。つまり高木先生は「こういう人達がいるのをわかってて、まだアプリを公開しているのは「不正指令電磁的記録に関する罪」に相当するのではないんですか?」という意味があってやっている(はず)。
ちなみにプライバシー侵害していることは間違いないのでマカフィーは速攻ウィルス認定したようだ。
http://home.mcafee.com/VirusInfo/VirusProfile.aspx?key=575603
これを証拠として、それでもなお公開していたということは「犯罪を助長する明確な意図があった」と言うことも可能だし、マカフィーほどのでかい所が言うなら、と「裁判所が思ったら」作者は前科者になるだろう。
結局、法律を変えてはみたもののLibrahack事件から何も進展していない。
http://librahack.jp/
以下、その後の展開、ケータイウォッチが先走った。
彼氏追跡アプリ「カレログ」はウイルス? 沈静化目指す提供元 - ケータイ Watch - http://goo.gl/arFsI
開発元が必死に俺は悪くないアピールしてるのにw
実際このケータイウォッチは勇み足だったようだ。
が、あるアングラ雑誌におもいっきりストーカー目的で造りましたと作者が自白しているという。今なお進展中の事案なので要チェックである。
高木先生は証人喚問とかでもしつこくしつこく質問していた。
「不正指令電磁的記録に関する罪」で、「プログラムが意図しない動作を第三者が悪用した場合に作者が罪に問われるのか?」
これに対しての法務省の見解は「作者が悪用されるのがわかってて放置した場合はありうる」。つまり「内心どう思っているか」に依存している。
包丁に例えると、「誰かが殺人をする可能性を考えてましたね?」と言われて「ハイ」と答えたら有罪になる。あと有名な会社だったら訴えられない(by岡山県警)。「常識的にありえないでしょう」とどや顔で言う検事や裁判官の顔が眼に浮かぶようだ。
カレログはストーカー行為を助長する目的で作ってるのは間違いないのだが、トップページに二十未満は使っちゃダメとか、相手の合意がいるとか責任逃れのことをたくさん書いてある。
で、最初の話になる。「カレログが必要だ」という人は「相手のプライバシー侵害のことは毛程も考えていない」人しかいない。自分がみられるのは困るけど人のは見たい。そんな人達のツイートを高木先生はサンプルとして集めていた。つまり高木先生は「こういう人達がいるのをわかってて、まだアプリを公開しているのは「不正指令電磁的記録に関する罪」に相当するのではないんですか?」という意味があってやっている(はず)。
ちなみにプライバシー侵害していることは間違いないのでマカフィーは速攻ウィルス認定したようだ。
http://home.mcafee.com/VirusInfo/VirusProfile.aspx?key=575603
これを証拠として、それでもなお公開していたということは「犯罪を助長する明確な意図があった」と言うことも可能だし、マカフィーほどのでかい所が言うなら、と「裁判所が思ったら」作者は前科者になるだろう。
結局、法律を変えてはみたもののLibrahack事件から何も進展していない。
http://librahack.jp/
以下、その後の展開、ケータイウォッチが先走った。
彼氏追跡アプリ「カレログ」はウイルス? 沈静化目指す提供元 - ケータイ Watch - http://goo.gl/arFsI
本来、彼氏に見つからずに監視するというコンセプトであったため、アプリのアイコンは一見して「カレログ」とわかりにくいものであったが、わかりやすい形に変更された。
開発元が必死に俺は悪くないアピールしてるのにw
実際このケータイウォッチは勇み足だったようだ。
が、あるアングラ雑誌におもいっきりストーカー目的で造りましたと作者が自白しているという。今なお進展中の事案なので要チェックである。
椅子 [プログラミング]
ITドカタにとって椅子は重要なファクターである。一日10時間座っているといっても過言ではないので、椅子が悪いと腰を痛める。で、数年前に7万ぐらいで椅子を買ったのだが、アマゾンみたらまだあった。
1万ぐらい安いんだよぉぉぉ。
そのときになんでこれを選んだか考えてみると
・人体工学に基づいた、という類の椅子は座り難いのが多かった
・これなんかは見た目こそいかにも人間工学ってかんじだったが座ってみたらジャストフィット
他に選択の余地なく、購入した。
これをお勧めするわけではないが、椅子は通販で買わず、必ず座って確認することをお勧めする。
実際家で使ってみるとヘッドレストが若干固い以外は自分の体にジャストフィット。当然のごとくヘッドレストの高さや胴の幅、空圧での高さ調整はできるので悪くない。というかむしろいい。それまでしょぼい椅子を使ってて腰がいてーなーと思っていたが、この椅子にしてからまったく不安が無くなったし、今も使っていて買い換えようという気が起きないし、オーディオシステムでの視聴にも使えるのだから自分にとってはベストバイであったといえる。
この椅子の独特の形が背中をいいかんじに伸ばしてくれるので背筋が伸びて気持ちいい。これが通常の背もたれタイプだと背骨を圧迫されて無理やり伸ばされたりして気持よくない。
この椅子でレバーで若干後に傾けてクラシックなんか聞いているとそのまま寝てしまったりするぐらい自分にはあっている。
あと使用上問題ないが悪いところは
・足元のローラーが5個あって頑丈なのはいいが、割とぶつかる(部屋が散らかり過ぎなだけかもしれないが)
背もたれが後に倒せるのでそれもあって少し広めなのかもしれない。
・肘掛けがチープ
肘掛けの予算が残ってませんでしたというぐらい肘掛けがチープ。見た目で選ぶときに一番気になるのがこの部分だろう。
・Made In Korea
まあ、見た目はともかく、背もたれに軽く寄りかかると椅子と一体化するような感覚がこの椅子のウリである。
デュオレストチェア 【ハイバック】 ヘッドレスト 布張り DR-7500G ブル-
- 出版社/メーカー: DUOREST(デュオレスト)
- メディア: ホーム&キッチン
1万ぐらい安いんだよぉぉぉ。
そのときになんでこれを選んだか考えてみると
・人体工学に基づいた、という類の椅子は座り難いのが多かった
・これなんかは見た目こそいかにも人間工学ってかんじだったが座ってみたらジャストフィット
他に選択の余地なく、購入した。
これをお勧めするわけではないが、椅子は通販で買わず、必ず座って確認することをお勧めする。
実際家で使ってみるとヘッドレストが若干固い以外は自分の体にジャストフィット。当然のごとくヘッドレストの高さや胴の幅、空圧での高さ調整はできるので悪くない。というかむしろいい。それまでしょぼい椅子を使ってて腰がいてーなーと思っていたが、この椅子にしてからまったく不安が無くなったし、今も使っていて買い換えようという気が起きないし、オーディオシステムでの視聴にも使えるのだから自分にとってはベストバイであったといえる。
この椅子の独特の形が背中をいいかんじに伸ばしてくれるので背筋が伸びて気持ちいい。これが通常の背もたれタイプだと背骨を圧迫されて無理やり伸ばされたりして気持よくない。
この椅子でレバーで若干後に傾けてクラシックなんか聞いているとそのまま寝てしまったりするぐらい自分にはあっている。
あと使用上問題ないが悪いところは
・足元のローラーが5個あって頑丈なのはいいが、割とぶつかる(部屋が散らかり過ぎなだけかもしれないが)
背もたれが後に倒せるのでそれもあって少し広めなのかもしれない。
・肘掛けがチープ
肘掛けの予算が残ってませんでしたというぐらい肘掛けがチープ。見た目で選ぶときに一番気になるのがこの部分だろう。
・Made In Korea
まあ、見た目はともかく、背もたれに軽く寄りかかると椅子と一体化するような感覚がこの椅子のウリである。
Visual Studio 2008がPlatform SDK for Windows 7を使ってくれない問題 [プログラミング]
思ったより検索にひっかからなかったので書いておく。
まず、環境変数 $WindowsSDKDirがv6.0からv7.1になってくれないのが問題。
似たような問題を検索かけると、確かに見つかる。
http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/9ec96544-0b7d-4b0b-8eca-dffb30a385be/
要はレジストリにキーがあって、どのPlatformSDKを使うかどうか判断している。
実際Common7\Toolsにあるvsvars32.batの中を見ると、確かにHKLMのレジストリから読んでいるように書いてある。
PlatformSDK for Windows 7をインストールすると確かにその値がv7.1になっていて、さらにsetで環境変数を確認すると、v7.1になっている。
その状態でVS2008を立ち上げて実行する・・・が、ダメッ
まだ何かあるのかと調べてみたら、どうもv6.0のエントリがHKCUにあるという情報が。よく見たらリンク先にも書いてあったが、HKCUをHKLMだと脳内変換してしまっていた。
早速見てみると謎のエントリがいっぱい・・・
v6.0は使わないどころかアンインストールされているので、まるごと消したら無事v7.1のディレクトリを見てくれるようになった。
単にVCインクルードディレクトリの指定を指定すればいいのがわかっていたが、気持ち悪かったので調べてみた。
ユーザーごとに設定できるようにと余計なお世話機能を入れたが、アンインストール時に消すのを忘れていたんだろうなぁ・・・
アメリカのソフトウェア製品はこういう余計なお世話機能を入れるのはいいけど、切れなかったり不具合があったりする印象が強い。
日本だと最初から使い物にならない印象が強いw
まず、環境変数 $WindowsSDKDirがv6.0からv7.1になってくれないのが問題。
似たような問題を検索かけると、確かに見つかる。
http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/9ec96544-0b7d-4b0b-8eca-dffb30a385be/
要はレジストリにキーがあって、どのPlatformSDKを使うかどうか判断している。
実際Common7\Toolsにあるvsvars32.batの中を見ると、確かにHKLMのレジストリから読んでいるように書いてある。
PlatformSDK for Windows 7をインストールすると確かにその値がv7.1になっていて、さらにsetで環境変数を確認すると、v7.1になっている。
その状態でVS2008を立ち上げて実行する・・・が、ダメッ
まだ何かあるのかと調べてみたら、どうもv6.0のエントリがHKCUにあるという情報が。よく見たらリンク先にも書いてあったが、HKCUをHKLMだと脳内変換してしまっていた。
早速見てみると謎のエントリがいっぱい・・・
v6.0は使わないどころかアンインストールされているので、まるごと消したら無事v7.1のディレクトリを見てくれるようになった。
単にVCインクルードディレクトリの指定を指定すればいいのがわかっていたが、気持ち悪かったので調べてみた。
ユーザーごとに設定できるようにと余計なお世話機能を入れたが、アンインストール時に消すのを忘れていたんだろうなぁ・・・
アメリカのソフトウェア製品はこういう余計なお世話機能を入れるのはいいけど、切れなかったり不具合があったりする印象が強い。
日本だと最初から使い物にならない印象が強いw
リムーバブルメディアの取り外し をWin32APIで実行する方法 [プログラミング]
久々に開発ネタ。やり方はしってはいたのだが、URL忘れるので貼っておく。
SetupDi を使用してハードウェア機器を列挙する方法
http://support.microsoft.com/kb/259695/ja
http://support.microsoft.com/kb/165721/ja
Windowsではリムーバブルメディア(USB-HDD)に大して遅延書き込みをする場合、遅延書き込みデータをフラッシュするために「安全な取り外し」を推奨している。これをやらないとメモリにデータが残っていてデータロスや、ファイルシステムの破損につながる。
一方でSATAにはeSATAという取り外し可能な規格があるが、自分が使っているSATAのホストアダプタはWindowsに取り外し可能であると通知しないため、取り外しアイコンが出てこない。
そこでHotSwap!とかのフリーウェアを使っているのだが、それの実装はこの処理をやっている。
キーワードはSetupDi/CM_あたり。ここらへんはデバイスマネージャーの機能をプログラムでできるようになっている。
プログラム組むのが面倒な場合は、devcon.exeというのもある。前にエントリ書いた気がするが。
余談だが、\\.\Xで開いたときはボリュームだが、\\.\PhysicalDeviceXで開けるのはディスクドライバだったりする。
ボリューム -> ファイルシステムドライバ -> PartMgr -> ディスクドライバ
IOCTLを出すと自分が担当じゃない場合は次に投げる処理が入っている・・・わけでもなかったりするので、ディスク全体の情報を有機的に調べる方法が意外に難しい。
USB-HDDなどをOSが認識した場合
・ホストアダプタがOSへ新しいドライブができたことを通知する
・ディスクドライバが物理デバイスオブジェクトに貼りつく(これがいわゆるFDO)
・ディスクドライバのUpperFilterであるPartMgrがMBRを読み込み、パーティション管理を行う
・Windowsの誰かからIOCTL_DISK/IOCTL_STORAGEでその情報を取得しにくる
・パーティションがNTFSだとNTFSドライバが動き出す(フィルタドライバがあればそれも動き出す)
というような流れになっている。ことから以下のことがおこる
・\\.\PhysicalDeviceXでNTFSでフォーマットされたディスクを直接書き換えると確実に破損するし、キャッシュとの不整合がおきる
・同様にMBRを物理的に書き換えても、上位のPartMgrやNTFSが知るすべが無いのでOSは知らんぷり。再接続したときだけわかる。
・NTFSはパーティションのことしか知らないので、そのパーティションが物理デバイスのどこにあるかはIOCTL_DISK/STORAGE_なんちゃらを出さないといけない。
・FSCTL_はNTFSへ、IOCTL_DISK/STORAGEはディスクへ出す物と考えていいはずだが、実際はキャッシュされているし、OSからのシーケンスでしか動かないので制約が多い
例えば上記のように知るすべがないから自分がIOCTLを出して変更を促そうと思っても覚えているのが別の何かでそいつがリクエストを出してこないといけないので意味が無い。Windowsだとこういう制限が多すぎて開発する気力が亡くなる人も多いのではないだろうか。
ここらへんのことをまともに書いた本が無いのがまた困る・・・
NTFSについては以下の本が素晴らしいのだが、古いからセキュリティに付いての記述がない上に絶版。しかも真面目につくろうとするとアンドキュメンテッドな事象に遭遇しまくる。
SetupDi を使用してハードウェア機器を列挙する方法
http://support.microsoft.com/kb/259695/ja
http://support.microsoft.com/kb/165721/ja
Createfile を GENERIC_READ|GENERIC_WRITE、FILE_SHARE_READ|FILE_SHARE_WRITE、し OPEN_EXISTING を使用します。LpFileName\\.\X パラメーターに指定する必要があります: (X は、実際のドライブ文字)。他のすべてのパラメーターは 0 になります。 FSCTL_LOCK_VOLUME IOCTL を使用して発行することによって、ボリュームをロックします。DeviceIoControl。その他のアプリケーションまたはシステムを使用している場合は、ボリューム、この IOCTL は失敗します。この関数を正常に戻ると、アプリケーション ボリューム以外が使用されていないことが保証されています。このシステムでは。 FSCTL_DISMOUNT_VOLUME IOCTL を発行することによって、ボリュームをマウント解除します。これボリュームのすべての情報を削除するのには、ファイル システムをがボリュームが関係を維持する内部情報を破棄します。 実行して、メディアを削除できるかどうかを確認、IOCTL_STORAGE_MEDIA_REMOVAL IOCTL。PreventMediaRemoval のメンバーを設定します。PREVENT_MEDIA_REMOVAL 構造体を FALSE この IOCTL を呼び出す前にします。これは、デバイスからメディアの削除を防ぐを停止します。 IOCTL_STORAGE_EJECT_MEDIA IOCTL とメディアを取り出します。場合は、デバイスIOCTL_STORAGE_EJECT_MEDIA することができますし、自動排出をすることはできません。スキップし、ユーザーがメディアを削除するように指定できます。 閉じる、ボリューム ハンドルを取得、最初のステップの問題で、FSCTL_UNLOCK_VOLUME IOCTL。これは、ドライブを使用することができます。他のプロセス。
Windowsではリムーバブルメディア(USB-HDD)に大して遅延書き込みをする場合、遅延書き込みデータをフラッシュするために「安全な取り外し」を推奨している。これをやらないとメモリにデータが残っていてデータロスや、ファイルシステムの破損につながる。
一方でSATAにはeSATAという取り外し可能な規格があるが、自分が使っているSATAのホストアダプタはWindowsに取り外し可能であると通知しないため、取り外しアイコンが出てこない。
そこでHotSwap!とかのフリーウェアを使っているのだが、それの実装はこの処理をやっている。
キーワードはSetupDi/CM_あたり。ここらへんはデバイスマネージャーの機能をプログラムでできるようになっている。
プログラム組むのが面倒な場合は、devcon.exeというのもある。前にエントリ書いた気がするが。
余談だが、\\.\Xで開いたときはボリュームだが、\\.\PhysicalDeviceXで開けるのはディスクドライバだったりする。
ボリューム -> ファイルシステムドライバ -> PartMgr -> ディスクドライバ
IOCTLを出すと自分が担当じゃない場合は次に投げる処理が入っている・・・わけでもなかったりするので、ディスク全体の情報を有機的に調べる方法が意外に難しい。
USB-HDDなどをOSが認識した場合
・ホストアダプタがOSへ新しいドライブができたことを通知する
・ディスクドライバが物理デバイスオブジェクトに貼りつく(これがいわゆるFDO)
・ディスクドライバのUpperFilterであるPartMgrがMBRを読み込み、パーティション管理を行う
・Windowsの誰かからIOCTL_DISK/IOCTL_STORAGEでその情報を取得しにくる
・パーティションがNTFSだとNTFSドライバが動き出す(フィルタドライバがあればそれも動き出す)
というような流れになっている。ことから以下のことがおこる
・\\.\PhysicalDeviceXでNTFSでフォーマットされたディスクを直接書き換えると確実に破損するし、キャッシュとの不整合がおきる
・同様にMBRを物理的に書き換えても、上位のPartMgrやNTFSが知るすべが無いのでOSは知らんぷり。再接続したときだけわかる。
・NTFSはパーティションのことしか知らないので、そのパーティションが物理デバイスのどこにあるかはIOCTL_DISK/STORAGE_なんちゃらを出さないといけない。
・FSCTL_はNTFSへ、IOCTL_DISK/STORAGEはディスクへ出す物と考えていいはずだが、実際はキャッシュされているし、OSからのシーケンスでしか動かないので制約が多い
例えば上記のように知るすべがないから自分がIOCTLを出して変更を促そうと思っても覚えているのが別の何かでそいつがリクエストを出してこないといけないので意味が無い。Windowsだとこういう制限が多すぎて開発する気力が亡くなる人も多いのではないだろうか。
ここらへんのことをまともに書いた本が無いのがまた困る・・・
NTFSについては以下の本が素晴らしいのだが、古いからセキュリティに付いての記述がない上に絶版。しかも真面目につくろうとするとアンドキュメンテッドな事象に遭遇しまくる。
Windows NT ファイルシステム詳説―A Developer’s Guide
- 作者: ラジーブ ナガール
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 1999/01
- メディア: 単行本
プログラムと登山は似ている [プログラミング]
・山の規模によって装備を変える必要がある
近所の裏山を登るのは普段着でよいが、富士山を登ろうと思ったらそれなりの装備が必要。
標高が高いところへ行くには、事前調査、スキル、体力が必要。
・冬の登山をなめない、無理だと思ったら一度安全地帯へ戻る勇気が必要。
ブリザードがくるとわかってても登り続ける馬鹿はいない。
・そのためには天候の変化を感じ取る経験も必要
正しい判断をするためには正しく自然から学ばねばならない。
・遭難した、しそうなときの準備を怠らない。
・道がわからないなら地図が必要
・兵糧が尽きると悲惨なことになる
判断を誤ると右京になってしまう。
なんでこんなことかいたかというと、別の人がやってるプロジェクトが遭難直前だから。
上記に書いたことが何一つ守られていない
・不可解で巨大なソースがある
ルールがまったくない
文字コードすら統一されていない
謎の数字による分岐多数
・仕様書がない
・バージョン管理をしていない
「戻る」ことができないので闇雲に進むしか無い
・締切り直前
どうやっても終わらなさすぎて他人ごとながら心配である。
近所の裏山を登るのは普段着でよいが、富士山を登ろうと思ったらそれなりの装備が必要。
標高が高いところへ行くには、事前調査、スキル、体力が必要。
・冬の登山をなめない、無理だと思ったら一度安全地帯へ戻る勇気が必要。
ブリザードがくるとわかってても登り続ける馬鹿はいない。
・そのためには天候の変化を感じ取る経験も必要
正しい判断をするためには正しく自然から学ばねばならない。
・遭難した、しそうなときの準備を怠らない。
・道がわからないなら地図が必要
・兵糧が尽きると悲惨なことになる
判断を誤ると右京になってしまう。
なんでこんなことかいたかというと、別の人がやってるプロジェクトが遭難直前だから。
上記に書いたことが何一つ守られていない
・不可解で巨大なソースがある
ルールがまったくない
文字コードすら統一されていない
謎の数字による分岐多数
・仕様書がない
・バージョン管理をしていない
「戻る」ことができないので闇雲に進むしか無い
・締切り直前
どうやっても終わらなさすぎて他人ごとながら心配である。
Mercurial MQのまとめ [プログラミング]
2chで話題になったので自分の使い方のまとめてみた。
■初期化
hg qinit
■編集、パッチ作成
hg qnew -f [patch_name]
■他の人の更新の取り込み
複数人開発でコミットするときにブランチを作りたくないので
hg qpop -a
hg pull
hg update
hg qpush [-a]
qpop/qpushで適用、未適用ができる。
■順番を入れ替えたいとき
hg qpop -aしてから
.hg/patch/seriesの順番を書き換えてもうまくいく。
本当は正しい方法があるのかもしれんが。
■パッチのコミット化
hg log -l[[:digit:]] で確認 qbaseやqtipなどのタグが増えている。
hg logで確認してテスト用のパッチをコミットしてしまわないようにする。
hg qfin -a
そもそもMQを使うと良いのは
hgで間違ってコミットしたときに消せないから。
MQで仮コミットして簡単にビルド、デバッグまでやってからコミットしてる。
で、確認中に誰かがコミットするかもしれないので、コミット前に上記の更新作業をやってから、コミットする。
独りで使う場合も、複数の変更を1つのチェンジセットにいれるのは躊躇われるので、qnew [-f]でガンガンパッチを作るようにしている。
なお、ヘッドを消したい場合はcloneでリビジョン指定するようだ。
http://mercurial.selenic.com/wiki/PruningDeadBranches
■初期化
hg qinit
■編集、パッチ作成
hg qnew -f [patch_name]
■他の人の更新の取り込み
複数人開発でコミットするときにブランチを作りたくないので
hg qpop -a
hg pull
hg update
hg qpush [-a]
qpop/qpushで適用、未適用ができる。
■順番を入れ替えたいとき
hg qpop -aしてから
.hg/patch/seriesの順番を書き換えてもうまくいく。
本当は正しい方法があるのかもしれんが。
■パッチのコミット化
hg log -l[[:digit:]] で確認 qbaseやqtipなどのタグが増えている。
hg logで確認してテスト用のパッチをコミットしてしまわないようにする。
hg qfin -a
そもそもMQを使うと良いのは
hgで間違ってコミットしたときに消せないから。
MQで仮コミットして簡単にビルド、デバッグまでやってからコミットしてる。
で、確認中に誰かがコミットするかもしれないので、コミット前に上記の更新作業をやってから、コミットする。
独りで使う場合も、複数の変更を1つのチェンジセットにいれるのは躊躇われるので、qnew [-f]でガンガンパッチを作るようにしている。
なお、ヘッドを消したい場合はcloneでリビジョン指定するようだ。
http://mercurial.selenic.com/wiki/PruningDeadBranches
ハートキャッチプリキュア問題を考える [プログラミング]
Windows Vista/7 ではハートキャッチプリキュアを「プリキュア」で検索できない
これは、日本語の形態素解析(日本語の分割)が難しいためにおこる
ハートキャッチプリキュア はどこで切れるだろうか?
人間の場合、ハート、キャッチ、プリキュアが単語だと分かっているが、機械にはそういうものだと教えないといけない。あと、小さいお友達の場合、プリキュアの意味はわかっていても、ハートキャッチの意味がわからないので、ハートキャッチが単語だと思っているかもしれない。そもそもアニメを知らない人は「プリキュア」という単語の意味がわからない。人間でもその人の知識が重要になってくる。
XPのときはなぜ検索できていたのかというと、馬鹿真面目にハートキャッチプリキュアの1文字目と比較、2文字目と比較・・・8文字目と比較、一致 というようなことをしている。(実際にはもうちょっと高度な方法もあるが基本的な考え方は同じ)
分割の難しさはいつものWikipediaに書いてある
日本語の形態素解析における諸問題
http://ja.wikipedia.org/wiki/%E5%BD%A2%E6%85%8B%E7%B4%A0%E8%A7%A3%E6%9E%90#.E6.97.A5.E6.9C.AC.E8.AA.9E.E3.81.AE.E5.BD.A2.E6.85.8B.E7.B4.A0.E8.A7.A3.E6.9E.90.E3.81.AB.E3.81.8A.E3.81.91.E3.82.8B.E8.AB.B8.E5.95.8F.E9.A1.8C
大学ではこの形態素解析は昔から論文のネタだし、携帯電話やWebの登場で、コンピューターの文字の理解力というものが非常に重要になっている。
なのに天下のMSが欠陥製品とも言うべきものを何故だしてしまったのか?
これは本国と日本との力学にあると推測する。
米「Vistaから形態素解析使って検索できるようにしたから」
日「えっ、日本語だとすごいデータベース使ったりしないとだめなんだけど・・・どうにかならない?」
米「この天才米様の考えた仕様にケチつけるやつがいるとはな・・・おまえクビ」
日「あ、うそうそ、すばらしいです。はい。認識率もばっちりです。はい。」
そして発売され、検索を利用するユーザーが途方にくれる。
この問題、MSは認識しつつも解決しようとしない。
Windows Vista の検索において、語句が検索されない場合がある
http://support.microsoft.com/kb/952003/
所詮日本語ローカルの問題ですからね。アメリカさんは真面目に対処してくれないのは当然です。
ちなみにGoogleは形態素解析のプロを雇ってGoogleIMEを作りました。
http://mecab.sourceforge.net/
これは、日本語の形態素解析(日本語の分割)が難しいためにおこる
ハートキャッチプリキュア はどこで切れるだろうか?
人間の場合、ハート、キャッチ、プリキュアが単語だと分かっているが、機械にはそういうものだと教えないといけない。あと、小さいお友達の場合、プリキュアの意味はわかっていても、ハートキャッチの意味がわからないので、ハートキャッチが単語だと思っているかもしれない。そもそもアニメを知らない人は「プリキュア」という単語の意味がわからない。人間でもその人の知識が重要になってくる。
XPのときはなぜ検索できていたのかというと、馬鹿真面目にハートキャッチプリキュアの1文字目と比較、2文字目と比較・・・8文字目と比較、一致 というようなことをしている。(実際にはもうちょっと高度な方法もあるが基本的な考え方は同じ)
分割の難しさはいつものWikipediaに書いてある
日本語の形態素解析における諸問題
http://ja.wikipedia.org/wiki/%E5%BD%A2%E6%85%8B%E7%B4%A0%E8%A7%A3%E6%9E%90#.E6.97.A5.E6.9C.AC.E8.AA.9E.E3.81.AE.E5.BD.A2.E6.85.8B.E7.B4.A0.E8.A7.A3.E6.9E.90.E3.81.AB.E3.81.8A.E3.81.91.E3.82.8B.E8.AB.B8.E5.95.8F.E9.A1.8C
大学ではこの形態素解析は昔から論文のネタだし、携帯電話やWebの登場で、コンピューターの文字の理解力というものが非常に重要になっている。
なのに天下のMSが欠陥製品とも言うべきものを何故だしてしまったのか?
これは本国と日本との力学にあると推測する。
米「Vistaから形態素解析使って検索できるようにしたから」
日「えっ、日本語だとすごいデータベース使ったりしないとだめなんだけど・・・どうにかならない?」
米「この天才米様の考えた仕様にケチつけるやつがいるとはな・・・おまえクビ」
日「あ、うそうそ、すばらしいです。はい。認識率もばっちりです。はい。」
そして発売され、検索を利用するユーザーが途方にくれる。
この問題、MSは認識しつつも解決しようとしない。
Windows Vista の検索において、語句が検索されない場合がある
http://support.microsoft.com/kb/952003/
所詮日本語ローカルの問題ですからね。アメリカさんは真面目に対処してくれないのは当然です。
ちなみにGoogleは形態素解析のプロを雇ってGoogleIMEを作りました。
http://mecab.sourceforge.net/