NICのMACアドレスを読み出すには？
解決MACアドレスを読み出す方法は過去ログから解ったのですが
APIで取得する方法ではレジストリを触って偽装された場合は
偽装された値を返すようなので、実際に装着されている NICの
MACアドレスを読み出したいのですが方法がわかりません
ヒントでも結構ですので方法をご存じの方がおられましたら
情報をお願いします。m(__)m
こことか。
ttp://www.kt.rim.or.jp/~ksk/wskfaq-ja/advanced.html
なーなーしー さん
有用な情報ありがとうございます。
紹介していただいたページで説明されている方法を試してみましたが
どの方法も NICの MACアドレスを読み出している訳ではなく
MACが偽装されている場合はそちらのアドレスが表示されました。
かなり難易度が高いようです・・・
調べてもそれっぽい情報がないのですが
ひょっとしてこの問題を解決するには NICのデバイスドライバと
会話しなければならないレベルになるでしょうか？
であれば、ちょっとレベルを下げてMACを偽装しているか
していないかだけを検出する方法はないでしょうか？
http://support.microsoft.com/kb/118623
これで一応取れましたが・・・
もしかしてＶＰＮ環境で、仮想ＮＩＣ入っているから・・・
とか言う話ですか？
ＶＰＮ環境が無いので、確認はできません。
以上。
オショウさん コメントありがとうございます。
紹介いただいたマイクロソフトのサンプルを試しましたが
やはりその方法ですと偽装には対応できません
ＶＰＮとかではなくあるソフトの認証に MACアドレスを
使っているのですが偽装されると破られてしまうため
NICの ROMに書かれているMACアドレスを直に読みたいのです。
ただ、MACアドレスを偽装してもデバイスマネージャで削除し
てから再度PnPで認識させると本来のアドレスに戻る事は確
認していますのでデバイスドライバ関連で調査していますが
糸口が見つからない状況です。
頑張って、仮にNIC自体のMACが読み出せたとしても、
そのNICのMAC自体を変更できる製品や、変更する手段等も現実にはあるわけですが、
「そんなことは知ってるが、それでも、
お手軽な方法を潰すだけでも一定の効果は期待できるはず」
という算段だということでよろしいでしょうか。
もしもこれが許容できないようなソフトなのであれば、MACだけにこだわるよりも、
他の手段との複合や前提条件などから再検討を促した方が幸せな気もしますが。
Banさん こんばんは
コメントありがとうございます。
>頑張って、仮にNIC自体のMACが読み出せたとしても、
>そのNICのMAC自体を変更できる製品や、変更する手段等も現実にはあるわけですが、
>「そんなことは知ってるが、それでも、
> お手軽な方法を潰すだけでも一定の効果は期待できるはず」
>という算段だということでよろしいでしょうか。
おっしゃる通りです。
ハードウェアレベルでMACを変更できるNICが現実に存在することは
認識しています。
その場合は許容せざるを得ないと考えているのですが、 レジスト
リを書き換える MAC偽装ツールに対しては耐性を持たせたいと思っ
ています。
であれば、NetworkAddressと言う定義がレジストリにあれば
偽装している・・・と決めてもよいのでは。
ＨＤＤのシリアルを認証キーにする方法もありますが・・・
こちらはそうそう書き換えできないようなので。
以上。
オショウさん こんばんは
重ね重ねコメントありがとうございます。
手元の偽装ツールで MACを詐称しても NetworkAddressと言う
エントリはできませんでした。ツールによるのでしょうか・・
HDDも考えたのですが最も壊れやすい部品ですから客の理解が
得られないと判断しています。
それと NICにするのは USB-NICですとマシンの変更が可能と
言うのもあり客の利便性をある程度考えた結果なのです。
やはり、直に NICの ROMにアクセスする必要がありそうです(・・);
一応確認・・・
HKEY_LOCAL_MACHINEの
\SYSTEM\CurrentControlSet\Control\Class
\{4D36E972-E325-11CE-BFC1-08002BE10318}
の下に4ケタの数字の数字のキーグループがありますが
その中に実際のＮＩＣのキーがあって、その下に該当
のNetworkAddressと言う文字列キーがあるかないか。
ＮＩＣのデバイスドライバーの仕様では、そこにできる
のですが、偽装ツールとなると、ドライバー側も仕様を
逸脱してどこかに保存しますので、使えない？？？
英語圏のサイトで、DeviceIoControlでドライバーと直接
やり取りしてＭＡＣアドレスを取得するコードが掲載さ
れているのを発見していますが・・・
VC++で実行できるコードを見つけていないので、後はご
自身で探すなり、チャレンジしてみて下さい。
※ 私は、ＵＳＢタイプのドングルで認証するソフトを
製作していましたので、その折、ＮＩＣのＭＡＣや
らＨＤＤシリアルやらＣＰＵＩＤやらいろいろ調査
して結局ＵＳＢドングルになったものですから。
以上。
あまりスマートな方法じゃないですが、
ipconfig /all
をリダイレクトすると、正しいMACアドレスが出てくるとか無いですか？
通信相手から見たときのMACアドレスはホンモノですか？
自分自身にarp投げてみるとかどうでしょう？
オショウさん
> 一応確認・・・
> HKEY_LOCAL_MACHINEの
> \SYSTEM\CurrentControlSet\Control\Class
> \{4D36E972-E325-11CE-BFC1-08002BE10318}
> の下に4ケタの数字の数字のキーグループがありますが
> その中に実際のＮＩＣのキーがあって、その下に該当
> のNetworkAddressと言う文字列キーがあるかないか。
今日は会社なのですが、会社のＰＣでは偽装してなくても
NetworkAddressと言う文字列キーがありました。
しかし、不思議なのはこのあたりを検索しても本来の MACアド
レスはどこにも格納されていないようです。# 暗号化されている？
ということは逆に考えると偽装すると MACアドレスがこのあたり
に作成されるのでしょうか・・・・？
だからオショウさんは NetworkAddressと言う文字列キーがあるか
ないかを偽装判断のひとつにしたらどうかとアドバイスしてくだ
さったわけですね m(__)m
> ＮＩＣのデバイスドライバーの仕様では、そこにできる
> のですが、偽装ツールとなると、ドライバー側も仕様を
> 逸脱してどこかに保存しますので、使えない？？？
> VC++で実行できるコードを見つけていないので、後はご
> 自身で探すなり、チャレンジしてみて下さい。
ありがとうございます。自分のスキルでははかなり厳しそうです。
それと、下手すると偽装していないお客さんの環境で偽装している
なんて誤動作したら大問題なので MACだけでなくホスト名なども含
めようかと逃げを考え始めています。根性なくてすみません Orz
> ※ 私は、ＵＳＢタイプのドングルで認証するソフトを
> 製作していましたので、その折、ＮＩＣのＭＡＣや
> らＨＤＤシリアルやらＣＰＵＩＤやらいろいろ調査
> して結局ＵＳＢドングルになったものですから。
HASPのようなソリューションでしょうか？
なーなーしー さん
> ipconfig /all
> をリダイレクトすると、正しいMACアドレスが出てくるとか無いですか？
残念ながら ipconfig /all では偽装された MACがしっかり表示されます。
通行人さん
> 通信相手から見たときのMACアドレスはホンモノですか？
> 自分自身にarp投げてみるとかどうでしょう？
他のＰＣから MACを偽装されたＰＣに向けて ping 打って
arp -A とすると 偽装されたMACが表示されます。
非常に厄介です。
「偽装」ってのは簡単に見破られないからこその偽装なのであって、
今のバージョンの偽装ソフトを見破る手段を見つけても、
次のバージョンではもっと巧妙に偽装されて見破れなくなる・・・
というあたりを考えると見破り側の開発コストが合わないと思う。
俺としてはＵＳＢドングルを推奨。専用ハードでなくても、
市販の任意のＵＳＢメモリを使えば良いのでは？
VID/PID/ProductID の３つ組は世界に唯一とされているわけで。
というよりそもそもくだらない認証などヤメヤメ！
正しく使ってくれるユーザは認証無くても正しく使うし
悪意有るユーザはデバッガで解析してでも認証を回避するし。
tetrapod さん
> 「偽装」ってのは簡単に見破られないからこその偽装なのであって、
> 今のバージョンの偽装ソフトを見破る手段を見つけても、
> 次のバージョンではもっと巧妙に偽装されて見破れなくなる・・・
> というあたりを考えると見破り側の開発コストが合わないと思う。
ごもっともだと思います。
このために費やしてきた時間がバカバカしいと自分でも思っています。
ちょっと悔しいですが現状レベルでリリースすることにします。
貴重な時間を割いてアドバイスくださったみなさん
ありがとうございました。 感謝いたします。m(__)m
別にそんな無いと思うよ。tetrapodさんの言うことは理想だけど、現実の仕事では全て理想どおり行くわけでもないし、出来る限りのプロテクトを入れとくのは十分意味あると思う。
特にアプリのユーザーが少ない場合はクラックされる可能性もそんなに高くないしね（ユーザーが経理のおじちゃん・おばちゃんなら、まずクラックなんてされない）。
>別にそんなこと無いと思うよ。
現状レベルリリースっつことは
・MAC アドレスプロテクト対応
・このプロテクトは MAC アドレス偽装されると解除されうる
ということだと思う。プロテクトせずに出しますとは書かれていない。
コスト的に適切な落としどころになったのでは？
俺は認証などくだらないと思うし、破られたときに是正するのがめんどうだし
ユーザーからの「認証失敗で起動しない、どうなっとるんぢゃゴルァ」という
問い合わせに時間を割くのが超つまらないと思うので
俺ソフトに認証機能を組み込むつもりは毛頭ない。
でも他人が自分のソフトに組み込むのは勝手だと思っている（否定はしない）
認証のための代案も出しておいたしさ
なーなーしー さん
>別にそんな無いと思うよ。tetrapodさんの言うことは理想だけど、現実の仕事では全て理想どおり行くわけでもないし、出来る限りのプロテクトを入れとくのは十分意味あると思う。
「出来る限り」のレベルをどこに設定するかが悩ましい
問題ですが偽装対策のために必要な時間と誤動作による
クレームが大きなリスクと感じています。
NICの ROM上にある MACを読み出すのは今後の課題として
時間があるときに挑戦してみたいと思います。
とりあえず マイクロソフトのページから DDKを落としま
したが気が遠くなりそうです（ｗ
ありがとうございました。
tetrapodさん
> コスト的に適切な落としどころになったのでは？
おっしゃるとおりです。MACアドレスに関する技術的な問題は
解決できませんでしたが自分なりに妥協点を見出せました。
ありがとうございました。
解決となってますが・・・
問いに答えておきます。
> ということは逆に考えると偽装すると MACアドレスがこのあたり
> に作成されるのでしょうか・・・・？
> だからオショウさんは NetworkAddressと言う文字列キーがあるか
> ないかを偽装判断のひとつにしたらどうかとアドバイスしてくだ
> さったわけですね m(__)m
デバドラ作れる技術や経験あれば、そう疑問にならないのですが
ボード上の隠しエリアに保存するとか、本来のMACアドレスは、
そこに保存してあるとか・・・
礼儀正しい？ボード・ドライバーの場合は、MACを変更すれば、
NetworkAddressキーに保存する・・・無ければ隠しエリアから
読み出して返す。とか・・・
> ありがとうございます。自分のスキルでははかなり厳しそうです。
> それと、下手すると偽装していないお客さんの環境で偽装している
> なんて誤動作したら大問題なので MACだけでなくホスト名なども含
> めようかと逃げを考え始めています。根性なくてすみません Orz
安全対策は必要かと。
またデータの二重化とか、片方が欠損したらバックアップでとか。
> HASPのようなソリューションでしょうか？
技研商事が販売するレインボー社のセンチネルとか、アラジンの
HASPとか、十条電子の・・・まだまだあります。
※ 顧客の要望で、プロテクトかけるソフトを数年製作していた
時期がありましたので、その辺は詳しい？方です。
● MACアドレス変更すれば、DHCPの場合、アドレスが変更されます。
固定ＩＰの場合は、ARPスプーフィングがあったかのように検知
できるはずです。
ソリューションとして見た場合、ネットワーク上に監視ＰＣを
設置すれば、偽装発見は容易いです。
シェアウェアでそういうものを監視するソフト出ています。
私も購入して実際に稼動させ監視ワークしました。
※ 社内の悪意のある社員を管理する為・・・
どんな会社や〜・・・
参考までに。
以上。
一応、結果報告
http://cc.codegear.com/Item/21010
ここのC++Builderのコードで、MACアドレスの
オリジナルと偽装、両方取れました。
CreateFile
DeviceIoControl
CloseFile
を使ってますが、ネットワークカードのデバイス名は
レジストリから取っています。
また、情報自体は・・・
OID_802_3_PERMANENT_ADDRESS ＜＝ オリジナル
OID_802_3_CURRENT_ADDRESS ＜＝ 変更後（現在）
から得ています。
100%確実かは、搭載されるボードとドライバーに依存
しますので・・・
敢えて言うならば、フラッグシップメーカのなら問題
なく取れました！（変更後も！）
以上。
オショウさん
わたしも紹介して頂いたサイトからプロジェクトを落としてみました。
ただ、C++ Builderを持っていないので実行ファイルは作れないのですが
デバイスドライバとレジストリが解らないと手も足も出ない雰囲気が
ヒシヒシと伝わってくるソースですね
そして、このサイトを見て初めて知ったのですが ボーランドは
C++ Builderを始めコンパイラ製品を売却しちゃったんですね
その昔 Turbo-Cからこの世界に入った私にとってはちょっと複雑
な思いがしました。
あ、雑談モードになってしまいました（ｗ
オショウさん 貴重な情報をありがとうございました。
#それにしてもこのBBS以前と比べてちょっと閑散としているように
#感じますがみなさんどちらへ行かれたのでしょうか？？
TurboC++ 2006 は、フリーでダウンロードできます。
その該当プロジェクトもTurboC++で読み込めますので
コンパイルしなおして実行できました。
http://www.turboexplorer.com/jp/downloads
※ 若干のコメントアウトはしましたが・・・
尚、TurboC++のダウンロードは、上記ＵＲＬの内容
を熟読して行って下さい。
VCソースを掲載しているところもあるようですが、
ＵＲＬは見失ってしまったもので・・・
尚、JAVAやPASCALで作ったのもありました。
● レジストリから読み込んでいるのは、現在、
アクティブになっているネットワークカード
のデバイス名を取得させています。
複数のカードがアクティブの場合は、最初の
１枚目からしかＭＡＣアドレス取得を行う事
ができませんので、プログラムの変更が必要
です。
デバイス名が解れば、CreateFileでオープン
して、そのハンドルを使ってDeviceIoControl
を実行してほしいＭＡＣアドレス情報を取得
します。
そんなに難しいことではありません。
.NETに移植して同じ動作をするものを作るの
に１時間とかかりませんでしたので、大丈夫
ですヨ！
以上。
オショウさん
重ね重ね貴重な情報をありがとうございます。
> そんなに難しいことではありません。
> .NETに移植して同じ動作をするものを作るの
> に１時間とかかりませんでしたので、大丈夫
> ですヨ！
>
.NETの波がものすごい勢いで押し寄せていますね
C#も気になる今日この頃です。（ｗ
散々探し回ってこのページに辿りつきました
「英語圏」という貴重なヒントがありましたので「イギリス」方面のページをさがしましたＡＰＩとかを使うと言うページがあるようです。頑張ってください
英国googleで調べてみました
http://www.nevaobject.com/phpBB3/viewtopic.php?t=67
ここに詐称対策の処理譜(ソースコード)例があります。
http://www.perlmonks.org/?node_id=639048
こちらはｃ言語で記述した詐称対策の処理譜(ソースコード)例があります。
要点は
GetAdaptersInfo API. はレジストを基にした値を返すのでこれを使うと詐称される
DeviceIoControl API を使って直に周辺機器(Peripheral)に問合せすると詐称が破れるようです。
もう少し研究します。
やっとのことでハンドルを取得することができました
(此処までで１０日位かかりました
-なんせアダプターの名前を取り出すのにも随分かかりました)
いよいよ次はＭＡＣ ＡＤＤＲＥＳＳです--以上進捗報告です
やばい! DeviceIoControlはMacAddress問合せにはOidをポインターで送る仕様になっているが、tcl/tkからはポインターを渡す手立てが見付らない。
TwapiとFfidleのファイルを隅から隅まで眺めたけどポインターで渡す方法はどこへやら。めげそう!
| ツイート |  |