Posted on 2014年10月24日(金) 01:00
タイトルのとおり。
どうも、Windows相手にNetBIOSの名前解決を試みると失敗することがあるようです。
ネットワーク・アナライザで見ると、リクエストは飛んでるのに応答が来ない。
発生条件は不明ですが、テストで変なリクエスト送ったあとに起きやすい気がするけど、何もしてなくても起きる時もある。
理由は不明ですが、一旦失敗するようになると、特定のIPアドレスから発信したものに対して応答が返らなくなる模様・・・。
全くそのままでIPアドレス変えると動くようになります。
このあたりエラーメッセージを簡略化してたので（接続できませんでしたくらいに）、次からメッセージ入れようと思います。
基本ここで失敗はしないと思っていたので。
どうもSMB/CIFS周りはロバスト性に欠けてやっかいですわー。
Windows同士でも調子わるいときありますもんね。
無駄にSMB/CIFS周り（のバッドノウハウ）に詳しくなっていく・・・。
Posted on 2014年9月19日(金) 16:24
とりあえず速報です。
iPhone6 Plus買いました。
でかいですね。
最初の設定時に気づいたのですが、「拡大モード」というのがあります。
シミュレータにはありませんでした。
その名のとおり、画面の要素全体が大きめになります。
アプリ側でそのような情報は来なかったと思うので、どのように対応しているかと思ったらピクセル数がiPhone6と同じになるようです。
さらにHOME画面も回転しなくなったりなど、まさにiPhone6のようになります。
よって、開発者はiPhone6PlusがあればiPhone6の解像度もテストできますよね。ステキ！
以下が検証結果です。
なんと！
iPhone6 Plusの拡大モードは、ピクセル数はiPhone6と同じですが、画面のscaleが@3x相当になってますね。
つまりまさかの新しいスクリーンサイズが今日新たに判明です！ ステキ！
deviceName=x86_64
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=2.000000
deviceName=x86_64
[UIScreen mainScreen].bounds=(414.000000,736.000000)
[UIScreen mainScreen].scale=3.000000
deviceName=iPhone7,2
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=2.000000
deviceName=iPhone7,1
[UIScreen mainScreen].bounds=(414.000000,736.000000)
[UIScreen mainScreen].scale=3.000000
deviceName=iPhone7,1
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=3.000000 ←New!
Posted on 2014年9月2日(火) 23:07
昨日、ComicGlassのアップデートのためiTunes connectにアプリを送信したところ、CFBundleShortVersionStringが無いということで警告が出ました。（警告は出ましたがアップロード自体は受理されてステータスはWaiting For Reviewに）
ComicGlassを最初に作ったのはiOS3の頃です。その時にはCFBundleShortVersionStringが無かったようでxcodeで自動的に作られなかったので今までずっと無いままでした。CFBundleShortVersionString無いなーとは思ってたんですが、バージョンアップのとき変更するの一つでいいし楽だからいいやと放置してました。
前回までは警告出なかったので最近警告が出るようになったんだと思います。
このCFBundleShortVersionStringですが、本来はピリオドで区切った３つの数字を用いるのが正しい表記のようです。10.0.1みたいな感じですね。現在ComicGlassのバージョン表記は7.50といった２数字表記になっているのでいつか改めないといけないかもしれません。警告が出るようになったということは今後厳格にチェックが入る前触れかもしれないので・・・。
なお、現在のところCFBundleShortVersionStringが３数字になっていなくても（7.50.1ではなく7.50とかでも）警告なく通るようです。
新たにアプリ作るときは正しいフォーマットでバージョン番号を付けたほうが良いと思われます。
お気をつけください。
Posted on 2014年6月9日(月) 06:05
詳細
後日また詳細に書こうと思いますが、ComicGlassの次バージョンにてSMB2プロトコルへの対応とSMBサーバ機能が利用できるようになりました。
SMB2はWindows Vista以降で利用できるプロトコルでWindowsXP/WindowsServer2003以前で使われていたSMB1の後継プロトコルになります。
現在ほとんどの機器がSMB1に対応して動作していると思いますが、XPのサポート期限も切れ、WindowsServer2003のサポートもまもなく切れますのでSMB2以降が主流になってくるかもしれません。
Windows8以降では高セキュリティ設定をするとSMB1が使えないことがあります。
SMBサーバ機能は、文字通りSMBサーバ（ファイル共有サーバ）として動作する機能です。
WindowsのエクスプローラーからComicGlass内のファイルを読み書きできます。
書き込みはもちろん、読み出しも出来ますし、直接ファイルを開いて確認することも可能になります。
フォルダを内容を含めてコピーしたり、ファイル名をPCから編集することも出来ますのでファイルの管理やバックアップが大変便利になります。
ただし、エクスプローラーで開いたままiPhoneをスリープしたりアプリを終了してしまうとWindows側がタイムアウトするまで困ったことになりますので使い方には少し注意が必要です。
（一応、ファイルへのアクセス中は自動的にiPhoneがスリープしないように実装してあります）
実装について
SMBの実装はVisuality Systems社のCIFS NQを使っています。
製品なので、接続互換性のテストがしっかりされており、（おそらく通信相手の仕様間違いも含めて（例））色々な相手と正しく通信できると思います。
基本用途は組み込み向け製品向け製品なのでiOSに移植するために実装した部分で不具合がある可能性は多分にありますが、とりあえず安定した通信が期待できるのではないかと。
（一応当面は旧独自実装も使えるよう、選択式にしてあります。これまで問題なかったのに問題が起きたという場合には旧設定にしてみてください。そして発生状況を教えて頂けると大変助かります）
Posted on 2014年6月9日(月) 02:54
重い腰を上げて、GoogleDrive対応を実装しました。
前にAPIを少しみた段階で”うえっっ”てなって放置していたのですが、ちょっと癖があるんですよね。
基本はHTTPなので、通信内容に癖があるわけじゃないのですが、SDKが微妙に使いづらいのです。
といっても作りが悪いわけでなく、GoogleDriveだけでなくGoogleの汎用ライブラリを使っているのが原因です。
ファイルのダウンロードは比較的簡単ですが、ストリーミングが少し面倒でした。
どうしても細切れにアクセスすることになるのでパフォーマンスがいまいち。
もう通信自体Googleのソース使わずに全部独自に実装してやろうか・・と思いましたがあまりに大変すぎて断念。
また、ComicGlassではリモートのファイル一覧を開いた状態のまま、アプリのスリープ中や終了後も状態やリストを保持する機能があります。
モバイルデバイスですから、前の状態からいつでも再開できるというのは重要なことです）
ここがまた問題で、GoogleDriveが返すファイルにアクセスするためのユニークURIが時間が経つと（正確にはセッションが新しくなると）勝手に変わります。
といわけで、前回開いていたファイルが現在どのファイルなのかをマッチングする必要があります。
この辺もURIが変わったら自動的に情報を再取得することで問題を回避しました。
たまに失敗しますので、どうしてもエラーになる場合は接続からやりなおしてください。
Posted on 2014年3月23日(日) 02:03
かつて、LinuxからSambaを使ってWindowsのファイル共有にアクセスすると、文字コードの変換の問題で大変苦労しました。
時代は流れ、LinuxでもWindowsでもUnicodeが標準になりました。
というわけで、一般的にSMBを使う分には文字コードで苦労することはほぼなくなりました。
しかし・・・。
とりあえず以下の画像をご覧ください。
これはWindows8のエクスプローラーの画面です。
何かおかしいところにお気づきでしょうか。
おかしいですよね。
いいおっさんがプリキュア・・・じゃなくて、同一のファイル名が同じフォルダに存在しています。
実はこれ、「ピ」と「プ」の文字がUNICODEの結合文字列になっています。
通常、Windowsで「プリキュア」と入力した場合、「プ」の文字はU+30D7になります。
しかしMacOSで「プリキュア」と(ファイル名として)入力した場合、「プ」の文字はU+30D5 U+309Aになります。
U+30D5は「フ」です。
U+309Aは半濁点記号です。
つまり、「フ」＋「゜」の合成で表現されます。
（なお、ここに書いた「゜」はU+309Cで、合成用ではなくそういう１文字ですので念のため）
Unicodeではこのような複数の表現方法があります。
混ざってる何かと困るので、普通は同一コードになるように正規化して扱います。
合成した方を使うのをNFC(Normalization Form Canonical Composition)、分解した方を使うのをNFD(Normalization Form Canonical Decomposition)と言います。
さて、最初の画像のファイル名ですが、「パ」と「プ」の表現方法を結合文字列、合成文字、混ぜてあります。
結果として４パターンの同名ファイル名が出来てしまったわけです。
何故かWindowsは上記のような状態を許してくれます。
許しているというか、初期の頃になんの正規化もせず扱ってしまったため、以後もそのままになっているんだと思います。（憶測）
さて、一方MacOSですが、上記のようなNFD,NFCの混在を許してくれません。
必ずNFDライクな正規化をされます。（正確にNFDでないのがまた困るんですが・・・）
iOSも一緒です。
よってファイル共有をすると大変困ります。
SMBには明確な仕様がない（もしかしたらあるかもしれなけど、ドキュメント読む限り発見できず）。
おそらくWindowsなのでNFCのUTF16 Little endianなんでしょうが、NFDでもプロトコルとしては問題なく（というかノータッチで）動きます。
さて、どう実装するのが正解なのでしょうか。
困りました。
Posted on 2014年1月23日(木) 00:02
Windowsでマイネットワークを開くと近くのコンピュータが自動的に表示されます。
これは単純にブロードキャストしてそれぞれが応答をするのではなく、バックアップブラウザを持っているホストに問い合わせをすることで実現しています。
バックアップブラウザはLAN上のコンピュータが自動的に選定されて、どれかがなります。
OSのバージョンによって優先度が決まっていたりしますが、問い合わせるだけなのでその部分はあまり気にしないことにします。
さて、これを実装しようとすると結構面倒で、
１．バックアップブラウザの検索
２．バックアップブラウザからブラウザリスト（ホスト一覧）の取得
と２段階を踏む必要があります。
１はブロードキャストで問い合わせ(GetBackup Request)をすると、バックアップブラウザが応答(GetBackup Response)を返してくれます。
ここで一つ重大な問題があります。
問い合わせは当然ながらIPで行っているわけですが、元はNetBIOSのため、バックアップブラウザが自分に対して応答を返すときに、名前解決を要求してきます。
よってNBNSの問い合わせに応答できるように実装しておかなければなりません。
（IPで送ってるんだからそのアドレスに返してよ・・と思いますがそうはなっていません）
これは本来であればOSの機能なので、アプリで実装してしまうと、他のアプリと同時にポートをBINDしたときに問題が起こりそうですね。
次に２ですが、これはSMBと同じです。
しかし、ダイレクトホスティング（ポート445番）では挙動が不安定でした(Windows7で確認)。
ちゃんとNetBIOSセッションサービスを利用すると安定して取得できます。謎です。
さて、この方法ですと、ワークグループ名の指定が必要です。
また何かしらの理由でバックアップブラウザが存在しないとホスト一覧を取得できません。
以下は禁じ手だと思うのですが、GoodReaderの実装がそうなっていたので紹介しておきます。
確実な方法ですが、ポートスキャンがちょっと攻撃っぽいので今のところComicGlassでは非採用にしました。
１．ネットワークのサブネットマスクからネットワークアドレスとホストアドレスを分離します。
２．全てのホストアドレスのTCP/445番ポートに対して接続を試みます。（つまりポートスキャン）
３．接続できたら、セッションセットアップの途中までやります。途中というのは相手のホスト名が判明するところまでです。（認証の途中）
４．ホスト名（NetBIOS名）が取得できたら切断しちゃいます。
とりあえず上記の方法であればブラウジング機能に頼らずホストを検出できます。ただし同じサブネットの中のみ。
（ポートスキャンしているから当然といえば当然ですが・・・）
Posted on 2014年1月21日(火) 22:36
今回はただの愚痴ですが・・・。
SMB/CIFSの仕様をみると、データの途中にいきなり可変長データが入っていたりします。
さらにpaddingがいたるところに出てきます。
また、変数は存在するものの、実際のところどういう値にしていいのか、定数としてどんなものがあるのかわからないことが多々あります。
そんなときはプロトコルアナライザです。
WindowsServer系ならばリソースキットで利用できますが、WireSharkなんかも便利です。
そして、絶対あったほうが良いもの・・。
それはポートミラーリング、またはポートモニタリング機能がついたスイッチングハブです。
完全なリピータハブがあればそれでもいいですが、おそらく10BASE-Tの時代のものしか無いと思うので・・・。
数年前までは何万円もしましたが、今では1万円を切る商品もあるみたいです。
Posted on 2013年12月19日(木) 00:56
Windowsで使われる、NetBIOSまわりを頑張ってみます。
やりたいことは、Windowsコンピュータ名(NETBIOS名）からIPアドレスを取得することです。
NetBIOSはとにかく不可解です。
本当に不可解なんですが、歴史的背景があるので仕方がありません。
どのくらい古いかというと1980年代くらいなので仕様書もイマイチ読みづらく、後の改変も多数あるので本当にわかりづりです。
まずNetBIOSはTCP/IPとは別物です。
現在ではプロトコル部分をNetBEUI、インターフェイス部分をNetBIOSと呼ぶようですが、元はインターフェイス（API)からプロトコルまですべてひっくるめた規格でした。
NetBEUIは現在では使われることは無くなりましたが、NetBIOSのインターフェイスだけは利用され続けているというわけです。
NetBIOSをTCP/IPで利用できるようにしたものがNetBIOS over TCP/IPです。（TCP/IPとか言いながらUDP/IPも多用します）
これ時代もWindows3.x時代のものなので何かと理解しづらいです。
さて、関係ありそうな、NetBIOS over TCP (NBT) Extensions NetBIOS over TCP (NBT) Extensions[MS-NBTE]をまず見てみると
名前解決についてはRFC1002を見るように書いてあります。
RFC1002の内容は「NetBIOS-over-TCP」となっています。
日付は March 1987・・・。
読んでみると・・・なんか意味不明・・ですががんばって読む。
とりあえずパケットのフォーマットはこう
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID | OPCODE | NM_FLAGS | RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QDCOUNT | ANCOUNT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSCOUNT | ARCOUNT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
で、名前解決のリクエストはこういう固定値を入れる
4.2.12. NAME QUERY REQUEST
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |0| 0x0 |0|0|1|0|0 0|B| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ QUESTION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bはブロードキャストフラグなので、1で固定みたいです。
なのでフラグ部分は0x0110。
QUESTION_NAMEの部分はRFC 883を使ってコード化しろって書いてます！
これがまだ何故？？というやり方で頭に？？？浮かびっぱなしです。
とりあえずNETBIOS名は15文字です。本来は16文字でしたが、最後の１バイトを別の用途に割り当てたため15文字。
15文字に満たない場合はスペース(0x20）で埋めます。
16文字目はサフィックスで種別を表すのですが、
0x00だとワークステーション サービス
0x20だとファイル サーバー サービス
0x1bだとドメイン マスタ ブラウザ
・・・などなどを表すようですが、、
これはもともとのLAN Managerの仕様ではなくMicrosoftの拡張仕様です。
どうやら0x00はクライアント、0x20がサーバサービスを示すようなのでここでは0x20が正解だと思われます。（実際にはどちらも名前登録されていて、反応もしてくれるので良いのですが）
で、肝心のNETBIOS名の格納方法です。
最初の１バイトは0x20を指定します。0x20=長さが32byteの意味で、NETBIOS名の場合は32byte固定と書いてあるので必ず0x20を指定。
NEBIOS名＋サフィックスの16byteを以下の手順で符号化して32Byteにします。
最後にNULL(0x00）くっつけるので、長さを表す先頭の0x20と合わせて34byteになります。
これがQUESTION_NAMEになります。
NETBIOS名の符号化は、
まず文字コードを4バイト単位にわけます。
空白文字(0x20)であれば0x2と0x0です。
0x0をA、0x1をB、0x2をC・・・という感じで文字を割り当てます。
0x20であれば「CA」になります。
つまりNETBIOS名が「FRED」であれば「EGFCEFEECACACACACACACACACACACACA」になります。
さて、これをUDPでブロードキャストすれば該当ホストがレスポンスを返してくれます。
iOSで1024番以下のポートをbindできるのか？とちょっと不安でしたが、やってみたら大丈夫でした。
レスポンスの内容は以下のとおり
4.2.13. POSITIVE NAME QUERY RESPONSE
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID |1| 0x0 |1|T|1|?|0 0|0| 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0000 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ RR_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NB (0x0020) | IN (0x0001) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDLENGTH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ ADDR_ENTRY ARRAY /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TTLより前はリクエストと同じ。
ADDR_ENTRY ARRAYにIPアドレスが入ります。
（複数ある場合は複数入ります。パケットの送信アドレスを見るか、自分のネットワークマスクと較べてどれを利用するか決めます）
実際には名前の解放パケットとかも飛んでくるようですが（それを見てキャッシュから削除する）、iOSでそれを監視し続けるのは非現実的なので無視します。
なお、IPv6の場合はLLMNR（Link-Local Multicast Name Resolution）を使う必要があります。
今回はIPv4だけでいいのでそっちはやりません。
（そのくらいの知識がある人はIPアドレスでわかるでしょうし・・・）
さて、これでコンピュータ名（NETBIOS名）を解決できるようになりました。
まぁ、なったところでどう使うかは悩ましいところなんですけどね。
Posted on 2013年12月13日(金) 02:23
Windows関連情報は運用を目的にしたものが多く、コーディング例はあんまり聞かないのでメモ的に書いておきます。
SMBの認証にはLM認証、NTLMv1認証、NTLMv2認証、Kerberos認証のいずれかを使います。
Kerberos認証は鍵交換でActiveDirectly環境想定のものなので除外。
LM認証はNTLMv1認証はだいぶ古いにもかかわらずつい最近まで使われていましたがWindows7からはデフォルト無効になっているようなのでこちらも使わない方針で行きます。
ようするに面倒なのでNTLMv2だけ対応します。
あと、まず非対応ということはあり得ないので、Unicodeだけ対応します。
さて、NTLMは「NT LAN Manager Authentication Protocol」のことらしいです。
Microsoftの仕様書名は[MS-NLMP]です。
基本的には認証情報をバイト列に並べているだけなので仕様書を読みながら実装すればなんとか出来ます。
SMB/CIFSがアライメントやら謎のpaddingやらとても実装しにくいのに比べると可変長データをpayloadにまとめているので少しだけ気楽です。
クライアント側で生成する必要があるのは、NEGOTIATE_MESSAGEとAUTHENTICATE_MESSAGEです。
前者は本当に必要な情報を連結してバイト列にしているだけなので楽勝。それでも実際実装してみると一発ではなかなか思い通りにならないのですが・・・。
後者のAUTHENTICATE_MESSAGEもほとんど同じですが、NEGOTIATE_MESSAGEに対してサーバから返されたCHALLENGE_MESSAGEに含まれる情報を使ってチャレンジレスポンスを計算する必要があります。
それがNTLMv2なわけですね。
AUTHENTICATE_MESSAGEのうち、計算が必要なのはNTLMv2 Responseというフィールドです。
といっても、使うのはmd4とmd5だけなんですね。
試行錯誤の結果正しい結果を出せるようになったのでメモ。
入力
・ドメイン（大文字のみ,UTF16LittileEndian）
・ユーザ名（大文字のみ,UTF16LittileEndian）
・パスワード(UTF16LittileEndian)
※ドメインとユーザー名は全て大文字に変換しておく
※文字列のNULLターミネーションは不要（含めない）
サーバから（CHALLENGE_MESSAGEの内容）
・Server challenge (8byte)
・TargetInfo (可変長)
（クライアント側で）生成するもの
・タイムスタンプ（8byte）
・Client challenge (8byte乱数)
１．パスワードのmd4ハッシュを求める
２．ユーザ名とドメイン名を連結する（例：「user」＋[Domain]→「USERDOMAIN」 ）
※ここを先入観でDOMAIN+USERの順番だと思い込んでハマりました・・・
３．２に対して、１を鍵として、hmac_md5を計算する
４．以下を連結する（これをblobと言うらしい）
署名(固定値＝0x01010000）
4byteの予約領域その１（0x00000000）
タイムスタンプ(8byte)
Client challenge(8byte)
4byteの予約領域その２（0x00000000）
TargetInfo
4byteの予約領域その３（0x00000000）
５．Server challengeと４を連結する
６．５に対して、３を鍵として、hmac_md5を計算する
７．６と４を連結する
７で出来たものがNTLMv2レスポンスになります。
ややこしいですね。
MD4はRFC 1320
MD5はRFC 1321
HMACは RFC 2104に規定されています。
なお、それぞれC言語コードが附属しています。
たいして計算量も無いので最適化も不要でしょうから、そのまま使ってもOKかと思います。ただしライセンス表記が必要です。
探せばそのあたりをクリアしたコードも見つかります。
（僕はmd4はそのまま使いました。md5は以前準備したコードがあったのでそっちを利用）
基本的に、SMBと同じく全てリトルエンディアンが使われます。
普通ネットワークバイトオーダーと言えばビッグエンディアンなんですけどね。
最初はエンディアン気にしてコード書いてましたが、どうせiPhoneもリトルエンディアンだし途中から面倒になってリトルエンディアン環境想定で作りました。
さて、これでSMBサーバと認証ができるようになりました。
次回はWindowsファイル共有に使うNETBIOS名（ホスト名）をNetBIOS over TCP/IPを使って名前解決（IPアドレスを取得する）をやってみたいと思います。
まぁ、IPアドレスでアクセスすれば良いので不要な気もしますが。。
欲を言えばBROWSERプロトコルを使ってネットワーク上のNETBIOSホスト名を自動収集したいところですが、、まぁNASとかはBonjourに対応してるから不要な気もします。
2015-05-18 修正 challengeのスペルが違うというお恥ずかしいミスがありましたのでこっそり修正。