1
00:00:00,000 --> 00:00:01,880
Давайте продолжать.

2
00:00:05,320 --> 00:00:07,520
Меня зовут Константин Грищенко.

3
00:00:07,660 --> 00:00:11,700
Я сегодня, опять, так получается, представлю компанию

4
00:00:11,700 --> 00:00:12,580
Poster Technologies.

5
00:00:12,980 --> 00:00:15,140
Почему-то так получается.

6
00:00:15,920 --> 00:00:18,640
И расскажу вам про вот этот странный артефакт,

7
00:00:18,780 --> 00:00:23,360
который изображен на титульном слайде.

8
00:00:23,360 --> 00:00:30,220
При нем много где много лет описано, где он возникает.

9
00:00:30,220 --> 00:00:34,460
Возникает во время атак злых хакеров, в случае, когда

10
00:00:34,460 --> 00:00:39,640
они туннелируют подключение к RTP через какой-то туннель,

11
00:00:39,640 --> 00:00:42,260
в некоторых случаях, часто это связано с утилитой

12
00:00:42,260 --> 00:00:46,160
игрок, много где описано, но почему-то нигде не описано

13
00:00:46,160 --> 00:00:49,120
природа этого, что это такое, почему он в таком странном

14
00:00:49,120 --> 00:00:54,120
Ну, пару слов о себе.

15
00:00:54,120 --> 00:00:59,120
В компании пользовательства я отвечаю за развитие технологий

16
00:00:59,120 --> 00:01:01,120
в Сибирь и опережающем сайту в ПТХ.

17
00:01:01,120 --> 00:01:04,120
Есть у нас такое подразделение.

18
00:01:04,120 --> 00:01:10,120
На различных позициях в СОКе я более 5 лет, а всего в ППР

19
00:01:10,120 --> 00:01:13,120
страшно подумать уже 23 года.

20
00:01:13,120 --> 00:01:18,120
Немного младше, я тут посчитал, немного младше протокола IPv4,

21
00:01:18,120 --> 00:01:22,580
сильно старше протокола IPv6, ну и был такой опыт в моей жизни,

22
00:01:22,580 --> 00:01:28,960
однажды смог установить ВИГУ-95 с кучей дискеток, правда, со второго раза, но он, тем не менее, смог.

23
00:01:29,740 --> 00:01:34,800
Вот некоторые из этих факторов, наверное, повлияли на то, что я решил это преследовать.

24
00:01:35,180 --> 00:01:43,720
Примеры упоминаний вот этих атак, о которых многие защитники знают,

25
00:01:43,720 --> 00:01:49,640
расследователи, специалисты, инцидент Респонса часто встречали, много где описаны.

26
00:01:50,540 --> 00:01:55,120
Я не помню точных данных, вот здесь на слайде, там 22-й год, то есть довольно давно.

27
00:01:56,240 --> 00:02:02,580
Как бы все известно, примеры каких-то иностранных и отечественных компаний,

28
00:02:02,680 --> 00:02:08,240
которые в своих отчетах этот артефакт напоминают, и чаще всего либо явно напоминают,

29
00:02:08,240 --> 00:02:11,720
или чуть ли не гандрок, либо просто говоря о протоколировании,

30
00:02:12,160 --> 00:02:14,360
но встречаются вот такие тезисы.

31
00:02:15,640 --> 00:02:19,340
Здесь я красить и выделю, не несет никакой информации

32
00:02:19,340 --> 00:02:21,820
о подключившейся системе.

33
00:02:22,700 --> 00:02:25,900
Ну, вроде как да, а что же несет?

34
00:02:26,240 --> 00:02:30,560
Я читал эти заметки, и мне всегда казалось, что, наверное,

35
00:02:31,100 --> 00:02:34,600
эти расследователи, которые тут все расследуют, они в курсе,

36
00:02:34,600 --> 00:02:39,480
Ну просто это какая-то мелочь, о которой они не хотят рассказывать, поэтому ничего не пишут

37
00:02:39,480 --> 00:02:47,420
Какой-то интерес во мне терпился до 2024 года, когда я однажды пошел на конференцию

38
00:02:47,420 --> 00:02:53,560
Вот зачем ходить на конференции, да? Можно просто ходить зачем-то, можно задавать вопросы

39
00:02:53,560 --> 00:03:00,180
На той конференции один из известных экспертов, одной из местных компаний, Олег Скуркин

40
00:03:00,180 --> 00:03:10,180
Делал какой-то доклад на какое-то свое тело и в этом же докладе опять упомянул про атаки, известный, уделительный блок, вот этот артефакт.

41
00:03:10,180 --> 00:03:17,180
А вот там где-то в зале, в темноте, не видно, но подписывал, там где-то сижу я со своими коллегами и решаю задать вопрос.

42
00:03:17,180 --> 00:03:24,180
Все-таки вот лично спросить у одного из экспертов, а что это такое? Может быть это все-таки известно? И опять не получаю ответа.

43
00:03:24,180 --> 00:03:31,140
получают ответ. Ответ был примерно такой, но это какой-то артефакт, непонятный, не знаю, не разбирались, неважно.

44
00:03:31,860 --> 00:03:40,140
Для целей расследования, наверное, неважно. А мне стало интересно, и в ближайшие дни я спал примерно вот так,

45
00:03:40,140 --> 00:03:47,740
как справа здесь во слайде нарисовано, вроде бы сплю, но при этом не дают мне почему-то покоя.

46
00:03:47,740 --> 00:03:55,660
и само это число, и два двоеточия, и знак процента, и почему это все вместе собрано там,

47
00:03:55,780 --> 00:03:59,440
где, казалось бы, по логике должен быть просто опять адрес.

48
00:04:00,280 --> 00:04:03,760
Вот здесь на слайде скриншот событий журнала Аудита,

49
00:04:04,020 --> 00:04:06,820
который описан во всех этих исследованиях,

50
00:04:06,820 --> 00:04:10,720
что в случае, когда хакеры попадают на систему,

51
00:04:11,540 --> 00:04:15,660
пробрасывают с помощью утилитет ГРО, обратно себе туннель,

52
00:04:15,660 --> 00:04:44,420
а потом через этот туннель подключаются по EDP, журнале аузита, вот о ком вот внизу указано, да, Windows Terminal Services Remote Connection, Manager Operational, пишется событие с номером 1149, и у него в параметрах значениях три интересных поля, пользователь домен и адрес источника.

53
00:04:44,420 --> 00:04:49,320
Пользователям дамет, все понятно, а вот адрес источника, ну, по логике должен быть адресом.

54
00:04:49,800 --> 00:04:53,480
И во всех обычных нормальных событиях там обычно написан IP-адрес.

55
00:04:53,720 --> 00:04:57,220
Привычный, известный IPv4 IP-адрес.

56
00:04:58,240 --> 00:05:00,780
Того самого IPv4, которого я чуть-чуть младше.

57
00:05:02,100 --> 00:05:06,980
Здесь то же самое событие справа для наглядности в исходном как бы XML-виде,

58
00:05:06,980 --> 00:05:11,600
чтобы посмотреть, что там, ну, вдруг какое-то форматирование сбивается или что-то.

59
00:05:11,600 --> 00:05:22,040
нет, действительно там в параметрах ровно такое значение 2.2% и вот это страшное число, не буду его называть на этот случай.

60
00:05:23,480 --> 00:05:34,580
И тут хочется вспомнить, ну я решил поразбираться и напрячь, начало память, а может бывают IP-адреса записанные в таком виде.

61
00:05:34,580 --> 00:05:42,140
Пошел, погуглил, почитал, вспомнил разную литературу,

62
00:05:42,140 --> 00:05:46,400
вспомнил какие-то RFC, что-то нашел.

63
00:05:46,400 --> 00:05:49,800
IP-адреса версии 4, ну что это такое, мы все с вами

64
00:05:49,800 --> 00:05:50,800
знаем, я надеюсь.

65
00:05:50,800 --> 00:05:54,820
Это просто число целых четырех байкеров, которые

66
00:05:54,820 --> 00:05:57,820
используются как на лентификаторах на старых интернете или

67
00:05:57,820 --> 00:05:58,820
в локальной сети.

68
00:05:58,820 --> 00:06:01,700
Но при этом интересно, что это число может быть

69
00:06:01,700 --> 00:06:05,520
записано в разном виде, в виде строки, в виде привычной

70
00:06:05,520 --> 00:06:08,560
нам десятичной, каждый парт отдельно в десятичном

71
00:06:08,560 --> 00:06:12,000
виде через строчку, можно писать в восьмеричном виде,

72
00:06:12,140 --> 00:06:14,900
можно писать в шестнадцатиричном виде, можно миксовать,

73
00:06:15,280 --> 00:06:19,580
и даже можно писать это число просто как большое

74
00:06:19,580 --> 00:06:21,980
целое число, и иногда это работает.

75
00:06:22,540 --> 00:06:26,640
Это работает, потому что где-то под капотом используется

76
00:06:26,640 --> 00:06:33,640
библиотека, функция AtomEd, которая все это умеет конвертить.

77
00:06:33,640 --> 00:06:38,820
Ну, я на это все посмотрел, интересно, но не похоже на

78
00:06:38,820 --> 00:06:42,320
то, что я видел в блоге.

79
00:06:42,320 --> 00:06:45,320
Ну, возможно, похоже вот это большое целое число,

80
00:06:45,320 --> 00:06:47,320
но все равно не оно.

81
00:06:47,320 --> 00:06:51,400
А еще бывает о версии 6.

82
00:06:51,400 --> 00:06:56,320
Там интереснее, там 16 байт, 128 бит, записывается

83
00:06:56,320 --> 00:07:02,080
обычно, когда пишется в виде текста в виде 16-ти ручных

84
00:07:02,080 --> 00:07:08,140
цифр, разделяются двоеточиями, нули, которые тут подряд можно

85
00:07:08,140 --> 00:07:11,080
сокращать, и тогда получается два двоеточия.

86
00:07:12,180 --> 00:07:15,040
И даже есть вот такая интересная запись, я нашел где-то

87
00:07:15,040 --> 00:07:16,040
когда-то в интернете.

88
00:07:17,160 --> 00:07:20,840
Почему-то в некоторых случаях в командлайне, особенно

89
00:07:20,840 --> 00:07:23,280
в Windows, нельзя использовать двоеточия.

90
00:07:23,280 --> 00:07:25,200
А как же тогда указывать эти адреса?

91
00:07:25,200 --> 00:07:29,420
Но вот компания Microsoft решили проблему вот таким способом.

92
00:07:29,420 --> 00:07:36,540
Они придумали доменное имя, как быть домен, IPv6.difins.literal.net.

93
00:07:36,540 --> 00:07:46,540
А если перед ним записать IPv6 адрес, но вместо двойточа расставить знаки минус, то все будет работать.

94
00:07:47,140 --> 00:07:50,500
Причем никаких резонов никуда не уходит, это где-то как-то резонится.

95
00:07:51,520 --> 00:07:54,600
То есть это по сути же как бы FQD, но только не настоящий.

96
00:07:54,600 --> 00:07:57,720
и он результется где-то внутри какой-то библиотеки на кроссовке.

97
00:07:58,320 --> 00:08:02,000
Но опять, что-то не хватает.

98
00:08:02,180 --> 00:08:04,420
Два твяточей есть, знака процента нет.

99
00:08:04,540 --> 00:08:08,060
Большое число я нашел, но в IPV4.

100
00:08:08,780 --> 00:08:12,800
Два твяточей я нашел, но вот здесь не хватает процента.

101
00:08:13,080 --> 00:08:15,580
Пойдем, искай дальше, сказал сам себе.

102
00:08:16,760 --> 00:08:22,080
И почитал еще чуть-чуть RFC в поисках какой-нибудь записи,

103
00:08:22,080 --> 00:08:23,560
в которой встречаются проценты.

104
00:08:23,560 --> 00:08:31,160
Проценты встречаются в так называемый, не знаю, смогу ли это произнести, скоблитерал IPv6-адрес.

105
00:08:32,680 --> 00:08:42,560
Грубо говоря, по-русски, как я это понял, это такой способ на локальной системе явно указать, к какому интерфейсу относится IPv6.

106
00:08:43,440 --> 00:08:49,920
Ну, процент 3, да, там, третий интерфейс, или процент китаж 2, ну, понятно, интерфейс китаж 2.

107
00:08:49,920 --> 00:08:56,920
Но эта штука обычно используется, имеет смысл только в пределах одной конкретно локальной системы.

108
00:08:56,920 --> 00:09:05,920
И в сумме опять я смотрю, ну это по отдельности все есть, и квадратные тучи где-то встречаются, и проценты где-то встречаются, и большие числа где-то встречаются.

109
00:09:05,920 --> 00:09:11,920
Но явно в таком виде ничего похожего нет, на первый взгляд.

110
00:09:11,920 --> 00:09:15,920
Но на самом деле, если приглядеться, кое-что похожее есть.

111
00:09:15,920 --> 00:09:18,360
Что это за число конкретное?

112
00:09:18,360 --> 00:09:25,640
Во всех тех атаках, которые описаны, встречалось конкретно вот это число, а не какое-то другое.

113
00:09:25,640 --> 00:09:32,700
Тут, наверное, многие из вас уже по дороге догадались или вспомнили, или быстро почитали на калькуляторе.

114
00:09:32,700 --> 00:09:34,700
Я тоже почитал.

115
00:09:34,700 --> 00:09:38,200
Если представить 16-ти личный вид, получается вот такое большое число.

116
00:09:38,200 --> 00:09:41,520
Я наставил пробитчики, чтобы его топливо читать.

117
00:09:41,520 --> 00:09:45,520
Ну и по сути это в твоей части 1 единицы и много нулей.

118
00:09:47,520 --> 00:09:49,520
На что это наводит, на какую мысль?

119
00:09:49,520 --> 00:09:53,520
Вот есть такие вышеиста адрес, которые соответствуют лома лохосту самому себе.

120
00:09:53,520 --> 00:09:55,520
Это тоже 1 единица и много нулей.

121
00:09:55,520 --> 00:09:59,520
Много выглядит чуть по-другому, да, единица в другом месте.

122
00:09:59,520 --> 00:10:04,520
Все 2 точи можно убрать, сократить, получается 2 2 точи 1.

123
00:10:04,520 --> 00:10:10,520
А вот в этом числе нельзя, получится какая-то ерунда, тут не получается.

124
00:10:10,520 --> 00:10:24,820
Но что-то похожее. И вот тут у меня стала вырисовываться гипотеза, что на самом деле вот это страшное число 2.0% это какая-то почему-то ошибочная форма занятий localhost.

125
00:10:24,820 --> 00:10:45,820
И по сути эта гипотеза, ну как бы триллиальна, потому что она логична, потому что подключение то самое хакерское по ЛДП через тунны, оно по сути и происходит с локал хаста на саму же машину, да, то есть какое-то клиентское туо локально подключается к службе удаленных рабочих столов.

126
00:10:45,820 --> 00:11:00,120
Я, конечно же, таким формальным языком не думал, но потом, когда готовил презентацию, я кратко формализовал свой исследовательский опыт в виде такой гипотезы

127
00:11:00,120 --> 00:11:04,580
Прежде чем пойти эту гипотезу проверять, я ее чуть-чуть еще в голове уточнил

128
00:11:04,580 --> 00:11:08,420
Везде описана вот эта константа вместе с утилитой игрок

129
00:11:08,420 --> 00:11:16,820
И как вам мне проверить? Я могу предположить, что игрок как-то с этим связан и пойти как-то изучать.

130
00:11:16,900 --> 00:11:22,560
Наверное, взять игрок, проводить какие-то эксперименты, например, сковырять игрок, посмотреть, почему он так делает.

131
00:11:23,140 --> 00:11:27,360
Вдруг он так делает специально, как-то, но вряд ли, но может быть.

132
00:11:28,000 --> 00:11:33,280
А можно другую гипотезу выделить, что игрок не виноват, а все делаем в самом туннеле.

133
00:11:34,120 --> 00:11:36,760
Я решил, что вторую гипотезу мне проверить проще.

134
00:11:36,760 --> 00:11:38,760
Ну почему я так решил?

135
00:11:38,760 --> 00:11:41,760
В момент заняться с игроком были какие-то сложности

136
00:11:41,760 --> 00:11:47,760
Что-то он то ли перестал в России работать, то ли деньги искал брать, я уже забыл

137
00:11:47,760 --> 00:11:55,760
Кроме игрока есть какие-то еще унтилитты, но в итоге в целом мне показалось проще стараться и по-хранению

138
00:11:55,760 --> 00:11:57,760
И теперь ее можно сформулировать так

139
00:11:57,760 --> 00:12:04,760
Вот это число в логике это странная форма записи localhostого IPv6 адреса 2.1

140
00:12:04,760 --> 00:12:07,720
которая возникает вот эта странность.

141
00:12:07,720 --> 00:12:10,440
Не из-за игрок, а из-за чего-то другого.

142
00:12:10,440 --> 00:12:12,400
Как проверять? Ну, легко.

143
00:12:12,400 --> 00:12:14,800
Надо что-то взять и провести эксперимент.

144
00:12:16,000 --> 00:12:17,480
Наверное, кажется легко, да?

145
00:12:17,480 --> 00:12:18,760
Значит, что взять?

146
00:12:18,760 --> 00:12:23,520
Где-то тут я собирался ставить ссылку, но похоже, забыл.

147
00:12:23,520 --> 00:12:25,400
А, нет, вот она, внизу.

148
00:12:25,400 --> 00:12:26,800
Внизу ссылочка.

149
00:12:26,800 --> 00:12:29,280
Это какой-то наобумный ресурс на GitHub,

150
00:12:29,280 --> 00:12:32,720
где собраны какие-то известные утилиты для туннелирования.

151
00:12:32,720 --> 00:12:34,720
Название «Rosson Tunnelin».

152
00:12:34,720 --> 00:12:38,720
Там этих утилит туннелирования, ну, несколько десятков.

153
00:12:38,720 --> 00:12:57,540
С ними со всеми как-то разбираться, какие удобные, какие-то подкопки не подходят, я не стал, а вспомнил про SSH, который с недалних пор и Windows тоже в умолчании есть, и подумал, что зачем что-то мне городить, ведь за цель эксперимента неважно.

154
00:12:57,540 --> 00:13:15,380
Поэтому, значит, простой совершенно слева ноутбук, с которого я подключаюсь, как будто бы хакер, справа специальный сервер, на котором я буду подключаться по ЛТП через туннель и смотреть, что у меня запишут в лог, между ними я прокидываю SSH.

155
00:13:15,380 --> 00:13:21,660
вы мне, конечно, можете сказать, что хакеры-то прокидывали СССР, ну, справа налево, взломав правый компьютер, да,

156
00:13:21,980 --> 00:13:27,180
а я прокидываю мне так проще слева направо, но для цель эксперимента это не важно.

157
00:13:27,360 --> 00:13:33,940
Мы же знаем, да, что когда TCP соединение установлено, уже не важно, кто был инициатор, кто жертва, да,

158
00:13:34,180 --> 00:13:38,180
соединения уже есть, да, то и обе стороны передаются, и параметры, да,

159
00:13:38,680 --> 00:13:41,760
порт слева, это тот порт, который будет открыт у меня на машине,

160
00:13:41,760 --> 00:13:46,060
порт справа это тот порт, куда я хочу пробросить свое подключение

161
00:13:46,060 --> 00:13:48,900
два третучия, один в квадратных ступочках

162
00:13:48,900 --> 00:13:53,300
ну, чтобы отличать, где здесь порты, а где здесь IP-адреса

163
00:13:53,300 --> 00:13:59,120
такая форма записи тоже с интересом я узнал, когда начал интересоваться IP-вышитель

164
00:13:59,120 --> 00:14:03,700
подключаюсь и обнаруживаю, что все хорошо работает

165
00:14:03,700 --> 00:14:05,960
SSH отличная утилита

166
00:14:05,960 --> 00:14:10,760
утилита нетстат, например, проверяю, убеждаюсь, что у меня все подключено

167
00:14:10,760 --> 00:14:14,980
Это не два соединения, это одно и то же соединение с двух сторон

168
00:14:14,980 --> 00:14:18,220
Два процесса работают, а тут друг в лоб подключился

169
00:14:18,220 --> 00:14:21,080
И у одного процесса есть соединение, у другого процесса есть

170
00:14:21,080 --> 00:14:23,440
Можно проводить исследование

171
00:14:23,440 --> 00:14:24,920
Как проводить исследование?

172
00:14:25,140 --> 00:14:31,480
Ну вот я подключился, я пропускаю слайд, я пошел в лоб и убедился, что проблемное значение пишется

173
00:14:31,480 --> 00:14:33,580
Я могу воспроизводить всю эту штуку

174
00:14:33,580 --> 00:14:39,440
Что делать? Надо разбираться, кто же сгенерировал неправильные данные в какой момент

175
00:14:39,440 --> 00:14:44,160
Ну, надо взять какой-то тлачек или взять какой-то бинарный модуль, какой-то дезасцемблер,

176
00:14:44,260 --> 00:14:45,820
зарыться туда и исследовать.

177
00:14:46,540 --> 00:14:48,240
А можно пойти чуть-чуть другим путем.

178
00:14:48,500 --> 00:14:49,420
Опять же, решил я.

179
00:14:49,620 --> 00:14:55,000
Я знал про такую старую, но не бесполезную, как говорил герой нового фильма,

180
00:14:55,120 --> 00:15:00,700
Old, Баткнот Абсолид, утилиту под названием Абиба не только.

181
00:15:01,260 --> 00:15:05,860
Утилита тоже старая, но в 2013 год это ее последняя актуальная версия.

182
00:15:05,860 --> 00:15:09,980
она больше не обновлялась, или я не нашел обновлений, версия 2.0.α,

183
00:15:10,620 --> 00:15:12,580
но она до сих пор отлично работает.

184
00:15:14,260 --> 00:15:19,620
Утилита позволяет перехватывать API-вызовы и смотреть, что попало на вход,

185
00:15:19,760 --> 00:15:21,140
что получилось на выходе.

186
00:15:21,500 --> 00:15:24,300
Очень удобно, когда вы примерно что-то понимаете,

187
00:15:24,820 --> 00:15:27,860
но не хотите от латчиков лезть неизвестно куда,

188
00:15:28,120 --> 00:15:30,340
или не умеете, или забыли, как это делается.

189
00:15:30,340 --> 00:15:35,780
Ну, как в моем случае, я очень много лет этим не занимался.

190
00:15:35,860 --> 00:15:37,320
и трудно вспоминать.

191
00:15:37,780 --> 00:15:39,620
Но встает вопрос в следующий.

192
00:15:39,780 --> 00:15:41,220
Хорошо, возьмем API-монитор.

193
00:15:41,820 --> 00:15:43,820
Что мониторить? Процессов-то много.

194
00:15:45,120 --> 00:15:45,840
За что браться?

195
00:15:47,980 --> 00:15:50,760
Надо найти какой-то процесс, который во всем этом участвует.

196
00:15:51,200 --> 00:15:53,980
Опять же, вариантов несколько, но там был скриншот раньше,

197
00:15:54,100 --> 00:15:56,980
у телеканал нетстар, и в принципе, добавить один ключик,

198
00:15:56,980 --> 00:16:02,700
и процессы видят, и можно понять, что отлаживать.

199
00:16:02,700 --> 00:16:15,600
Другой способ, который более наглядный, поэтому я что-то привел замечательный утилит процесс эксплуатации пакета утилит Марка Русиновича, а может уже она и не Марка Русиновича, сессинтерненс в общем.

200
00:16:16,600 --> 00:16:21,500
При должном умении с помощью этой утилиты можно найти нужный процесс.

201
00:16:21,500 --> 00:16:31,840
Достаточно вспомнить, что служба управления, подключение к службе рабочих столов, да, это терминал сервисов на самом деле или что-то такое.

202
00:16:32,440 --> 00:16:44,480
Можно вспомнить, что можно посмотреть по онлайне у процессов, вывести этот столбик, вспомнить, что большинство майкрософтских сервисов живет на самом деле внутри процесса SVC Host,

203
00:16:44,480 --> 00:16:48,640
которые только на первый взгляд кажутся одинаковыми, а внутри них живет разное.

204
00:16:49,400 --> 00:16:54,020
Можно посмотреть открытые порты, найти тот процесс, у которого открыт нужный порт, перегистрироваться везде.

205
00:16:54,180 --> 00:17:00,220
В общем, с разных сторон можно поискать процессы, в которых подгружено много всяких библиотек с названиями RDP.

206
00:17:01,140 --> 00:17:07,660
Ну вот с разных сторон я посмотрел, нашел тот самый процесс и пошел проводить эксперименты.

207
00:17:07,660 --> 00:17:14,660
Эксперимент. Подключаю к нужному процессу, включаю, мониторить.

208
00:17:14,660 --> 00:17:18,660
Но не все эти вызовы, но все эти вызовы, связанные со сетевыми функциями.

209
00:17:18,660 --> 00:17:22,660
Смотрю внимательно, нахожу какую-то функцию под названием

210
00:17:22,660 --> 00:17:29,660
GetNameInfoW, на которой на выходе что-то похожее на структуру с ОКД,

211
00:17:29,660 --> 00:17:34,660
который содержит IP-адрес, в том числе. На выходе вот стрелочкой показано,

212
00:17:34,660 --> 00:17:36,660
Два раза, но и то же, просто увеличено.

213
00:17:36,660 --> 00:17:38,660
Какой-то IP-адрес.

214
00:17:38,660 --> 00:17:41,660
В данном эксперименте я подключался с помощью IPv4,

215
00:17:41,660 --> 00:17:44,660
просто чтобы проверить, как вообще все работает,

216
00:17:44,660 --> 00:17:46,660
все работает для IPv4 не то.

217
00:17:46,660 --> 00:17:51,660
Вот все, я нашел примерно место, в котором что-то похожее происходит.

218
00:17:51,660 --> 00:17:55,660
И этот же самый IP-адрес я увидел в логе, провожу эксперименты дальше.

219
00:17:55,660 --> 00:18:01,660
Беру IPv6, здесь, видно, плохо, поэтому второй слайд увеличен с тем же самым.

220
00:18:01,660 --> 00:18:06,380
подключаюсь через туннель, в общем, весь тот самый эксперимент провожу

221
00:18:06,380 --> 00:18:10,240
и вижу ровно то, что и я хотел найти

222
00:18:10,240 --> 00:18:13,060
при CallWebю, это значение на входе

223
00:18:13,060 --> 00:18:16,900
здесь на слайде не видно, дальше будет чуть понятней

224
00:18:16,900 --> 00:18:25,520
но там содержится по смыслу структура, окрестующая API на 6 адреса клиента

225
00:18:25,520 --> 00:18:29,280
ну там должен быть Localhost API на 6 адреса

226
00:18:29,280 --> 00:18:35,600
А на выходе после Google WebView буфер, в котором должна оказаться строка.

227
00:18:36,400 --> 00:18:40,020
Вот то самое сломанное и испорченное значение.

228
00:18:40,600 --> 00:18:44,940
Значит, я примерно нашел место, где проблема проявляется.

229
00:18:45,180 --> 00:18:46,360
И можно копать дальше.

230
00:18:48,440 --> 00:18:51,340
Пару слов о вот этой функции. Что за функция? Так классно.

231
00:18:51,700 --> 00:18:55,660
Мне всегда нравилось вариацией облаживать процессы Microsoft,

232
00:18:55,660 --> 00:18:58,300
каких-то продуктов, а не какие-то другие.

233
00:18:58,300 --> 00:19:03,300
потому что у них есть документация, она в целом хорошая.

234
00:19:03,300 --> 00:19:10,300
GetNameInfoW, вот такая функция, у нее есть какие-то параметры.

235
00:19:10,300 --> 00:19:14,300
Флаги описывают поведение. Вообще эта функция может много чего разного,

236
00:19:14,300 --> 00:19:20,300
и предназначена она, например, для того, чтобы из IP-адреса, ну, в виде числа в виде IP-адреса,

237
00:19:20,300 --> 00:19:23,300
получить, например, hostName.

238
00:19:23,300 --> 00:19:27,980
Но с флагом, не знаю, но мере хост, она генерирует строковое представление IP-5.

239
00:19:27,980 --> 00:19:29,980
Не хост-мег.

240
00:19:29,980 --> 00:19:33,700
Ну, собственно, то, в чем я и пытаюсь разобраться.

241
00:19:33,700 --> 00:19:36,260
Странная строковая представительница.

242
00:19:36,260 --> 00:19:40,180
И в своих экспериментах я встречал в двух видах.

243
00:19:40,180 --> 00:19:44,180
Ну, два вида отличаются, здесь немножко гребит на экране,

244
00:19:44,180 --> 00:19:46,260
вторым параметром, размер структуры.

245
00:19:46,260 --> 00:19:50,180
В одном случае 28 байт, в другом случае 16.

246
00:19:50,180 --> 00:19:57,180
Ну, несложно догадаться, когда IPv4 там 16, когда IPv6 там 28.

247
00:19:57,180 --> 00:20:00,180
Возможно, эти факты нам дальше понадобятся.

248
00:20:00,180 --> 00:20:02,180
И что за структура на входе?

249
00:20:02,180 --> 00:20:11,180
Вот со структурой сотнада рынка, видимо, так звезды сложились давно, когда придумывали весь этот сетевой стэк в разных операционных системах.

250
00:20:11,180 --> 00:20:18,820
некоторые запыхатели говорят что у других производителей своровали там сети ОСК

251
00:20:18,820 --> 00:20:22,300
а другие горячки просто так же написали, так совпало

252
00:20:22,300 --> 00:20:33,840
много где используются структурки которые пытаются однотипно описать разное

253
00:20:33,840 --> 00:20:39,460
и используют разные трюки языка Си, чтобы ссылаться на память по-разному

254
00:20:39,460 --> 00:20:55,160
И здесь встречается структура SoCADR, которая потом указатель, ее может приводиться к типу указатель на SoCADR-in для IP-адресов версии 4, либо к типу SoCADR-in для IP-адресов версии 6.

255
00:20:55,160 --> 00:21:02,840
Вот здесь я их зачем-то нарисовал, ну, например, вы можете быстро посчитать, кто способен в это время суток

256
00:21:02,840 --> 00:21:09,420
Размер структуры, то у вас получится, что там 16, а здесь 28

257
00:21:09,420 --> 00:21:12,520
Ровно как было на предыдущем слайде

258
00:21:12,520 --> 00:21:18,420
Ну и дальше я певаю пи-монитор, запускаю

259
00:21:18,420 --> 00:21:23,480
Несколько слайдов назад, там был маленький спойлер

260
00:21:23,480 --> 00:21:25,340
здесь я его убрал

261
00:21:25,340 --> 00:21:26,240
и что я вижу?

262
00:21:26,780 --> 00:21:29,300
я вижу результат эксперимента

263
00:21:29,300 --> 00:21:31,300
показывает, что

264
00:21:31,300 --> 00:21:34,160
испорченное значение в куфер записалось

265
00:21:34,160 --> 00:21:35,740
вот здесь

266
00:21:35,740 --> 00:21:37,460
красненьким испорченное значение

267
00:21:37,460 --> 00:21:38,460
на слайде видно

268
00:21:38,460 --> 00:21:41,160
а когда я хочу подробно посмотреть

269
00:21:41,160 --> 00:21:43,120
содержимое памяти, чтобы понять

270
00:21:43,120 --> 00:21:45,640
ну что там у меня куда съехало

271
00:21:45,640 --> 00:21:46,720
где что испортилось

272
00:21:46,720 --> 00:21:49,420
я ничего не вижу, я вижу 17

273
00:21:49,420 --> 00:21:50,560
и много нулей

274
00:21:50,560 --> 00:21:54,220
Где хотя бы одна единица?

275
00:21:54,220 --> 00:21:56,220
Одна единица должна быть.

276
00:21:56,220 --> 00:22:00,220
Может быть у кого-то в зале есть ответный вопрос?

277
00:22:00,220 --> 00:22:01,960
Попробуй добавить чуть-чуть интерактива.

278
00:22:01,960 --> 00:22:08,320
Кстати, герои на этом слайде тоже примерно того же возраста,

279
00:22:08,320 --> 00:22:10,320
что и протокол.

280
00:22:10,320 --> 00:22:13,100
Возьмите фильм, из которого этот герой примерно того

281
00:22:13,100 --> 00:22:16,140
же возраста, что и протокол IPv6.

282
00:22:16,140 --> 00:22:18,720
С удивлением узнал я, когда готовился к этому.

283
00:22:18,720 --> 00:22:24,140
Ну нет вариантов, но ответ несложный

284
00:22:24,140 --> 00:22:29,340
Значит, смотрите, автор утилиты API-монитора

285
00:22:29,340 --> 00:22:31,260
Он же как утилиту написал?

286
00:22:31,300 --> 00:22:37,440
Он написал некую утилиту, и к ней еще кучу конфигурационных файлов, которые все эти API-структуры описывают

287
00:22:37,440 --> 00:22:42,680
В нем в описании не было учтено, что данных может быть больше

288
00:22:42,680 --> 00:22:53,020
То есть он учел всякие разные штуки, что, например, 17 это признак, который описывает тип AF, подчеркивание, и нет 6

289
00:22:53,020 --> 00:22:56,060
То есть он, в принципе, про IPv6 что-то знал

290
00:22:56,060 --> 00:23:02,960
Но при этом, что надо заложить здесь побольше данных для отображения 28 байт, а не всего лишь 16

291
00:23:02,960 --> 00:23:04,680
Он не сделал

292
00:23:04,680 --> 00:23:10,520
Но оказалось, что он сделал самое, не то чтобы главное, а важное

293
00:23:10,520 --> 00:23:17,520
Его утилита не прибита гвоздями, и несмотря на то, что она сделана в 2013 году, она до сих пор работает.

294
00:23:17,520 --> 00:23:26,220
Это первый плюс и второй плюс. Все описания лежат в файликах, их можно редактировать.

295
00:23:26,380 --> 00:23:33,640
Вот описание структуры SoGatorIn, где написано, что в определенном поле имеет тип чар 14,

296
00:23:34,640 --> 00:23:37,820
2 байта под тип, а потом 14 байта под все остальное.

297
00:23:37,820 --> 00:23:45,800
А вот так, в двух местах, с первого раза у меня не получилось, но там хороший и отдаточный лоб, и я понял, в чем ошибка.

298
00:23:45,940 --> 00:23:53,220
В двух местах надо подправить, я думаю здесь понятно, и тип, да, слева исходная, справа исправленная версия.

299
00:23:54,180 --> 00:24:00,760
Нужно добавить свой как бы тип с названием чар 30 и длину этого типа 30.

300
00:24:00,760 --> 00:24:01,760
30.

301
00:24:03,400 --> 00:24:04,860
Ставить и все будет.

302
00:24:07,820 --> 00:24:18,820
Повторяю эксперимент. Уже отображаются все нужные данные и здесь отлично видно, я здесь стрелочками показал, что куда и почему.

303
00:24:18,820 --> 00:24:35,840
И в итоге, я сейчас немножко время начинает сжимать, поэтому сокращаю. Красненькими стрелочками и черточками я отобразил связь всех полей в структуре с данными в памяти.

304
00:24:35,840 --> 00:24:51,640
И теперь хорошо видно, что вот эта самая последняя единица, которая действительно есть, уехала в поле, которое отвечает за хранение того самого Sculpe IT, то есть локального нормального интерфейса.

305
00:24:52,180 --> 00:24:53,720
И выехала из-за 5 адреса.

306
00:24:53,940 --> 00:25:02,900
Пока непонятно почему, но гипотеза подтверждается, что ты куда-то съехала, дабы только уточнить в каком месте.

307
00:25:02,900 --> 00:25:07,520
Адрес localhost содержит всего одну единицу, поэтому

308
00:25:07,520 --> 00:25:10,820
не очень понятно, что именно съехало, какой байт съехал

309
00:25:10,820 --> 00:25:11,820
там.

310
00:25:11,820 --> 00:25:14,780
Начиная с середины или начиная с самого первого байта, или

311
00:25:14,780 --> 00:25:16,120
один последний байт.

312
00:25:16,120 --> 00:25:19,140
Поэтому проводим еще один эксперимент, берем какой-нибудь

313
00:25:19,140 --> 00:25:22,660
интервайль, найдем вашести адрес, подключаемся, смотрим,

314
00:25:22,660 --> 00:25:25,920
что получилось и убеждаемся, что снижает, ну видно наглядно,

315
00:25:25,920 --> 00:25:27,920
снижает весь этот адрес.

316
00:25:27,920 --> 00:25:32,120
Вначале появляется 4 лишних байта, в конце появляется

317
00:25:32,120 --> 00:25:33,360
какое-то странное число.

318
00:25:34,240 --> 00:25:35,460
Логика понятна,

319
00:25:36,060 --> 00:25:37,340
можно легко проверить,

320
00:25:38,240 --> 00:25:39,880
что это за число и как вернуть обратно.

321
00:25:40,080 --> 00:25:41,340
Здесь мы стрелки предумеваем,

322
00:25:41,380 --> 00:25:43,740
1, 2, 3, 4. Берем вот это число,

323
00:25:43,820 --> 00:25:45,640
берем калькулятор, переводим 16-ти

324
00:25:45,640 --> 00:25:53,480
переставляем все в обратном порядке байт и видим ровно те цифры в IPv6 адресе.

325
00:25:54,600 --> 00:25:59,180
Где проявляется проблема? Проблема проявляется в событии 1149, с которого я начал,

326
00:25:59,660 --> 00:26:06,840
еще раз, минимум, в двух событиях 4778 и 4779 про подключение и отключение сессии РДП.

327
00:26:07,960 --> 00:26:12,240
Все идет аналогичным образом. А может быть, я уже в интернете описано, спросил я себя,

328
00:26:12,240 --> 00:26:15,840
и оказалось, что нет, я не нашел описание такой проблемы,

329
00:26:16,380 --> 00:26:18,240
но нашел описание похожей.

330
00:26:19,260 --> 00:26:25,500
Это примерно времен 2008 года, переход с РТП-7 на РТП-8,

331
00:26:26,360 --> 00:26:30,080
и, значит, проблема у человека была, он заметил неправильное

332
00:26:30,080 --> 00:26:33,900
адреса в саблении 46-24, и обычно известные нам саблению

333
00:26:33,900 --> 00:26:36,960
о донтификации, а ответ был такой, мы разобрались,

334
00:26:37,080 --> 00:26:40,080
причина в том, что мы поменяли немножечко стек,

335
00:26:40,080 --> 00:26:42,380
появилась структура, запомните,

336
00:26:42,480 --> 00:26:44,260
VPS, SoCADR

337
00:26:44,260 --> 00:26:46,120
и из-за несогласованности

338
00:26:46,120 --> 00:26:47,960
что-то как поехало. Но мы все починили,

339
00:26:48,020 --> 00:26:50,220
написано здесь. Оказалось, что

340
00:26:50,220 --> 00:26:51,340
починили, но не все.

341
00:26:52,220 --> 00:26:54,020
Теперь надо немного по дебажам, тут я

342
00:26:54,020 --> 00:26:56,160
совсем буду ускоряться. Значит,

343
00:26:57,100 --> 00:26:58,480
примерно понятно, что дебажает,

344
00:26:58,480 --> 00:27:00,860
но дальше некоторые сложности, и как я с ним боролся.

345
00:27:00,920 --> 00:27:02,220
Если Саша удобно, но не всегда

346
00:27:02,220 --> 00:27:04,500
арендовать можно быстро

347
00:27:04,500 --> 00:27:06,580
какую-нибудь виртуалку с новой версией Windows,

348
00:27:06,800 --> 00:27:08,620
чтобы на разных версиях протестировали,

349
00:27:08,620 --> 00:27:14,440
Но не хочется долго оборочиться, програсывать порты, разрешать SSH, чтобы там возиться

350
00:27:14,440 --> 00:27:18,860
Можно арендовать рядом две виртуалки, это в два раза дороже и опять возиться

351
00:27:18,860 --> 00:27:24,500
А можно взять, например, утилиту из того списка DevTunnels от самой компании Microsoft

352
00:27:24,500 --> 00:27:28,040
Она почти такая же удобная, как и урок, а может быть даже и лучше

353
00:27:28,040 --> 00:27:29,520
И с ней классно работает

354
00:27:29,520 --> 00:27:36,140
Мы на одном хосте подключаем маппинг, на другом хосте, этим же DevTunnels подключаемся к туннелю

355
00:27:36,140 --> 00:27:38,180
Порты проброшены, можно работать

356
00:27:38,180 --> 00:27:46,680
Вторая проблема. Отлаживать прикольно, удобно, здорово, но когда ты отлаживаешь что-то, подключение по РДП, ты можешь застрять текстуру.

357
00:27:46,680 --> 00:27:55,180
Вот на первой картинке состояние до, слева клиент, еще не подключился, но хочет. Справа рабочая станция, он будет подключаться.

358
00:27:56,400 --> 00:28:01,860
Ниже состояние после. Он подключился, у него десктоп слева, справа окошко для ввода пароля.

359
00:28:01,860 --> 00:28:08,080
А вот если станет точка остановок, то в момент подключения все встанет на паузу и вы окажете здесь нигде.

360
00:28:08,220 --> 00:28:09,340
Вы не сможете отлаживать.

361
00:28:09,880 --> 00:28:12,320
Проблема не проблема.

362
00:28:12,480 --> 00:28:18,240
Возьмите сервер, поднимите нормальный терминальный сервер, где можно несколько мультисессий, но неохота возиться.

363
00:28:18,940 --> 00:28:19,480
Второй вариант.

364
00:28:19,640 --> 00:28:29,040
Девтунов может проброс сразу несколько портов, а многие отладчики, в том числе Мир Николаевич Кюримов, отладчик, могут отлаживать удаленно по TCP.

365
00:28:29,040 --> 00:28:33,280
Пробрасываем код для отладчика, отлаживаем через него и в текстурке не застреваем.

366
00:28:33,280 --> 00:28:37,280
Неочевидные сложности последний слайд.

367
00:28:37,280 --> 00:28:41,280
Отлаживать винтовые пенали удобно, легко, классно.

368
00:28:41,280 --> 00:28:43,400
Там нормальный код, там нет опускации.

369
00:28:43,400 --> 00:28:45,840
Там есть символы и это плюс.

370
00:28:45,840 --> 00:28:48,400
Но кода много и для меня минус.

371
00:28:48,400 --> 00:28:51,040
Порально, ну потому что не знаешь, за что хвататься.

372
00:28:51,040 --> 00:28:53,760
РТП это же большое, где там, не сказать.

373
00:28:53,760 --> 00:29:00,100
Но плюс, с помощью лабьего монитора я примерно знаю место, где проблема точно проявляется.

374
00:29:00,200 --> 00:29:03,800
Надо только чуть назад отмотать и найти, где она возникает.

375
00:29:03,960 --> 00:29:08,620
А в Intel архитектуре есть удобная штука, но наверняка во всех других тоже.

376
00:29:09,100 --> 00:29:15,880
Это аппаратные брэкпоинты, которые позволяют ставить точке стол, но только на код, но и на обращение к памяти.

377
00:29:15,880 --> 00:29:19,220
Поэтому во время отладки я просто вижу проблемное место

378
00:29:19,220 --> 00:29:21,360
Ставлю брэкпоинт на память

379
00:29:21,360 --> 00:29:22,960
Еще раз отлаживаю, смотрю

380
00:29:22,960 --> 00:29:25,020
Кто обращается к этой памяти раньше

381
00:29:25,020 --> 00:29:27,280
И таким образом за несколько операций

382
00:29:27,280 --> 00:29:29,340
Я нашел проблемное место

383
00:29:29,340 --> 00:29:31,740
Ну, оно на самом деле в двух местах

384
00:29:31,740 --> 00:29:32,620
Начало здесь

385
00:29:32,620 --> 00:29:34,820
Библиотека РТП КОРАТС

386
00:29:34,820 --> 00:29:37,320
Метод на складе написан

387
00:29:37,320 --> 00:29:39,880
Кусок КОРА за тех, кто знаком с Семблером

388
00:29:39,880 --> 00:29:42,800
Кусок картинка для тех, кто смотрит на картинки

389
00:29:42,800 --> 00:29:43,600
И ничего не понимает

390
00:29:43,600 --> 00:29:50,440
Вот здесь 128-битный регистр, там IP-адрес, вот сюда он копируется.

391
00:29:51,040 --> 00:29:57,640
Чуть выше по коду, заполняется значение 17, это признак структуры АЭФ-6.

392
00:29:59,200 --> 00:30:05,020
Видно разницу, 12 байт, запомним это, я почти уже закончил.

393
00:30:05,020 --> 00:30:13,860
А та самая структура высокоадр, которая уже возникала, в другом модуле выглядит вот так.

394
00:30:14,780 --> 00:30:20,400
В этой структуре есть 4 лишних байта, а то для выравнивания.

395
00:30:20,400 --> 00:30:30,680
И в итоге получается один модуль, как там было написано, заполняется смещением 12, хотя должно быть 8.

396
00:30:30,680 --> 00:30:34,100
а другой модуль читает эти данные со скрещением 8.

397
00:30:34,800 --> 00:30:39,000
То есть одни и те же данные интерпретируются вот так наглядно.

398
00:30:39,120 --> 00:30:41,380
Я не знаю, наглядно вам или нет, мне наглядно.

399
00:30:41,500 --> 00:30:44,420
Здесь одни и те же данные нарисованы два раза.

400
00:30:44,860 --> 00:30:50,280
Сверху, вот в этом слайде, 17, но на 0, 1, и покрашены так,

401
00:30:50,340 --> 00:30:55,600
как эти данные интерпретируют первый модуль, который заполняют эти данные в памяти.

402
00:30:55,600 --> 00:31:08,260
А снизу, как интерпретировать второй модуль, и из-за разного патентного равнования в разных структурах, которые должны описывать одно и то же в разных модулях, получается ошибка.

403
00:31:08,820 --> 00:31:14,640
А в каких версиях ошибка? Ну, я тестировал вот на этих версиях год назад, примерно в это время.

404
00:31:16,680 --> 00:31:24,600
И мой опыт позволяет мне сказать о том, что, скорее всего, подвержены этой проблемой все версии, начиная с Windows 8 и Windows 7 в 2012.

405
00:31:24,600 --> 00:31:34,940
Конечно, я все не протестировал, но те, которые протестировал, и то сообщение в интернете о 2008-2009 года или 2010-го говорит об этом.

406
00:31:35,740 --> 00:31:42,480
Но при этом вот этот персонаж Питер Гриффин позволяет задать вопрос, а неужели всем все равно?

407
00:31:42,720 --> 00:31:50,060
Ну, видимо, да, потому что, скорее всего, никто не пользуется всерьез IPv6-адресом в реальной работе.

408
00:31:50,060 --> 00:31:59,860
И никто всерьез не читает блоги, кроме случаев, когда уже всех поломали, а там уже придут ребята из Дефир, все расследуют, а открыли, и значение всего очень-то и важно.

409
00:31:59,860 --> 00:32:04,820
Конечно, мы зарепортили с коллегами это дело, мне мои коллеги помогли на красоте

410
00:32:04,820 --> 00:32:08,080
Но так как здесь уязвимости нет, а просто сообщение об ошибке

411
00:32:08,080 --> 00:32:12,460
Нам ответили так, что, ну, примерно, спасибо, мы учтем

412
00:32:12,460 --> 00:32:15,440
Мы когда-нибудь это вам отдадим людям, они разберутся, они поправят

413
00:32:15,440 --> 00:32:19,220
Целые дни, какой нет, баунтинг, какой нет, об этой дни, баунтинг не дадим

414
00:32:19,220 --> 00:32:20,200
Мы вам ничего не ответим

415
00:32:20,200 --> 00:32:24,760
Ну и до сих пор ничего не ответили, но я провел какой-то эксперимент

416
00:32:24,760 --> 00:32:26,720
Буквально на днях

417
00:32:26,720 --> 00:32:29,640
Судя по всему, проблема уже исправлена

418
00:32:29,640 --> 00:32:47,800
Вот здесь маленькое сообщение, да, есть такие же люди с проблемами, вот что-то на китайском, 2024 год, кто-то спросил, а почему там лорус, там неправильно опять ли сопричатся на форуме Ask, на Microsoft, какие-то Ask questions.

419
00:32:47,800 --> 00:32:50,480
Ну многие знают, какого качества там ответы

420
00:32:50,480 --> 00:32:51,920
Первый ответ там вообще ни о чем

421
00:32:51,920 --> 00:32:53,380
Второй ответ через два года

422
00:32:53,380 --> 00:32:56,120
Буквально на днях, в воздействии этого время

423
00:32:56,120 --> 00:32:58,120
Да, чувак, там есть проблема

424
00:32:58,120 --> 00:33:00,080
Тебе надо вот так пересчитать, на как бы адрес

425
00:33:00,080 --> 00:33:02,660
Все будет хорошо, я сейчас буду писать баг-репорт

426
00:33:02,660 --> 00:33:05,440
Ну вот будет теперь два баг-репорта

427
00:33:05,440 --> 00:33:06,520
Наш и еще один

428
00:33:06,520 --> 00:33:09,360
Значит, я проверил на актуальных версиях

429
00:33:09,360 --> 00:33:11,680
Windows 10 уже не поддерживается

430
00:33:11,680 --> 00:33:13,700
Я не уверен, что я взял самую последнюю

431
00:33:13,700 --> 00:33:15,600
Но я постарался накатить все обновления

432
00:33:15,600 --> 00:33:16,840
Ошибка до сих пор есть

433
00:33:16,840 --> 00:33:18,600
Windows 11

434
00:33:18,600 --> 00:33:22,160
Вот такой версии не самая новая ошибка есть

435
00:33:22,160 --> 00:33:24,300
Это же релиз

436
00:33:24,300 --> 00:33:25,460
Более свежий пилд

437
00:33:25,460 --> 00:33:27,660
Со всеми обновлениями на середину мая

438
00:33:27,660 --> 00:33:28,760
Ошибки уже нет

439
00:33:28,760 --> 00:33:31,480
Свежий Windows 11 этого года

440
00:33:31,480 --> 00:33:32,320
Ошибки нет

441
00:33:32,320 --> 00:33:35,320
Можно сделать предположение, что все поправили

442
00:33:35,320 --> 00:33:37,440
Ну и вот скриншот

443
00:33:37,440 --> 00:33:38,580
Сегодня утром

444
00:33:38,580 --> 00:33:40,800
Юпор СТ

445
00:33:40,800 --> 00:33:42,720
2.2.1

446
00:33:42,720 --> 00:33:44,680
На поправленной версии

447
00:33:44,680 --> 00:33:46,740
Итоги

448
00:33:46,740 --> 00:33:48,880
ошибка есть, но эта ошибка

449
00:33:48,880 --> 00:33:50,740
витус, с ингрок не связана

450
00:33:50,740 --> 00:33:53,440
не согласован на промоку данных

451
00:33:53,440 --> 00:33:55,040
на расследование не влияет

452
00:33:55,040 --> 00:33:57,440
ошибочное значение

453
00:33:57,440 --> 00:33:59,040
из логов, если вам нужно

454
00:33:59,040 --> 00:34:00,880
можно восстановить данные

455
00:34:00,880 --> 00:34:01,940
не безвозвратно

456
00:34:01,940 --> 00:34:04,840
портятся и вот формула для пересчета

457
00:34:04,840 --> 00:34:07,440
у меня все, спасибо за внимание

458
00:34:07,440 --> 00:34:10,380
давайте вопрос

459
00:34:10,380 --> 00:34:15,700
спасибо, мы немножко вылезли

460
00:34:15,700 --> 00:34:18,340
без расписания, но поскольку у нас все маленькое,

461
00:34:18,340 --> 00:34:22,200
куларное, можно давить до трачка и задавать ему вопросы

462
00:34:22,200 --> 00:34:24,760
непосредственно по человеку.