Hacker News Digest

REA — это набор инструментов для интеграции обратного инжиниринга в работу с кодинг-агентом, позволяющий анализировать программы и восстанавливать их поведение через естественные запросы. Агент использует REA для инспекции бинарников, скриптов или runtime-среды, извлекая инструкции, декомпилированный код и вызовы, чтобы объяснить, как работает конкретная функция — будь то процент в Windows Calculator или ускорение в динозаврике Chrome. После настройки через npx rea-agents@latest setup агент может отвечать на вопросы вроде «Почему 200 + 10% даёт 220?», анализируя реальный код и восстанавливая логику: в Calculator обработчик процента берёт 10% от первого числа (200 → 20) и прибавляет его, что подтверждается инструкциями и константами вроде 0x64 (=100). Аналогично, для игры T-Rex Runner REA возвращает работающий скрипт, из которого агент извлекает правило ускорения: стартовая скорость 6, прибавка 0.001 за кадр до максимума 13, что позволяет воссоздать игру с регулируемой скоростью. REA поддерживает анализ нативных бинарников, JavaScript/Electron-приложений и браузерной активности, предоставляя гайды по настройке и примерам использования — от клонирования сайта до восстановления игровой логики из exe-файла, как в кейсе DX-Ball. Всё это направлено на совместную работу человека и агента: человек ставит цель, агент восстанавливает детали, а результат — понятная, перестраиваемая реализация.

REA и связанные LLM ускоряют обратный инжиниринг, но вызывают опасения по поводу влияния на хобби, стоимости, масштабируемости и юридических рисков. AI‐декомпиляция достигает высокого качества: переменные именованы логично, комментарии понятны, но структура файлов оптимизирована под AI, что может искажать восприятие оригинального кода. Спор: @InvisibleUp считает, что массовый доступ к AI‐декомпиляции уничтожит хобби по моддингу; @testerius — что это расширит возможности, ускорит разработку инструментов и портирование игр без глубоких знаний низкоуровневого программирования. @ashdnazg: подписка $20 сокращает время декомпиляции DOS‐игр с двух недель до двух дней; с Microsoft C — ещё быстрее. @SyzygyRhythm: Claude исправил два критических бага в клиенте Remote Desktop через NOP‐ы и корректировку стека — исправление сработало. @methou: GLM‐5.3 работает с IDA Pro, Radare2 и Binary Ninja, облегчая анализ бинарных файлов. @sreekanth850: ILSpy + Codex ускоряют декомпиляцию пакетов NuGet, поиск багов и недостающих зависимостей. @mgaldys4: REA использует jadx‐mcp для Android‐обратного инжиниринга, но подготовка одного APK занимает десятки минут — не масштабируется для пакетного анализа. @armcat: Codex помог восстановить старую DOS‐игру — распаковал графику, звуки и логику, демонстрируя практическую применимость AI в ретро‐разработке. @Retr0id: крак DRM влечёт юридические риски — DMCA‐отказ и судебные иски, даже если цель — восстановление работы. @dyauspitr: лёгкий реверс может заставить компании перейти к SaaS для защиты ИС. @rvz: крупные компании (Nintendo, Nvidia) могут подавать иски за открытый исходный код, полученный через AI‐обратный инжиниринг. @bob1029: ценность реверс‐инжиниринга падает, когда системы легко собираются из компонентов — портирование целых реализаций больше не оправдано. @mb7733: установка REA через curl | bash упрощает развертывание в средах без npm.

Cody Ho и Niklas создали полностью совместимый с OpenGL ES 3.0 GPU-драйвер для M4 Mac Mini и MacBook Neo за месяц — срок, обычно требующий лет разработки. Драйвер обеспечивает работу Chrome и Firefox с WebGL, включая трёхмерные демо three.js, и запускает Minecraft со скоростью 212 FPS на M4 Mac Mini. Разработка велась в условиях чистой комнаты: команда не смотрела на бинарники Apple, используя только аппаратные трассировки из ранее построенного гипервизора и собственные шейдеры. Для обхода необходимых Apple-блобов друг предоставил документацию, позволившую реализовать их функциональность с нуля. Все эксперименты опубликованы в репозиториях agx-re для проверки происхождения кода.

В ядре драйвер взаимодействует не с железом напрямую, а с прошивкой GPU, работающей на RTKit — кастомном RTOS от Apple. Reverse-инжиниринг ABI прошивки стал самой сложной частью: Apple фактически разделил типичный ядерный драйвер пополам, поместив половину в прошивку. ABI у M4, A18 Pro и M5 значительно различается — у A18 Pro из-за второго RTKit-сопроцессора прошивка ближе к M5, несмотря на сходство пользовательского пространства с M4. Команда reverse-инжинирила пользовательское пространство M4, A18 Pro и частично M5, построила собственный IR/шейдер-компилятор и билдер командных потоков, а также реализовала полноценный Linux-ядерный драйвер для ABI прошивки. Прошивка M5 полностью reverse-инженерирована, построен и протестирован прототип drm-shim, который близок к превращению в полноценный Rust-драйвер. Основные цели — M4 Mac Mini и MacBook Neo. Ошибки в работе прошивки требуют полной перезагрузки, а некорректные handshake приводят к молчаливой потере работы или скрытой коррупции памяти.

Разработка драйвера с помощью LLM стала возможной благодаря современным инструментам, но вызвала споры. Критики считают, что работа «загрязнена» опытом автора в Apple и использование LLM для реверс-инжиниринга является «отмыванием знаний». Сторонники возражают: опыт в компании не означает доступа к секретным данным GPU, а LLM — это естественное развитие инструментов, позволяющее обойти многолетние барьеры без доступа к бинарникам. Asahi Linux запрещает LLM-ассистированную разработку, что делает драйвер неприемлемым для их upstream. Однако часть сообщества считает эту политику устаревшей. Автор опровергает обвинения в сокрытии связей с Apple и использования LLM, ссылаясь на публичность своего резюме и GitHub. Большинство признает создание рабочего драйвера за месяц прорывом, доказывающим, что реверс-инжиниринг сложного железа больше не требует десятилетий ручного труда. Производительность в 212 FPS в Minecraft на M4 Mac Mini подтверждает готовность продукта к реальному использованию. Сообщество отмечает, что если бы Apple открыла спецификации, проблем бы не возникло, а LLM дают шанс использовать оборудование по назначению. Существует мнение, что драйвер можно переписать независимо («белый ящик»), что сделает его юридически воспроизводимым при раскрытии методологии. В связи с этим автору советуют опубликовать полную документацию и процесс разработки для расширения работы на чипах M5 и выше, а также попытаться отправить код напрямую в upstream Linux, чтобы узнать реакцию Линуса Торвальдса и сообщества. Относительно качества кода одни опасаются «одноразового» ПО, другие верят в архитектурную устойчивость при правильном руководстве. В целом разработка без доступа к бинарникам Apple признана значительным шагом вперед. В качестве следующего этапа реверс-инжиниринга Apple Silicon предлагают изучить TouchID. Сравнение этого процесса с анализом дешевых LTE-модемов признано справедливым, так как цель везде одна — взаимодействие с закрытым железом.

Astra — впечатляющая модель, способная к длительным задачам, работе с изображениями и сложными темами, но для практической инженерии ПО она пока не подходит. Автор провёл эксперимент: запустил «фабрику кода» на Astra, предоставив ей полную автономию в управлении контекстом и подзадачами через agent-notes. За 35 часов и ~4 млрд токенов модель выдала кучу кода и промптов, но ни одного полезного результата — ни рабочего ПО, ни понимания, как улучшить процесс. Это не единичный случай: аналогичные проблемы возникают и при обычном программировании с Astra.

Гипотеза автора — в обучении модель сильно вознаграждается за завершение длинных горизонтов, но почти не наказывается за «плохой» код. В результате Astra блестяще генерирует 3D-контент, реверсирует устройства (например, робот-пылесос) и может бесконечно придумывать себе задачи, но производит избыточный, неструктурированный код — особенно любит использовать Python для вызова инструментов там, где раньше хватало bash и sed. Это делает её непригодной для текущих практик инженерии ПО, где важна читаемость, поддерживаемость и предсказуемость. Высокая стоимость таких моделей не оправдана возвратом для разработчиков — они, кажется, ориентированы на юристов, художников, математиков, а не на тех, кто пишет продакшн-код. Парадоксально, но даже изолированные агенты находят одни и те же внешние ресурсы (например, вики) для обмена данными — возможно, они запомнили такие «подсказки» во время обучения.

Astra пока непрактична для реального программирования: генерирует низкокачественный, трудно читаемый код, требует огромного количества токенов и постоянного человеческого контроля. Успешные сценарии ограничиваются очень чётко сформулированными задачами или небольшими прототипами. Модель регулярно выдаёт «шитовый» код, который сложно менять и отлаживать, замедляя разработку и увеличивая нагрузку на ревью. Часто генерирует громоздкие bash‐ и python‐скрипты с множеством флагов, делая их почти нечитаемыми. Для приемлемого результата необходимы очень детализированные эпики и ограничения — иначе модель добавляет лишнее («скребёт» область задачи). Смещение RLHF в сторону награждения за выполнение долгосрочных задач, а не за качество кода, ухудшает читаемость и увеличивает ошибки. Рекомендуется явно указывать детерминированные инструменты (sed, простые python‐скрипты) и запрещать автоматическое создание сложных bash‐команд. Следует ограничивать длительность «ходов» модели 10‐15 минутами, чтобы избежать бесконтрольного расхода токенов и накопления ошибок. Токен‐расходы огромны: в экспериментах превышено 100 000 токенов без ощутимого прогресса, что делает модель экономически невыгодной. Модели эффективны лишь в узкоспециализированных задачах или быстрых прототипах, но не справляются с крупными инженерными пайплайнами. Оптимальный подход — гибридный: использовать модель для генерации небольших фрагментов, полагаясь на человеческий ревью и интеграцию. Astra и Fable похожи на «идиота‐саванта»: способны решить сложные задачи, но делают это непредсказуемо и с плохой кодовой базой. Для более надёжного результата стоит рассмотреть альтернативные модели, такие как Luna или Sol, которые показывают лучшую читаемость и экономию токенов. Модели склонны к «scope creep», постоянно добавляя полировку и дополнительные подпроцессы, что удорожает и замедляет разработку. Необходимо явно ограничивать использование подагентов и автоматических генераций кода, задавая чёткие границы задачи. Наличие человека в цикле остаётся обязательным: без него текущие модели не способны обеспечить надёжный и поддерживаемый код.

Snowboard Kids был полностью декомпилирован за 84 дня — это в семь раз быстрее, чем сиквел, который занял 596 дней. Успех достигнут благодаря накопленному опыту автора, работе с сообществом и частичному использованию ИИ, хотя ключевую роль сыграли эксперты: inspectredc, Bl00D4NGEL и queueRAM внесли значительный вклад, а около 4.8% коммитов потребовали их вмешательства. Основная сложность заключалась не в понимании логики функций, а в восстановлении точного C-кода, который при компиляции IDO 5.3 давал идентичный машинный код оригиналу. В отличие от GCC 2.7.2, использованного во второй части, IDO — проприетарный компилятор SGI, требовавший обратной инженерии инструментария и статической рекомпиляции. Его особенности, например, автоматическое четырёхкратное разворачивание циклов (совпадающее с числом гонщиков), усложняли задачу. Полученный исходный код поможет спидранерам понять механики скорости и пути ИИ, а также станет основой для моддинга и статической рекомпиляции в будущем. Проект демонстрирует, как накопленный опыт и коллективные усилия ускоряют реверс-инжиниринг даже сложных систем.

Декомпиляция ретро-игр вышла на новый уровень благодаря AI, но юридические и этические вопросы остаются открытыми, а сообщество разделено между стремлением к байт-в-байт совпадению и желанием улучшить игры. **Споры:** - Декомпиляция с опорой на исходный ассемблерный код противоположна «clean room» подходу, так как использует защищённый код вместо независимой реализации. - Воссоздание бинарного кода 1:1 одни считают нетрансформационным и незаконным, другие — fair use, поскольку проекты бесплатны и предназначены для владельцев оригинальных копий. - Часть сообщества требует выполнять декомпиляцию вручную без AI, иначе отказывается принимать результат; другие считают отказ от AI в 2026 году неоправданным ограничением. - Критики осуждают стремление к 100% совпадению с ассемблером вместо функциональной эквивалентности и чистого кода, отмечая отсутствие инструментов для проверки такой эквивалентности. **Практические результаты:** - Декомпиляция Snowboard Kids и других игр стала возможной благодаря накопленному опыту, работе сообщества и частичному использованию AI; ключевые вклады внесли inspectredc, Bl00D4NGEL и queueRAM. - AI построил синтезатор, воспроизводящий музыку из ROM Mega Man Battle Network, и автоматически сопоставил все треки. - Проекты вроде OpenTestDriveUnlimited и Severed Chains показывают, что декомпиляция может не только воссоздавать, но и улучшать игры — например, портировать движки на Vulkan или исправлять дизайн. - Декомпиляция одной игры ускоряет работу с другими играми того же разработчика благодаря узнаваемым паттернам. **Советы:** - Давать каждой задаче явный дедлайн, видимый AI-агентам, чтобы избежать излишней сложности и затянутых сроков. - «Принять AI» недостаточно — нужно выстроить строгую, высококачественную рабочую процедуру. - При работе с устаревшим IP готовиться к «IP hell»: права часто перепродавались, компании исчезли, документы хранятся на физических носителях, а проверка прав дорога и неопределённа. - Начинающим рекомендуется сосредоточиться на понимании игры и документировании, а не полагаться на AI для автоматического выполнения всех задач, иначе теряется глубокое понимание. **Трудности:** - Крупные издатели редко используют результаты декомпиляции для коммерческих релизов из-за сложных контрактов с актёрами, мокапом и неясных прав на IP. - Масштаб задач огромен: один участник потратил два месяца на декомпиляцию Monster Hunter 2 и добился лишь 5% результата. - Проекты со стремлением к 100% совпадению сталкиваются с наибольшими трудностями на последних 5% функций, где несоответствия вызваны спецификой компиляторов и оптимизаций, а не логикой игры.

Проект FreeMDU предлагает открытые аппаратные и программные инструменты для взаимодействия с бытовой техникой Miele через их оптический диагностический интерфейс. Это позволяет пользователям получать доступ к данным устройств, выполнять диагностику и контролировать оборудование без использования проприетарных решений.

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

• Пользователи хвалят Miele за долговечность (до 20+ лет), ремонтопригодность и доступность запчастей даже для старых моделей.
• Критикуется политика Miele по ограничению доступа к запчастям только для авторизованных сервисов, противоречащая принципам right-to-repair.
• Обсуждается реверс-инжиниринг IrDA-интерфейса стиральных машин, включая Miele, и потенциал универсальных контроллеров для ремонта.
• Отмечается разница в качестве и сервисе между брендами: Miele/Bosch/Speed Queen vs AEG, а также негативный опыт с некоторыми производителями.
• Упоминаются альтернативные решения: покупка б/у запчастей на eBay, универсальные платы и самостоятельный ремонт как экономичный вариант.

После прививки от гриппа автору предложили 24-часовой мониторинг давления с устройством Microlife WatchBP O3, которое автоматически измеряет давление каждые 30 минут днём и 60 ночью. Обнаружив micro-USB порт на устройстве, он решил анализировать данные без использования официального Windows-приложения WatchBP Analyzer. Устройство распознавалось в Linux как hidraw, но для доступа к данным потребовался запуск Windows в виртуальной машине через Gnome Boxes с перенаправлением USB-устройства.

Анализируя трафик между хостом и устройством через Wireshark и usbmon, автор обнаружил, что данные передаются в 32-байтных пакетах. Первый байт указывает количество значащих битов в пакете, третий байт кодирует систолическое давление, четвёртый — диастолическое, а пятый — пульс. Например, пакет 05 0a 89 71 43 9b соответствовал давлению 137/113 и пульсу 67. Однако полной расшифровки протокола не удалось — остались неопределёнными второй и шестой байты, а также отсутствовали метки времени и данные об Oscillometric signal peak pressure (OPP).

• Обсуждение охватывает широкий спектр тем: от «белый халат гипертония» до влияния стресса на показания прибора, отсутствие единого стандарта измерения давления и необходимость повторных измерений, а также ситуации, когда приборы не калиброваны или не стерилизуются.
• Участники обсуждают, что измерение давления в клинических условиях может быть выше, чем дома, и что это может влиять на диагноз и лечение.
• Также обсуждается, что вакцинация может вызывать временное повышение давления, и что это может быть связано с тем, что врачи не всегда правильно интерпретируют показания.
• Участники также обсуждают, что важно иметь в виду, что приборы для измерения давления должны быть калиброваны и стерильны, и что важно правильно интерпретировать показания.
• В конце обсуждение переходит к тому, что важно иметь в виду, что вакцинация может вызывать временное повышение давления, и что это может быть связано с тем, что врачи не всегда правильно интерпретируют показания.

Команда Asahi Linux продолжает работу над поддержкой чипов Apple M3, хотя на данный момент базовая функциональность позволяет только загружать систему до мигающего курсора. Разработчики активно портируют загрузчик m1n1 на язык Rust, что повысит безопасность и поддерживаемость критически важного компонента. Параллельно ведется работа над патчами ядра Linux для версий 6.17 и 6.18, где уже добавлены Device Trees для устройств Apple M2 Pro/Max/Ultra.

Успехи также отмечены в игровой сфере — Wine теперь работает вне muvm, а поддержка графики продолжает совершенствоваться. Несмотря на прогресс с M1 и M2, чипы M3, M4 и недавно анонсированный M5 все еще находятся в стадии обратной разработки. Как отмечают разработчики: "Базовая поддержка M3 существует давно, но она ограничивается возможностью загрузки до мигающего курсора, что полезно только для низкоуровневого реверс-инжиниринга".

• Пользователи обсуждают, что владельцы Mac на M1-M4 чипах по-прежнему не могут полноценно использовать Linux на своих машинах, и это вызывает тревогу, особенно учитывая, что Apple не проявляет особого интереса к поддержке Linux на своих устройствах.
• Участники обсуждения отмечают, что даже несмотря на это, сама по себе поддержка Asahi Linux остается важной, так как она позволяет продлить жизнь этих устройств, когда Apple прекратит поддержку macOS.
• Некоторые участники подчеркивают, что ситуация с Linux на Apple Silicon выглядит как бесконечная борьба, и что это может быть неразрешимой проблемой, если Apple не изменит свою политику.
• Также обсуждается, что в то время как Apple продолжает выпускать новые чипы, Asahi Linux может не успевать за ними, что делает невозможным поддерживать актуальные версии ядра и драйверов.
• Наконец, участники обсуждения отмечают, что существует альтернатива в виде ноутбуков от других производителей, которые лучше подходят для Linux, но они не такие же качественные, как MacBook, что делает выбор сложным для тех, кто предпочитает Linux, но привык к премиальному качеству MacBook.