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

Рассказываю, почему SQLite отлично подойдет вам в повседневной работе. И неважно, разработчик вы, аналитик, тестировщик, админ или продакт-менеджер.

Вы когда-нибудь задумывались, как много вокруг умной электроники? Куда ни глянь, натыкаешься на устройство, в котором есть микроконтроллер с собственной прошивкой. Фотоаппарат, микроволновка, фонарик... Да даже некоторые USB Type C кабели имеют прошивку! И всё это в теории можно перепрограммировать, переделать, доработать. Вот только как это сделать без документации и исходников? Конечно же реверс-инжинирингом! А давайте-ка подробно разберём этот самый процесс реверса, от самой идеи до конечного результата, на каком-нибудь небольшом, но интересном примере!

Дисклеймер:

• Puppeteer — для доступа к веб-страницам.
• Cheerio — для парсинга HTML-кода.
• Tor — для выполнения каждого запроса с различного IP-адреса.

В предыдущей статье мы разбирались с Vcc-glitch-атаками при помощи ChipWhisperer. Нашей дальнейшей целью стало поэтапное изучение процесса считывания защищенной прошивки микроконтроллеров. С помощью подобных атак злоумышленник может получить доступ ко всем паролям устройства и программным алгоритмам. Яркий пример – взлом аппаратного криптокошелька Ledger Nano S с платой МК STM32F042 при помощи Vcc-glitch-атак.

Интересно? Давайте смотреть под кат.

Предыстория

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

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

Введение

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

Ни одной. Всё, что есть в интернете, касается лишь одного или двух аспектов этого процесса. Ну например: давайте набросаем корпус и распечатаем на 3D-принтере. Или купим типовой и насверлим в нём отверстий. Хотя на Хабре и есть пара материалов, но они тоже не так полны информацией, как могли бы быть.

Но так, чтобы были расписаны все этапы, от идеи до серийного производства, — я такого не нашёл. Поэтому решил написать своё руководство, максимально наполненное фактами, картинками и примерами.

Как спроектировать корпус — схема работы

Необходимое вступление

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

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

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

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

Зачем

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

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.