DHCP Client emulieren

    Hallo zusammen,
    Ich wollte mal fragen ob es möglich ist mit AutoIt einen DHCP Clienten zu emulieren.
    Die SuFu habe ich schon benutzt.
    Habe es vorhin schon mal versucht, kriege aber vom Server nur eine unverständliche Antwort die sich
    mit StringToBinary nicht entschlüsseln lässt.
    Hier mein Script:

    Spoiler anzeigen
    [autoit]


    UDPStartup()
    $open = UDPOpen("255.255.255.255",67)
    $socket = UDPBind("0.0.0.0",68)
    UDPSend($open,"DHCPDISCOVER")
    Do
    $recv = UDPRecv($socket,1024^2)
    Until $recv <> ""
    MsgBox(0,"",$recv)
    UDPShutdown()

    [/autoit]


    Ausgabe ist manchmal in Binär-Form(also 0x0090u0870 etc.) oder gar keine.

    MfG Jonas

    Einmal editiert, zuletzt von Jonas Houben (9. August 2013 um 22:40)

    Soweit verstanden,
    Aber muss man die gesendeten Daten dann auch irgendwie kodieren?
    Leider gibt es in dem RFC keine eindeutige Syntax, so wie "DHCPDISCOVER [param1] [param2]" oder so.
    Nur gaannnzz viel Text :(
    Kann man so etwas in der Art irgendwo finden?

    MfG Jonas

    Klar müssen deine Nachrichten auch kodiert werden, es handelt sich schließlich um ein fixes Protokoll. Der Aufbau (Syntax) von den verschiedenen DHCP Paketen ist unter anderem im englischen Wikipedia Artikel dokumentiert:

    http://en.wikipedia.org/wiki/Dynamic_H…ration_Protocol

    In meinem Scriptteil beschränke ich mich wenn ich mich recht erinnere darauf alles nach dem "Magic Cookie" auszulesen, diese dort enthaltenen "Options" sind hier bzw. in den jeweiligen RFC dokumentiert:

    http://www.networksorcery.com/enp/protocol/bootp/options.htm

    Es ist jedenfalls nichts was man in ein paar Stunden programmiert hat und es erfordert auch sehr viel Einarbeitungszeit.


    Die Frage ist aber wozu du das überhaupt brauchst. Windows beherrscht DHCP schließlich selbst und jeder 0815 Router bietet ebenfalls einen DHCP Server. Wenn es dir darum geht DHCP Traffic im Netzwerk zu analysieren bieten sich professionelle Networksniffer an, wie z.B. Wireshark. Auch für die Anwendungsfälle DHCP Requests abzufangen und zuerst zu beantworten (DHCP Rogue Server) oder das Netzwerk mit DHCP Requests zu fluten (DHCP Starvation Attack) gibts genügend "Hacker Software", sowas gehört hier aber ohnehin nicht her, siehe Forenregeln. Cisco ist im übrigen so nett in ihrem Lehrmaterial einige dieser speziellen Tools zu nennen.

    Wie dem auch sei mir wäre es jedenfalls zuviel Arbeit das komplette Protokoll auseinanderzunehmen und zu verstehen.


    EDIT:
    Im englischen Wiki Artikel ist im übrigen auch ein Screenshot eines Software DHCP Servers für Windows zu finden: http://www.vercot.com/~serva/default.html
    Vielleicht tuts das ja für deine Zwecke auch.

    Einmal editiert, zuletzt von misterspeed (10. August 2013 um 22:15)

    Es geht mir einfach darum zu versuchen mit AutoIt einen einfachen DHCP Client zu emulieren.
    Was ich noch nicht ganz verstehe wie man jetzt Daten abschickt.
    Muss man die 0x003 und so hintereinander hängen?

    MfG Jonas

    Ähm ja? Hast du dir mein Script angesehen? Dort wird in der Console das empfangene DHCP Paket eines beliebigen Netzwerk Gerätes ausgegeben, sobald dieses sich mit dem Netzwerk verbindet. Genau sowas muss dein Client auch verschicken, damit er vom Server eine Antwort bzw. IP zugewiesen bekommt.

    Hier mal ein Beispiel:

    Code
    0x01010600066C37B2000000000000000000000000000000000000000010683F364BDE00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000638253633501033D070110683F364BDE3204C0A80116390205DC3C0C6468637063642D352E352E360C18616E64726F69642D616366356561383563633364313136653709012103060F1C333A3BFF

    Dieses Paket wurde von meinem Script empfangen als ich mein Android Smartphone mit dem WLAN verbunden habe.

    Wenn wir die Nachricht nun wie im englischen wiki Artikel beschrieben zerlegen erhalten wir alle Einzelbestandteile der Nachricht, das schaut dann so aus:

    Was das alles bedeutet sollte im Wiki Artikel erklärt werden, bzw. in den dort erwähnten weiterführenden Links. Gegen Ende der Nachricht findet sich immer ein Magic Cookie (63825363). Ab hier folgen dann die DHCP Options (Die eigentliche Nachricht des Clients... was will der client vom server?). Mein Script zerlegt diesen langen Options HEX String zuerst in Sätze anhand der Längenangaben, welche immer im 2. Octet stehen. Danach werden die Sätze einzeln ausgewertet und die enthaltenen Daten in lesbare Strings oder Dezimal Zahlen umgewandelt:

    Um die Options in lesbare Form zu bringen muss man wissen in welchem Format jede Option beschrieben ist, das ist meinem Link bezüglich der Options und zugehörigen RFC zu entnehmen und keinesfalls für alle identisch, also eine heiden Arbeit das alles zu supporten, daher habe ich mich in meiner SWITCH...CASE Abfrage auf die wenigen Options beschränkt welche meine Geräte tatsächlich versenden. Die nicht unterstützen Options werden nicht näher analysiert.

    Fangen wir mal mit Satz 1 der Options an:

    Code
    35 01 03

    35 in Hex entspricht Dezimal ausgedrückt der Zahl 53 und steht für die Art der Option, diese kann man hier nachschlagen: http://www.networksorcery.com/enp/protocol/bootp/options.htm

    Code
    53	1	DHCP message type.	RFC 1533, RFC 2132, RFC 3203, RFC 4388

    Es handelt sich also um die Option "DHCP message type", welche immer 1 Octet lang ist (manche Optionen haben auch variable Längen). Das 2. Octet eines Satzes gibt die Länge aber immer an (wichtig bei variabler Länge), in unserem Fall "01", was dezimal einer 1 entspricht und sich mit der Beschreibung auf der genannten Webseite deckt. Das 3. Octet des Satzes sind dann die Daten, in unserem fall "03". Was bedeutet diese "03" nun? Dazu müssen wir die genaue Beschreibung im RFC Dokument nachschlagen:

    Wenn wir im RFC 1533 nach "DHCP Message Type" suchen landen wir hier

    Die "03" steht also für "DHCPREQUEST".

    Genau nach diesem Schema verfahren wir für alle Sätze und haben letzlich die Übersetzung (siehe oben). Wenn du nun ernsthaft immernoch einen DHCP Client programmieren willst wünsche ich viel Spaß beim Studium der RFC Dokumente, prinzipiell musst du "nur" den umgekehrten Weg gehen und das was du verschicken willst nach obigem Schema kodieren. Ein Client muss aber natürlich immer auch die Antworten verstehen, du brauchst also auch all das was ich zum Teil schon in meinem Script mache und hier gerade sehr ausführlich erläutert habe.

    4 Mal editiert, zuletzt von misterspeed (12. August 2013 um 13:42)

    misterspeed,
    sehr schön erklärt und auch fein aufbereitet! :thumbup:
    Das auseinanderfrickeln von derart komplizierten Protokollen ist schon eine Heidenarbeit für sich, bei unbekannten Protokollen bzw. Formaten kommt noch das Testen und Reingeneering dazu 8o , das tu ich mir aber heutzutage nur noch bei einfachen Sachen an^^

    Allerdings beobachte ich den Thread seit dessen Erstellung :rolleyes:
    Der TE hat ein Problem, welches er nicht mal ansatzweise äussert. Es ist immer noch nicht klar, wieso und weshalb überhaupt WAS gemacht werden soll....
    Und wenn ich dann lese

    Zitat

    Leider gibt es in dem RFC keine eindeutige Syntax, so wie "DHCPDISCOVER [param1] [param2]" oder so.
    Nur gaannnzz viel Text
    Kann man so etwas in der Art irgendwo finden?

    ist mir schon klar, dass wieder mal "der Arm aus der Sonne gelegt" werden soll.
    Die RFC zum Thema listen definitiv alles auf, was an Informationen benötigt wird. Wieso findest DU die Informationen in dem "gaaaanzzz viel Text", der TE aber nicht? Wieso kannst du Scripte zur Verdeutlichung erstellen, der TE aber nicht?

    Wieder mal ein schönes Beispiel dafür, dass die c&p-Generation nicht in der Lage ist, aus Bergen von Informationen (RFC, Wiki, google) das Gesuchte rauszuziehen :huh:

    Danke. ;)

    Ich hatte es damals aber auch schnell wieder aufgegeben, nachdem mir der Umfang klar wurde, denn in den RFC Dokumenten sind sicher noch sehr viel mehr Informationen zum Protokollablauf und den genauen Aufbauregeln vermerkt. Das alles durchzugehen würde Wochen benötigen, daher Hut ab vor all den Programmieren, die dieses Protokoll in der Vergangenheit vollständig umgesetzt haben.

    Ich habe ebenfalls meine Zweifel, dass der TE dazu in der Lage ist, aber dieser Thread hilft vielleicht auch in Zukunft den groben Aufbau des Protokolls besser zu verstehen und zumindestens Ansatzweise zu analysieren. Hier liegt auch der Unterschied. Im anderen Thread gab es eine klare Aufgabenstellung die mit begrenztem Aufwand lösbar war, hier fehlt soetwas bzw. es soll einfach das komplette Protokoll unterstützt werden. Das ist schlichtweg nicht machbar ohne "gaaaanzzz viel Text" zu lesen und zu verstehen.

    Davon ab fallen mir aber auch keine wirklichen Anwendungszwecke für einen eigenen DHCP Client/Server ein, außer die am Rande erwähnten Angriffsszenarien auf bestehende Netzwerke.