PokerEV Securityanalyse

    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Da mich bei pokerEv schon immer wundert, dass man vom programm dazu gezwungen wird regelmäßig updates zu machen (wobei dann keine veränderung feststellbar ist) und auf der angeblich kommerziellen Website nichtmal nen impressum zu finden ist, hab ich mal begonnen ein wenig zu analysieren, was das ding so macht. hab dazu erstmal alle calls von GetProcAddress geloggt und nen paar seltsamkeiten gesehen.
      Zunächst werden bereits bei Programmstart diverse crypt-functions genutzt, deren sinn sich mir nicht erschließt. Klar könnte das auch nen wahnsinnig schlechter packer sein, aber ich bin da etwas misstrauisch.

      Etwas besorgniserregend finde ich auch diese Aufrufe:
      C:\WINDOWS\system32\USER32.dll SetWinEventHook
      C:\WINDOWS\system32\USER32.dll UnhookWinEvent
      und
      C:\WINDOWS\system32\kernel32.dll CreateRemoteThread
      C:\WINDOWS\system32\ntdll.dll NtCreateUserProcess


      Ich hab bisher nochnichts genauer angesehen und weiß nicht, ob das normale verhaltensweisen sind, oder ob da etwas faul ist. Ich werd mich demnächst mal damit befassen, was dort verschlüsselt und gehooked wird, und wo der remotefred erzeugt wird und welcher prozess dort gestartet wird. Kann aber nen paar wochen dauern, bis ich da genaueres weiß. hab bisher noch keine software für solche analysen und muss alles neuschreiben.
      Wäre nett, falls sich noch jemand an der analyse beteiligen würde.
  • 5 Antworten
    • Lifeisabug
      Lifeisabug
      Bronze
      Dabei seit: 30.12.2007 Beiträge: 1.629
      Den Aufwand kannst du dir sparen :)

      Original von pokersille
      Da mich bei pokerEv schon immer wundert, dass man vom programm dazu gezwungen wird regelmäßig updates zu machen (wobei dann keine veränderung feststellbar ist) und auf der angeblich kommerziellen Website nichtmal nen impressum zu finden ist, hab ich mal begonnen ein wenig zu analysieren, was das ding so macht.
      Habe mich schon laenger nicht mehr mit PokerEV befasst, da es auf Ongame durch die fehlenden mucked Hands eher wenig zu gebrauchen ist. Die Updates haben den einfachen Hintergrund, dass eigentlich schon ewig geplant war, aus PokerEV ein kommerzielles Produkt zu machen. Wenn ich mich recht entsinne sollten tracker-aehnliche Funktionen eingebaut werden etc. Der Entwickler moechte einfach verhindern, dass dies relativ stabile Programm fuer jeden bis in alle Ewigkeit frei verfuegbar ist. Durch die Updates haelt er sich die Option offen, es zu kommerzialisieren. Die Wertung dessen sei jedem selbst ueberlassen :)


      Original von pokersille
      Etwas besorgniserregend finde ich auch diese Aufrufe:
      C:\WINDOWS\system32\USER32.dll SetWinEventHook
      C:\WINDOWS\system32\USER32.dll UnhookWinEvent
      und
      C:\WINDOWS\system32\kernel32.dll CreateRemoteThread
      C:\WINDOWS\system32\ntdll.dll NtCreateUserProcess
      Das ist wirklich kein Stueck besorgniserregend.
      Die einzigen Events, die er hooked sind:
      EVENT_SYSTEM_MOVESIZESTART (0x0000000A)
      A window is being moved or resized. This event is sent by the system; servers never send this event.
      EVENT_SYSTEM_MOVESIZEEND (0x0000000B)
      The movement or resizing of a window has finished. This event is sent by the system; servers never send this event.

      Er erhaelt damit also wirklich nur resize events.


      Mit dem RemoteThread habe ich mich jetzt nicht weiter auseinander g esetzt, da er in keinem anderen Prozess gestartet wurde bei mir. Und da er eh nichts hooked ist es mir auch wurscht :)
      Ich finde es auf Grund der Tatsache, dass PokerEV eigentlich nie mit irgendeinem Server zu kommunizieren scheint, nicht so richtig bedenklich. Darueber hinaus ist der Junge bei 2+2 recht angesehen und bekannt. Letzteres ist natuerlich keine Garantie, dass da alles sauber ist. Aber zusammen mit den anderen Fakten scheint recht sicher zu sein, dass PokerEV nichts verwerfliches tut.
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Die Argumentation ist natürlich nachvollziehbar, aber gesundes Misstrauen hat noch niemanden geschadet. Hab gestern nochmal die CPEncrypt() aus rsaenh.dll angesehen und erstmal keinen Aufruf gefunden. Werd mir auf jedenfall nochmal den CreateRemotefred() und den NtCreateUserProcess() ansehen. Damit könnte schließlich auch noch nen hook gemacht werden. Wenn dort auch nichts zu finden ist, ist das Programm vertrauenswürdig.
    • Lifeisabug
      Lifeisabug
      Bronze
      Dabei seit: 30.12.2007 Beiträge: 1.629
      Habe mir jetzt nicht angeguckt was er da verschluesselt, aber solange er nur encrypted und nicht decrypted ist doch alles im lot. Wenn ich mir seine DLLs anschaue scheint er Mono Security zu nutzen - vielleicht um sich vor Cracks zu schuetzen, was wirklich Sinn bei seiner Laufzeit von 2-4 Wochen machen wuerde.

      Wenn er keine SystemWide Hooks macht, sondern ueber einen remote Thread, dann macht er dass ueber dll injection. Wenn ich mich jetzt nicht bei den Schnittstellen verguckt habe gibt es aber in seinem Programm keine DLL, die dafuer geeignet waere. VICE zeigt mir auch keine derartige Aktivitaet an.
      Ungefaehrlich :)

      Und ja gesundes Misstrauen ist ok. In diesem Fall kam es einfach ein bissel zu spaet. Das Programm ist seit Ewigkeiten draussen und erfreut sich grosser Beliebtheit. Wenn ein Tool bei 2+2 released wird, dann prueft das dort jeder zweite geek auf bis ins Kleinste. Die Leute, die schaedliche Pokersoftware verbreiten wollen, versuchen das eher ueber Google.
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      Du hast schon recht, nicht alles, was man sich nicht sofort erklären kann ist böse.
      Wie ich oben bereits erwähnt hab, wurden die Cryptmodule ja ausschließlich initialisiert. Nen call auf CPEncrypt() konnte ich nicht fststellen. CPDecrypt() hab ich mir noch nicht angesehen. Allerdings finde ich Encrypts deutlich gefährlicher als decrypts. angenommen ich würde nen spy basteln, würde ich die infos nicht plain über die leitung schicken. die wincrypt-api für packer zu verwenden hat meiner meinung nach wenig bis garkeinen sinn. interne funktionen, die diesen job machen sind da deutlich besser geeignet. Aber ok, nur weil ich nicht weiß, warum die module geladen werden, muss da nix böses dahinter stecken.
      Gleiches gilt für den remotethread, auch wenn ich der meinung bin, dass dlls zwar der einfachste, aber nicht der einzige weg ist, um ne codeinjection zu machen.
      Was ist VICE? Meinst du damit WeichEis?
    • pokersille
      pokersille
      Bronze
      Dabei seit: 28.01.2008 Beiträge: 565
      So, hab mir jetzt noch den NtCreateUserProcessEx (<- Was macht die eigentlich? Ist die Vista-only? msdn sagt nix über die) und den CreateRemoteThread angesehen. Einen aufruf von NtCreateUserProcessEx konnte ich nicht feststellen und den RemoteThread erzeugt die Anwendung in sich selbst, ist also auch ungefährlich.
      Seltsamerweise läuft die Anwendung auch ohne den dabei erzeugten Thread bestens, terminiert ohne aber nicht. Könnte nen Garbage Collector oder sowas sein. Hab leider zu wenig Ahnung von der CLR, um was qualifiziertes dazu zu sagen.
      Bin mir jetzt fast sicher, dass das Programm ungefährlich ist.