Телеграм канал «Kali Linux»

Нашли готовую виртуальную машину для OSINT-исследований — Trace Labs OSINT VM.

Это не «магическая пробивалка», а отдельная рабочая среда для легального поиска по открытым источникам: CTF, фактчекинг, расследования, поиск цифровых следов и обучение OSINT.

Что внутри:

* Sherlock — поиск аккаунтов по username
* PhoneInfoga — анализ открытых данных по номерам
* SpiderFoot и sn0int — автоматизация OSINT-проверок
* theHarvester и h8mail — работа с email и утечками
* Shodan CLI — поиск по открытым интернет-устройствам
* Sublist3r — поддомены
* exiftool и steghide — метаданные и стеганография
* Obsidian — заметки прямо во время исследования

Главный плюс - всё уже собрано в изолированной VM, не нужно засорять основную систему десятками инструментов.

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

https://github.com/tracelabs/tlosint-vm

Как найти бэкдор на своём ПК: 6 шагов проверки

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

#бэкдор #кибербезопасность #взлом #безопасность

✔️ curl - один из самых недооценённых проектов в истории софта.

Первый релиз вышел 20 марта 1998 года. Его запустил один разработчик - Daniel Stenberg.

Прошло больше 27 лет, а он всё ещё поддерживает проект.

Сегодня curl работает на миллиардах устройств и поставляется почти везде:

* macOS
* основные Linux-дистрибутивы
* Windows 10 и новее
* серверы
* контейнеры
* embedded-системы
* CI/CD пайплайны

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

Одна маленькая CLI-утилита стала невидимой инфраструктурой интернета.

Вот так выглядит настоящий open source: без хайпа, без миллиардных раундов, но с кодом, который держит половину мира.

💡Совет Linux

Случайно удалил файл и не понимаешь, что именно пропало?

Попробуй проверить недавние изменения:


find ~/ -type f -mtime -1


Команда покажет файлы в домашней директории, которые менялись за последние 24 часа.

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

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

✔️ Продвинутый Linux-совет: как быстро найти конфиг, который ты правил вчера

Бывает классика: вчера что-то поправил в /etc, сегодня сервис ведёт себя странно, а какой именно конфиг менялся, уже не помнишь.

Базовый вариант:


find /etc -type f -mtime -1


Он покажет файлы в /etc, изменённые за последние 24 часа.

Но на практике лучше использовать более точную версию:


sudo find /etc -type f -mmin -1440 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort


Что здесь полезного:


-mmin -1440


Ищет файлы, изменённые за последние 1440 минут, то есть за сутки.


-printf '%TY-%Tm-%Td %TH:%TM %p\n'


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


sort


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

Если нужно найти изменения за последние 2 часа:


sudo find /etc -type f -mmin -120 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort


Если хочешь сразу посмотреть самые свежие изменения сверху:


sudo find /etc -type f -mmin -1440 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort -r

🛡️ Awesome Privacy — это список лучших инструментов, ресурсов и практик для защиты вашей конфиденциальности и минимизации цифрового следа.

📦 Категории включают:

- Браузеры и расширения
- Поисковые системы
- Электронная почта и мессенджеры
- VPN и Tor
- Операционные системы
- Удаление трекеров
- Защита мобильных устройств
- Файлы и облачные хранилища
- Обход цензуры
- Удаление аккаунтов
- Полезные гайды и многое другое

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

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

https://github.com/Lissy93/awesome-privacy

⚡️ Почему обычный `min(a, b)` в C может вернуть неожиданный результат

В C есть неприятная ловушка: если сравнивать signed и unsigned значения, компилятор может привести оба числа к unsigned.

И тогда отрицательное число внезапно превращается в огромное положительное.

Пример:


#define min(a, b) ((a) < (b) ? (a) : (b))

int x = -1;
unsigned int y = 10;

printf("%u\n", min(x, y));


Интуитивно кажется, что минимум — -1.

Но при сравнении x < y значение -1 приводится к unsigned и становится очень большим числом. В итоге сравнение работает уже не так, как ожидает разработчик.

Именно поэтому в Linux kernel макрос min() устроен хитрее. Он не просто сравнивает два значения, а сначала делает type check:


#define min(x, y) ({ \
typeof(x) _x = (x); \
typeof(y) _y = (y); \
(void) (&_x == &_y); \
_x < _y ? _x : _y; \
})


Ключевая строка здесь:


(void) (&_x == &_y);


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

Это хороший пример системного C-подхода: лучше сломать сборку сразу, чем получить «правильный» код, который иногда считает неправильно.

В низкоуровневом коде такие мелочи решают очень много. Один неудачный implicit conversion — и проверка размера, индекса или лимита начинает работать против вас.