Меня давно интересовал вопрос, насколько сложно написать собственный загрузчик операционной системы. Я не говорю о простой программе, выводящей «Hello, World!», а о полноценном загрузчике, который передаёт управление от встроенного программного обеспечения компьютера ядру операционной системы. Современные загрузчики представляют собой сложные программы, способные загружать множество операционных систем различными способами, учитывая массу нюансов, связанных с программным и аппаратным обеспечением. Читая их исходный код, легко утонуть в деталях и потерять понимание сути и реализации.

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

В этой статье я хочу поделиться результатом своих исследований в области моделирования систем управления двигателями переменного тока. В качестве объекта управления был выбран синхронный двигатель с постоянными магнитами PMSM (Permanent Magnet Synchronous Machine) как наиболее распространенная машина в современных транспортных средствах. Основное внимание будет уделено построению математической модели системы, объекта управления, и алгоритмов для симуляции. Для реализации модели я выбрал open source решения: Python control, Scilab. Мне было интересно, возможно ли использование свободных средств моделирования для построения более-менее сложных и реальных систем. Далее я поделюсь своими впечатлениями. В первой части статьи приводится теоретический материал, где описываются основные уравнения двигателя и элементы теории управления. Для теоретической части необходимы базовые понимания электротехники, ниже приложу ссылки, где можно обновить знания. Я постарался проработать разные источники литературы, чтобы взять необходимый минимум, с которым самому пришлось столкнуться для понимания сути процессов управления двигателем. Читатель вправе пропустить матчасть и перейти сразу к описанию реализации, и при необходимости вернуться к некоторым теоретическим аспектам в этом материале, или других источниках. Реализация алгоритмов управления построена по классическому принципу с помощью диаграммы потоков.

В новой статье мы расскажем о необычном случае восстановления блока SRS от Audi A4, который был "сломан" после неудачного обновления прошивки. Вы узнаете:

Как внутренняя ошибка B2000 блокирует работу ЭБУ и почему её невозможно устранить стандартными методами.

Что такое технология voltage glitching и как она позволяет обойти защиту закрытых процессоров.

Какие инструменты и методы используются для восстановления автомобильных блоков управления.

Практические шаги по работе с процессором V850E2 и восстановлению флеш-памяти.

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

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

Но тут история иная. Во-первых, цена как у реальных приборов. Во-вторых, это не абсолютный ноунейм. И в-третьих – производитель открыто заверяет, что установлен дорогой инфракрасный датчик. Так почему бы не попробовать?

Под катом небольшой рассказ про все эти датчики и пара советов, как не промахнуться.

Меня зовут Максим, я ведущий разработчик в VK. Занимаюсь инфраструктурой доставки электронной почты в проекте Mail.ru. Наша команда разработала и довела до эксплуатации файловую систему (ФС) на FUSE в рамках проекта распределённой почтовой очереди. В проекте требовалось реализовать сетевую ФС, которая сохраняет данные в трёх копиях, в разных ЦОДах. Цель — повысить отказоустойчивость, чтобы даже полный выход из строя одного ЦОДа не приводил к нарушениям SLA. Эта статья для всех, кто интересуется файловыми системами и хранением данных. Мы обсудим:

- зачем писать свою ФС;

- как написать свою ФС с помощью фреймворка FUSE;

- какие подводные камни есть у эксплуатации FUSE в production.

Эта статья — результат трёх лет разработки ФС. Сейчас самое время заварить чай, рассказ будет долгим. 

Какие цели у этого руководства:
Обеспечение доступа через VDS сервер используя технологии xray, посредством маршрутизатора Keenetic и скрипта Xkeen.

Кому предназначено:
Для людей, которые хотят решить поставленную задачу, не вдаваясь во все тонкости настройки, выполняя инструкции шаг за шагом.

Здраствуйте меня зовут Дмитрий. Недавно я написал статью как собрать прошивку для одноплатного компьютера Orange PI i96 с нуля. Если вы не читали то очень советую. И там я упоминал что для того чтобы собрать прошивку на новом ядре Linux, мне пришлось переписать драйверы с учетом архитектуры Device Tree, которую использует современное ядро. В этой статье я опишу как я это сделал.

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

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

Уже сто пятьдесят лет никто не решается массово заредизайнить клавуа, у Эпл последняя выглядит вот так. Давайте немного подвигаем кнопки и посмотрим как можно сделать лучше.

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

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

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

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

Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта,  в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.

Когда мы разрабатывали модуль ghidra nodejs для инструмента Ghidra, мы поняли, что не всегда получается корректно реализовать опкод V8 (движка JavaScript, используемого Node.js) на языке описания ассемблерных инструкций SLEIGH. В таких средах исполнения, как V8, JVM и прочие, один опкод может выполнять достаточно сложные действия. Для решения этой проблемы в Ghidra предусмотрен механизм динамической инъекции конструкций P-code — языка промежуточного представления Ghidra. Используя этот механизм, нам удалось превратить вывод декомпилятора из такого:

В прошлом году наша команда столкнулась с необходимостью анализа байткода V8. Тогда еще не существовало готовых инструментов, позволявших восстановить такой код и обеспечить удобную навигацию по нему. Было принято решение попробовать написать процессорный модуль под фреймворк Ghidra. Благодаря особенностям используемого языка описания инструкций на выходе мы получили не только читаемый набор инструкций, но и C-подобный декомпилятор. Эта статья — продолжение серии материалов (1, 2) о нашем плагине для Ghidra.

Между написанием процессорного модуля и статьи прошло несколько месяцев. За это время спецификация SLEIGH не изменилась, и описанный модуль работает на версиях 9.1.2–9.2.2, которые были выпущены за последние полгода.

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

В документации можно прочесть, что процессорные модули для Ghidra пишутся на языке SLEIGH, который произошел от языка SLED (Specification Language for Encoding and Decoding) и разрабатывался целенаправленно под Ghidra. Он транслирует машинный код в p-code (промежуточный язык, используемый Ghidra для построения декомпилированного кода). Как у языка, предназначенного для описания инструкций процессора, у него достаточно много ограничений, которые, однако, можно купировать за счет механизма внедрения p-code в java-коде.

Исходный код созданного процессорного модуля представлен на github. В этой статье будут рассматриваться принципы и ключевые понятия, которые использовались при разработке процессорного модуля на чистом SLEIGH на примере некоторых инструкций. Работа с пулом констант, инъекции p-code, анализатор и загрузчик будут или были рассмотрены в других статьях. Также про анализаторы и загрузчики можно почитать в книге The Ghidra Book: The Definitive Guide.