Harmony ist dafür da, Fremdsoftware zu blockieren. Das tut es auch recht gut. Problematisch wird es nur, wenn man ein Programm explizit unterstützen muss… Die Rede ist von RCX – einer japanische Erweiterung des RO Clients, die vielen “alten Hasen” unter RoCha bekannt sein dürfte. Ansonsten verschafft dieses Video einen recht guten Überblick über die Features:

Ein Kunde sprach mich vor kurzem darauf an, dass RCX nicht mit Harmony kompatibel sei. Nicht verwunderlich, schließlich lädt RCX nicht nur eine fremde DLL, sondern fängt auch Winsock Funktionen ab, um anhand der Netzwerkpakete beispielsweise Skilleffekte anzuzeigen. So begann also mein Odysee hin zu einem RCX Fix…

Nach kurzer Codeanalyse stellte sich heraus, warum andere Bot-Protections keine derartigen Probleme haben: Die Netzwerkfunktionen arbeiten nicht direkt auf WinAPI Ebene – RCX umgeht sie daher dezent. Da Harmony auf mehreren Layern arbeitet und alle davon unter RCX liegen gestaltet sich die Sache etwas schwieriger.
Mein finaler Plan:

• Über Whitelisting wird der RCX DLL der Zugriff auf Harmony gestattet
• Ein- und ausgehende Netzwerkpakete werden gesammelt und über emulierte Winsock Aufrufe an RCX übergeben
• ????
• Profit!

Punkt 1 war schnell erledigt. Die Emulation der Winsock Aufrufe wurde etwas ekelhafter: RCX fängt alle Winsock Aufrufe ab und muss daher selbstständig die originalen Funktionen aufrufen. Bei eingehenden Paketen würde RCX also selbstständig “nachfragen”, ob Pakete vorhanden sind, feststellen, dass dem nicht so ist und einfach mal nichts tun. Ich durfte daher die originalen Winsock Funktionsaufrufe ebenfalls abfangen und RCX mit meinen Daten füttern. Dazu kommt, dass einige Harmony Layer den RO Client derart modifizieren, dass eine Rekonstruktion der originalen Pakete nur mit erheblichem Aufwand möglich ist. Yay.

Im Endeffekt konnte ich den Code auf ~300 Zeilen (und 8 Stunden Arbeit…) kürzen, trotzdem denke ich lieber nicht so oft daran, was bei aktiviertem RCX Fix mit Netzwerkpaketen angestellt wird: