https://github.com/Exodus-Privacy/exodus-standalone/blob/096eb7bf10e05594227178cb76486f01c283e799/exodus_analyze.py#L76

Я такого ещё не видывал. Это скрипт, который ищет в приложениях всякие трекеры. Возможно вы знаете про Exodus, например вот: https://cloudflare.f-droid.org/en/packages/org.eu.exodus_privacy.exodusprivacy/

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

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

У меня тут странная ситуация. Есть программа, задача которой - шифровать данные пользователя. Когда пользователь вводит мастер-пароль, то какое-то время он виден в памяти программы. И, в целом, это более-менее ожидаемо - хотя бы потому что GUI здесь и сейчас этот пароль отображает.

Но вот далее, когда пароль принят и контейнер подключен, он тут же должен вытереться из памяти. Об этом, кстати, даже OWASP пишет:
> 8.3.6 Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data.

Однако я ещё несколько минут считываю пароль из памяти. Видимо его просто не вытирают вовсе и он стирается только тогда, когда сама ОС таки что-то туда запишет. И, если система просто простаивает, пароль будет ещё долго доступен.

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

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

Опустим, что у производителя на этом ящике нет автоматического ответа с тикетом, просто молчание. Но через несколько дней мне всё же ответили, что разберутся. Через неделю молчания я снова написал "ну чего" и ответили, что у них не воспроизводится, удалось извлечь лишь часть пароля и вообще такой баг правили в 2019 году.

В общем, проще процитировать переписку, убрав всё, что может подсказать, о чём идёт речь:

<вырезано>По всей видимости, GUI не обнуляет введённый мастер-пароль, сохраняя его в памяти.
<вырезано>Для наглядности и простоты воспроизведения я использовал ArtMoney.
<вырезано>Видео здесь: https://<ссылка на мой некстклауд>

Через неделю снова я:
Привет. Есть какое-то движение?

Ответ:
У нас нет точного воспроизведения данного кейса, в памяти только удалось найти часть от пароля. Мы посмотрели на предыдущие исправления <вырезано>, у нас это правилось еще в 2019 году.

Я:
Эм. В смысле? На видео версия <вырезано: суть в том, что самая распоследняя и новее нет> На видео показано, как пароль находится целиком.
Просто если вы говорите, что проблемы нет, я публикую данные сейчас.
Если вы говорите, что проблему подтвердили и работаем над устранением, то публикую через 90 дней после подтверждения.

Ответ:
Попробуем повторно воспроизвести.

————-
Собственно, к чему я это всё. У меня какая-то непонятная ситуация. Производитель и не подтверждает проблему и я не могу запустить 90 дней стандартных, и не опровергает и я не могу опубликовать демонстрацию. Вот что я должен делать?

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

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

СЯУ, что при генерации UUID версии 1 используется в том числе, читаем внимательно... Количество порций (интервалов, штук - как вам нравится) по 100 наносекунд, прошедших с 15 октября 1582.

Одна наносекунда, это одна миллиардная, то есть 10e-9 или 1/1_000_000_000 секунды. Добавляем два разряда этой соточки, получается 10e-7 или 1/10_000_000 или одна десятимиллионная секунды. То есть сколько десятимиллионных секунды прошло с 15 октября 1582 года.

Пришлось загуглить, что это за дата. Оказывается это дата введения григорианского календаря как раз.

Мне это напоминает вот ту шутку: "Один человек, живший в семнадцатом столетии, как-то смешал воду, лед и соль и измерил температуру замерзания смеси. Эту температуру он принял за ноль и наверняка хохотал, представляя, как все станут ломать голову: а нахуя было солить?! Фамилия у него была Фаренгейт."

В боевой сборке ГосУслуг забыли убрать регистрацию тестовой ссылки. Вряд ли страшно, но глупо

Я один сначала прочёл так, что согласие выдано до 27 года?

Дело не двигается. Написал письмо с указанием даты публикации информации публично. 90 дней выпадают на май (отсчёт идёт от 6 февраля - когда впервые мне ответили).

Странное ощущение, когда упрашиваешь компанию исправить проблему в их продукте, тогда как сама компания позиционируется как ИБ контора.

Ну либо проблема реально существует только у меня в виртуалке, я уже не знаю. Проверим в мае.

Мир Пэй просто перманентно находится в ANR. Я отправил им 60 последних отчётов. Посмотрите на частоту:

- Вот вам багрепорт
- А где паспорт и мазок?

https://text.tchncs.de/umnik/eto-prosto-podbivka-spiska-izmenenii-s-poiasneniiami-chtoby-ne-skakat-po-stat-ia

Подбил в одном месте, какие изменения в Android 14 будут для нас — разработчиков и тестировщиков.

Попробовал новую блогоплатформу, но позже скопирую этот текст на привычный blogspot. Было бы классно найти платформу для блогов, именно длинных, с картинками и всё такое, но быстрых. И не тех, которые завязаны на конкретные сервисы типа Телеги.

В общем, с блогспота надо валить, но куда. Вот, трогаю пока writefreely. Он и маркдаун поддерживает, и является частью федивёрса

https://myachinqa.blogspot.com/2023/03/android-14.html

Та же самая статья, просто на блогспоте. Могут вылезти старые, уже исправленные, опечатки, т.к. я запутался в версиях и мог перенести не ту. Ну, опечатки на суть не влияют.

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

То, что основная масса пользователей будет делать это на автомате для калькулятора оценки роли не играет, так что норм. Многопользовательские системы также не рассматриваю, т.к., будем честны, более одной учётной записи Windows — это прям лютая редкость. Но нужно понимать, что если атакующий — ваша "половинка" или кто-то, кому вы (зря) доверяете, то защиты сейчас нет. Он просто запустит заразу _в своём сеансе_ и в нём же поднимет заразе привилегии, предоставив возможность читать память процессов _в вашем_ сеансе. Но это опускаем.

В общем, будем надеяться, проблему исправят.

Дополнительно — скоро запишу видос про уязвимость в Android, которую исправили. Сейчас период релизов, просто не до этого. Но я не забыл :) И да, денег всё ещё не заплатили. Висят в статусе PENDING.

Обещанная статья про уязвимость в Android, которую нашла наша команда. Напомню, что сводилась она к тому, что WhatsApp получал доступ к микрофону так, что Android этого не видел и никак не сигнализировал: не сохранялось в истории доступа, не появлялся соответствующий индикатор.

Текст один и тот же, выбирайте, в каком форматировании вам удобнее читать. Ну и первая весит поменьше. Ссылка на PoC в статье есть.

https://text.tchncs.de/umnik/obkhod-rezhima-mode_ignored-v-app-op

https://myachinqa.blogspot.com/2023/03/modeignored-app-op.html

Если вы хотите сообщить о проблеме в "Мой Офис" (входит в реестр отечественного ПО), то у вас затребуют персданные. Читаем соглашение о них:

2. Цели сбора и обработки персональных данных

- направление подписчикам и пользователям Сайтов сообщений информационного и рекламного характера посредством электронных почтовых сообщений и смс-сообщений с соблюдением требований действующего законодательства Российской Федерации;

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

Вообще удивительное дело. Наши разработчики ПО выполняют 152 ФЗ спустя рукава и используя максимум лазеек, чтобы положить на него болт. При этом исполнять требования GDPR бегут, роняя тапки. Выглядит так, что производителям ПО положить хрен на сограждан, но вот эльфы из Европы достойны самого лучшего

Кто-то, простите не помню кто, но точно был подписан, спрашивал про стажировку. У меня её нет, но вот мои бывшие коллеги делают: https://safeboard.kaspersky.ru/ Оплачиваемая!

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

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

https://music.yandex.ru/album/18910064/track/110185672

- У нас была платёжная форма, на которую было написано 9 тыс. строк тестов и ни один из них не проверял чего-то нужного
- Как так?
- Это тесты, ну там, на уровне, где вообще всё замокано. И условие такое: if (true) { return true }. И так 9 тысяч строк кода

СЯУ, что клиенты ДОЛЖНЫ (MUST) сваливать коды возврата в их дженерик варианты, когда не знают реального кода. HTTP коды, в смысле.

Суть в том, что списки кодов возврата расширяемы (ну, это не новость) и, если клиент не знает конкретного кода, он MUST обработать код как x00. То есть 204 → 200, 409 → 400 и прочее.

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

Ухудшилась стабильность автотестов на Espresso. Стал разбираться, в чём дело.

У меня есть тест, который следит за таймером на экране. Так как я стараюсь не трогать код самого приложения (лезть в код, который написан много лет назад - себе дороже), то использовал банальный способ: делаю ViewAssertion на нужный мне текст и, если получаю исключение о несовпадении текста, повторяю попытку. Ну а что поделать, приходится так.

Это работало прекрасно несколько лет. И недавно сломалось. Каждый раз ассершен не обнаруживает нужный счётчик, пролетает мимо. Стал отлаживаться и увидел, что эспрессо просто замирает на 5 секунд после каждого опроса!

Оказалось, что поведение Espresso изменили в 3.5.0: https://developer.android.com/jetpack/androidx/releases/test#espresso-3.5.0

Espresso's DefaultFailureHandler now saves a screenshot on test failures to TestStorage

И вот если эспрессо не смог снять скриншот, он замирает на 5 секунд. Но хотя бы сообщает об этом в лог: java.util.concurrent.TimeoutException: Waited 5 seconds (plus 1063571 nanoseconds delay) for androidx.concurrent.futures.ResolvableFuture

Эта проблема не только у меня, вот другой человек жалуется: https://github.com/android/android-test/issues/1584

Гугл сжалился и сделал "фикс" https://github.com/android/android-test/commit/44b2b456d3052f6114ac3e3b5d2676e6f8885e37 На самом деле не фикс, а просто теперь я обязан создать свой FailureHandler и выставить отключение снятия скриншота.

Фикс доступен только в альфе: https://developer.android.com/jetpack/androidx/releases/test#espresso-3.6.0-alpha01: Allow customizing espresso's default failure handler to disable screenshots on failures

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

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

Текст будет в комментарии

    /**
     * Retrieves default launcher package name
     *
     * @return package name of the default launcher
     */
    public String getLauncherPackageName() {
        Intent intent = new Intent(Intent.ACTION_MAIN);
        intent.addCategory(Intent.CATEGORY_HOME);
        PackageManager pm = mInstrumentation.getContext().getPackageManager();
        ResolveInfo resolveInfo = pm.resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY);
        return resolveInfo.activityInfo.packageName;
    }

UiDevice из uiautomator от Google утверждает, что лончером у меня является com.android.settings, а не com.android.launcher3. Лан, напишу свою определялку.

Поисследовал поведение и похоже дело такое:
- https://issuetracker.google.com/issues/178965163
- воспроизводится на Android 11 и новее. Стреляет из-за фичи видимости пакетов. Ну знаете, нужно в манифесе прописать <queries> либо дать разрешение на получение всех приложений
- настройки действительно являются лаунчером. Но когда пользователь таки разблокирует устройство, они передают управление лаунчеру по умолчанию

Решений этой проблемы два с половиной варианта:
1. Написать свой детект лаунчера. Я не проверял, но чел утверждает, что работает: https://github.com/adil-hussain-84/UiAutomatorExperiments. Это не мой путь. Выше я уже писал, что не хочу подменять поведение фреймворков без крайней нужды
2. В Манифесте включить ожидаемые ланчеры в видимость. В моём случае:

    <queries>
        <package android:name="com.android.launcher3"/>
    </queries>

2.1. В Манифесте объявить разрешение android.permission.QUERY_ALL_PACKAGES, которое позволит видеть все приложения. Возможно вам будет удобнее этот вариант