Reverse engineering Apple USB-C controller and JTAG access

📌 Переглянув виступ Stacksmashing на DEF CON 32: From getting JTAG on the iPhone 15 to hacking Apple’s USB-C Controller. Доповідь присвячена низькорівневому аналізу апаратної безпеки в сучасних мобільних пристроях.

Ключовий об’єкт дослідження — пропрієтарний USB-C controller від Apple, відповідальний за енергоживлення та автентифікацію аксесуарів. Попри шифровану прошивку і захисні механізми, автору вдалося:
• отримати дамп прошивки з фізичного пристрою,
• частково відновити інструкційний набір (ISA) контролера,
• модифікувати комерційний USB-C адаптер для ін’єкції власного коду,
• обійти захисти на рівні BootROM через fault injection,
• отримати доступ до JTAG-портів системи-на-чипі (A17 SoC).

Підхід показує, як можливо виявити апаратні вектори атаки навіть у комерційних пристроях із високим рівнем інтеграції та захисту. Цінним є також підхід до аналізу закритих мікроконтролерів і обхід обфускації без спеціалізованих інструментів.

📚 YouTube — DEF CON 32: Stacksmashing

І перед сном можна подивитись стрім geohot, еххх велика людина...

Go, HTTP і продуктивність без магії

Почав із продуктивності — порівняв net/http і Fiber (fasthttp) в реальному бенчмарку.
Зробив два HTTP-сервери з одним маршрутом /ping:

1️⃣ net/http
— чистий Go
— ручне управління буфером (var buf [64]byte)
— 0 heap allocations per request
— простий, стабільний

2️⃣ Fiber
— на fasthttp
— максимально low-level
— вищий RPS, менше абстракцій

🔬 Результат бенчмарку (hey -n 100000 -c 100) (на скріншоті)
🧠 Висновки:
• Fiber дійсно швидший (~30% на цьому тесті)
• Але net/http з оптимізаціями — дуже близько
• У складних сценаріях (JSON, TLS, middleware) перевага Fiber згасає
• net/http краще інтегрується з Go-екосистемою та підтримує HTTP/2

Не здаюсь — копаю далі. Чим глибше, тим цікавіше. Можливо, вийде щось краще...

you guys do realize schizophrenic « immutable variable » sounds like?

🧠 Продуктивність, кеш і детермінованість: чому я пишу частину бекенду на C, а не Go

Один із моїх нових проєктів — низькорівнева бібліотека на C. Це буферний менеджер та TCP-сервер (на даний момент), який:
- не використовує динамічні алокації високого рівня,
- має передбачуваний і мінімалістичний API,
- ідеально підходить для інтеграції через cgo з Go.

Але навіщо це взагалі — у 2025 році, коли є Fiber, Fasthttp, Gin, Flask, Django, net/http та інші high-level штуки?

📌 Відповідь: контроль → детермінованість → продуктивність.

Це гарантія, що:

“Однакові вхідні дані → один і той самий вихід з фіксованими часовими характеристиками.”

🧪 У системах обробки запитів це означає: latency predictable.
Не 1 мс сьогодні, а завтра 50 мс через GC. А 20 мкс — стабільно, завжди.

Про кеш та залежності

💬 “Контроль над кешем і залежностями дає справжній контроль над продуктивністю.”

Це не дослівна цитата, але суть підтверджена словами експертів:

⸻⸻⸻⸻⸻⸻⸻⸻⸻⸻⸻⸻

📚 Цитати, що формують філософію

🔸 Ulrich Drepper, автор «What Every Programmer Should Know About Memory»:
“If your program is not written with memory hierarchies in mind, it will suffer.” — «Якщо ваша програма не написана з урахуванням ієрархії пам’яті, вона буде страждати.»

🔸 Herb Sutter (C++ committee):
“Sometimes manual memory management is the only way to achieve your performance goals.” — «Іноді ручне управління пам’яттю — це єдиний спосіб досягти бажаного рівня продуктивності.»

🔸 Andrei Alexandrescu (Modern C++ Design):
“Performance is a first-class concern.” — «Продуктивність — це пріоритет першого класу.» (тобто, продуктивність — не побічний ефект, а центральна мета)

🔸 Brian Kernighan:
“Debugging is twice as hard as writing the code in the first place. So make it simple.” — «Налагодження вдвічі складніше, ніж написання коду. Тож зробіть його простим.»

🔸 Dennis Ritchie:
“UNIX is simple. It just takes a genius to understand its simplicity.”
«UNIX — це просто. Просто потрібен геній, щоб зрозуміти цю простоту.»

Чому Go — не завжди рішення

Go — чудовий для бізнес-логіки. Але:
- Він не дає контролю над кешем.
- GC може “вистрілити в ногу” під навантаженням.
- Важко досягти latency predictability.

Я не пишу вебсервер повністю на C. Я ізолюю критичну частину I/O та буферизації в модулі, написаному мовою, яку розуміє CPU. Go залишається для обробки, логіки, розширення.

⸻⸻⸻⸻⸻⸻⸻⸻⸻⸻⸻⸻

Висновок

Мій підхід — це філософія Unix, переглянута під кутом 2025-го:
- Просте ядро на C,
- Чітка детермінована поведінка,
- Без GC, без preemption delays,
- І Go як приємний зовнішній шар.

Контроль памʼяті — контроль продуктивності.
— Підписано: Ritchie, Drepper, Alexandrescu, Gregg і всі, хто пише не лише код, а системи.

"Це вам не кнопочки красити на фронтенді, це курва системне програмування..." - Ти не жив, поки не написав власноруч парсер інструкцій з масками і зсувами.

🧙Wizard Level 6: “Bitwise operations are the dark magic of programming.”

Запустив, продовжую розбиратись з Core, ALU і з самим ARM64
https://www.twitch.tv/t3nyd

https://www.twitch.tv/t3nyd

https://www.twitch.tv/t3nyd

На першій частині стріма, я розширив декодування інструкцій та набір opcode'ів. Включено повний список базових інструкцій ARM64. Додано допоміжні функції декодування.

Єдине, що не реалізовано це гілки та операції з пам'яттю, вони залишаються як OPCODE_UNKNOWN для майбутньої реалізації.

https://github.com/DenysSkobalo/silico/commit/735e18c706178ba4bb72e015f40f924b3f8eb76c

Продовжую далі😌

Рефакторинг блоку декокудвання та розробка execute & ALU

https://www.twitch.tv/t3nyd

https://www.twitch.tv/t3nyd

https://www.twitch.tv/t3nyd

За три години стріма, розширив DecodeInstr, ввів InstrClass для класифікації інструкцій (арифметика, логічні, гілки, памʼять, системні). Переписав decode() та імплементував execute() для підтримки цієї класифікації. Виніс арифметичні та логічні інструкції у execute_alu(). Додано інструкції: ADD, SUB, ADDI, SUBI, MUL, MOVZ, MOVN, MOVK, AND, ORR, EOR, ANDI, ORRI, EORI.

Додано повідомлення про невідому інструкцію з точним PC, щоб легше відловлювати баги.

У main.c тепер є зручний приклад з повним тестовим набором інструкцій, які працюють: обчислення, логіка, завантаження констант, зсуви.

Commit 1: https://github.com/DenysSkobalo/silico/commit/99468597a66ed3c3012fd468f3e5d6af19ef78b7

Commit 2: https://github.com/DenysSkobalo/silico/commit/dd4d1cc077181f082c3554a6725b3b5758231fa1

Літо всралося, відпочинок закінчився, час знову грузнути в грьобаному універі й розгрібати свої проєкти. Останній курс, тому треба добивати все, що почав.

Кілька місяців тому я запускав експеримент — писати свою мінімальну ОС. Потім забив, але репо на GitHub залишив. І ось тиждень тому дістав його з архіва й нарешті почав рухати далі.

Що вже зроблено:
- прибрав старий 16-бітний bootloader на ASM;
- завів Multiboot через GRUB та ISO;
- організував лінкування ядра через LD і NASM;
- написав мінімальне ядро на C з виводом на VGA;
- навів лад у Makefile: тепер є build, iso, qemu, docker;
- додав build.sh для Docker-збірки.

Проєкт оживає, і навіть у такому мінімальному вигляді він уже приносить кайф. Далі буде цікавіше.

Репо: https://github.com/DenysSkobalo/detux

На днях, мені прийшов мікроконтролер на базі ESP8266EX. В ній присутній WiFi (802.11 b/g/n) з TCP/IP стеком, SRAM (64KB instructions + 96KB data), SPI Flash 4 MB, GPIO, SPI, I^2C, UART, PWM, ADC.

І перше, що я вирішив на ньому зроюити, це підняти легкий вебсервер. Написав все на С++ та скомпілював для Arduino через заголовковий файл. А далі все постандарту, збірка проєкта та прошивка через Makefile. Одне з мінусів те, що я не маю доступу до роутера тому підняв через телефон хотспот та підключився до нього і на ПК на якому потрібно відкрити піднятий сервер, він повинен теж бути підключеним до WiFi (у моєму випадку хотспот), що підключений сам сервер. Далі відкриваєм IP-адрес котрий пише на OLED, що підключений до чіпсета, вбиваємо в браузер, відкривається сайт, пишемо повідомлення та отримуємо повідомлення на екрані, що було написано на сайті.

Але, щоб вирішити проблему щодо відкриття сайту з любого WiFi, то я придумав рішення. Можна прокинути тунель через Ngrok або Cloudfare Tunnel, але я вибрав Ngrok, прокинув тунель, отримав згенероване рандомне URL-посилання і все працює так само.

Ось такий невеликий, але доволі цікавий проєкт. Нижче залишаю посилання на репо.

https://github.com/DenysSkobalo/ESP8266-webAP

Продовжую гратись з ESP8266EX 🙂
Після того як підняв базовий вебсервер і прокидав тунель через Ngrok, я вирішив трохи ускладнити завдання.

🔹 Тепер мікроконтролер працює у режимі Access Point (AP) -- тобто він сам створює WiFi-мережу. Не потрібно ніякого роутера чи хотспоту з телефону: ESP8266 піднімає свій SSID, показує його та IP прямо на OLED-екрані, і до цієї мережі можна підключитися будь-яким пристроєм. Відкриваєш браузер → заходиш за IP → бачиш сайт із ESP.

По суті, ESP8266 перетворився на мініатюрний роутер із власним вебсервером.

Репо той самий, але тепер у ньому інша назва:
https://github.com/DenysSkobalo/ESP8266-webAP