Доброго времени суток!

Есть DLLка одного приложения, осуществляющая среди всего прочего (размер файла почти 7 Мб) еще и коммуникацию клиента с сервером, заключающуюся в передаче и приеме ответов, а именно 7 пакетов туда-сюда при инициализации (размер пакета от 36 байт до 2кб), регулярный пинг с клиента на сервер и еще некоторая инфа при отключении клиента.
По смыслу и изменению файлов я, в принципе, знаю что должно передаваться (автообновление настроек пишется в конфиг) и по размерам пакетов даже можно догадаться что и где (как раз 1 пакет порядка 1-2 Кб).

Задача у меня разгадать весь алгоритм и реализовать его на высокоуровневом языке программирования.
Со знаниями программирования и сокетов у меня все в порядке, а вот ассемблер так сказать на начальном уровне, учу в процессе.

Проблема в том, что размеры пакетов всегда постоянные (36, 172, 32, 72, [900-2000], 264, 72, 56, 56, ...), содержимое = 4 байта на длину, дальше 4 символа сигнатура, потом чуть ли не рандом, который никогда не повторяется. Прямая эмуляция последовательности сохраненных пакетов дает отлуп - 120 байт вместо 72 в ответ на 3й запрос от клиента к серверу.

В коде (использую IDA, больше ничего не умею) есть 3 вхождения сигнатуры. Первая в функции, которая судя по тому, что я разгадал, берет буффер данных, проверяет наличие сигнатуры и длину буффера, выдает ошибки либо результат - буффер начиная с после сигнатуры и длину.
Две другие - где эта сигнатура пишется в нужное смещение массива, по идее для последующей отправки на сервер. Собственно, копаюсь я пока вокруг первой функции (bufproc1). Т.к. она принимает данные и возвращает результат, который потом как-то преобразуется, но сама ничего не вызывает, искал кто вызывает ее и что происходит после.

Вот начало самой процедуры

Jump to xref

Вот так хитро запускается


Вызов какой-то странный, вместо call идет lea + mov, больше нигде не нашел. Что это и с чем едят?

P.S. разрешите в этой теме задавать дальнейшие вопросы, которые будут возникать в ходе исследования

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

hexrays запусти

ассемблера увы вы тоже не знаете

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

Пик 1 - выделение памяти под локальные переменные метода в стеке;
Пик 2 - таблица методов и свойств какого-то класса(объекта);
Пик 3 - работа со свойствами объекта.

-----
Следуй за белым кроликом

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

В смысле вкладка Pseudocode? Спасибо
Пишет result = (int)off_F09978;
Вообще странно, там 4 параметра, а тут ни одного... код возврата там ни о чем не говорит, к тому же в версии библиотеки под винду и линукс они разные...

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

pic1 - start это не старт,это базо независимый thrunk
из за этого у вас и рейс ничего нормально не покажет

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

В start ничего интересного нет (в смысле операций с переменными, шифрования итд), и вызывался он чуть ли не с каждой функции (видел минимум 3 старта) потому не зостанавливался на нем


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

епрст, вы меня читаете?
это не старт, из за того что вы его обозвали как старт, рейс не правильно посчитает все базо независимые смещения

стяните любую so либу с линукса? где есть отладочные символы и поставте правильное имя место start

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

Да вроде я его не обзывал как старт, я даю функциям более заковыристые имена типа wtf_bufproc1

тут я нифига не понял
мне все равно линукс или винда, там код похожий но не идентичный (интересно, кому это не лень было вместо кроссплатформенных модулей сидеть и пилить под каждую остьсвой). Сначала ковырял виндовую библиотеку, потом увидел что в линуксовой половина названий функций типа SSL* и AES* сами распознались а в виндовой все были sub_адрес и стал смотреть только линуксовую

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

если вы не знаете что такое базонезависимый код, а он у вас на pic3
то идите и разбирайтесь

детский сад, обьяснять почему gcc сгенерил не такой код как msvc

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

Вычитается база, теперь догнал.

> почему gcc сгенерил не такой код как msvc
там не в этом дело. Вот, например, в линуксовой версии
>7, в винде >=8
<=7 в винде <8
В выводе дебага (ошибки в консоли) в винде имя файла, в линуксе полный путь начиная с /home/
Некоторые строки отличаются и т.д.

Ладно, забил. Прием мне не особо нужен, предположим что сервер всегда шлет клиенту корректные пакеты. Копаю другое вхождение сигнатуры, там формирование пакета и WSASend() - вроде ближе к цели

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

_i686_get_pc_thunk_bx
когда переименуете, рейс выдаст более нормальный результат
хотя бывает еще _i686_get_pc_thunk_cx

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