революционные шутки aol

WOLF D.A. AKA PAYHASH FROM

Спецвыпуск: Хакер, номер #065, стр. 065-008-3

flap_end(buf, sflap);

free(data);

return buf;

}

Ничего себе! Вот как просто ;). Узнав о том, что AOL сменил версию протокола, мы сразу же ринулись расшифровывать дампы. Думали, в протоколе произошли кардинальные изменения. Однако нам открылась картина, которая почти не отличается от старой, — наше удивление было безмерно :). Изменения были формальны и поверхностны: не так был страшен черт, как его малевали.

Если авторизация в базе AOL-сервера пройдет успешно, к нам прилетит пакет SIGN_ON:TOC2.0 (см. ХС #58). Кстати, ты легко убедишься в этом, если самостоятельно сделаешь дамп этого пакета любимым снифером (под Windows рекомендую Iris).

все ясно?

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

Начнем с отправки сообщений. В принципе, здесь не изменилось ничего. Остался тот же пакет toc_send_im, и никаких ошибок в отправке сообщений не наблюдалось (имеется в виду протокол TOC). Вместо toc_send_im рекомендуется ставить toc2_send_im — это единственное, что нужно отметить.

Посмотрим дампы отправки сообщений двух протоколов (см. дампы №3, №4 и картинку №2).

Дамп пакета №3 — отправка текстового сообщения (протокол TOC v1)

TOC v.1.0:

2A 02 00 09 00 21 74 6F 63 5F 73 65 6E 64 5F 69 *....!toc_send_i

6D 20 3x 3x 3x 3x 3x 3x 20 22 48 65 6C 6C 6F 20 m xxxxxx "Hello

62 72 6F 21 0A 22 00 bro!.".

Дамп пакета №4 — отправка текстового сообщения (протокол TOC v2)

TOC v.2.0:

2A 02 00 09 00 21 74 6F 63 32 5F 73 65 6E 64 5F *.P..!toc2_send_

69 6D 20 3x 3x 3x 3x 3x 3x 20 22 48 65 6C 6C 6F im xxxxxx "Hello

20 62 72 6F 21 22 00 bro!".

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

Функция, которая собирала пакет для отправки сообщения, теперь приняла вот такой вид:

static unsigned char *encode_toc_send_im(char *buf, const char *remscreenname, char *mess)

{

char *sflap, *message;

message=(char *)malloc(128, sizeof(char *));

memset(message, 0, 128);

buf=sflap=flap_begin(buf, TYPE_DATA);

//TOC v.1.0

//sprintf(message, "toc_send_im %s \"%s\"", remscreenname, mess);

//TOC v.2.0

sprintf(message, "toc2_send_im %s \"%s\"", remscreenname, mess);

buf=writes(buf, message, strlen(message));

buf=writeb(buf, 0x00);

flap_end(buf, sflap);

free(message);

return buf;

}

Что такое входящее сообщение? Это частный случай исходящего сообщения :), только относительно сервера. Почему именно так? Допустим, мы сформировали пакет toc2_send_im, отправили его с исходящим сообщением на сервер TOC/AIM. Сервер TOC/AIM, получив такое сообщение, конвертирует его в пакет IM_IN_ENC2 — исходящего сообщения для сервера (он же — пакет входящего сообщения для клиента).

Задача нашей AIM/TOC/ICQ-программы должна заключаться в том, чтобы суметь разобрать пакет IM_IN_ENC2. На дампе №5 (см. дамп №5 и картинку №3) пакет IM_IN_ENC2 входящего сообщения выглядит таким образом: