В прошлой статье про SecureBoot мне очень не хватало возможности сделать снимок экрана при настройке UEFI через BIOS Setup, но тогда выручило перенаправление текстовой консоли в последовательный порт. Это отличное решение, но доступно оно на немногих серверных материнских платах, и через него можно получить только псевдографику, а хотелось бы получить настоящую — она и выглядит приятнее, и вырезать ее каждый раз из окна терминала не надо.
Вот именно этим мы и займемся в этой статье, а заодно я расскажу, что такое DXE-драйвер и как написать, собрать и протестировать такой самостоятельно, как работают ввод с клавиатуры и вывод на экран в UEFI, как найти среди подключенных устройств хранения такое, на которое можно записывать файлы, как сохранить что-нибудь в файл из UEFI и как адаптировать какой-то внешний код на С для работы в составе прошивки.
Если вам все еще интересно — жду вас под катом.

В предыдущей статье был описан ход исследования безопасности прошивок промышленных коммутаторов. Мы показали, что обнаруженные архитектурные недостатки позволяют легко подделывать образы прошивок, обновлять ими свитчи и исполнять свой код на них (а в некоторых случаях — и на подключающихся к свитчам клиентах). В дополнение, мы описали возможности закрепления внедряемого кода на устройствах. Подчеркнули низкое качество кода прошивок и отсутствие механизмов защиты от эксплуатации бинарных уязвимостей.
Мы обещали привести реальный пример сильной модели безопасности прошивок, где модификация исполнимого кода является очень нетривиальной задачей для потенциального злоумышленника.

Встречайте – подсистема Intel Management Engine, самая загадочная составляющая архитектуры современных x86-платформ.

Продолжаем говорить о безопасности UEFI, на этот раз речь пойдет об атаках на NVRAM и защите от них.
Неплохая, казалось бы, идея о том, что на микросхеме SPI можно хранить настройки практически вечно, не полагаясь на ненадежную и зависящую от батарейного питания CMOS SRAM, сыграла с разработчиками UEFI весьма злую шутку, теперь NVRAM с каждой новой версией стандарта обрастает все большим количеством костылей и подпорок, и конца этому процессу не видно. Если вам интересно, что именно пытаются подпереть костылем — эта статья для вас.
По традиции, всех, кто еще по каким-то причинам не читал первые три части — рекомендую начать с них, остальных с нетерпением жду под катом.

Наверное, нет человека, которого бы не раздражало, что самые важные пункты в договорах всегда пишутся «мелким шрифтом».

Но, зная об этом, раз за разом многие люди подписывают бумаги, не прочитав их внимательно, и платят комиссии, о которых не догадывались.

42-летний житель Воронежа нашел остроумный способ обратить эту особенность в свою пользу и теперь, пользуясь невнимательностью банкиров, собирается отсудить у них 24 миллиона рублей.

В конце 90-х компания Number Nine Visual Technology, тогдашний светоч дизайна видеокарт, предлагала на сайте VGA BIOS для своих PCI-устройств. Ничего примечательного в этом событии нет. Разве что, видеокарты Number Nine могли работать как на IBM PC-совместимых платформах, так и в MAC-системах, использующих Power PC. Поэтому одно и то же устройство комплектовалось различными файлами BIOS.

Скорее всего, тогда и не могло быть иначе. Как сейчас дело обстоит с поддержкой устройств, рассчитанных на работу в разных аппаратных средах? Ответ на этот вопрос дает спецификация UEFI, в рамках которой предлагается изящное решение – EFI Byte Code или EBC. С его помощью можно создавать кроссплатформенные приложения для firmware.

Давайте сразу обговорим масштаб времени. Процессор вашего компьютера живёт наносекундами: большинство CPU может сделать несколько вещей за одну наносекунду — в основном, простую математику и сравнения. Чтобы облегчить восприятие, предположим, что вы являетесь процессором и вместо наносекунд живёте и работаете секунда за секундой. Для ясности, применим эту метафору на одноядерном процессоре.

Вы можете одновременно держать несколько вещей в голове (регистр). Не больше, чем десяток или два в вашей активной памяти, но вы способны вспомнить любую из них практически мгновенно. Важную для себя информацию вы держите под рукой, будь то доступный за пару секунд отрывной блокнотик на рабочем столе (кэш L1) или одна из книжек на полке (кэш L2 и больше), которые настолько хорошо организованы, что любой фрагмент информации вы можете получить не более чем за десяток секунд или около того.

Перевод второй лекции Джеральда Сассмана

«Процедуры и процессы: подстановочная модель.»

Эти лекции были прочитаны 25 лет назад сотрудникам HP, но на самом деле это тот легендарный вводный курс 6.001, который читался в MIT в 1980 году. С тех пор эти лекции sine qua none во всем мире программирования. Хотелось бы чтобы каждый программист посмотрел этот курс, ничего не учит абстрактному мышлению лучше, чем SICP.
Приятного просмотра на ночь глядя.

В бета-версиях Windows 3.1 был скрытый и зашифрованный код, который при запуске на DR-DOS выдавал непонятное сообщение о вымышленной ошибке.

В релизе решили подобными фокусами не заниматься, но код проверок и само сообщение не убрали: они так и остались внутри WIN.COM, и достаточно изменить один байт, чтобы AARD-код снова выполнялся при каждом запуске.

Зачем его оставили? Неужели Microsoft рассчитывала однажды в будущем разблокировать эти сомнительные проверки?
Конечно же, нет. Даже сообщение в релизе осталось неизменённое: «Please contact Windows 3.1 beta support.» Если бы сообщение действительно предназначалось для показа, после окончания бета-тестирования его бы обновили.

Так зачем оставлять в релизе бессмысленный код, который никогда не выполняется?

В данной статье попытался очень подробно описать свои шаги при исследовании кода андроида и его выполнения в Dalvik VM. Мне было очень интересно узнать ответы, на вопросы:

• Как выглядит код, генерируемый С? (с позиции ARM)
• Как выглядит код, генерируемый Java?
• Как и где происходит выполнение кода?

Поэтому данная статья разбита на 3 части.

Мне кажется ставить перед собой такие вопросы и изучить их — важный момент при последующем написании кода, ведь андроид уже наступил на пятки и не знать его также, как и один из своих любимых инструментов (например С) уже будет не правильно.

Новая Зеландия приняла новый Закон о патентах, который запрещает патентовать программное обеспечение, фрагменты исходного кода и алгоритмы. Запрет принят после пяти лет споров, задержек и активных попыток лоббирования со стороны транснациональных корпораций.

По мнению сторонников отмены софтверных патентов, отсутствие интеллектуальной собственности в этой области только поощрит инновации. «Уточнив список того, что подлежит патентованию, мы даём новозеландским компаниям большую гибкость для адаптации и улучшения существующих изобретений, продолжая при этом защитить подлинные инновации», — сказал министр торговли Крейг Фосс (Craig Foss).

Решение законодателей приветствовали представители Института ИТ-профессионалов (IITP), которые отметили знаменательный день, когда «старые законы встретились с современными технологиями» и вышли победителями на благо разработчиков.

Статью с обзором ситуации с микроэлектроникой в России я закончил утверждением, что сейчас в России есть технические возможности для создания любых военных микросхем (если не считаться с ценой). Однако и в комментариях к той статье, и во многих других — всех больше волновал вопрос отсутствия (на уровне погрешности измерений) производства чисто-коммерческих (гражданских) высокотехнологичных продуктов. Этот вопрос волновал и меня, потому я постоянно мучил вопросами всех, кто так или иначе связан с высокими технологиями и бизнесом в России.

Ответ на него важен, если вы сами хотите создать конкурентный высокотехнологичный продукт — чтобы не потратить лучшие годы жизни в изначально неравных условиях.

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

Сразу нужно отметить, что в связи с многогранностью проблемы объем статьи получился довольно большой, так что можно начать читать с резюме в конце, и затем прочитать лишь те разделы, которые вызовут интерес. Сразу хочу предупредить — повествование «нелинейное», соседние заголовки могут описывать разные аспекты проблемы и быть друг с другом практически не связанными.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

Тема перевода зарубежной профессиональной IT-литературы стоит достаточно остро, многие любят читать книги в оригинале по различным причинам, таким так время выхода русского перевода с запозданием на годы, недостаточный профессионализм переводчика и соответствующая потеря тонкостей и авторского стиля и т.д.

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Вернул из черновиков

О переводе

Это перевод 10 главы книги The Passionate Programmer: Creating a Remarkable Career in Software Development. Её автор — Chad Fowler — талантливый Ruby-разработчик, известный докладчик на конференция, посвящённых Ruby и IT в целом. Бывший саксофонист, а сейчас — CTO 6Wunderkinder.

В книге говорится о разных аспектах карьеры программиста, даются интересные советы как начинающим разработчикам, как так устоявшимся профессионалам. Книга состоит из 53 глав (кроме того, после некоторых глав есть интересные рассказы, один из которых уже дважды переводили на Хабре). Главы достаточно независимы и можно знакомиться с ними в любом порядке. Книга понравится многим программистам, которым интересен взгляд заслуженного профессионала на современную карьеру в IT. И конечно, я рекомендую купить данную книгу в электронном или печатном виде в знак благодарности автору.

Привет, Хабр!

Решил посмотреть лучшие посты своего любимого хаба и с ужасом обнаружил, что такой фичи нет.

В связи с тем, что данная возможность появилась, а топик сносить в черновики не хочется — ниже рейтинг самых комментируемых и добавляемых в избранное статей самых популярных хабов. Кроме того пару слов о реализации скрипта.

Последняя часть инфраструктуры USB — хабы. Хотя хабы — отдельные USB-устройства, они достаточно тесно связаны с другими частями инфраструктуры, чтобы спецификация хабов была частью основной спецификации USB, а код поддержки — частью ядра, расположенной в файле bus/usb/hub.inc.

Задачи хабов таковы.

• Хабы предоставляют питание всем подключённым устройствам.
• Хабы оповещают хост о подключении и отключении устройств.
• Хабы делают сброс подключённого устройства, попутно определяя его скорость, по команде с хоста.
• Хабы транслируют весь трафик, приходящий от хоста, подключённым устройствам в период после сброса и до отключения, а также трафик от устройств в обратную сторону.
• HighSpeed-хабы содержат Transaction Translator, связывающий HighSpeed-шину с низкоскоростной USB1-шиной.

Трансляция трафика без переключения скорости происходит полностью прозрачно для хоста. Расщеплёнными транзакциями занимается хост-контроллер EHCI, здесь от софта важно только заполнить те поля в аппаратной части структуры канала, которые содержат адрес TT-хаба и порт в TT-хабе — и, разумеется, учитывать время транзакций при планировании. Драйвер хабов управляет остальными пунктами списка задач.


Хабы имеют код класса устройства 9, код подкласса устройства 0 и три варианта 0, 1, 2 для кода протокола. Согласно спецификации USB, HighSpeed-хаб обязан поддерживать режим работы с единым TT для всех своих портов, и дополнительно может, но не обязан, поддерживать режим работы с отдельным TT для каждого порта. Типичный случай — режим с различными TT отсутствует, тогда код протокола равен 0. В случае поддержки такого режима в данных конфигурации должны быть два варианта дескриптора интерфейса с одинаковым номером интерфейса. Тогда код протокола 1 идентифицирует режим с единым TT, который должен быть принят по умолчанию, а код протокола 2 — режим с различными TT, включаемый командой SET_INTERFACE. Существование в живой природе хабов, поддерживающих режим с различными TT, не подтверждено, как и польза от этого режима, поэтому драйвер хабов даже не пытается его обнаружить и включить и просто использует режим единого TT, включённый по умолчанию.

Обнаружив интерфейс класса 9, уровень логического устройства читает структуру usb_hub_callbacks, содержащую указатели на функции драйвера usb_hub_init и usb_hub_disconnect. Работа драйвера начинается, когда уровень логического устройства вызывает usb_hub_init, и заканчивается, когда уровень поддержки каналов вызывает usb_hub_disconnect в ответ на отключение устройства.

Удивительная история разыгралась с экспертом по информационной безопасности Драгосом Руи (Dragos Ruiu). Он утверждает, что еще 3 года назад ему удалось обнаружить вирус, поражающий BIOS, скрытно распространяющийся через модификацию контролеров флэш-карт и, что самое удивительное, использующий для коммуникаций между зараженными машинами ультразвук, производимый системным динамиком материнской платы!

Впервые Драгос заподозрил неладное, когда его MacBook Air, на котором он только что установил новую копию OS X, спонтанно обновил загрузочную прошивку. Он попытался загрузиться с CD-Rom, но ему это не удалось. Обнаружилось, что машина без запросов пользователю изменяет настройки загрузки.

Эксперт запустил на машине Open BSD, но странности в поведении не исчезли. Все так же без спроса изменялась конфигурация, более того, обнаружилась странная сетевая активность по протоколу IPv6, который был вообще отключен в системе. Еще более странным, оказалась способность зараженных машин передавать небольшие порции данных на другие инфицированные машины, находящиеся в непосредственной близости, даже когда Wi-Fi и Bluetooth, кабели Ethernet и питания были физически отсоединены!

Читая небольшую заметку на известном новостном ресурсе, увидел забавное вступление: «Новые планшеты Microsoft как будто созданы для того, чтобы их не покупать». Сомнительное, на мой взгляд, высказывание все же подкреплено нелегкой участью первой версии Surface RT и удивительной похожестью на него нового Surface 2. Однако, наша компания всегда в первую очередь шла на поводу клиентов.

Суть данной статьи, которая может показаться читателям Хабра немного провокационной, заключается в следующем: в конце 2013 года мы представляем новый продукт – электронный ключ Guardant Code micro для защиты приложений на Windows RT от пиратства. Кто-то, возможно, уже крутит пальцем у виска, но мы действительно предлагаем разработчикам серьезных (!) приложений под Windows RT защитить свой софт с помощью аппаратного ключа.

В статье вы узнаете:
1. Зачем нам понадобилась Windows RT 8.1 и чем плоха первая Windows RT с точки зрения наших задач
2. Как вся эта конструкция работает
3. Как ограниченность архитектуры не позволила нам обеспечить поддержку электронного ключа в виде microSD-карты
4. … и какими костылями ее можно обойти

Привет, %username%!

В сегодняшнем посте речь пойдет о криптостойкости генераторов псевдослучайных чисел (ГПСЧ).
Для начала определимся, что же такое криптостойкий ГПСЧ (КСГПСЧ).

КСГПСЧ должен удовлетворять «тесту на следующий бит». Смысл теста в следующем: не должно существовать полиномиального алгоритма, который, зная первые k битов случайной последовательности, сможет предсказать k+1 битов с вероятностью более 50 %.

Wikipedia

Возможно, кое-кто из читателей использовал такие ГПСЧ, как регистры сдвига с линейной обратной связью (РСЛОС) или любимый многими программистами Вихрь Мерсенна. Я постараюсь показать, что оба этих способа, несмотря на весьма хорошие статистические свойства и большие периоды, не соответствуют приведенному выше определению и их нельзя считать криптографически стойкими, а также предложу, в качестве альтернативы, два очень надежных ГПСЧ.

UEFI

UEFI (Unified Extensible Firmware Interface) — замена устаревшему BIOS. Эта спецификация была придумана Intel для Itanium, тогда она еще называлась EFI (Extensible Firmware Interface), а потом была портирована на x86, x64 и ARM. Она разительно отличается от BIOS как самой процедурой загрузки, так и способами взаимодействия с ОС. Если вы купили компьютер в 2010 году и позже, то, вероятнее всего, у вас UEFI.

На Хабре уже много писали о самодельных электронных устройствах разного калибра. То, о чем хочу рассказать я, не стоит ставить в один ряд с “умным домом” или производством деревянных мышей. Наверняка, те, кто только начинает развлекаться с DIY и думают, с чего начинать, найдут для себя что-нибудь полезное. Я надеюсь, этот пост лишний раз убедит новичков в том, что в нашем деле годится любая, даже самая странная, на первый взгляд, идея.

Итак, идея

Всё началось с того, что в один прекрасный день я решил жениться! Заявление, подготовка к празднику, все дела. Но вот задача: сделать оригинальные приглашения на свадьбу. Подписывать куски картона не хотелось. Душа просила хардкорного хэндмэйда, далёкого от традиционных свадебных шаблонов. И вот на моё “и вообще, можно электронные девайсы сделать” невеста сказала: “Круто! Давай!”