Адаптация vpnagentd исправления Cisco AnyConnect для OSX

Question

Я пытаюсь найти решение, позволяющее разделить туннелирование с клиентом Cisco AnyConnect для OSX. Я нашел, как он модифицирует брандмауэр, и это можно исправить. Проблема, однако, в том, что демон vpnagentd продолжает перехватывать таблицу маршрутизации.

Саша Пачев предложил элегантное решение для Linux (https://superuser.com/a/546668/568559), однако у меня возникают проблемы с его адаптацией к OSX.

Hack.c, написанный для Linux, ссылается на linux/netlink.h, которого нет в OSX. Я думаю, что это откуда AF_NETLINK .

#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;
}

Я не знаком с этим языком, поэтому я не уверен, где искать. Я вижу, как другие ссылались в первоначальном вопросе на адаптацию этого к OSX, но я не вижу результатов, опубликованных где-либо.

Кому-нибудь повезло с адаптацией этого метода к OSX? Любая помощь с благодарностью.

Как только я получу этот аспект, я буду рад поделиться с вами полным решением.

Answer 1

(Я написал расширенную версию этой функции, которая истощает данные NETLINK, следуя удивительной детективной работе Саши Пачева, выясняющей, какую функцию перехватывать. Я рад видеть, что люди нашли код полезным.)

Из другого потока я вижу, что кто-то использовал "nm", чтобы найти аналогичный обработчик обратного вызова для OSX, и вы пытаетесь создать подходящую функцию для его замены. Насколько я понимаю, OSX вообще не предоставляет интерфейс NETLINK, поэтому очень маловероятно, что версия AnyConnect для OSX сохраняет контроль над таблицей маршрутизации так же, как это делает клиент Linux. Я не знаю, какой механизм OSX обеспечивает, чтобы сигнализировать AnyConnect о том, что произошло изменение маршрутизации, но поскольку он не основан на NETLINK, код, используемый для слива сообщения netlink, неприменим.

По иронии судьбы, оригинальный стиль функции заглушки, предоставляемый Сашей, скорее всего, будет всем, что вам нужно, чтобы помешать ему заменить ваши маршруты своими собственными. Эта функция выглядела так:

int __ZN25CInterfaceRouteMonitorMac20routeCallbackHandlerEv()
{
  return 0;
}

В linux эта оригинальная функция приводила к высокому использованию процессора, поскольку событие NETLINK, которое инициировало вызов к обработчику обратного вызова, никогда не будет очищено этим бесполезным кодом. тот же эффект может произойти для клиента OSX, где любое событие, вызывающее запуск этой функции, также не очищается. Но если эта функция является правильной функцией-обработчиком для перехвата, и вы можете сделать свою собственную библиотеку для переопределения этой функции и загрузить эту библиотеку вместо реальной, по крайней мере, вы остановите ее для сброса таблицы маршрутизации каждый раз. раз вы пытаетесь изменить это самостоятельно. Если вы зайдете так далеко, возможно, стоит пожертвовать некоторым процессором.

Удачи!

Answer 2

Просто наткнулся на этот пост. Думаю, я поделюсь своими результатами.

Я только что сделал это взломать OSX. Решение, данное Rubio, действительно работает (и, к сожалению, приводит к 100% -ной загрузке ЦП на одном ядре).

Я не смог обмануть загрузчик в использовании моей функции, так как OSX не использует LD_PRELOAD и DYLD_INSERT_LIBRARIES по какой-то причине не работал для этого двоичного файла. Если кто-то еще столкнется с этой проблемой, я решил ее, отредактировав оригинальную сборку libvpnagentutilities.dylib (шестнадцатеричный редактор - ваш лучший друг здесь)

Замените первые 6 байтов функции следующими инструкциями, чтобы получить тот же эффект "возврата 0", что и код C, приведенный выше:

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

Однако после еще некоторой трассировки вызова функции я нашел способ сделать это БЕЗ увеличения загрузки ЦП. Это на самом деле проще, чем мое решение выше. Есть еще один символ, которому фактически делегирована задача изменения таблицы маршрутов, называемая _ZN28CInterfaceRouteMonitorCommon20routeCallbackHandlerEv. Прослеживая стек вызовов этой функции, я нашел функцию, которую она вызывает, чтобы произвести изменение по смещению 67c06.

Решение? Игнорируйте изменения, которые я перечислил ранее, и вместо этого просто замените инструкцию вызова в 67c06 на nop!

Вот прежде:

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

И вот окончательный вариант:

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

Это должно быть все, что вы измените. Замените оригинальный vpnagentutilities.dylib этой модифицированной версией и наслаждайтесь таблицей маршрутов без няни. Он по-прежнему будет изменять таблицу во время первоначального подключения, но тогда вы можете изменить ее, как считаете нужным.

EFF ВЫ ВСЕ НЕ СОЕДИНЯЕТЕ!