Anpassung des Cisco AnyConnect vpnagentd-Updates für OSX

1661
James Miller

Ich versuche, eine Lösung zu finden, die Split-Tunneling mit dem Cisco AnyConnect-Client für OSX ermöglicht. Ich habe herausgefunden, wie die Firewall geändert wird, und das lässt sich beheben. Das Problem ist jedoch, dass der vpnagentd- Daemon die Routingtabelle ständig entführt.

Sasha Pachev schlug eine elegante Lösung für Linux vor ( https://superuser.com/a/546668/568559 ). Ich habe jedoch Herausforderungen bei der Anpassung an OSX.

Die für Linux geschriebene hack.c verweist auf eine linux / netlink.h, die unter OSX nicht vorhanden ist. Ich denke, hier kommt der AF_NETLINK her .

#include <sys/socket.h> #include <linux/netlink.h>  int __ZN25CInterfaceRouteMonitorMac20routeCallbackHandlerEv() { int fd=50; // max fd to try char buf[8192]; struct sockaddr_nl sa; socklen_t len = sizeof(sa);  while (fd) { if (!getsockname(fd, (struct sockaddr *)&sa, &len)) { if (sa.nl_family == AF_NETLINK) { ssize_t n = recv(fd, buf, sizeof(buf), MSG_DONTWAIT); } } fd--; } return 0; }

Ich bin mit dieser Sprache nicht vertraut, daher bin ich mir nicht sicher, wo ich suchen muss. Ich kann andere Personen in der ursprünglichen Frage zur Anpassung an OSX sehen, aber ich sehe die Ergebnisse nirgendwo veröffentlicht.

Hat jemand Glück, diese Methode an OSX anzupassen? Jede Hilfe sehr geschätzt.

Sobald dieser Aspekt funktioniert, freue ich mich sehr über die vollständige Lösung.

2

2 Antworten auf die Frage

1
Rubio

(Ich habe die erweiterte Version dieser Funktion geschrieben, die die NETLINK-Daten entleert, nachdem Sasha Pachevs großartige Detektivarbeit herausgefunden hat, welche Funktion abgefangen werden soll. Ich bin froh, dass die Leute den Code für nützlich gehalten haben.)

Aus dem anderen Thread sehe ich, dass jemand "nm" verwendet hat, um herauszufinden, dass es einen analogen Callback-Handler für OSX gibt, und Sie versuchen, eine geeignete Funktion zu erstellen, um sie zu ersetzen. Ich verstehe, dass OSX überhaupt keine NETLINK-Schnittstelle bietet. Daher ist es sehr unwahrscheinlich, dass die OSX-Version von AnyConnect die Steuerung der Routing-Tabelle auf dieselbe Weise wie der Linux-Client übernimmt. Ich weiß nicht, welchen Mechanismus OSX anbietet, um AnyConnect zu signalisieren, dass eine Routing-Änderung erfolgt ist. Da es sich jedoch nicht um NETLINK-basierte Funktionen handelt, ist der hier verwendete Code zum Entleeren der Netlink-Nachricht nicht anwendbar.

Ironischerweise würde der ursprüngliche Stub-Funktionsstil von Sasha wahrscheinlich alles sein, was Sie benötigen, um zu verhindern, dass Ihre Routen durch eigene ersetzt werden. Diese Funktion sah wie folgt aus:

int __ZN25CInterfaceRouteMonitorMac20routeCallbackHandlerEv() { return 0; }

Unter Linux führte diese ursprüngliche Funktion zu einer hohen CPU-Auslastung, da das NETLINK-Ereignis, das den Aufruf des Callback-Handlers auslöste, niemals durch diesen Nichts-Code gelöscht werden würde. Der gleiche Effekt kann für den OSX-Client auftreten, bei dem das Ereignis, das beim Aufruf dieser Funktion ausgelöst wird, ebenfalls nicht gelöscht wird. Wenn diese Funktion jedoch die richtige Handler-Funktion zum Abfangen ist und Sie Ihre eigene Bibliothek so einrichten können, dass sie diese Funktion überschreibt und diese Bibliothek statt der echten geladen wird, müssen Sie zumindest die Routing-Tabelle jedes Mal zurücksetzen Mal versuchen Sie es selbst zu ändern. Wenn Sie so weit kommen, kann es sich lohnen, etwas CPU zu opfern.

Viel Glück!

1
John Wilkey

Gerade auf diesen Beitrag gestoßen. Ich dachte, ich würde meine Ergebnisse teilen.

Ich habe diesen Hack gerade unter OSX gemacht. Die von Rubio angebotene Lösung funktioniert in der Tat (und führt leider auch zu 100% CPU auf einem Core).

Ich konnte den Loader nicht dazu bringen, meine Funktion zu verwenden, da OSX LD_PRELOAD nicht verwendet und DYLD_INSERT_LIBRARIES aus irgendeinem Grund für diese Binärdatei nicht funktionierte. Wenn jemand anderes auf dieses Problem stößt, habe ich es gelöst, indem ich die ursprüngliche libvpnagentutilities.dylib-Assembly bearbeitet habe (ein Hex-Editor ist hier Ihr bester Freund).

Ersetzen Sie die ersten 6 Bytes der Funktion durch die folgenden Anweisungen, um den gleichen "return 0" -Effekt wie der oben angegebene C-Code zu erzielen:

__ZN25CInterfaceRouteMonitorMac20routeCallbackHandlerEv: 0007add0 movl $0x0, %eax  0007add5 retl

Nach mehr Funktionsaufrufverfolgung habe ich jedoch einen Weg gefunden, dies zu tun, OHNE die CPU-Auslastung zu erhöhen. Es ist eigentlich einfacher als meine Lösung oben. Es gibt ein anderes Symbol, das tatsächlich die Aufgabe hat, die Routentabelle mit dem Namen _ZN28CInterfaceRouteMonitorCommon20routeCallbackHandlerEv zu ändern. Als ich den Aufrufstack dieser Funktion nachverfolgte, fand ich die Funktion, die aufgerufen wird, um die Änderung am Offset 67c06 auszuführen.

Die Lösung? Ignorieren Sie die Änderungen, die ich zuvor aufgeführt habe, und ersetzen Sie stattdessen einfach die Aufrufanweisung bei 67c06 durch nop's !!

Hier ist das vorher:

00067c03 movl %eax, (%esp)  00067c06 calll *0x8(%ecx)  00067c09 addl $0x4, %esp

Und hier ist die endgültige Version:

00067c03 movl %eax, (%esp) 00067c06 nop 00067c07 nop 00067c08 nop 00067c09 addl $0x4, %esp

Das sollte alles sein, was Sie ändern. Ersetzen Sie die ursprüngliche vpnagentutilities.dylib durch diese modifizierte Version und genießen Sie eine Babysitter-freie Routentabelle. Die Tabelle wird zwar während der ersten Verbindung noch geändert, Sie können sie jedoch beliebig ändern.

EFF DU JEDE VERBINDUNG!

Verwandte Probleme