パケットをしばらく傍受してから、ヒューリスティックを適用します。これ以降は IPv4 とイーサネットを想定しています。HUB ではなくイーサネット スイッチを使用する場合、これはうまく機能しません。詳しくは最後に。
実際の ARP パケット (ブロードキャストおよびマルチキャストの IP アドレスと MAC アドレスは無視) だけでなく、イーサネット (または何でも) と IP ヘッダーに基づいて、独自の RARP (逆アドレス解決) テーブルを作成します。テーブルが複数の IP アドレスを単一のハードウェア インターフェイスにマップできることを確認してください。実際の ARP パケットによって入力または検証されたテーブル内の IP アドレスには、そのようなフラグが付けられる必要があります。
ゲートウェイは、より多くのトラフィックを送受信する可能性があります。このトラフィックには、多くの異なるネットワークからの多くの IP アドレスが含まれている可能性がありますが、ハードウェア アドレスは同じです。ゲートウェイは、多数の IP アドレスを持つ 1 つの MAC アドレスとしてテーブルに表示されます。この MAC アドレス アドレスに関連する ARP トランザクションを観察している可能性が高いため、seen in ARP packetフラグが設定されている MAC をエイリアスする IP アドレスを探すことができます。これはほぼ確実にゲートウェイの IP アドレスです。
おそらく、ゲートウェイの IP アドレスに基づいてネットワーク アドレスとサブネット マスクを推測できますが、これは信頼できるものではない可能性があります。非標準のネットマスクを使用したネットワークでこれを機能させたい場合は、次のことを試すことができます。2 つの IP アドレス サイズのアキュムレータ変数を作成します。
uint32_t acc_and = 0xFFffFFff;
uint32_t acc_or = 0x00000000;
そして、テーブル内のARP検証済みアドレスごとに、次のことを行います
acc_and &= ip_addr;
acc_or |= ip_addr;
このために、ゲートウェイから来たパケットで宛先 IP アドレス (マルチキャストではない) を使用することもできますが、そのようにフラグを立てる前に、ゲートウェイを知る必要があります。
アドレスのネットワーク部分は (最初の操作の後) 両方で同じままである必要がありますが、下部のビットがいっぱいになり始めるacc_and間、下部のビットがクリアされ始める必要があります。acc_or十分なサンプルがあれば、次の方法でネットワーク アドレスを特定できます。
uint32_t net_addr = acc_and & acc_or;
およびネットマスクは次のとおりです。
uint32_t net_mask = acc_and ^ acc_or;
サンプリングされた十分なローカル IP アドレスを取得するには時間がかかりすぎる可能性があるため、次の方法で絞り込みを開始できます。
uint32_t almost_net_mask = acc_and ^ acc_or;
int i = 0;
while ( 1 & almost_net_mask ) {
i++;
almost_net_mask >>= 1;
}
uint32_t net_mask = 0xFFffFFff;
while( i-- ) {
net_mask <<=1;
}
これにより、最後の 1 ビット セットが見つかります。最下位の 0 ビットは、明らかにアドレスのローカル部分の一部ではありません。または、次の方法でも同じことができますi。
i = ffs( ~ ( acc_and ^ acc_or ) ) ; // assuming that int on your system is 32 bit. if not use ffsl
ネットマスクとネットワークアドレスを本当に確認したい場合は、他のことを試すことができます。ゲートウェイがパケットを転送しようとするかどうかを確認することができます. これは先に進んで自分自身に IP アドレスを割り当てる必要があり、ネットマスクが正しくないと危険です。
範囲外ではない可能性を高めるために、トラフィックが送受信されていない最小の正当な IP アドレスを選択するようにしてください。そのアドレスの ARP 要求をスプーフィングし、応答を探すことができます (独自の実際の MAC アドレスを使用することもできますが、これには IP を作成することもできます。IP である必要はなく、少し混乱する可能性があります)。 . ARP で要求できない IP アドレスを見つけたら、それを自分で要求します。
実際には高すぎる IP アドレスになってしまった可能性があります。ネットマスクはまだ推測にすぎないため、これを確実に知ることは困難です。あなたが生きるための空きスロットがないため、これが当てはまる場合は運が悪い.
ネットマスクを調整する必要があるかどうかを確認するには、ローカル ネットワークには表示されていないが、ネットマスクとネットワーク アドレスの推測に基づいて、ローカル ネットワークにある可能性がある宛先アドレスを持つ IP パケットを送信してみてください。これらの推測が外れている場合、ネットワークアドレスに割り当てられたビットが多すぎるため、(これまでのところ) 最適に推測されたネットワークアドレスのネットマスク部分から下位ビットを変更するアドレスに送信することをお勧めします。IP アドレスを ARP し、誰かが応答するかどうかを確認することで、通常どおりこれらを送信してみることができますが、アドレスを推測していて見逃す可能性があるため、宛先 MAC アドレスをゲートウェイに転送するかどうかを確認します。そうしないように構成されている可能性があります。そのため、最初にネットワークで既に観察したネットワークのメンバーに対してこれを実行し、それが転送されるかどうかを確認してみてください。ゲートウェイがパケットを転送する場合、ネットマスクの考えを信頼して、ネットマスクの考えを絞り込むことができます。ゲートウェイがローカル ネットワークの既知のメンバー宛てのパケットを転送しない場合は、調整する理由ができるまでローカルのネットマスクとネットワークのアイデアを使用し続けるか、その範囲内のアドレスの ARP 要求を送信することができます (これは、あなたの質問に「はい」または「たぶん」のいずれかとしてのみ答え、「いいえ」の可能性はありません）。ゲートウェイがパケットを転送する場合、ネットマスクの考えを信頼して、ネットマスクの考えを絞り込むことができます。ゲートウェイがローカル ネットワークの既知のメンバー宛てのパケットを転送しない場合は、調整する理由ができるまでローカルのネットマスクとネットワークのアイデアを使用し続けるか、その範囲内のアドレスの ARP 要求を送信することができます (これは、あなたの質問に「はい」または「たぶん」のいずれかとしてのみ答え、「いいえ」の可能性はありません）。ゲートウェイがパケットを転送する場合、ネットマスクの考えを信頼して、ネットマスクの考えを絞り込むことができます。ゲートウェイがローカル ネットワークの既知のメンバー宛てのパケットを転送しない場合は、調整する理由ができるまでローカルのネットマスクとネットワークのアイデアを使用し続けるか、その範囲内のアドレスの ARP 要求を送信することができます (これは、あなたの質問に「はい」または「たぶん」のいずれかとしてのみ答え、「いいえ」の可能性はありません）。
イーサネット スイッチを使用している場合、フレームが別の場所に送られる必要があることをスイッチが認識している場合、スイッチはイーサネット フレームを転送せず、フレームが表示されないため、事態はさらに困難になります。ただし、送信者が ARP キャッシュにその IP のエントリをまだ保持しておらず、そのエントリを早期に更新しようとしている場合を除き、これらの ARP 要求はブロードキャストされるため、多くの ARP 要求を転送します (これはすべてのシステムで行われるとは限りません)。これにより、ネットワークとそのメンバーのアイデアを構築するのがはるかに難しくなりますが、まともな仕事をすることができるでしょう. ただし、ゲートウェイに対する ARP 要求の量と、ゲートウェイからの ARP 要求の量が他のシステムよりも多いことに依存して、それを特定する必要があるでしょう。これは、ファイル サーバーが同様のトラフィックを持つ可能性があるため、エラーが発生しやすくなります。
Windowsネットワークでは、IP 0.0.0.0を使用して、ポート67（または68）でUDPソケットを開き、SMBブロードキャストメッセージがIPアドレスを学習するのを待つことができます。そこから、ARPパケットを使用して、そのIPに近いアドレス上のデバイスを検索できます。
ネットワークが255.255.255.0より小さいネットマスクを使用する場合に備えて、元のIP（同一の上位ビット）にできるだけ近い未使用のアドレスを見つけてください。未使用のIPを見つけたら、デバイス用にそれを要求し、GratuitousARPを送信します。
ここでARPスキャンを続行し、応答するデバイスを見つけたら、それを一時的にデフォルトゲートウェイとして設定し、応答するインターネット上のデバイスの既知のIPアドレスにpingを実行してみます。応答があれば、ゲートウェイが見つかりました。
DHCPを使用すると、99％の確率でそこに到達できるので、これは大変な作業です。
実行できますが、簡単な方法ではありません（私の貧弱な知識によると）。さらに分析するソリューション：
スニッフィング ライブラリは、libpcap または winpcap だと思います。
似たようなことをしたことはありませんが、Googleで参照が見つからない場合は、この方法で行くと思います。