Как я недавно обнаружил эту бумагу , описывающую механизм сниффинга для iOS с использованием расширения Apple NEPacketTunnelProvider , мне стало любопытно, и мне захотелось понять его с технической точки зрения:Посмотреть.Поскольку я обычно не работаю на таком глубоком сетевом уровне, я не могу понять его в деталях, которые мне бы хотелось.Поскольку Charles Proxy для iOS должен делать что-то очень похожее, не требуя контролируемых устройств, я предполагаю, что подход, который автор статьи, представленной в 2016 году, может все еще работать в настоящее время.
Автор утверждал, что«Все, что связано с разбором IP-пакета, созданием IP-пакета или анализом ответа DNS, должно было быть реализовано самим».Поскольку я хочу полностью понять это, я попытался построить это сам.Я строю NetworkExtension и цикл сообщений для packetFlow из NEPacketTunnelProvider.Мне удалось получить датаграммы ip и попытаться разобрать их.Я использовал целые числа без знака соответствующего размера для исходного и целевого ip, транспортного протокола и версии ip, но я не уверен, как обрабатывать полезную нагрузку.Мой парсер использует ptr.load(fromByteOffset: <offset>, as:<DataType>.self), где ptr - это UnsafeRawPointer для доступа к информации о потоке пакетов.Поскольку data может превышать хранилище UInt64, я не знаю, как правильно получить доступ и сохранить полезную нагрузку.
Кроме того, я решил, что исходный IP-адрес всегда равен 192.168.20.1(устанавливается как NEIPv4Settings адрес моего интерфейса), и мой целевой ip всегда 192.168.2.1 (мой фиктивный NEDNSSettings сервер).Это приводит меня к моим первым вопросам: это DNS-запросы?Будет ли пакет дейтаграмм запрашивать какую-либо дополнительную информацию о фактической цели?Значит ли это, что мне нужно каким-то образом выполнить запрос к DNS-серверу и перенаправить пакет к цели, которую я получу из этого DNS-запроса?
Следующим шагом будет реализация обработки TCP / UDP,право?Мой нынешний подход к анализу позволяет различать UDP, TCP и ICMP (хотя я еще не исследовал в последнем).Поэтому я бы перебрал дейтаграммы и посмотрел, требуют ли они сеанса / соединения UPD или TCP, и передал бы дейтаграмму.Проблема, с которой я в настоящее время вижу их с концептуальной точки зрения: как узнать, какой порт источника / назначения использовать для соединений / сеансов TCP / UPD?Насколько я знаю, эта информация не является частью самого IP-пакета (поскольку это скорее некоторая информация, которая нам нужна на уровне транспортного уровня, а не на уровне сетевого уровня).
Кроме того, я нашел проект под названием Specht на github.Он использует самописную библиотеку под названием NEKit , которая также использует подход NEPacketTunnelProvider.Когда я правильно понимаю их подход, им удалось каким-то образом построить локальный прокси-сервер, написав некоторые механизмы наблюдения для обработки запросов, но, поскольку я относительно новичок в работе в сети и быстром, я не уверен, полностью ли я это понимаюисправить или я просто не нашел все эти TCP / UDP и / или DNS логики.Этот проект сопоставим с подходом прокси-сервера paper and charles?
Последний вопрос: прокси-сервер Charles в большинстве случаев может показывать имя хоста цели.В настоящее время я просто могу видеть IP-адреса назначения (которые являются не реальными IP-адресами назначения, а адресом моего DNS-сервера).Как я могу видеть имя хоста как читабельный текст?Чарльз делает nslookup как-то?Чарльз получает эту информацию из дейтаграмм?
Я знаю, что это довольно амбициозно с моей стороны, поскольку у меня недостаточно знаний в этой теме, чтобы создать нечто похожее по тестовым причинам, но у меня все еще есть мотивация углубиться в эту тему, и у меня также есть ощущение, что я уже поняла некоторые ключевые моменты.очков, но, к сожалению, недостаточно, чтобы решить головоломку ... Может быть, вы сможете дать мне еще несколько советов, чтобы лучше понять.Если бы мог быть даже более простой способ заархивировать подобное поведение (чтобы увидеть исходящие соединения на уровне имени хоста), я бы также заинтересовался этим: -)