forked from HeadLightSecurity/vkmitm
-
Notifications
You must be signed in to change notification settings - Fork 0
/
description.ru.txt
93 lines (53 loc) · 4.73 KB
/
description.ru.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
Vk Android app
Проанализируем данные, которые шлет приложение и попытаемся выделить главное. Устроим пробную переписку, чтобы понять, как это все работает.
Запросы на обновление сообщений у нас летают следующего вида:
http://im123.vk.com/im3631?act=a_check&key=2daaa..274a&ts=1846839244&wait=25&mode=106&version=1
http://im123.vk.com/im3631?act=a_check&key=7de96..93aa&ts=1846839265&wait=25&mode=106&version=1
...
Различается только key, и, судя по всему, старым кеем можно пользоваться, и читать приходящие и исходящие сообщения. Эвенты тоже можно (типа что "набирает сообщение", "прочитал", и тд), но мне лень детектить. key живет меньше суток точно, но больше пары часов, и не имеет разницы, с какого ip был запрос.
Послсе каждого запросы ts чуть-чуть увеличивается, чтобы ответ не был таким большим, как ниже, например. Чем меньше ts, тем больше данных мы увидим.
Пример большого лога:
{
"ts": 1846839265,
"pts": 21,
"updates": [
[4, 2, 35, 17642261, 1444088823, " ... ", "111111111111", {}], // Наше первое отправленное сообщение
[3, 2, 1, 17642261],
[7, 17642261, 2], // сообщение под номером 2 было прочитано пользователем 17642261
[61, 17642261, 1], // пользователь 17642261 начинает печатать в ответ
[61, 17642261, 1], // ...
[61, 17642261, 1], // ...
[4, 3, 49, 17642261, 1444089179, " ... ", "222222222", {}], // пользователь 17642261 присылает нам сообщение
[3, 3, 1, 17642261],
[6, 17642261, 3],
[4, 4, 35, 17642261, 1444089308, " ... ", "3333333333", {}], // отправили сообщение пользователю 17642261
[3, 4, 1, 17642261],
[7, 17642261, 4], // он его прочитал
[61, 17642261, 1], // начал печатать в ответ
[4, 5, 49, 17642261, 1444089370, " ... ", "444444444444", {}], // присылает в ответ сообщение
[3, 5, 1, 17642261],
[6, 17642261, 5],
[8, -17642261, 7],
[4, 6, 1, 231326698, 1444090605, " ... ", "5555555555", {}], // пользователь 231326698 присылает нам сообщение
[7, 231326698, 5], // читаем сообщение
[3, 6, 1, 231326698],
[6, 231326698, 6]
]
}
Выделим пока то, в чем мы можем быть точно уверены:
{
"ts": 0,
"pts": 0,
"updates": [
[..],
[type(4), num, type_msg(49/51, 17/3, ??), friend_id, unix_time, ??, msg, ??], // обычное сообщение (тип 4), type_msg - так я пытаюсь детектить полученное/отправленное, не уверен в стабильности, нужно тестить.
[type(7), friend_id, num], // прочитать сообщение (тип 7)
[type(61), friend_id, ??], // печатает сообщение (тип 61)
[..]
]
}
Дальше есть два пути. Первый - перехватывать до первого запроса на /im1234... как выше, и потом его долбить без участия жертвы, например каждые 5 секунд, чтобы получать обновления. Нам то пофигу на трафик, в отличии от мобильного приложения.
Если бы я не был слишком ленив, то написал бы так. Но данный скрипт парсит все проходящие пакеты и выделят те, которые подойдут по заданной выше маске. Ну и если они подходят - работать с ними. Но можно просто перехватить запрос и долбить его.
Написал скрипт, который на данный момент делает следующее - слушает пакеты и ждет, пока будет пакет с ответом на GET /im123, а при получении - парсит и выводит его.
Можно разбирать и PCAP файлы тоже.
# vkmitm