Zulan, klappt das Inject-Beispiel von http://pycap.sourceforge.net/ bei dir und du siehst in Wireshark die abgesendeten Pakete?!
Zulan, klappt das Inject-Beispiel von http://pycap.sourceforge.net/ bei dir und du siehst in Wireshark die abgesendeten Pakete?!
Achtung Spoiler:
update.php solltes es nun geben:
https://help.github.com/articles/syncing-a-fork
zulan@vow:~/PBStats$ git merge upstream/master
Auto-merging web/page/contentmanager/Game.functions.php
Merge made by the 'recursive' strategy.
web/page/contentmanager/Game.functions.php | 3 +--
web/page/update.php | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 96 insertions(+), 2 deletions(-)
create mode 100755 web/page/update.php
Achtung Spoiler:
Zum senden der Fake-Pakete:
Also bei mir funktioniert folgendes:
Mangels funktionierendem Civ in einer VM bzw. Pitboss auf anderem Rechner hab ich es noch nicht mit dem PB getestet nur mit einem einfachen:Code:import socket import sys import ip import udp ClientHost = '192.168.122.222' ServerHost = '192.168.122.1' ClientPort = 2056 ServerPort = 2056 upacket = udp.Packet() upacket.sport = ClientPort upacket.dport = ServerPort #upacket.data = "\xfe\xfe\x68" upacket.data = "Hello Server" ipacket = ip.Packet() ipacket.src = ClientHost ipacket.dst = ServerHost ipacket.df = 1 ipacket.ttl = 64 ipacket.p = 17 ipacket.data = udp.assemble(upacket, False) raw_ip = ip.assemble(ipacket, 1) try: sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW) except socket.error , msg: print 'Socket could not be created. Error Code : ' + str(msg[0]) + ' Message ' + msg[1] sys.exit() sock.sendto(raw_ip, (ipacket.dst, 0))
Die UDP Checksumme fehlt noch, ich habs versucht die mit dem Pseudoheader zu berechnen, aber noch nicht hinbekommen (pyip versucht das garnicht erst die UDP cheksumme korrekt zu berechnen).Code:import socket ServerHost = '192.168.122.1' ServerPort = 2056 sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((ServerHost, ServerPort)) while True: data, addr = sock.recvfrom(1024) print "received message |", data, "| from ", addr
Achtung Spoiler:
Ich danke dir Die Udp-Checksumme soll ja nur optional sein. Hatte zwar geschrieben, dass ich meine Probleme auf diese Checksumme zurück führte, aber da hatte ich wohl noch was im Ethernet-Header falsch gesetzt.
Ich habe heute noch ein paar C-Beispiele angeschaut, die libnet direkt nutzen und auch die Checksumme automatisch berechnen, aber ich probiere das jetzt mal mit dem ip-Paket aus.
Ok, das Unterbrechen des Uploads vom PB-Server klappt. Ich werde dass jetzt in ein Skript gießen, was einmal pro Minute aufwacht und den Udp-Traffic auf einem Port analysiert. Wenn 10 Pakete für einen Client die gleiche Struktur haben wird das als Upload-Bug definiert und ein Beenden der Verbindung probiert.
Läuft nat. wegen der verwendeten Bibs nicht unter Windows…
Warum nicht einfach dauerhaft mitsniffen? Dann hat man ne komplette Serie, das dürfte einfacher auszuwerten sein.
Neben pycap gibt es noch pypcap, das gibts auch für Windows. das sind ja beides nur libpcap wrapper, sollte sich leicht überführen lassen.
https://code.google.com/p/pypcap/downloads/list
Bzw. Für neuere Python.
http://breakingcode.wordpress.com/20...n-2-5-2-6-2-7/
Achtung Spoiler:
Im Anhang ist das Skript für die Upload-Problematik. Bisher nur für Linux. Im Zip sind auch die zwei benutzten Bibliotheken, aber pycap muss man wahrscheinlich eigenständig installieren, da da ja Bibs kompiliert werden.
Habe den Python-Teil des Pitboss-Server auch schon so verändern, dass er Headless läuft.
Kommt das ins github?
Edit: Ah, du hast dein pycap von github, ich hatte meins von der 11 Jahre alten sourceforge seite . Aber das sind auch nur 3 nutzlose commits.
Achtung Spoiler:
Bei Headless-Versuch gibt leider einen Rückschlag zu vermelden. Ich habe zwar alle Fensterklassen (wx.*) aus dem Code entfernt und auch einen Zustand erreicht, in dem keine Python-Exceptions (auch Fenster) geworfen werden, aber es wird immer noch versucht ein Fenster anzulegen. Darauf weist auch die Zeile
hin, die wine beim Starten in die Konsole schreibt. Ich hatte dann noch probiert die Fensterausgabe mit xvfb (xvfb-run wine [...] ) umzulenken, aber das scheiterte bisher an 3D-Grafik-Calls.Code:fixme:win:EnumDisplayDevicesW ((null),0,0x32f3b8,0x00000000), stub!
Edit: Beim Googeln zu dem xvfb-Fehler fand ich einen Thread von 2008 aus dem Civforum. Threadersteller: ZulanCode:err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems wine: Unhandled page fault on read access to 0x00000000 at address 0x5f08da (thread 0009), starting debugger...
Positiv ist, dass die CPU-Last ohne Fenster stark sinkt. Von vormals 15% auf 1% falls niemand eingeloggt ist.
Wahrscheinlich hast du recht und man kann das Skript an der Stelle vereinfachen und das Sniffen sofort neustarten, nachdem es in Aktion getreten war.
Geändert von Ramkhamhaeng (20. August 2014 um 12:20 Uhr)
Kannst du die Version mal auf github oder hier stellen. Wenn da einfach irgendwo ein paar OpenGL calls kommen, kann man die vielleicht einfach abfangen und so tun als ob es erfolgreich war.
Ich bin mir noch nicht ganz sicher wann next() None zurueck gibt und wann es blockiert. Das muesste man sich nochmal anschauen. Ich bin mir aber prinzipiell nicht ganz sicher ob die Heuristik greift - bzw. ob es ueberhaupt moeglich ist das zuverlaessig zu unterscheiden ohne sich die Client-Packete anzuschauen. Ich habe den Packetlog nicht vorliegen, aber kann man ausschliessen, dass die selbe Paketstruktur nicht bei Normalem eingeloggt sein auftritt? Oder vielleicht waehrend ein andere Spieler sich einloggt zwischen dem Server und dem Spieler der schon eingeloggt ist?Wahrscheinlich hast du recht und man kann das Skript an der Stelle vereinfachen und das Sniffen sofort neustarten, nachdem es in Aktion getreten war.
Achtung Spoiler:
Habe es als noGui-Branch in meinem Repo hochgeladen. Achtung, bin noch nicht dazu gekommen deine Änderungen zu mergen. Änderungen sind nur in Assets/Python/Pitboss erfolgt.
Edit: Hm, er uploaded noch Keine Ahnung warum er da so viel hochläd…
Die gleiche Paketstruktur sollte nicht auftauchen. Habe das schon ein wenig ausgetestet. Der Server wiederholt immer die gleichen Daten, wenn die Gegenstelle nicht mehr antwortet. Das hatte interessanterweise aber nicht ganz ausgereicht und ich wurde teilweise beim Laden der Karte gekickt Aber nachdem ich in dem If-Statement bei 'len(payload)' mit der genauen Udp-Paketgröße vergleiche, die beim Upload-Bug auftritt ist alles in Butter. Diese Größe tritt anderenfalls laut Wireshark selten (oder sogar gar nicht) auf. Ich nahm die Länge vom Payload und nicht die Gesamtlänge des Ethernet-Packets, weil bei IPv6-Adressen eine andere Gesamtlänge auftritt.Ich bin mir noch nicht ganz sicher wann next() None zurueck gibt und wann es blockiert. Das muesste man sich nochmal anschauen. Ich bin mir aber prinzipiell nicht ganz sicher ob die Heuristik greift - bzw. ob es ueberhaupt moeglich ist das zuverlaessig zu unterscheiden ohne sich die Client-Packete anzuschauen. Ich habe den Packetlog nicht vorliegen, aber kann man ausschliessen, dass die selbe Paketstruktur nicht bei Normalem eingeloggt sein auftritt? Oder vielleicht waehrend ein andere Spieler sich einloggt zwischen dem Server und dem Spieler der schon eingeloggt ist?
Die Analyse der Paketstruktur ist eigentlich aber auch nur dann erforderlich, wenn man das Antwortpaket erstellen will. Es würde auch der Ansatz reichen die Ip's von Eingangs und Ausgangstraffic zu vergleichen. Wenn die Clients nicht antworten ist offensichtlich was im argen Wäre aber in der Programmierung aufwändiger gewesen.
Geändert von Ramkhamhaeng (20. August 2014 um 12:56 Uhr)
Das wird alles so cool
Freedom's just another word for nothing left to lose
Frage zu PHP-Syntax in deinem Code:
Bei älteren PHP-Versionen ist die Syntax "$columnNames = [];" nicht bekannt.
Kann ich in = array() umwandeln ohne das es bei dir Warnungen wirft, oder?