Профиль должен быть заполнен на русском языке кириллицей. Заполнение профиля заведомо ложными или некорректными данными - причина возможного отказа в регистрации на форуме.

Где применимы методы декомпиляции машинного кода в АСУ ТП?

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

Автор темы
DeadBrother
новенький
новенький
Сообщения: 1
Зарегистрирован: 12 июл 2014, 00:17
Ф.И.О.: Константин

Где применимы методы декомпиляции машинного кода в АСУ ТП?

Сообщение DeadBrother » 12 июл 2014, 01:11

Всем привет.
Нужна следующая помощь.

Нужны ответы и идеи на вопрос: :?: "Где и Как в АСУ ТП можно применить декомпиляцию машинного кода?"

Объясню предпосылки.
Так получилось, что занимаюсь диссертацией на тему "метод восстановления алгоритмов машинного кода (МК)".
Это некий аналог декомпиляции, но не совсем.
Цель - обеспечение информационной безопасности (в условиях отсутствия исходного кода поиск НДВ - случайных ошибок программистов или злонамерянных закладок, обеспечение достоверности ПО и т.п.).

При этом, областью применения являются НЕ типичные ПК (с имеющимися уже средствами защиты, такими как антивирусы и т.п.; МК - для Intel, AMD, ...), а специализированные устройства - например маршрутизаторы (для роутеров Cisco и их IOS это крайне актуально; МК - для PowerPC, MIPS, ...). Изначально метод применялся для телекоммуникационных устройств.

:!: НО необходимо данную тему максимально применить к АСУ ТП!

К сожалению, с АСУ ТП почти не знаком.
Ознакомился с общей теорией, практиками и существующими реализациями, но чувствую, что не хватает общения с реальными людьми.

То что уже понял касательно моего вопроса (прошу подправить):
1. на высоком уровне автоматизации:
- декомпиляция МК не особо нужна, т.к. SCADA работают на популярных OS, типа Windows/Linux для которых есть свои широкоизвестные средства защиты, постоянные обновления и фиксы; да и вообще, такие ОС явно не подходят для анализа на уровне ассемблера.
2. на среднем уровне автоматизации:
- часть PLC выполняет МК, которое может быть проприетарным и не иметь открытого исходного кода - а следовательно содержать закладки (как изначально, так и после обновления), которые могут быть более эффективно найдены по восстановленным алгоритмам;
- часть PLC содержит виртуальную машину, которая выполняет байткод IL и тут декомпиляция МК мало применима, поскольку реализация виртуальной машины скорее всего стандартная(открытая) и не содержит особых НДВ, а для восстановления программы по ее байткоду вполне достаточно существующих средств.
3. на низком уровне автоматизации:
- всевозможные датчики, исполнительные механизмы вполне могут быть выполнять МК и содержать НДВ;
4. маршрутизаторы для промышленных сетей (относится ли это к АСУ ТП?):
- так называемая CIsco "индустриализацией Интернета", выполненная например в таких продуктах, как Cisco Industrial Ethernet 2000/3000/..., т.е. телекоммуникации, распространенные в промышленном производстве

Готов к комментариям и обсуждению.

Спасибо.


Михайло
почётный участник форума
почётный участник форума
Сообщения: 2230
Зарегистрирован: 10 ноя 2009, 04:58
Ф.И.О.: Толмачев Михаил Алексеевич
Благодарил (а): 1 раз
Поблагодарили: 23 раза
Контактная информация:

Re: Где применимы методы декомпиляции машинного кода в АСУ Т

Сообщение Михайло » 12 июл 2014, 06:00

1) Многие ПЛК имеют извлекаемые флэшки, там лежат заветные скомпилированные коды, а иногда даже исходные проекты. Но то, что лежит во внутренней энергонезависимой памяти ПЛК не факт, что соответствует содержимому флэшки в виду изощренности врага. Если рассмотреть метод вражеского вируса под названием Stuxnet, то он зашивался в систему еще до этапа компиляции, на компьютерах с ОС Windows.
2) Подключаемый к контроллеру ноутбук с установленным программным обеспечением имеет обычно функцию сравнения исходного проекта с загруженным компилированным кодом. Иногда просто по штампу времени (по времени последнего изменения). Просто информация для сведения.
3) Подключенный ноутбук также может показывать состояние всех переменных в процессе работы ПЛК (диагностическая функция). Тоже для сведения.
4) Некоторых датчиков, а также аналоговых входов и выходов ПЛК (как средств измерения) могут касаться требования ГОСТ Р 8.654-2009 "Требования к программному обеспечению средств измерений". Содержание ГОСТа может быть интересно Вам.
5) Маршрутизаторы и прочее сетевое оборудование - это часть АСУТП. Любые заминки, ошибки, вирусы в этой части - останов АСУТП и производства.


Степа
осмотрелся
осмотрелся
Сообщения: 146
Зарегистрирован: 25 окт 2010, 09:30
Ф.И.О.: Капуста Степан Степанович
Поблагодарили: 5 раз

Re: Где применимы методы декомпиляции машинного кода в АСУ Т

Сообщение Степа » 24 авг 2014, 20:20

DeadBrother писал(а):При этом, областью применения являются НЕ типичные ПК (с имеющимися уже средствами защиты, такими как антивирусы и т.п.; МК - для Intel, AMD, ...), а специализированные устройства - например маршрутизаторы (для роутеров Cisco и их IOS это крайне актуально; МК - для PowerPC, MIPS, ...). Изначально метод применялся для телекоммуникационных устройств.

Я Вас сразу же поправлю: типичному ПК никто не мешает быть ПЛК. Как пример: ICP-CON серий i7000 и i8000, ADAM серии 5000 /в серии 4000 я не помню что-то ПЛК/ - по своей сути почти обычные IBM PC\XT, только без видеокарт, контроллеров дисководов /FDD и HDD/, контроллеров LPT и со всеми устройствами не на "привычных" адресах. Никаких средств защиты у него нет.

DeadBrother писал(а):Так получилось, что занимаюсь диссертацией на тему "метод восстановления алгоритмов машинного кода (МК)".
Это некий аналог декомпиляции, но не совсем.
Цель - обеспечение информационной безопасности (в условиях отсутствия исходного кода поиск НДВ - случайных ошибок программистов или злонамерянных закладок, обеспечение достоверности ПО и т.п.).

Слово "обеспечение ИБ" тут, как мне кажется, лишнее. И "обеспечение достоверности" тоже. Поиск ошибок, случайных или злонамеренных /т.н. "закладка"/ - не суть: тут согласен.
Достоверность ПО обеспечивается контрольными суммами /если учитывать только объективные угрозы/ или хэш-суммами и/или электронными подписями /если учитывать и субъективные угрозы/. А обеспечение ИБ... Скорее всего, ИБ будет строиться с учетом найденых прорех... Т.е. уже вполне ремесленник справится.

DeadBrother писал(а):1. на высоком уровне автоматизации:
- декомпиляция МК не особо нужна, т.к. SCADA работают на популярных OS, типа Windows/Linux для которых есть свои широкоизвестные средства защиты, постоянные обновления и фиксы; да и вообще, такие ОС явно не подходят для анализа на уровне ассемблера.

Ошибочка вышла: SCADA - просто приложение, тоже предоставляет собой некую точку входа. Средства защиты, обновления, фиксы - это ОС, но не SCADA. ОС анализировать может и не стоит - их и так много народу анализирует на предмет НДВ. Но вот SCADA... Тут все не просто плохо, а гораздо хуже.
Внутри SCADA крутится проект, который также может содержать ошибки и закладки. Тут, правда, декомпилировать, чаще всего, просто нечего: исходные коды всех скриптов обычно открыты. Тут разве что заниматься декомпиляцией дополнительных библиотек /даже древняя Advantech GeniDAQ 4.25 из скрипта могла вызывать функции из сторонних динамически загружаемых библиотек - DLL/.

DeadBrother писал(а):2. на среднем уровне автоматизации:
- часть PLC выполняет МК, которое может быть проприетарным и не иметь открытого исходного кода - а следовательно содержать закладки (как изначально, так и после обновления), которые могут быть более эффективно найдены по восстановленным алгоритмам;
- часть PLC содержит виртуальную машину, которая выполняет байткод IL и тут декомпиляция МК мало применима, поскольку реализация виртуальной машины скорее всего стандартная(открытая) и не содержит особых НДВ, а для восстановления программы по ее байткоду вполне достаточно существующих средств.

Виртуальная машина тоже может содержать ошибки и закладки. Даже несмотря на то, что она иногда бывает с открытым исходным кодом /чаще все-таки и виртуальная машина тоже проприетарна/. Т.е. или декомпиляция и восстановление алгоритма или анализ исходных кодов и восстановление алгоритма. И как-то обеспечить проверку, что наличная виртуалка соответствует той, которая получилась после компиляции проверенных исходников: после компиляции чаще всего байт-код будет другим.
Кстати, уже упомянутый тут Stuxnet правил как раз виртуальную машину во вполне конкретных типах ПЛК, если находил там интересующий его проект.

DeadBrother писал(а):3. на низком уровне автоматизации:
- всевозможные датчики, исполнительные механизмы вполне могут быть выполнять МК и содержать НДВ;

Ну тут все просто: почти наверняка проприетарный код, в котором могут быть НДВ. Т.е. декомпиляция и...

DeadBrother писал(а):4. маршрутизаторы для промышленных сетей (относится ли это к АСУ ТП?):
- так называемая CIsco "индустриализацией Интернета", выполненная например в таких продуктах, как Cisco Industrial Ethernet 2000/3000/..., т.е. телекоммуникации, распространенные в промышленном производстве

В общем-то уже можно отнести к АСУ... Тут так же, все так же, как и в предыдущем пункте

Как-то так в общем...

Аватара пользователя

Exactamente
частый гость
частый гость
Сообщения: 409
Зарегистрирован: 20 ноя 2012, 12:45
Ф.И.О.: :.О.N.Ф
Благодарил (а): 3 раза
Поблагодарили: 3 раза

Re: Где применимы методы декомпиляции машинного кода в АСУ Т

Сообщение Exactamente » 25 авг 2014, 00:24

ну вот кстати вопрос можно ли IL считать самым низким уровнем инструкций аналогично асму, команды которого точь-в-точь транслируются в команды процессора. Если в ПЛК процы - тот же пентиум или АРМ... так что вполне есть интерес декомпиляции, по-моему.
«Сразу видно внимание к каждой мелочи, неиспорченным не осталось ничто».


Вернуться в «Общие вопросы»



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей