- •От издательства
- •О техническом обозревателе
- •О соавторах
- •Об авторах
- •Вступительное слово
- •Благодарности
- •Предисловие
- •Почему важна защита интернета вещей?
- •Чем защита интернета вещей отличается от традиционной ИТ-защиты?
- •Законы хакинга интернета вещей
- •Заключение
- •Моделирование угроз для интернета вещей
- •Схема моделирования угроз
- •Определение архитектуры
- •Разбивка архитектуры на компоненты
- •Выявление угроз
- •Использование деревьев атак для обнаружения угроз
- •Распространенные угрозы интернета вещей
- •Атаки с подавлением сигнала
- •Атаки с воспроизведением
- •Атаки со взломом настроек
- •Клонирование узла
- •Заключение
- •Пассивная разведка
- •Физический или аппаратный уровень
- •Периферийные интерфейсы
- •Среда загрузки
- •Блокировки
- •Предотвращение и обнаружение несанкционированного доступа
- •Прошивка
- •Интерфейсы отладки
- •Физическая устойчивость
- •Разведка
- •Атаки на сетевой протокол и службы
- •Тестирование беспроводного протокола
- •Оценка веб-приложений
- •Картирование приложений
- •Элементы управления на стороне клиента
- •Аутентификация
- •Управление сеансом
- •Проверка ввода
- •Логические ошибки
- •Сервер приложений
- •Исследование конфигурации хоста
- •Учетные записи пользователей
- •Привилегии учетной записи
- •Уровни патчей
- •Удаленное обслуживание
- •Управление доступом к файловой системе
- •Шифрование данных
- •Неверная конфигурация сервера
- •Мобильное приложение и облачное тестирование
- •Заключение
- •4. Оценка сети
- •Переход в сеть IoT
- •VLAN и сетевые коммутаторы
- •Спуфинг коммутатора
- •Двойное тегирование
- •Имитация устройств VoIP
- •Идентификация устройств IoT в сети
- •Обнаружение паролей службами снятия отпечатков
- •Атаки MQTT
- •Настройка тестовой среды
- •Написание модуля MQTT Authentication-Cracking в Ncrack
- •Тестирование модуля Ncrack на соответствие MQTT
- •Заключение
- •5. Анализ сетевых протоколов
- •Проверка сетевых протоколов
- •Сбор информации
- •Анализ
- •Создание прототипов и разработка инструментов
- •Работа с Lua
- •Общие сведения о протоколе DICOM
- •Генерация трафика DICOM
- •Включение Lua в Wireshark
- •Определение диссектора
- •Определение основной функции диссектора
- •Завершение диссектора
- •Создание диссектора C-ECHO
- •Начальная загрузка данных функции диссектора
- •Анализ полей переменной длины
- •Тестирование диссектора
- •Разработка сканера служб DICOM для механизма сценариев Nmap
- •Написание библиотеки сценариев Nmap для DICOM
- •Коды и константы DICOM
- •Написание функций создания и уничтожения сокетов
- •Создание заголовков пакетов DICOM
- •Написание запросов контекстов сообщений A-ASSOCIATE
- •Чтение аргументов скрипта в движке сценариев Nmap
- •Определение структуры запроса A-ASSOCIATE
- •Анализ ответов A-ASSOCIATE
- •Создание окончательного сценария
- •Заключение
- •6. Использование сети с нулевой конфигурацией
- •Использование UPnP
- •Стек UPnP
- •Распространенные уязвимости UPnP
- •Злоупотребление UPnP через интерфейсы WAN
- •Другие атаки UPnP
- •Использование mDNS и DNS-SD
- •Как работает mDNS
- •Как работает DNS-SD
- •Проведение разведки с помощью mDNS и DNS-SD
- •Злоупотребление на этапе проверки mDNS
- •Атаки «человек посередине» на mDNS и DNS-SD
- •Использование WS-Discovery
- •Как работает WS-Discovery
- •Подделка камер в вашей сети
- •Создание атак WS-Discovery
- •Заключение
- •UART
- •Аппаратные средства для связи с UART
- •Как найти порты UART
- •Определение скорости передачи UART
- •JTAG и SWD
- •JTAG
- •Как работает SWD
- •Аппаратные средства для взаимодействия с JTAG и SWD
- •Идентификация контактов JTAG
- •Взлом устройства с помощью UART и SWD
- •Целевое устройство STM32F103C8T6 (Black Pill)
- •Настройка среды отладки
- •Кодирование целевой программы на Arduino
- •Отладка целевого устройства
- •Заключение
- •Как работает SPI
- •Как работает I2C
- •Настройка архитектуры шины I2C типа «контроллер–периферия»
- •Заключение
- •9. Взлом прошивки
- •Прошивка и операционные системы
- •Получение доступа к микропрограмме
- •Взлом маршрутизатора Wi-Fi
- •Извлечение файловой системы
- •Статический анализ содержимого файловой системы
- •Эмуляция прошивки
- •Динамический анализ
- •Внедрение бэкдора в прошивку
- •Нацеливание на механизмы обновления микропрограмм
- •Компиляция и установка
- •Код клиента
- •Запуск службы обновления
- •Уязвимости служб обновления микропрограмм
- •Заключение
- •10. Радио ближнего действия: взлом rFID
- •Радиочастотные диапазоны
- •Пассивные и активные технологии RFID
- •Структура меток RFID
- •Низкочастотные метки RFID
- •Высокочастотные RFID-метки
- •Настройка Proxmark3
- •Обновление Proxmark3
- •Клонирование низкочастотных меток
- •Клонирование высокочастотных меток
- •Имитация RFID-метки
- •Изменение содержимого RFID-меток
- •Команды RAW для небрендированных или некоммерческих RFID-тегов
- •Подслушивание обмена данными между меткой и считывателем
- •Извлечение ключа сектора из перехваченного трафика
- •Атака путем подделки RFID
- •Автоматизация RFID-атак с помощью механизма скриптов Proxmark3
- •Пользовательские сценарии использования RFID-фаззинга
- •Заключение
- •11. Bluetooth Low Energy (BLE)
- •Как работает BLE
- •Необходимое оборудование BLE
- •BlueZ
- •Настройка интерфейсов BLE
- •Обнаружение устройств и перечисление характеристик
- •GATTTool
- •Bettercap
- •Взлом BLE
- •Настройка BLE CTF Infinity
- •Приступаем к работе
- •Заключение
- •12. Радиоканалы средней дальности: взлом Wi-Fi
- •Как работает Wi-Fi
- •Атаки Wi-Fi на беспроводные клиенты
- •Деаутентификация и атаки «отказ в обслуживании»
- •Атаки на Wi-Fi путем подключения
- •Wi-Fi Direct
- •Атаки на точки доступа Wi-Fi
- •Взлом WPA/WPA2
- •Взлом WPA/WPA2 Enterprise для сбора учетных данных
- •Методология тестирования
- •Заключение
- •13. Радио дальнего действия: LPWAN
- •Захват трафика LoRa
- •Настройка платы разработки Heltec LoRa 32
- •Настройка LoStik
- •Превращаем USB-устройство CatWAN в сниффер LoRa
- •Декодирование протокола LoRaWAN
- •Формат пакета LoRaWAN
- •Присоединение к сетям LoRaWAN
- •Атаки на LoRaWAN
- •Атаки с заменой битов
- •Генерация ключей и управление ими
- •Атаки воспроизведения
- •Подслушивание
- •Подмена ACK
- •Атаки, специфичные для приложений
- •Заключение
- •14. Взлом мобильных приложений
- •Разбивка архитектуры на компоненты
- •Выявление угроз
- •Защита данных и зашифрованная файловая система
- •Подписи приложений
- •Аутентификация пользователя
- •Управление изолированными аппаратными компонентами и ключами
- •Проверенная и безопасная загрузка
- •Анализ приложений iOS
- •Подготовка среды тестирования
- •Статический анализ
- •Динамический анализ
- •Атаки путем инъекции
- •Хранилище связки ключей
- •Реверс-инжиниринг двоичного кода
- •Перехват и изучение сетевого трафика
- •Анализ приложений Android
- •Подготовка тестовой среды
- •Извлечение файла APK
- •Статический анализ
- •Обратная конвертация двоичных исполняемых файлов
- •Динамический анализ
- •Перехват и анализ сетевого трафика
- •Утечки по побочным каналам
- •Заключение
- •15. Взлом умного дома
- •Физический доступ в здание
- •Клонирование RFID-метки умного дверного замка
- •Глушение беспроводной сигнализации
- •Воспроизведение потока с IP-камеры
- •Общие сведения о протоколах потоковой передачи
- •Анализ сетевого трафика IP-камеры
- •Извлечение видеопотока
- •Атака на умную беговую дорожку
- •Перехват управления интеллектуальной беговой дорожкой на базе Android
- •Заключение
- •Инструменты для взлома интернета вещей
- •Предметный указатель
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Рис.5.5.Диссектор DICOM в Lua для сообщений A-типа в Wireshark
Создание диссектора C-ECHO
Анализируя запрос C-ECHO с помощью нашего нового анализатора, мы должны увидеть,что он состоитиз разных сообщенийA-типа,по- добных тем, которые показаны на рис. 5.5. Следующий шаг – анализ данных, содержащихся в этих пакетах DICOM.
Чтобы показать, как можно обрабатывать строки в нашем диссек- торе Lua, давайте добавим в диссектор код для анализа сообщения A-ASSOCIATE. На рис. 5.6 показана структура запроса A-ASSOCIATE.
Тип |
Зарезервировано |
Длина |
Версия |
Зарезервировано |
Заголовок |
Зарезервировано |
Приложение + |
PDU |
(0x0) |
PDU |
протокола |
(0x0) |
объекта |
(0x0) |
Представление+ |
|
|
|
|
|
вызываемого |
|
Контекстданных |
|
|
|
|
|
приложения |
|
пользователя |
1 байт |
1 байт |
4 байт |
2 байта |
2 байта |
16 байт |
32 байта |
Переменная |
|
|
|
|
|
|
|
длина |
Рис.5.6.Структура запроса A-ASSOCIATE
Обратите внимание на заголовки вызываемого и вызывающего приложения длиной 16 байт. Заголовок объекта приложения – это метка, которая идентифицирует поставщика услуг. Сообщение так- же содержит зарезервированный раздел длиной 32 байта, который должен быть заполнен нулями,атакже элементы переменнойдлины, включая элементы Application Context (контекст приложения), Pre- sentation Context (контекст представления) и User Info (информация о пользователе).
134 Глава 5
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
Извлечение строковых значений заголовков объектовw Click |
to |
|
|
|
|
m |
|||||
|
|
|
|
|
|||||||
|
w |
|
|
|
|
|
|
|
|
|
|
приложения |
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
|||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
Начнем с извлечения полей фиксированнойдлины сообщения,вклю- чая строковые значения вызывающего и вызываемого приложения названия сущностей. Это полезная информация; часто службы не имеют аутентификации,поэтому,если у вас есть правильный заголо- вок объекта приложения, вы можете подключиться и начать вводить команды DICOM. Мы можем определить новые объекты ProtoField для нашего сообщения запроса A-ASSOCIATE с помощью следующего кода:
protocol_version = ProtoField.uint8("dicom-a.protocol_version", "protocolVersion", base.DEC)
calling_application = ProtoField.string( "dicom-a.calling_app", "callingApplication")
called_application = ProtoField.string("dicom-a.called_app", "calledApplication")
Чтобы извлечь строковые значения названий вызываемых и вы- зывающих приложений, используем функцию ProtoField ProtoField. string. Мы передаем ей имя, которое будет использовать в фильтрах , необязательное имя для отображения в дереве , формат отобра- жения(base.ASCII илиbase.UNICODE)инеобязательноеполеописания.
Начальная загрузка данных функции диссектора
После добавления новых ProtoFields в качестве полей в диссектор протокола нам нужно добавить код для их загрузки в функцию дис- сектора,dicom_protocol.dissector(),поэтому они включены вдерево отображения протокола:
local pdu_id = buffer(0, 1):uint() -- Convert to unsigned int
if pdu_id == 1 or pdu_id == 2 then -- ASSOC-REQ (1) / ASSOC-RESP (2)
local assoc_tree = subtree:add(dicom_protocol, buffer(), "ASSOCIATE REQ/ RSP")
assoc_tree:add(protocol_version, buffer(6, 2)) assoc_tree:add(calling_application, buffer(10, 16)) assoc_tree:add(called_application, buffer(26, 16))
end
Диссектор должен добавить извлеченные поля в поддерево в де- реве протокола. Чтобы создать поддерево, вызываем функцию add() из нашего существующего дерева протоколов . Теперь наш простой анализатор может определятьтипы PDU,длину сообщения,тип сооб- щенияASSOCIATE ,протокол,вызывающее и вызываемое приложе- ния. Результат показан на рис. 5.7.
Анализ сетевых протоколов 135
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Рис.5.7.Поддеревья,добавленные к существующим деревьям протоколов
Анализ полей переменной длины
Теперь, когда мы идентифицировали и проанализировали разделы фиксированной длины, давайте проанализируем поля сообщения, имеющие переменную длину. В DICOM мы используем идентифика- торы, называемые контекстами, для хранения, представления и об- мена различных характеристик.Мы покажем вам,как найти три раз- личныхтипадоступныхконтекстов:контекстприложения,контексты презентации и контекстинформации о пользователе,которые имеют переменное количество элементов полей.Но мы не будем писать код для анализа содержимого элемента.
Для каждого из контекстов добавим поддерево, которое отобража- ет длину контекста и переменное количество элементов контекста. Измените основной диссектор протокола, чтобы он выглядел следу- ющим образом:
function dicom_protocol.dissector(buffer, pinfo, tree) pinfo.cols.protocol = dicom_protocol.name
local subtree = tree:add(dicom_protocol, buffer(), "DICOM PDU") local pkt_len = buffer(2, 4):uint()
local pdu_id = buffer(0, 1):uint() subtree:add_le(pdu_type, buffer(0,1)) subtree:add(message_length, buffer(2,4))
if pdu_id == 1 or pdu_id == 2 then -- ASSOC-REQ (1) / ASSOC-RESP (2)
local assoc_tree = subtree:add(dicom_protocol, buffer(), "ASSOCIATE REQ/RSP") assoc_tree:add(protocol_version, buffer(6, 2)) assoc_tree:add(calling_application, buffer(10, 16)) assoc_tree:add(called_application, buffer(26, 16))
--Extract Application Context
local context_variables_length = buffer(76,2):uint()
local app_context_tree = assoc_tree:add(dicom_protocol, buffer(74, context_variables_ length + 4), "Application Context")
app_context_tree:add(app_context_type, buffer(74, 1)) app_context_tree:add(app_context_length, buffer(76, 2)) app_context_tree:add(app_context_name, buffer(78, context_variables_length))
--Extract Presentation Context(s)
local presentation_items_length = buffer(78 + context_variables_length + 2, 2):uint() local presentation_context_tree = assoc_tree:add(dicom_protocol, buffer(78 + context_
136 Глава 5
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
||
|
|
|
C |
|
E |
|
|
|
|
|
|
|
C |
|
E |
|
|
|
|||||||
|
|
X |
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
|
||||||
|
- |
|
|
|
|
|
d |
|
|
|
- |
|
|
|
|
|
|
d |
|
||||||
|
F |
|
|
|
|
|
|
|
t |
|
|
|
F |
|
|
|
|
|
|
|
|
t |
|
||
|
D |
|
|
|
|
|
|
|
|
i |
|
|
|
D |
|
|
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
|
|
|
|
|
|
|
|
|
|
|
r |
||||
P |
|
|
|
|
|
NOW! |
o |
|
P |
|
|
|
|
|
|
NOW! |
o |
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
BUY |
|
|
|
|
|
|
|
|
|
BUY |
|
|
||||||||
|
|
|
|
to |
|
|
|
|
|
|
variables_length, presentation_items_length + 4), "Presentation Context") |
|
|
|
|
|
to |
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
w |
|
|
|
|
|
|
|
|
|
m |
w |
|
|
|
|
|
|
|
|
|
|
m |
|||
w Click |
|
|
|
|
|
|
o |
|
w Click |
|
|
|
|
|
|
o |
|||||||||
|
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
_ |
|
|
|
|
|
|
|||
|
. |
|
|
|
|
|
e |
|
presentation_context_tree:add(presentation_context_type, buffer(78 + context_variables. |
|
|
|
e |
|
|||||||||||
|
|
p |
df |
|
|
|
g |
.c |
|
|
|
|
p |
df |
|
|
|
g |
.c |
|
|||||
|
|
|
|
|
n |
|
|
|
|
|
|
|
|
|
|
n |
|
|
|
|
|||||
|
|
|
|
-xcha |
|
|
|
length, 1)) |
|
|
|
|
|
-x cha |
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
presentation_context_tree:add(presentation_context_length, buffer(78 + context_ variables_length + 2, 2))
-- TODO: Extract Presentation Context Items
--Extract User Info Context
local user_info_length = buffer(78 + context_variables_length + 2 + presentation_items_ length + 2 + 2, 2):uint()
local userinfo_context_tree = assoc_tree:add(dicom_protocol, buffer(78 + context_ variables_length + presentation_items_length + 4, user_info_length + 4), "User Info Context")
userinfo_context_tree:add(userinfo_length, buffer(78 + context_variables_length + 2 + presentation_items_length + 2 + 2, 2))
-- TODO: Extract User Info Context Items end
end
При работе с сетевыми протоколами часто встречаются поля пе- ременной длины, требующие вычисления смещений. Очень важно, чтобы вы получили правильные значения длины, потому что все вы- числения смещений зависят от них.
Помня об этом, мы извлекаем контекст приложения , контексты представления и контекст информации о пользователе .Для каж- дого контекста извлекаем длину контекста и добавляем поддерево для информации, содержащейся в этом контексте . Мы добавляем отдельные поля с помощью функции add() и вычисляем смещение строк в зависимости от длины полей. Все эти данные мы извлекаем из пакета, полученного с помощью функции buffer().
Тестирование диссектора
После внесения изменений,упомянутых в предыдущем разделе,убе- дитесь,что ваши пакеты DICOM анализируются правильно,проверив полученную длину. Теперь вы должны увидеть поддерево для каждо- го контекста (рис.5.8).Обратите внимание: поскольку мы предостав- ляемдиапазон буферов в новых поддеревьях,можно выбратьих,что- бы выделить соответствующий раздел.Не пожалейте времени,чтобы убедиться, что каждый контекст протокола DICOM распознается так, как вы ожидали.
Если вы хотите попрактиковаться, рекомендуем вам добавлять в диссектор поля из разных контекстов. Вы можете скачать пакет DI- COM со страницы образца пакета Wireshark, где мы выложили пакет, содержащий эхо-запрос DICOM. Вы также найдете полный пример, включая фрагментацию TCP, в онлайн-ресурсах этой книги. Помни- те, что вы можете перезагрузить скрипты Lua в любое время, чтобы протестироватьсвойпоследнийдиссекторбезперезапускаWireshark,
Анализ сетевых протоколов 137