После прошлого обсуждения интересных находок в Jabber модуле Мобильного Агента, мне сказали о похожей ситуации в ICQ. Ну что же, берем уже установленный инвентарь, качаем дополнительно релиз 1.11 и новую бету 1.16 и читаем.
Итак, применив ту же технику сравнения строк с отладочной информацией к файлу icq_0x2001FAC8.dll от версии 1.11 Агента, можно обнаружить довольно много совпадений :) Дабы не перегружать читателя, выложу лишь несколько наиболее интересных строк — содержащие либо имена функций/аргументов, либо душевные комментарии автора:
Интересно, что автоматический поиск нашел 165 строк в версии 1.11 и уже 175 в версии 1.15. А вот в недавно вышешей версии 1.16 помимо чистки логов Jabber модуля также были удалены практически все найденые пересечения с отладочными строками в ICQ! Кроме одного :)
Для желающих привожу полные списки строк:
P.S. А тем временем мы посмотрели в XML консоли траффик версии 1.16. Мирандовую ноду из капсов удалили, причем радикально, методом удаления необходимого по ХЕР-115 аттрибута node — похоже человек действительно не понимает зачем это все надо и как оно работает…
Один из разработчиков мирандового jabber-плагина даже предложил, при необхдимости написать статью с детальным описанием протокола XEP-115: Entity Capabilities на русском.
P.P.S. Один добрый человек отснифал трафик Мобильного Агента 1.15 и выявил интересную закономерность. При запуске идет запрос обновления:
В запросе передаётся большое количество данных, начиная от разрешения экрана и версии ОС и заканчивая уникальными идентификаторами, которые в дампе закрыты нулями. После получения ответа с двойкой, приложение трясёт экраном на несколько пикселей вправо-влево порядка 2-4 секунд и выходит.
Если надо крашить клиент, сервер отправляет двойку после unknow, если клиент крашить не надо — отправляет тройку. При этом, если заблокировать в фаерволле доступ к mobile.mail.ru, то этот страшный критический баг резко пропадает и всё начинает работать нормально без тряски
И, как обычно: мы никого ни в чем не обвиняем, просто публикуем интересную информацию из общедоступных источников.
Итак, применив ту же технику сравнения строк с отладочной информацией к файлу icq_0x2001FAC8.dll от версии 1.11 Агента, можно обнаружить довольно много совпадений :) Дабы не перегружать читателя, выложу лишь несколько наиболее интересных строк — содержащие либо имена функций/аргументов, либо душевные комментарии автора:
| 000618E8 | Ignoring SNAC(x%02X,x%02X) — FAMILYx%02X not implemented | chan_02data.c (99) icq_avatar.c (1234) |
| 00061924 | *** Yeehah, avatar login sequence complete | icq_avatar.c (1303) |
| 00061A5C | Avatar reply broken, trying to do my best. | icq_avatar.c (1378) |
| 0006E5A8 | *** Yeehah, login sequence complete | fam_01service.c (1060) |
| 0006E738 | Cannot handle abort messages yet… :( | fam_04message.c (534) fam_04message.c (595) fam_04message.c (1223) icq_directmsg.c (233) |
| 0006EE48 | ResizeCookieList: realloc failed. | cookies.c (63) |
| 0006FD54 | Error: Unknown wCommand=0x%x in OFT request | oscar_filetransfer.c (790) |
| 0006F424 | Uploading of avatar hash failed. | fam_13servclist.c (762) |
Интересно, что автоматический поиск нашел 165 строк в версии 1.11 и уже 175 в версии 1.15. А вот в недавно вышешей версии 1.16 помимо чистки логов Jabber модуля также были удалены практически все найденые пересечения с отладочными строками в ICQ! Кроме одного :)
| 0006EFE4 | Uploading of avatar hash failed. | fam_13servclist.c (762) |
Для желающих привожу полные списки строк:
P.S. А тем временем мы посмотрели в XML консоли траффик версии 1.16. Мирандовую ноду из капсов удалили, причем радикально, методом удаления необходимого по ХЕР-115 аттрибута node — похоже человек действительно не понимает зачем это все надо и как оно работает…
<presence> <priority>5</priority> <c xmlns='http://jabber.org/protocol/caps' ver='1.0'/> <status>Custom status</status> </presence>
Один из разработчиков мирандового jabber-плагина даже предложил, при необхдимости написать статью с детальным описанием протокола XEP-115: Entity Capabilities на русском.
P.P.S. Один добрый человек отснифал трафик Мобильного Агента 1.15 и выявил интересную закономерность. При запуске идет запрос обновления:
GET /agent_stat?a=symbian-v3&b=MobileAgent%20v1.15%20BETA&c=unknown&d=0000000000&e=0000000000&f=2&g=00000000000000000000000000000000&h=0&j=1&k=6&m=lang_ru.txt&n=1&o=1&p=0&q=00000000000000000000000000000000&r=0&s=320&t=240&u=0 HTTP/1.1 User-Agent: mmrim/1.0 Host: mobile.mail.ru HTTP/1.1 200 OK Server: nginx/0.7.10 Date: Sat, 07 Feb 2009 00:00:00 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive 6a MobileAgent v1.11|default|001|unknow|2|http://my.agent.mail.ru/mobile/tree30/SymbianOS9.1/MobileAgent.SIS| 0
В запросе передаётся большое количество данных, начиная от разрешения экрана и версии ОС и заканчивая уникальными идентификаторами, которые в дампе закрыты нулями. После получения ответа с двойкой, приложение трясёт экраном на несколько пикселей вправо-влево порядка 2-4 секунд и выходит.
Если надо крашить клиент, сервер отправляет двойку после unknow, если клиент крашить не надо — отправляет тройку. При этом, если заблокировать в фаерволле доступ к mobile.mail.ru, то этот страшный критический баг резко пропадает и всё начинает работать нормально без тряски
И, как обычно: мы никого ни в чем не обвиняем, просто публикуем интересную информацию из общедоступных источников.
