本日408mだそうな。
海抜からの高さなのか、地表からの高さなのかはさておき、あそこらへんの地表高さ自体大したことないことを考慮すると、そりゃとんでもない高さと言えましょう。
確かに土台部分の裾野は広がる錐になっているとは言え、しかしとんでもないスリムなノッポさ加減に、まず驚くこと請け合い。
と、いろいろ書きたいのだが、明日にします。
理由も明日にします。
[PR] Excelで多桁計算するなら「Addin for Excel 95-2007 Basic Edition」!
[PR] 古い通信アプリにも安心を。OverSslの継続公開についてはコメントをください。
[PR] 古い通信アプリにも安心を。OverSslの継続公開についてはコメントをください。
2010年7月アーカイブ
書き換え方が悪いのか、書き換える場所が悪いのか・・・
イーサフレーム書き換えることはできても、発信できていなく、ダメっぽいので、別な方法を探そうと思ったのだった。
やはり、NICに到達しちゃったあとで、送信先MACアドレスまで入ったイーサフレームも出来上がった後で何かしようと思うのは、そもそもの間違いなんだろうな。
とりあえず、またサンプルを漁るか・・・
イーサフレームを書き換えるところまではできた。
でも、まだTCPコネクションを確立できていない。
意図した書き換えもできてるし、書き換えた結果、影響は与えられているようなので、書き換える値などをもう少し見てみる予定。
超面倒・・・
ドライバはカーネルモードで動くわけで、かなりの特権が与えられる。
そんなものが、無暗にメモリを喰いまくったり、例外吐いたりしたらえらいことになるわけだということは薄々気が付いていた。
サンプルコードを見ても、alloc系関数は特定要素の生成に特化したものだったりするのは当たり前だと思ったのだが、どうも、メモリ確保には細心の注意というか、気軽にメモリ確保しちゃいけないんじゃないかと、思ったのは、今日。
一時的なメモリ領域で、固定長にできず、しかし、内容解析のために連続領域が必要・・・といった場合でも、それを確保せずに済ませる方法を考えた方が、どうやらいいらしい。
メモリ確保しないとか、変数を使わないのは、XSLTで慣れてる？
打ち上げ花火は夏の風物詩だが、実は夏場の渇水対策のための雨乞いなんじゃないかと思う。
特に、あの音と煙は雨を呼ぶのに最適だ。
音は大気を揺らし、煙は微粒子。
大気中の水分を水滴や氷粒へと変えるきっかけになる。
水滴や氷粒は雨となって降り注ぐ。
渇水の心配が無く、逆に大雨で困る地域、またはその風上に位置する地域であれば、花火大会などの開催はもしかすると控えるべきではないかと思う。
ま、でも、風物詩だからねぇ・・・
悪戦苦闘の末、読めたのだが・・・
どうやら取得できたのは、IPパケットじゃなくそれを含んだイーサパケットらしい。
まぁ、そりゃ宛先を決めるのならIPアドレスじゃなくてMACアドレスが必要だよねぇ・・・
じゃなくて、そんなところまでいかないうちに、ループバックさせないとマズイのかも。
と思いつつ、書き換えできるかを先に試してみようかと思う。
当たり障りの無い情報ならいくらでもあるんだけど、ドライバ開発するための資料となると、Webですら殆ど見つからない。
DDK(WDK)のサンプルを選んで、デバッグ表示でIPパケットダンプしようと思っただけなのに、明らかにそこに目的のIPパケットがありそうなのに、もうやり方が分からない。
ヘルプ読むと、関数とかマクロ使えとか書いてあったりするんだけど、具体的な関数名やマクロ名が分からん。
気長にコツコツやるしかないのだろう。
そのうち分かってくるといいなぁ。
HotFixを適用してみた。
一応、ショートカットの殆どからアイコンが消えた。
＃一部アイコンが表示されたままになっているものがあるけど、なんでだろ？
＃プロパティ見ると、ちゃんとアイコン不明になってんだけどねぇ？
にしても、少し使いにくくなったのは否めない。
アイコンなんてただの飾りだと思っていたんだけど、ちゃんと識別マーカーになってたんだと再認識。
久しぶりに通電したら、MC-R700、電源まわりで問題があるらしく、充電うまくできなくてご臨終。
電源プラグまわりからしておかしく、ちょっと動かすと断線してしまうらしく、バッテリ充電もできない状態では、そのたびにシステムが初期化されるという、どうしようもない状態に。
まぁ、CE2.11だから今となってはつかいみちあまり無いんだけど、CFとPCの2スロット構成で、SVGA画面となれば、何かに使えそうな予感だけはしていたんだけど。
残念。
http://www.microsoft.com/japan/technet/security/advisory/2286198.mspx
これはヤバいかも。
多分、Windows 2000とかも影響受けるんだよね・・・
＃サポート切れてるから書かれてないだけだろう。
9xとかは当然、HotFixも出ないだろうし。
＃一気にOS更新をさせようとするベンダーの策略か？
経路としては特にWebDAVがマズイな。
＃個人的には使ってないけど。
.lnkと.pifだけのように書かれているけど、.urlは問題無いのかな？
XPのDDKと最新のWDKを落としてきて、英語とにらめっこしたり、サンプルコード見たりしてるんだけど、いまいちよく分かっていない。
やりたいことは分かっている。
IPパケットの書き換えだ。
直接TCP内容を書き換えるか、宛先だけをを書き換えて別プロセス(socketベースのアプリケーション)で書き換えを行わせるか、どちらかの方法でできるはずだとは考えているのだが、やはり、よくわからない。
Vista以降の場合、何とかサンプルになりそうなものを見つけはしたものの、XPでの方法がよくわからない。
やはりいきなりドライバってことに無理があるのだろうか？
最初から順番にやっていかないとダメなんだろうか？
OverSsl Clientのコンセプトは良いはずだ。
暗号化で安全な通信経路を保障しちゃうのは結構ありがたいはずだ。
だが、問題はいくつかある。
＃STARTTLSに対応できないのはコンセプト上、仕方ないのだが。
一番の問題は、アプリケーションの設定を変更しなければならないことだ。
この変更に対応できない場合はとても残念なことだが利用できない。
例えばWWWブラウザなどはその最たるものだ。
そして、それは、サーバーを固定指定することに起因する。
OverSsl Serverの場合は、この仕様で問題ないのだが、Clientでは問題となるわけだ。
他にも問題はあるのだけれど、この問題が解消できると、クライアントアプリケーションの設定を不要にできる可能性が出てくる。
つまり、あまりネットワークを知らない一般ユーザでも導入が簡単になる可能性がある。
続きを読む: 大いに悩む
http://internet.watch.impress.co.jp/docs/column/jirei/20100714_380352.html
↑この事例とそのあとの話の繋がりは少しおかしい。
無線LANの暗号化は、アクセスポイント－無線機器の間で行われるもので、通信経路全体を暗号化しているわけではない。
だから、WEPだろうがWPA/WPA2だろうが、アクセスポイントまで到達できてしまった通信は、それより先では無防備になる。
WEP解読云々は別の話である。
APで受け取ったパケットを解析すれば、無線LANの暗号化なんて、関係ないのだから。
＃だからといって、無線LAN暗号化が不要だとか、知らないAPを使っていいというわけではないので、注意。
記事の事例に限れば最も重要な解は、記事の最後の方にあるメールのSSL暗号化だ。
通信中の情報保護をするのなら、通信経路全体を暗号化する必要がある。
通信経路全体を暗号化するのならば、やはり、クライアントからサーバーまでEnd-to-Endの暗号化が保障されたほうがいい。
SSL暗号化はその一つの解で一般的だと思う。
古いクライアントアプリケーションだと、SSL暗号化通信に対応できてないものもあるので、そういう場合は、OverSsl *を使えばいいのにって話になる。
＃iOSには対応しておりませんが。
ただ、メールの場合、暗号化されたところで、所詮メールサーバーまで。
そこから先の転送(目的のアドレスのメールボックスを保有しているサーバーへの通信)が暗号化されていないと意味は薄れるわけだが。
円周率を追加したアドインの評価を完了。
あとはドキュメントだけ。
鋭意執筆中。
公開されるのは来週・・・かな。
んー、おまけにいくつか関数ぶち込んであるんで、ぜひレジストして全関数を使ってほしいのだけどなぁ。
というのはさておき、現在公開中の0.7.1にもある問題が解決できていない。
続きを読む: Excelアドイン評価完了
なんか、できそうだったので、やってみた。
元ソースは過去のC/C++コード。
非同期パケットダンプがちょっと固まりやすいけれど、一応できた。
＃固まるってのは、Rawパケ採取にBackgroundWorker使ってんだけど、激しいProgressChangedによって、Form描画が詰まっちゃってるっぽい。←応急処置入れたので固まりにくくなったと思う。
あと、停止時に例外出るのは仕様。
一応、実行ファイルだけ置いておく。
OverSsl使った場合、ちゃんと暗号化されていることが、視覚的に分かるぞ。
さすがに、XP以降じゃないとダメかも。
要.NET Framework 3.5だし。
IPv6でも動くかも知れないけど、未確認。
＃IPv6ヘッダ解析はIPアドレス部分だけ入れてあるつもりだけど。
(追記)実行には管理者権限が必要です。
とりあえず、フルマネージコードでRawパケ採取できることが分かったことは収穫。
いつからかは定かではないけれど、キータイプ属性値に変更があったようで。
CUS と Custom Key の両方に対応してはじくようにしたので、変更前でも変更後でもOK。
本当はもっと効率がいいXSLT記述があると思うけど、個人的には、元XMLに手を加えることなくテーブル表示できるだけでいいので、これで十分かつ超便利。
そして、アドインを登録しようとして、重大なエラーとやらが出る。
Heap blockなんとか～ってエラーだとわかり、解放時のエラーらしいというのは分かったのだが、デバッグモードでトラップするのは、非常に困難。
- Excelにあらかじめアドイン(ちゃんと登録できるやつ)を設定しておく
- デバッグビルド物件に置換
- VSデバッグモードでExcelを起動(アドインを引数にしない)
- 操作等を実施
- 例外ダイアログが出たら、デバッグでコードが出るところまで何度かボタンをクリック
これで、何とか原因を突き止めることができる。
今回の問題は、デバッグ実行時の引数にアドインを指定してると呼び出されない関数にあったので、はじめはわけが分からなかった。
＃現在リリースされているものとは違うコードです。
こういう手法に気付くまでが大変だけど、コードや呼び出し履歴を掴めれば、どこの何が原因かを判別するのが容易になる。
ま、PRですし、既出ですが。
まずは、OverSsl Clientをインストールして、↓こんなふうに設定を追加しますよ。
続きを読む: HTTPSサイトで何が返っているかを確認する冴えたやり方
ま、気にする人はいないだろうけど、メモがてら。
- 絶対値・・・実装。
- 円周率・・・実装。
- SQRTPI相当・・・実装延期。
- 桁指定・・・実装延期。
- SUM系・・・実装延期。
- 数値化・・・追加実装。
ま、こんなところか。
円周率は出せているし、絶対値も現状用意済みの内部関数を呼ぶだけ。
あとは数値化だが、これも何とかなったっぽいので、これで、出せる・・・と思うのだが、デバッグモードで実行すると、例外がボロボロ出るところがあるので、原因を調べてからにしたい。
数値化はとても便利かも知れない。
＃現状、Excelには255文字以上の数値文字列を数値化する関数が無い。
64bit版もできるんだけど、これは要望か何かがあるなら考えるけど、メジャーバージョンアップまで非公開の予定。
続きを読む: 予告の変更
と、声に出して言いたい。
パイと言っても円周率(π)ですが。
いや～、スタティックライブラリのリソースからロードするのって、結構難しいですね。
あと、ちょっとリソースファイルの編集について、インクルードを処理するのは、リソースビューで開いて、「リソースファイルのインクルード」でやると簡単だったことをメモしておく。
で、πですが、こんな感じ。
続きを読む: パイ出た！
しかし、もし、仕様ならば、仕方ないし、そうじゃなくても、現状そうならばそうで対処するしかない。
＃回避策があるのならば、それに頼る。
＃＃回避策が無いのに、不具合を仕様と言っちゃう(再起動したところで、再現を繰り返すだけ)のは愚かなだけだが。
とりあえず、関数の説明は同梱のPDFにお任せしちゃうことで、無しにすることは不可能ではないので、それで対応してみる。
さて、円周率3万桁、ちゃんと出るかはこれから確認。
例のXLLSDKをやっと取り込んだんだけど、やはり引数なしでうまくいかない。
サンプルだと引数なし関数の登録がうまくいくのかと思っていたのだけれど、試しに関数の説明まで出そうとしたところ、引数ありになってしまうことが分かった。
関数の説明を端折ると、引数なしとして登録できる。
これは誰のせいなのか、全く分からないのだけれど、Excelのせい？なのか・・・よくわからん。
とりあえず、Excel2003でも2010でも挙動が同じだったこと、VS2008でもVS2010でも結果は変わらなかったことをメモとして残しておく。
いやはや、さて、困ったぞ。
本読んでもこのあたり書いてないんだよなぁ・・・
あと、文字列(関数の説明以降)の最後1文字が切れるのも俺のせいじゃないらしい。
そういえば、引数なし関数がうまく登録できないとき、関数の引数んとこに空白1文字入ってるっぽいんだよね。
余分な1文字と無くなる1文字で辻褄は合ってるのか・・・？
んー、英語版Excelで試してみるか・・・
