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

За это время я пообщался со многими людьми из этой сферы: с членами некоммерческих организаций, сражающихся за права на конфиденциальность данных в разных странах до сотрудников компаний, занимающихся рекламными технологиями. Они подтвердили или опровергли мои слова (в основном подтвердили). Меня даже пригласили в подкаст «Lock and Code» для обсуждения геолокационных данных и конфиденциальности.

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

Я существенно улучшил свою методику (хотя она определённо может быть более эффективной), и в этом посте хочу поделиться ею.

* Деятельность Meta — соцсети Facebook и Instagram — запрещена в России как экстремистская.

▍ TL;DR

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

Описание выложено в репозиторий GitHub.

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

Два года спустя, после долгих мук и множества постов, я уволился [перевод на Хабре], чтобы создать собственную консалтинговую фирму. Неудивительно, что меня совершенно не волновало, получится ли у меня — я осознавал риски, на которые иду. Деньги приходят и уходят, ничего особо страшного со мной произойти не может.

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

Вспомню ли я два прошлых года написания постов и задумаюсь ли: «Разработка ПО не особо важна почти ни в каком контексте. Мы не запускали людей в космос: возможно, стоило просто брать лёгкие деньги и заткнуться?»

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

Если на компьютере под Linux нужно быстренько запустить Windows или MacOS, самый простой и быстрый способ сделать это — ввести команду для скачивания и загрузки докер-контейнера с этой ОС.

В маркетплейсе RuVDS много готовых образов с установленными операционными системами. Там разные дистрибутивы Linux, Windows Server и CentOS. Но нет контейнеров с операционными системами.

Операционная система в докер-контейнере (в QEMU) не требует ручной инсталляции ОС. Всего одна команда в консоли — и контейнер Windows скачивается и запускается.

Двадцать лет назад, 7 апреля 2005 года, Линус Торвальдс создал самый первый коммит в «информационном менеджере из ада» Git.

За эти двадцать лет Git превратился из простого маленького личного проекта в самую масштабную и популярную систему управления версиями.

Лично для меня это было захватывающее приключение в мире ПО, со своими взлётами и падениями.

Я начал пользоваться Git лишь спустя всего несколько месяцев после первого коммита, и применение его было достаточно необычным. А затем я стал сооснователем GitHub, написал самую, наверно, популярную книгу про Git, создал официальный веб-сайт проекта, организовал ежегодную конференцию разработчиков и так далее — этот проект изменил мир разработки ПО, но лично для меня он стал огромным изменением в судьбе.

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

Некоторые из них хорошо известны, другие — достаточно нишевые. Но все они очень полезны разработчикам и менеджерам. Любопытно, какие из них вам известны:

1. Закон Паркинсона.
2. Закон Хофштадтера.
3. Закон Брукса.
4. Закон Конвея (и обратный закон Конвея).
5. Закон Каннингема.
6. Закон Старджона.
7. Закон Завински.
8. Закон Хайрама.
9. Закон Прайса.
10. Эффект Рингельмана.
11. Закон Гудхарта.
12. Закон Гилба.
13. Закон Мёрфи.

Поехали.

Когда я запустила первую симуляцию червя, ветра Санта-Аны дули уже сильно. Я не хакер, но это было просто: открываешь оболочку терминала, вставляешь команды из GitHub и наблюдаешь за бегущим по экрану каскадом символов. Совсем как в фильмах. Пока я искала в пролетающем перед глазами коде узнаваемые слова — neuron, synapse — ко мне подошёл друг, чтобы пойти со мной на ужин. «Секунду. Я тут прогоняю на компьютере червя», — крикнула я ему из офиса.

В корейском ресторане царил хаос: ветер клонил пальмы и гонял магазинные тележки по парковке. Атмосфера казалась сюрреалистичной, похожей на подкаст, проигрываемый с удвоенной скоростью. «Чем ты там занимаешься? Киберпреступлениями?», — спросил друг. Я попробовала ему объяснить: «Нет, не червя типа Stuxnet. Настоящего живого червя».

Когда я добралась домой, было уже темно, а в Альтадене уже загорались первые искорки пожаров. На моём ноутбуке меня ждал червь в объёмной пиксельной коробке. Заострённый с обоих концов, он висел в тумане из частиц, странно прямой и неподвижный. Разумеется, он никогда не был живым. Но мне он казался мертвее мёртвого. «Браво», — сказал мне Стивен Ларсон, когда я написала ему тем же вечером, — «вы добились состояния «hello world» в симуляции».

Хранить тысячи закладок в браузере — совершенно неблагодарная задача. Там отсутствуют даже офлайн-предпросмотр и автоматические теги, не говоря о полнотекстовом поиске и автоматическом скачивании/архивировании по RSS.

Для нормального управления закладками нужно специализированное решение. Тут много вариантов, а одно из лучших — это опенсорсное приложение Hoarder («Копилка информации»). Оно устанавливается на сервер и выступает единой БД для доступа из любых клиентов: Android, iOS, Chrome, Firefox и т. д.

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

На практике, создаваемое нами ПО выполняется на множестве процессоров. К сожалению, многие наши допущения, справедливые для одного процессора, в случае нескольких процессоров становятся ложными. Например, каким будет состояние памяти, если два процессора изменяют один блок памяти? В общем случае на этот вопрос ответить сложно. Может случиться так, что внесённое одним процессом изменение перепишет внесённое другим. Справедливо может быть и обратное: может «победить» изменение другого процессора. Или оба процесса могут попытаться внести изменение одновременно, в результате чего возникнет неопределённое состояние, не соответствующее ни одному ожидаемому. Мы называем такие операции доступа «гонками данных» — ситуацией, в которой два или более процессоров в программе одновременно получают доступ к одной области памяти, и хотя бы одна из этих операций доступа выполняет запись без должной синхронизации.

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

В эти выходные мне пришлось купить новую посудомоечную машину, потому что моя старая GE умерла.

Я купил машину Bosch серии 500, потому что её рекомендовали в журнале Consumer Reports и, что более важно, она нашлась в магазине.

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

Есть два правдивых утверждения.

Первое прозвучит плохо для культуры, в которой инженеров мотивируют извиняться за сам факт их существования, а не умеющий кодить мошенник вправе заявлять, что он является «идейным вдохновителем». Утверждение заключается в том, что я — один из лучших инженеров в моей непосредственной рабочей среде. Я изучаю приблизительно на два-три порядка больше, чем средний инженер рядом со мной. Мне делала оффер на должность сениора одна из лучших компаний в стране, разные Серьёзные Люди с радостью повторно нанимают меня и радостно наблюдают, как я разгребаю лениво составленные примечания к коммитам. Дела мои вполне хороши.

Второе прозвучит плохо, потому что иногда мне приходится убеждать людей нанять меня: я очевидно хуже, чем те, кто пишет мне связанные с работой письма. Я смутно лишь могу догадываться, как с тремя-четырьмя годами опыта качественной работы в психологии я смог стать «сениор-инженером». Я писал тесты только для личных проектов, потому что ни у одного моего работодателя не было никаких рабочих тестов, как и интереса в их написании. Код для моей магистерской я полностью написал без контроля версий, потому что один из лучших университетов страны ему не обучал. Если вкратце, я ни разу не решал по-настоящему сложной задачи, а лишь нажимал на кнопочку «сэкономить полмиллиона долларов», которую не замечал никто другой. Я просто тупица.

Я знаю, что второе утверждение истинно, потому что вижу, насколько сложными вещами занимаются другие люди, и знаю, что истинно первое, ведь я, иммигрант, без проблем попал в 3-4% людей, получающих самую высокую зарплату в стране. Как эти два утверждения могут быть истинны одновременно?

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

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

YouTube Music, «Яндекс Музыка», Spotify, SoundCloud — относительно удобные музыкальные сервисы, но с недостатками:

• плохая работа в офлайне;
  
• отсутствие поддержки lossless;
  
• абонентская плата;
  
• неполная фонотека;
  
• многое другое...

Их коллекции далеки от полноты. Редких треков вообще нет. Более того, музыка иногда просто пропадает из-за каких-то заморочек с авторскими правами.

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

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

Введение

Несколько месяцев назад в поисках идей по ускорению кода я изучал множество научных статей по 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 очень часто используются дополнительные защиты от любопытных глаз, например, обнаружение джейлбрейка или обфускация кода.

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

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