Programmiersprache Ethernet/IP/ICMP?

#1
Hey zuasmmen,
vorab danke, dass Du dir die Zeit genommen und meinen Thema angeklickt hast.


Zu meiner Person:

Ich selbst bezeichne mich als Quereinsteiger aus der Fernmelde- und Telekommunikationsbranche und habe kein Studium oder Ausbildung in einem klassischen IT-Beruf genossen.

Die letzten Jahre hat mein Arbeitgeber immer mehr Systeme von PDH/SDH Technik durch Ethernet/IP-Systeme ersetzt.
Daher bin ich heute eher als Netzwerkadministrator tätig und besitze ein meiner Meinung nach mehr als grundlegendes Verständnis der untersten dreieinhalb OSI-Schichten. Von Anwendersupport, Server Virtualisierung, Office Problemen, Betriebssystempflege, Domainverwaltung... bin ich Meilenweit entfernt. Also neben Netzwerkanalyse und Parametrierkenntnissen von optischen/kupfer/mobilfunk-Umsetzern, Routern, Switchen und Firewalls bin ich eigentlich nicht viel besser als der gemeine DAU:D.

Privat habe ich mit der Scriptsprache AutoIT ein paar kleine Nutzerhilfen geschrieben. Daher sind mir einige Programmiergrundlagen bekannt.
Dennoch sind meine Scripte meist mehr zweckorientiert als sauber und strukturiert:rolleyes:.



Meine Anforderung:

Ich bin mit den gängigen Netzwerkanalysetools vertraut doch das reicht mir nicht. Daher suche ich eine Programmiersprache mit der ich möglichst viel Einfluss auf eine Netzwerkkarte oder wahlweise Treiber oder API habe.



Ziel:

Manipulation des Ethernet-Frames/Header & Ethernet-Frames/Header
-dest und src MAC anpassen
-Erzeugung von Broadcasts
-VID ändern
-Rahmenfehler erzeugen
-überlange Pakete
-falsche Prüfsummen (gewollte Bitfehler und ggf. Kollisionen)
-ARP Anfragen mit fehlerhafter
-Nachbildung von LLDP
-jede andere Gemeinheit, die wenn man eben mal dabei ist in den Sinn kommt
-möglichst jedes einzelne Bit verbiegen können​
Nachbildung und Manipulation des ICMP Protokolls
Nachbildung des TCP & UDP Protokolls ist zwar auch Interessant aber nicht mein Hauptaugenmerk. Hierbei währe vor allem eine Nachbildung der Anwendungen Telnet, SSH, DNS und SNMP hilfreich.

Ich bin mir bewusst, dass es das alles schon irgendwo fertig zu finden gibt. Mir geht es in erster Linie nicht die Funktion an sich, sondern theoretische Kenntnisse von RFC's auch mal praktisch nachzustellen.



Die Fragen:
Meine Frage ist nicht wie ich die einzelnen Punkte umsetzen soll, sondern was ich als Grundlage nutzen kann.

Welchen Ansatzpunkt könnt ihr mir empfehlen oder wovon könnt abraten?
-Treiber
-API
-Fertige Bibliothek verwenden​
Welche Programmiersprache empfehlt ihr mir?
Gibt es zu diesem Thema Tutorials oder eine Community?
-Wo sollte ich mich am besten Informieren?​

Wenn ihr mir davon abraten möchtet dann bedenkt bitte, dass die gesteckten Ziele als einzelne Projekte und nicht als eine große Aufgabe gedacht sind.




Nochmal vielen Dank, dass du bis hierher meine Ausführungen gefolgt bist.

mit freundlichen Grüßen
Nurgle
 

Fabolous

Well-Known Member
#2
So wie ich das sehe kommt da nur C/ C++ in Frage, ausgehend von deiner Erfahrung kannst du dann mit Glück in 10 Jahren deinen ersten kleinen Treiber entwickeln. Nicht falsch verstehen, aber Netzwerkprogrammierung an sich ist schon ein ziemlich komplexes Thema, Netzwerktreiber würde ich als das komplexeste überhaupt bezeichnen. Solltest du diese Analyseanforderungen jemals selbstständig mit eigenen Treibern erfüllen können, bräuchtest du keinen Chef mehr und könntest dich über sein Gehalt lustig machen ;).
 

lano

Well-Known Member
c-b Experte
#3
Da würde alles funktionieren was mit raw Sockets umgehen kann.

Wenns nur mal zum probieren von irgendwas sein soll nehme ich perl.
Ansonsten bietet sich c an.

Edit: die Wahl im Bezug auf das Betriebssystem würde ich auf Linux fallen lassen.
 

Fabolous

Well-Known Member
#4
Da würde alles funktionieren was mit raw Sockets umgehen kann.
Die Anforderungen implizieren Möglichkeiten der Manipulation, Analyse und teilweise sogar Nachbildung jeglicher Abläufe und Inhalte, angefangen mit dem physical layer. Mit sockets, oder allgemein der jeweils regulären Betriebssystemschnittstelle würden die vielen system calls schon bei einer eingehenden Verbindung die Wartezeit verdoppeln. Abgesehen davon hat man bei Geschichten wie dem ARP die Grenzen von sockets schnell erreicht während Malware im Kernelmode sich darüber kaputt lachen könnte.

Edit: die Wahl im Bezug auf das Betriebssystem würde ich auf Linux fallen lassen.
Warum das denn bitte? :)
 

lano

Well-Known Member
c-b Experte
#5
Weil linux schon von haus aus alle Voraussetzungen erfüllt um das vorhaben umzusetzen.
Weil ich mir es da völlig schenken kann da irgendwelche treiber zu programmieren.
Und auch mit Geschichten wie arp gibt es keine Probleme.
Stell dir vor, im kernel lässt sich arp ganz leicht abschalten.
Und auch alles andere. Und stell dir vor, es gibt sogar ein kernelmodul das einem ne ganz einfache möglichkeit gibt auf dem untersten Layer rumzuwurschteln wie man möchte.
Von langsam hab ich noch nix bemerkt, selbst mein 250MHz ThinClient packt das locker. Und ob da irgendwelche systemcalls wie oft aufgerufen werden, das kann mir völlig am Arsch vorbei gehen, solange ich das nicht mit nem Taschenrechner im Scheckkartenformat versuche.
Meine Meinung.
 

Fabolous

Well-Known Member
#6
Stell dir vor, das alles funktioniert auch mit Windows oder dachtest du nur Linux kennt sockets? Ich sprach allerdings nicht von Zirkusauftritten, sondern von seriösen Fällen in denen beispielsweise Verbindungen eines gängigen Servers analysiert werden müssen. Bin gespannt wie lange dir die system calls bei tausenden aktiven Verbindungen 'am Arsch vorbei gehen'.
 

lano

Well-Known Member
c-b Experte
#7
Wusst ich garnicht das linux gleich nen compiler mitliefert.
Das windows so nett ist und mich im kernel rumwurschteln lässt ist auch völlig an mir vorbeigegangen.
Wieso erzählst du jetzt eigentlich wieder ein von sockets? War dir doch noch ein post vorher nicht ausreichend genug?
Die anzahl der Verbindungen interessiert so garnicht, die Anzahl der Pakete ist ausschlaggebend.
Und gängige Server, wie zb der wo das forum drauf läuft haben ne 100mbit Anbindung. Da ist die mögliche Datenmenge recht begrenzt.

Aber wenn du dich soo gut auskennst, in wie weit würde mir denn windows die Möglichkeit geben auf dem weg der daten geziehlt einzugreifen?
So sieht das bei Linux aus: fetch.php.png

Ist aber vllt nicht deine gehaltsklasse.
 

Fabolous

Well-Known Member
#8
Wusst ich garnicht das linux gleich nen compiler mitliefert.
Seit wann ist denn hier die Rede von Compilern?
Das windows so nett ist und mich im kernel rumwurschteln lässt ist auch völlig an mir vorbeigegangen.
Unter Windows 2000 war das auch noch ohne weiteres möglich. Irgendwie hat man sich aber weiter entwickelt und den direkten Kernelzugriff für normale Applikationen durch Schnittstellen ersetzt. Bei Linux scheint das nicht anders zu sein, oder wie begründest du die Existenz von system calls wenn man doch sowieso 'im Kernel rumwurschteln' kann wie man will?
Es geht hier um eines der einfachsten Prinzipien aller Betriebssysteme, nämlich die Trennung von Applikationen und dem Kernel. Also kannst du dir die Windows-Vergleiche auch sparen, der uneingeschränkte Zugriff ist ohne Schnittstellen nicht möglich. Fakt.

Aber wenn du dich soo gut auskennst, in wie weit würde mir denn windows die Möglichkeit geben auf dem weg der daten geziehlt einzugreifen?
So sieht das bei Linux aus:
An allen, an denen du auch von Linux aus drauf zugreifen könntest. Bitteschön: https://msdn.microsoft.com/de-de/library/windows/desktop/aa969177(v=vs.85).aspx
 

lano

Well-Known Member
c-b Experte
#9
Es ging darum das ich gesagt habe, linux bringt schon alles mit, und nen compiler ist genauso dabei wie viele viele tools zum analysieren, manipulieren usw.

Du hast es mit dem Kernel anscheinend nicht so ganz gerafft. Aber wenn du der Meinung bist du kannst bei windows genauso sachen ändern wie im linux kernel, naja viel spass.
 

Fabolous

Well-Known Member
#10
Es ging darum das ich gesagt habe, linux bringt schon alles mit, und nen compiler ist genauso dabei wie viele viele tools zum analysieren, manipulieren usw.
Das ist wirklich schön, leider geht es hier nicht um die Verwendung irgendwelcher Tools und Linux hebt sich dadurch ohnehin in keinerlei Hinsicht von Windows ab.
Du hast es mit dem Kernel anscheinend nicht so ganz gerafft.
Raff du erst mal die Grundlagen moderner Betriebssysteme, dann reden wir weiter. Ist aber villeicht auch nicht deine Gehaltsklasse.
 

lano

Well-Known Member
c-b Experte
#11
Ist ja gut.
Windows bringt natürlich standard mäßig hunderte tools mit, war schon immer so und wird auch immer so sein.
Der windowskernel lässt sich auch genauso anpassen wie bei linux, windows ist ja für offenen quellcode bekannt.
Zerro Copy networking verursacht wie schon immer haufenweise systemcalls.
Windows war in sachen netzwerke auch schon immer wesendlich flexibler, darum haben Geräte der Netzwerkinfrastuktur auch meist ein windows installiert.
Reicht es jetzt?
 

German

Well-Known Member
c-b Experte
#12
Jungs, bringt doch nichts wenn ihr euch hier die Köpfe einschlagt. Der TO hat bislang noch keinerlei Statement abgegeben, zu dem was ihr vorschlagt. Sicher wird es am Ende eine Kombination aus der Socket API des jeweiligen OS werden und (dort wo das nicht ausreicht oder zu viele Ressourcen frisst) eine Neuentwicklung in Richtung Treiber. Also cool down, bleibt beim Thema (und das ist nicht die Frage nach Linux oder Windows) und helft dem TO selbst zu entscheiden. Wenn ihr euch in einem Kleinkrieg verrennt, kann der Thread am Ende gleich in die Tonne, wegen Unübersichtlichkeit und fehlenden Informationen die dem TO tatsächlich helfen (und um letzteres geht es schließlich in einem Form).

Just my two cents ...
 

-AB-

Well-Known Member
c-b Team
c-b Experte
#13
Am Rande noch.... Da Suchmaschinen Dinge wie Ironie grundsätzlich entgehen, sollte im Idealfall jeder nur das schreiben, was er auch tatsächlich meint.

windows ist ja für offenen quellcode bekannt
Irgendjemand landet sonst z.B. aufgrund dieser Aussage auf dieser Seite und lernt gleich mal falsche Dinge, das wollen wir natürlich vermeiden...
 

lano

Well-Known Member
c-b Experte
#14
@-AB-
Ach komm, meinste wirklich das das einer für Fakt erklärt? Nagut, wenn einer wirklich nach dem Win Source sucht wird er sogar in gewissem Maße fündig. Aber glaubst du echt dass einer deswegen ne Mail an Microsoft schreibt und nach dem Rest fragt?

In einem Punkt geb ich euch jedoch vollkommen recht. Das Thema ist zerschossen und kann in den Müll. Der TO ist vermutlich abgeschreckt für sein leben und lässt sich hier nicht mehr blicken. Ja, ich hätts vorher beenden sollen, tut mir leid.

So, noch nen Tierbild und gut.
2_big.jpg
 
Oben