Портирование иностранного ПО

Я полагаю, что это зависит от требований заказчика к тестовому покрытию кода. Из того, что я знаю, уже даже на ASIL B написание тестов становится более трудоёмкой задачей, чем написание алгоритмов.
Так, вроде, уже везде так.
 
Реклама
Наивность продолжает изливаться. Нормальный вендор, дорожащий продуктом, уж как-нибудь догадается закрыть (зашифровать) собственный код. Дабы всякие умные не могли там что-то поменять просто так
Это делается в редчайших случаях очень дорогих продуктов. Так как геммороя от такого решения для себя же самих вендор получает много больше, чем пользы.
 
Ну так это у вас небось эппл. Он отличается замкнутостью.
И все таки, где вы собираетесь добывать исходные коды? Или предполагается как-то взломать сертификат скомпилированного кода (крайно маловероятное событие) и получить "работающую" систему без возможности ее дальнейшей модификации?
 
Нет, это не эпл а ERP. И без сертификата кусок кода тупо не работает.
Ну так небось подписались на облачные сервисы. Себе на голову.
Или код внутри, в жабе? Тогда он там же внутри в кейчейне сидит и меняется легко и просто. Но при наличии знаний как его менять. В смысле не код а сертификат. В жабе кое где проверку выключить проблематично, приходится сертификаты руками впихивать и кстати в анализе рисков у меня риск #1 _протухшие сертификаты_, даже в США, стоят.
В вашем случае вам нужно в систему загрузить новые рут сертификаты (что сделать можно всегда) а потом поставить сертификаты уже сгенеренные на них. Это сделать можно практически всегда. Но если система толком не документирована то делать должны специалисты а не доморощенные любители.
Шифрованный софт. Ну аппл любит ставить ключи в бутявки, хотя и это давно уже умеют перепрограммировать, как скажем перепрограммируют все дроны при отправке на фронт - есть даже фирмы на этом специализирующиеся. Зашифрованный софт - с одной стороны мы такое сделали еще в 1985м году. С другой мало кто в здравом уме будет заниматься этим так как всегда можно снаружи подключиться через виртуализацию и скатать например тот же софт сразу после его расшифровки или же поменять ключи расшифровки на свои. В общем все это защита от идиота исключительно. Но главное, все можно закрыть. Но геммороя от закрытия закрывающий огребает столько что как правило ищут компромисс - закрывают от идиотов только чтобы самим себе не построить подножку. А уж в реал тайм софте закрывать шифрацией - это огрести неслабый шанс что у вас прямо в процессе все сломается на миллиард, мало кто так будет делать. Хотя например софт для литографов - верю если шифруют. А вот софт для скажем обычного GPS - никогда не поверю. Дураков таких немае.
 
И все таки, где вы собираетесь добывать исходные коды? Или предполагается как-то взломать сертификат скомпилированного кода (крайно маловероятное событие) и получить "работающую" систему без возможности ее дальнейшей модификации?
Так код управления то весь написан в России. Зачем там что то ломать. И для SSJ и для МС-21 все эти коды как раз изначально свои.

PS. А на фига мне ломать сертификат скомпилированного кода? Запускаем систему в виртуалке, после того как она инициализировалась замораживаем, получаем систему с расшифрованным кодом. И лазим снаружи сколько хотим. Защита от такого имеется в самых последних процессорах но ее мало кто будет использовать в приложениях да и нет у оных доступа туда, она делается скорее для того чтобы скажем в телефоне код который работает с радио (и который менять нельзя так как это нарушит сразу требования всяких там радио совместимостей) не менялся операционной системой или чтобы сторейдж для ключей не была легко доступна.
Я когда то читал лекции по секьюрити. И начинал с того что _нет никаких проблем закрыть что угодно_. Берем комп выключаем запираем в сейф. Делов то. Проблема дать доступ. А когда доступ дали, все обычно и ломается и довольно таки легко.
 
Это делается в редчайших случаях очень дорогих продуктов. Так как геммороя от такого решения для себя же самих вендор получает много больше, чем пользы.
Несопоставимо с количеством геморроя, получаемого вендором safety-critical устройства, позволяющего пользователю неконтролируемо патчить свою прошивку.
 
Ну так небось подписались на облачные сервисы. Себе на голову.
Или код внутри, в жабе? Тогда он там же внутри в кейчейне сидит и меняется легко и просто. Но при наличии знаний как его менять. В смысле не код а сертификат. В жабе кое где проверку выключить проблематично, приходится сертификаты руками впихивать и кстати в анализе рисков у меня риск #1 _протухшие сертификаты_, даже в США, стоят.
В вашем случае вам нужно в систему загрузить новые рут сертификаты (что сделать можно всегда) а потом поставить сертификаты уже сгенеренные на них. Это сделать можно практически всегда. Но если система толком не документирована то делать должны специалисты а не доморощенные любители.
Шифрованный софт. Ну аппл любит ставить ключи в бутявки, хотя и это давно уже умеют перепрограммировать, как скажем перепрограммируют все дроны при отправке на фронт - есть даже фирмы на этом специализирующиеся. Зашифрованный софт - с одной стороны мы такое сделали еще в 1985м году. С другой мало кто в здравом уме будет заниматься этим так как всегда можно снаружи подключиться через виртуализацию и скатать например тот же софт сразу после его расшифровки или же поменять ключи расшифровки на свои. В общем все это защита от идиота исключительно. Но главное, все можно закрыть. Но геммороя от закрытия закрывающий огребает столько что как правило ищут компромисс - закрывают от идиотов только чтобы самим себе не построить подножку. А уж в реал тайм софте закрывать шифрацией - это огрести неслабый шанс что у вас прямо в процессе все сломается на миллиард, мало кто так будет делать. Хотя например софт для литографов - верю если шифруют. А вот софт для скажем обычного GPS - никогда не поверю. Дураков таких немае.

Нет, не облачные. Нет, не эпл. Фантазируйте дальше, вы тут уже со своей цесноцентричностью стали местным мемом - видимо и про ПО так же хотите
 
Несопоставимо с количеством геморроя, получаемого вендором safety-critical устройства, позволяющего пользователю неконтролируемо патчить свою прошивку.
Ну и. И айфоны и андроиды давно уже хакнули. Иногда с перепайкой но ни одного устройства на которое хакеры не могут поставить свой софт - на сегодня не замечено.
 
А на фига мне ломать сертификат скомпилированного кода? Запускаем систему в виртуалке, после того как она инициализировалась замораживаем, получаем систему с расшифрованным кодом.
Получаем систему с машинным кодом, командами для процессора. Что с ним делать то? Тупо скопировать и поставить в продакшн? А потом выяснится, что часть кода разблокируется не сразу, а потом, при выполнении каких-то условий (ну типа как МКАС срабатывает фиг знает когда)
 
Так код управления то весь написан в России. Зачем там что то ломать. И для SSJ и для МС-21 все эти коды как раз изначально свои.
Софт для Талес и какой-нибудь Ханивелл пишут в РФ. Тогда все хорошо
 
Реклама
Представляю где-нибудь на торрент-трекере "Пакет прошивок авионики ССЖ-100. Кряк в архиве (отключите антивирус перед использованием)."

Если что, мы на главном авиационном форуме, обсуждаем на полном серьезе взлом талес, гармина и прочего, тссс!:oops:
 
Софт для Талес и какой-нибудь Ханивелл пишут в РФ. Тогда все хорошо
Ну так софт на котором написана система управления - не является чисто пропроетари талеса и ханивелла. Там только какие то API может и являются но они все наверняка документированны от и до. Так что я не понял зачем их то ломать? Софт написан в РФ, АПИ которым он пользуется задокументированн. Понятно что замену оных нужно сертифицировать. Но это не означает что софт придется переписывать (может только подправлять под какие то особенности API) или что придется самолет полностью ре-сертифицировать.

Кроме того не забываем что протоколы обмена данными которые оные Талес и Ханивелл используют - стандартизованны от и до. То есть там тоже нет ничего пропроетарного.

PS. Хотя скатать и разобрать софт на котором работает Гармин или там талес - можно без особых проблем. Нет там никаких шифраций, там железо вообще лохматейших годов используется.
 
Ну и. И айфоны и андроиды давно уже хакнули. Иногда с перепайкой но ни одного устройства на которое хакеры не могут поставить свой софт - на сегодня не замечено.
Вообще не понял смысла тезиса. Вы собираетесь коммерчески эксплуатировать самолёт, на который "хакеры смогли поставить свой софт" - или вы собираетесь импортозамещать не доступную более авионику?
 
Ну так софт на котором написана система управления - не является чисто пропроетари талеса и ханивелла.
А можно поконкретнее, что вы понимаете под "софт на котором написана система управленич"?
 
Ну так софт на котором написана система управления - не является чисто пропроетари талеса и ханивелла. Там только какие то API может и являются но они все наверняка документированны от и до. Так что я не понял зачем их то ломать? Софт написан в РФ, АПИ которым он пользуется задокументированн.
Какие-то АПИ. написанные под конкретную железку. Часть же РФ только конфиг, использующий предоставляемые функции АПИ использовать в указанных рамках.

Функция ограничения тангажа. Исполнение и какими эволюциями руля высоты будет выполняться лежит на Core. А часть кода РФ - "Ну пусть будет не больше 20 градусов. Пишем "20" "
 
Ну и еще. Почему на супер пупер открытом линуксе владельцы видеокарт нвидиа сидят на проприетарном драйвере, хотя попытки создать открытый вменяемый длится много лет? Ведь это массовое устройство, втыкается в стандартный разъем и исполняет документированные команды.
Тоже самое касается и в смартфоне по поводу того-же радиомодуля.
Драйвер и есть связь работы с конкретным железом.
 
Я полагаю, что это зависит от требований заказчика к тестовому покрытию кода. Из того, что я знаю, уже даже на ASIL B написание тестов становится более трудоёмкой задачей, чем написание алгоритмов.
покрытие кода давно прописано, утверждено и согласованно. И тесты, отвечающие требованиям заказчика давно созданы.
Так что не высасывайте из пальца проблемы там где их нет.
Перенос ПО с одного железа на другое выеденного яйца не стоит.
Да, тесты придется прогнать заново.
А изменения если и будут, то только на уровне драйверов периферии
 
покрытие кода давно прописано, утверждено и согласованно. И тесты, отвечающие требованиям заказчика давно созданы.
Так что не высасывайте из пальца проблемы там где их нет.
Перенос ПО с одного железа на другое выеденного яйца не стоит.
Да, тесты придется прогнать заново.
А изменения если и будут, то только на уровне драйверов периферии
Если у вас не получается начать с начала, попробуем начать с конца.

Как вы собираетесь заставлять Honeywell и Thales прогонять их тесты на вашем железе?
 
Реклама
Назад