Анализ\Блокировка\Редактирование трафика определенного процесса

@siriusED · Регистрация: 20.05.2010

Студворк — интернет-сервис помощи студентам

Привет. Появилась идея написать что-то аля сниффера который умел бы перехватывать траффик по фильтрам (srsIP\dstIP\PID).
Будет возможность создавать список правил. И если процесс пытается соединится с сервером который в правилах определен как заблокированный - то процесс просто драпал это соединение.
Ну и как бонус еще может редактирование пакетов на лету по шаблону и пересылка от приложения к серверу и от серверу к приложению.

Короче нужно функционал почти идентичный Charles proxy но с возможностью перехвата пакетов уровня Ethernet, как делает WireShark, например.

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

Есть может быть у кого какие идеи\готовые Open Source решения, или хотя бы примеры? Был бы благодарен за любую инфу по теме. Пока что буду сам пытаться гуглить само собой.

@siriusED · 28.03.2024, 04:40 **[ТС]**

Ну что, из собранных мною примеров реализаций из всех статей и гита, за 2 дня работы удалось собрать единый софт который уже умеет редиректить траффик с заданного процесса Socks5 Server, Пока что все работает в режиме консоли и без особых сверх возможностей, но пока что на этом все

Но думаю это самое важное что нужно было сделать, дальше буду продолжать работать над дропом пакетов, изменении пейлоадов итд. Примеров по TLS через этот драйвер я не нашел, но в паре статей упоминалось что там, вроде как, можно реализовать МИТМ. Но пока что хочу дописать что-то адекватное сначала а уже потом буду дополнять

Так что пока что вот как то так. Если что будет еще интересного напишу.

Добавлено через 3 часа 24 минуты
И еще может быть кто знает на чем бы потестировать TCP, может быть какие мини онлайн игры есть или чаты или какие сервисы что бы без соединение было без шифрований упаковок итд именно созданных для тестирования или обучающих целей, если кто вкурсе таких проектов подскажите

@Undisputed · 28.03.2024, 10:07

Сообщение от siriusED

Примеров по TLS через этот драйвер я не нашел, но в паре статей упоминалось что там, вроде как, можно реализовать МИТМ

То что можно реализовать MITM в драйвере еще не значит, что вы сможете расшифровать TLS. MITM это необязательно "быть посередине TLS и уметь его прочесть". Когда слушаете незашифрованный трафик, это тоже MITM. Трафик попадает в драйвер после того как приложение его отправит. А шифрующие приложения сначала шифруют данные, и только потом их отправляют. Следовательно, вы будете видеть одни кракозябры.

Сообщение от siriusED

И еще может быть кто знает на чем бы потестировать TCP

Например http://example.com. Отправьте GET запрос, только не добавляйте заголовок "Accept-Encoding", иначе возвращаемый ответ будет сжатым.

@siriusED · 02.04.2024, 23:39 **[ТС]**

Так, я тут не много отсутствовал, но счас вернулся и вот пытаюсь что-то покодить но получается че-то не особо. Сделал я редирект траффика с процесса на мой SOCK5 локальный сервер (Написан на С#). Но сколько я понял схему то Мой драйвер перенаправляет траффик с приложения на мой локальный сервер на котором два сокета один клиент второй сервер, и моя идея была в том что бы иметь возможность отправлять пакеты на сервер через сокет который "держит" соединение с сервером (TCP). Простой редирект траффика через мой прокси работает нормально, но вот сейчас хочу как то спарсить пакеты что б воспроизвести траффик уже визуально и че то не получается...

Пробою, сейчас, парсить пакет через хорошую библиотекуPacketDotNet. У нее есть метод

C#
1
var packet = Packet.ParsePacket(LinkLayers.Ethernet, e.Buffer);

Он парсит Езернет пакет, а вот когда с него я пытаюсь получить IPPacket то получаю null

C#
1
var ipPacket = packet.Extract<IPPacket>();

Это проблемы библиотеки или я что-то не так понял? Я же могу читать IP пакеты на траффике проходящем через SOCK5 или нет? Уже часа три сижу и че-то ничего не могу допереть, очень давно уже с SOCK5 работал...

Подскажите в чем может быть проблема.

@Annemesski · 03.04.2024, 09:06

siriusED, протокол Ethernet не работает с IP-адресами, там только MAC, чтобы получить IP надо парсить пакет на транспортном уровне, то есть должно быть что-то типа

C#
1
2
var packet = Packet.ParsePacket(LinkLayers.TCP, e.Buffer);
var ipPacket = packet.Extract<IPPacket>();

@Undisputed · 03.04.2024, 13:02

siriusED,
Как-то сумбурно описали ваши мысли.

1) У вас должен быть прокси сервер, который принимает входящие соединения
2) Должен быть драйвер, который будет выполнять проксирование нужного соединения в прокси сервер
3) Драйвер помимо выполнения проксирования соединения, так же должен предоставлять айпи и порт целевого сервера
4) Прокси сервер должен установить соединение с целевым сервером по айпи и порту, которые драйвер предоставил как целевые
5) Прокси сервер должен забрать информацию от целевого сервера и передать её в соединение, которое было установлено в п.2

Это упрощенно. Еще нужно будет учесть нюансы с TLS.

Добавлено через 3 минуты
И да, работа с Ethernet вам здесь не нужна, так что вы двигаетесь в ошибочном направлении

@siriusED · 03.04.2024, 19:40 **[ТС]**

Undisputed, Ну сейчас у меня, как я и писал выше, работает перенаправление траффика з процесса на мой локальный прокси сервер, и для примера если я выбираю процесс браузера `firefox` то траффик проходит через мой прокси сервер локальный и в браузере я открываю сайт и все работает, значит траффик через прокси сервер идет, проблема только в том что я не совсем понимаю как мне данные спарсить именно с пакетов которые проходят через этот прокси сервер. прокси Socks5, на сокетах все стандартно в принципе. В моем понимании прокси сервер просто должен был принимать пакет на одном конце и передавать его на заданный сервер и этот пакет просто и легко должен был парсится на ивентах сокетов OnReceive, неужели и тут все сложно и надо и здесь изучать?

Сообщение от Undisputed

И да, работа с Ethernet вам здесь не нужна, так что вы двигаетесь в ошибочном направлении

Да не нужен мне Ethernet как таковой, просто я думал та библиотека которую я пытался использовать умеет парсить пакет как Ethernet а уже с него можно получить все другие протоколы выше по стеку. Но почему-то она не может этого сделать, по докам при парсинге Ethernet пакета в нем должно быть свойство PacketDotNet.Packet PayloadPacket { get; } но как бы я не пробовал там всегда null.
Но при этом когда я паршу массив байт который я взял с другого сниффера который на рав сокетах работает то тогда все нормально парсится например вот пакет какой-то:

C#
1
2
3
4
5
6
string IPHex = "45000028099f400080060498c0a80167.....";
var ipBytes = StringToBytes(IPHex);
var packetRaw = Packet.ParsePacket(LinkLayers.Raw, ipBytes);
var ipPacket = packetRaw.Extract<IPPacket>();
 
Console.WriteLine(ipPacket.DestinationAddress); // Все есть и все парсится как надо

Может прокси сервер что-то как то шифрует или что-то еще? В принципе можно попробовать другой прокси что ли... Ну либо же библиотека не умеет парсить IP пакеты, короче что-то тут где-то криво я чувствую...

Добавлено через 12 минут
Пока что немного посниферил пакеты итд выяснил что походу c# сокет в колбеке передает только данные из TCP пакета, вот пример одного и того же пакета (простой GET запрос из браузера), первый это целый IPPacket а второй это то, что я вижу в буфуре сокета

C#
1
2
3
4
5
6
7
private int _packetSize = 4096;
private byte[] _buffer;
public Socket Sock { get; set; }
 
// ...
 
Sock.BeginReceive(_buffer, 0, _buffer.Length, SocketFlags.None, DataReceived, Sock);

Code
1
2
3
45 00 01 8A 73 73 40 00 80 06 00 00 7F 00 00 01 7F 00 00 01 E2 5D 11 5C 69 BE 7B FF 95 05 6B A6 50 18 27 F9 13 39 00 00 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A 48 6F 73 74 3A 20 77 77 77 2E 74 65 73 74 69 6E 67 6D 63 61 66 65 65 73 69 74 65 73 2E 63 6F 6D 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73 20 4E 54 20 31 30 2E 30 3B 20 72 76 3A 38 38 2E 30 29 20 47 65 63 6B 6F 2F 32 30 31 30 30 31 30 31 20 46 69 72 65 66 6F 78 2F 38 38 2E 30 0D 0A 41 63 63 65 70 74 3A 20 74 65 78 74 2F 68 74 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 6D 6C 3B 71 3D 30 2E 39 2C 69 6D 61 67 65 2F 61 76 69 66 2C 69 6D 61 67 65 2F 77 65 62 70 2C 2A 2F 2A 3B 71 3D 30 2E 38 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 75 61 67 65 3A 20 65 6E 2D 55 53 2C 65 6E 3B 71 3D 30 2E 35 0D 0A 41 63 63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 20 64 65 66 6C 61 74 65 0D 0A 44 4E 54 3A 20 31 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A 55 70 67 72 61 64 65 2D 49 6E 73 65 63 75 72 65 2D 52 65 71 75 65 73 74 73 3A 20 31 0D 0A 0D 0A
---------------------------
47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A 48 6F 73 74 3A 20 77 77 77 2E 74 65 73 74 69 6E 67 6D 63 61 66 65 65 73 69 74 65 73 2E 63 6F 6D 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73 20 4E 54 20 31 30 2E 30 3B 20 72 76 3A 38 38 2E 30 29 20 47 65 63 6B 6F 2F 32 30 31 30 30 31 30 31 20 46 69 72 65 66 6F 78 2F 38 38 2E 30 0D 0A 41 63 63 65 70 74 3A 20 74 65 78 74 2F 68 74 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 68 74 6D 6C 2B 78 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 6D 6C 3B 71 3D 30 2E 39 2C 69 6D 61 67 65 2F 61 76 69 66 2C 69 6D 61 67 65 2F 77 65 62 70 2C 2A 2F 2A 3B 71 3D 30 2E 38 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 75 61 67 65 3A 20 65 6E 2D 55 53 2C 65 6E 3B 71 3D 30 2E 35 0D 0A 41 63 63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 20 64 65 66 6C 61 74 65 0D 0A 44 4E 54 3A 20 31 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A 55 70 67 72 61 64 65 2D 49 6E 73 65 63 75 72 65 2D 52 65 71 75 65 73 74 73 3A 20 31 0D 0A 0D 0A

@Undisputed · 03.04.2024, 20:43

Сообщение от siriusED

Ну сейчас у меня, как я и писал выше, работает перенаправление траффика з процесса на мой локальный прокси сервер, и для примера если я выбираю процесс браузера `firefox` то траффик проходит через мой прокси сервер локальный и в браузере я открываю сайт и все работает, значит траффик через прокси сервер идет, проблема только в том что я не совсем понимаю как мне данные спарсить именно с пакетов которые проходят через этот прокси сервер

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

Неплохо было бы еще уточнить, какие именно данные вас интересует. Что конкретно хотите спарсить? Какие данные хотите получить? Айпи адрес и/или порт назначения, тело запроса/ответа, может заголовки http? Что именно надо?

Добавлено через 4 минуты

Сообщение от siriusED

Может прокси сервер что-то как то шифрует или что-то еще?

Прокси может шифровать, если используется TLS.

@siriusED · 05.04.2024, 02:30 **[ТС]**

Undisputed, Короче с прокси сервером оказалось все не проще чем с драйвером

Все что я думал я понимаю я сейчас уже перестал так думать

Одним словом сижу изучаю все по прокси серверам пока что. А тот сервер что я нашел оказалось шифровал траффик между клиентом и локальным ендпоинтом прокси. И плюс как оказалось он совершенно не поддерживал UDP, а UDP мне так же нужно и там с этим все не так просто ибо мне нужен прокси который сможет пакеты обрабатывать в синхронном режиме для того что бы я потом смог реализовать что-то типа дебага где пакеты приходят по одному и я их либо принимаю либо отклоняю при чем в обе стороны.

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

А на счет данных то они были но были на уровне TCP а я хотел IP, пока что не уверен что во още можно парсить IP пакеты через прокси на сокетах, а даже если и как то можно, тогда мне скорей всего, придется либо костылить либо самому заголовки собирать, а это уже лютый оверхед, так что пока что, мне в принципе, хватит и уровня TCP\UDP. Для начала нужно реализовать прокси который бы умел делать все что мне надо и успешно передавать данные для обеих протоколов TCP и UDP. (Даже тестеры для этого уже нашел

)

Одним словом пока что изучаю доки по прокси серверам и как это во обще работает, сложно конечно, но зато хоть буду понимать что во обще происходит и почему если что-то нужно будет подправить потом

@siriusED · 09.04.2024, 12:52 **[ТС]**

Undisputed, Во общем нашел один прокси сервер на гите, но он был только с поддержкой TCP, изучил протоколы и все остальное и дописал вроде как работающую поддержку UDP, уже прикрутил его к своему софту, теперь драйвер редиректит траффик на мой прокси и на нем сделал ивент на получение пакета и туда передаю пакет при получении (Клиент\Сервер) и жду действий от пользователя и потом передаю пакет клиенту, в принципе работает нормально, вчера тестировал и уже могу симулировать рандомную задержку пакетов, либо менять данные пакетов на лету по правилу(пока что только http тестировал), но вот как правильно сделать потерю пакетов че-то не могу понять...
В описанной выше модели когда а получаю ответ от пользователя что пакет нужно "дропнуть", то есть не отправлять клиенту а просто пропустить, вместо отправки пакета клиенту, я пробовал просто начать получение новых данных от сервера, но на сколько я понял, сервер как буд-то ждет подтверждения доставки по какому-то заданному таймауту и только потом отправляет новый пакет, по TCP я знаю что там есть механизм гарантирования доставки, но все равно ждать по таймауту - это как то долго, а нету варианта как то проинформировать сервер что пакет потерян и нужно что бы эту ситуацию обработал сам сервер по его правилам и настройкам, может быть Вы как это правильно делается?

@Undisputed · 09.04.2024, 15:29

Сообщение от siriusED

сервер как буд-то ждет подтверждения доставки

В этой схеме должно быть два сервера
1) прокси-сервер
2) целевой сервер, который запросил пользователь
О каком именно сервере идет речь?

Сообщение от siriusED

менять данные пакетов на лету по правилу(пока что только http тестировал), но вот как правильно сделать потерю пакетов че-то не могу понять

Исходя из этого сообщения я так понимаю речь идет о том что бы дропнуть часть данных HTTP. Если так, то в таком случае нельзя просто дропнуть данные. Например, если прокси сервер уже передал клиенту заголовок Content-Length, то "дропание пакета" будет означать, что клиент получит меньшее количество данных, чем ему было заявлено в Content-Length. Следовательно, клиент (например браузер), может оставаться в режиме ожидания, пока не придут все заявленные данные, либо отвалится по истечению некоторого таймаута.

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

@siriusED · 09.04.2024, 16:48 **[ТС]**

Undisputed, Нет, я сейчас говорю о потере целого TCP пакета, вот схема:
-На прикси сервер прилетает запрос от клиента
-Прокси сервер коннектится к удаленному серверу и перенаправляет запрос от клиента на этот удаленный сервер
-Удаленный сервер отсылает пакет обратно на прокси сервер
-Прокси сервер вместо перенаправления этого пакета на клиента просто "дропает" игнорирует этот пакет
- И вот дальше мне не совсем понятно...

Сейчас у меня сделано так: Дальше вместо отправки пакета клиенту я просто встаю на чтение данных от удаленного сервера, и у меня просто все висит в состоянии ожидания, потому что и сервер пакет отправил прокси серверу у него все ок и он просто ждет дальнейших указаний, и в это же время клиент ждет пакета от прокси сервера, и так же в состоянии ожидания. То это это и есть реальная потеря пакета вот так вот оба сидят и ждут и все? А как ни будь проинформировать клиент или удаленный сервер что пакет потерян и что бы они сами обрабатывали эту ситуацию как у них написано в коде, нельзя ни как?
Или например если на самом деле, на каком то узле сети глюканет роутер или маршрутизатор и пакет реально потеряется без симуляций, тогда клиент так же будет ждать какое-то время пока пакет не прийдет или что?

И сразу уточню что я хочу понять именно как все работает в реальности что бы сделать аналогичную симуляцию а не черт пойми что которое ничего общего с реальностью не имеет и потом этим пользоваться и тестировать на нем

@Undisputed · 09.04.2024, 17:32

Сообщение от siriusED

вот схема

Какой протокол используете для обращения к целевому серверу? Судя по сообщению выше, вы используете HTTP. В таком случае мне не совсем понятно, почему вы говорите

Сообщение от siriusED

Нет, я сейчас говорю о потере целого TCP пакета, вот схема

... как нет? Схема которую вы описали соответствует тому о чем я говорил.

Сообщение от siriusED

И вот дальше мне не совсем понятно

Дальше нужно соответствовать ожиданиям всех сторон-участников.

Сообщение от Undisputed

В целом следует учитывать ожидания каждого участника схемы что бы обеспечить правильную работу всей системы

Пример с Content-Length был дан выше.

Сообщение от siriusED

То это это и есть реальная потеря пакета вот так вот оба сидят и ждут и все? А как ни будь проинформировать клиент или удаленный сервер что пакет потерян и что бы они сами обрабатывали эту ситуацию как у них написано в коде, нельзя ни как?

Вы должны действовать согласно используемому протоколу. Если ждут, то значит что-то обещали им в рамках протокола, вот они и ждут обещанного. Опять же, возвращаю вас к примеру с Content-Length. Всё что вы можете сделать, это отправить то или иное сообщение в рамках используемого протокола или просто закрыть соединение.

Сообщение от siriusED

я хочу понять именно как все работает в реальности

В реальности зависит от требований, вот возможные варианты
1) отбросив данные получателя не жалуетесь на то, что получатель продолжает ждать этих данных
2) по используемому протоколу отправляете получателю сообщение, которое должно привести к требуемому исходу
3) просто закрываете соединение (с получателем и/или целевым сервером)

@siriusED · 11.04.2024, 01:20 **[ТС]**

Undisputed, Выходит все упирается в протокол общения клиента с сервером, другими словами если в правилах их протокола на стороне клиента написано ждать 10 часов пакета от сервера после запроса то клиент будет ждать 10 часов, и единственный вариант как это ускорить это отправить "фейковый" пакет, либо пустой пакет. Где то так примерно да?
Выходит реальная потеря пакета это и есть простое игнорирование (неотправка) клиенту\серверу пакета, а что будет после этого это зависит только от протокола, тогда я в принципе могу использовать простое игнорирование пакета и это будет реальная симуляция потери пакета, все верно я понял?

@Undisputed · 11.04.2024, 09:02

Сообщение от siriusED

Выходит все упирается в протокол общения клиента с сервером, другими словами если в правилах их протокола на стороне клиента написано ждать 10 часов пакета от сервера после запроса то клиент будет ждать 10 часов, и единственный вариант как это ускорить это отправить "фейковый" пакет, либо пустой пакет. Где то так примерно да?

Немного сумбурно расписали. Попробую внести некоторую ясность. В целом да, основу коммуникации составляет протокол общения клиента с сервером но могут быть нюансы, выходящие за пределы протокола. Например, таймаут. Допустим клиент может отключиться если он перестанет получать данные в течении N секунд и это время ожидания необязательно должно являться частью протокола.

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

Сообщение от siriusED

Выходит реальная потеря пакета это и есть простое игнорирование (неотправка) клиенту\серверу пакета, а что будет после этого это зависит только от протокола

В целом да. Но как уже говорил выше, дальнейшее развитие событий может так же зависеть не только от протокола, но и еще от различных настроек каждого участника коммуникации (например, от таймаута, который задан на стороне клиента и/или сервера)

Сообщение от siriusED

тогда я в принципе могу использовать простое игнорирование пакета и это будет реальная симуляция потери пакета, все верно я понял?

Да

@siriusED · 16.04.2024, 02:22 **[ТС]**

Undisputed, Понял, ну тогда ок, тогда все что нужно есть, дальше уже буду кодить логику и верстать UI.

@siriusED · 16.09.2024, 00:31 **[ТС]**

Много времени прошло... И как всегда и получается все что я хотел реализовать все было не правильно криво и тупо

Даже не хочу думать сколько инфы и книг я прочитал за это время... Сейчас изучаю "С" и "kernel programming". Пока что реализовал(почти, остались стримы и фрагментация пакетов) свой кастомный API к опенсорсному Wireshark, вернее к его диссекторному движку, сейчас работаю над написанием очень хитрого драйвера что бы иметь возможность делать очень интересные вещи в области трафика и иметь широкий выбор опций по фильтрации и управлению. Одним словом как будет что нить хоть как то рабочее - отпишусь о результатах. Пока что читаю, изучаю, думаю и пишу код...
P.S. Странное дело, на таком уровне я куда больше читаю и думаю чем пишу код

Тема оказалась очень не простой...

Новые блоги и статьи Все статьи Все блоги /
Эксперимент с картинкой-обложкой на CodinGame Adler 10.07.2026 Решил на днях провести эксперимент. У меня есть аккаунт на CodinGame, ТОП-3 по РФ среди 2200 участников (в разделе соревнования по программированию ИИ-ботов). Там есть обложка, куда можно влепить. . .	После бана на Пикабу не работает авторизация аккаунта с Яндекса. Hrethgir 09.07.2026 В частности https:/ / auto. ru/ logbook/ zapret-na-vozhdenie-posle-65-let_1cf28789-07b4-4c75-a2f7-4cd4edf9deeb тут хотел оставить комментарий такой Зрите в корень - монополизация на разработку программ. . .	GitDOS: Когда я решил скрестить MS-DOS, GitHub и Claude MaGz GoLd 08.07.2026 Привет, Киберфорум! Хочу поделиться своим проектом, который, надеюсь, вас заинтересует. GitDOS — это веб-приложение, которое позволяет запускать DOS в браузере с тремя крутыми фичами: диски живут в. . .	Учебный мини "цифровой двойник" = (Сервер = Java + Flask_питон )+(3D = Гугловскаая 4T nvideo + google colab) +( WMS = Odoo на Docker) anaschu 07.07.2026 Увидел в требованиях к вакансии создателя имитационных моделей связку (REst + Api + WMS + Anylogic + питон + 3D Nvideo), и решил посмотреть, что это такое. Из этого всего я работал более менее. . .
Море в объективе kumehtar 06.07.2026 Хотел написать много проникновенных слов, но передумал. Оно само - говорит. Кто слышит тот слышит.	Doom для терминала без стрельбы и монстров. 3D Raycasting на ascii. dcc0 05.07.2026 Попросил нейронную сеть deepai. org написать рейкастинг 3D с библиотекой ncurses для Linux. Чтобы можно было ходить на стрелочки. Чтобы стены были отрисованы символами. Справилась. Первый вариант. . .	Установка статуса документа по условию Maks 05.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "НарядПутевка" разработанного в КА2. Задача: в табличной части "Материалы" документа при записи автоматически устанавливать статус. . .	Сезонность и суточность закисления почв anaschu 04.07.2026 200 часов это все равно моловато. Есть ситуации, но нестандартные, когда смена происходит за 5 лет. Но обычно это 50 лет и более. Наверное, закисление почвы происходит сезонно в средней. . .

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705

	Анализ\Блокировка\Редактирование трафика определенного процесса 21.03.2024, 07:40. Показов 32685. Ответов 35 Метки нет (Все метки) Привет. Появилась идея написать что-то аля сниффера который умел бы перехватывать траффик по фильтрам (srsIP\dstIP\PID). Будет возможность создавать список правил. И если процесс пытается соединится с сервером который в правилах определен как заблокированный - то процесс просто драпал это соединение. Ну и как бонус еще может редактирование пакетов на лету по шаблону и пересылка от приложения к серверу и от серверу к приложению. Короче нужно функционал почти идентичный Charles proxy но с возможностью перехвата пакетов уровня Ethernet, как делает WireShark, например. Пока что почитал, погуглил и вроде как перехват трафика реализовать не очень сложно, просто через драйвер NpCap, а вот редактирование пакетов и пересылка в обе стороны я пока что даже не понимаю как это можно сделать... Пока что только одна идея - Прокси, но тут проблема что трафик нужно как то перенаправлять с процесса на этот прокси, а сторонний софт использовать не хочу. Есть может быть у кого какие идеи\готовые Open Source решения, или хотя бы примеры? Был бы благодарен за любую инфу по теме. Пока что буду сам пытаться гуглить само собой. 0

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705
	28.03.2024, 04:40 [ТС]
	Ну что, из собранных мною примеров реализаций из всех статей и гита, за 2 дня работы удалось собрать единый софт который уже умеет редиректить траффик с заданного процесса Socks5 Server, Пока что все работает в режиме консоли и без особых сверх возможностей, но пока что на этом все Но думаю это самое важное что нужно было сделать, дальше буду продолжать работать над дропом пакетов, изменении пейлоадов итд. Примеров по TLS через этот драйвер я не нашел, но в паре статей упоминалось что там, вроде как, можно реализовать МИТМ. Но пока что хочу дописать что-то адекватное сначала а уже потом буду дополнять Так что пока что вот как то так. Если что будет еще интересного напишу. Добавлено через 3 часа 24 минуты И еще может быть кто знает на чем бы потестировать TCP, может быть какие мини онлайн игры есть или чаты или какие сервисы что бы без соединение было без шифрований упаковок итд именно созданных для тестирования или обучающих целей, если кто вкурсе таких проектов подскажите 0

@Undisputed 901 / 478 / 93 Регистрация: 10.06.2014 Сообщений: 2,700
	03.04.2024, 13:02
	siriusED, Как-то сумбурно описали ваши мысли. 1) У вас должен быть прокси сервер, который принимает входящие соединения 2) Должен быть драйвер, который будет выполнять проксирование нужного соединения в прокси сервер 3) Драйвер помимо выполнения проксирования соединения, так же должен предоставлять айпи и порт целевого сервера 4) Прокси сервер должен установить соединение с целевым сервером по айпи и порту, которые драйвер предоставил как целевые 5) Прокси сервер должен забрать информацию от целевого сервера и передать её в соединение, которое было установлено в п.2 Это упрощенно. Еще нужно будет учесть нюансы с TLS. Добавлено через 3 минуты И да, работа с Ethernet вам здесь не нужна, так что вы двигаетесь в ошибочном направлении 0

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705
	05.04.2024, 02:30 [ТС]
	Undisputed, Короче с прокси сервером оказалось все не проще чем с драйвером Все что я думал я понимаю я сейчас уже перестал так думать Одним словом сижу изучаю все по прокси серверам пока что. А тот сервер что я нашел оказалось шифровал траффик между клиентом и локальным ендпоинтом прокси. И плюс как оказалось он совершенно не поддерживал UDP, а UDP мне так же нужно и там с этим все не так просто ибо мне нужен прокси который сможет пакеты обрабатывать в синхронном режиме для того что бы я потом смог реализовать что-то типа дебага где пакеты приходят по одному и я их либо принимаю либо отклоняю при чем в обе стороны. Короче я уже понял что с прокси сервером придется провозится дольше чем с драйвером и редиректами адресов, и что-то мне подсказывает что придется писать во обще все самому... А на счет данных то они были но были на уровне TCP а я хотел IP, пока что не уверен что во още можно парсить IP пакеты через прокси на сокетах, а даже если и как то можно, тогда мне скорей всего, придется либо костылить либо самому заголовки собирать, а это уже лютый оверхед, так что пока что, мне в принципе, хватит и уровня TCP\UDP. Для начала нужно реализовать прокси который бы умел делать все что мне надо и успешно передавать данные для обеих протоколов TCP и UDP. (Даже тестеры для этого уже нашел ) Одним словом пока что изучаю доки по прокси серверам и как это во обще работает, сложно конечно, но зато хоть буду понимать что во обще происходит и почему если что-то нужно будет подправить потом 0

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705
	09.04.2024, 12:52 [ТС]
	Undisputed, Во общем нашел один прокси сервер на гите, но он был только с поддержкой TCP, изучил протоколы и все остальное и дописал вроде как работающую поддержку UDP, уже прикрутил его к своему софту, теперь драйвер редиректит траффик на мой прокси и на нем сделал ивент на получение пакета и туда передаю пакет при получении (Клиент\Сервер) и жду действий от пользователя и потом передаю пакет клиенту, в принципе работает нормально, вчера тестировал и уже могу симулировать рандомную задержку пакетов, либо менять данные пакетов на лету по правилу(пока что только http тестировал), но вот как правильно сделать потерю пакетов че-то не могу понять... В описанной выше модели когда а получаю ответ от пользователя что пакет нужно "дропнуть", то есть не отправлять клиенту а просто пропустить, вместо отправки пакета клиенту, я пробовал просто начать получение новых данных от сервера, но на сколько я понял, сервер как буд-то ждет подтверждения доставки по какому-то заданному таймауту и только потом отправляет новый пакет, по TCP я знаю что там есть механизм гарантирования доставки, но все равно ждать по таймауту - это как то долго, а нету варианта как то проинформировать сервер что пакет потерян и нужно что бы эту ситуацию обработал сам сервер по его правилам и настройкам, может быть Вы как это правильно делается? 0

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705
	09.04.2024, 16:48 [ТС]
	Undisputed, Нет, я сейчас говорю о потере целого TCP пакета, вот схема: -На прикси сервер прилетает запрос от клиента -Прокси сервер коннектится к удаленному серверу и перенаправляет запрос от клиента на этот удаленный сервер -Удаленный сервер отсылает пакет обратно на прокси сервер -Прокси сервер вместо перенаправления этого пакета на клиента просто "дропает" игнорирует этот пакет - И вот дальше мне не совсем понятно... Сейчас у меня сделано так: Дальше вместо отправки пакета клиенту я просто встаю на чтение данных от удаленного сервера, и у меня просто все висит в состоянии ожидания, потому что и сервер пакет отправил прокси серверу у него все ок и он просто ждет дальнейших указаний, и в это же время клиент ждет пакета от прокси сервера, и так же в состоянии ожидания. То это это и есть реальная потеря пакета вот так вот оба сидят и ждут и все? А как ни будь проинформировать клиент или удаленный сервер что пакет потерян и что бы они сами обрабатывали эту ситуацию как у них написано в коде, нельзя ни как? Или например если на самом деле, на каком то узле сети глюканет роутер или маршрутизатор и пакет реально потеряется без симуляций, тогда клиент так же будет ждать какое-то время пока пакет не прийдет или что? И сразу уточню что я хочу понять именно как все работает в реальности что бы сделать аналогичную симуляцию а не черт пойми что которое ничего общего с реальностью не имеет и потом этим пользоваться и тестировать на нем 0

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705
	11.04.2024, 01:20 [ТС]
	Undisputed, Выходит все упирается в протокол общения клиента с сервером, другими словами если в правилах их протокола на стороне клиента написано ждать 10 часов пакета от сервера после запроса то клиент будет ждать 10 часов, и единственный вариант как это ускорить это отправить "фейковый" пакет, либо пустой пакет. Где то так примерно да? Выходит реальная потеря пакета это и есть простое игнорирование (неотправка) клиенту\серверу пакета, а что будет после этого это зависит только от протокола, тогда я в принципе могу использовать простое игнорирование пакета и это будет реальная симуляция потери пакета, все верно я понял? 0

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705
	16.04.2024, 02:22 [ТС]
	Undisputed, Понял, ну тогда ок, тогда все что нужно есть, дальше уже буду кодить логику и верстать UI. 0

@siriusED 32 / 31 / 13 Регистрация: 20.05.2010 Сообщений: 705
	16.09.2024, 00:31 [ТС]
	Много времени прошло... И как всегда и получается все что я хотел реализовать все было не правильно криво и тупо Даже не хочу думать сколько инфы и книг я прочитал за это время... Сейчас изучаю "С" и "kernel programming". Пока что реализовал(почти, остались стримы и фрагментация пакетов) свой кастомный API к опенсорсному Wireshark, вернее к его диссекторному движку, сейчас работаю над написанием очень хитрого драйвера что бы иметь возможность делать очень интересные вещи в области трафика и иметь широкий выбор опций по фильтрации и управлению. Одним словом как будет что нить хоть как то рабочее - отпишусь о результатах. Пока что читаю, изучаю, думаю и пишу код... P.S. Странное дело, на таком уровне я куда больше читаю и думаю чем пишу код Тема оказалась очень не простой... 0