Добрались до дефкона в этом году.

Напишу потом подробный пост.

Афтерпати проходит хорошо

Ищу людей готовых делать CTF таски за вознаграждение на публичные/не публичные ивенты.
Резюме кидать в личку - @revker.

Тем временем появился первый анонс про проект, над которым я работал последние полгода.

https://www.forbes.com/sites/daveywinder/2024/10/23/new-security-shakeup-for-1-billion-users-of-google-messages-confirmed/

Очень страшно запускать что-то на 1 миллиард пользователей, посмотрим как оно полетит...

Как долго я спал. Оказывается в пыхе теперь нельзя (deprecated) писать вот так:

echo "Hello ${name}";

Вот так все еще можно

echo "Hello {$name}"

https://php.watch/versions/8.2/$%7Bvar%7D-string-interpolation-deprecated

Ушла эпоха.

В блоге JetBrains вчера вышло прощание с создателем Флибусты – Стивером, но с малоизвестной стороны: в очень техническом посте подробно расписано как много Стивер сделал для языка программирования Java, если коротко – он был автором популярного инструмента для программистов на языке Java и сильно облегчил жизнь программистам, и я честно этого не знал

JetBrains теперь организует мемориал в память Стиверу, продолжит развитие этого инструмента (декомпилятора Fernflower) с открытой лицензией, и рассматривает гранты и стипендии людям в смежных сферах

JetBrains – молодцы

Кстати как-то забыл написать про новую опен-сорц тулзу от Гугла.

Это аналог утилиты file, но вместо magic используем другой magic ML.

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

https://github.com/google/magika

10 лет в CTF

У меня сегодня своеобразный юбилей. Написал аж целый длинно-пост на эту тему.

https://telegra.ph/10-let-v-CTF-11-08

Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешников" и "айтишников" заменят "роботы" 🌝

Сегодня мы с радостью готовы поделиться первой уязвимостью из реального мира, обнаруженной агентом Big Sleep: отрицательным переполнением (underflow) буфера стека с возможностью реализации эксплойтов в SQLite, — широко используемом опенсорсном движке баз данных. Мы обнаружили уязвимость и сообщили о ней разработчикам в начале октября, и они устранили её в тот же день. К счастью, мы обнаружили эту проблему до её появления в официальном релизе, так что она не затронула пользователей SQLite.

Как мы нашли уязвимость в SQLite при помощи LLM
https://habr.com/ru/articles/855882/

Оригинальный пост
https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html

Но я сейчас хотел бы не про это.

SQLite знаменит тем, что они очень трепетно относятся к тестированию своего кода.

В частности, тестового кода в 590 (пятьсот девяносто) раз больше, чем кода самого проекта

As of version 3.42.0 (2023-05-16), the SQLite library consists of approximately 155.8 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 590 times as much test code and test scripts - 92053.1 KSLOC.

Думаю говорить о том, что там 100% покрытие ветвлений не надо.

SQLite активно использует fuzzing. Использовать они его начали после того исследователь Михал Залевски (Michał Zalewski) нашёл 22 бага с помощью фаззера

Фаззинг нашёл 22 бага в SQLite за полчаса
https://xakep.ru/2015/04/16/fazzing-sqlite/

Оригинальный пост
Finding bugs in SQLite, the easy way
https://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html

Или, например, у них есть Valgrind, который позволяет отлаживать работу с оперативой, делать профилировку и обнаруживать утечки

SQLite делает ещё кучу всего, что бы сделать свой продукт лучше. Подробней можно почитать на отдельной странице - https://www.sqlite.org/testing.html

И в таких условиях всё равно находятся регулярно баги, что-то нужно править и т.д.

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

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

Мы украли идею вдохновлялись Google Hackceler8, и получилось достаточно круто.

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

Если вам интересно почитать исходники простенького платформера на Go и поискать баги самому, то вот вам код.
https://github.com/C4T-BuT-S4D/ctfcup-2024-igra

А под спойлером читы от команды-победителя академического зачета.
https://github.com/dtlhub/ctfcup-2024-igra/

В комменты прикреплю примеры прохождений.

Ну, и немного мыслей на эту тему, как разработчика CTF со стажем.
Для начала, распишу немного подробнее формат:

0. Взламывать игру? В смысле?
В прямом. Мы даем игрокам исходный код игры на Go с уровнем, на котором есть 4 предмета, и их нужно собрать.
Понятно, что если задача будет просто собрать предметы, то игроки могут очень быстро поломать игру локально и просто переместить игрока к предмету или поменять код, чтобы сделать себе wall-hack.
Поэтому у нас есть сервер, который проверяет, что игроки не написали чит. В нашем варианте всё работает достаточно просто:
* Раз в тик состояние игры меняется, в том числе, если игрок нажал на клавишу
* На клиенте мы считаем контрольную сумму состояния движка (буквально где стоит игрок, сколько у него хп, где находится босс и т.д.)
* Input игрока и хэш состояния игры отправляется на сервер
* Сервер применяет инпут игрока, сверяет контрольную сумму и, если она не совпадает, заявляет, что игрок считерил.
Такое решение позволяет нам запрещать какие-то мощные читы (тот же wall-hack), но при этом разрешать другие читы (slow-mode, free camera).

1. Такой формат не самый лучший для проведения идеальных (максимально честных) соревнований.
Но формат достаточно интересно смотреть даже, если вы ничего в этом не понимаете.
Для этого правда нужна очень хорошая трансляция, если интересно, посмотрите финал Google CTF прошлого года.
https://www.youtube.com/watch?v=HFeD4kYcW7A

2. Такой формат гораздо интереснее писать разработчикам.
Последние много лет я делаю задачи на CTF, и идей уже меньше, мотивация делать задачи зачастую отсутствует.
А тут что-то новое, так еще и разработка игр. Я никогда не занимался разработкой игр, а тут тебе нужно делать всё практически с нуля, чтобы сделать баги в игровом движке.
Получается два в одном: ты закрываешь юношеский гештальт по разработке игр + делаешь интересные задачи для участников.

3. Раунды короткие.
Всего 4 предмета и 2.5 часа. Соревнования достаточно динамичные и игроки точно не успевают заскучать.
На прошедшем финале только последний уровень игроки смогли полностью решить (собрать все предметы), но и на это потребовалось почти всё время.

4. Некоторые баги придумываются сами-собой.
Мой баг для первого уровня появился когда я делал реализацию Coyote-фреймов. Я забыл ресетнуть новое состояние при ресете игры, и получалось, что ты мог сделать прыжок в воздухе сразу после рестарта игры (и только после рестарта).
Дальше другой разработчик для красоты сделал тайлы, с которыми игрок не коллизится (для красоты). Сразу решили добавить это в первый уровень, сделав "фэйковую стену"

Но есть и минусы:
1. Сложно придумать много багов на механики игры и не повторять себя.
Чтобы сделать все баги в игре на механики, нужно добавить много механик, а это не так уж и просто. В итоге мы добавили несколько обычных CTF-задачек в игру. Но для решения некоторых задачек всё равно нужно было понимать как работает движок игры (например, как можно ввести unicode в диалоговое окно).
2. В соревновании сильно решает умение быстро и много читать код на языке движка.
В нашем случае нужно было читать много кода на Go, который я считаю очень читаемым языком. Но всё равно, получается небольшое преимущество, если у вас в команде есть senior go developers.
Итог:
Формат придуманный Гуглом, кажется глотком свежего воздуха в мире CTF, где существует 2.5 формата (KoH считаем за 0.5).
Я очень рад, что наша команда может повторить этот формат для наших соревнований, дать участникам кубка пощупать новый формат хакерских игр и получить удовольствие от участия в финале.

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

Поэтому они уже будут после нового года.

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

На видео попали все перелеты и некоторые авто-путешествия, при этом за кадром осталось около 10 поездок по Ирландии.

Ну и немного статистики:
30+ перелетов
15+ стран
3 континента

Давеча друг прислал пост из одного из тележных пабликов.

Первая мысль-напоминание по этому поводу: огромное кол-во современных пабликов в телеге (да и некоторых СМИ) — кликбейтные помойки, которым лишь бы что-нибудь запостить для охватов, а фактчекинг для лохов. Но это вы и так знаете.
А теперь по сабжу. Перед вами как раз таки мой последний проект в Гугле. И нет, они не сканируют все ваши фото. Они вообще не сканируют ничего задним числом (по крайней мере не должны). И даже вот вам пару ссылок в защиту:
https://thehackernews.com/2025/02/google-confirms-android-safetycore.html
https://www.howtogeek.com/google-is-not-scanning-all-the-images-on-your-android-phone/

Но теперь другая мысль, более обидная.
Я понимаю почему люди недовольны и почему они легко поверят в заголовки “Гугл сканирует ваши файлы”. И тут я выделяю два основных фактора: PR и репутация.
Напоминаю, что я здесь сильно biased: я работал в Гугле над этим проектом. И господи, вы бы знали как мы запаривались на тему privacy всего этого. Мы буквально делали большинство решений с мыслью: “мы НИКОГДА не получим никакого фидбэка юзера. У нас не будет НИКАКИХ логов.” И это скорее всего правда на ближайшие годы. Обсуждали различные edge-case’ы и все понимали, что если пользователь сам не даст согласие, мы не получим никакого фидбэка. Да и фича скорее всего, будет работать добровольно у совершеннолетних пользователей, а значит большинство пользователей её не включит. Но важно это не только обсудить внутри, но и донести пользователям: нарисовать красивые диаграммы, сделать пресс-релиз. Apple например тоже ставят что хотят и вообще хотели сдавать вас ментам известны странными идеям. Так вот, у эппла есть такая же фича (блюр фоток для детских аккаунтов) и я не слышал, чтобы был вой на эту тему. Потому, что эппл сделали какой-то пресс-релиз о своей фиче, да и большинству людей пофиг на апдейты, если они не делают их жизнь хуже.

И вот тут, как раз хочу поговорить про репутацию. И тут у меня очень двоякое ощущение. Многие люди выбирают андройд, а не айфон, как раз-таки потому, что у вас есть контроль над приложениями, апдейтами и вообще, что у вас установлено, то и работает. Хотите удалить гугл сервисы? “Да, пожалуйста”. И таких пользователей справедливо бесит, что им поставили что-то без их ведома. И я это понимаю, и было бы круто дать людям галочку “я ничего не хочу я не хочун” и пусть их обходят стороной все обновки.
А второй момент как раз в том, что люди не доверяют Гуглу и в современном мире AI думают, что компании пытаются получить их данные любыми способами. Поэтому звучит логично, что Гугл слушает ваши устройства, сканирует все ваши фотки и тд.

Как итог:
Если бы я работал сейчас в Гугле, у меня бы сгорело сильнее. Куча людей старались, правда думали о privacy, но в итоге подвел маркетинг/PR. При этом я считаю, что сама фича получилась хорошо. И если это убережет хотя бы одного ребенка от внезапного дикпика, я буду считать, что не зря потратил полгода жизни, учив машины смотреть на нюдсы. И не читайте желтушных телеграм-каналов перед обедом.

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

https://www.quantamagazine.org/the-largest-sofa-you-can-move-around-a-corner-20250214/

Очень прикольная история!
В 1966 году математик Лео Мосер сформулировал задачу “moving sofa”:
Представим себе коридор шириной 1 ед с поворотом на 90° в конце.
Задача - найти максимально большой по площади двумерный диван, который можно продвинуть через угол.

Как оказалось, задача эта ни разу не тривиальная, и на ее решение ушло больше 50 лет.
Даже интереснее: в 1992 другой ученый по фамилии Гервер предложил супер нетривиальную форму дивана (на видео), при которой площадь достигает 2.2195 ед^2.
Но ни он, ни другие математики не могли формально доказать, что эта форма является оптимальной.

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

- Форма дивана Гервера состоит из 18 элементов сложной формы, и ее площадь не описывается ни в каких известных величинах (π и прочих).
Но, тем не менее, она является оптимальным решением задачи “двигающегося дивана”.

И вот в декабре 2024 молодой корейский математик Jineon Baek представил свое доказательство оптимальности дивана Гервера.
Он представил все допустимые варианты формы дивана в качестве точек бесконечно-мерного пространства, и создал такую фукнцию Q, которая удовлетворяла нескольким условиям:

- Для произвольной точки в пространстве диванов Q выдает значение, больше или равное площади дивана такой формы.
- Для точки, соответсвтующей дивану Гервера, значение Q = фактической площади дивана.
- Функция “ведет себя” похоже на параболу

Дальше ему оставалось доказать, что функция достигает максимума как раз в точке Q - тогда диван Гервера будет оптимальным решением задачи о перетаскивании дивана. Что он и сделал в своей 119-ти страничной работе.

Кстати, Герверу сейчас 75 и, с его слов, ему “повезло дожить до момента”, когда его решение наконец обосновали. Мощно!

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

Вчера ездили с друзьями в weekend trip, останавливались в Airbnb.
Решили вечером посмотреть фильм и подключить ноутбук к старенькому телевизору.

И, значит, беру я свой макбук на M1 — пытаюсь сделать трансляцию экрана, запускаю фильм в VLC. Сначала наблюдаю рассинхрон звука с видео, а потом мак просто ловит фриз. Прям вот такой фриз, что нужно долго держать кнопку выключения.

Оказалось, что это известная проблема на M1:
https://discussions.apple.com/thread/255299255?answerId=260151714022&sortBy=rank&page=1

Вообще крайне интересно, на каком конкретно моменте трансляция видео через HDMI может всё зафризить, но в итоге я попробовал:

1. Не дублировать экран, а выводить отдельно.
2. Снизить refresh rate до 24 Гц.
3. Выключить Bluetooth, лол (совет с форума выше).

Не знаю, что из этого помогло, но фильм мы посмотрели. Осадочек от Apple остался.

P.S. Макбук — всё ещё топ-ноут за свои деньги.

Я сейчас в командировке и резко вспомнил веселую проблему у приложения убер.

Заключается она в том, что мне приходят все чеки на русском. А потом эти чеки мне нужно отправлять в бухгалтерию (в Ирландии/США).

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

https://www.reddit.com/r/uber/comments/1d597ty/changing_language_from_receipts/

Опять же, известная проблема, но никто не чинит.

Больше всего меня в таких багах радует думать об их происхождении. Как разработчик с каким-то стажем у меня обычно есть несколько догадок почему так вышло. Моя версия под спойлером:

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