This media is not supported in your browser
VIEW IN TELEGRAM
В Рекрипте есть не только заказные проекты и исследования, но и инициативные. Они позволяют нам профессионально расти и развиваться, оттачивая мастерство и приобретая новые навыки и знания
#ии #видеоаналитика
#ии #видеоаналитика
🔥12👍3
А тем временем мы поздравляем одну из наших замечательных сотрудниц с успешной защитой на ОТЛИЧНО дипломного проекта на курсах повышения квалификации по Data Science в МФТИ. С учётом диплома курсы длились около года и были весьма насыщенными: 6 часов лекций в неделю, плюс, домашние задания. Математический аппарат, практика. Плюс, практика в рамках рабочих задач. На текущий момент ещё несколько сотрудников компании Рекрипт повышают свою квалификацию и получают дополнительное образование в МФТИ по направлению Data Science и ИИ. На картинке результат обучения нескольких классификаторов
🔥9👍4🤔1
Вышел препринт нашей статьи с основателем блокчейн-платформы Emercoin Олегом Ховайко. Олегу удалось существенно улучшить параметры безопасности RC4 и встроить генератор псевдослучайных чисел на его базе в ядро Emercoin. Одна из ключевых идей генератора - возможность добавления энтропии без лишних механизмов синхронизации, которые довольно серьёзно тормозят его работу. Новый генератор прекрасно прошёл тесты PractRand на нескольких 32-х терабайтовых последовательностях. Для сравнения исходный генератор на базе классического RC4 выдавал "предупреждение о неслучайности" после 1 Тб. При этом скорость скачивания блокчейна со схемой на базе RC4OK (по предложению Рона Ривеста - автора оригинального RC4 - новый алгоритм получил название RC4OK, где OK - сокращение от Oleg Khovaiko) выросла втрое по сравнению с предыдущей схемой, используемой в Emercoin.
Моя роль в работе - аудит нового алгоритма, анализ возможностей для взлома. Это та самая работа, которую действительно приятно и интересно делать. Олег - отличный специалист.
Ссылка на статью: https://eprint.iacr.org/2023/1486/
Там, в статье, ссылки на исходники и результаты тестов
#rc4ok #криптография
Моя роль в работе - аудит нового алгоритма, анализ возможностей для взлома. Это та самая работа, которую действительно приятно и интересно делать. Олег - отличный специалист.
Ссылка на статью: https://eprint.iacr.org/2023/1486/
Там, в статье, ссылки на исходники и результаты тестов
#rc4ok #криптография
👍11
Закладки или бэкдоры в нейросетях - тема популярная. Особенно - в нейросетях глубокого обучения. Найти такие бэкдоры гораздо сложнее, чем искать их в обычном коде, включая уже скомпилированный машинный код. А всяких интересных дел с их помощью можно много наделать, учитывая лавинообразное распространения технологий ИИ в нашей жизни. Чтобы встроить бэкдор, как правило, нужен оригинальный или близкий к оригинальному датасет, на котором обучается модель. Т.е. получается, что тот, кто обучает модель, тот и встраивает закладку, ибо хорошие датасеты нынче приватны и недёшевы (привет визионерам и футурологам, рассказывавшим нам на пафосных пиджачных конференциях некоторое время назад, что датасеты будут доступны каждому желающему в изрядном количестве 😜).
Авторы работы "A Data-free Backdoor Injection Approach in Neural Networks" задались вопросом, можно ли "забэкдорить" уже обученную модель. И выяснили, что вполне себе да. Привели методику, исходники и примеры. Как это можно использовать? Например, можно осуществлять атаку на цепочку поставок, находясь в этой цепочке где-то между производителем модели и её конечным пользователем.
Ссылка на статью: https://www.usenix.org/conference/usenixsecurity23/presentation/lv
Ссылка на исходники: https://github.com/lvpeizhuo/Data-free_Backdoor
#ии #почитать
Авторы работы "A Data-free Backdoor Injection Approach in Neural Networks" задались вопросом, можно ли "забэкдорить" уже обученную модель. И выяснили, что вполне себе да. Привели методику, исходники и примеры. Как это можно использовать? Например, можно осуществлять атаку на цепочку поставок, находясь в этой цепочке где-то между производителем модели и её конечным пользователем.
Ссылка на статью: https://www.usenix.org/conference/usenixsecurity23/presentation/lv
Ссылка на исходники: https://github.com/lvpeizhuo/Data-free_Backdoor
#ии #почитать
GitHub
GitHub - lvpeizhuo/Data-free_Backdoor: This is the source code for Data-free Backdoor. Our paper is accepted by the 32nd USENIX…
This is the source code for Data-free Backdoor. Our paper is accepted by the 32nd USENIX Security Symposium (USENIX Security 2023). - lvpeizhuo/Data-free_Backdoor
👍7😱1
Сжато и со ссылками про разработку руткитов под Windows:
https://idov31.github.io/2022/07/14/lord-of-the-ring0-p1.html
https://idov31.github.io/2022/08/04/lord-of-the-ring0-p2.html
https://idov31.github.io/2022/10/30/lord-of-the-ring0-p3.html
https://idov31.github.io/2023/02/24/lord-of-the-ring0-p4.html
https://idov31.github.io/2023/07/19/lord-of-the-ring0-p5.html
#windows #malware #почитать
https://idov31.github.io/2022/07/14/lord-of-the-ring0-p1.html
https://idov31.github.io/2022/08/04/lord-of-the-ring0-p2.html
https://idov31.github.io/2022/10/30/lord-of-the-ring0-p3.html
https://idov31.github.io/2023/02/24/lord-of-the-ring0-p4.html
https://idov31.github.io/2023/07/19/lord-of-the-ring0-p5.html
#windows #malware #почитать
Интересно про внутреннее устройство EDR в части взаимодействия между процессами режима пользователя и драйверами ядра. Практическое применение "ослепления" спорно, но знать механизмы не будет лишним
https://sensepost.com/blog/2023/filter-mute-operation-investigating-edr-internal-communication/
#windows #почитать
https://sensepost.com/blog/2023/filter-mute-operation-investigating-edr-internal-communication/
#windows #почитать
👍1
Хороший анализ хорошей атаки от создателя блокчейн-платформы Emercoin и сервиса EmerDNS Олега Ховайко
#offensive #блокчейн
#offensive #блокчейн
Emercoin
Official website of Emercoin
Decentralized solutions for business and personal use
👍1
Forwarded from Oleg Khovayko
Исаав продал право первородства за чечевичную похлёбку. Библейская история.
В интернетах в полный рост наблюдаем нечто похожее - продажа безопасности за удобство пользования.
Ещё когда появился Letsencrypt, у меня возникло недоумение. Что мол да, удобно и бесплатно. Но стоит злоумышленнику перехватить контроль над DNS-записью, он с помощью Letsencrypt сгенерирует себе новый сертификат для MITM-сервера, и далее будет компроментировать весь трафик на сайт, защищённый TLS. И в таком случае даже использование RR-записей TLSA/CAA не помогает, так как если враг захватил DNS, то он естественно может в те записи напихать всё что ему надо.
И вот, прямое доказательство моих подозрений: https://www.opennet.ru/opennews/art.shtml?num=59965
Тут правда замешан именно хостер, а не владелец DNS-записи. Именно хостер переставил IP на MITM-сервер, и потом у Letsencrypt заказал себе сертификат, через который и стал гонять трафик.
Но что ни говори, а Letsencrypt и подобные ему ACME-серверы превращают 2FA доказательство идетничности сервера (DNS+TLS) в 1FA, где идентичность удостоверяется только DNS-ом. И что самое глупое и обидное - что эту деградацию защиты можно сделать и для сервера, кто честно покупает сертификат "где надо". Скажем, есть надёжный банк, который купил зелёеый сертификат megabank.com у verisign за $300. Но если злоумышленник скомпрометирует DNS-запись - он и ноавый сертификат у Letsencrypt получит, и CAA запись поправит, внеся туда свежеполученный сертификат как валидный.
Моё мнение таково, что форум браузеров должен запретить удобные сервисы типа Letsencrypt. Или же - надо переходить на emerDNS, с локальным резолвингом. Тогда перехват DNS невозможен.
В интернетах в полный рост наблюдаем нечто похожее - продажа безопасности за удобство пользования.
Ещё когда появился Letsencrypt, у меня возникло недоумение. Что мол да, удобно и бесплатно. Но стоит злоумышленнику перехватить контроль над DNS-записью, он с помощью Letsencrypt сгенерирует себе новый сертификат для MITM-сервера, и далее будет компроментировать весь трафик на сайт, защищённый TLS. И в таком случае даже использование RR-записей TLSA/CAA не помогает, так как если враг захватил DNS, то он естественно может в те записи напихать всё что ему надо.
И вот, прямое доказательство моих подозрений: https://www.opennet.ru/opennews/art.shtml?num=59965
Тут правда замешан именно хостер, а не владелец DNS-записи. Именно хостер переставил IP на MITM-сервер, и потом у Letsencrypt заказал себе сертификат, через который и стал гонять трафик.
Но что ни говори, а Letsencrypt и подобные ему ACME-серверы превращают 2FA доказательство идетничности сервера (DNS+TLS) в 1FA, где идентичность удостоверяется только DNS-ом. И что самое глупое и обидное - что эту деградацию защиты можно сделать и для сервера, кто честно покупает сертификат "где надо". Скажем, есть надёжный банк, который купил зелёеый сертификат megabank.com у verisign за $300. Но если злоумышленник скомпрометирует DNS-запись - он и ноавый сертификат у Letsencrypt получит, и CAA запись поправит, внеся туда свежеполученный сертификат как валидный.
Моё мнение таково, что форум браузеров должен запретить удобные сервисы типа Letsencrypt. Или же - надо переходить на emerDNS, с локальным резолвингом. Тогда перехват DNS невозможен.
www.opennet.ru
Зафиксирован перехват шифрованного трафика jabber.ru и xmpp.ru
Администратор Jabber-сервера jabber.ru (xmpp.ru) выявил атаку по расшифровке трафика пользователей (MITM), проводимую на протяжении от 90 дней до 6 месяцев в сетях немецких хостинг-провайдеров Hetzner и Linode, в которых размещён сервер проекта и вспомогательные…
Пусть здесь побудет:
https://systemweakness.com/windows-rdp-event-logs-identification-tracking-and-investigation-part-1-d1f23e26cc05
https://systemweakness.com/windows-rdp-event-logs-part-2-bbbc35898455
#windows #почитать #форенсика
https://systemweakness.com/windows-rdp-event-logs-identification-tracking-and-investigation-part-1-d1f23e26cc05
https://systemweakness.com/windows-rdp-event-logs-part-2-bbbc35898455
#windows #почитать #форенсика
Medium
Windows RDP Event Logs: Part-1
Remote Desktop Protocol (RDP) is a widely used technology that allows users to connect remotely to another computer or server over a…
Про практическое
VPN пользуются многие. Каждый в своих целях. Это, конечно, далеко не только про обход блокировок, а в большей степени - про объединение сетей и про удалённую работу, как следствие этого самого объединения сетей. В общем, технология мега-популярная. При использовании VPN гуру рекомендуют беспарольную аутентификацию. Мы согласны с уважаемыми экспертами. Пароли можно побрутфорсить, часто они слабенькие, да и вообще как-то несолидно. Другое дело, когда у пользователя есть закрытый ключ, а аутентификация беспарольная. Тогда всё прям правильно и по дзену. Да, но нет.
Возьмём, к примеру, OpenVPN - наиболее популярную реализацию технологии VPN. Простота настройки и эксплуатации в сочетании с огромным числом этих самых настроек, надёжность, приемлемая скорость работы, поддержка разных платформ, возможность подключать расширения. В общем, масса достоинств. Где находятся конфиги и закрытые ключи? В подавляющем большинстве случаев либо в пользовательских папках (куда любому пользователю разрешены чтение и запись), либо в папках с привилегированным доступом на запись. Если говорить о Windows, то это C:\Users\<user>\OpenVPN\config или C:\Program Files\OpenVPN\config. Любое приложение, запущенное с привилегиями обычного пользователя, может прочитать оттуда. А следовательно, прочитать закрытый ключ.
В умных книжках и проспектах написано много умных вещей про аппаратные токены с неизвлекаемым ключом (впрочем, с некоторыми криптопровайдерами ключ может покидать даже такой токен, но мы об этом шёпотом и пальцем указывать не будем 😜 ) и прочую двухфакторную аутентификацию. Однако на практике даже крупные компании, включая компании, специализирующиеся на ИБ, просто раздают OpenVPN-конфиги с ключами своим сотрудникам с инструкциями по установке. Либо сисадмины сами ставят сотрудникам OpenVPN на их ПК и кладут ключи в нужные директории. На этом всё. Иногда на таких ПК даже стоит антивирус :)
Как закрытый ключ попадает к злоумышленнику? Например, через фишинг. Фишинг - это реально работающий инструмент. Если в компании тысяча человек народа, у большинства из которых есть удалённый доступ, например, из дома (вспоминаем ковидные времена), то вероятность, что кто-то из сотрудников (например, кто-то не из IT-шников) попадётся и запустит у себя на ПК вредоносный код, достаточно велика. Дальше конфиги с ключами скачиваются с ПК жертвы. Имея закрытый ключ, можно попасть за периметр организации. Profit!
Учитывая массовую удалёнку и, как её следствие, широко практикуемую политику BYOD, схема атаки вполне себе рабочая. Но это, конечно, на практике. В теории всё хорошо :)
Как с этим бороться? Хочется сказать про аппаратные токены. Они действительно здесь полезны. Особенно, когда ключ действительно не извлекается. Но, если организация имеет большую распределённую по стране или даже по миру сеть удалённых сотрудников, массовое внедрение аппаратных токенов - это серьёзная задача для IT-служб, которую они не всегда торопятся решать. Не по причине лени, а потому что это просто на самом деле весьма не просто. Как с организационной, так и с технической стороны. Делается не по щелчку, да и не так уж это и дёшево. Опять же, речь про реальный мир, а не про красивые теории и песни продавцов. Есть промежуточные решения, но о них поговорим позже :)
VPN пользуются многие. Каждый в своих целях. Это, конечно, далеко не только про обход блокировок, а в большей степени - про объединение сетей и про удалённую работу, как следствие этого самого объединения сетей. В общем, технология мега-популярная. При использовании VPN гуру рекомендуют беспарольную аутентификацию. Мы согласны с уважаемыми экспертами. Пароли можно побрутфорсить, часто они слабенькие, да и вообще как-то несолидно. Другое дело, когда у пользователя есть закрытый ключ, а аутентификация беспарольная. Тогда всё прям правильно и по дзену. Да, но нет.
Возьмём, к примеру, OpenVPN - наиболее популярную реализацию технологии VPN. Простота настройки и эксплуатации в сочетании с огромным числом этих самых настроек, надёжность, приемлемая скорость работы, поддержка разных платформ, возможность подключать расширения. В общем, масса достоинств. Где находятся конфиги и закрытые ключи? В подавляющем большинстве случаев либо в пользовательских папках (куда любому пользователю разрешены чтение и запись), либо в папках с привилегированным доступом на запись. Если говорить о Windows, то это C:\Users\<user>\OpenVPN\config или C:\Program Files\OpenVPN\config. Любое приложение, запущенное с привилегиями обычного пользователя, может прочитать оттуда. А следовательно, прочитать закрытый ключ.
В умных книжках и проспектах написано много умных вещей про аппаратные токены с неизвлекаемым ключом (впрочем, с некоторыми криптопровайдерами ключ может покидать даже такой токен, но мы об этом шёпотом и пальцем указывать не будем 😜 ) и прочую двухфакторную аутентификацию. Однако на практике даже крупные компании, включая компании, специализирующиеся на ИБ, просто раздают OpenVPN-конфиги с ключами своим сотрудникам с инструкциями по установке. Либо сисадмины сами ставят сотрудникам OpenVPN на их ПК и кладут ключи в нужные директории. На этом всё. Иногда на таких ПК даже стоит антивирус :)
Как закрытый ключ попадает к злоумышленнику? Например, через фишинг. Фишинг - это реально работающий инструмент. Если в компании тысяча человек народа, у большинства из которых есть удалённый доступ, например, из дома (вспоминаем ковидные времена), то вероятность, что кто-то из сотрудников (например, кто-то не из IT-шников) попадётся и запустит у себя на ПК вредоносный код, достаточно велика. Дальше конфиги с ключами скачиваются с ПК жертвы. Имея закрытый ключ, можно попасть за периметр организации. Profit!
Учитывая массовую удалёнку и, как её следствие, широко практикуемую политику BYOD, схема атаки вполне себе рабочая. Но это, конечно, на практике. В теории всё хорошо :)
Как с этим бороться? Хочется сказать про аппаратные токены. Они действительно здесь полезны. Особенно, когда ключ действительно не извлекается. Но, если организация имеет большую распределённую по стране или даже по миру сеть удалённых сотрудников, массовое внедрение аппаратных токенов - это серьёзная задача для IT-служб, которую они не всегда торопятся решать. Не по причине лени, а потому что это просто на самом деле весьма не просто. Как с организационной, так и с технической стороны. Делается не по щелчку, да и не так уж это и дёшево. Опять же, речь про реальный мир, а не про красивые теории и песни продавцов. Есть промежуточные решения, но о них поговорим позже :)
🤔5🔥2
Появилась реализация на Rust алгоритма RC4OK, о котором писали ранее. Несмотря на то, что работа ещё в стадии preprint, интерес к реализации есть (ещё бы его не было с такими то характеристиками). Это хорошо
Ссылка: https://lib.rs/crates/rc4ok
#rc4ok #криптография
Ссылка: https://lib.rs/crates/rc4ok
#rc4ok #криптография
Lib.rs
RC4OK — Rust utility
Lightweight High-Performance Cryptographically Strong Random Number Generator
👍3
Работа хоть и не совсем свежая, но крайне интересная. Я бы даже сказал - отражающая тренд развития практической ИБ. Если совсем кратко, то в разных головах, включая наши, уже давно бродят мысли по поводу анализа больших графов зависимостей (или графов происхождения - provenance graphs) разного рода событий, например, на рабочих станциях. Например, известный процесс скачал какой-то файл, который был открыт другим процессом, спустя длительное время. Этот другой процесс через сутки вышел в сеть на такой-то ресурс, потом, спустя неделю, этот другой процесс создал соединение, пробежался по директориям, обратился к каким-то файлам на чтение... А потом, спустя какое-то время, появилась ещё какая-то похожая активность. По отдельности эти события малозначительны, да ещё и разделены по времени (low and slow). В общем, EDR может и пропустить (особенно, если атакующим известно, какая EDR у жертвы, им удалось её изучить, выделить шаблоны на поведение и обойти их). Но в совокупности эти события дают однозначную картину. Точнее, давали бы, если бы такие огромные быстрорастущие графы происхождения можно было бы на практике эффективно хранить и обрабатывать. Но всё-таки хранить, обрабатывать и выявлять очень хочется. Как говорится, если нельзя, но очень хочется, то можно. Здесь приходят на помощь разного рода способы "сжатия" (назову это так, чтобы долго не писать) графов с сохранением необходимой информации. Работа как раз про это. В дальнейшем к этим предварительно обработанным данным применяются классические алгоритмы Data Science для выявления аномалий. Да, ИБ, как и много другое, уверенно движется в сторону эффективной работы с большими данными и применению ИИ.
Материал хорошо проработан, много полезных ссылок. Так то работа, если немного подумать, не только про защиту рабочих станций, но и много про что ещё. Просто интересная математика, которую имеет смысл понимать. В общем, очень рекомендую. По ссылке статья, слайды и видео выступления
https://www.ndss-symposium.org/ndss-paper/unicorn-runtime-provenance-based-detector-for-advanced-persistent-threats/
#ии #почитать
Материал хорошо проработан, много полезных ссылок. Так то работа, если немного подумать, не только про защиту рабочих станций, но и много про что ещё. Просто интересная математика, которую имеет смысл понимать. В общем, очень рекомендую. По ссылке статья, слайды и видео выступления
https://www.ndss-symposium.org/ndss-paper/unicorn-runtime-provenance-based-detector-for-advanced-persistent-threats/
#ии #почитать
🔥3
Поздравляем! Кстати, все желающие сотрудники Компании обучаются за счёт Компании
👍13🔥3🎉2
Солидная часть наших разработок делается на C и C++. Потому возникла идея здесь описать знания, которыми, на наш взгляд, должен владеть начинающий разработчик C++.
1. Стек. Как передаются аргументы в функцию. Адрес возврата. Форматы вызовов (cdecl, stdcall, fascall). Локальные переменные (почему они локальные и как это связано со стеком).
2. Массивы и динамические списки. Люди, утверждающие, что знают STL, иногда не понимают разницы между std::list и std::vector.
3. Память. Глобальные переменные, динамическая память, регистровая память, стек (уже было, но это реально важно). Очень хочется понимания страничной адресации памяти.
4. Наследование. Виртуальные функции. Таблица виртуальных методов.
5. Компиляция и линковка. Что это вообще такое.
Хорошие книжки по C++:
1. Стивен Прата, Язык Программирования C++
2. Скотт Майерс, Эффективное использование C++
3. Николаи Джосаттис, Стандартная библиотека C++. Справочное руководство
4. Вандевурд Дэвид, Грегор Дуглас, Шаблоны C++. Справочник разработчика.
5. Дейл Роджерсон, Основы COM (здесь очень хорошо описано наследование и таблицы виртуальных методов, такого нигде не видел больше)
Полезные советы начинающим:
1. Не нужно стесняться при отладке глядеть в ассемблерный код. Если хочется писать действительно серьёзные системные вещи, понимать, как оно работает под капотом, важно. Снимет массу вопросов, сэкономит кучу времени.
2. Экспериментировать лучше с линуксовым стеком
#почитать #программирование
1. Стек. Как передаются аргументы в функцию. Адрес возврата. Форматы вызовов (cdecl, stdcall, fascall). Локальные переменные (почему они локальные и как это связано со стеком).
2. Массивы и динамические списки. Люди, утверждающие, что знают STL, иногда не понимают разницы между std::list и std::vector.
3. Память. Глобальные переменные, динамическая память, регистровая память, стек (уже было, но это реально важно). Очень хочется понимания страничной адресации памяти.
4. Наследование. Виртуальные функции. Таблица виртуальных методов.
5. Компиляция и линковка. Что это вообще такое.
Хорошие книжки по C++:
1. Стивен Прата, Язык Программирования C++
2. Скотт Майерс, Эффективное использование C++
3. Николаи Джосаттис, Стандартная библиотека C++. Справочное руководство
4. Вандевурд Дэвид, Грегор Дуглас, Шаблоны C++. Справочник разработчика.
5. Дейл Роджерсон, Основы COM (здесь очень хорошо описано наследование и таблицы виртуальных методов, такого нигде не видел больше)
Полезные советы начинающим:
1. Не нужно стесняться при отладке глядеть в ассемблерный код. Если хочется писать действительно серьёзные системные вещи, понимать, как оно работает под капотом, важно. Снимет массу вопросов, сэкономит кучу времени.
2. Экспериментировать лучше с линуксовым стеком
#почитать #программирование
👍10
Добавлю к предыдущему посту. Почему важно понимать низкий уровень при программировании на, казалось бы, высокоуровневом языке C++? Например, статическая локальная переменная в функции. При понимании, где она на самом деле располагается, становится совершенно понятно, почему её значения сохраняются от вызова к вызову. И сразу понятно, что там с многопоточностью. Равно как понимание, чем отличается вызов статической функции-члена класса от вызова обычной функции-члена класса, сразу даст ответ на вопросы с доступностью членов класса. Понимание низкоуровневой механики происходящего позволит не заучивать все эти вещи, а понимать, почему именно так. Как и говорил выше, это экономит кучу времени и приносит меньше страданий и себе, и людям. Так что без основ реверсинга никуда :)
А пока ещё один документ, куда имеет смысл обращаться при работе. Это стандарт C++ https://isocpp.org/files/papers/N4860.pdf
#почитать #программирование
А пока ещё один документ, куда имеет смысл обращаться при работе. Это стандарт C++ https://isocpp.org/files/papers/N4860.pdf
#почитать #программирование
👍6
👍5
Все побежали, и я побежал (c) :)
Все стараются подвести итоги года. Мы тоже это сделаем. Однако писать много букв лень, поэтому просто приведём ссылки, картинки и видео.
https://eprint.iacr.org/2021/136
https://eprint.iacr.org/2023/1486/
Сделано много, сделано хорошо. От брингапа материнской платы с прошивкой, device tree и всем сопутствующим до трекера объектов. Мы растём во всех смыслах. Это отлично!
Все стараются подвести итоги года. Мы тоже это сделаем. Однако писать много букв лень, поэтому просто приведём ссылки, картинки и видео.
https://eprint.iacr.org/2021/136
https://eprint.iacr.org/2023/1486/
Сделано много, сделано хорошо. От брингапа материнской платы с прошивкой, device tree и всем сопутствующим до трекера объектов. Мы растём во всех смыслах. Это отлично!
👍7🎉2❤1👀1