Введение

Несколько месяцев назад в поисках идей по ускорению кода я изучал множество научных статей по computer science. Не буду притворяться, что хорошо их понимал, но меня не пугает непонятное, и я готов признать своё невежество¹. Я обнаружил статью, написанную пятнадцать лет назад², в которой было множество новых для меня концепций. Мне никак не удавалось в них разобраться.

Что же делать дальше? Можно искать другие статьи, чтобы они заполнили мои пробелы. Это рискованное предприятие, потому что они могут запутать ещё больше, но избежать этого нельзя. Я нашёл статью с нужной структурой данных, в которой упоминался исходный код с веб-сайта. Код был написан на C++, а я работаю на Rust, но решил, что всё равно стоит на него взглянуть. Однако зайдя на сайт, я не обнаружил там ресурс, поэтому я написал владельцу веб-сайта, который оказался преподавателем computer science.

Этот преподаватель (Гонсало Наварро) очень тепло меня принял и сразу же ответил мне^{3 4}. И только в процессе общения с ним я осознал, что видел его фамилию на множестве статей в этой области. Оказалось, я познакомился с одним из специалистов мирового уровня в области компактных структур данных (succinct data structure). Невежество может завести очень далеко.

Что же такое компактные структуры данных? Если вы изучали в последние десятилетия computer science, то могли сталкиваться с ними, но мне не доводилось встречаться с ними в процессе работы программистом, а если и доводилось, то я сразу же о них забыл. Но я считаю, что эти структуры данных обладают потрясающими свойствами.

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

Я решил, что стоит немного о них рассказать.

Прошло два года...

… с тех пор, как я разработал и выпустил Git-Sim — бесплатный опенсорсный инструмент для визуализации команд Git непосредственно в репозиториях пользователя.

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

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

В рамках моей работы над будущим постом об утерянном и наконец-то найденном фрагменте истории Mac я экспериментировал со старыми жёсткими дисками SCSI под брендом Apple, выпускавшимися Quantum и Conner в 1990-х. В этой статье я расскажу о хорошо известном в мире винтажных компьютеров факте, который, думаю, будет интересен читателям.

Дело в том, что многие из этих жёстких дисков уже отказываются работать. Это очень распространённая проблема у старых моделей Quantum ProDrive, например, LPS и ELS. Шпиндель раскручивается, но мы не слышим ожидаемого паттерна щёлкающих звуков запуска, а спустя несколько секунд он снова останавливается.

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

График поездов метро Нью-Йорка можно посмотреть на mta-trmnl.pages.dev. Исходный код моего проекта выложен на GitHub: фронтенд, бэкенд.

▍ Я безголовый

Просыпаясь утром, я каждый раз смотрю погоду и график метро, а затем иду в душ и сразу забываю эту информацию. Выхожу из душа, проверяю её снова, но пока одеваюсь, снова всё забываю. Ищу телефон, разблокирую его, обновляю виджет погоды и виджет метро так часто, что телефон отключает Face ID и заставляет меня ввести пароль. Ко времени, когда я надеваю обувь, я уже опаздываю, а когда спускаюсь по лестнице, до следующего поезда остаётся десять минут. Это очень раздражает.

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

В 2021 году я только начинал свой путь в наступательной безопасности. Я уже взломал довольно много компаний и получал стабильный доход охотой за баг-баунти — практикой этичного хакинга, при которой исследователи безопасности находят уязвимости и сообщают о них, получая за это вознаграждение. Однако я ещё не достиг уровня, позволившего бы мне быстро обнаруживать критические уязвимости цели. Этот уровень умений казался мне недостижимым. Но всё поменялось, когда я познакомился с человеком, ставшим ключевой фигурой в моей карьере баг-баунти: Snorlhax.

Поначалу я видел в нём конкурента. Он был намного выше меня во французской таблице лидеров HackerOne, что стимулировало меня расти над собой. Мы начали общаться в Discord, и спустя несколько недель я рассказал ему о многообещающей программе баг-баунти. Вскоре после этого он обнаружил у этой цели критическую уязвимость, оценённую в 10000 долларов — сумму вдвое больше, чем максимальная полученная мной от этой же цели. Мотивировавшись этим, я вернулся к этой же цели и за ту же неделю нашёл собственную критическую уязвимость за 10000 долларов в другом классе багов.

Вместо того, чтобы продолжать состязаться, мы решили сотрудничать. Теперь нашей задачей стало выявление у этой цели всех возможных классов багов: IDOR, SQL-инъекций, XSS, багов OAuth, Dependency Confusion, SSRF, RCE и так далее. Все их мы нашли, сообщили компании и написали отчёты. Это сотрудничество длилось несколько лет, и даже сегодня мы время от времени снова возвращаемся к этой цели.

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

В посте я расскажу, как мы со Snorlhax наконец-то этого добились.

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

«Сколько времени вам на это потребуется?»

Привычность этого бытового прибора внушила мне ложное чувство безопасности

Недавно я столкнулся с приложением, которое:

1. Блокирует прикрепление к нему отладчиков.
2. Выполняет преждевременный выход при попытках инъецирования кода.
3. Приводит к вылету телефона целиком, если запустить её со включённым джейлбрейком (!).

По последнему пункту: кто вообще так делает???

Всё, что мы делаем (например, выполняем моддинг TikTok, чтобы он показывал только видео с котиками, или устраняем торможения в чужих приложениях), требует возможности исследования работы приложения.

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

Похоже, это приложение стало на удивление интересной комбинацией всего перечисленного.

Намного более сложной, чем можно было бы ожидать от обычного старого виджет-приложения.

В ноябре 2023 года, когда OpenAI добавила в ChatGPT возможность генерации изображений DALL-E 3 через веб-интерфейс ChatGPT, на короткое время возник мем: пользователи отправляли LLM базовое изображение и несколько раз просили «сделать его более X», где X могло быть чем угодно.

Тренд быстро сошёл на нет, потому что все эти изображения были очень похожими и скучными; к тому же они необъяснимым образом все сводились к чему-то космическому, вне зависимости от исходного изображения и промта. Тем не менее, этот тренд достаточно любопытен с научной точки зрения тем, что столь бессмысленный и нечёткий промт каким-то образом влияет на конечное изображение, и что это изменение очевидно для пользователя.

А что будет, если я попробую похожий способ с кодом? Сгенерированный LLM код вряд ли будет мусорным (хоть это и возможно), поскольку он следует строгим правилам, и в отличие, например, от изображений, его качество можно измерить объективнее.

Если код в самом деле можно улучшить, просто при помощи интерактивного промтинга, попросив LLM «написать код получше» (хоть это и очень глупо), то это приведёт к огромному росту продуктивности. А если это так, то что произойдёт, если таких итераций с кодом будет слишком много? Каким станет эквивалент «космического» кода? Есть только один способ это выяснить!

Недавно наша компания достигла отметки в 1 000 000 созданных серверов. Это хороший повод рассказать о том, как клиенты RUVDS используют VPS и почему эта услуга настолько популярна. В этой статье мы рассмотрим основные сценарии использования виртуальных серверов из нашей практики и покажем, как много задач можно решить с помощью VPS.

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

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

Моя работа в течение последнего года заключалась в анализе погрешности различных математических функций, накопления этой погрешности и способов её уменьшения при помощи различных программных паттернов. Одной из исследованных мной тем были базовые математические функции, используемые в функциях активации нейронных сетей, а также способы их аппроксимации для повышения производительности. В процессе работы нам пришлось столкнуться с противодействием со стороны людей, активно стремящихся к корректной реализации математических функций и к соответствию их стандартам, в частности, к соблюдению обеспечения корректности одной наименее значимой единицы измерения (unit in last place, ULP) для элементарных функций.

Я был заинтересован в дальнейшей работе по аппроксимации этих функций, поэтому приступил к исследованию того, каким образом они гарантируют корректность, и если они корректны только на 1 ULP, то где располагаются ошибки в области определения функции.

В процессе изучения я обнаружил, что ни одна из популярных математических библиотек, используемых во множестве сфер вычислений, на самом деле не выполняет корректное округление в соответствии с требованиями любой версии IEEE 754 после первой редакции 1985 года.

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

Само по себе это необязательно плохо, несмотря на то, что одна из аксиом информационной безопасности запрещает делать именно это. Написание криптографического кода (но не его развёртывание или публикация!) — важный первый шаг в обучении алгоритмам.

Я заметил такую тенденцию (как в примере с Session): разработчики некорректно утверждают, что не реализуют собственную криптографию, ведь они используют низкоуровневую криптографическую библиотеку.

Эта ошибка свойственна не только сомнительным приложениям, форкающим мессенджеры со сквозным шифрованием, чтобы вырезать прямую секретность (forward secrecy).

Недавно я прочитал о масштабной утечке геолокационных данных из Gravy Analytics, благодаря которой стало известно, что более двух тысяч приложений из AppStore и Google Play тайно собирали геолокационные данные пользователей без их согласия. И часто об этом не знали даже разработчики.

Я изучил список (ссылка) и обнаружил как минимум три приложения, установленные на моём iPhone. Проверьте сами!

У меня возникла идея: попробовать отследить себя снаружи, то есть купить свои геолокационные данные, утёкшие через какое-нибудь приложение.

Введение

20 ноября 2024 года я и Шубхам Шах обнаружили уязвимость безопасности в сервисе автомобиля Subaru, подключённого к STARLINK. Он предоставил нам неограниченный целевой доступ ко всем автомобилям и аккаунтам пользователей в США, Канаде и Японии.

Благодаря доступу, полученному через эту уязвимость, нападающий, зная лишь фамилию и почтовый индекс жертвы, почтовый адрес, номер телефона или номерной знак, мог выполнять следующие действия:

• Дистанционно запускать и глушить двигатель, выполнять блокировку и разблокировку, получать текущее местоположение любого автомобиля.
• Получать полную историю местонахождения любого автомобиля за последний год с точностью до пяти метров, обновляемую при запуске двигателя.
• Запрашивать и получать личную информацию (personally identifiable information, PII) любого покупателя, в том числе контакты для экстренной связи, авторизованных пользователей, физический адрес, платёжную информацию (например, последние четыре цифры кредитной карты) и PIN автомобиля.
• Получать доступ к различным пользовательским данным, в том числе к истории звонков, сведениям о предыдущих владельцах, показаниям одометра, истории продаж и многому другому.

После отправки нами отчёта об уязвимости, подверженная уязвимости система была пропатчена в течение 24 часов и никогда не использовалась злонамеренно.

▍ Введение

Наш первый «компилятор WebAssembly в твите» имел длину 269 байт; с тех пор мы смогли снизить её всего до 192 байтов.

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

let c=(b,l)=>WebAssembly.instantiate(new Int8Array(
[,97,115,109,1,,,,1,5,1,96,,1,127,3,2,1,,7,4,1,,,,10,
l=(b=b.split` `.flatMap(t=>t>-1?[65,t]:107+'-*/'.indexOf(t)))
.length+4,1,l-2,,...b,11]))

А вот пример его использования:

(await c('11 11 1 - + 4 * 2 /')).instance.exports['']()

Но это не просто хитрый трюк — если вы начнёте разбираться, как работает этот код, то на удивление много узнаете о WebAssembly! В этом посте мы объясним, как это всё работает, пошагово деобфусцируя код.

Fizzbuzz — это простой алгоритм, который когда-то был популярен в контексте технических собеседований.

Я знал, что это такое, но до прошлой недели меня ни разу не просили написать его.

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

Базовую реализацию fizzbuzz можно написать однострочником на Typescript:

const fizzbuzz = (n: number)=>`${n%3 ? '' : 'Fizz'}${n%5 ? '' : 'Buzz'}`;

Во время собеседования меня попросили написать fizzbuzz на любом близком мне языке; собеседующий даже сказал, что можно использовать эзотерические языки программирования, но рекомендовал не делать этого, потому что некоторые правила реализовать будет сложно. Этого вполне можно было ожидать, ведь собеседование могло длиться до 45 минут, а обсуждать простой fizzbuzz особого смысла не было. Менять язык программирования после начала собеседования тоже было запрещено.

Недавно я обнаружил потрясающую новую статью How to think about end-to-end encryption and AI, написанную группой исследователей из Нью-Йоркского и Корнеллского университетов. Я очень рад прочтению этой статьи, потому что, хоть не согласен со всеми её выводами, она стала первой попыткой ответа на невероятно важные вопросы.

С одной стороны, максимума мой интерес к этой теме достиг, когда были разработаны системы ИИ-помощников наподобие защиты от мошеннических звонков Google и Apple Intelligence. Обе эти системы нацелены на то, чтобы ИИ был задействован практически во всех частях телефона, даже в личных сообщениях. С другой стороны, я размышлял о негативном влиянии ИИ на конфиденциальность из-за недавних европейских обсуждений законов об обязательном сканировании контента, благодаря которым системы машинного обучения смогут сканировать все отправляемые личные сообщения.

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

Но давайте начнём с чего-то попроще.

RustDesk — приложение для удалённого рабочего стола с открытым исходным кодом, разработанное для самохостинга в качестве альтернативы TeamViewer. Название такое, потому что программа написана на Rust.

Работает из коробки, не требует конфигурации. Если установить сервер синхронизации на своём хостинге, то любые машины в интернете могут синхронизироваться и устанавливать соединение через наш сервер для удалённого управления рабочими столами друг друга. Трафик идёт напрямую между ними, но если это невозможно — тоже через сервер, до 3 Мбит/с (1920×1080).

Клиентское приложение есть для iOS и Android (на КДПВ), что позволяет со смартфона управлять рабочим столом Windows, Linux и MacOS (и наоборот), а также обмениваться файлами. Есть ещё веб-клиент.

«Вот бы существовал способ попроще...»

Я трачу слишком много времени на скроллинг лент соцсетей. Это вредит моему здоровью, так почему же я продолжаю это делать?

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

Однако я наткнулся на относительно малоизвестную сегодня старую бесплатную и опенсорсную технологию, которая ДОЛЖНА стать решением проблем современных медиа без потери доступного качественного контента. Это RSS.

Ричард Levelord Грей — известный гейм-дизайнер, один из основателей Ritual Entertainment, активно участвовавший в создании таких легендарных игр, как Duke Nukem, American McGee’s Alice и Serious Sam. В 2019 году мы беседовали с Ричардом о его пути в индустрию и работе над «дюком». Сегодня мы поговорим о более поздних (и нередко скандальных) проектах Ричарда по известным франшизам, о его независимой разработке и о том, как Levelord видит геймдев сегодня.

1. SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite.
   
   Её поддерживают три человека. Они не допускают внешних контрибьюторов.