• Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)
    0

    Не очень понятен вопрос. Если речь о Kali под Banana Pi, то я предлагаю сделать всё то же самое, заменив только сборку ядра и U-Boot. Все инструкции по сборке этих двух компонентов должны быть в наличии.

  • VPN в домашнюю локалку
    0

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

  • Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)
    0

    До вашего комментария не знал о такой фиче. Попробую разобраться, спасибо!

  • Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)
    0

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


    Для добавления пакета в Ubuntu придётся либо выполнять довольно строгие требования проекта Debian, либо выполнять всё то же самое для Ubuntu и, возможно, объяснять, почему это не было добавлено сразу в Debian. А потом ещё ждать релиза перед использованием.


    Альтернатива — собственный репозиторий, который придётся частично синхронизировать с Kali, возможно, следить за версиями и зависимостями.


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

  • Возможности для массового деанона в Telegram
    0

    Вы – большой молодец!

  • Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)
    +1

    Не вполне согласен, но неоднозначность действительно есть. Меньше всего я думаю над заголовком, поправил.

  • Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)
    +1
    1. Под Kali собирают огромное количество самого разного ПО требуемого для пентеста, скорее всего, это будет использоваться в следующем Флиппере. оно находится в более актуальном состоянии и требования для его сопровождения у Kali существенно ниже чем, например, у Debian. Думаю, сравнивать имеет смысл только с другими дистрибутивами для пентеста.
    2. Всё в мерж-реквесте. Собираются образы shell-скриптом, функциональную часть я в этой статье и расписал. Есть, конечно, некоторые best practices, но они слишком специфичны для конкретно этой команды, просто сложившийся набор правил.
  • Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)
    +1

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

  • Flipper Zero — прогресс за сентябрь
    0

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

  • Flipper Zero — прогресс за сентябрь
    0

    Качество приёма переотражённого IR-сигнала не меняется от положения передатчика?

  • Возможности для массового деанона в Telegram
    0

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

  • Возможности для массового деанона в Telegram
    0

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


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

  • Возможности для массового деанона в Telegram
    –2

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


    Статья выглядит предвзято, потому что я предвзят по отношению к синхронизации контактов из телефонной книги, в этом вы правы. Впрочем, убрал слово "тотальный" из заголовка. Действительно, наличие таких настроек исключает его по смыслу.

  • Возможности для массового деанона в Telegram
    +2

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

  • Возможности для массового деанона в Telegram
    –3

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

  • Возможности для массового деанона в Telegram
    –1

    Виноват, каюсь. Сначала я надеялся, что у меня получится, а потом не придумал ничего другого. В tl;dr постарался никого не запутать.

  • Возможности для массового деанона в Telegram
    +1

    Я смотрел на сайтах вроде sms-reg.com, там зависит от мессенджера. Для телеграма регистрация дороже.

  • Упаковка приложения в F-Droid
    0

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

  • Упаковка приложения в F-Droid
    +1

    Я просто не подумал об этом на тот момент. Краем глаза увидел, что единственный com.google.* свободный и приверил ещё парочку подозрительных, но целиком проверять не стал. В голове держал только то, что гугловых инструментов для сборки в F-Droid просто нет.


    Хорошее замечание, перед окончательной упаковкой обязательно перепроверю.

  • Ядерный шелл поверх ICMP
    0

    Интересно. Мне всегда казалось, что void говорит о том, что никаких данных не подразумевается.

  • Ядерный шелл поверх ICMP
    0

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

  • Ядерный шелл поверх ICMP
    0

    Одного, поэтому ICMP-пакет и не требует тройного рукопожатия. Но для модуля ядра это не должно быть проблемой, TCP-пакет можно принять и обработать в любом виде, без установки полноценного соединения.

  • Ядерный шелл поверх ICMP
    0

    Точно, как-то я и не заметил подмены.

  • Ядерный шелл поверх ICMP
    0

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

  • Ядерный шелл поверх ICMP
    0

    Обязательно, спасибо! Про фрагментированные echo-пакеты я даже не знал.

  • Ядерный шелл поверх ICMP
    0

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

  • Ядерный шелл поверх ICMP
    0

    В случае с ядром будет сходу kernel panic.

  • Ядерный шелл поверх ICMP
    0

    Интересно, спасибо. Подумаю над этим, когда чуть лучше изучу язык.

  • Ядерный шелл поверх ICMP
    0

    Я тестировал на удалённой. Повезло, но могло быть интересней.

  • Ядерный шелл поверх ICMP
    0

    Не понимаю проблему, я даже в C не специалист. cmd_string может перезаписываться разными ICMP-пакетами?

  • Ядерный шелл поверх ICMP
    0

    У меня до виртуалки ничего не подменялось. Есть сведения о железках, которые точно так делают?

  • Ядерный шелл поверх ICMP
    0
    Есть ограничение на ethernet пакет

    Да, MTU, про него не думал. Если IP-пакет собирается ядром прежде чем попадёт в нетфильтр, то всё будет хорошо. Возможно, зависит от приоритета, надо проверять.


    при следующем icmp echo отправьте его назад

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


    Когда у меня на виртуалке заканчивается оперативная память вместе с буфером подкачки, то /bin/sh уже не открывается.

    Подозреваю, что в этом случае и сама команда рискует не выполниться. Команда ведь всё же не в ядре выполняется, ядро запускает процесс в юзерспейсе. Пока я имел в виду только высокий LA, на случай нехватки памяти, проще будет добавить ключ sysrq:, который будет в обход юзерспейса триггерить нужный обработчик. Там есть и вызов OOM и убийство всех процессов кроме инита.

  • Ядерный шелл поверх ICMP
    0

    Проверил файндом, ничего не нашлось. Там лежат модули из пакета и из DKMS, а загружаемое простым insmod остаётся только в памяти. Заметно будет в выводе lsmod.

  • Ядерный шелл поверх ICMP
    0
    каков максимальный размер ICMP payload?

    Сам ICMP-пакет по размерам не ограничен, но есть ограничения на IP-пакет, 65535 байт. Из этого вычитаем 20 байт на заголовок IP-пакета и 8 байт на заголовок ICMP-пакета, получается намного больше, чем моё ограничение.


    Было бы интересно увидеть реализацию отправки «ответа» в icmp reply.

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


    Будет ли оно работать когда уже свалился shh?

    Конкретно это не проверял, /bin/sh никак не зависит от SSH-сервера. Кроме того, SSH работает по TCP, а в моём модуле TCP никак не затрагивается.

  • Ядерный шелл поверх ICMP
    0

    Должна. Фунцкия с запуском будет уже поставлена в очередь планировщика, но клиентская часть точно зависнет, потом учто ожидает ответного пакета.

  • Железо проекта: как мы строили комнату с хакерским квестом
    +1

    Гирлянда была отвлекающим манёвром? В дискорде мигание приняли за модуляцию, морзянку какую-нибудь.

  • Ядерный шелл поверх ICMP
    +1

    Если в хуке вызывать юзерспейс-программу не ожидая её выполнения, с аргументом UMH_NO_WAIT, то ничего не произойдёт. Думаю, что хук завершается вместе со всеми потомками. Если вызывать с UMH_WAIT_EXEC или UMH_WAIT_PROC, то ядро крашится.

  • Ядерный шелл поверх ICMP
    –1

    Да, верно. Такая безопасность будет работать только через неясность. Я полагаю, что можно заменить прероутинг на построутинг и дать доступ только локальным IP-адресам. Возможно в этом случае до модуля не доберутся "марсианские" пакеты и подделка не будет работать.

  • Ядерный шелл поверх ICMP
    0

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

  • VPN в домашнюю локалку
    –1

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