Оу! Сегодня наконец-то я получил свою новую Юнити Студию!Дрожащей рукой я распаковываю содержимое посылки. О да! маленький кристалл, всего-то с в пол ладони величиной, а на нем все: процессор, память(достаточная для самых максимальных возможностей), видеопроцессор, аудио процессор, сама программа.
Закон Мура суров и беспощаден: удвоение числа транзисторов на пластине каждые два года. Именно благодаря беспрестанному развитию процессоров Интел(а следом, NVidia, AMD, Samsung и остальные) умудрилась запихать в один процессор содержимое системного блока, после чего процессор и перестали называть процессором, а стали кристаллом, и снизить его стоимость настолько, что стала возможной сама идея кристалла-программы.
Я вставляю его в панель моего компьютера: кристалл входит в щель и сам защелкивается, а на рабочем столе появляется иконка. Все! Установка завершена! Нет теперь долгих часов ожидания чего-то там… Деинсталляция тоже простая — выдерни нужный кристалл в одном из 256 гнезд. Но это жесткая деинсталляция, мягкая — через соответствующее меню в ОС.
Правда, это уже четвертый кристалл данной, 7-ой версии Студии… Ну что поделаешь, не распространяются по Интернету апдейты, не могут. Просто из-за такой ситуации: каждый процессор со своей кодовой базой. То есть, команда MOV EAX, EDX имеет опкод не 8BC2, а… никто не знает какой именно. Набор опкодов определяется случайным образом на заводе-производителе при прожиге пластины. А потом под нее идет компиляция программы.
Идеальная защита! Никто не может написать вирус, если ассемблерные команды — другие! Помнится, лет десять назад были языки со своей виртуальной машиной… А теперь, с# и java — компилируемые языки.
Ну в самом деле, какая разница на какой ОС сидит пользователь, если среда передает в программу только размеры окна, и ввод/вывод подключенных устройств, а программа выдает уже готовую картинку? При этом, все API ввода/вывода любых устройств для любых ОС строго стандартизировано и шаг влево, шаг вправо — считается побег, а прыжок на месте — провокация.
Да, есть минусы — программы приходится рассылать по почте, а для разработки заказывать «процессор разработчика».
Поставляется он отдельно от любой среды разработки. Кстати, кодовую таблицу ассемблерных опкодов для конкретного процессора разработчика запрашивает сама среда разработки, и получить ее для изучения не представляется возможным — шифрование, протоколы безопасности, все такое… если доказана возможность получения кодовой таблицы от данной среды разработки — гигантские штрафы и заморозка партий выпуска. Но зато, можно не опасаться того, что исходные коды «утекут в сеть» — на кой это нужно, если процессор разработчика стоит как автомобиль?
Я один из немногих, кто может себе позволить процессор разработчика… И то, потому что занимаюсь последней отрадой программистов — веб-разработкой.
Тоже, кстати непростое дело. Любая динамика — выполняется на стороне сервера и является компилируемой. А пользователю нельзя передавать никакой активный код. Зато пользователь может передавать все клики мышой и ввод с клавиатуры… Да-да серверам пришлось стать мощнее… То есть, отличить сайт от тонкого клиента теперь просто невозможно. Помнится, какой хай подняли разработчики, когда наш президент издал такой указ!
А куда деваться-то? В Штатах подобный указ вышел годом раньше… Но у них хотя бы сеть и сервера справляются с подобной нагрузкой… а у нас все как всегда…
Хорошо еще, до языков программирования вся эта чушь стандартизации не добралась! Были, были попытки назвать язык 1C государственным и запретить остальные… Слава богу, сама 1С воспротивилась — ей никогда не догнать все существующие фреймворки всех существующих языков. Ну и общество высказалось…
Еще одна отрада — опенсорц. Ему, правда, пришлось стать платным. Не для отдельных библиотек и фреймворков, разумеется, а для отдельных программ и ОС. Почему пришлось? Потому что компилировать сорцы под свой процессор операционной системы никто не может — кодовой таблицы процессора нет. А выпуск кристалла стоит денежек… вот и крутятся как могут. Тот же ОпенОфис периодически устраивает сбор денег на свой выпуск.
Upd: предполагается, что разрядность процессора как минимум, не уменьшается, а как максимум увеличивается. Т.е. количество вариантов на один опкод — 2^64 или больше.
С увеличением числа транзисторов на кристалле не обязательно растет производительность: так, последняя Мафия «весит» 42 гига в запакованном варианте — и все это должно лежать на кристалле. Т.е. встроенный минимум 1Тб(у нас же будущее, да?) флэш-накопитель + хз сколько оперативка.
Upd2: Я забыл упомянуть, что каждый кристалл — это полностью самодостаточная система, у которой нет функции доступа к файлам на внутреннем накопителе. Т.е. вы не сможете скопировать на флэшку ни калькулятор, ни текстурки, ни зашитый в ОС фон рабочего стола. Так же, вы не можете скопировать на диск кристалла вашу программу и ее оттуда запустить. Исключение составляет только процессор разработчика — он может сохранять скомпилированные файлы на внешний(по отношению к кристаллу) диск и исполнять их оттуда.
По результатам обсуждения выяснилось, что 64бита на опкод взламывается за приемлемое время. Так что, я, своей волей автора, меняю разрядность кристалла на 128бит и говорю, что в случае указания недействующего опкода срабатывает исключение процессора кристалла типа «идет атака». Как отреагирует программа на кристалле — не известно, но будем предполагать худший вариант: в случае сетевой атаки — блокирование IP-адреса, в случае локальной — остановка программы и просьба отнести/отправить кристалл в техподдержку.
Комментарии (90)
gasizdat
03.12.2016 08:57Описана разновидность security through obscurity (в данном случае — рандомная таблица опкодов). В общем случае — ни от чего не защищает. Т.к. обмен с внешним миром, судя по всему предполагается, то удаленной таргетированной атакой на конкретный процессор можно восстановить всю таблицу опкодов, а дальше — дело техники.
Ckpyt
03.12.2016 09:09Эм… а можно поконкретней. Вот у нас есть, грубо говоря, найденная ошибка переполнения буфера.
Как именно можно восстановить кодовую таблицу?
Общую технику атаки я знаю — куча NOP, потом код атаки. Но как можно в этом случае заставить удаленную машину ответить на данный адрес?
П.с. вариант перебрать все варианты опкодов — не вариант, это 2^64 комбинаций.gasizdat
03.12.2016 10:19+1Проблема обфускации в том, что а) поле вариантов изначально сужено до изначального набора кодов, б) одна и та же изначальная лексема сопоставляется строго одной и той же обфусцированной лексеме, в) правила связывания лексем между собой семантически предопределены (к примеру, две инструкции mov ax, bx и mov ax, cx не будут следовать подряд друг за другом). К примеру, предположим, что есть язык, в котором есть две буквы, а длина слов ограничена 2 символами. Тогда в языке может быть не более 6 слов. Теперь как бы вы не обфусцировали предложения на этом языке, проблема перебора возможных вариантов сильно сужается указанными правилами. Поэтому нет и не будет никаких 2^64 комбинаций (которых, впрочем, тоже весьма мало для сколь-нибудь эффективной криптозащиты).
Переполнение буфера это не атака, а уязвимость, открывающая вектор атаки. В вашем примере все еще проще — уязвимостью является сам подход, для которого известны ограничения а, б и в (см. выше).Ckpyt
03.12.2016 10:31-1Понимаете, 2^64 — это количество вариантов для одного опкода на 64-х битном процессоре. Да, при этом, само поле опкодов много меньше 2^64. Ну, пусть будет около 100 000. На самом деле, для успешной атаки и того меньше — около ста, двухсот. Проблема в том, что вам придется вычислять каждый отдельный опкод. Так как их много меньше 2^64, то итоговое число вариантов составит что-то около 2^72 — 200. Теперь, идем дальше.
Атака удаленная. У меня на сайте на ввод пароля админа давалось 3 попытки, после чего шло блокирование IP-адреса сроком на год.
Так как число опкодов много меньше числа вариантов опкодов, то что мешает заложить в процессор исключение типа «идет атака» на незадействованные опкоды? Как думаете, какое число исключений процессора кристалла будет заложено для блокировки IP-адреса?gasizdat
03.12.2016 11:06+1В простейшем случае не нужно вычислять каждый отдельный опкод. К примеру, я приду к вам в гости и пока вы будете заваривать мне чай на кухне, незаметно перекопирую стандартную программу Калькулятор с вашего ПК к себе на флешку. Я на халяву получу почти всю таблицу кодов процессора и это без малейшего брута, исключительно соц. инженерией. При удаленной атаке слегка посложнее, но так же нет ничего невероятного в том, чтобы словить в сетевых пакетах мусор из кодового сегмента при том же пресловутом выходе за границы памяти. Вопрос целенаправленности атаки — не более.
Ckpyt
03.12.2016 11:18Блин… я, кажется, забыл упомянуть, то получить скомпилированную программу можно только с процессора разработчика и никак иначе… Ну, то есть, на стандартном кристалле отсутствует доступ к внутреннему жесткому диску. Прощу прощения за эту оплошность.
Я для этого и ввел процессор разработчика, чтобы было возможно хоть как-то разрабатывать программы.
Ну и разумеется, скомпилированный код не передается по сети — это явно указано.в самом начале, когда приходит кристалл с очередным обновлением. Меня, правда, выше пытались убедить, что хранить таблицы опкодов для каждого конкретного процессора — это безопасно, но пока не смогли.gasizdat
03.12.2016 11:37Ну, если программы нельзя изменять, то это не интересно. Тогда и вся свистопляска с обфускацией не нужна, т.к. любая атака направлена на модификацию штатного кода. А если это невозможно, то и смысла рассуждать дальше нет. Проще тогда взять какой-нибудь матричный проц, типа FPGA и «напрожигать» в нем программ, аля MS Office.
Ckpyt
03.12.2016 11:55Обфускация нужна. Так как остается возможность править код в оперативной памяти — именно так и происходят атаки по переполнению буфера. И я не знаю будет там FPGA или обычный перезаписываемый флэш-накопитель. Кроме того, там может быть просто энергонезависимый накопитель без разделения ОЗУ/долговременная память. Доводов «за» достаточно для обоих вариантов.
arheops
03.12.2016 17:51+1Современная криптография давно доказала, что обфускация не дает практически никакого увеличения сложности шифра.
Ckpyt
04.12.2016 08:37Вы не знаете контекста…
Вы прежде чем влезать, почитали бы всю переписку начиная со статьи. В данном случае, у нас не обычная обфускация, а ее реализация через замену опкодов.
Я это указывал вот здесь: https://geektimes.ru/post/283316/#comment_9729206, и вот здесь:https://geektimes.ru/post/283316/#comment_9729408…
Ну и годная статья про виртуальный процессор: http://citforum.ru/security/software/virt_proc/arheops
04.12.2016 10:06+1В криптографии есть понятие стойкости. Так как ваша обфускация является конечной табличной заменой — не добавляет стойкости вообще. Вот если б у вас была безконечная таблица — тогда да, но это недостижимо в описываемых вами параметрах
Hellsy22
04.12.2016 15:19Вы не понимаете сути того, на что ссылаетесь. Если у вас есть зашифрованный текст и расшифрованный текст — то да, табличная замена ничего не дает. Но если у вас есть только черный ящик, в котором вы не можете получить доступа ни к зашифрованному тексту, ни к расшифрованному и вынуждены отправлять туда что-то вслепую, причем при неправильной команде все просто блокируется — таблица обеспечит не просто большую, но практически абсолютную криптостойкость.
arheops
04.12.2016 18:18Как раз теоретическая криптография и все ее теоремы и имеют дело с черными ящиками. Тут будут как минимум стандартные програмные блоки, стандартный ввод и стандартный вывод. В описанном вами случае стойкость регулируется фразой «все просто блокируется»(хотя это очень не просто, будет самоблокироватся/зависать), а не обфускацией.
Ckpyt
04.12.2016 22:17Стандартный ввод и стандартный вывод не должны давать возможность запускать произвольный код на выполнение. Т.е. вы не можете сказать: «а вот выполни-ка мне такую-то команду и верни результат».
Ваш стандартный ввод — это положение мыши и ввод с клавиатуры. А вывод — готовая картинка. Т.е., как написали ниже — взломать игру «волк ловит яйца» используя только кнопки на игрушке.
Ckpyt
04.12.2016 22:08RSA так же является конечной табличной заменой. Как говориться, все дело в длине ключа. Длина ключа в данном случае — 128 бит. Количество опкодов — порядка сотни тысяч(в наибольшем случае) Но! При первом же промахе процессор будет знать что ломают. И как он среагирует — неизвестно.
У вас не просто черный ящик, у вас активный черный ящик, который на неверную информацию будет реагировать.arheops
04.12.2016 22:41Ну займитесь, что ли, теорией. Есть очень много методов дающих тот же эффект гараздо меньшими усилиями. Тут будет взломать относительно легко, поскольку вы будете запускать стандартный програмный код.
Ckpyt
04.12.2016 22:471)О'кей, расскажите мне, пожалуйста, про эти методы… Или дайте ссылку на них.
2)Кроме того, у вас есть стандартный код, предположим, из open-source библиотеки, это да… но КАК, КАКИМ ОБРАЗОМ вы получите зашифрованный?
3)И вы все время забываете про возможность самоблокировки.arheops
04.12.2016 23:04У меня нет желания пересказать вам курс защиты информации. Давайте считать, что вы доказали мне, что ваш метод защиты не ломается. Хотя он не отличается по сути от програмного метода ничем. Вон ифоны вроде как тоже самоблокируются.
qw1
05.12.2016 11:51RSA так же является конечной табличной заменой. Как говориться, все дело в длине ключа. Длина ключа в данном случае — 128 бит
Тут дело в стойкости алгоритма, а не длине ключа.
К примеру, циклическое наложение по XOR ключа длиной 1024 бит на документ в несколько мегабит легко ломается.
Так и в случае шифрования опкодов: каждый опкод шифруется независимо, есть устойчивые сочетания (push ebp / mov ebp, esp или mov esp, ebp / pop ebp / ret) которые сразу отбиваются статистикой. С точки зрения криптоанализа (если снят дамп), это сводит сложности к нулю.Ckpyt
05.12.2016 12:15У вас нет возможности получить дамп. Кажется, я учел все возможности, чтобы этого избежать. Обфускация же проводится для того, чтобы предотвратить выполнение произвольного кода, поступившего из вне.
Ну, грубо говоря, при успешной хакерской атаки. В этом случае, у хакера не будет возможности снять дамп(разумеется, если не предусмотрено уже скомпилированным кодом программы), а только запустить на выполнение свой код.
И вот для того, чтобы этот код не запустился и при этом послал сигнал программе о взломе, и используется обфускация.
П.с. и да, скриптовые языки я тоже грохнул.
Ckpyt
03.12.2016 10:47Так, я сейчас попытаюсь объяснить вариант а для себя своими словами. Если я не прав, поправляйте.
Вы говорите, что если у нас есть три числа 100, 010, 001, то мы можем поменять только 100 на 010 или 001, но не на 20 или 30. Так?
П.с. тема обфускации для меня нова, и я тут полный даун… но я уже читаю по ней статьи :-)gasizdat
03.12.2016 11:12Пока все верно понимаете.
По большому счету, метод, который вы предложили в железе, уже много лет используется в софтовом исполнении. Это т.н. метод виртуальных машин (например, можно сразу смотреть п. 3). Взлом такой защиты затруднен, только если применяется многоуровневый стек виртуализации (в современных системах защиты ПО — это несколько десятков слоев виртуализации).Ckpyt
03.12.2016 12:16ШТО?!!! Один слой виртуализации — замедление в десятки раз… А десятки слоев оставят от моих 2,6 ГГц… Ну-ка 10^10 = 10 000 000 000, т.е останется 2,6Гц. кажется, у вас где-то ошибка… Или я вас не понял.
Кроме того, по ссылке ясно написано — замена опкодов на другие дает надежный, трудновзламываемый вариант.
Кроме того, ваше согласие с предыдущим ответом — это неверное понимание ситуации. Опкоды могут быть любые, а не только из числа используемых. Просто потому, что железо не стеснено недостатками ассемблера. Т.е. нам не надо маскироваться под уже существующие опкоды. Грубо говоря, мы можем вместо однобайтного опкода, унаследованного аж от 80086 указать 8-и байтный… а то и вовсе 16-и, чтобы жизнь медом не казалась :-)
Почему виртуальный процессор сейчас взламывается? Потому что на руках у злоумышленника есть таблица соответствий, зашитая в программу. Восстановить по ней машинный код защищенного модуля — задача сложная, но реализуемая. У меня же основная сложность в том, что эту таблицу не получить так легко и просто: нет доступа к скомпилированным кодам, только методом тыка с риском запороть процессор(см upd2). Если я, конечно, правильно понял статью :-)
Eklykti
03.12.2016 12:49Один слой виртуализации — замедление в десятки раз
ЧЁ?
Ckpyt
03.12.2016 13:34Тут имеется ввиду виртуальный процессор — замена одного опкода другим. И да, это-таки в десятки раз.
Alexeyslav
05.12.2016 12:35в десятки раз, это когда пытаешься виртуализировать процессор с мощной системой команд на более простом, например виртуализировать процессор Core i5 на физической машине с 80286 процессором. Тогда да, одну команду из набора SSE3 физический процессор будет выполнять сотню тактов заменяя её последовательностью из более простых команд…
Но нынешняя виртуализация идёт практически 1 к 1 за исключением небольшого оверхеда в считанные проценты, и то в случае необходимости эмуляции отсутствующих модулей/функций на более нижнем уровне. А если мы попытаемся эмулировать i5 процессор на i7 то потеряем лишь считанные проценты, и скорей всего только на уровне переключения контекста между процессами.
Где-то была статья по отлову китайского гипервизора на китайских платах, так вот оттуда я узнал что современные компьютеры уже достаточно виртуальны, наша операционная система уже является 3 или даже 5-м вложенным уровнем виртуализации… т.е. до того как исполнение кода доходит до загрузочного сектора уже имеем 3 уровня виртуализации или и того больше. ОС даёт ещё несколько уровней… при этом узнать реальный уровень виртуализации — практически невозможно, только если воспользоваться аппаратным счётчиком тактов самого процессора, который, впрочем, тоже можно виртуализировать.Ckpyt
06.12.2016 02:46Это все работает в том случае, если частично совпадают таблицы команд. Тогда нужно эмулировать только те команды, которых нет в процессоре. У нас другая ситуация — у нас подмена опкодов. Т.е. даже не на уровне ассемблера, а на уровне машинных команд. Так вот, в этом случае используется виртуальный процессор, который декодирует конкретную команду в какую-то другую, заранее не известную.
Современные виртуальные процессоры, используемые не в системах виртуализации, а в системах обфускации(еще раз, мы не про те процессоры говорим), как правило, работают достаточно медленно — как раз из-за подмены команд + промахов конвейера.
При этом, так как схему команд одного процессора хакеру построить вполне себе реально, в обфусцированной программе используется несколько виртуальных процессоров — в зависимости от параноидальности настройщика, может быть для каждого модуля свой процессор. Это еще более затрудняет жизнь хакеру, но еще более увеличивает количество промахов конвейера.
Вполне себе допускаю, что для улучшения производительности, используются приемы, о которых я мало знаю — к примеру, как пишут ниже, дешефрация строки кэша, а потом ее исполнение. Но даже в этом случае, все равно будет дешифровки — от нее никуда не денешься. И это будет замедление в 3-5 раз.
в описанной вами статье используется другая схема виртуализации — там просто идет логирование системы команд. И да, это замедление не в десятки раз, а всего-то в полтора-два…
GennPen
03.12.2016 13:28-1Один слой виртуализации — замедление в десятки раз
Вы случаем не из прошлого, когда виртуализация только начала развиваться?
Нынче виртуальные машины работают почти 1:1 по производительности с хостом.
Недавно проверял производительность виртуальной машины с хостом — получил результат с разницой в пределах погрешности.Ckpyt
03.12.2016 13:35+1Извините, но тут речь идет не о виртуальной машине, а о виртуальном процессоре. — замена одного опкода другим. И да, это-таки в десятки раз.
GennPen
03.12.2016 13:43А что это мешает делать на аппаратном уровне?
Есть стандартный процессор со стандартными опкодами, при загрузке из защищенной зоны считывается таблица соответствия опкодов, эта таблица опкодов прожигается на заводе при изготовлении процессора… по сути это у вас и описано в тексте
Ну, или сделать загрузку таблицы опкодов динамической, из памяти доступной только для записи для всех кроме процессора.
Набор опкодов определяется случайным образом на заводе-производителе при прожиге пластины.
Ckpyt
03.12.2016 13:54Современные системы защиты информации пока так делать не умеют. Ну и современные процессоры тоже не умеют. Я потому и описал развитие систем защиты программного обеспечения именно в «железном» варианте как вариант скорого будущего :-)
И-таки да, я считаю, что к этому мы и придем.
Главный минус динамических таблиц опкодов в процессоре — постоянные промахи конвейера и таблицы предсказания переходов. Но мысль интересная… Ее можно обдумать. Спасибо.
Интересно будет услышать мнение кого-нибудь из Интела по поводу такой системы защиты :-)arheops
03.12.2016 17:53Ерунда это. Практически каждый СОВРЕМЕННЫЙ процессор имеет аппаратную систему декодирования команд. Тоесть в данном случае речь идет о модификации таблицы декодирования, что вообще никак не скажется на реальном выполнении.
Alexeyslav
05.12.2016 14:06Наверно имеете в виду таблицу опкод-микрокод? Такая таблица есть и сейчас, но она ограниченного размера по банальным причинам — быстродествие дешифраторов падает пропорционально разрядности дешифратора, а в процессоре он должен работать на частоте ядра, поэтому основная часть этой «таблицы» выполнена на жёсткой минимизированной логике.
Потом, микрокод жестко завязан на дешифратор команд.
А этот самый дешифратор команд является узким местом в процессоре — от него зависит длительность исполнения каждой микрокоманды и максимальная рабочая частота процессора, соответственно его оптимизируют таким образом чтобы обеспечивал минимальный путь сигнала через логическую матрицу, с другой таблицей микрокодов минимальный путь может неожиданно оказаться длиннее, и процессор не сможет работать на максимальной частоте.qw1
05.12.2016 20:38Это соображение уже не актуально. Потому что код выполняется из кеша опкодов и загрузка строки кеша из RAM занимает сотни тактов. Если в кеше команд хранить код в декодированном виде, а декодировать при заполнении строки кеша, сразу строку целиком, разница практически не будет заметна.
vikarti
03.12.2016 20:15таак, хорошо. чтобы вскрыть — нам надо таблицу трансляции получить, и это единственное чем кристаллы отличаются?
вызываем например BarsMonster, даем ему электронный микроскоп, кристалл разработчика и несколько копий того что надо + несколько копий того что нам НЕ надо и просим помочь.
он составляет карту кристалла и выясняет где там — 'ssd' с программой а где таблица опкодов.
затем даем еще один кристалл с тем что надо, считывает программу (вот правда как… к кристаллу разработчика можно подключить нестандартные внешние устройства?) а затем — таблицу опкодов.
Ckpyt
04.12.2016 22:40Нет, мне нравится эта идея! В самом деле нравится! Вы хотите взломать тот кристалл, который есть у ВАС тупо его разобрав!
Ну-ка, что нам известно про современные процессоры? Интел заявила о переходе на 5 нанометровый техпроцесс:
http://www.mobiledevice.ru/78783-intel-processor-roadmap-processor-intel-core.aspx
При этом, расстояние между двумя атомами железа всего — 2,5•10^?10 м. Т.е. толщина дорожки — 20 атомов. Офигеть, да? Любая тяжелая частица ее разорвет… То есть, при снятии защитного кожуха с кристалла в незащищенном помещении, вы получаете кашу вместо процессора. Вы согласны экранировать ваше помещение от тяжелых частиц?
Но допустим, вы решили и эту проблему. Ваш доблестный BarsMonster, разрушив сотню кристаллов в попытке научится снимать кожух и клей без разрушения кристалла(5 нанометров, помним?), получил-таки таблицу опкодов! Потом он научился снимать намагниченность с флэш-структур(честно, не знаю как она работает)… Сколько у него уйдет времени на один кристалл?
Вряд ли месяц… скорее, полгода-год…
Nuwen
03.12.2016 09:03То есть, команда MOV EAX, EDX имеет опкод не 8BC2, а… никто не знает какой
Четыре байта на опкод, значит? Возможно будет собрать аппаратный брутфорсер, который будет гонять всевозможно скомпилированные программы на «кристалле», до победного конца. Либо вирус будет сам подбирать, закон Мура ведь позволит и вирусам наращивать мощности.
Но зато, можно не опасаться того, что исходные коды «утекут в сеть» — на кой это нужно, если процессор разработчика стоит как автомобиль?
Но у китайцев всегда можно заказать такой за 40$, они его в ручную отобрали из списанных целиком партий, из-за нескольких бракованых кристаллов в контроле. Под него же будут распространяться патченые версии коммерческих программ, получится что законопослушные граждане будут покупать игры и программы по немыслимым сегодня, выросшим из-за монополии ценам, раз в год или два. А пираты просто будут запускать спираченые дампы этих прог на пиратском эмуляторе «кристалла», переключая сотни их в мгновение ока, с помощью системы прерываний. А опен сорс один раз поднапряжётся и сделает кристалл, на котором запустится любая GNU совместимая программа.Hellsy22
03.12.2016 09:07-1опен сорс один раз поднапряжётся и сделает кристалл, на котором запустится любая GNU совместимая программа
… т.е. любая из имеющихся десяти, хоть на что-то годных. Ну и конечно, будет зверски тормозить, отставать в развитии от своих коммерческих собратьев на десяток-другой лет, но зато GNU же!
Ckpyt
03.12.2016 09:18Четыре байта на опкод, значит? Возможно будет собрать аппаратный брутфорсер, который будет гонять всевозможно скомпилированные программы на «кристалле», до победного конца. Либо вирус будет сам подбирать, закон Мура ведь позволит и вирусам наращивать мощности.
Эм… Во-первых, в указанном примере не четыре байта, а два. Во-вторых, Intel наследует команды от самого 80086 до наших дней. Т.е. есть и однобайтные опкоды на 8 байтном(64 бита) процессоре.
А перебрать все 2^64 варианта на один опкод… Ну, около года на один опкод при терафлопсовом кристалле.Hellsy22
03.12.2016 11:161. Примерно 2/3 года.
2. Почему один поток?
3. Никто не мешает предварительно прочитать с кристалла все, что можно прочитать, чтобы хотя бы составить базу возможных команд.Ckpyt
03.12.2016 11:263 Как это никто? Если бы было возможно чтение с кристалла пользователем — стали бы вообще заморачиваться такой защитой?
2. потому что другие потоки заняты вычислением других опкодов. Сколько у нас опкодов в современном процессоре? правда, для успешной атаки достаточно что-то около 200 опкодов… Мнда… на моей видеокарте 3000 ядер… Возражение принято.
1, мнда… если это будет неприемлимо малым временем, то придется увеличивать разрядность процессора… Думаю, это будет возможно.
maxzhurkin
04.12.2016 11:02+1На самом деле, команды на битовом уровне имеют определённую структуру, которая делает невозможной полную рандомизацию опкодов, что на порядки сокращает количество возможных вариантов (если, конечно, речь идёт о рандомизации набора команд i16/i32/a64)
arheops
03.12.2016 11:51я, вас, возможно, удивлю, но и сейчас некоторые ПО/системы взлома стоят поболее автомобиля. А уж исходники чегото более-менее серйозного полюбому стоят поболее автомобиля.
Ckpyt
03.12.2016 13:57Я знаю. Когда-то, давным давно, я работал в химлаборатории при НИИ НефтеМиме, ныне закрытом за ненадобностью. И мы тогда смотрели почем можно приобрести разный нужный софт. Ценник вызывал острое ощущение своей неполноценности и жгучую зависть к тем самым 1,500 клиентов по всему миру :-)
sens_boston
03.12.2016 17:48+1Идеальная защита! Никто не может написать вирус, если ассемблерные команды — другие!
После данной сентенции дальше можно и не читать: абсолютно наивное утверждение, если вспомнить об огромном количестве вирусов и червей, написанных на скриптах и основывающихся на «человеческой уязвимости».
Вообще, интерактивная открытая система, специально предназначенная для взаимодействия с пользователем, уязвима по умолчанию. Не помню, кто-то из «хакеров», криминалов-взломщиков (как бы и не Кевин Митник) утверждал, что «если вы хотите обезопасить компьютер от проникновения, то установите его в отдельной комнате за бронированными дверями с охраной, отключите любые информационные сети — никакого Интернета! И да, не включайте питание...» ;)
APLe
03.12.2016 18:25+1Мрачная картинка. Но мне сложно представить, кто сможет продавить запрет создания компьютеров с редактируемым кодом: мир не одним Интелом ограничивается, технология известная, и сравнительно простая, а ваш «компьютер» даже простейшие скрипты домашней автоматизации уровня чайника выполнять не сможет.
qw1
03.12.2016 20:33Это же шифр простой замены, который вскрывается на раз статистическими методами.
Будут очень выделяться типовые участки: прологи функций, куски кода, которые компилятор вставляет для определённых действий.
А уж если известно, что в составе кода есть какая-либо известная библиотека, можно легко найти её инварианты и сразу расшифровать все опкоды, которые в ней присутствуют.Hellsy22
04.12.2016 15:22Будут очень выделяться типовые участки
У вас нет доступа к RAW-данным на кристалле ни в каком виде. Только то, что позволяет API самого приложения. По сути, кристалл — это компьютер. Вот представьте, что у вас сейчас есть старая игра «Волк ловит яйца», взломайте ее, используя лишь кнопки, имеющиеся в наличии.qw1
05.12.2016 11:55Тогда зачем что-то шифровать или обфусцировать?
Проблема выполнения пользовательского кода решается запретом выполнения из стека/кучи.
В крайнем случае, делим память на RAM и ROM, выполняем код только ROM, и никак иначе (если речь о спецпроцессорах).Ckpyt
05.12.2016 12:22Смотрите, программа, к примеру, работает с сетью. В этом случае, на нее проходят все сетевые атаки. И так как программисты у нас не боги, то рано или поздно ее взломают. И сумеют запустить свой код.
Вот для защиты от этого сценария и сделана обфускация.qw1
05.12.2016 12:44Если говорить о веб, взломщикам, как правило, фиолетово, какой набор машинных инструкций выполняет сервер. Взломщики действуют уровнями выше: на уровне CMS, или базы данных, или даже на уровне логики программы, находя способы выполнить действия, не предусмотренные разработчиком.
Даже если запретить скрипты (программа выполняется без ОС? и нет даже подобия cmd.exe?), в любой большой программе программисты напишут свой встроенный механизм скриптов или макросов. И это можно как-то эксплуатировать.
Например, тот же SQL — запретите? Или как бороться с инъекциями в нём?Ckpyt
06.12.2016 03:01Я специально написал в статье: вэб превратился в тонкие клиенты. Т.е. наружу торчит только ввод/вывод мыши/клавиатуры, а приходит — уже готовая картинка. Таким образом, придется не ломать сайт, читая его код и узнавая запросы к БД, а ломать готовое приложение. Т.е. никакого доступа с SQL вы не получите.
Я не спорю, многие приложение сейчас имеют встроенные скриптовые языки. Тот же автокад, к примеру. Но. В ситуации, когда наличие скриптового языка будет угрожать безопасности, я думаю, от них будут отказываться в пользу компилируемых. Ну или напишут компилятор для скриптового языка, если это возможно.
Почему так? Потому что получив доступ к скриптовому языку, допустим, того же автокада, хакер автоматически получает доступ к документам пользователя(не к ОС и не к другим программам). Согласитесь, автокаду будет очень неприятно выплачивать штафы по убыткам?qw1
06.12.2016 18:15В ситуации, когда наличие скриптового языка будет угрожать безопасности, я думаю, от них будут отказываться в пользу компилируемых.
Что же они уже сейчас не поотказывались? Да потому что скрипты слишком полезны и ускоряют разработку. То есть, от них огромная финансовая выгода. «Штафы по убыткам» сейчас практически отсутствуют в сфере ПО (всё идёт «как есть» и «без гарантий»)
Таким образом, придется не ломать сайт, читая его код и узнавая запросы к БД, а ломать готовое приложение. Т.е. никакого доступа с SQL вы не получите.
Тот же firefox вовсю внутри пользуется SQLite. А доступ к SQL хакеры разумеется получают не напрямую, а из-за того, что пользовательские данные так или иначе доходят до SQL-скриптов, и, если они должным образом не экранированы, могут попасть в скрипт не как данные, а как команды, и выполниться.
ShamAnton
04.12.2016 02:21+1Ну оупенсорсники просто будут торговать кристаллами с открытой структурой для универсальных применений. Не все же параноики…
Nuwen
04.12.2016 08:56Вообще подумать, то определённый смысл в этом всём есть. Только использовать эту технологию можно не для защиты софта, а в более благих, на вид, целях. Выпустив программный пакет, фирма заказывает на завод в Китае аппаратный сопроцессор, напечатанный специально для этой программы, и содержащий хардо-софтовые алгоритмы ускорения обработки данных. Программа может работать и без него с базовой производительностью, как игры, которые запускаются и без видеокарты. При наличии процессора же, программа работает как на стероидах, с аппаратной поддержкой. Тогда не будет необходимости с каждым чихом программистов выпускать новый камешек, а остальные выкидывать как устаревший и небезопасный хлам. Обновляться будет сама программа, пользующаяся сопроцессором. На крайняк, если понадобится сменить прошивку процессора, то уже давно существуют методы подписи прошивок и бутлоадеры в телефонах, например, которые просто не дадут загрузить неподписанную прошивку. Половина устройств на рынке смартфонов не дают возможности установить кастомную прошивку.
perfect_genius
04.12.2016 19:25Чип-нейросеть обученная — такую даже не скопируешь, а сигналы обучения есть только у разработчика.
Varkus
05.12.2016 09:13In future: new MS Office 2030 in ASIC
Т.е. всё то что уже описал автор, за исключением, более приближенно к реальности.
ASIC на платке вставляемой в PCI-Express, в нём происходит вся магия офиса, на входе же мышь клава буфер обмена, на выходе рендер окна офиса.GreenStore
05.12.2016 10:49+1In future: new MS Office 2030 in Web
ни какие ASIC не будут нужны, будут сплошные тонкие клиенты.GennPen
05.12.2016 11:40In future: new MS Office 2030 in Web
Уже сейчас есть всякие Office 365 и Google DocsGreenStore
05.12.2016 13:25Office 365 — это десктопное приложение, просто распространяется по подписке. Так же, как Intellij IDEA Ultimate, например.
GennPen
05.12.2016 14:36Office 365 есть и веб-версия без установки на компьютер. Это всякие Office 2016 и т.п. — только для компьютера, без подписки с одноразовой первоначальной оплатой.
GreenStore
05.12.2016 16:19То, что в Web конкретно называется Office Online (https://office.live.com/).
GreenStore
Что-то я все же не понял, почему апдейты не могут распространяться по Интернету? Уникальная кодовая база апдейтам нисколько не мешает. Между устройством и сервером обновления устанавливается защищенный канал связи и хоть заобновляйся.
Ckpyt
Потому что сервер не знает какая именно кодовая таблица используется в данном процессоре. Это не знает даже завод-изготовитель — сразу после изготовления партии и заливки программ, он стирает где на каком кристалле какая была кодовая база.
П.с. Статья написана в режиме максимальной паранойи, :-)
GreenStore
Есть криптография с открытым ключом, на крайний случай есть разделяемый секрет (shared secret) и соответствующие криптографические протоколы. Таким образом, можно установить безопасный канал связи между устройством и сервером обновлений.
Далее процессор передает свою конфигурацию, или она становится понятна серверу после процедуры аутентификации и сервер готовит нужное обновление. И, благодаря криптографии, с завода можно исключить утечку данных.
Поэтому, никаких принципиальных проблем с обновлением нет.
Возможно проблема в том, что вы не знакомы с криптографией.
Ckpyt
Есть проблема физической утечки данных с завода третьим лицом. Это раз. Есть проблема нестойкости и/или взлома данного криптографического алгоритма/фремворка — вспомните о проблеме OpenSSL. Это два. Есть(и всегда будет) проблема таргетированной атаки на завод, когда на один сервер обрушивается мощь ботнета в миллион машин.
Так что, моя паранойя говорит, что хранить таблицу опкодов — не самый параноидальный режим :-)
GreenStore
Если вы говорите о этой проблеме, то почему считаете, что ей не подвержено производство «уникальных кристаллов»? Тоже самое абсолютно.
Безопасность основана на существовании доверия на каком-то уровне. Вы должны доверять или заводу, или службе, которая генерирует прошивки, или чему-либо еще. Если вы ничему не можете доверять, до безопасность не работает!
Ckpyt
Не абсолютно.
Во-первых, будет скомпрометирована только текущая, производящаяся партия кристаллов. Кто будет их получателем — заранее не известно. Если хранить все таблицы, будут скомпрометированы ВСЕ произведенные кристаллы. Если, скажем, кристалл попал в комп президента и известен завод-изготовитель данного кристалла, то вопрос доступа к данным — это всего лишь вопрос времени.
Во-вторых, как правило, физическая утечка легче обнаруживается удаленного взлома(смотреть в сторону систем защиты информации. В частности, Dallas Lock). Т.е. в случае ЧП можно будет арестовать партию еще не проданных/лежащих на складе и т.п. кристаллов, что дешевле заменять уже проданные.
Но давайте предположим, что завод-разработчик не хранит у себя никаких таблиц, а просто их передает компании-разработчику. Что получится?
Одна и та же компания занимает лидирующее положение на рынке операционных систем, на рынке подготовки документов(Microsoft Office), на рынке сред разработки ну и так далее,… Отсюда: вопрос о взломе и похищении таблиц опкодов рано или поздно поднимет суммы, близкие к бесконечности(с т.з. обывателя). А дальше вопрос о физической утечки данных даже не будет стоять… он будет лежать и сам ползти к удобному месту.
Понимаете, весь профит в том, что ключей для расшифровки нет НИ У КОГО. Почему? Потому что имея на руках таблицу опкодов взлом удаленной системы становится не сложнее взлома в нынешних условиях.
П.с. я просто не знаю каким еще языком объяснить что паранойи в защите информации много не бывает.
GreenStore
Хочу ответ начать с конца, прокомментировав фразу «я просто не знаю каким еще языком объяснить что паранойи в защите информации много не бывает».
Если это так, тогда поясните, почему у корневого сертификата, который использует Google, длина ключа 2048 бит, а не 4096 бит или даже 65536 бит?
Ckpyt
Выбор длины ключа всегда ограничивается снизу минимальным временем для взлома и сверху производительностью системы. В ситуации, когда подписывать приходится часто, ключ имеет смысл ограничивать хоть какой-то разумной длиной. А вот когда один раз зашифровал и время от времени расшифровываешь… DrWeb шифрования своих ключей использует 512 бит, NetBeans — 1024, Aspen One — 4096. Кому верить?
GreenStore
Так Вы до этого говорили, что паранойи много не бывает, а сейчас говорите, что бывает.
Кому верить, вам от 3 декабря днем, или вам от 3 декабря вечером?
Ckpyt
Эм… я вам уже говорил: статья написана в режиме максимальной паранойи. Собственно, без нее бы и не было статьи.
В тоже время, реальные производители, как правило, думают не только о безопасности, но и о производительности.
Кстати, первая ласточка реализации моих идей: http://senselock.ru/projects/senselock-vmprotect.php «выполнение кода защиты в ядре электронного ключа SenseLock;».
Как говориться, дальше будет больше :-)
GreenStore
Идем дальше.
Поясните, как должно обеспечиваться отсутствие утечек «таблиц кристаллов» с вашего завода?
Как должно обеспечиваться отсутствие закладок аппаратной части кристаллов, которые намеренно вносят разработчики?
Как должно обеспечиваться отсутствие закладок в программном коде, которые намеренно вносят разработчики?
Ckpyt
Последние два пункта — мимо кассы. Понимаете, ну внес к примеру, разработчик уязвимость, позволяющую выполнять произвольный код… только таблиц опкодов у него нет. И как следствие, он не может выполнить свой код. Остаются скрипты, но это настолько явная уязвимость… Доверие со стороны покупателей будет моментально подорвано.
Что же касается язвимостей со стороны процессора… ну, с выполнением кода мы уже разобрались. Осталась заранее заложенная уязвимость в виде выполнение кода на другой таблице опкодов, заранее известной разработчику процессора. Как думаете, как скоро вскроется такая закладка?
Самая засада с утечками с завода. Потому что контролировать отсутствие утечек можно только аудитом. А аудит безопасности, к сожалению, не решает проблемы разового физического выноса таблиц. Но, к счастью, после грамотного аудита безопасности почти невозможно скрыть факт физического выноса таблиц. Если, разумеется, злоумышленник — не завод. Но это тоже — быстро вскрывается и заводу на фиг не надо.
GreenStore
Выполнять — это позднее. А прежде всего — простое чтение и запись памяти в указанное место, создание дампа.
После создания дампа и с возможностью модификации памяти разломать такую систему — дело относительно короткого времени независимо от того, известны вам опкоды или нет. Особенно, если этот процесс автоматизировать.
Может никогда не быть обнаружена, особенно, если эта закладка неявной формы. Это крайне сложно искать.
Так как с этим бороться?
Это же должно иметь какое-то основание, а не фантазия про «грамотный аудит». Что такое грамотный аудит, на чем он основан, как он может выявить проблему? Почему криминал не может подкупить/запугать людей, ответственных за аудит и он будет смотреть на все сквозь пальцы?
Докажите, что ваша задача вообще решаема.
Ckpyt
Согласен. Это — потенциально уязвимая ситуация. И она лмбо решается доверием к софту, либо никак не решается…
http://www.infox.ru/science/enlightenment/2016/01/27/Matyematiki_dokazali.phtml
Т.е. с железом, с которым имеют дело тысячи и миллионы разработчиков, вскрытие такой ситуации — дело полгода… Особенно, если за дело возьмется кто-то подобный Мыщъху(он же Крис Касперски).
Разумное возражение.
1)Смотрите, если право на аудит безопасности будет иметь любой, кто хочет заказать выпуск кристаллов на данном заводе, то и аудит будет проводится их силами или силами наемной команды. Т.е. в любом случае, не местными, а приезжими, прибывшими буквально на день-два, живущими на территории завода. Как думаете, имеет ли смысл им угрожать, если они уедут и смогут обратиться в правоохранительные органы той страны, из которой они приехали? Или как быстро вскроется подкуп при таком количестве аудитов?
2)Аудит безопасности проводится так, чтобы доказать вероятность взлома/утечки на компании-цели. Если идет удаленный аудит, то компания даже может и не знать о таком мероприятии. Если локальный — изымаются записи с камер безопасности, тщательно проверяются, проверяются рабочие места, проверяются права на предмет доступа к информации, проверяется вообще все, что только можно.
В 2004-ом такой аудит внезапно нашел скрытую камеру в цеху на том заводе, где я работал… Думаю, с тех пор средства и методы а аудиторов подросли…
Hellsy22
Я не разделяю идей автора, по мне, так никакой президент или кто-то другой не в силах изменить ход развития IT так радикально. Но эти вопрос про таблицы мне представляется очевидным. Вот вам три варианта.
1. Таблицы создаются временно, в процессе записи кристалла. Нигде не хранятся.
2. При инициализации кристалл сам генерит себе таблицу команд и транслирует софт из «базовой» таблицы в свою.
3. Таблицы создаются и хранятся, но зашифрованы ключом, половина которого прошита на кристалле (он же его уникальный номер) — без ключа к ним доступа нет. Это вариант на случай необходимости отладки после возврата кристалла изготовителю.
vikarti
Senselock и раньше это все умел.
VMProtect там прикручен чтобы пользователю не приходилось возится с выделением части кода, которая будет грузится на ключ (с чем есть проблемы — бесплатный компилятор SDCC может давать код только для тормозного режима работы, а 'платный' быстрый надо покупать задорого и не у не них).
ну и скорость… не очень и это мягко говоря (правда крипто-функции имеют аппаратную реализацию).
Hellsy22
Сервер не знает, но кристалл-то знает. Он может получать данные в стандартной кодовой таблице и транслировать их в свою. Делов-то…
Ckpyt
Это потенциально уязвимая ситуация. Появляется дыра: можно попробовать притвориться имеющим право на запись и записать вирус в стандартной кодовой таблице. Т.е. вместо задачи расшифровки таблицы опкодов задача сведется к задаче «притворись право имеющим».
Хотя… это потенциально решаемая задача. Предположим, на процессор лежит открытый ключ, зашитый разработчиком. Он служит для получения сессионного ключа… ну и для идентификации. А дальше — по вашей схеме…
Тут возникает вопрос утечки ключей… В режиме максимальной паранойи легко предположить, что и они утекут, где бы не лежали. Ну, просто предположим, что в качестве программы выступает ОС, установленная на компе президента. И, соответственно, суммы на получение закрытого ключа моментально достигают пределов что-то около бесконечности(для обывателя, см ситуацию с Нотчем). Как думаете, как скоро такой ключ будет получен?
Hellsy22
Думаю, что это частично решается разделением прав доступа и физическим переключателем.
Например, «ОС» апдейтить невозможно. Основной софт — только из аналога «рекавери», для чего придется кристалл вытащить и вставить другой стороной, например. А вот плагины — без ограничений, но лишь с подтверждения пользователя. Никакого автоапдейта. Как-то так.
Alexeyslav
А вот толку от этого… плагины замают пользователя просьбой дёрнуть переключатель по малейшему поводу и вплоть до «не буду работать пока не разрешишь обновление, потому что существенно изменилось API и старое уже не поддерживается». И самое главное — дергая переключатель ТЫ НЕ БУДЕШЬ ЗНАТЬ что именно там обновилось. Даже в случае полностью открытых исходников — у тебя просто не будет времени на анализ изменений в плагине, и того какую потенциальную угрозу они несут.
И чем больше плагинов тем больше подобного ада.
Hellsy22
Кристалл — изначально черная коробка и ни один пользователь не знает, что именно в нем происходит. Хуже того, он сделан максимально защищенным от реверс-инженеринга. Как-то странно на этом фоне сокрушаться по поводу отсутствия точных знаний о работе плагинов.