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

Я задался целью найти в программе функцию, которая дешифрует трафик и скопировать её в свою программу.
Дезасемблировал программу и нашёл все ссылки на импортируемую функцию recv, которая читает данные из сокета. К сожалению, ничего интересного не нашлось.
1. Функция считывает из сокета 1 байт - ссылок на неё в программе нет.
2. Функция считывает из сокета заданное число байт - ссылок на неё тоже нет.
3. Функция создаёт соединение, что-то отправляет, что-то получает в ответ и тут же закрывает соединение и разрушает сокет.
4. Оконная процедура, которая обрабатывает сообщения сокета. Считывает в стек все данные из сокета и ничего с ними не делает. Это, как мне кажется, наиболее интересное из всего, что удалось найти.

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

Собственно, хочу получить от специалистов совет - в какую сторону дальше копать. Заранее благодарю за помощь.

| Сообщение посчитали полезным:

а сервер у тебя есть?
кроме recv существует еще recvfrom

| Сообщение посчитали полезным:

Нет, сервер удалённый.
resvfrom смотрел. Не используется.

| Сообщение посчитали полезным:

У программы нет dll\sys?
В ресурсы посмотри, возможно там в ресурсах есть dll, которая сохраняется на диск во время выполнения программы.

| Сообщение посчитали полезным:

SCRTR пишет:
нашёл все ссылки на импортируемую функцию recv
Обычно ставить бряк предпочтительней не на все ссылки, а сразу на экспортируемую функцию в библиотеке, а то может быть динамическое формирование адреса или вызов из длл, тогда пропустишь вызовы.

| Сообщение посчитали полезным:

У программы есть dll-ки. В том числе, такие, которые импортируют функции для работы с сокетами из WSOCK32.DLL
Я остановился на исследовании exe-файла потому, что в нём я нашёл строковые константы, которые по моему разумению, используются для обработки трафика. Т.е. после расшифровки трафика программа сравнивает полученные с сервера команды с этими жёстко прописанными выражениями и на основании этого выполняет те или иные действия.
К сожалению, Ida не показала мне из каких мест в программе есть ссылки на чтение этих строковых выражений.

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

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Случай тяжелый, а если используется динамическое шифрование - вообще труба.
Но для исследования выход есть: Напиши свою dll(в таких делах отладчик мало помогает, т.к. обмен идет в реальном времени и очень важны таймауты) , и сплайсом перехватывай recv, WSArecv из ws2_32.dll, читая/изменяя пакет и глядя чего программа выдает. Если прога не использует для обмена эти функи, значит она работает ч/з AFD или еще ниже, что встречается очень редко, но и это легко прехватить... Я только такими методами сокеты ковыряю.

-----
продавец резиновых утёнков

| Сообщение посчитали полезным:

SCRTR
Попробуй ещё Api шпионом посмотреть какие функции вообще вызываются.

| Сообщение посчитали полезным:

SCRTR, дело в том что IDA не всё refs находит. Например какой-то кусок кода всё ещё unexplored, или в коде просто нету прямого call - так в MFC обработчик к табличке которая формируется макросом.

Самое простое это посмотреть на все данные в отладчике. Если код или протокол слишком мудрёный, и в клиетре всё написано на blocking (synchronous) вызовах то сделай inject DLL, воткни свои обработчики splicing-ом в несколько мест и пиши данные в лог.

| Сообщение посчитали полезным:

поставить ьряк на обращение к памяти куда recv() пишет должно помочь отследить обращения на которые ida xref не нашла

| Сообщение посчитали полезным:

Спасибо всем, кто откликнулся. Направления дальнейших исследований понятны. Буду ковырять.

| Сообщение посчитали полезным:

Дело в том, что шифрование трафика может производиться не той прогой, которая его шлет-возможна отправка через шифрующий прокси. Посмотрите модель OSI(open systems interconnection) - уровень представления на нем как раз и производиться шифрование.
Короче афтар выясни, нет ли на сервере прокси или vpn и выдирай уже из них шифратор\дешифратор хотя толку с этого наверняка будет мало - тебе придется вклиниться в соединение, всё это очень геморойно.
Здесь уже больше хак чем реверсинг или крак.

| Сообщение посчитали полезным:

1. Cокет может применяться в ReadFile/WriteFile.
2. Если в программе есть вызовы CreateIoCompletionPort, то используются порты завершения и отследить ссылки очень сложно.

Совет: Посылай клиенту пакет с шаблоном и лови в отладчике.

| Сообщение посчитали полезным: