Всем привет.
Нужна следующая помощь.
Нужны ответы и идеи на вопрос: "Где и Как в АСУ ТП можно применить декомпиляцию машинного кода?"
Объясню предпосылки.
Так получилось, что занимаюсь диссертацией на тему "метод восстановления алгоритмов машинного кода (МК)".
Это некий аналог декомпиляции, но не совсем.
Цель - обеспечение информационной безопасности (в условиях отсутствия исходного кода поиск НДВ - случайных ошибок программистов или злонамерянных закладок, обеспечение достоверности ПО и т.п.).
При этом, областью применения являются НЕ типичные ПК (с имеющимися уже средствами защиты, такими как антивирусы и т.п.; МК - для Intel, AMD, ...), а специализированные устройства - например маршрутизаторы (для роутеров Cisco и их IOS это крайне актуально; МК - для PowerPC, MIPS, ...). Изначально метод применялся для телекоммуникационных устройств.
НО необходимо данную тему максимально применить к АСУ ТП!
К сожалению, с АСУ ТП почти не знаком.
Ознакомился с общей теорией, практиками и существующими реализациями, но чувствую, что не хватает общения с реальными людьми.
То что уже понял касательно моего вопроса (прошу подправить):
1. на высоком уровне автоматизации:
- декомпиляция МК не особо нужна, т.к. SCADA работают на популярных OS, типа Windows/Linux для которых есть свои широкоизвестные средства защиты, постоянные обновления и фиксы; да и вообще, такие ОС явно не подходят для анализа на уровне ассемблера.
2. на среднем уровне автоматизации:
- часть PLC выполняет МК, которое может быть проприетарным и не иметь открытого исходного кода - а следовательно содержать закладки (как изначально, так и после обновления), которые могут быть более эффективно найдены по восстановленным алгоритмам;
- часть PLC содержит виртуальную машину, которая выполняет байткод IL и тут декомпиляция МК мало применима, поскольку реализация виртуальной машины скорее всего стандартная(открытая) и не содержит особых НДВ, а для восстановления программы по ее байткоду вполне достаточно существующих средств.
3. на низком уровне автоматизации:
- всевозможные датчики, исполнительные механизмы вполне могут быть выполнять МК и содержать НДВ;
4. маршрутизаторы для промышленных сетей (относится ли это к АСУ ТП?):
- так называемая CIsco "индустриализацией Интернета", выполненная например в таких продуктах, как Cisco Industrial Ethernet 2000/3000/..., т.е. телекоммуникации, распространенные в промышленном производстве
Готов к комментариям и обсуждению.
Спасибо.
- Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
- Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
- Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
- За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
- Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
- Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
- Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.
Где применимы методы декомпиляции машинного кода в АСУ ТП?
Модератор: kirillio
-
- новенький
- Сообщения: 1
- Зарегистрирован: 12 июл 2014, 01:17
- Имя: Константин
- Страна: Россия
- город/регион: Санкт-Петербург
-
- почётный участник форума
- Сообщения: 3577
- Зарегистрирован: 10 ноя 2009, 04:58
- Имя: Толмачев Михаил Алексеевич
- город/регион: г. Чехов, МО
- Благодарил (а): 6 раз
- Поблагодарили: 271 раз
Re: Где применимы методы декомпиляции машинного кода в АСУ Т
1) Многие ПЛК имеют извлекаемые флэшки, там лежат заветные скомпилированные коды, а иногда даже исходные проекты. Но то, что лежит во внутренней энергонезависимой памяти ПЛК не факт, что соответствует содержимому флэшки в виду изощренности врага. Если рассмотреть метод вражеского вируса под названием Stuxnet, то он зашивался в систему еще до этапа компиляции, на компьютерах с ОС Windows.
2) Подключаемый к контроллеру ноутбук с установленным программным обеспечением имеет обычно функцию сравнения исходного проекта с загруженным компилированным кодом. Иногда просто по штампу времени (по времени последнего изменения). Просто информация для сведения.
3) Подключенный ноутбук также может показывать состояние всех переменных в процессе работы ПЛК (диагностическая функция). Тоже для сведения.
4) Некоторых датчиков, а также аналоговых входов и выходов ПЛК (как средств измерения) могут касаться требования ГОСТ Р 8.654-2009 "Требования к программному обеспечению средств измерений". Содержание ГОСТа может быть интересно Вам.
5) Маршрутизаторы и прочее сетевое оборудование - это часть АСУТП. Любые заминки, ошибки, вирусы в этой части - останов АСУТП и производства.
2) Подключаемый к контроллеру ноутбук с установленным программным обеспечением имеет обычно функцию сравнения исходного проекта с загруженным компилированным кодом. Иногда просто по штампу времени (по времени последнего изменения). Просто информация для сведения.
3) Подключенный ноутбук также может показывать состояние всех переменных в процессе работы ПЛК (диагностическая функция). Тоже для сведения.
4) Некоторых датчиков, а также аналоговых входов и выходов ПЛК (как средств измерения) могут касаться требования ГОСТ Р 8.654-2009 "Требования к программному обеспечению средств измерений". Содержание ГОСТа может быть интересно Вам.
5) Маршрутизаторы и прочее сетевое оборудование - это часть АСУТП. Любые заминки, ошибки, вирусы в этой части - останов АСУТП и производства.
-
- осмотрелся
- Сообщения: 158
- Зарегистрирован: 25 окт 2010, 10:30
- Имя: Капуста Степан Степанович
- Поблагодарили: 7 раз
Re: Где применимы методы декомпиляции машинного кода в АСУ Т
Я Вас сразу же поправлю: типичному ПК никто не мешает быть ПЛК. Как пример: ICP-CON серий i7000 и i8000, ADAM серии 5000 /в серии 4000 я не помню что-то ПЛК/ - по своей сути почти обычные IBM PC\XT, только без видеокарт, контроллеров дисководов /FDD и HDD/, контроллеров LPT и со всеми устройствами не на "привычных" адресах. Никаких средств защиты у него нет.DeadBrother писал(а):При этом, областью применения являются НЕ типичные ПК (с имеющимися уже средствами защиты, такими как антивирусы и т.п.; МК - для Intel, AMD, ...), а специализированные устройства - например маршрутизаторы (для роутеров Cisco и их IOS это крайне актуально; МК - для PowerPC, MIPS, ...). Изначально метод применялся для телекоммуникационных устройств.
Слово "обеспечение ИБ" тут, как мне кажется, лишнее. И "обеспечение достоверности" тоже. Поиск ошибок, случайных или злонамеренных /т.н. "закладка"/ - не суть: тут согласен.DeadBrother писал(а):Так получилось, что занимаюсь диссертацией на тему "метод восстановления алгоритмов машинного кода (МК)".
Это некий аналог декомпиляции, но не совсем.
Цель - обеспечение информационной безопасности (в условиях отсутствия исходного кода поиск НДВ - случайных ошибок программистов или злонамерянных закладок, обеспечение достоверности ПО и т.п.).
Достоверность ПО обеспечивается контрольными суммами /если учитывать только объективные угрозы/ или хэш-суммами и/или электронными подписями /если учитывать и субъективные угрозы/. А обеспечение ИБ... Скорее всего, ИБ будет строиться с учетом найденых прорех... Т.е. уже вполне ремесленник справится.
Ошибочка вышла: SCADA - просто приложение, тоже предоставляет собой некую точку входа. Средства защиты, обновления, фиксы - это ОС, но не SCADA. ОС анализировать может и не стоит - их и так много народу анализирует на предмет НДВ. Но вот SCADA... Тут все не просто плохо, а гораздо хуже.DeadBrother писал(а):1. на высоком уровне автоматизации:
- декомпиляция МК не особо нужна, т.к. SCADA работают на популярных OS, типа Windows/Linux для которых есть свои широкоизвестные средства защиты, постоянные обновления и фиксы; да и вообще, такие ОС явно не подходят для анализа на уровне ассемблера.
Внутри SCADA крутится проект, который также может содержать ошибки и закладки. Тут, правда, декомпилировать, чаще всего, просто нечего: исходные коды всех скриптов обычно открыты. Тут разве что заниматься декомпиляцией дополнительных библиотек /даже древняя Advantech GeniDAQ 4.25 из скрипта могла вызывать функции из сторонних динамически загружаемых библиотек - DLL/.
Виртуальная машина тоже может содержать ошибки и закладки. Даже несмотря на то, что она иногда бывает с открытым исходным кодом /чаще все-таки и виртуальная машина тоже проприетарна/. Т.е. или декомпиляция и восстановление алгоритма или анализ исходных кодов и восстановление алгоритма. И как-то обеспечить проверку, что наличная виртуалка соответствует той, которая получилась после компиляции проверенных исходников: после компиляции чаще всего байт-код будет другим.DeadBrother писал(а):2. на среднем уровне автоматизации:
- часть PLC выполняет МК, которое может быть проприетарным и не иметь открытого исходного кода - а следовательно содержать закладки (как изначально, так и после обновления), которые могут быть более эффективно найдены по восстановленным алгоритмам;
- часть PLC содержит виртуальную машину, которая выполняет байткод IL и тут декомпиляция МК мало применима, поскольку реализация виртуальной машины скорее всего стандартная(открытая) и не содержит особых НДВ, а для восстановления программы по ее байткоду вполне достаточно существующих средств.
Кстати, уже упомянутый тут Stuxnet правил как раз виртуальную машину во вполне конкретных типах ПЛК, если находил там интересующий его проект.
Ну тут все просто: почти наверняка проприетарный код, в котором могут быть НДВ. Т.е. декомпиляция и...DeadBrother писал(а):3. на низком уровне автоматизации:
- всевозможные датчики, исполнительные механизмы вполне могут быть выполнять МК и содержать НДВ;
В общем-то уже можно отнести к АСУ... Тут так же, все так же, как и в предыдущем пунктеDeadBrother писал(а):4. маршрутизаторы для промышленных сетей (относится ли это к АСУ ТП?):
- так называемая CIsco "индустриализацией Интернета", выполненная например в таких продуктах, как Cisco Industrial Ethernet 2000/3000/..., т.е. телекоммуникации, распространенные в промышленном производстве
Как-то так в общем...
-
- частый гость
- Сообщения: 409
- Зарегистрирован: 20 ноя 2012, 13:45
- Имя: :.О.N.Ф
- Страна: Россия
- Благодарил (а): 3 раза
- Поблагодарили: 7 раз
Re: Где применимы методы декомпиляции машинного кода в АСУ Т
ну вот кстати вопрос можно ли IL считать самым низким уровнем инструкций аналогично асму, команды которого точь-в-точь транслируются в команды процессора. Если в ПЛК процы - тот же пентиум или АРМ... так что вполне есть интерес декомпиляции, по-моему.
«Сразу видно внимание к каждой мелочи, неиспорченным не осталось ничто».