Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 90
Правда, это уже четвертый кристалл данной, 7-ой версии Студии… Ну что поделаешь, не распространяются по Интернету апдейты, не могут.
Что-то я все же не понял, почему апдейты не могут распространяться по Интернету? Уникальная кодовая база апдейтам нисколько не мешает. Между устройством и сервером обновления устанавливается защищенный канал связи и хоть заобновляйся.
Потому что сервер не знает какая именно кодовая таблица используется в данном процессоре. Это не знает даже завод-изготовитель — сразу после изготовления партии и заливки программ, он стирает где на каком кристалле какая была кодовая база.
П.с. Статья написана в режиме максимальной паранойи, :-)
П.с. Статья написана в режиме максимальной паранойи, :-)
Есть криптография с открытым ключом, на крайний случай есть разделяемый секрет (shared secret) и соответствующие криптографические протоколы. Таким образом, можно установить безопасный канал связи между устройством и сервером обновлений.
Далее процессор передает свою конфигурацию, или она становится понятна серверу после процедуры аутентификации и сервер готовит нужное обновление. И, благодаря криптографии, с завода можно исключить утечку данных.
Поэтому, никаких принципиальных проблем с обновлением нет.
Возможно проблема в том, что вы не знакомы с криптографией.
Далее процессор передает свою конфигурацию, или она становится понятна серверу после процедуры аутентификации и сервер готовит нужное обновление. И, благодаря криптографии, с завода можно исключить утечку данных.
Поэтому, никаких принципиальных проблем с обновлением нет.
Возможно проблема в том, что вы не знакомы с криптографией.
Есть проблема физической утечки данных с завода третьим лицом. Это раз. Есть проблема нестойкости и/или взлома данного криптографического алгоритма/фремворка — вспомните о проблеме OpenSSL. Это два. Есть(и всегда будет) проблема таргетированной атаки на завод, когда на один сервер обрушивается мощь ботнета в миллион машин.
Так что, моя паранойя говорит, что хранить таблицу опкодов — не самый параноидальный режим :-)
Так что, моя паранойя говорит, что хранить таблицу опкодов — не самый параноидальный режим :-)
Есть проблема физической утечки данных с завода третьим лицом
Если вы говорите о этой проблеме, то почему считаете, что ей не подвержено производство «уникальных кристаллов»? Тоже самое абсолютно.
Безопасность основана на существовании доверия на каком-то уровне. Вы должны доверять или заводу, или службе, которая генерирует прошивки, или чему-либо еще. Если вы ничему не можете доверять, до безопасность не работает!
Есть проблема физической утечки данных с завода третьим лицом
Если вы говорите о этой проблеме, то почему считаете, что ей не подвержено производство «уникальных кристаллов»? Тоже самое абсолютно.
Не абсолютно.
Во-первых, будет скомпрометирована только текущая, производящаяся партия кристаллов. Кто будет их получателем — заранее не известно. Если хранить все таблицы, будут скомпрометированы ВСЕ произведенные кристаллы. Если, скажем, кристалл попал в комп президента и известен завод-изготовитель данного кристалла, то вопрос доступа к данным — это всего лишь вопрос времени.
Во-вторых, как правило, физическая утечка легче обнаруживается удаленного взлома(смотреть в сторону систем защиты информации. В частности, Dallas Lock). Т.е. в случае ЧП можно будет арестовать партию еще не проданных/лежащих на складе и т.п. кристаллов, что дешевле заменять уже проданные.
Но давайте предположим, что завод-разработчик не хранит у себя никаких таблиц, а просто их передает компании-разработчику. Что получится?
Одна и та же компания занимает лидирующее положение на рынке операционных систем, на рынке подготовки документов(Microsoft Office), на рынке сред разработки ну и так далее,… Отсюда: вопрос о взломе и похищении таблиц опкодов рано или поздно поднимет суммы, близкие к бесконечности(с т.з. обывателя). А дальше вопрос о физической утечки данных даже не будет стоять… он будет лежать и сам ползти к удобному месту.
Понимаете, весь профит в том, что ключей для расшифровки нет НИ У КОГО. Почему? Потому что имея на руках таблицу опкодов взлом удаленной системы становится не сложнее взлома в нынешних условиях.
П.с. я просто не знаю каким еще языком объяснить что паранойи в защите информации много не бывает.
Хочу ответ начать с конца, прокомментировав фразу «я просто не знаю каким еще языком объяснить что паранойи в защите информации много не бывает».
Если это так, тогда поясните, почему у корневого сертификата, который использует Google, длина ключа 2048 бит, а не 4096 бит или даже 65536 бит?
Если это так, тогда поясните, почему у корневого сертификата, который использует Google, длина ключа 2048 бит, а не 4096 бит или даже 65536 бит?
Выбор длины ключа всегда ограничивается снизу минимальным временем для взлома и сверху производительностью системы. В ситуации, когда подписывать приходится часто, ключ имеет смысл ограничивать хоть какой-то разумной длиной. А вот когда один раз зашифровал и время от времени расшифровываешь… DrWeb шифрования своих ключей использует 512 бит, NetBeans — 1024, Aspen One — 4096. Кому верить?
Так Вы до этого говорили, что паранойи много не бывает, а сейчас говорите, что бывает.
Кому верить, вам от 3 декабря днем, или вам от 3 декабря вечером?
Кому верить, вам от 3 декабря днем, или вам от 3 декабря вечером?
Эм… я вам уже говорил: статья написана в режиме максимальной паранойи. Собственно, без нее бы и не было статьи.
В тоже время, реальные производители, как правило, думают не только о безопасности, но и о производительности.
Кстати, первая ласточка реализации моих идей: http://senselock.ru/projects/senselock-vmprotect.php «выполнение кода защиты в ядре электронного ключа SenseLock;».
Как говориться, дальше будет больше :-)
В тоже время, реальные производители, как правило, думают не только о безопасности, но и о производительности.
Кстати, первая ласточка реализации моих идей: http://senselock.ru/projects/senselock-vmprotect.php «выполнение кода защиты в ядре электронного ключа SenseLock;».
Как говориться, дальше будет больше :-)
Идем дальше.
Поясните, как должно обеспечиваться отсутствие утечек «таблиц кристаллов» с вашего завода?
Как должно обеспечиваться отсутствие закладок аппаратной части кристаллов, которые намеренно вносят разработчики?
Как должно обеспечиваться отсутствие закладок в программном коде, которые намеренно вносят разработчики?
Поясните, как должно обеспечиваться отсутствие утечек «таблиц кристаллов» с вашего завода?
Как должно обеспечиваться отсутствие закладок аппаратной части кристаллов, которые намеренно вносят разработчики?
Как должно обеспечиваться отсутствие закладок в программном коде, которые намеренно вносят разработчики?
Последние два пункта — мимо кассы. Понимаете, ну внес к примеру, разработчик уязвимость, позволяющую выполнять произвольный код… только таблиц опкодов у него нет. И как следствие, он не может выполнить свой код. Остаются скрипты, но это настолько явная уязвимость… Доверие со стороны покупателей будет моментально подорвано.
Что же касается язвимостей со стороны процессора… ну, с выполнением кода мы уже разобрались. Осталась заранее заложенная уязвимость в виде выполнение кода на другой таблице опкодов, заранее известной разработчику процессора. Как думаете, как скоро вскроется такая закладка?
Самая засада с утечками с завода. Потому что контролировать отсутствие утечек можно только аудитом. А аудит безопасности, к сожалению, не решает проблемы разового физического выноса таблиц. Но, к счастью, после грамотного аудита безопасности почти невозможно скрыть факт физического выноса таблиц. Если, разумеется, злоумышленник — не завод. Но это тоже — быстро вскрывается и заводу на фиг не надо.
Что же касается язвимостей со стороны процессора… ну, с выполнением кода мы уже разобрались. Осталась заранее заложенная уязвимость в виде выполнение кода на другой таблице опкодов, заранее известной разработчику процессора. Как думаете, как скоро вскроется такая закладка?
Самая засада с утечками с завода. Потому что контролировать отсутствие утечек можно только аудитом. А аудит безопасности, к сожалению, не решает проблемы разового физического выноса таблиц. Но, к счастью, после грамотного аудита безопасности почти невозможно скрыть факт физического выноса таблиц. Если, разумеется, злоумышленник — не завод. Но это тоже — быстро вскрывается и заводу на фиг не надо.
Последние два пункта — мимо кассы. Понимаете, ну внес к примеру, разработчик уязвимость, позволяющую выполнять произвольный код…
Выполнять — это позднее. А прежде всего — простое чтение и запись памяти в указанное место, создание дампа.
После создания дампа и с возможностью модификации памяти разломать такую систему — дело относительно короткого времени независимо от того, известны вам опкоды или нет. Особенно, если этот процесс автоматизировать.
Осталась заранее заложенная уязвимость в виде выполнение кода на другой таблице опкодов, заранее известной разработчику процессора. Как думаете, как скоро вскроется такая закладка?
Может никогда не быть обнаружена, особенно, если эта закладка неявной формы. Это крайне сложно искать.
Так как с этим бороться?
Но, к счастью, после грамотного аудита безопасности почти невозможно скрыть факт физического выноса таблиц.
Это же должно иметь какое-то основание, а не фантазия про «грамотный аудит». Что такое грамотный аудит, на чем он основан, как он может выявить проблему? Почему криминал не может подкупить/запугать людей, ответственных за аудит и он будет смотреть на все сквозь пальцы?
Докажите, что ваша задача вообще решаема.
Последние два пункта — мимо кассы. Понимаете, ну внес к примеру, разработчик уязвимость, позволяющую выполнять произвольный код…Выполнять — это позднее. А прежде всего — простое чтение и запись памяти в указанное место, создание дампа.
Согласен. Это — потенциально уязвимая ситуация. И она лмбо решается доверием к софту, либо никак не решается…
Осталась заранее заложенная уязвимость в виде выполнение кода на другой таблице опкодов, заранее известной разработчику процессора. Как думаете, как скоро вскроется такая закладка?Может никогда не быть обнаружена, особенно, если эта закладка неявной формы. Это крайне сложно искать.
Так как с этим бороться?
http://www.infox.ru/science/enlightenment/2016/01/27/Matyematiki_dokazali.phtml
Т.е. с железом, с которым имеют дело тысячи и миллионы разработчиков, вскрытие такой ситуации — дело полгода… Особенно, если за дело возьмется кто-то подобный Мыщъху(он же Крис Касперски).
Но, к счастью, после грамотного аудита безопасности почти невозможно скрыть факт физического выноса таблиц.Это же должно иметь какое-то основание, а не фантазия про «грамотный аудит».
Разумное возражение.
1)Смотрите, если право на аудит безопасности будет иметь любой, кто хочет заказать выпуск кристаллов на данном заводе, то и аудит будет проводится их силами или силами наемной команды. Т.е. в любом случае, не местными, а приезжими, прибывшими буквально на день-два, живущими на территории завода. Как думаете, имеет ли смысл им угрожать, если они уедут и смогут обратиться в правоохранительные органы той страны, из которой они приехали? Или как быстро вскроется подкуп при таком количестве аудитов?
2)Аудит безопасности проводится так, чтобы доказать вероятность взлома/утечки на компании-цели. Если идет удаленный аудит, то компания даже может и не знать о таком мероприятии. Если локальный — изымаются записи с камер безопасности, тщательно проверяются, проверяются рабочие места, проверяются права на предмет доступа к информации, проверяется вообще все, что только можно.
В 2004-ом такой аудит внезапно нашел скрытую камеру в цеху на том заводе, где я работал… Думаю, с тех пор средства и методы а аудиторов подросли…
Я не разделяю идей автора, по мне, так никакой президент или кто-то другой не в силах изменить ход развития IT так радикально. Но эти вопрос про таблицы мне представляется очевидным. Вот вам три варианта.
1. Таблицы создаются временно, в процессе записи кристалла. Нигде не хранятся.
2. При инициализации кристалл сам генерит себе таблицу команд и транслирует софт из «базовой» таблицы в свою.
3. Таблицы создаются и хранятся, но зашифрованы ключом, половина которого прошита на кристалле (он же его уникальный номер) — без ключа к ним доступа нет. Это вариант на случай необходимости отладки после возврата кристалла изготовителю.
1. Таблицы создаются временно, в процессе записи кристалла. Нигде не хранятся.
2. При инициализации кристалл сам генерит себе таблицу команд и транслирует софт из «базовой» таблицы в свою.
3. Таблицы создаются и хранятся, но зашифрованы ключом, половина которого прошита на кристалле (он же его уникальный номер) — без ключа к ним доступа нет. Это вариант на случай необходимости отладки после возврата кристалла изготовителю.
Senselock и раньше это все умел.
VMProtect там прикручен чтобы пользователю не приходилось возится с выделением части кода, которая будет грузится на ключ (с чем есть проблемы — бесплатный компилятор SDCC может давать код только для тормозного режима работы, а 'платный' быстрый надо покупать задорого и не у не них).
ну и скорость… не очень и это мягко говоря (правда крипто-функции имеют аппаратную реализацию).
VMProtect там прикручен чтобы пользователю не приходилось возится с выделением части кода, которая будет грузится на ключ (с чем есть проблемы — бесплатный компилятор SDCC может давать код только для тормозного режима работы, а 'платный' быстрый надо покупать задорого и не у не них).
ну и скорость… не очень и это мягко говоря (правда крипто-функции имеют аппаратную реализацию).
Сервер не знает, но кристалл-то знает. Он может получать данные в стандартной кодовой таблице и транслировать их в свою. Делов-то…
Это потенциально уязвимая ситуация. Появляется дыра: можно попробовать притвориться имеющим право на запись и записать вирус в стандартной кодовой таблице. Т.е. вместо задачи расшифровки таблицы опкодов задача сведется к задаче «притворись право имеющим».
Хотя… это потенциально решаемая задача. Предположим, на процессор лежит открытый ключ, зашитый разработчиком. Он служит для получения сессионного ключа… ну и для идентификации. А дальше — по вашей схеме…
Тут возникает вопрос утечки ключей… В режиме максимальной паранойи легко предположить, что и они утекут, где бы не лежали. Ну, просто предположим, что в качестве программы выступает ОС, установленная на компе президента. И, соответственно, суммы на получение закрытого ключа моментально достигают пределов что-то около бесконечности(для обывателя, см ситуацию с Нотчем). Как думаете, как скоро такой ключ будет получен?
Хотя… это потенциально решаемая задача. Предположим, на процессор лежит открытый ключ, зашитый разработчиком. Он служит для получения сессионного ключа… ну и для идентификации. А дальше — по вашей схеме…
Тут возникает вопрос утечки ключей… В режиме максимальной паранойи легко предположить, что и они утекут, где бы не лежали. Ну, просто предположим, что в качестве программы выступает ОС, установленная на компе президента. И, соответственно, суммы на получение закрытого ключа моментально достигают пределов что-то около бесконечности(для обывателя, см ситуацию с Нотчем). Как думаете, как скоро такой ключ будет получен?
Думаю, что это частично решается разделением прав доступа и физическим переключателем.
Например, «ОС» апдейтить невозможно. Основной софт — только из аналога «рекавери», для чего придется кристалл вытащить и вставить другой стороной, например. А вот плагины — без ограничений, но лишь с подтверждения пользователя. Никакого автоапдейта. Как-то так.
Например, «ОС» апдейтить невозможно. Основной софт — только из аналога «рекавери», для чего придется кристалл вытащить и вставить другой стороной, например. А вот плагины — без ограничений, но лишь с подтверждения пользователя. Никакого автоапдейта. Как-то так.
А вот толку от этого… плагины замают пользователя просьбой дёрнуть переключатель по малейшему поводу и вплоть до «не буду работать пока не разрешишь обновление, потому что существенно изменилось API и старое уже не поддерживается». И самое главное — дергая переключатель ТЫ НЕ БУДЕШЬ ЗНАТЬ что именно там обновилось. Даже в случае полностью открытых исходников — у тебя просто не будет времени на анализ изменений в плагине, и того какую потенциальную угрозу они несут.
И чем больше плагинов тем больше подобного ада.
И чем больше плагинов тем больше подобного ада.
Описана разновидность security through obscurity (в данном случае — рандомная таблица опкодов). В общем случае — ни от чего не защищает. Т.к. обмен с внешним миром, судя по всему предполагается, то удаленной таргетированной атакой на конкретный процессор можно восстановить всю таблицу опкодов, а дальше — дело техники.
Эм… а можно поконкретней. Вот у нас есть, грубо говоря, найденная ошибка переполнения буфера.
Как именно можно восстановить кодовую таблицу?
Общую технику атаки я знаю — куча NOP, потом код атаки. Но как можно в этом случае заставить удаленную машину ответить на данный адрес?
П.с. вариант перебрать все варианты опкодов — не вариант, это 2^64 комбинаций.
Как именно можно восстановить кодовую таблицу?
Общую технику атаки я знаю — куча NOP, потом код атаки. Но как можно в этом случае заставить удаленную машину ответить на данный адрес?
П.с. вариант перебрать все варианты опкодов — не вариант, это 2^64 комбинаций.
Проблема обфускации в том, что а) поле вариантов изначально сужено до изначального набора кодов, б) одна и та же изначальная лексема сопоставляется строго одной и той же обфусцированной лексеме, в) правила связывания лексем между собой семантически предопределены (к примеру, две инструкции mov ax, bx и mov ax, cx не будут следовать подряд друг за другом). К примеру, предположим, что есть язык, в котором есть две буквы, а длина слов ограничена 2 символами. Тогда в языке может быть не более 6 слов. Теперь как бы вы не обфусцировали предложения на этом языке, проблема перебора возможных вариантов сильно сужается указанными правилами. Поэтому нет и не будет никаких 2^64 комбинаций (которых, впрочем, тоже весьма мало для сколь-нибудь эффективной криптозащиты).
Переполнение буфера это не атака, а уязвимость, открывающая вектор атаки. В вашем примере все еще проще — уязвимостью является сам подход, для которого известны ограничения а, б и в (см. выше).
Переполнение буфера это не атака, а уязвимость, открывающая вектор атаки. В вашем примере все еще проще — уязвимостью является сам подход, для которого известны ограничения а, б и в (см. выше).
Понимаете, 2^64 — это количество вариантов для одного опкода на 64-х битном процессоре. Да, при этом, само поле опкодов много меньше 2^64. Ну, пусть будет около 100 000. На самом деле, для успешной атаки и того меньше — около ста, двухсот. Проблема в том, что вам придется вычислять каждый отдельный опкод. Так как их много меньше 2^64, то итоговое число вариантов составит что-то около 2^72 — 200. Теперь, идем дальше.
Атака удаленная. У меня на сайте на ввод пароля админа давалось 3 попытки, после чего шло блокирование IP-адреса сроком на год.
Так как число опкодов много меньше числа вариантов опкодов, то что мешает заложить в процессор исключение типа «идет атака» на незадействованные опкоды? Как думаете, какое число исключений процессора кристалла будет заложено для блокировки IP-адреса?
Атака удаленная. У меня на сайте на ввод пароля админа давалось 3 попытки, после чего шло блокирование IP-адреса сроком на год.
Так как число опкодов много меньше числа вариантов опкодов, то что мешает заложить в процессор исключение типа «идет атака» на незадействованные опкоды? Как думаете, какое число исключений процессора кристалла будет заложено для блокировки IP-адреса?
В простейшем случае не нужно вычислять каждый отдельный опкод. К примеру, я приду к вам в гости и пока вы будете заваривать мне чай на кухне, незаметно перекопирую стандартную программу Калькулятор с вашего ПК к себе на флешку. Я на халяву получу почти всю таблицу кодов процессора и это без малейшего брута, исключительно соц. инженерией. При удаленной атаке слегка посложнее, но так же нет ничего невероятного в том, чтобы словить в сетевых пакетах мусор из кодового сегмента при том же пресловутом выходе за границы памяти. Вопрос целенаправленности атаки — не более.
Блин… я, кажется, забыл упомянуть, то получить скомпилированную программу можно только с процессора разработчика и никак иначе… Ну, то есть, на стандартном кристалле отсутствует доступ к внутреннему жесткому диску. Прощу прощения за эту оплошность.
Я для этого и ввел процессор разработчика, чтобы было возможно хоть как-то разрабатывать программы.
Ну и разумеется, скомпилированный код не передается по сети — это явно указано.в самом начале, когда приходит кристалл с очередным обновлением. Меня, правда, выше пытались убедить, что хранить таблицы опкодов для каждого конкретного процессора — это безопасно, но пока не смогли.
Я для этого и ввел процессор разработчика, чтобы было возможно хоть как-то разрабатывать программы.
Ну и разумеется, скомпилированный код не передается по сети — это явно указано.в самом начале, когда приходит кристалл с очередным обновлением. Меня, правда, выше пытались убедить, что хранить таблицы опкодов для каждого конкретного процессора — это безопасно, но пока не смогли.
Ну, если программы нельзя изменять, то это не интересно. Тогда и вся свистопляска с обфускацией не нужна, т.к. любая атака направлена на модификацию штатного кода. А если это невозможно, то и смысла рассуждать дальше нет. Проще тогда взять какой-нибудь матричный проц, типа FPGA и «напрожигать» в нем программ, аля MS Office.
Обфускация нужна. Так как остается возможность править код в оперативной памяти — именно так и происходят атаки по переполнению буфера. И я не знаю будет там FPGA или обычный перезаписываемый флэш-накопитель. Кроме того, там может быть просто энергонезависимый накопитель без разделения ОЗУ/долговременная память. Доводов «за» достаточно для обоих вариантов.
Современная криптография давно доказала, что обфускация не дает практически никакого увеличения сложности шифра.
Вы не знаете контекста…
Вы прежде чем влезать, почитали бы всю переписку начиная со статьи. В данном случае, у нас не обычная обфускация, а ее реализация через замену опкодов.
Я это указывал вот здесь: https://geektimes.ru/post/283316/#comment_9729206, и вот здесь:https://geektimes.ru/post/283316/#comment_9729408…
Ну и годная статья про виртуальный процессор: http://citforum.ru/security/software/virt_proc/
Вы прежде чем влезать, почитали бы всю переписку начиная со статьи. В данном случае, у нас не обычная обфускация, а ее реализация через замену опкодов.
Я это указывал вот здесь: https://geektimes.ru/post/283316/#comment_9729206, и вот здесь:https://geektimes.ru/post/283316/#comment_9729408…
Ну и годная статья про виртуальный процессор: http://citforum.ru/security/software/virt_proc/
В криптографии есть понятие стойкости. Так как ваша обфускация является конечной табличной заменой — не добавляет стойкости вообще. Вот если б у вас была безконечная таблица — тогда да, но это недостижимо в описываемых вами параметрах
Вы не понимаете сути того, на что ссылаетесь. Если у вас есть зашифрованный текст и расшифрованный текст — то да, табличная замена ничего не дает. Но если у вас есть только черный ящик, в котором вы не можете получить доступа ни к зашифрованному тексту, ни к расшифрованному и вынуждены отправлять туда что-то вслепую, причем при неправильной команде все просто блокируется — таблица обеспечит не просто большую, но практически абсолютную криптостойкость.
Как раз теоретическая криптография и все ее теоремы и имеют дело с черными ящиками. Тут будут как минимум стандартные програмные блоки, стандартный ввод и стандартный вывод. В описанном вами случае стойкость регулируется фразой «все просто блокируется»(хотя это очень не просто, будет самоблокироватся/зависать), а не обфускацией.
Стандартный ввод и стандартный вывод не должны давать возможность запускать произвольный код на выполнение. Т.е. вы не можете сказать: «а вот выполни-ка мне такую-то команду и верни результат».
Ваш стандартный ввод — это положение мыши и ввод с клавиатуры. А вывод — готовая картинка. Т.е., как написали ниже — взломать игру «волк ловит яйца» используя только кнопки на игрушке.
Ваш стандартный ввод — это положение мыши и ввод с клавиатуры. А вывод — готовая картинка. Т.е., как написали ниже — взломать игру «волк ловит яйца» используя только кнопки на игрушке.
RSA так же является конечной табличной заменой. Как говориться, все дело в длине ключа. Длина ключа в данном случае — 128 бит. Количество опкодов — порядка сотни тысяч(в наибольшем случае) Но! При первом же промахе процессор будет знать что ломают. И как он среагирует — неизвестно.
У вас не просто черный ящик, у вас активный черный ящик, который на неверную информацию будет реагировать.
У вас не просто черный ящик, у вас активный черный ящик, который на неверную информацию будет реагировать.
Ну займитесь, что ли, теорией. Есть очень много методов дающих тот же эффект гараздо меньшими усилиями. Тут будет взломать относительно легко, поскольку вы будете запускать стандартный програмный код.
RSA так же является конечной табличной заменой. Как говориться, все дело в длине ключа. Длина ключа в данном случае — 128 бит
Тут дело в стойкости алгоритма, а не длине ключа.
К примеру, циклическое наложение по XOR ключа длиной 1024 бит на документ в несколько мегабит легко ломается.
Так и в случае шифрования опкодов: каждый опкод шифруется независимо, есть устойчивые сочетания (push ebp / mov ebp, esp или mov esp, ebp / pop ebp / ret) которые сразу отбиваются статистикой. С точки зрения криптоанализа (если снят дамп), это сводит сложности к нулю.
У вас нет возможности получить дамп. Кажется, я учел все возможности, чтобы этого избежать. Обфускация же проводится для того, чтобы предотвратить выполнение произвольного кода, поступившего из вне.
Ну, грубо говоря, при успешной хакерской атаки. В этом случае, у хакера не будет возможности снять дамп(разумеется, если не предусмотрено уже скомпилированным кодом программы), а только запустить на выполнение свой код.
И вот для того, чтобы этот код не запустился и при этом послал сигнал программе о взломе, и используется обфускация.
П.с. и да, скриптовые языки я тоже грохнул.
Ну, грубо говоря, при успешной хакерской атаки. В этом случае, у хакера не будет возможности снять дамп(разумеется, если не предусмотрено уже скомпилированным кодом программы), а только запустить на выполнение свой код.
И вот для того, чтобы этот код не запустился и при этом послал сигнал программе о взломе, и используется обфускация.
П.с. и да, скриптовые языки я тоже грохнул.
Так, я сейчас попытаюсь объяснить вариант а для себя своими словами. Если я не прав, поправляйте.
Вы говорите, что если у нас есть три числа 100, 010, 001, то мы можем поменять только 100 на 010 или 001, но не на 20 или 30. Так?
П.с. тема обфускации для меня нова, и я тут полный даун… но я уже читаю по ней статьи :-)
Вы говорите, что если у нас есть три числа 100, 010, 001, то мы можем поменять только 100 на 010 или 001, но не на 20 или 30. Так?
П.с. тема обфускации для меня нова, и я тут полный даун… но я уже читаю по ней статьи :-)
Пока все верно понимаете.
По большому счету, метод, который вы предложили в железе, уже много лет используется в софтовом исполнении. Это т.н. метод виртуальных машин (например, можно сразу смотреть п. 3). Взлом такой защиты затруднен, только если применяется многоуровневый стек виртуализации (в современных системах защиты ПО — это несколько десятков слоев виртуализации).
По большому счету, метод, который вы предложили в железе, уже много лет используется в софтовом исполнении. Это т.н. метод виртуальных машин (например, можно сразу смотреть п. 3). Взлом такой защиты затруднен, только если применяется многоуровневый стек виртуализации (в современных системах защиты ПО — это несколько десятков слоев виртуализации).
ШТО?!!! Один слой виртуализации — замедление в десятки раз… А десятки слоев оставят от моих 2,6 ГГц… Ну-ка 10^10 = 10 000 000 000, т.е останется 2,6Гц. кажется, у вас где-то ошибка… Или я вас не понял.
Кроме того, по ссылке ясно написано — замена опкодов на другие дает надежный, трудновзламываемый вариант.
Кроме того, ваше согласие с предыдущим ответом — это неверное понимание ситуации. Опкоды могут быть любые, а не только из числа используемых. Просто потому, что железо не стеснено недостатками ассемблера. Т.е. нам не надо маскироваться под уже существующие опкоды. Грубо говоря, мы можем вместо однобайтного опкода, унаследованного аж от 80086 указать 8-и байтный… а то и вовсе 16-и, чтобы жизнь медом не казалась :-)
Почему виртуальный процессор сейчас взламывается? Потому что на руках у злоумышленника есть таблица соответствий, зашитая в программу. Восстановить по ней машинный код защищенного модуля — задача сложная, но реализуемая. У меня же основная сложность в том, что эту таблицу не получить так легко и просто: нет доступа к скомпилированным кодам, только методом тыка с риском запороть процессор(см upd2). Если я, конечно, правильно понял статью :-)
Кроме того, по ссылке ясно написано — замена опкодов на другие дает надежный, трудновзламываемый вариант.
Кроме того, ваше согласие с предыдущим ответом — это неверное понимание ситуации. Опкоды могут быть любые, а не только из числа используемых. Просто потому, что железо не стеснено недостатками ассемблера. Т.е. нам не надо маскироваться под уже существующие опкоды. Грубо говоря, мы можем вместо однобайтного опкода, унаследованного аж от 80086 указать 8-и байтный… а то и вовсе 16-и, чтобы жизнь медом не казалась :-)
Почему виртуальный процессор сейчас взламывается? Потому что на руках у злоумышленника есть таблица соответствий, зашитая в программу. Восстановить по ней машинный код защищенного модуля — задача сложная, но реализуемая. У меня же основная сложность в том, что эту таблицу не получить так легко и просто: нет доступа к скомпилированным кодам, только методом тыка с риском запороть процессор(см upd2). Если я, конечно, правильно понял статью :-)
Один слой виртуализации — замедление в десятки раз
ЧЁ?
Тут имеется ввиду виртуальный процессор — замена одного опкода другим. И да, это-таки в десятки раз.
в десятки раз, это когда пытаешься виртуализировать процессор с мощной системой команд на более простом, например виртуализировать процессор Core i5 на физической машине с 80286 процессором. Тогда да, одну команду из набора SSE3 физический процессор будет выполнять сотню тактов заменяя её последовательностью из более простых команд…
Но нынешняя виртуализация идёт практически 1 к 1 за исключением небольшого оверхеда в считанные проценты, и то в случае необходимости эмуляции отсутствующих модулей/функций на более нижнем уровне. А если мы попытаемся эмулировать i5 процессор на i7 то потеряем лишь считанные проценты, и скорей всего только на уровне переключения контекста между процессами.
Где-то была статья по отлову китайского гипервизора на китайских платах, так вот оттуда я узнал что современные компьютеры уже достаточно виртуальны, наша операционная система уже является 3 или даже 5-м вложенным уровнем виртуализации… т.е. до того как исполнение кода доходит до загрузочного сектора уже имеем 3 уровня виртуализации или и того больше. ОС даёт ещё несколько уровней… при этом узнать реальный уровень виртуализации — практически невозможно, только если воспользоваться аппаратным счётчиком тактов самого процессора, который, впрочем, тоже можно виртуализировать.
Но нынешняя виртуализация идёт практически 1 к 1 за исключением небольшого оверхеда в считанные проценты, и то в случае необходимости эмуляции отсутствующих модулей/функций на более нижнем уровне. А если мы попытаемся эмулировать i5 процессор на i7 то потеряем лишь считанные проценты, и скорей всего только на уровне переключения контекста между процессами.
Где-то была статья по отлову китайского гипервизора на китайских платах, так вот оттуда я узнал что современные компьютеры уже достаточно виртуальны, наша операционная система уже является 3 или даже 5-м вложенным уровнем виртуализации… т.е. до того как исполнение кода доходит до загрузочного сектора уже имеем 3 уровня виртуализации или и того больше. ОС даёт ещё несколько уровней… при этом узнать реальный уровень виртуализации — практически невозможно, только если воспользоваться аппаратным счётчиком тактов самого процессора, который, впрочем, тоже можно виртуализировать.
Это все работает в том случае, если частично совпадают таблицы команд. Тогда нужно эмулировать только те команды, которых нет в процессоре. У нас другая ситуация — у нас подмена опкодов. Т.е. даже не на уровне ассемблера, а на уровне машинных команд. Так вот, в этом случае используется виртуальный процессор, который декодирует конкретную команду в какую-то другую, заранее не известную.
Современные виртуальные процессоры, используемые не в системах виртуализации, а в системах обфускации(еще раз, мы не про те процессоры говорим), как правило, работают достаточно медленно — как раз из-за подмены команд + промахов конвейера.
При этом, так как схему команд одного процессора хакеру построить вполне себе реально, в обфусцированной программе используется несколько виртуальных процессоров — в зависимости от параноидальности настройщика, может быть для каждого модуля свой процессор. Это еще более затрудняет жизнь хакеру, но еще более увеличивает количество промахов конвейера.
Вполне себе допускаю, что для улучшения производительности, используются приемы, о которых я мало знаю — к примеру, как пишут ниже, дешефрация строки кэша, а потом ее исполнение. Но даже в этом случае, все равно будет дешифровки — от нее никуда не денешься. И это будет замедление в 3-5 раз.
в описанной вами статье используется другая схема виртуализации — там просто идет логирование системы команд. И да, это замедление не в десятки раз, а всего-то в полтора-два…
Современные виртуальные процессоры, используемые не в системах виртуализации, а в системах обфускации(еще раз, мы не про те процессоры говорим), как правило, работают достаточно медленно — как раз из-за подмены команд + промахов конвейера.
При этом, так как схему команд одного процессора хакеру построить вполне себе реально, в обфусцированной программе используется несколько виртуальных процессоров — в зависимости от параноидальности настройщика, может быть для каждого модуля свой процессор. Это еще более затрудняет жизнь хакеру, но еще более увеличивает количество промахов конвейера.
Вполне себе допускаю, что для улучшения производительности, используются приемы, о которых я мало знаю — к примеру, как пишут ниже, дешефрация строки кэша, а потом ее исполнение. Но даже в этом случае, все равно будет дешифровки — от нее никуда не денешься. И это будет замедление в 3-5 раз.
в описанной вами статье используется другая схема виртуализации — там просто идет логирование системы команд. И да, это замедление не в десятки раз, а всего-то в полтора-два…
Один слой виртуализации — замедление в десятки раз
Вы случаем не из прошлого, когда виртуализация только начала развиваться?
Нынче виртуальные машины работают почти 1:1 по производительности с хостом.
Недавно проверял производительность виртуальной машины с хостом — получил результат с разницой в пределах погрешности.
Извините, но тут речь идет не о виртуальной машине, а о виртуальном процессоре. — замена одного опкода другим. И да, это-таки в десятки раз.
А что это мешает делать на аппаратном уровне?
Есть стандартный процессор со стандартными опкодами, при загрузке из защищенной зоны считывается таблица соответствия опкодов, эта таблица опкодов прожигается на заводе при изготовлении процессора… по сути это у вас и описано в тексте
Ну, или сделать загрузку таблицы опкодов динамической, из памяти доступной только для записи для всех кроме процессора.
Есть стандартный процессор со стандартными опкодами, при загрузке из защищенной зоны считывается таблица соответствия опкодов, эта таблица опкодов прожигается на заводе при изготовлении процессора… по сути это у вас и описано в тексте
Ну, или сделать загрузку таблицы опкодов динамической, из памяти доступной только для записи для всех кроме процессора.
Набор опкодов определяется случайным образом на заводе-производителе при прожиге пластины.
Современные системы защиты информации пока так делать не умеют. Ну и современные процессоры тоже не умеют. Я потому и описал развитие систем защиты программного обеспечения именно в «железном» варианте как вариант скорого будущего :-)
И-таки да, я считаю, что к этому мы и придем.
Главный минус динамических таблиц опкодов в процессоре — постоянные промахи конвейера и таблицы предсказания переходов. Но мысль интересная… Ее можно обдумать. Спасибо.
Интересно будет услышать мнение кого-нибудь из Интела по поводу такой системы защиты :-)
И-таки да, я считаю, что к этому мы и придем.
Главный минус динамических таблиц опкодов в процессоре — постоянные промахи конвейера и таблицы предсказания переходов. Но мысль интересная… Ее можно обдумать. Спасибо.
Интересно будет услышать мнение кого-нибудь из Интела по поводу такой системы защиты :-)
Ерунда это. Практически каждый СОВРЕМЕННЫЙ процессор имеет аппаратную систему декодирования команд. Тоесть в данном случае речь идет о модификации таблицы декодирования, что вообще никак не скажется на реальном выполнении.
Наверно имеете в виду таблицу опкод-микрокод? Такая таблица есть и сейчас, но она ограниченного размера по банальным причинам — быстродествие дешифраторов падает пропорционально разрядности дешифратора, а в процессоре он должен работать на частоте ядра, поэтому основная часть этой «таблицы» выполнена на жёсткой минимизированной логике.
Потом, микрокод жестко завязан на дешифратор команд.
А этот самый дешифратор команд является узким местом в процессоре — от него зависит длительность исполнения каждой микрокоманды и максимальная рабочая частота процессора, соответственно его оптимизируют таким образом чтобы обеспечивал минимальный путь сигнала через логическую матрицу, с другой таблицей микрокодов минимальный путь может неожиданно оказаться длиннее, и процессор не сможет работать на максимальной частоте.
Потом, микрокод жестко завязан на дешифратор команд.
А этот самый дешифратор команд является узким местом в процессоре — от него зависит длительность исполнения каждой микрокоманды и максимальная рабочая частота процессора, соответственно его оптимизируют таким образом чтобы обеспечивал минимальный путь сигнала через логическую матрицу, с другой таблицей микрокодов минимальный путь может неожиданно оказаться длиннее, и процессор не сможет работать на максимальной частоте.
таак, хорошо. чтобы вскрыть — нам надо таблицу трансляции получить, и это единственное чем кристаллы отличаются?
вызываем например BarsMonster, даем ему электронный микроскоп, кристалл разработчика и несколько копий того что надо + несколько копий того что нам НЕ надо и просим помочь.
он составляет карту кристалла и выясняет где там — 'ssd' с программой а где таблица опкодов.
затем даем еще один кристалл с тем что надо, считывает программу (вот правда как… к кристаллу разработчика можно подключить нестандартные внешние устройства?) а затем — таблицу опкодов.
вызываем например BarsMonster, даем ему электронный микроскоп, кристалл разработчика и несколько копий того что надо + несколько копий того что нам НЕ надо и просим помочь.
он составляет карту кристалла и выясняет где там — 'ssd' с программой а где таблица опкодов.
затем даем еще один кристалл с тем что надо, считывает программу (вот правда как… к кристаллу разработчика можно подключить нестандартные внешние устройства?) а затем — таблицу опкодов.
Нет, мне нравится эта идея! В самом деле нравится! Вы хотите взломать тот кристалл, который есть у ВАС тупо его разобрав!
Ну-ка, что нам известно про современные процессоры? Интел заявила о переходе на 5 нанометровый техпроцесс:
http://www.mobiledevice.ru/78783-intel-processor-roadmap-processor-intel-core.aspx
При этом, расстояние между двумя атомами железа всего — 2,5•10^−10 м. Т.е. толщина дорожки — 20 атомов. Офигеть, да? Любая тяжелая частица ее разорвет… То есть, при снятии защитного кожуха с кристалла в незащищенном помещении, вы получаете кашу вместо процессора. Вы согласны экранировать ваше помещение от тяжелых частиц?
Но допустим, вы решили и эту проблему. Ваш доблестный BarsMonster, разрушив сотню кристаллов в попытке научится снимать кожух и клей без разрушения кристалла(5 нанометров, помним?), получил-таки таблицу опкодов! Потом он научился снимать намагниченность с флэш-структур(честно, не знаю как она работает)… Сколько у него уйдет времени на один кристалл?
Вряд ли месяц… скорее, полгода-год…
Ну-ка, что нам известно про современные процессоры? Интел заявила о переходе на 5 нанометровый техпроцесс:
http://www.mobiledevice.ru/78783-intel-processor-roadmap-processor-intel-core.aspx
При этом, расстояние между двумя атомами железа всего — 2,5•10^−10 м. Т.е. толщина дорожки — 20 атомов. Офигеть, да? Любая тяжелая частица ее разорвет… То есть, при снятии защитного кожуха с кристалла в незащищенном помещении, вы получаете кашу вместо процессора. Вы согласны экранировать ваше помещение от тяжелых частиц?
Но допустим, вы решили и эту проблему. Ваш доблестный BarsMonster, разрушив сотню кристаллов в попытке научится снимать кожух и клей без разрушения кристалла(5 нанометров, помним?), получил-таки таблицу опкодов! Потом он научился снимать намагниченность с флэш-структур(честно, не знаю как она работает)… Сколько у него уйдет времени на один кристалл?
Вряд ли месяц… скорее, полгода-год…
Кстати, спасибо за BarsMonster! Потрясающий человечище! Я аж зачитался :-)
опен сорс один раз поднапряжётся и сделает кристалл, на котором запустится любая GNU совместимая программа
… т.е. любая из имеющихся десяти, хоть на что-то годных. Ну и конечно, будет зверски тормозить, отставать в развитии от своих коммерческих собратьев на десяток-другой лет, но зато GNU же!
Четыре байта на опкод, значит? Возможно будет собрать аппаратный брутфорсер, который будет гонять всевозможно скомпилированные программы на «кристалле», до победного конца. Либо вирус будет сам подбирать, закон Мура ведь позволит и вирусам наращивать мощности.
Эм… Во-первых, в указанном примере не четыре байта, а два. Во-вторых, Intel наследует команды от самого 80086 до наших дней. Т.е. есть и однобайтные опкоды на 8 байтном(64 бита) процессоре.
А перебрать все 2^64 варианта на один опкод… Ну, около года на один опкод при терафлопсовом кристалле.
1. Примерно 2/3 года.
2. Почему один поток?
3. Никто не мешает предварительно прочитать с кристалла все, что можно прочитать, чтобы хотя бы составить базу возможных команд.
2. Почему один поток?
3. Никто не мешает предварительно прочитать с кристалла все, что можно прочитать, чтобы хотя бы составить базу возможных команд.
3 Как это никто? Если бы было возможно чтение с кристалла пользователем — стали бы вообще заморачиваться такой защитой?
2. потому что другие потоки заняты вычислением других опкодов. Сколько у нас опкодов в современном процессоре? правда, для успешной атаки достаточно что-то около 200 опкодов… Мнда… на моей видеокарте 3000 ядер… Возражение принято.
1, мнда… если это будет неприемлимо малым временем, то придется увеличивать разрядность процессора… Думаю, это будет возможно.
2. потому что другие потоки заняты вычислением других опкодов. Сколько у нас опкодов в современном процессоре? правда, для успешной атаки достаточно что-то около 200 опкодов… Мнда… на моей видеокарте 3000 ядер… Возражение принято.
1, мнда… если это будет неприемлимо малым временем, то придется увеличивать разрядность процессора… Думаю, это будет возможно.
На самом деле, команды на битовом уровне имеют определённую структуру, которая делает невозможной полную рандомизацию опкодов, что на порядки сокращает количество возможных вариантов (если, конечно, речь идёт о рандомизации набора команд i16/i32/a64)
я, вас, возможно, удивлю, но и сейчас некоторые ПО/системы взлома стоят поболее автомобиля. А уж исходники чегото более-менее серйозного полюбому стоят поболее автомобиля.
Идеальная защита! Никто не может написать вирус, если ассемблерные команды — другие!
После данной сентенции дальше можно и не читать: абсолютно наивное утверждение, если вспомнить об огромном количестве вирусов и червей, написанных на скриптах и основывающихся на «человеческой уязвимости».
Вообще, интерактивная открытая система, специально предназначенная для взаимодействия с пользователем, уязвима по умолчанию. Не помню, кто-то из «хакеров», криминалов-взломщиков (как бы и не Кевин Митник) утверждал, что «если вы хотите обезопасить компьютер от проникновения, то установите его в отдельной комнате за бронированными дверями с охраной, отключите любые информационные сети — никакого Интернета! И да, не включайте питание...» ;)
Мрачная картинка. Но мне сложно представить, кто сможет продавить запрет создания компьютеров с редактируемым кодом: мир не одним Интелом ограничивается, технология известная, и сравнительно простая, а ваш «компьютер» даже простейшие скрипты домашней автоматизации уровня чайника выполнять не сможет.
Это же шифр простой замены, который вскрывается на раз статистическими методами.
Будут очень выделяться типовые участки: прологи функций, куски кода, которые компилятор вставляет для определённых действий.
А уж если известно, что в составе кода есть какая-либо известная библиотека, можно легко найти её инварианты и сразу расшифровать все опкоды, которые в ней присутствуют.
Будут очень выделяться типовые участки: прологи функций, куски кода, которые компилятор вставляет для определённых действий.
А уж если известно, что в составе кода есть какая-либо известная библиотека, можно легко найти её инварианты и сразу расшифровать все опкоды, которые в ней присутствуют.
Будут очень выделяться типовые участки
У вас нет доступа к RAW-данным на кристалле ни в каком виде. Только то, что позволяет API самого приложения. По сути, кристалл — это компьютер. Вот представьте, что у вас сейчас есть старая игра «Волк ловит яйца», взломайте ее, используя лишь кнопки, имеющиеся в наличии.
Тогда зачем что-то шифровать или обфусцировать?
Проблема выполнения пользовательского кода решается запретом выполнения из стека/кучи.
В крайнем случае, делим память на RAM и ROM, выполняем код только ROM, и никак иначе (если речь о спецпроцессорах).
Проблема выполнения пользовательского кода решается запретом выполнения из стека/кучи.
В крайнем случае, делим память на RAM и ROM, выполняем код только ROM, и никак иначе (если речь о спецпроцессорах).
Смотрите, программа, к примеру, работает с сетью. В этом случае, на нее проходят все сетевые атаки. И так как программисты у нас не боги, то рано или поздно ее взломают. И сумеют запустить свой код.
Вот для защиты от этого сценария и сделана обфускация.
Вот для защиты от этого сценария и сделана обфускация.
Если говорить о веб, взломщикам, как правило, фиолетово, какой набор машинных инструкций выполняет сервер. Взломщики действуют уровнями выше: на уровне CMS, или базы данных, или даже на уровне логики программы, находя способы выполнить действия, не предусмотренные разработчиком.
Даже если запретить скрипты (программа выполняется без ОС? и нет даже подобия cmd.exe?), в любой большой программе программисты напишут свой встроенный механизм скриптов или макросов. И это можно как-то эксплуатировать.
Например, тот же SQL — запретите? Или как бороться с инъекциями в нём?
Даже если запретить скрипты (программа выполняется без ОС? и нет даже подобия cmd.exe?), в любой большой программе программисты напишут свой встроенный механизм скриптов или макросов. И это можно как-то эксплуатировать.
Например, тот же SQL — запретите? Или как бороться с инъекциями в нём?
Очевидно же — обфусцировать команды SQL! )
Я специально написал в статье: вэб превратился в тонкие клиенты. Т.е. наружу торчит только ввод/вывод мыши/клавиатуры, а приходит — уже готовая картинка. Таким образом, придется не ломать сайт, читая его код и узнавая запросы к БД, а ломать готовое приложение. Т.е. никакого доступа с SQL вы не получите.
Я не спорю, многие приложение сейчас имеют встроенные скриптовые языки. Тот же автокад, к примеру. Но. В ситуации, когда наличие скриптового языка будет угрожать безопасности, я думаю, от них будут отказываться в пользу компилируемых. Ну или напишут компилятор для скриптового языка, если это возможно.
Почему так? Потому что получив доступ к скриптовому языку, допустим, того же автокада, хакер автоматически получает доступ к документам пользователя(не к ОС и не к другим программам). Согласитесь, автокаду будет очень неприятно выплачивать штафы по убыткам?
Я не спорю, многие приложение сейчас имеют встроенные скриптовые языки. Тот же автокад, к примеру. Но. В ситуации, когда наличие скриптового языка будет угрожать безопасности, я думаю, от них будут отказываться в пользу компилируемых. Ну или напишут компилятор для скриптового языка, если это возможно.
Почему так? Потому что получив доступ к скриптовому языку, допустим, того же автокада, хакер автоматически получает доступ к документам пользователя(не к ОС и не к другим программам). Согласитесь, автокаду будет очень неприятно выплачивать штафы по убыткам?
В ситуации, когда наличие скриптового языка будет угрожать безопасности, я думаю, от них будут отказываться в пользу компилируемых.Что же они уже сейчас не поотказывались? Да потому что скрипты слишком полезны и ускоряют разработку. То есть, от них огромная финансовая выгода. «Штафы по убыткам» сейчас практически отсутствуют в сфере ПО (всё идёт «как есть» и «без гарантий»)
Таким образом, придется не ломать сайт, читая его код и узнавая запросы к БД, а ломать готовое приложение. Т.е. никакого доступа с SQL вы не получите.Тот же firefox вовсю внутри пользуется SQLite. А доступ к SQL хакеры разумеется получают не напрямую, а из-за того, что пользовательские данные так или иначе доходят до SQL-скриптов, и, если они должным образом не экранированы, могут попасть в скрипт не как данные, а как команды, и выполниться.
Ну оупенсорсники просто будут торговать кристаллами с открытой структурой для универсальных применений. Не все же параноики…
Свой собственный «Денди»-панк, с барахолкой и картриджами?
Кто то явно хочет получить работу в Denuvo GmbH
In future: new MS Office 2030 in ASIC
Т.е. всё то что уже описал автор, за исключением, более приближенно к реальности.
ASIC на платке вставляемой в PCI-Express, в нём происходит вся магия офиса, на входе же мышь клава буфер обмена, на выходе рендер окна офиса.
Т.е. всё то что уже описал автор, за исключением, более приближенно к реальности.
ASIC на платке вставляемой в PCI-Express, в нём происходит вся магия офиса, на входе же мышь клава буфер обмена, на выходе рендер окна офиса.
In future: new MS Office 2030 in Web
ни какие ASIC не будут нужны, будут сплошные тонкие клиенты.
ни какие ASIC не будут нужны, будут сплошные тонкие клиенты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита софта в 2025