Несколько лет назад один из членов нашей команды заказал себе OnePlus 6T прямо из Китая. Телефон пришел в оригинальной упаковке и типовой комплектации: с зарядным устройством, кабелем и чехлом. Смартфон без проблем проработал год, ничем, на первый взгляд, не отличаясь от тех, что продаются в России.
Но однажды приложения начали предупреждать о наличии root-доступа, а некоторые, особенно банковские, вообще перестали запускаться. При этом прошивка никаким образом не модифицировалась, а обновления устанавливались исключительно из официальных источников, относящихся к ОС. Такое странное поведение смартфона побудило нас провести исследование, результаты которого описаны в этой статье.

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

Привет, Хабр! В этой статье рассказываем о созданном нами устройстве, которое помогает тестировать электронные девайсы в процессе разработки.  Речь идет об устройстве для автоматизации и имитации процесса отключения/переподключения USB-гаджетов. Подробности разработки и самого устройства – под катом.

С 27 по 29 августа 2021 года в онлайн-формате проходило соревнование YauzaCTF. Соревнование проводилось в формате Task-Based, принять участие могла любая команда, желающая попробовать свои силы. Участникам предстояло в течение 48 часов решить задания следующих категорий: web, reverse, PWN, forensics, crypto, OSINT, joy, hardware, pentest и emulation.

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

Предупреждение! Далее следует лонгрид про нули и единицы (в прямом смысле).

Лето – пора практик для студентов вузов. Команда Raccoon Security регулярно приглашает всех желающих на персональные и групповые стажировки. Этим летом к нам на стажировку пришли студенты с кафедры ИУ4 МГТУ им. Н.Э. Баумана. Целый месяц они принимали активное участие в производственных процессах и применяли на практике полученные в вузе теоретические знания. Мы решили рассказать об этой стажировке и поделиться отзывами студентов, которые в ней поучаствовали.

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

Чаще всего, когда речь заходит о стендах тестирования электронных устройств, мы представляем массовое производство. Там подобные стенды не просто правило хорошего тона, а острая необходимость. И это правильный подход! На эту тему есть пара интересных статей: «Как выглядит тестирование электроники Flipper Zero», «Серийное производство электроники в России. Автоматизация тестирования».

На многопоточных производствах обычно используют готовые решения для тестирования и отладки устройств, такие как PCBA Test, Semco Machine Corporation или INGUN. Для первичной отладки оборудования готовые решения могут не подойти: у них большие габариты (стенд может занимать треть стола Embedded-разработчика), компоненты таких стендов труднодоступны для модификации.

А что, если изделие не предполагает серийного производства? Как проводить отладку небольшого устройства, к которому неудобно подключать разъемы? Припаивание проводов к тест-пойнтам имеет свои нюансы: этот процесс может быть долгим и трудозатратным, из-за следов пайки портится внешний вид платы, да и вообще неаккуратная пайка может привести к отрыванию контактных площадок.

В этой статье мы поделимся опытом создания стендов для отладки.

Давайте представим, что вы студент старших курсов вуза по какому-нибудь околоИБшному направлению или специалист в смежной области, желающий сменить сферу деятельности на исследование защищенности аппаратного или программного обеспечения. Потенциальный работодатель почти всегда требует практический опыт, но как его получить?

Можно выбрать какое-нибудь устройство и самостоятельно ковырять его до победного конца (или полного разочарования в своих навыках). А можно делать подобное в рамках стажировки, где опытные наставники проведут по этому тернистому пути, поддерживая и направляя, если это необходимо.

Далее вас ждет история о том, что я делал на стажировке в НТЦ "Вулкан".

Команда RaccoonSecurity приглашает всех желающих принять участие в онлайн-стажировке-хакатоне RaccHack 2021 на тему Smart Office. Мероприятие будет проходить в течение двух месяцев с 2 августа по 2 октября.

Собирая как-то в очередной раз разные ревизии для одного и того же проекта вручную, у нас возникла навязчивая мысль: а можно ли собирать это все автоматически по нажатию одной кнопки? Забегая вперед, сообщим, что мы решили эту проблему, причем мы упростили сборку проекта не только на локальном компьютере, но и запустили удаленную сборку на GitLab CI.

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

Команда Racoon Security постоянно находится в поиске новых технологий для применения в исследованиях и контрактном производстве. В очередной раз просматривая список докладов прошедших выставок Embedded World 2019 и Embedded World 2020, мы наткнулись на документ от NXP Semiconductors - Extend MCU Security Capabilities Beyond Trusted Execution with Hardware Crypto Acceleration and Asset Protection. Так мы узнали про технологию SRAM PUF, в основе которой лежит так называемая Физически неклонируемая функция (Physically unclonable function) на основе состояния памяти. Мы решили разобраться, как работает эта технология, есть ли у нее недостатки и как ее можно применить в наших разработках.

Разработка своего устройства от А до Я. Часть 2: Создание устройства

В предыдущей статье мы рассказали о том, что такое электронное устройство и как начать разработку собственного девайса. Мы рассмотрели следующие этапы:

• проработка концепции устройства;
• разработка функциональной схемы;
• разработка принципиальной схемы;
• закупка компонентов;
• макетирование и симуляция устройства.

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

Задумывались ли вы когда-нибудь о том, чтобы разработать собственное электронное устройство, но не знали, с чего начать? Тогда приглашаем вас к прочтению данной статьи, в которой мы постараемся осветить весь процесс создания своего электронного устройства – от концепции до реального девайса на примере хобби-проекта одного из наших сотрудников. Статья разделена на две части и имеет следующий план:

• Часть 1: От концепции до макета
  
  • Что такое электронное устройство
  • Концепция устройства
  • Функциональная схема
  • Принципиальная схема
  • Закупка компонентов
  • Макетирование и симуляция устройства
• Часть 2: Создание устройства
  
  • Разработка печатной платы
  • Разработка корпуса и оснасток
  • Верификация и исправление ошибок
  • Отправка платы на производство
  • Создание корпуса
  • Сборка и отладка устройства

Далее повествование будет вестись от лица сотрудника.

В конце 2020 года ожидается выход устройств с поддержкой интерфейсов нового поколения USB4/Thunderbolt 4. Данные интерфейсы похожи, однако имеют ряд принципиальных отличий. Среди таких отличий можно выделить наиболее значимое: спецификации на USB4 общедоступные и любой желающий может изучить основные принципы работы данного интерфейса, в отличие от Thunderbolt 4.

В данной статье мы рассмотрим изменения, которые претерпел интерфейс USB4 по сравнению с предыдущей версией (USB 3.2), разберем архитектуру USB4 и перечислим его основные характеристики.

Более подробную информацию можно найти в спецификации на USB4.

Зачем?!

Наверное, это первая эмоция большинства людей, прочитавших название статьи. Однако, давайте представим следующую ситуацию: в процессе исследования устройства вы доходите до точки, когда можете исполнить внутри устройства свой код, и хотите вывести через UART заветное "Hello, Habr!", помигать светодиодами на плате как на новогодней ёлке или включить JTAG, но всего этого в вашем распоряжении нет.

В этой статье мы покажем необычный способ трассировки прошивки устройств с помощью эмулятора SPI-флешек.

Год от года мы наблюдаем технический прогресс: мощность компьютеров растет, скорости передачи данных увеличиваются, появляются новые стандарты… Но, как говорилось в одном известном фильме, с великой силой приходит великая ответственность! Что мы получаем (помимо большой скорости) от новых стандартов и интерфейсов? Какие угрозы таят в себе Thunderbolt и USB4? Так ли опасен Thunderspy, как его описывают? Давайте разберемся!

В современных embedded-устройствах используется огромное количество различных разъемов, таких как USB Type-B, miniUSB, microUSB и так далее. Все они отличаются форм-фактором, максимальной пропускной способностью и другими различными характеристиками. Самым верным решением в данной ситуации было бы минимизировать количество используемых разъемов и остановиться на каком-то одном, «едином» для большинства разработок. Наиболее перспективным выглядит использование разъема Type-C. В нем объединены невероятная пропускная способность с высокой мощностью питания. Такие производители, как Apple, Huawei, Sony уже внедряют разъем Type-C в свои разработки, постепенно отказываясь от использования «старых» разъемов. А чем embedded-разработчики хуже?

В данной статье мы приведем общую информацию, необходимую для практического применения Type-C. Наиболее полезной она будет для новичков в сфере embedded, но надеемся, что каждый найдет в ней что-то интересное.

В статье рассмотрены методы геопозиционирования сетевых интерфейсов по IP-адресу на примере API-сервиса криптобиржи Binance. Геопозиционирование основано на дистанционно-временных моделях пересчета времени кругового обхода (RTT) в дистанцию и определения примерного местоположения сетевого интерфейса.

Современным электронным сервисам очень важно знать о географическом местоположении клиентов для «тонких» настроек своих маркетинговых процессов. Повсеместно используются разные техники геопозиционирования пользователей, основанные на привязке к базовым станциям мобильной связи и точкам доступа Wi-Fi. Однако существует целый ряд других задач, для решения которых необходимо знать геопозицию не самого пользователя, а сервера и его сетевого интерфейса. Такие сервисы, как MaxMind (безусловный отраслевой лидер), широко известны публике (можно также почитать здесь), но в целом в сети мало материала в открытом доступе, посвященного технологическим вопросам глобального геопозиционирования хоста по его IP-адресу. В этой статье мы расскажем о некоторых решениях в этой предметной области и поделимся результатами наших исследований.

За подробностями следуйте под кат.

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

В первой части нашего цикла статей мы начали освещать тему эффективности применения методологии TDD для микроконтроллеров (далее – МК) на примере разработки прошивки для STM32. Мы выполнили следующее:

1. Определили цель и инструменты разработки.
2. Настроили IDE и фреймворк для написания тестов.
3. Написали тест-лист для разрабатываемого функционала.
4. Создали первый простой тест и запустили его.

Во второй статье мы описали процесс разработки платформонезависимой логики по методологии TDD.

В заключительной статье мы опишем, как запускали разработанный код на STM32F103C8, а также подведем итоги всего нашего исследования эффективности TDD для микроконтроллеров.

Подробности – под катом.

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

В предыдущей статье мы начали освещать тему эффективности применения методологии TDD для микроконтроллеров (далее – МК) на примере разработки прошивки для STM32. Мы выполнили следующее:

1. Определили цель и инструменты разработки.
2. Настроили IDE и фреймворк для написания тестов.
3. Написали тест-лист для разрабатываемого функционала.
4. Создали первый простой тест и запустили его.

В этой статье расскажем, как мы применили методологию TDD для реализации тестов из тест-листа и написания кода прошивки для их успешного выполнения. При написании тестов будем использовать специальные тестовые объекты для ликвидации зависимостей разрабатываемой логики от других программных модулей. В конце статьи мы представим бизнес-логику проекта и проанализируем особенности применения методологии TDD для реализации прошивки МК. Подробности – под катом.

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

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

Сфера применения встраиваемых систем постоянно расширяется, сложность выполняемых ими задач растет. Это в свою очередь повышает риск внесения ошибок в процессе разработки, что увеличивает вероятность весьма дорогостоящих дефектов в ПО.

Одной из наиболее популярных методологий улучшения качества разрабатываемых приложений является Test-driven development (TDD). Но эффективна ли методология TDD для разработки встраиваемых систем? Ответ на этот вопрос будем искать под катом.