Root + TCPServer + _MemoryRead

    Hallo Community,

    ich stehe derzeit vor einem kleinen Problem.
    In den letzten Tagen habe ich ein Script gebastelt welche von einem MW3 Server die Spielinformationen ausliest (via MemoryOpen & MemoryRead).
    Das ganze wird über eine UDF an die Clients verteilt (die alle 2.5sec die Informationen abfragen).
    Hier zuhause funktioniert das ganze Tadellos über 127.0.0.1
    Nun ist das AutoIt Serverscript auf dem GameServer gestartet und ich kann mit dem Client eine Verbindung herstellen. Es kommen jedoch keine Daten an (so als könne die MW3Server.exe nicht gefunden werden. Ich bin auch schon mit dem Hoster in Kontakt getreten wo das Problem liegen könnte.

    Auf dem Root läuft nur eine (unsere) iw5mp.exe + das AutoIt Server Script, in der Firewall ist alles nötige Freigegeben (sonst könnte ich ja mit dem Client keine Verbindung herstellen). Das AutoIt Script wird mit Administratorrechten Ausgeführt (Windows UAC ist aktiv).

    Hat jemand von euch eine Idee wo das Problem liegen könnte?

    Zeig uns doch mal die beiden Scripte, dann könnten wir Fehler auf seiten deiner Scripts schon mal ausschließen... ;) Möglicher weise besitzt der Server auch einen Schutzmechanismus der vom aktuellen Computer abhängt. Hast du das ganze auf verschiedenen Rechnern getestet? Wurde das Script schon mal im Netzwerk getestet? Also nicht über Localhost sonder mit zwei verschiedenen Rechnern im Netzwerk... ;)

    LG
    Christoph :)

    Die Beiden Scripte sind hier:
    http://www.aeclan.de/dl/CLIENT.au3
    http://www.aeclan.de/dl/SERVER.au3
    Im Netzwerk lief das ganze vor 3 Wochen noch Problemlos, seitdem habe ich nur kleinere änderungen vorgenommen (Netzwerk = WLan Laptop + Lan PC über einen Router)
    Einen weiteren Test habe ich auch schon außerhalb des Hauses mit dem PC eines Freundes vorgenommen, da kamen auch keine Probleme auf.


    EDIT: Wie ich gerade herausgefunden habe, findet mein Script die iw5mps.exe, jedoch werden keine Daten ausgelesen.

    3 Mal editiert, zuletzt von juloko1 (15. September 2012 um 14:16)

    Keine Ahnung welches OS auf deinem Server läuft, aber Serverbetriebssysteme haben normalerweise die "Datenausführungsverhinderung" aktiviert. Könnte mir durchaus vorstellen, dass das bei Zugriffen auf Speicherbereiche anderer Anwendungen zu Problemen führen kann. Hatte jedenfalls selbst schon Anwendungen, die auf Windows 7 einwandfrei liefen, auf Windows 2008 R2 allerdings erst nach Ausnahme in der Datenausführungsverhinderung.

    Hey,

    danke für den Tipp.

    Laut Angaben des Hosters ist die Datenausführungsverhinderung deaktiviert.
    (2008 R2)


    Grüße.

    Keine Ahnung wie das bei Game Servern so läuft... hast du vollen Remotedesktopzugang zum Server? Wenn ja verfügst du überhaupt über Administratorrechte? Läuft der Gameserver ansich über deinen eigenen Benutzeraccount des physikalischen Servers oder wird der auf einem von dir nicht direkt zugreifbaren Account ausgeführt? Ob die Memory UDF die du da verwendest in der Lage ist auch Speicherbereiche von Programmen auszulesen, die auf anderen Benutzeraccounts laufen weiß ich nicht, ggf. liegt ja auch da das Problem.

    Zitat von misterspeed

    Keine Ahnung wie das bei Game Servern so läuft... hast du vollen Remotedesktopzugang zum Server? Wenn ja verfügst du überhaupt über Administratorrechte? Läuft der Gameserver ansich über deinen eigenen Benutzeraccount des physikalischen Servers oder wird der auf einem von dir nicht direkt zugreifbaren Account ausgeführt? Ob die Memory UDF die du da verwendest in der Lage ist auch Speicherbereiche von Programmen auszulesen, die auf anderen Benutzeraccounts laufen weiß ich nicht, ggf. liegt ja auch da das Problem.


    1. Remote zugang habe ich keinen. Der GameServer (für uns speziell auf MW3 ausgelegt) verfügt über einen FTP zugang und über ein Web Interface, worüber wir den MW3 Server starten & beenden können. - Das AI Script habe ich halt kompiliert & auf den Server hochgeladen. Da ich das ganze aber nicht über den FTP/das Webinterface starten kann, habe ich noch ein Tool gemacht welches permanent läuft und dauerhaft einen TCP Port abhört (23328), so kann ich das Serverscript an und ausschalten.
    2. Laut Hoster wird das Script mit Administratorrechten gestartet.
    3. So wie ich das verstanden habe läuft ein Benutzer mit mehreren MW3 Servern (unser hat aber eine namentlich geänderte *.exe - sodass es mit ProcessExists keinerlei komplikationen geben sollte).
    Als UDF verwende ich die NomadMemory.au3
    Ich werde den Hoster einmal Fragen ob es irgendwie möglich ist eine Bildschirmübertragung zum Server machen zu können.

    Grüße.

    Und du bist dir sicher, dass das Autoit Script überhaupt gestartet wird? Bastel doch mal ein Testscript, das nur eine Datei @scriptdir anlegt und sich dann wieder beendet. Das Ergebnis kannste dann ja zumindestens per FTP prüfen.
    Ohne vollen Serverzugang stelle ich mir jedenfalls den Betrieb eines eigenen TCP Servers problematisch vor, Zugang zur Windows Firewall haste so ja z.B. auch selbst keinen und musst dich auf die Aussagen des Hosters verlassen. Da der Hoster anscheinend ja auch andere Kunden mit diesem Server versorgt bezweifle ich auch, dass er dir irgendwelche weitergehenden Rechte auf der Maschine einräumen wird oder überhaupt mit der Ausführung von Fremdcode auf seinem Server einverstanden ist. Letztlich wäre das ja ein enormes Sicherheitsrisiko für den Hoster und die anderen Kunden auf dem Server.

    Zitat von misterspeed

    Und du bist dir sicher, dass das Autoit Script überhaupt gestartet wird? Bastel doch mal ein Testscript, das nur eine Datei @scriptdir anlegt und sich dann wieder beendet. Das Ergebnis kannste dann ja zumindestens per FTP prüfen.
    Ohne vollen Serverzugang stelle ich mir jedenfalls den Betrieb eines eigenen TCP Servers problematisch vor, Zugang zur Windows Firewall haste so ja z.B. auch selbst keinen und musst dich auf die Aussagen des Hosters verlassen. Da der Hoster anscheinend ja auch andere Kunden mit diesem Server versorgt bezweifle ich auch, dass er dir irgendwelche weitergehenden Rechte auf der Maschine einräumen wird oder überhaupt mit der Ausführung von Fremdcode auf seinem Server einverstanden ist. Letztlich wäre das ja ein enormes Sicherheitsrisiko für den Hoster und die anderen Kunden auf dem Server.


    Ja, das AutoIt Script wird erfolgreich gestartet. Ich habe testweise eine ini Datei in @ScriptDir verzeichnis anlegen lassen, in welche die _MemoryRead Daten eingetragen werden - der Wert bleibt aber leer.
    Die Windows Firewall wurde auch extra für mich freigegeben, sonst könnte ich keine (erfolgreiche) Verbindung mit einem Client zum Server herstellen. Das Problem liegt lediglich daran, das _MemoryRead keine Daten ausliefert.
    Ich habe mir auch schon einen einfachen Text vom Server senden lassen, das klappt problemlos. Ich kann einfach keinen Grund finden, warum es nicht funktionieren sollte. Das Antivirenprogramm vom Hoster soll auch keine Meldung gemacht haben.

    Dann hilft wohl nur gescheites debugging. Ich gehe davon aus, dass die Funktionen _MemoryOpen() und _MemoryRead() durchaus über Errorcodes und Fehlerrückgabewerte verfügen, die man auswerten könnte, dazu eben mal einen Blick in die UDF werfen. Der erste Schritt wäre also dein Script so umzubauen, dass die Teilergebnisse nicht sofort weiterverarbeitet sondern erstmal zu Debugzwecken in Logdateien inklusive möglicher Fehlercodes ausgegeben werden. Auch verwendest du anscheinend die Ergebnisse von iniread im Funktionsaufruf. Um Fehler auszuschliessen sollte der INI Inhalt ebenfalls zuerst geprüft werden.

    Alles klar, danke für den Tipp.
    Ja - mit der NomadMemory.au3 kann ich mehrere Fehlercodes abfangen.
    Ich versuche die jetzt mal in eine *.ini zu schreiben, mal schauen was man so rauslesen kann.
    Ich melde mich nochmal!
    EDIT: Das ist echt komisch - meine error.ini sieht derzeit so aus.
    [MEMORYOPEN]
    ERROR=0
    [MEMORYREAD]
    ERROR=0
    MAP= (die angeblichen Daten die ausgelesen werden - leeres Feld :( )

    Ich stell jetzt mal folgendes hin:
    Der Prozess 'iw5mp.exe' wird von ProcessExists & _MemoryOpen gefunden. _MemoryRead gibt keinen Fehler aus.

    [autoit]

    $IW5MP_MAP = _MemoryRead("0x" & IniRead(@ScriptDir & "\data.ini", "OFFSET", "MAP", ""), $IW5MPProcess, 'char[64]')
    ; @Error - 0 = No error.
    ; 1 = Invalid $ah_Handle.
    ; 2 = $sv_Type was not a string.
    ; 3 = $sv_Type is an unknown data type.
    ; 4 = Failed to allocate the memory needed for the DllStructure.
    ; 5 = Error allocating memory for $sv_Type.
    ; 6 = Failed to read from the specified process.
    If @error = 0 Then
    IniWrite(@ScriptDir & "\playerdata.ini", "MEMORYREAD", "ERROR", "0")
    IniWrite(@ScriptDir & "\playerdata.ini", "MEMORYREAD", "MAP", $IW5MP_MAP)
    EndIf

    [/autoit]


    Trotzdem bleibt der Wert 'MAP = ' leer.

    4 Mal editiert, zuletzt von juloko1 (16. September 2012 um 21:14)

    Mein Hoster hat auf meine Antwort hin auch keine Idee mehr.
    Er meinte das es eventuell noch an der UAC liegen könnte.

    Hat hier jemand vielleicht noch eine Idee?

    Grüße

    Macht es einen Unterschied ob ich ein Skript mit unterschiedlichen AutoIt Versionen kompiliere?
    Weil auf meinem PC funktioniert es ja problemlos (auch im Netzwerk).

    Zitat von juloko1

    Macht es einen Unterschied ob ich ein Skript mit unterschiedlichen AutoIt Versionen kompiliere?


    Ja natürlich immer dann wenn mind. 1 benutzte UDF nicht mit der verwendeten Version kompatibel ist. Und die Nomad-udf wurde menes Wissens noch nicht an die aktuelle Version angepasst.

    Zitat von juloko1

    Weil auf meinem PC funktioniert es ja problemlos (auch im Netzwerk).


    Sind denn beide Skripte mit der gleichen AutIt-Version kpmpiliert worden?

    mg autpBert

    Ja,
    ich kompiliere SERVER + CLIENT mit meinem Computer.
    Es ist echt schade das man den Fehler nicht finden kann. Ich bin schon viele möglichkeiten durchgegangen woran es liegen könnte :( In dem Script stecken soviele Stunden Arbeit.

    Grüße

    Vielleicht auch ein 32/64 bit Problem? Keine Ahnung ob diese memory UDF da Probleme macht. Könnte mir aber gut vorstellen, dass es einen unterschied macht ob man die Speicherbereiche einer 32bit oder 64bit Anwendung ausliest.

    Der Server läuft (wie mein PC auch) auf x64 - habe das Serverscript gerade mal als x64 kompiliert - macht soweit aber keinen Unterschied :(

    Also,

    ich war gerade auf einem anderen Root, da besteht dasselbe Problem. Diesmal war ich per RDP drauf, in der Firewall war alles freigegeben, am Antivirus lag es nicht. Die Windows UAC war aus.
    Ich konnte die Befehle vom Client (z.B. Chat) ohne Probleme ausführen. Es gibt also nur das Problem mit dem MemoryRead.

    Zitat von juloko1

    Es gibt also nur das Problem mit dem MemoryRead.


    Und dieses wundert mich nicht falls du >3.3.6.1 verwendest, dann musst du alle UDF's welche die Funktion hex verwenden anpassen. Ist imho ein Bug der aktuellen Version kompiliere dein Skript doch einfach mit der 3.3.6.1. Zu diesem Bug gibt es einen Beitrag von Funkey im Zusammenhang mit GDI-Progress darin wird auch bechrieben wie die hex-Funktion ersetzt werden muss. Afair muss Hex() mit Hex(Int()) ersetzt werden.

    mfg autoBert