Темы категории "ВОПРОС/ОТВЕТ"

Вопрос

Как восстановить переписку из резервной копии?

Проблема: Не удаётся получить доступ к истории сообщений после сброса, переустановки мессенджера или повреждения текущей базы данных. Требуется извлечение данных из ранее созданного бэкапа. Причины: 1. Резервная копия зашифрована (end-to-end encryption, AES-256 для WhatsApp/Telegram). 2. Несовместимость формата: iOS-бэкап (iTunes/iCloud) не читается на Android и наоборот. 3. Повреждение файла резервной копии при переносе или хранении. Решение: 1. Для Android (WhatsApp/Telegram): - Местонахождение бэкапа: `/sdcard/WhatsApp/Databases/` (файлы `msgstore-YYYY-MM-DD.1.db.crypt12/14`). - Инструмент: Elcomsoft Phone Breaker (легален для собственных данных) или WhatsApp Viewer (кроссплатформенная утилита). - Команда (Linux/macOS) для расшифровки Crypt14: ```bash python3 wa_crypt_tool.py decrypt -k -i msgstore.db.crypt14 -o msgstore.db ``` Где `` — извлечённый ключ (через рут или бэкап ADB). - Примечание: для восстановления переписки из резервной копии на андроид без рута требуется сброс и восстановление через Google Drive (только с той же учётной записью). 2. Для iOS (iMessages, WhatsApp): - Извлечение из iTunes-бэкапа: iBackup Viewer (бесплатен, работает без джейлбрейка). - Пароль от бэкапа (если установлен) сбрасывается через Elcomsoft Phone Password Breaker (брутфорс слабых паролей). - Путь к нужной базе: `3d0d7e5fb2ce288813306e4d4636395e047a3d28` (для iMessage). 3. Универсальный метод (любая платформа): - Autopsy (Sleuth Kit) — анализ дампов разделов (требует root/jailbreak). - Magnet AXIOM (платная, демо-версия существует) — автоматическое извлечение и парсинг бэкапов более 200 приложений. - Важно: если вы ищете как извлечь историю сообщений из бэкапа телефона, используйте FTK Imager для создания образа раздела `userdata` и последующего анализа через `sqlite3`. Юридические ограничения (РФ): - Вмешательство в чужие бэкапы без согласия владельца — ст. 138 УК РФ («Нарушение тайны переписки»). - Все методы применимы только к собственным устройствам и данным. Для корпоративной форензики — с письменного разрешения юрлица.

Вопрос

Как проверить, подлинный ли документ или скан?

Проблема: Необходимо установить подлинность предоставленного документа или его скана — выявить признаки монтажа, редактирования или подмены исходного файла. Причины: - Подделка в графическом редакторе (Photoshop, GIMP) — вставка фрагментов, изменение реквизитов, текста. - Сканирование поддельного бумажного носителя, созданного методом цветной струйной печати. - Изменение метаданных или подмена содержимого в многостраничном PDF (например, замена одной страницы). - Генерация полностью синтетического документа через нейросети (GAN, Stable Diffusion) или текстовые редакторы. Решение (легальные методы без нарушения законодательства РФ): ### 1. Визуальная экспертиза и анализ атрибутов файла (первичная проверка подлинности скан-копии документа) - Проверьте DPI и разрешение. Откройте свойства файла (Windows: ПКМ → Свойства → Подробно). Для реального скана характерно значение 200–300 DPI (или 600). DPI ниже 150 или нестандартные значения (72, 96) — признак экспорта из графического редактора, а не сканера. - Анализируйте тени и градиенты. В Photoshop часто остаются следы: неравномерный шум, резкие границы вокруг вставленных объектов, отсутствие естественного шума бумаги на вставке. - Проверьте шрифты и выравнивание. Подделки часто содержат мелкий текст с разным межбуквенным расстоянием (кернингом), «съехавшие» строки или несоответствие шрифта стандартам (например, в паспортах РФ используется шрифт ISOCPEUR). - Используйте увеличение (Zoom 400-800%). Ищите артефакты JPEG-сжатия, крапинки (dithering) на однотонных заливках — признаки скриншота или повторного сохранения. ### 2. Анализ метаданных (EXIF, XMP, PDF) для проверки подлинности электронного документа - Для изображений (JPG, PNG, TIFF): `exiftool -a -u suspect_doc.png` Ищите теги: - `Software` — Photoshop, Adobe Illustrator, Paint.NET → признак редактирования. - `CreateDate` / `ModifyDate` — если даты не совпадают или модификация позже даты документа. - `ImageDescription` — может содержать имя автора или программы. - `History` (XMP) — цепочка изменений (Photoshop History). - Для PDF: `pdfid.py suspect.pdf` (утилита Didier Stevens) — проверка на скрытые действия (JavaScript, OpenAction, EmbeddedFiles). `pdf-parser.py suspect.pdf` — извлечение и анализ всех объектов, поиск встроенных изображений, не соответствующих структуре (например, 5 изображений в 2-страничном документе). Пример команды для выявления скрытого текста в PDF: `python pdf-parser.py -s /Font suspect.pdf` — поиск нестандартных шрифтовых подстановок. ### 3. Форензика JPEG-артефактов (ELA — Error Level Analysis) Метод выявляет области, добавленные позже (вставки), по разности в уровнях ошибок сжатия. Инструмент: `forensically Beta` (онлайн, без регистрации) или скрипт Python: ```python from PIL import Image, ImageChops, ImageFilter import sys input_image = sys.argv[1] im = Image.open(input_image) im.save('/tmp/temp_ela.jpg', 'JPEG', quality=95) ela_im = Image.open('/tmp/temp_ela.jpg') diff = ImageChops.difference(im, ela_im) diff = diff.filter(ImageFilter.GaussianBlur(radius=2)) diff.save('ela_output.png') ``` Области с яркими пикселями (отличие от фона) — вероятные места редактирования. ### 4. Проверка шумов датчика сканера (Sensor Noise Pattern) Для профессиональной проверки подлинности скана документа: Сравните равномерный шум фона (нулевая точка, белая область) с эталонным шумом конкретной модели сканера. Любая вставка будет иметь другой рисунок шума. Инструмент (закрытый код, не для нарушений): PRNU analysis через `python prnu` (библиотека). Легально используется только на собственных эталонных сканах, полученных законно. ### 5. Криминалистическая экспертиза бумажного носителя (если есть физический документ) - Ультрафиолетовая лампа (365 нм). Настоящий документ (паспорт, диплом) содержит защитные волокна, реагирующие свечением. Поддельная струйная печать даёт яркую фиолетовую засветку всей поверхности. - Тактильный анализ. Используйте пальцы и лупу: на реальном документе текстура печати глубокая (trapping, рельеф), на струйной — плоская, глянцевая. - Микроскоп (80-200х). Растровые точки струйного принтера имеют характерную «кляксу» (bleeding), в отличие от четких листовых растров офсета. ### Итоговая последовательность действий для проверки подлинности документа: 1. Запросить оригинал файла без перекомпрессии (RAW, TIFF, не JPEG). 2. Запустить `exiftool` на изображение и PDF — отсечь 80% подделок с редактированием. 3. Выполнить ELA-анализ (Python или онлайн) — найти вставки. 4. При физическом документе — УФ-лампа + микроскоп. 5. При высоких рисках — обратиться в аккредитованную лабораторию судебной экспертизы (не нарушая тайну следствия, если это ваше дело). Важно: Ни один метод не даёт 100% гарантии без доступа к эталонному образцу сканера и бумаги (например, госконтракт). Указанные техники легальны, не требуют инвазивного доступа и не нарушают законодательство РФ.

Вопрос

Как восстановить файлы после переустановки системы?

Проблема: После переустановки ОС данные на системном разделе (C:\) недоступны. Файлы кажутся потерянными, но физически сектора диска не затерты мгновенно. Причины: - Форматирование или перезапись разделов установщиком Windows/Linux. - Новые данные (файлы ОС) частично перезаписали старые кластеры, где хранились ваши файлы. - Файлы не удалены, а помечены как «свободное место» — структура файловой системы (MFT для NTFS, суперблоки для ext4) повреждена или перезаписана частично. Решение (пошагово, без права на ошибку): 1. Немедленное действие: Отключите компьютер. Не загружайте переустановленную систему с установочного диска. Любая запись (логи, кэш браузера, установка драйверов) уменьшает шансы на восстановление остатков данных. 2. Загрузка с Live-CD/USB (дистрибутив Linux): Загрузитесь с Ubuntu USB. Не монтируйте раздел автоматически — откройте терминал. 3. Создание посекторной копии (наиболее надежно для восстановления битых файлов после переустановки системы): ```bash sudo dd if=/dev/sda1 of=/mnt/external_drive/disk_copy.img bs=64K status=progress ``` Работать ТОЛЬКО с копией, а не с диском. 4. Анализ сканов на копии: - PhotoRec (CGSecurity) — восстановление по сигнатурам (фото, документы, архивы). Запускать на образе: ```bash sudo photorec /mnt/external_drive/disk_copy.img ``` - TestDisk — восстановление структуры разделов, если таблица разделов затерта. 5. Использование DMDE (оптимальный вариант для NTFS после переустановки): - Запустите DMDE с Live-CD. - Откройте образ диска → выберите «Полный скан». - В результатах ищите папки с именем `$Root`, `$Recycle.Bin`, `$User` — это остатки старой структуры. - Восстановите только критически важные файлы (в DMDE это бесплатно для мелких файлов). Критическое предупреждение: - Шанс восстановления падает с каждым часом работы переустановленной системы. Если прошло >2 дней, 90% данных перезаписаны. - Не используйте R-Studio, Recuva на активной системе — они пишут временные файлы на восстанавливаемый раздел. - Для профессионального восстановления (сложные битые файлы) — обращайтесь в лаборатории, работающие с аппаратными дубликаторами (PC-3000).

Вопрос

Как узнать, кто заходил в соцсеть с моего телефона?

Проблема: Подозрение на несанкционированный доступ к вашему аккаунту соцсети с вашего же устройства. Необходимо установить факт и источник доступа. Причины: 1. Фишинг или вредоносное ПО на телефоне (кейлоггер, стилер cookie). 2. Компрометация сессии (перехват cookie при подключении к публичным Wi-Fi). 3. Уязвимость в браузере/ОС (редко, но актуально для устаревших версий Android/iOS). 4. Реальный физический доступ к разблокированному устройству (друг/родственник) с последующим запуском приложения. Решение (только легальные методы, ч. 272-273 УК РФ не нарушаем): 1. Проверка истории входов в соцсеть на телефоне (основной метод). ВКонтакте: Настройки → Безопасность → История активности. Ищите IP, тип устройства (iOS/Android/Web) и метку времени. Несовпадение модели телефона с Вашей — признак чужого доступа. Telegram: Настройки → Конфиденциальность → Активные сессии. Завершите все, кроме текущей. Instagram/Facebook: Настройки → Центр аккаунтов → Пароль и безопасность → Где вы вошли. Одноклассники: Настройки → Мои действия → История входов. 2. Анализ логов авторизации Google/Apple ID (поможет при входе через SSO). Android: myaccount.google.com → Безопасность → Ваши устройства и Недавние действия по безопасности. iPhone: appleid.apple.com → Вход и безопасность → Статус учетной записи → История входов. 3. Локализация по IP из истории входов (ограниченно). Скопируйте IP-адрес из логов соцсети. Через whois-сервис (например, 2ip.ru) определите провайдера и город. Совпадение с вашим домашним Wi-Fi — исключает удаленный доступ, но не локальный. 4. Проверка на наличие программ для слежки на телефоне без рут-прав (Android). Зайдите в Настройки → Приложения → Все приложения. Ищите приложения с пустыми иконками, странными названиями (типа `com.monitor.xxx`), или те, у которых запрошено разрешение "Поверх других окон". Пример команд (терминал Android, если есть adb): ``` adb shell dumpsys usagestats ``` Выдаст список приложений со временем последнего запуска. 5. Экстренное завершение всех сессий. В настройках безопасности соцсети нажмите "Завершить все сессии" (или "Выйти на всех устройствах"). После этого немедленно смените пароль на сложный (30+ символов, через менеджер паролей). Включите двухфакторную аутентификацию (2FA) — это 95% защиты. Важно: Стандартными средствами ОС (без рута/jailbreak и установки сомнительного ПО) посмотреть полный лог открытия приложений и переходов внутри соцсети невозможно. Инструменты типа Dr.Fone или iMobie могут читать удаленные данные, но не логи активных сессий. Единственный достоверный источник — серверный лог самой соцсети (п.1).

Вопрос

Как проверить, редактировали ли таблицу после сохранения?

Проблема: Необходимо достоверно определить, вносились ли изменения в таблицу (Excel, SQL, CSV) после её последнего сохранения, без доверия к встроенным датам файловой системы (которые легко подделываются). Причины: 1. Подмена метаданных: Дата «Изменено» в свойствах файла может быть изменена через `SetFileTime` или атрибуты. 2. Необновление даты: Редактирование без сохранения не меняет дату файла. 3. Ложный след: Восстановление предыдущих версий (Shadow Copy) может перемешать временные метки. Решение (3 уровня глубины): 1. Базовый — хэш-контроль (для контрольных точек) - Если есть эталонный хэш (MD5/SHA256) файла сразу после сохранения, вычислите текущий: ```cmd certutil -hashfile "C:\table.xlsx" SHA256 ``` - Ограничение: Работает только при заранее взятом хэше. Не покажет факт неавторизованного редактирования, если эталона нет. 2. Продвинутый — метаданные файла таблицы в контексте версий - Проверка версий файла (Windows Previous Versions): - Клик ПКМ по файлу → «Свойства» → «Предыдущие версии». - Если версии отличаются по размеру/дате — минимум одно сохранение после даты эталона. Не говорит о редактировании — только о факте записи. - Анализ метаданных OOXML (для .xlsx/.xlsm): - Распакуйте `file.xlsx` (это ZIP) и проверьте `docProps/core.xml`: ```xml 2024-03-15T10:00:00Z ``` - Если `modified` > даты эталонного сохранения — прямое доказательство редактирования. Дата подделывается только через распаковку и правку XML. 3. Форензика — анализ логов файловой системы ($MFT/JumpList) - NTFS $MFT (Master File Table): - Используйте `MFT Explorer` или `$MFT` парсер. - Сравните атрибуты `$STANDARD_INFORMATION` (SI) и `$FILE_NAME` (FN). - Признак редактирования: Время `$SI.Modified` — время последнего изменения данных. Если `SI.Modified` > `FN.Creation` — изменение было. - Команда извлечения (только для экспертов, читать блок RAW): ```cmd fsutil mft readFile C:\ 0x1C0 > mft_dump.txt (пример для ручного разбора) ``` - Jump Lists (Windows 10/11): Содержат историю открытия и сохранения конкретных файлов приложением (Excel, Notepad++). Анализ через `JLECmd.exe` или вручную `%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\`. - Результат: Даты последнего сохранения в Excel — если дата в Jump List позднее эталона, файл редактировали. Итоговая рекомендация для OSINT/форензики: - Наиболее надёжный метод без эталонного хэша — сопоставление атрибутов $MFT (SI vs FN) и анализ `docProps/core.xml` внутри OOXML-контейнера. - Для баз данных (SQLite/MySQL) — проверка WAL-журнала (Write-Ahead Log) — если размер журнала >0 при закрытой БД — были изменения после последнего сохранения (CHECKPOINT).

Вопрос

Как восстановить данные с телефона после падения в воду?

### Проблема Телефон не включается после падения в воду, данные недоступны. Риск потери информации из-за короткого замыкания и коррозии контактов. ### Причины 1. Попадание воды на материнскую плату → электролиз под напряжением → окисление контактов и дорожек. 2. Влага в разъемах (USB, SIM, карта памяти) → коррозия контактов → потеря связи с накопителем. 3. Если устройство было включено: короткое замыкание цепей питания → выход из строя контроллера NAND или eMMC. 4. Повреждение аккумулятора (вздутие, утечка) → риск воспламенения при попытке зарядки. ### Решение (легальные методы, только для собственного устройства или с письменного согласия владельца) #### Этап 1. Немедленные действия (до высыхания) - НЕ включать! Отключить питание (вынуть батарею, если съемная). - Не заряжать, не подключать к ПК — подача напряжения ускоряет коррозию. - Извлечь SIM и карту памяти — их данные часто сохраняются. Просушить карту памяти отдельно (силикагель, рис на 48 часов). #### Этап 2. Сушка и очистка - Разобрать телефон (открутить все винты, снять экран, отделить плату). - Промыть плату изопропиловым спиртом (99%) — он вытесняет воду и не проводит ток. - Ультразвуковая ванна с изопропанолом (5-10 мин, 40 кГц) — удаляет солевые отложения. - Сушка: 24-48 часов при 40-50°C (не СВЧ, не фен без контроля температуры!). Идеально — сушильный шкаф или силикагель. #### Этап 3. Диагностика и восстановление данных с телефона после падения в воду - Если плата не повреждена, но не включается: заменить аккумулятор, проверить тестером напряжение на контактах питания. Подключить через USB-тестер (ток потребления

Вопрос

Как увидеть, какие устройства подключались к ПК?

Вот структурированный ответ для ForensicAnvil.ru, без воды, по запросу «как увидеть, какие устройства подключались к ПК». ### Проблема: Необходимо определить, какие USB-устройства и внешние накопители когда-либо подключались к данному компьютеру Обычно требуется при расследовании инцидентов: выявление факта копирования данных на флешку, определение неизвестного устройства (мышь/клавиатура) или поиск следов подключения мобильного телефона. ### Причины: Сложность обнаружения из-за очистки журналов Пользователь мог удалить историю подключений через стандартный интерфейс. Реестр Windows или журналы событий могли быть частично перезаписаны. Требуется анализ скрытых ключей реестра и логов Plug and Play. ### Решение: Извлечение истории с помощью реестра и журналов событий Используйте только встроенные средства Windows или легальное ПО (Sysinternals, NirSoft). 1. Просмотр истории подключений USB-накопителей через реестр (USBSTOR) Самый надежный способ. Откройте `regedit` от имени Администратора. Путь: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR` Что смотреть: Каждый GUID (например, `Disk&Ven_SanDisk&Prod_Ultra&Rev_1.00`) — это уникальное устройство, подключавшееся к ПК. Дата первого/последнего подключения: Перейдите в ветку `...\Properties\{83da6326-97a6-4088-9453-a1923f573b29}` (0064 — первое подключение, 0066 — последнее). Декодируйте значение `0064` (FILETIME) с помощью PowerShell: ```powershell [datetime]::FromFileTime((Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\DISK&VEN_SANDISK&PROD_ULTRA&REV_1.00\4&1a2b3c4d&0\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0064").'(default)') ``` 2. Определение устройств, подключавшихся к компьютеру, через журналы событий (Event Viewer) Используйте для поиска конкретных дат, когда было вставлено устройство. Путь: `Приложения и службы > Microsoft > Windows > Partition > Diagnostic` Event ID 1006: Фиксирует подключение нового диска (например, флешки). Что смотреть: Вкладка «Подробно» -> `FriendlyName` (имя накопителя) и `VolumeSize` (объем). Путь: `Приложения и службы > Microsoft > Windows > DriverFrameworks-UserMode > Operational` Event ID 2003: Логирует подключение любого USB-устройства (клавиатура, веб-камера, модем). Event ID 2100: Логирует отключение. 3. Программное извлечение (легальные утилиты) Если нужно выгрузить историю в отчет без ручного копания в реестре: USBDeview (NirSoft): Показывает все USB-устройства, подключавшиеся к системе, с датами, серийными номерами и меткой «Отключено/Подключено». Не требует установки. PowerShell (встроенный): Экспорт ключей реестра в CSV. ```powershell Get-ChildItem -Path "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR" -Recurse | ForEach-Object { $_.PSPath } | Out-File -FilePath C:\usb_history.txt ``` SEO-вкрапление: Для точного просмотра истории подключений USB и определения устройств, подключавшихся к компьютеру, ключевым является анализ ветки USBSTOR. Если вы хотите увидеть, какие устройства подключались к ПК в прошлом, не полагайтесь на визуальную историю в панели управления — используйте реестр или журналы Microsoft-Windows-Partition/Diagnostic. Важно: Анализ должен проводиться на выключенной системе или смонтированном образе диска (для forensic-экспертизы). Манипуляции с реестром могут повлиять на работу системы — работайте с копией реестра или read-only.

Вопрос

Как проверить, с какого IP заходили в аккаунт?

### Проблема Вы подозреваете, что в ваш аккаунт (почта, соцсети, мессенджер) заходили с незнакомого IP-адреса. Необходимо извлечь и проанализировать историю входов в аккаунт по IP для выявления утечки или взлома. ### Причины - Кража пароля через фишинг или утечку БД. - Активная сессия на чужом устройстве (например, общественный ПК, VPN с вредоносным узлом). - Бездействие пользователя: не отозваны сессии, не включена 2FA. ### Решение Пошаговая инструкция по получению логов авторизации в аккаунте для наиболее популярных сервисов. #### 1. Google (Gmail, YouTube) - Перейти: `myaccount.google.com` → Безопасность → Секция «Ваши устройства» → Управление всеми устройствами. - Нажать на сессию → отобразится IP и время. Для экспорта: Журнал активности → скачать в JSON (там полные метаданные, включая User-Agent и IP). - Альтернатива: `myaccount.google.com/data-and-privacy` → Скачать данные → выбрать только «Сведения об устройствах и действиях». Это стандартный метод анализа логов безопасности Microsoft/Google. #### 2. Яндекс (Почта, Диск) - `passport.yandex.ru` → История входов (или Безопасность → Последние действия). - Время, IP, регион. Клик по записи — User-Agent. Кнопка «Завершить все сеансы». - Для глубокого OSINT-анализа по IP-адресу используйте `whois` или `ipinfo.io` прямо в браузере. #### 3. VK / Одноклассники - VK: Настройки → Безопасность → Показать историю активных сессий. - OK: Настройки → Безопасность → История входов. - Сохраняет IP, браузер, устройство. Есть отметка «мобильное приложение» и GPS-координаты (если дано разрешение). #### 4. Discord - `discord.com/settings/Authorized Apps` → Пролистать вниз → Смотреть историю входов. - IP, метка местоположения (по GeoIP), Device Fingerprint. - Команда `/sessions list` (бот Dyno или в терминале приложения) не покажет IP, только сессии — это неполноценный мониторинг входов через лог активности. #### 5. Microsoft (Outlook, Azure) - `account.microsoft.com/security` → Просмотр активности входа. - Данные: IP, приложение, успех/неудача, крайне полезно для расследования инцидентов форензики. - SSH/API: `Get-AzureADAuditSignInLogs` (PowerShell, для глобальных администраторов). #### 6. Экспорт через IMAP/POP3 (для собственного ПО) - Проверить `Received`-цепочку письма. Алгоритм: ```bash # Найти последний внешний IP перед вашим MTA curl -X VERP -T email.eml https://mxtoolbox.com/ | grep "Received: from" ``` - Для Telegram: `@userinfobot` (выдает IP пользователя, если он ввел /start — но это не история входов, а разовая проверка). ### Заключительный совет по безопасности - Включите 2FA (TOTP, а не SMS) — это снижает вероятность несанкционированного доступа по украденному IP. - После анализа журнала активности входа — смените пароль и отзовите все устройства. - Используйте VPN только с адресом, который не совпадает с вашим регионом входа (если вы в Москве, а лог из Питера — подозрительно). Легальность: все данные получаются через штатные интерфейсы сервисов (запрос данных самого пользователя). Статья 138 УК РФ не применима при анализе собственных логов.

Вопрос

Как восстановить файлы, если программа вылетает при открытии?

Проблема: Утилита восстановления данных (R-Studio, GetDataBack, DMDE) аварийно завершает работу при попытке открыть том или запустить сканирование. Причины: 1. Критическое повреждение файловой системы (RAW/bad boot sector): Драйвер ФС вызывает Access Violation при парсинге $MFT/FAT-таблицы. 2. Дефекты носителя (Read/Write Error): Программа пытается считать сбойный сектор, ядро ОС «вешает» вызов — таймаут, крах. 3. Проблема с виртуальной памятью (логин-сессия): Огромный образ или битый диск создает своп-файл на нестабильном винчестере. 4. Отсутствие прав администратора или конфликт драйвера низкого уровня. Решение (пошагово, без GUI, если возможно): 1. Обход краха утилиты: - Используй консольную версию той же программы (например, `R-Studio CLI`, `dmde.exe /L`). - Загрузись с Live USB (Linux LiveCD — Ubuntu/Debian) и восстановление с помощью `ddrescue` + `testdisk/photorec`. Вылеты при открытии программы Windows не повлияют. 2. Диагностика и изоляция дефектов (восстановление файлов с поврежденного диска): - Сначала создай посекторную копию диска в безопасную среду: ```bash # Linux sudo dcfldd if=/dev/sdb of=/mnt/backup/image.dd bs=512 conv=noerror,sync status=progress ``` - Затем «реконструкция» образа через тестирование поверхности. Если крах вызван битым сектором — работа только с образом с файлом лога ошибок. 3. Ремонт файловой системы без открытия тома: - Запусти `chkdsk X: /f /r` (только если не на диске с проблемой — риск). Лучше — `fsck` в Linux на отмонтированной ФС. - Используй `TestDisk` (режим Quick/Deep Scan) для перестроения таблицы разделов. Запускай из командной строки (Win/Linux) — краш утилит восстановления обычно обходится. 4. Действия в случае, когда программа вылетает при открытии файловой системы: - В DMDE: диалог выбора тома -> пропустить «Авто-детект» -> «Выбрать логический диск» -> Прочитать MBR/GPT отдельно (Ctrl+D). Если получение структуры падает — диск умер аппаратно. - Открывай образ в `HxD` (hex-редактор) — если сам редактор не падает, проблема в драйвере ФС, а не в носителе. 5. Аппаратное решение (если софт валится из-за bad blockов): - Подключи проблемный диск через USB-мост. Используй `Victoria for Windows` или `HDD Regenerator` для «обхода» уцелевших секторов (кратковременное отключение таймаутов SATA). Только если данные не критичны. Ключевой принцип: Никогда не запускай утилиту восстановления напрямую на умирающем диске — только на его образе. Сбой при открытии программы — 90% аппаратных дефектов поверхности.

Вопрос

Как узнать, меняли ли время на компьютере?

### Проблема Факт изменения времени — весомый аргумент в цифровой криминалистике: позволяет выявить сокрытие следов, манипуляции с логами или алиби. Задача — доказать, что системные часы были переведены вручную или с помощью стороннего ПО. ### Причины 1. Смена часового пояса — легитимно, но редко. 2. Ручная правка через интерфейс ОС или утилиты (`date`, `timedatectl`). 3. Синхронизация с NTP (ошибка сервера, подмена). 4. Сброс CMOS-памяти (разряд батарейки, отключение питания). 5. Злонамеренные действия — подмена времени для обхода лицензий, фальсификации действий в логах, алиби. ### Решение Проверка фальсификации системного времени на компьютере требует анализа журналов Windows Event Viewer (ID 1, 4616) или syslog на Linux. #### Windows 1. Откройте Event Viewer → Windows Logs → System. 2. Фильтр по ID события 1 (изменение времени) или 4616 (системное время изменено). 3. Анализ: записи содержат предыдущее и новое время, причину (ProcessId, User). Если `TimeChange` не совпадает с шагом синхронизации NTP — ручное вмешательство. Анализ событий изменения системных часов Windows через PowerShell: ```powershell Get-WinEvent -FilterHashTable @{LogName='System'; ID=1} | Format-List TimeCreated, Message ``` Ищите `Reason: Manual Time Change` или `ProcessId: 4` (System) vs другой PID. #### Linux/Unix Для инструментов для выявления подмены времени в цифровой криминалистике: - Журнал `systemd-timesync` или `chronyd` (см. `/var/log/messages`). - Команда `last reboot -F` — покажет изменения uptime, косвенно указывающие на сброс. Инструментально: ```bash grep "timedatectl" /var/log/syslog grep "time set by" /var/log/auth.log ``` Ручная смена через `date` оставит след в `.bash_history` или `auditd` (если включен). #### Дополнительные признаки - Множество записей с одинаковым временем (скоростное изменение). - Расхождение `LastBootUpTime` и времени создания файлов в теневых копиях (Volume Shadow Copy). - Для глубокой проверки — сравнение меток времени файловой системы (`MACE` атрибуты) с логами сторонних сервисов (DNS, прокси). Если время файла раньше/позже на 5+ минут, а лог изменения отсутствует — подозрение на правку. Резюме: Используйте проверку журналов событий изменения системных часов в связке с `Sysmon` (Event ID 1, 3) и `auditd` на Linux. Только это даст однозначный ответ в рамках легальных методов цифровой криминалистики.

Вопрос

Как восстановить сообщения после обновления приложения?

Проблема: После обновления мессенджера (Telegram, WhatsApp, Viber) или соцсети (VK, OK) исчезла история переписки. Визуально чаты пусты, сообщения не загружаются. Причины: 1. Сброс локальной БД: Обновление перезаписывает структуру базы данных (SQLite). Старая БД блокируется, новая создается пустой. 2. Смена ключа шифрования: В end-to-end мессенджерах (Signal, Telegram Secret Chat) при обновлении алгоритма шифрования старые локальные ключи становятся невалидными, сообщения не дешифруются. 3. Миграция ошибок: Сбой при конвертации схемы БД из старой версии в новую (несовместимость типов данных, нарушение индексов). 4. Синхронизация облака: При входе после обновления клиент по ошибке перезаписывает облачную историю пустой локальной копией. Решение: 1. Восстановление сообщений из резервной копии (до обновления) iOS (iTunes/Finder): Отключи автоматическую синхронизацию. Подключи устройство к ПК. `Finder` → устройство → «Восстановить из резервной копии». Выбирай бекап, созданный до даты обновления приложения. Важно: Сообщения из iCloud не перезаписываются, если они не были загружены обратно на устройство. Android (Google Drive локально): Удали приложение, установи версию до обновления (APK Mirror). Открой приложение, выбери «Восстановить из резервной копии Google Drive». Если такого варианта нет: `adb backup -f backup.ab -noapk` (если ранее делал бекап) — восстановить через `dd if=backup.ab | openssl zlib -d > backup.tar`. Windows/Mac: Полный дамп папки `%AppData%\Local\[Appname]\` или `~/Library/Application Support/[Appname]/`. Замени папку на сохраненную копию. 2. Извлечение данных из старой базы (если резервной копии нет) Локализация файлов: Android (root): `/data/data/[пакет приложения]/databases/` — файлы `.db`, `.wal`, `.shm`. iOS (без jailbreak): только через полный дамп файловой системы (iMazing, EaseUS MobiSaver — извлечение из iTunes-бекапа). Desktop: `%AppData%/Telegram Desktop/tdata/` — папки `user_data`, `dumps`. Извлечение: Для Android: `adb shell "cp -r /data/data/org.telegram.messenger/databases/ /sdcard/backup_db/"`, затем `adb pull /sdcard/backup_db/`. Анализ: `sqlite3 databases.db .dump` — поиск таблиц `messages`, `chat_history`, `conversation`. Восстановление (пример для Telegram на ПК): Найди файл `user_data` и замени его в папке `%AppData%/Telegram Desktop/tdata/` после закрытия приложения. Запусти заново — история будет пересканирована. 3. Восстановление сообщений через файлы кэша/медиа WhatsApp: Файлы `.db.crypt12` (зашифрованные). Дешифровка — только с ключом из `msgstore.db.crypt12.key` (находится в `misc/`). Если ключ устарел — увы. Telegram (облачные чаты): Приложение автоматически загрузит историю с сервера после восстановления доступа к файлу `key_datas` (в `tdata`). Не удаляй папку `tdata`. Команды (Windows, при закрытом приложении): 1. Переход в папку: `cd %AppData%\Telegram Desktop\tdata\user_data` 2. Замена: `xcopy /E /Y "D:\backup\user_data" "C:\Users\%USERNAME%\AppData\Roaming\Telegram Desktop\tdata\user_data"` 3. Удаление кэша: `del /F /Q "C:\Users\%USERNAME%\AppData\Roaming\Telegram Desktop\tdata\cache"` Легальность: Действия проводятся только с собственных устройств и файлов пользователя. Извлечение данных третьих лиц (не ваших) — нарушение ст. 272 УК РФ (Неправомерный доступ к компьютерной информации). Убедись, что бекап создан заранее — без него шансы < 15% при смене ключа шифрования.

Вопрос

Как увидеть, какие приложения устанавливались недавно?

Проблема: Необходимо оперативно выявить факты установки нового ПО на Windows/Android/macOS без доступа к учетной записи магазина или встроенному логу изменений системы. Причины: - Установка зловредного ПО без ведома пользователя (malware, PUP). - Несанкционированные действия сотрудника или ребенка. - Сокрытие следов заражения самим вредоносным ПО (чистка логов). - Необходимость инвентаризации софта при форензике. Решение (Windows 10/11): 1. Просмотр истории установки через PowerShell (надежнее, чем GUI): ```powershell Get-WinEvent -FilterHashtable @{LogName='Setup'; ProviderName='Microsoft-Windows-SetupCl'}| Where-Object {$_.Id -eq 2001} | Format-Table TimeCreated, Message -AutoSize ``` Или через реестр (менее надежно, чистится): ``` HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall (для 32-битных) ``` Смотрите поле `InstallDate`. Важно: журнал Setup, как правило, не чистится штатно — это основной артефакт для проверки истории установки приложений на Windows. 2. Анализ журнала событий установщика Windows (MsiInstaller): ```powershell Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'} | Where-Object {$_.Id -eq 1033} | Format-Table TimeCreated, Message -AutoSize ``` 3. Prefetch-файлы (.pf) — косвенный признак: Путь: `C:\Windows\Prefetch` Дата изменения файла `.pf` может указывать на первый запуск, что коррелирует с установкой. Однако это не гарантия того, что приложение устанавливалось именно в этот момент (можно запустить с флешки). Решение (Android без root — ограничено): - Google Play: «Google Play» → «Управление приложениями и устройством» → «Управление» → сортировать по дате установки. Это список недавно добавленных приложений Android из магазина. - PackageManager (ADB): Дает список всех пакетов с датой первого запуска (не установки), но не показывает историю удалений. ```bash adb shell pm list packages -f --show-versioncode --user 0 adb shell dumpsys package | grep “firstInstallTime” ``` Важно: Ни один из методов (кроме анализа журнала Setup на Windows) не гарантирует 100% точности при активной чистке следов. Для глубокого анализа логов установщика ПО** в рамках форензики используйте инструменты типа Registry Explorer или анализ Volume Shadow Copy.

Вопрос

Как восстановить данные с карты памяти, которую не видит ПК?

### Проблема: ПК не видит карту памяти (SD/microSD) — нет отображения в «Моём компьютере», ошибка «Вставьте диск», даже не определяется в диспетчере устройств. Причины: 1. Аппаратные / Физические: Износ контактов, повреждение дорожек microSD, неисправность адаптера/картридера (USB-порт или встроенный слот). Замыкание из-за пыли или влаги в корпусе карты. Несовместимость (класс скорости или объём старше 32 ГБ не поддерживается старым устройством). 2. Логические / Программные: Ошибка файловой системы (FS): структура RAW, повреждена MBR/GPT (загрузочная запись), сбой из-за извлечения без безопасного отключения. Вирусная активность: файлы скрыты, доступ заблокирован. Конфликт драйверов: устаревший или битый драйвер картридера. Проблема с буквой диска: системе не удаётся присвоить букву (конфликт с сетевой папкой). Решение (пошагово, строго по приоритету): Только легальные методы — без использования запрещённых утилит для взлома или форматирования с обходом защиты (не относится к делу). Диагностика проводится без записи на карту, чтобы не перетереть данные перед восстановлением. ### Шаг 1. Аппаратная диагностика (исключить отказ картридера) 1. Проверьте адаптер: если используется microSD->SD, замените его на другой. Наденьте на microSD (вставьте в слот ПК). 2. Используйте другой порт: USB 2.0 на задней панели ПК (прямое питание). 3. Подключите через телефон: вставьте карту в смартфон (не ПК), подключите телефон по USB как накопитель (MTP). Если смартфон видит карту — извлеките данные через него. Если нет — карта физически мертва, восстановление в домашних условиях невозможно (нужен лабораторный data recovery с выпаиванием чипов). ### Шаг 2. Проверка в оснастке «Управление дисками» (diskmgmt.msc) 1. `Win+R` → `diskmgmt.msc`. 2. Если карта отображается как «Не распределена» (RAW или «Нет данных») — переходите к шагу 4. 3. Если есть буква → просто извлеките файлы через проводник. 4. Если диска нет — замените картридер (см. Шаг 1). ### Шаг 3. Восстановление данных с нераспознаваемой карты (логика RAW или ошибка FS) Инструмент: DMDE (бесплатный для 4000 файлов, не требует оплаты для recovery без сохранения — можно просматривать) или R-Studio. Только для чтения (read-only): Запустите DMDE от имени администратора. Выберите физический диск (не том, например «\\\\.\PhysicalDrive2»). Полная проверка/Full Scan: начните сканирование. После завершения — просмотрите папку `$Root` и `$Recycle.Bin`. Восстанавливайте только те файлы, которые визуально определяются (jpg, doc, pdf). Не форматируйте — сначала скопируйте данные на другой носитель. ### Шаг 4. Восстановление доступа без форматирования (если карта не RAW, но не открывается) 1. `Win+R` → `cmd` (от администратора). 2. `chkdsk I: /f` (замените `I` на букву вашей карты). Если ошибка «RAW» или «не удалось» — переходите к Шагу 3 (DMDE). 3. Если `chkdsk` успешен — извлеките данные. ### Шаг 5. Если после восстановления данных карта не нужна Форматирование: `diskpart` → `list disk` → `select disk X` → `clean` → `create partition primary` → `format fs=fat32 quick`. Или через сторонний форматтер (SD Card Formatter). Признак полного отказа: ПК не видит карту ни через телефон, ни через новый адаптер, в `diskmgmt.msc` её нет — деградация чипа памяти. Дальнейшие действия (замена кристалла, химпрочесы) — вне полномочий легального пентестера и решаются только специализированными лабораториями стоимостью от 50 000 руб. ### SEO (long-tail, органично) Не пытайтесь запускать «программу для восстановления файлов с microSD» на повреждённом носителе — это разрушит данные. Частая ошибка: «как восстановить удаленные фото с карты памяти через CMD?» — chkdsk не восстанавливает удалённые файлы, только чинит FS. Используйте DMDE или R-Studio для scan-секторов (поиск сигнатур). Если «компьютер не видит карту памяти в проводнике но видит в управлении дисками» — это типичный признак корректного логического сбоя (требуется chkdsk или сканирование). При восстановлении с карты памяти формата exFAT на ПК с Windows 10/11 проблем не возникает — все драйверы встроены (только версия сборки не менее 1809).

Вопрос

Как узнать, меняли ли настройки приватности в аккаунте?

Проблема: Необходимо установить факт и временную метку изменения параметров приватности (видимость профиля, контента, список друзей) без ведома владельца. Причины: 1. Компрометация сессии (украденные cookie/токены). 2. Установка вредоносного расширения браузера (Auto-fill/Form grabber). 3. Инсайдерский доступ к устройству. 4. Отложенное действие кликера/автоматизации (парсер UI). Решение (по платформам): VK: Как проверить историю изменения настроек приватности в ВК? Войдите в Настройки → Безопасность → История активности. Фильтр: Изменение настроек профиля. VK не логирует конкретное поле — ищите временные корреляции с другими подозрительными действиями (входы с новых IP, сбросы сессий). Параллельно проверьте Приложения → удалите неизвестные, имеющие доступ к настройкам. Telegram: Аудит изменения приватности в мессенджере. Настройки → Конфиденциальность → Активные сеансы. Принудительно завершите незнакомые сессии (кнопка Завершить все). Проверьте Автоматическое удаление сообщений — если включено без вашего ведома, это признак вмешательства. Журнал изменений самих настроек ТГ не ведет — анализ только через девиацию поведения. Instagram (Meta): Логи изменения параметров приватности аккаунта Instagram. Профиль → Настройки → Центр аккаунтов → Ваша информация и разрешения → Активность входа. Сравните даты/устройства. Если настройки были изменены с необычного устройства — факт зафиксирован. Используйте Download Your Information (запрос данных) -> раздел Security and Login — там будут логи Change password и Change email, но не сами privacy settings. Вывод строится по косвенным признакам (сброс пароля -> смена приватности). Почтовые сервисы (Gmail, Yandex, Mail.ru): Проверьте Настройки пересылки и POP/IMAP — часто меняются автоматизацией. В Gmail: Настройки → Фильтры и заблокированные адреса — если там незнакомое правило (удалять/пересылать письма), менявший настройки мог создать его вручную. Облачные сервисы и десктопные клиенты (Windows/Mac): Сбор логов: `wevtutil qe Security /q:"[System[EventID=4728 or EventID=4732 or EventID=4756]]" /c:100 /f:text` (поиск изменений членства в группах — редко, но косвенно). Более эффективно: проверьте Microsoft 365 Audit Log (если акк корпоративный) или Windows Event ID 4663 для папок с файлами настроек (путь к профилю браузера). Для домашнего ПК — без внешнего мониторинга это невозможно. Критическое замечание: Большинство social media платформ не сохраняют детализированные журналы изменения каждой галки приватности (например, "кто видит друзей"). Метод поиска — сравнение текущих значений с бекапом конфигурации (если делали скриншоты ранее) или анализ логов входа/смены пароля как триггеров. Для полной цепочки событий требуется настройка SIEM-системы (Splunk, ELK) до инцидента — постфактум* это не восстановить.

Вопрос

Как восстановить переписку, если сменил устройство?

Проблема: Утеряна история сообщений после перехода на новое устройство. Критическая необходимость восстановления переписки после смены смартфона без облачного бекапа. Причины: 1. Отсутствие предварительного резервного копирования на старом устройстве (Google Drive, iCloud, локальный дамп). 2. Использование сквозного шифрования (E2EE) в мессенджерах (WhatsApp, Signal) — ключи уникальны для устройства, сервер не хранит историю. 3. Принудительная привязка к SIM/номеру в Telegram: при перевыпуске сим-карты старая сессия инвалидируется. Решение (легальные методы, без взлома): 1. Извлечение данных чатов — резервная копия мессенджера со старого устройства (если оно физически доступно): - Android (WhatsApp): `adb backup -f backup.ab -noapk com.whatsapp` → инструментом `abe.jar` распаковать в `.tar` → извлечь `msgstore.db` и `wa.db`. Формат базы SQLite — чтение через DB Browser. - iOS (не jailbreak): Только iCloud/локальный бекап iTunes. Физическое копирование из песочницы приложения без джейлбрейка невозможно (закон РФ, ст. 273 УК не нарушаем — штатного доступа нет). Как восстановить переписку после смены смартфона на iOS — только через официальный iCloud Restore. - Telegram Desktop: Скопировать папку `AppData\Local\Telegram Desktop\tdata` со старого ПК. На новом устройстве — указать ту же папку до авторизации. Не работает, если привязан облачный пароль. 2. Перенос истории сообщений через экспорт (если приложение поддерживает): - WhatsApp: Настройки → Чаты → Экспорт чата → Email/Telegram. Формат `.txt` — теряются медиа. - Viber: В настройках «Перенос сообщений» — для смены Android→Android (одноразовый QR-код). 3. Восстановление из облачных сервисов (только при включенном бекапе до смены): - Google Drive (WhatsApp Android): При первой установке на новом устройстве — предложит восстановить бекап. Важно: бекап создается не чаще 1 раза в 7 дней. - iCloud (WhatsApp iOS): Восстановление только из копии iCloud после сброса до заводских настроек или при установке на новый iPhone. - Telegram: Данные хранятся на серверах, история привязана к аккаунту. После входа на новом устройстве — вся переписка доступна (кроме локальных медиа). 4. Форензика (безнадежно, но для полноты): - Если устройство утеряно — извлечение дампа NAND через JTAG/чип-офф — незаконно в РФ без экспертной лицензии. Физически невозможно в бытовых условиях. Итог: - Единственный рабочий способ без нарушения закона — предварительно включенный облачный бекап (Google Drive/iCloud). - Если бекапа нет, а старый девайс исправен — извлечение через `adb backup` (Android) или копия `tdata` (Telegram Desktop). - Невозможно: восстановить историю WhatsApp с поврежденного телефона или при смене номера без переноса SIM → данные необратимо утеряны. SEO-фразы: восстановление переписки после смены смартфона, перенос истории сообщений с устройства на устройство, как сохранить чаты при замене телефона, извлечение базы данных WhatsApp из бэкапа.

Вопрос

Как проверить, подделывали ли подпись в документе?

### Проблема Определение факта подделки подписи в документе — требуется подтверждение её подлинности или выявление признаков фальсификации. ### Причины - Визуальная имитация — копирование на просвет, перерисовка, сканирование и печать. - Техническая подделка — использование графических редакторов для наложения подписи на скан. - Цифровая фальсификация — подстановка чужой электронной подписи (ЭП) либо модификация подписанного файла без нарушения валидности подписи (например, атака на хэш). - Аппаратная подделка — подписи, выполненные на планшетах или с помощью плоттера с последующей распечаткой. ### Решение Для рукописной подписи на бумаге / скане: 1. Визуальный анализ — проверка неравномерности нажима, точек остановок (петли, разрывы), следов карандашной разметки, лака или подчистки. 2. Микроскопия — с помощью USB-микроскопа (40–200х) ищите следы корректора, несоответствие чернил (разные оттенки, расплывы при намокании), пикселизацию при сканировании. 3. Графологическая экспертиза — сравнение с эталонными образцами (не менее 5–10 с разным давлением и скоростью). Признаки подделки: дрожащие линии, излишняя угловатость, отсутствие динамики. 4. Цифровой анализ скана — используйте инструменты анализа изображений (GIMP, Photoshop): - Увеличьте до 800% — проверьте артефакты JPEG (блоки 8×8 при повторном сжатии). - Режим наложения «Разница» (Difference): наложите скан под вопросом на оригинальную подпись из другого документа — подделка выдаст расходящиеся контуры. - Проверьте метаданные файла (EXIF/PDF Metadata): дата создания/редактирования может быть позже даты заверения документа. Для электронной подписи (ЭП): 1. Проверка валидности подписи — откройте документ в КриптоПро CSP или используйте `openssl smime -verify` (для PKCS#7/.sig). Например: ```bash openssl smime -verify -in document.sig -inform PEM -content document.pdf -CAfile ca.pem ``` 2. Анализ сертификата — проверьте срок действия, отозван ли (CRL/OCSP), имя владельца. Подделка может быть через самоподписанный сертификат. 3. Хэш документа — вычислите хэш (SHA256) и сравните с хэшем внутри подписи. Если не совпадает — документ изменён после подписания. 4. Проверка chain of trust — используйте `openssl verify -verbose -CAfile root.pem cert.pem`. Невалидная цепочка — признак подлога. Программные инструменты (легальные): - Amped Authenticate — криминалистический анализ изображений (анализ подписи, шум, компрессия). - FOCA (для метаданных Office/PDF) — ищите несоответствия авторов, изменений. - ExifTool — выгрузка всех метаданных: `exiftool -a -u document.pdf`. Критическое предупреждение: Заключение о подделке должно основываться на комплексной экспертизе. Одиночный признак недостаточен для правовых выводов. Рекомендуется привлекать сертифицированного графолога и использовать спектрометрию (распознавание чернил) — только для уполномоченных экспертов. Не используйте методы, нарушающие ст. 137, 272, 273 УК РФ (незаконный доступ, создание вредоносного ПО). Все действия — только с согласия владельца документа или в рамках законной экспертизы.

Вопрос

Как восстановить файлы после сбоя питания при записи?

### Проблема При сбое питания во время записи страдает целостность файловой системы: - Файл остаётся в состоянии «незавершённой транзакции» (partially written). - Метаданные (inode, journal) повреждены – ОС видит битый файл, нулевой размер или ошибку ввода-вывода. - На физическом носителе возможны bad sectors из-за внезапного парковки головок (HDD) / потери питания NAND (SSD). ### Причины 1. Незавершённая запись journal’а (ext4, NTFS, APFS) – критично при отключении в момент flush-буфера. 2. B-tree / MFT corruption – сбой при изменении структуры каталогов (список файлов, атрибуты). 3. Кэширование записи без Flush (Write-back cache) – если отключён журнал или диск «слетел» до сброса. 4. SSD-контроллер – потеря питания во время сборки «мусора» (GC) может убить целый блок. ### Решение #### Шаг 1. Аппаратное клонирование (не работаем с оригиналом) - Используй ddrescue (GNU) для создания побитовой копии: ```bash sudo ddrescue -f -n /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.log ``` Параметр `-n` – skip bad sectors, не пытаемся читать дефект дважды. - Для SSD – запрети включение до клонирования, если контроллер вышел из строя. Обращайся к ремонту (PC-3000) – это область аппаратной форензики, не DIY. #### Шаг 2. Восстановление файловой системы через журнал - ext4 на Linux: ```bash sudo fsck.ext4 -f /mnt/backup/disk.img ``` Если journal повреждён – `-b superblock` (бекап суперблока, находишь через `mke2fs -n`). - NTFS (Windows / Linux): ```bash sudo ntfsfix /dev/loop0 ``` Поверх – chkdsk /f на смонтированном образе (только на копии!). - XFS: ```bash sudo xfs_repair -v /mnt/backup/disk.img ``` Если journal содержит частичную запись – fsck откатит незавершённый блок (потеря данных неизбежна для того самого файла, который писался в момент сбоя). #### Шаг 3. Карвинг (сканирование по сигнатурам) для недоступных файлов Когда файловая система критически разрушена, применяют восстановление данных после внезапного отключения питания через raw-сканеры: - PhotoRec (бесплатно, кроссплатформенно): ```bash sudo photorec /log /d /recup /dev/loop0 ``` Ищет JPEG, PDF, DOCX, ZIP, SQLite и т.д. по заголовкам. Не требует метаданных. - DMDE (условно-бесплатно, Windows/Linux) – для сложных случаев (файлы в «слетевшем» RAID, сильно фрагментированные). Глубокая детекция восстановления из незавершенной транзакции ext4 если journal частично цел. #### Шаг 4. Восстановление потерянной таблицы разделов Если сбой привёл к тому, что раздел не виден, используй: - TestDisk (тот же пакет, что и PhotoRec): `sudo testdisk /dev/sdX` → перестроить MBR/GPT, восстановить геометрию. - После – запустить шаг 2 или 3 на восстановленном разделе. ### Предупреждение Никогда (!) не пиши новые данные на оригинальный носитель до полного клонирования. Одна запись – и фрагменты «переживших» сбой файлов могут быть затерты. Для систем на ext4 с включённым journal (по умолчанию) шансы потери не пишущегося в момент сбоя файла низкие, но сам файл, на который шла запись, – не спасти без карвинга (если он был единственной копией).

Вопрос

Как узнать, кто скачивал файлы с облачного хранилища?

Проблема: Отсутствие прямой возможности идентифицировать конкретного пользователя (ФИО, IP-адрес), скачавшего файл, используя стандартные инструменты большинства облачных провайдеров (Google Drive, Яндекс.Диск, Dropbox, OneDrive). Обычно доступен лишь факт скачивания (время, файл), но не привязка к аккаунту скачивающего. Причины: 1. Приватность по умолчанию: Архитектура облачных сервисов не предназначена для сбора метаданных о потребителе контента при прямом скачивании (не через просмотр). 2. Отсутствие аудита на стороне потребителя: Если вы (владелец) дали доступ по ссылке (без входа), провайдер не логирует, кому принадлежит IP. 3. Служебный режим загрузки: Многие сервисы (Google Drive через API, S3) не передают заголовки авторизации при прямом GET-запросе, а только при манипуляции с самим аккаунтом (удаление, перемещение, изменение прав). Решение (легальное, без взлома): 1. Использование специализированных ссылок с логированием (Email-уведомления): - Яндекс.Диск: В настройках шаренга активируйте "Уведомлять о доступе по ссылке". Яндекс зафиксирует почту того, кто ввёл её для доступа (если он не вошёл по прямой ссылке). - Google Drive: Установите права "Ограниченный доступ" и отправляйте приглашение на email. Так каждый скачивающий будет идентифицирован по аккаунту. 2. Анализ логов облачного провайдера (уровень владения аккаунтом): - Если файл находится в корпоративном аккаунте (Google Workspace, Яндекс 360): войдите в Admin console → Reports → Audit → Drive log. - Google: Фильтр `event_name = download` + `user` (кого затронуло). Лог показывает уникальный идентификатор сессии. - Яндекс 360: Администрирование → Логи → Облако → `Действие` = "Скачивание". 3. Для S3-совместимых хранилищ (Minio, AWS S3): - Включите Server Access Logging на бакете. - Ищите строки с `HTTP method = GET` и `Object Key = ваш_файл`. - В логе будет `Requester` (IAM-пользователь, если авторизация через API) или `Remote IP` (если доступ публичный). Внимание: IP — не юридически достаточное доказательство (может быть динамический или через VPN). 4. Принудительная авторизация через внешний шлюз: - Разместите файл на своём сервере (nginx, VPS), куда передаётся запрос на скачивание. Логи nginx (`access.log`) покажут `$remote_addr` и `$http_user_agent`. - Внедрите одноразовую ссылку (токен) через ForensicAnvil.ru/research — пример простого скрипта, генерирующего и логирующего каждый клик. Пример команды для nginx: ```nginx location /downloads { auth_request /auth; access_log /var/log/nginx/downloads.log custom; } ``` Логи будут содержать IP, User-Agent, Referer. Критическое предупреждение: Легальность — только для своих данных. Получение IP или email-адреса лиц, скачавших файл с публичной ссылки, не даёт права на DPI, DDOS или сбор без согласия (152-ФЗ). Для судебного иска потребуется документированная фиксация факта скачивания с удостоверяющего центра (например, через EDS).

Вопрос

Как восстановить данные с телефона, который не включается?

Проблема: Устройство не подает признаков жизни (черный экран, отсутствие реакции на кнопки, вибрацию). Доступ к пользовательским данным (фото, контакты, документы) невозможен стандартными методами. Причины: 1. Аппаратный сбой: Выход из строя контроллера питания (PMIC), разрыв дорожек шины питания, деградация аккумулятора (глубокий разряд ниже порога контроллера). 2. Повреждение загрузчика (Bootloop/Dead Boot): Сбой прошивки (неудачное OTA), битый раздел `boot` или `aboot` (Qualcomm) / `preloader` (MediaTek). Телефон циклически перезагружается или зависает на логотипе. 3. Физическое повреждение NAND/UFS-чипа: Механический удар, попадание влаги, электростатический разряд (ESD). Чип памяти может выйти из строя как устройство или иметь битые блоки в служебной зоне. Решение (Легальные методы, не нарушающие 272-ФЗ и 273-ФЗ РФ): 1. Диагностика с заменой аккумулятора (Исключение источника питания): - Отключите шлейф батареи (если съемная) на 60 секунд. - Подключите заведомо исправный аккумулятор или внешний блок питания с ограничением тока (1.5-2A) напрямую к контактам BMS (Battery Management System), минуя контроллер заряда. Цель: исключить неисправность PMIC на стороне батареи. 2. Перевод в Emergency Download Mode (EDL) / BROM Mode (Qualcomm / MediaTek): - Qualcomm: Замкните тестовые точки (TEST POINT) на плате (логика GND на USB_D+/D- или на GPIO) или используйте "EDL cable" (короткое замыкание D+ на GND в штекере USB). Телефон определится в Device Manager как `QDLoader 9008`. - MediaTek: Зажмите обе клавиши громкости при подключении к ПК. Устройство появится как `MediaTek DA USB VCOM`. - Действие: Снимите дамп всей памяти через OEM-инструменты (Qualcomm Sahara Protocol / MTK SP Flash Tool). Это копия данных без модификации — законно для собственного устройства. 3. Chip-off (Извлечение чипа памяти) — только при физическом повреждении контроллера или моста: - Инструменты: Инфракрасный фен (BGA-пайка), паяльная станция, программатор (Easy JTAG Plus, Medusa Pro II, Z3X Easy J-Tag). - Процедура: Выпаяйте NAND/UFS-чип, очистите от подтеков флюса, считайте дамп в программаторе в режиме "User Data Only" (обход поврежденного контроллера телефона). - Риски: Термическое разрушение чипа (требуется до 380°C с обдувом 70-80 L/min). После снятия дампа чип обычно невосстановим для повторной пайки. 4. Восстановление из дампа: - Qualcomm: Используйте `QcomDumper` или `QFIL` для извлечения разделов `userdata`, `system`, `cache`. - Анализ: Монтируйте образ `userdata` (ext4/f2fs) в Linux через `mount -o loop`. Для шифрованных данных (FBE/FDE) потребуется ключ, хранящийся в TEE. Если ключ нечитаем — данные невосстановимы без сертификата производителя. Ключевые ограничения (Важно знать): - Шифрование File-Based Encryption (FBE) делает невозможным восстановление без пароля/графического ключа, даже при полном дампе NAND. - Методы Chip-off и Test Point не гарантируют целостность данных при физическом повреждении NAND-массива. Вероятность успеха — 30-70% в зависимости от модели и причины отказа. - Законность: Все действия допустимы только на устройстве, принадлежащем вам или при наличии письменного согласия законного владельца. Извлечение данных с чужого устройства — уголовное преступление (ст. 272, 273 УК РФ).

Вопрос

Как вернуть удалённые заметки в облаке?

### Проблема: Удалённые заметки исчезли из облачного хранилища Причины: 1. Автоматическая синхронизация после удаления – если заметка удалена локально, облако (iCloud, Google Keep, Evernote, OneNote) синхронизирует это действие на сервере. 2. Истечение срока хранения корзины – у большинства сервисов корзина живёт 30–60 дней; после этого данные безвозвратно стираются из дата-центров. 3. Перезапись данных на стороне провайдера – даже после удаления из корзины, физические сектора могут быть затерты новыми данными (особенно в shared-кластерах). Решение (только легальные методы): ### 1. Восстановление заметок из облачного хранилища через корзину или дамп - Google Keep: `keep.google.com` → Корзина (Trash) → выбрать заметки → «Восстановить». Если корзина пуста — шансов 0 (нет API для forensics у третьих лиц). - iCloud Notes: через `icloud.com/notes` → папка «Recently Deleted» → срок 30–40 дней. - OneNote: `onenote.com` → Настройки учётной записи → «Восстановить удаленные». Работает только в течение 60 дней с момента очистки корзины. - Evernote: аккаунт → Корзина → «Восстановить». При Premium/Professional – срок увеличен. Команда для бэкапа (если корзина ещё активна, Python с requests): ```python import requests # Для iCloud — используйте pyicloud (pip install pyicloud) from pyicloud import PyiCloudService api = PyiCloudService('email', 'password') notes = api.notes.all() # Сохранить в JSON перед удалением из корзины ``` ### 2. Как вернуть удаленные заметки в облаке через запрос к провайдеру - Google: подать запрос через Google Takeout (даже после удаления из корзины — из дампа за 2-3 недели до удаления). - Microsoft: заявка в поддержку с трассировкой удаления через `event.log` учётной записи (только для платных OneDrive/Office 365). - Apple: если данные были на устройстве до синхронизации — используйте forensic-копию iPhone через UFED/Physical Analyzer (далее — дамп SQLite БД заметок, `/var/mobile/Library/Notes/notes.sqlite`). ### 3. Восстановление удаленных данных через forensics (локальный кеш) Если облачная корзина очищена, но заметка ранее открывалась на устройстве: - Android: `adb backup -f notes.ab` → извлеките `notes.db` (SQLite) — удаленные записи могут быть в таблице с флагом `deleted=0` или в WAL-файле. - iOS: извлечение через `iMazing` или `Бэкап в iTunes` → поиск по `ZDELETEDFLAG` в `NSNotes.db`. ### 4. Программа для восстановления заметок с облака (только если данные не перезаписаны) - DiskDrill / R-Studio – для восстановления локального кеша облачных клиентов (папки кеша Evernote, OneNote). - PhoneRescue for iOS – извлекает notes из iCloud-бекапа (без пароля – не работает, AES-256). Важно: Если облачный провайдер использует end-to-end шифрование (например, Notes в iCloud с включенной защитой данных), восстановление без логина невозможно — даже для экспертов-форензиков. Легальный путь только через пароль пользователя или ордер.

Вопрос

Как увидеть историю копирования файлов на флешку?

Проблема: Определить, какие файлы были скопированы на USB-накопитель, когда это произошло и с какого устройства. Стандартные средства (например, журнал копирования в Проводнике) не хранят такую историю. Причины: - Windows (и другие ОС) по умолчанию не логирует операции копирования на ФС-уровне. - Встроенная функция `Recent Places` или списки последних файлов в решении системных логов не предназначены для подтверждения факта копирования именно на USB-носитель. - При удалении файлов или перезаписи метаданных (время доступа) анализ усложняется. Решение: ### 1. Анализ артефактов USB в Windows (как просмотреть историю копирования на флэшку) - Prefetch (pf): Файлы `.pf` в `%SystemRoot%\Prefetch` содержат пути к запущенным приложениям. Если файл был скопирован (например, через cmd или `Copy`), запуск `cmd.exe` даст его путь, но не сам факт копирования. Используйте `strings .pf | findstr /i "F:"` (замените `F:` на букву флешки). - Jump Lists (юмп-листы): Данные в `%APPDATA%\Microsoft\Windows\Recent` (сетевые, USB). Открыть через `$RECYCLE.BIN` — неэффективно. - Event Logs (события, связанные с копированием на usb): В `Applications and Services Logs/Microsoft/Windows/DriverFrameworks-UserMode/Operational` (ID 2003, 2100, 2102) логируется подключение USB, но не копирование. - USN Journal (журнал изменений NTFS): Самый надежный источник для как посмотреть что копировали на флешку. #### Инструкция (легально, без стороннего ПО): 1. Вставьте флешку, откройте `cmd` от администратора. 2. Выполните: `fsutil usn readjournal C: > C:\usn.txt` (замените `C:` на системный диск). 3. Отфильтруйте записи по букве флешки: `findstr /i "F:" C:\usn.txt > C:\usn_filtered.txt`. 4. Анализируйте Reason и FileName. Копирование создаёт запись `Data Overwrite | Data Extend | File Create`. Важно: USN-журнал не хранит источник копирования (например, «скопировано из папки X на локальном диске»). Только факт, что файл появился на томе с определённым именем и временем. ### 2. Анализ через альтернативные потоки данных (ADS) — для NTFS-флешек - Файлы на флешке могут содержать скрытые ADS (например, `Zone.Identifier`), где указан URL-источник, если файл скачан, но не при копировании. Для выявления: `dir /r I:\` (путь к флешке). ### 3. Кроссплатформенный способ (без прав администратора) - На Linux/Mac с флешкой: `sudo strings /dev/sdX1 | grep -i "copy\|\.jpg\|\.docx"` — покажет flotsam (остаточные данные), но не даст гарантии целостности. ### 4. Инструменты форензики (легальные, для экспертизы) - USBDeview (NirSoft) — показывает время подключения/отключения, PID, VID, серийный номер. Не покажет файлы. - FTK Imager — создаёт образ флешки, затем можно проверить `$OrphanFiles`, `$Recycle.Bin`, `$LogFile`. - Autopsy (Sleuth Kit) — реконструирует действия пользователя по MFT и Journal. Итог: Единственный надёжный метод — анализ USN-журнала системы, куда была вставлена флешка, или полная криминалистическая экспертиза образа (MFT, $LogFile, $UsnJrnl). Для обычного пользователя «история копирования файлов на usb в windows» отсутствует.

Вопрос

Как вернуть удалённые закладки в браузере?

Проблема: Пользователь случайно удалил закладки в браузере (Chrome, Firefox, Edge) и не может их вернуть стандартными средствами (Ctrl+Z, история). Причины: 1. Ручное удаление отдельных адресов или целых папок через менеджер закладок. 2. Автоматическая синхронизация — удаление на одном устройстве мгновенно применяется к облачному аккаунту. 3. Сброс/переустановка браузера без предварительного экспорта файла закладок. 4. Повреждение файла базы данных браузера (обычно SQLite) из-за сбоя системы. Решение: 1. Восстановление удаленных закладок в Chrome через синхронизацию (с облака) - Открой `chrome://settings/syncSetup/advanced` → раздел «Управление синхронизацией» → отключи синхронизацию закладок (временно). - Перейди на `chrome://history/` → боковое меню «Закладки» — Chrome хранит снимки за последние 90 дней. Выбери дату до удаления. - Верни закладки через кнопку «Восстановить». 2. Как достать закладки из резервной копии файловой системы - Закрой браузер. - Открой `%LOCALAPPDATA%\Google\Chrome\User Data\Default\` (или `~/Library/Application Support/Google/Chrome/Default/` на macOS). - Найди файл `Bookmarks.bak` — это ежедневная автоматическая копия. - Удали `Bookmarks` (текущий), переименуй `Bookmarks.bak` в `Bookmarks`. Запусти браузер. 3. Программа для восстановления данных на уровне файловой таблицы (если файл закладок удален) - Используй PhotoRec (бесплатно, работает без установки, не требует прав root). - Выбери диск C: → тип файла: `Bookmarks` (Chrome) или `places.sqlite` (Firefox). - Установи размер кластера как на вашем томе — PhotoRec восстановит удаленный `.sqlite` или JSON-файл. 4. Восстановление удаленных закладок в Firefox если нет синхронизации - Открой `about:support` → нажми «Открыть папку профиля». - Найди папку `bookmarkbackups` — там лежат сжатые копии `.jsonlz4` каждой сессии. - Установи дополнение Mozilla Firefox Bookmarks Backup Viewer или распакуй вручную утилитой `lz4json` (`npm install -g lz4json`). - Импортируй нужный файл (самый свежий до удаления) через Библиотека → Импорт и резервирование → Восстановить. 5. Если восстанавливаете из облачной копии после сброса браузера - Войди в Google Аккаунт, открой `bookmarks.google.com`. - Нажми «Действия» → перейди в «Журнал изменений» → выбери контрольную точку за дату, предшествующую удалению. 6. Продвинутая очистка при повреждении базы SQLite (Chrome/Edge) - Утилита DB Browser for SQLite (бесплатно). - Открой `Bookmarks` (без расширения) в `%LOCALAPPDATA%\Microsoft\Edge\User Data\Default\`. - Выполни SQL: `UPDATE slots SET id = id WHERE id = id;` (переиндексация) — может восстановить скрытые записи. - Если структура нарушена — экспорт таблицы `bookmarks` в CSV через SQLite и ручной импорт. Когда ничего не помогает: - Проверь резервную копию всей системы (точки восстановления Windows/tmutil на macOS). - Примени Boomerang for Google Chrome (расширение) — предустановленное сохранение каждой сессии закладок не поможет сейчас, но решит проблему на будущее: настрой частоту автосохранения.

Вопрос

Как проверить, оригинальное ли фото или из интернета?

Проблема: Невозможность достоверно отличить оригинальную цифровую фотографию (снятую камерой устройства) от изображения, скачанного из интернета, без анализа технических свойств файла. Причины: 1. Метаданные (EXIF): Социальные сети и мессенджеры (Telegram, WhatsApp) полностью вычищают метаданные. Оригинал с камеры содержит серийный номер, модель, GPS-координаты, дату съемки, специфичные для камеры теги (F-число, ISO). Скачанное фото либо не имеет ни одного тега EXIF, либо содержит служебные теги процессора (например, `Software: GIMP 2.10.14`). 2. Артефакты сжатия: Онлайн-платформы (VK, Twitter) пережимают JPEG, создавая уникальные блочные артефакты 8x8 пикселей (артефакты квантования). 3. Шум матрицы: Оптический шум (Photo Response Non-Uniformity, PRNU) — уникальная «цифровая подпись» сенсора камеры. На скачанном и пережатом изображении этот шум отсутствует или перезаписан. Решение: ### 1. Анализ метаданных и определение источника скачанной фотографии Инструмент: `exiftool` (консоль) или GUI (Exif Pilot, ExifToolGUI). Команда: ```bash exiftool -a -G1 -s /path/to/image.jpg ``` Ключевые признаки скачанного фото: - Отсутствие тегов `EXIF IFD0:Make`, `EXIF IFD0:Model`, `EXIF IFD0:CreateDate`. - Присутствие `Software` с названием графического редактора (Photoshop, GIMP, Pixelmator). - Поле `JFIF Version: 1.01` — характерно для изображений из браузера. Признак оригинала: - Наличие всех метаданных камеры (включая `EXIF:ISO`, `EXIF:FocalLength`, `EXIF:GPSLatitude`). ### 2. Проверка подлинности цифрового изображения через ошибки сжатия Метод: Анализ уровня ошибок (Error Level Analysis, ELA). Инструмент: Онлайн-сервис [fotoforensics.com](https://fotoforensics.com) (ELA-анализ) или локальный инструмент `forensically` (beta). Инструкция: - Загрузите фото на FotoForensics. - Нажмите «ELA» (Error Level Analysis). - Оригинал: равномерный шум по всей области, яркость одинаковая. - Скачано/пережато: резкие темные области (сжатие JPEG повторно наложилось на уже сжатый кадр), яркие белые края вокруг объектов (повторное сохранение). ### 3. Обратный поиск изображения в поисковых системах (OSINT) Инструменты: Google Images (поиск по картинке), TinEye, Yandex.Images. Техника: - Обрежьте фото до ключевого объекта (если есть рамки/подписи). - Загрузите в поисковик. - Результат: Если фото найдено на сайтах-стоки (Shutterstock, Getty) или в ленте соцсетей с датой до даты предполагаемого снятия — это копия из интернета. ### 4. Верификация шума сенсора (PRNU) — экспертный уровень Метод: Сравнение шума матрицы с эталонным шумом камеры. Инструмент: `PRNU Compare` (Python, пакет `pyprnu`) или `AMOS` (Academic software). Условие: Требуется эталонный снимок с той же камеры (на выдержке 1/30, 1/60, ISO 100). Результат: Если коэффициент корреляции Пирсона > 0.1 — фото сделано этой камерой. Если < 0.01 — фото из интернета или с другого устройства. Итоговая краткая инструкция: 1. Запустите `exiftool` — смотрите наличие `Make`, `Model`, `CreateDate`. 2. Откройте на FotoForensics ELA — однородный шум = оригинал, яркие области = копия. 3. Обновите поиск по картинке (TinEye, Google Images). 4. При сильных подозрениях — PRNU-анализ (только для экспертов-криминалистов).

Вопрос

Как узнать, кто печатал документ на сетевом принтере?

Проблема: Отсутствие прямой привязки задания (Job ID) к конкретному пользователю в логах сетевого принтера по умолчанию. Принтер видит IP-адрес, MAC и имя хоста, но не авторизованного сотрудника. Причины: 1. Протокол печати: RAW (Port 9100) и LPD не передают доменную учетку — только имя хоста отправителя. 2. Отсутствие аудита: Не настроена отправка syslog на SIEM (Wazuh/Splunk) или не включен Event Log 307/7036 на сервере печати Windows. 3. Пул принтеров: Документ мог уйти на другой физический девайс из-за балансировки. Решение (пошагово, легальные методы в рамках РФ): 1. Трассировка через сервер печати (Windows): Журнал: `Event Viewer → Applications and Services Logs → Microsoft → Windows → PrintService → Operational` Фильтр: Event ID 307 (печать завершена) или 7036 (задание отправлено). Поле User Name в деталях события — это учетка, отправившая документ. Нюанс: Работает только если клиенты не используют драйверы с "печать напрямую" (LPR). 2. Анализ syslog принтера (для HP/Lexmark/Kyocera): Подключитесь к веб-интерфейсу принтера → `Сеть` → `SNMP` / `Syslog`. Настройте отправку на сервер. Что искать: В строке лога ищите `User Name` (если настроено доменное шифрование TLS/SSL) или `Client Hostname` (маппинг через DHCP-логи). Команда для grep: `cat /var/log/print.log | grep "Completed" | grep -i "doc_name.pdf"` 3. Анализ файлов спула (для Windows Print Server): Расположение: `C:\Windows\System32\spool\PRINTERS\.SPL` Метод: Используйте `Print Spooler File Viewer` (например, `SpliD` от Nirsoft — легальна для форензики). Что даст: Извлечет учетную запись `User Name` и `Machine Name` из бинарного заголовка SPL-файла. 4. Если принтер — часть MFP (МФУ): `Веб-морда` → `Администрирование` → `Журнал заданий` → `Выгрузка CSV`. В CSV будет колонка `User`, если включена аутентификация по LDAP/AD. Без неё — только номер аппарата. 5. Корреляция по времени (если п.1-3 не дали): Возьмите точное время печати из лога принтера (время завершения). Сверьте с логами контроллера домена (Event ID 4624) — кто логинился на ПК, с которого пришел запрос. Затем проверьте `Security Event Log` на этом ПК (событие 5416 — активность очереди печати). Итоговый чек-лист: Must have: Включен `Operational` лог PrintService на сервере печати. Nice to have: Настроено доменное шифрование на принтере (LDAPS) и отправка syslog на SIEM. Если ничего нет:** Единственный путь — опрос сотрудников по времени из лога принтера (не нарушая 152-ФЗ, используя как служебную записку).

Вопрос

Как проверить, с какого места загружалось видео?

### Проблема: установление места съемки или загрузки видео Необходимо определить географические координаты или физическое местоположение, где было снято или загружено видео. Это требуется для проверки алиби, анализа цифровых улик или подтверждения происхождения контента. ### Причины: какие данные сохраняются 1. EXIF (метаданные) — в видеофайлах от камер и смартфонов (MP4, MOV, AVI) могут сохраняться: - GPS-координаты (широта/долгота) - Дата и время съемки (UTC) - Модель устройства 2. Данные от платформ — при загрузке в соцсети (YouTube, ВК, TikTok) метаданные обычно удаляются, но может оставаться временная метка загрузки, IP-адрес (в логах платформы, недоступных обычному пользователю). 3. Медиа-ридеры — программы вроде FFmpeg, ExifTool, MediaInfo могут извлекать метаданные, даже если видео было пережато. ### Решение: проверка происхождения загруженного видео #### 1. Извлечение метаданных с помощью ExifTool (самый надежный для локальных файлов) ```bash # Установить ExifTool (доступен для Linux/macOS/Windows) exiftool -GPSPosition video.mp4 exiftool -CreateDate video.mp4 exiftool -Model video.mp4 ``` - Если есть GPS — получите координаты, затем вставьте в Google Maps или Яндекс.Карты. - Если GPS нет — проверьте `DateTimeOriginal`, `CreateDate`, `MediaCreateDate`. Они показывают время съемки в часовом поясе устройства. #### 2. Анализ через MediaInfo (GUI или CLI) ```bash mediainfo video.mp4 | grep -i gps ``` - Метаданные отображаются в секции `General` или `Video`. Координаты ищут как `GPS position`. #### 3. Определение геолокации видео по временной метке и данным устройства Если GPS отсутствует, но есть точное время и модель устройства: - Используйте базу данных IMEI (только для правоохранительных органов) или данные о базовых станциях (требует доступа к провайдеру). Легально для эксперта — только с согласия владельца устройства. - Для видео с YouTube: используйте `youtube-dl --dump-json URL` — метаданных GPS там нет, но есть `upload_date` и `location` (если автор указал вручную). #### 4. Поиск координат по визуальным элементам (OSINT-подход) Если метаданных нет: - По тени и солнцу: определите примерное время и широту. - По геопривязке объектов: здания, вывески, рельеф — используйте Google Street View, Яндекс.Панорамы. - По уникальным деталям: номер дома, дорожный знак, антенна сотовой связи (можно пробить по базам Cell ID — легально для экспертов с доступом к базам операторов). #### 5. Проверка файла на наличие скрытых слоев (для сложных случаев) ```bash ffprobe -show_format video.mp4 | grep -i "location\|GPS\|coordinates" ``` Или извлеките все метаданные в JSON: ```bash exiftool -j video.mp4 > metadata.json ``` #### Важно: легальные ограничения в РФ - Самостоятельный сбор GPS-координат чужого контента — без согласия субъекта персональных данных может быть нарушением 152-ФЗ «О персональных данных». - Анализ видео с целью идентификации геолокации без согласия владельца файла или видео — только в рамках официальной экспертизы (по постановлению следователя/суда). Итог: если видео загружено — ищите оригинальный файл (не пережатый соцсетями). Из метаданных единственный прямой способ — GPS. Если его нет — используйте OSINT по визуальным маркерам и временной метке.

Как восстановить переписку из резервной копии?

Проблема: Не удаётся получить доступ к истории сообщений после сброса, переустановки мессенджера или повреждения текущей базы данных. Требуется извлечение данных из ранее созданного бэкапа. Причины: 1. Резервная копия зашифрована (end-to-end encryption, AES-256 для WhatsApp/Telegram). 2. Несовместимость формата: iOS-бэкап (iTunes/iCloud) не читается на Android и наоборот. 3. Повреждение файла резервной копии при переносе или хранении. Решение: 1. Для Android (WhatsApp/Telegram): - Местонахождение бэкапа: `/sdcard/WhatsApp/Databases/` (файлы `msgstore-YYYY-MM-DD.1.db.crypt12/14`). - Инструмент: Elcomsoft Phone Breaker (легален для собственных данных) или WhatsApp Viewer (кроссплатформенная утилита). - Команда (Linux/macOS) для расшифровки Crypt14: ```bash python3 wa_crypt_tool.py decrypt -k -i msgstore.db.crypt14 -o msgstore.db ``` Где `` — извлечённый ключ (через рут или бэкап ADB). - Примечание: для восстановления переписки из резервной копии на андроид без рута требуется сброс и восстановление через Google Drive (только с той же учётной записью). 2. Для iOS (iMessages, WhatsApp): - Извлечение из iTunes-бэкапа: iBackup Viewer (бесплатен, работает без джейлбрейка). - Пароль от бэкапа (если установлен) сбрасывается через Elcomsoft Phone Password Breaker (брутфорс слабых паролей). - Путь к нужной базе: `3d0d7e5fb2ce288813306e4d4636395e047a3d28` (для iMessage). 3. Универсальный метод (любая платформа): - Autopsy (Sleuth Kit) — анализ дампов разделов (требует root/jailbreak). - Magnet AXIOM (платная, демо-версия существует) — автоматическое извлечение и парсинг бэкапов более 200 приложений. - Важно: если вы ищете как извлечь историю сообщений из бэкапа телефона, используйте FTK Imager для создания образа раздела `userdata` и последующего анализа через `sqlite3`. Юридические ограничения (РФ): - Вмешательство в чужие бэкапы без согласия владельца — ст. 138 УК РФ («Нарушение тайны переписки»). - Все методы применимы только к собственным устройствам и данным. Для корпоративной форензики — с письменного разрешения юрлица.

Как проверить, подлинный ли документ или скан?

Проблема: Необходимо установить подлинность предоставленного документа или его скана — выявить признаки монтажа, редактирования или подмены исходного файла. Причины: - Подделка в графическом редакторе (Photoshop, GIMP) — вставка фрагментов, изменение реквизитов, текста. - Сканирование поддельного бумажного носителя, созданного методом цветной струйной печати. - Изменение метаданных или подмена содержимого в многостраничном PDF (например, замена одной страницы). - Генерация полностью синтетического документа через нейросети (GAN, Stable Diffusion) или текстовые редакторы. Решение (легальные методы без нарушения законодательства РФ): ### 1. Визуальная экспертиза и анализ атрибутов файла (первичная проверка подлинности скан-копии документа) - Проверьте DPI и разрешение. Откройте свойства файла (Windows: ПКМ → Свойства → Подробно). Для реального скана характерно значение 200–300 DPI (или 600). DPI ниже 150 или нестандартные значения (72, 96) — признак экспорта из графического редактора, а не сканера. - Анализируйте тени и градиенты. В Photoshop часто остаются следы: неравномерный шум, резкие границы вокруг вставленных объектов, отсутствие естественного шума бумаги на вставке. - Проверьте шрифты и выравнивание. Подделки часто содержат мелкий текст с разным межбуквенным расстоянием (кернингом), «съехавшие» строки или несоответствие шрифта стандартам (например, в паспортах РФ используется шрифт ISOCPEUR). - Используйте увеличение (Zoom 400-800%). Ищите артефакты JPEG-сжатия, крапинки (dithering) на однотонных заливках — признаки скриншота или повторного сохранения. ### 2. Анализ метаданных (EXIF, XMP, PDF) для проверки подлинности электронного документа - Для изображений (JPG, PNG, TIFF): `exiftool -a -u suspect_doc.png` Ищите теги: - `Software` — Photoshop, Adobe Illustrator, Paint.NET → признак редактирования. - `CreateDate` / `ModifyDate` — если даты не совпадают или модификация позже даты документа. - `ImageDescription` — может содержать имя автора или программы. - `History` (XMP) — цепочка изменений (Photoshop History). - Для PDF: `pdfid.py suspect.pdf` (утилита Didier Stevens) — проверка на скрытые действия (JavaScript, OpenAction, EmbeddedFiles). `pdf-parser.py suspect.pdf` — извлечение и анализ всех объектов, поиск встроенных изображений, не соответствующих структуре (например, 5 изображений в 2-страничном документе). Пример команды для выявления скрытого текста в PDF: `python pdf-parser.py -s /Font suspect.pdf` — поиск нестандартных шрифтовых подстановок. ### 3. Форензика JPEG-артефактов (ELA — Error Level Analysis) Метод выявляет области, добавленные позже (вставки), по разности в уровнях ошибок сжатия. Инструмент: `forensically Beta` (онлайн, без регистрации) или скрипт Python: ```python from PIL import Image, ImageChops, ImageFilter import sys input_image = sys.argv[1] im = Image.open(input_image) im.save('/tmp/temp_ela.jpg', 'JPEG', quality=95) ela_im = Image.open('/tmp/temp_ela.jpg') diff = ImageChops.difference(im, ela_im) diff = diff.filter(ImageFilter.GaussianBlur(radius=2)) diff.save('ela_output.png') ``` Области с яркими пикселями (отличие от фона) — вероятные места редактирования. ### 4. Проверка шумов датчика сканера (Sensor Noise Pattern) Для профессиональной проверки подлинности скана документа: Сравните равномерный шум фона (нулевая точка, белая область) с эталонным шумом конкретной модели сканера. Любая вставка будет иметь другой рисунок шума. Инструмент (закрытый код, не для нарушений): PRNU analysis через `python prnu` (библиотека). Легально используется только на собственных эталонных сканах, полученных законно. ### 5. Криминалистическая экспертиза бумажного носителя (если есть физический документ) - Ультрафиолетовая лампа (365 нм). Настоящий документ (паспорт, диплом) содержит защитные волокна, реагирующие свечением. Поддельная струйная печать даёт яркую фиолетовую засветку всей поверхности. - Тактильный анализ. Используйте пальцы и лупу: на реальном документе текстура печати глубокая (trapping, рельеф), на струйной — плоская, глянцевая. - Микроскоп (80-200х). Растровые точки струйного принтера имеют характерную «кляксу» (bleeding), в отличие от четких листовых растров офсета. ### Итоговая последовательность действий для проверки подлинности документа: 1. Запросить оригинал файла без перекомпрессии (RAW, TIFF, не JPEG). 2. Запустить `exiftool` на изображение и PDF — отсечь 80% подделок с редактированием. 3. Выполнить ELA-анализ (Python или онлайн) — найти вставки. 4. При физическом документе — УФ-лампа + микроскоп. 5. При высоких рисках — обратиться в аккредитованную лабораторию судебной экспертизы (не нарушая тайну следствия, если это ваше дело). Важно: Ни один метод не даёт 100% гарантии без доступа к эталонному образцу сканера и бумаги (например, госконтракт). Указанные техники легальны, не требуют инвазивного доступа и не нарушают законодательство РФ.

Как восстановить файлы после переустановки системы?

Проблема: После переустановки ОС данные на системном разделе (C:\) недоступны. Файлы кажутся потерянными, но физически сектора диска не затерты мгновенно. Причины: - Форматирование или перезапись разделов установщиком Windows/Linux. - Новые данные (файлы ОС) частично перезаписали старые кластеры, где хранились ваши файлы. - Файлы не удалены, а помечены как «свободное место» — структура файловой системы (MFT для NTFS, суперблоки для ext4) повреждена или перезаписана частично. Решение (пошагово, без права на ошибку): 1. Немедленное действие: Отключите компьютер. Не загружайте переустановленную систему с установочного диска. Любая запись (логи, кэш браузера, установка драйверов) уменьшает шансы на восстановление остатков данных. 2. Загрузка с Live-CD/USB (дистрибутив Linux): Загрузитесь с Ubuntu USB. Не монтируйте раздел автоматически — откройте терминал. 3. Создание посекторной копии (наиболее надежно для восстановления битых файлов после переустановки системы): ```bash sudo dd if=/dev/sda1 of=/mnt/external_drive/disk_copy.img bs=64K status=progress ``` Работать ТОЛЬКО с копией, а не с диском. 4. Анализ сканов на копии: - PhotoRec (CGSecurity) — восстановление по сигнатурам (фото, документы, архивы). Запускать на образе: ```bash sudo photorec /mnt/external_drive/disk_copy.img ``` - TestDisk — восстановление структуры разделов, если таблица разделов затерта. 5. Использование DMDE (оптимальный вариант для NTFS после переустановки): - Запустите DMDE с Live-CD. - Откройте образ диска → выберите «Полный скан». - В результатах ищите папки с именем `$Root`, `$Recycle.Bin`, `$User` — это остатки старой структуры. - Восстановите только критически важные файлы (в DMDE это бесплатно для мелких файлов). Критическое предупреждение: - Шанс восстановления падает с каждым часом работы переустановленной системы. Если прошло >2 дней, 90% данных перезаписаны. - Не используйте R-Studio, Recuva на активной системе — они пишут временные файлы на восстанавливаемый раздел. - Для профессионального восстановления (сложные битые файлы) — обращайтесь в лаборатории, работающие с аппаратными дубликаторами (PC-3000).

Как узнать, кто заходил в соцсеть с моего телефона?

Проблема: Подозрение на несанкционированный доступ к вашему аккаунту соцсети с вашего же устройства. Необходимо установить факт и источник доступа. Причины: 1. Фишинг или вредоносное ПО на телефоне (кейлоггер, стилер cookie). 2. Компрометация сессии (перехват cookie при подключении к публичным Wi-Fi). 3. Уязвимость в браузере/ОС (редко, но актуально для устаревших версий Android/iOS). 4. Реальный физический доступ к разблокированному устройству (друг/родственник) с последующим запуском приложения. Решение (только легальные методы, ч. 272-273 УК РФ не нарушаем): 1. Проверка истории входов в соцсеть на телефоне (основной метод). ВКонтакте: Настройки → Безопасность → История активности. Ищите IP, тип устройства (iOS/Android/Web) и метку времени. Несовпадение модели телефона с Вашей — признак чужого доступа. Telegram: Настройки → Конфиденциальность → Активные сессии. Завершите все, кроме текущей. Instagram/Facebook: Настройки → Центр аккаунтов → Пароль и безопасность → Где вы вошли. Одноклассники: Настройки → Мои действия → История входов. 2. Анализ логов авторизации Google/Apple ID (поможет при входе через SSO). Android: myaccount.google.com → Безопасность → Ваши устройства и Недавние действия по безопасности. iPhone: appleid.apple.com → Вход и безопасность → Статус учетной записи → История входов. 3. Локализация по IP из истории входов (ограниченно). Скопируйте IP-адрес из логов соцсети. Через whois-сервис (например, 2ip.ru) определите провайдера и город. Совпадение с вашим домашним Wi-Fi — исключает удаленный доступ, но не локальный. 4. Проверка на наличие программ для слежки на телефоне без рут-прав (Android). Зайдите в Настройки → Приложения → Все приложения. Ищите приложения с пустыми иконками, странными названиями (типа `com.monitor.xxx`), или те, у которых запрошено разрешение "Поверх других окон". Пример команд (терминал Android, если есть adb): ``` adb shell dumpsys usagestats ``` Выдаст список приложений со временем последнего запуска. 5. Экстренное завершение всех сессий. В настройках безопасности соцсети нажмите "Завершить все сессии" (или "Выйти на всех устройствах"). После этого немедленно смените пароль на сложный (30+ символов, через менеджер паролей). Включите двухфакторную аутентификацию (2FA) — это 95% защиты. Важно: Стандартными средствами ОС (без рута/jailbreak и установки сомнительного ПО) посмотреть полный лог открытия приложений и переходов внутри соцсети невозможно. Инструменты типа Dr.Fone или iMobie могут читать удаленные данные, но не логи активных сессий. Единственный достоверный источник — серверный лог самой соцсети (п.1).

Как проверить, редактировали ли таблицу после сохранения?

Проблема: Необходимо достоверно определить, вносились ли изменения в таблицу (Excel, SQL, CSV) после её последнего сохранения, без доверия к встроенным датам файловой системы (которые легко подделываются). Причины: 1. Подмена метаданных: Дата «Изменено» в свойствах файла может быть изменена через `SetFileTime` или атрибуты. 2. Необновление даты: Редактирование без сохранения не меняет дату файла. 3. Ложный след: Восстановление предыдущих версий (Shadow Copy) может перемешать временные метки. Решение (3 уровня глубины): 1. Базовый — хэш-контроль (для контрольных точек) - Если есть эталонный хэш (MD5/SHA256) файла сразу после сохранения, вычислите текущий: ```cmd certutil -hashfile "C:\table.xlsx" SHA256 ``` - Ограничение: Работает только при заранее взятом хэше. Не покажет факт неавторизованного редактирования, если эталона нет. 2. Продвинутый — метаданные файла таблицы в контексте версий - Проверка версий файла (Windows Previous Versions): - Клик ПКМ по файлу → «Свойства» → «Предыдущие версии». - Если версии отличаются по размеру/дате — минимум одно сохранение после даты эталона. Не говорит о редактировании — только о факте записи. - Анализ метаданных OOXML (для .xlsx/.xlsm): - Распакуйте `file.xlsx` (это ZIP) и проверьте `docProps/core.xml`: ```xml 2024-03-15T10:00:00Z ``` - Если `modified` > даты эталонного сохранения — прямое доказательство редактирования. Дата подделывается только через распаковку и правку XML. 3. Форензика — анализ логов файловой системы ($MFT/JumpList) - NTFS $MFT (Master File Table): - Используйте `MFT Explorer` или `$MFT` парсер. - Сравните атрибуты `$STANDARD_INFORMATION` (SI) и `$FILE_NAME` (FN). - Признак редактирования: Время `$SI.Modified` — время последнего изменения данных. Если `SI.Modified` > `FN.Creation` — изменение было. - Команда извлечения (только для экспертов, читать блок RAW): ```cmd fsutil mft readFile C:\ 0x1C0 > mft_dump.txt (пример для ручного разбора) ``` - Jump Lists (Windows 10/11): Содержат историю открытия и сохранения конкретных файлов приложением (Excel, Notepad++). Анализ через `JLECmd.exe` или вручную `%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\`. - Результат: Даты последнего сохранения в Excel — если дата в Jump List позднее эталона, файл редактировали. Итоговая рекомендация для OSINT/форензики: - Наиболее надёжный метод без эталонного хэша — сопоставление атрибутов $MFT (SI vs FN) и анализ `docProps/core.xml` внутри OOXML-контейнера. - Для баз данных (SQLite/MySQL) — проверка WAL-журнала (Write-Ahead Log) — если размер журнала >0 при закрытой БД — были изменения после последнего сохранения (CHECKPOINT).

Как восстановить данные с телефона после падения в воду?

### Проблема Телефон не включается после падения в воду, данные недоступны. Риск потери информации из-за короткого замыкания и коррозии контактов. ### Причины 1. Попадание воды на материнскую плату → электролиз под напряжением → окисление контактов и дорожек. 2. Влага в разъемах (USB, SIM, карта памяти) → коррозия контактов → потеря связи с накопителем. 3. Если устройство было включено: короткое замыкание цепей питания → выход из строя контроллера NAND или eMMC. 4. Повреждение аккумулятора (вздутие, утечка) → риск воспламенения при попытке зарядки. ### Решение (легальные методы, только для собственного устройства или с письменного согласия владельца) #### Этап 1. Немедленные действия (до высыхания) - НЕ включать! Отключить питание (вынуть батарею, если съемная). - Не заряжать, не подключать к ПК — подача напряжения ускоряет коррозию. - Извлечь SIM и карту памяти — их данные часто сохраняются. Просушить карту памяти отдельно (силикагель, рис на 48 часов). #### Этап 2. Сушка и очистка - Разобрать телефон (открутить все винты, снять экран, отделить плату). - Промыть плату изопропиловым спиртом (99%) — он вытесняет воду и не проводит ток. - Ультразвуковая ванна с изопропанолом (5-10 мин, 40 кГц) — удаляет солевые отложения. - Сушка: 24-48 часов при 40-50°C (не СВЧ, не фен без контроля температуры!). Идеально — сушильный шкаф или силикагель. #### Этап 3. Диагностика и восстановление данных с телефона после падения в воду - Если плата не повреждена, но не включается: заменить аккумулятор, проверить тестером напряжение на контактах питания. Подключить через USB-тестер (ток потребления

Как увидеть, какие устройства подключались к ПК?

Вот структурированный ответ для ForensicAnvil.ru, без воды, по запросу «как увидеть, какие устройства подключались к ПК». ### Проблема: Необходимо определить, какие USB-устройства и внешние накопители когда-либо подключались к данному компьютеру Обычно требуется при расследовании инцидентов: выявление факта копирования данных на флешку, определение неизвестного устройства (мышь/клавиатура) или поиск следов подключения мобильного телефона. ### Причины: Сложность обнаружения из-за очистки журналов Пользователь мог удалить историю подключений через стандартный интерфейс. Реестр Windows или журналы событий могли быть частично перезаписаны. Требуется анализ скрытых ключей реестра и логов Plug and Play. ### Решение: Извлечение истории с помощью реестра и журналов событий Используйте только встроенные средства Windows или легальное ПО (Sysinternals, NirSoft). 1. Просмотр истории подключений USB-накопителей через реестр (USBSTOR) Самый надежный способ. Откройте `regedit` от имени Администратора. Путь: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR` Что смотреть: Каждый GUID (например, `Disk&Ven_SanDisk&Prod_Ultra&Rev_1.00`) — это уникальное устройство, подключавшееся к ПК. Дата первого/последнего подключения: Перейдите в ветку `...\Properties\{83da6326-97a6-4088-9453-a1923f573b29}` (0064 — первое подключение, 0066 — последнее). Декодируйте значение `0064` (FILETIME) с помощью PowerShell: ```powershell [datetime]::FromFileTime((Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\DISK&VEN_SANDISK&PROD_ULTRA&REV_1.00\4&1a2b3c4d&0\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0064").'(default)') ``` 2. Определение устройств, подключавшихся к компьютеру, через журналы событий (Event Viewer) Используйте для поиска конкретных дат, когда было вставлено устройство. Путь: `Приложения и службы > Microsoft > Windows > Partition > Diagnostic` Event ID 1006: Фиксирует подключение нового диска (например, флешки). Что смотреть: Вкладка «Подробно» -> `FriendlyName` (имя накопителя) и `VolumeSize` (объем). Путь: `Приложения и службы > Microsoft > Windows > DriverFrameworks-UserMode > Operational` Event ID 2003: Логирует подключение любого USB-устройства (клавиатура, веб-камера, модем). Event ID 2100: Логирует отключение. 3. Программное извлечение (легальные утилиты) Если нужно выгрузить историю в отчет без ручного копания в реестре: USBDeview (NirSoft): Показывает все USB-устройства, подключавшиеся к системе, с датами, серийными номерами и меткой «Отключено/Подключено». Не требует установки. PowerShell (встроенный): Экспорт ключей реестра в CSV. ```powershell Get-ChildItem -Path "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR" -Recurse | ForEach-Object { $_.PSPath } | Out-File -FilePath C:\usb_history.txt ``` SEO-вкрапление: Для точного просмотра истории подключений USB и определения устройств, подключавшихся к компьютеру, ключевым является анализ ветки USBSTOR. Если вы хотите увидеть, какие устройства подключались к ПК в прошлом, не полагайтесь на визуальную историю в панели управления — используйте реестр или журналы Microsoft-Windows-Partition/Diagnostic. Важно: Анализ должен проводиться на выключенной системе или смонтированном образе диска (для forensic-экспертизы). Манипуляции с реестром могут повлиять на работу системы — работайте с копией реестра или read-only.

Как проверить, с какого IP заходили в аккаунт?

### Проблема Вы подозреваете, что в ваш аккаунт (почта, соцсети, мессенджер) заходили с незнакомого IP-адреса. Необходимо извлечь и проанализировать историю входов в аккаунт по IP для выявления утечки или взлома. ### Причины - Кража пароля через фишинг или утечку БД. - Активная сессия на чужом устройстве (например, общественный ПК, VPN с вредоносным узлом). - Бездействие пользователя: не отозваны сессии, не включена 2FA. ### Решение Пошаговая инструкция по получению логов авторизации в аккаунте для наиболее популярных сервисов. #### 1. Google (Gmail, YouTube) - Перейти: `myaccount.google.com` → Безопасность → Секция «Ваши устройства» → Управление всеми устройствами. - Нажать на сессию → отобразится IP и время. Для экспорта: Журнал активности → скачать в JSON (там полные метаданные, включая User-Agent и IP). - Альтернатива: `myaccount.google.com/data-and-privacy` → Скачать данные → выбрать только «Сведения об устройствах и действиях». Это стандартный метод анализа логов безопасности Microsoft/Google. #### 2. Яндекс (Почта, Диск) - `passport.yandex.ru` → История входов (или Безопасность → Последние действия). - Время, IP, регион. Клик по записи — User-Agent. Кнопка «Завершить все сеансы». - Для глубокого OSINT-анализа по IP-адресу используйте `whois` или `ipinfo.io` прямо в браузере. #### 3. VK / Одноклассники - VK: Настройки → Безопасность → Показать историю активных сессий. - OK: Настройки → Безопасность → История входов. - Сохраняет IP, браузер, устройство. Есть отметка «мобильное приложение» и GPS-координаты (если дано разрешение). #### 4. Discord - `discord.com/settings/Authorized Apps` → Пролистать вниз → Смотреть историю входов. - IP, метка местоположения (по GeoIP), Device Fingerprint. - Команда `/sessions list` (бот Dyno или в терминале приложения) не покажет IP, только сессии — это неполноценный мониторинг входов через лог активности. #### 5. Microsoft (Outlook, Azure) - `account.microsoft.com/security` → Просмотр активности входа. - Данные: IP, приложение, успех/неудача, крайне полезно для расследования инцидентов форензики. - SSH/API: `Get-AzureADAuditSignInLogs` (PowerShell, для глобальных администраторов). #### 6. Экспорт через IMAP/POP3 (для собственного ПО) - Проверить `Received`-цепочку письма. Алгоритм: ```bash # Найти последний внешний IP перед вашим MTA curl -X VERP -T email.eml https://mxtoolbox.com/ | grep "Received: from" ``` - Для Telegram: `@userinfobot` (выдает IP пользователя, если он ввел /start — но это не история входов, а разовая проверка). ### Заключительный совет по безопасности - Включите 2FA (TOTP, а не SMS) — это снижает вероятность несанкционированного доступа по украденному IP. - После анализа журнала активности входа — смените пароль и отзовите все устройства. - Используйте VPN только с адресом, который не совпадает с вашим регионом входа (если вы в Москве, а лог из Питера — подозрительно). Легальность: все данные получаются через штатные интерфейсы сервисов (запрос данных самого пользователя). Статья 138 УК РФ не применима при анализе собственных логов.

Как восстановить файлы, если программа вылетает при открытии?

Проблема: Утилита восстановления данных (R-Studio, GetDataBack, DMDE) аварийно завершает работу при попытке открыть том или запустить сканирование. Причины: 1. Критическое повреждение файловой системы (RAW/bad boot sector): Драйвер ФС вызывает Access Violation при парсинге $MFT/FAT-таблицы. 2. Дефекты носителя (Read/Write Error): Программа пытается считать сбойный сектор, ядро ОС «вешает» вызов — таймаут, крах. 3. Проблема с виртуальной памятью (логин-сессия): Огромный образ или битый диск создает своп-файл на нестабильном винчестере. 4. Отсутствие прав администратора или конфликт драйвера низкого уровня. Решение (пошагово, без GUI, если возможно): 1. Обход краха утилиты: - Используй консольную версию той же программы (например, `R-Studio CLI`, `dmde.exe /L`). - Загрузись с Live USB (Linux LiveCD — Ubuntu/Debian) и восстановление с помощью `ddrescue` + `testdisk/photorec`. Вылеты при открытии программы Windows не повлияют. 2. Диагностика и изоляция дефектов (восстановление файлов с поврежденного диска): - Сначала создай посекторную копию диска в безопасную среду: ```bash # Linux sudo dcfldd if=/dev/sdb of=/mnt/backup/image.dd bs=512 conv=noerror,sync status=progress ``` - Затем «реконструкция» образа через тестирование поверхности. Если крах вызван битым сектором — работа только с образом с файлом лога ошибок. 3. Ремонт файловой системы без открытия тома: - Запусти `chkdsk X: /f /r` (только если не на диске с проблемой — риск). Лучше — `fsck` в Linux на отмонтированной ФС. - Используй `TestDisk` (режим Quick/Deep Scan) для перестроения таблицы разделов. Запускай из командной строки (Win/Linux) — краш утилит восстановления обычно обходится. 4. Действия в случае, когда программа вылетает при открытии файловой системы: - В DMDE: диалог выбора тома -> пропустить «Авто-детект» -> «Выбрать логический диск» -> Прочитать MBR/GPT отдельно (Ctrl+D). Если получение структуры падает — диск умер аппаратно. - Открывай образ в `HxD` (hex-редактор) — если сам редактор не падает, проблема в драйвере ФС, а не в носителе. 5. Аппаратное решение (если софт валится из-за bad blockов): - Подключи проблемный диск через USB-мост. Используй `Victoria for Windows` или `HDD Regenerator` для «обхода» уцелевших секторов (кратковременное отключение таймаутов SATA). Только если данные не критичны. Ключевой принцип: Никогда не запускай утилиту восстановления напрямую на умирающем диске — только на его образе. Сбой при открытии программы — 90% аппаратных дефектов поверхности.

Как узнать, меняли ли время на компьютере?

### Проблема Факт изменения времени — весомый аргумент в цифровой криминалистике: позволяет выявить сокрытие следов, манипуляции с логами или алиби. Задача — доказать, что системные часы были переведены вручную или с помощью стороннего ПО. ### Причины 1. Смена часового пояса — легитимно, но редко. 2. Ручная правка через интерфейс ОС или утилиты (`date`, `timedatectl`). 3. Синхронизация с NTP (ошибка сервера, подмена). 4. Сброс CMOS-памяти (разряд батарейки, отключение питания). 5. Злонамеренные действия — подмена времени для обхода лицензий, фальсификации действий в логах, алиби. ### Решение Проверка фальсификации системного времени на компьютере требует анализа журналов Windows Event Viewer (ID 1, 4616) или syslog на Linux. #### Windows 1. Откройте Event Viewer → Windows Logs → System. 2. Фильтр по ID события 1 (изменение времени) или 4616 (системное время изменено). 3. Анализ: записи содержат предыдущее и новое время, причину (ProcessId, User). Если `TimeChange` не совпадает с шагом синхронизации NTP — ручное вмешательство. Анализ событий изменения системных часов Windows через PowerShell: ```powershell Get-WinEvent -FilterHashTable @{LogName='System'; ID=1} | Format-List TimeCreated, Message ``` Ищите `Reason: Manual Time Change` или `ProcessId: 4` (System) vs другой PID. #### Linux/Unix Для инструментов для выявления подмены времени в цифровой криминалистике: - Журнал `systemd-timesync` или `chronyd` (см. `/var/log/messages`). - Команда `last reboot -F` — покажет изменения uptime, косвенно указывающие на сброс. Инструментально: ```bash grep "timedatectl" /var/log/syslog grep "time set by" /var/log/auth.log ``` Ручная смена через `date` оставит след в `.bash_history` или `auditd` (если включен). #### Дополнительные признаки - Множество записей с одинаковым временем (скоростное изменение). - Расхождение `LastBootUpTime` и времени создания файлов в теневых копиях (Volume Shadow Copy). - Для глубокой проверки — сравнение меток времени файловой системы (`MACE` атрибуты) с логами сторонних сервисов (DNS, прокси). Если время файла раньше/позже на 5+ минут, а лог изменения отсутствует — подозрение на правку. Резюме: Используйте проверку журналов событий изменения системных часов в связке с `Sysmon` (Event ID 1, 3) и `auditd` на Linux. Только это даст однозначный ответ в рамках легальных методов цифровой криминалистики.

Как восстановить переписку из резервной копии?

Проблема: Не удаётся получить доступ к истории сообщений после сброса, переустановки мессенджера или повреждения текущей базы данных. Требуется извлечение данных из ранее созданного бэкапа. Причины: 1. Резервная копия зашифрована (end-to-end encryption, AES-256 для WhatsApp/Telegram). 2. Несовместимость формата: iOS-бэкап (iTunes/iCloud) не читается на Android и наоборот. 3. Повреждение файла резервной копии при переносе или хранении. Решение: 1. Для Android (WhatsApp/Telegram): - Местонахождение бэкапа: `/sdcard/WhatsApp/Databases/` (файлы `msgstore-YYYY-MM-DD.1.db.crypt12/14`). - Инструмент: Elcomsoft Phone Breaker (легален для собственных данных) или WhatsApp Viewer (кроссплатформенная утилита). - Команда (Linux/macOS) для расшифровки Crypt14: ```bash python3 wa_crypt_tool.py decrypt -k -i msgstore.db.crypt14 -o msgstore.db ``` Где `` — извлечённый ключ (через рут или бэкап ADB). - Примечание: для восстановления переписки из резервной копии на андроид без рута требуется сброс и восстановление через Google Drive (только с той же учётной записью). 2. Для iOS (iMessages, WhatsApp): - Извлечение из iTunes-бэкапа: iBackup Viewer (бесплатен, работает без джейлбрейка). - Пароль от бэкапа (если установлен) сбрасывается через Elcomsoft Phone Password Breaker (брутфорс слабых паролей). - Путь к нужной базе: `3d0d7e5fb2ce288813306e4d4636395e047a3d28` (для iMessage). 3. Универсальный метод (любая платформа): - Autopsy (Sleuth Kit) — анализ дампов разделов (требует root/jailbreak). - Magnet AXIOM (платная, демо-версия существует) — автоматическое извлечение и парсинг бэкапов более 200 приложений. - Важно: если вы ищете как извлечь историю сообщений из бэкапа телефона, используйте FTK Imager для создания образа раздела `userdata` и последующего анализа через `sqlite3`. Юридические ограничения (РФ): - Вмешательство в чужие бэкапы без согласия владельца — ст. 138 УК РФ («Нарушение тайны переписки»). - Все методы применимы только к собственным устройствам и данным. Для корпоративной форензики — с письменного разрешения юрлица.

Как проверить, подлинный ли документ или скан?

Проблема: Необходимо установить подлинность предоставленного документа или его скана — выявить признаки монтажа, редактирования или подмены исходного файла. Причины: - Подделка в графическом редакторе (Photoshop, GIMP) — вставка фрагментов, изменение реквизитов, текста. - Сканирование поддельного бумажного носителя, созданного методом цветной струйной печати. - Изменение метаданных или подмена содержимого в многостраничном PDF (например, замена одной страницы). - Генерация полностью синтетического документа через нейросети (GAN, Stable Diffusion) или текстовые редакторы. Решение (легальные методы без нарушения законодательства РФ): ### 1. Визуальная экспертиза и анализ атрибутов файла (первичная проверка подлинности скан-копии документа) - Проверьте DPI и разрешение. Откройте свойства файла (Windows: ПКМ → Свойства → Подробно). Для реального скана характерно значение 200–300 DPI (или 600). DPI ниже 150 или нестандартные значения (72, 96) — признак экспорта из графического редактора, а не сканера. - Анализируйте тени и градиенты. В Photoshop часто остаются следы: неравномерный шум, резкие границы вокруг вставленных объектов, отсутствие естественного шума бумаги на вставке. - Проверьте шрифты и выравнивание. Подделки часто содержат мелкий текст с разным межбуквенным расстоянием (кернингом), «съехавшие» строки или несоответствие шрифта стандартам (например, в паспортах РФ используется шрифт ISOCPEUR). - Используйте увеличение (Zoom 400-800%). Ищите артефакты JPEG-сжатия, крапинки (dithering) на однотонных заливках — признаки скриншота или повторного сохранения. ### 2. Анализ метаданных (EXIF, XMP, PDF) для проверки подлинности электронного документа - Для изображений (JPG, PNG, TIFF): `exiftool -a -u suspect_doc.png` Ищите теги: - `Software` — Photoshop, Adobe Illustrator, Paint.NET → признак редактирования. - `CreateDate` / `ModifyDate` — если даты не совпадают или модификация позже даты документа. - `ImageDescription` — может содержать имя автора или программы. - `History` (XMP) — цепочка изменений (Photoshop History). - Для PDF: `pdfid.py suspect.pdf` (утилита Didier Stevens) — проверка на скрытые действия (JavaScript, OpenAction, EmbeddedFiles). `pdf-parser.py suspect.pdf` — извлечение и анализ всех объектов, поиск встроенных изображений, не соответствующих структуре (например, 5 изображений в 2-страничном документе). Пример команды для выявления скрытого текста в PDF: `python pdf-parser.py -s /Font suspect.pdf` — поиск нестандартных шрифтовых подстановок. ### 3. Форензика JPEG-артефактов (ELA — Error Level Analysis) Метод выявляет области, добавленные позже (вставки), по разности в уровнях ошибок сжатия. Инструмент: `forensically Beta` (онлайн, без регистрации) или скрипт Python: ```python from PIL import Image, ImageChops, ImageFilter import sys input_image = sys.argv[1] im = Image.open(input_image) im.save('/tmp/temp_ela.jpg', 'JPEG', quality=95) ela_im = Image.open('/tmp/temp_ela.jpg') diff = ImageChops.difference(im, ela_im) diff = diff.filter(ImageFilter.GaussianBlur(radius=2)) diff.save('ela_output.png') ``` Области с яркими пикселями (отличие от фона) — вероятные места редактирования. ### 4. Проверка шумов датчика сканера (Sensor Noise Pattern) Для профессиональной проверки подлинности скана документа: Сравните равномерный шум фона (нулевая точка, белая область) с эталонным шумом конкретной модели сканера. Любая вставка будет иметь другой рисунок шума. Инструмент (закрытый код, не для нарушений): PRNU analysis через `python prnu` (библиотека). Легально используется только на собственных эталонных сканах, полученных законно. ### 5. Криминалистическая экспертиза бумажного носителя (если есть физический документ) - Ультрафиолетовая лампа (365 нм). Настоящий документ (паспорт, диплом) содержит защитные волокна, реагирующие свечением. Поддельная струйная печать даёт яркую фиолетовую засветку всей поверхности. - Тактильный анализ. Используйте пальцы и лупу: на реальном документе текстура печати глубокая (trapping, рельеф), на струйной — плоская, глянцевая. - Микроскоп (80-200х). Растровые точки струйного принтера имеют характерную «кляксу» (bleeding), в отличие от четких листовых растров офсета. ### Итоговая последовательность действий для проверки подлинности документа: 1. Запросить оригинал файла без перекомпрессии (RAW, TIFF, не JPEG). 2. Запустить `exiftool` на изображение и PDF — отсечь 80% подделок с редактированием. 3. Выполнить ELA-анализ (Python или онлайн) — найти вставки. 4. При физическом документе — УФ-лампа + микроскоп. 5. При высоких рисках — обратиться в аккредитованную лабораторию судебной экспертизы (не нарушая тайну следствия, если это ваше дело). Важно: Ни один метод не даёт 100% гарантии без доступа к эталонному образцу сканера и бумаги (например, госконтракт). Указанные техники легальны, не требуют инвазивного доступа и не нарушают законодательство РФ.

Как восстановить файлы после переустановки системы?

Проблема: После переустановки ОС данные на системном разделе (C:\) недоступны. Файлы кажутся потерянными, но физически сектора диска не затерты мгновенно. Причины: - Форматирование или перезапись разделов установщиком Windows/Linux. - Новые данные (файлы ОС) частично перезаписали старые кластеры, где хранились ваши файлы. - Файлы не удалены, а помечены как «свободное место» — структура файловой системы (MFT для NTFS, суперблоки для ext4) повреждена или перезаписана частично. Решение (пошагово, без права на ошибку): 1. Немедленное действие: Отключите компьютер. Не загружайте переустановленную систему с установочного диска. Любая запись (логи, кэш браузера, установка драйверов) уменьшает шансы на восстановление остатков данных. 2. Загрузка с Live-CD/USB (дистрибутив Linux): Загрузитесь с Ubuntu USB. Не монтируйте раздел автоматически — откройте терминал. 3. Создание посекторной копии (наиболее надежно для восстановления битых файлов после переустановки системы): ```bash sudo dd if=/dev/sda1 of=/mnt/external_drive/disk_copy.img bs=64K status=progress ``` Работать ТОЛЬКО с копией, а не с диском. 4. Анализ сканов на копии: - PhotoRec (CGSecurity) — восстановление по сигнатурам (фото, документы, архивы). Запускать на образе: ```bash sudo photorec /mnt/external_drive/disk_copy.img ``` - TestDisk — восстановление структуры разделов, если таблица разделов затерта. 5. Использование DMDE (оптимальный вариант для NTFS после переустановки): - Запустите DMDE с Live-CD. - Откройте образ диска → выберите «Полный скан». - В результатах ищите папки с именем `$Root`, `$Recycle.Bin`, `$User` — это остатки старой структуры. - Восстановите только критически важные файлы (в DMDE это бесплатно для мелких файлов). Критическое предупреждение: - Шанс восстановления падает с каждым часом работы переустановленной системы. Если прошло >2 дней, 90% данных перезаписаны. - Не используйте R-Studio, Recuva на активной системе — они пишут временные файлы на восстанавливаемый раздел. - Для профессионального восстановления (сложные битые файлы) — обращайтесь в лаборатории, работающие с аппаратными дубликаторами (PC-3000).

Как узнать, кто заходил в соцсеть с моего телефона?

Проблема: Подозрение на несанкционированный доступ к вашему аккаунту соцсети с вашего же устройства. Необходимо установить факт и источник доступа. Причины: 1. Фишинг или вредоносное ПО на телефоне (кейлоггер, стилер cookie). 2. Компрометация сессии (перехват cookie при подключении к публичным Wi-Fi). 3. Уязвимость в браузере/ОС (редко, но актуально для устаревших версий Android/iOS). 4. Реальный физический доступ к разблокированному устройству (друг/родственник) с последующим запуском приложения. Решение (только легальные методы, ч. 272-273 УК РФ не нарушаем): 1. Проверка истории входов в соцсеть на телефоне (основной метод). ВКонтакте: Настройки → Безопасность → История активности. Ищите IP, тип устройства (iOS/Android/Web) и метку времени. Несовпадение модели телефона с Вашей — признак чужого доступа. Telegram: Настройки → Конфиденциальность → Активные сессии. Завершите все, кроме текущей. Instagram/Facebook: Настройки → Центр аккаунтов → Пароль и безопасность → Где вы вошли. Одноклассники: Настройки → Мои действия → История входов. 2. Анализ логов авторизации Google/Apple ID (поможет при входе через SSO). Android: myaccount.google.com → Безопасность → Ваши устройства и Недавние действия по безопасности. iPhone: appleid.apple.com → Вход и безопасность → Статус учетной записи → История входов. 3. Локализация по IP из истории входов (ограниченно). Скопируйте IP-адрес из логов соцсети. Через whois-сервис (например, 2ip.ru) определите провайдера и город. Совпадение с вашим домашним Wi-Fi — исключает удаленный доступ, но не локальный. 4. Проверка на наличие программ для слежки на телефоне без рут-прав (Android). Зайдите в Настройки → Приложения → Все приложения. Ищите приложения с пустыми иконками, странными названиями (типа `com.monitor.xxx`), или те, у которых запрошено разрешение "Поверх других окон". Пример команд (терминал Android, если есть adb): ``` adb shell dumpsys usagestats ``` Выдаст список приложений со временем последнего запуска. 5. Экстренное завершение всех сессий. В настройках безопасности соцсети нажмите "Завершить все сессии" (или "Выйти на всех устройствах"). После этого немедленно смените пароль на сложный (30+ символов, через менеджер паролей). Включите двухфакторную аутентификацию (2FA) — это 95% защиты. Важно: Стандартными средствами ОС (без рута/jailbreak и установки сомнительного ПО) посмотреть полный лог открытия приложений и переходов внутри соцсети невозможно. Инструменты типа Dr.Fone или iMobie могут читать удаленные данные, но не логи активных сессий. Единственный достоверный источник — серверный лог самой соцсети (п.1).

Как проверить, редактировали ли таблицу после сохранения?

Проблема: Необходимо достоверно определить, вносились ли изменения в таблицу (Excel, SQL, CSV) после её последнего сохранения, без доверия к встроенным датам файловой системы (которые легко подделываются). Причины: 1. Подмена метаданных: Дата «Изменено» в свойствах файла может быть изменена через `SetFileTime` или атрибуты. 2. Необновление даты: Редактирование без сохранения не меняет дату файла. 3. Ложный след: Восстановление предыдущих версий (Shadow Copy) может перемешать временные метки. Решение (3 уровня глубины): 1. Базовый — хэш-контроль (для контрольных точек) - Если есть эталонный хэш (MD5/SHA256) файла сразу после сохранения, вычислите текущий: ```cmd certutil -hashfile "C:\table.xlsx" SHA256 ``` - Ограничение: Работает только при заранее взятом хэше. Не покажет факт неавторизованного редактирования, если эталона нет. 2. Продвинутый — метаданные файла таблицы в контексте версий - Проверка версий файла (Windows Previous Versions): - Клик ПКМ по файлу → «Свойства» → «Предыдущие версии». - Если версии отличаются по размеру/дате — минимум одно сохранение после даты эталона. Не говорит о редактировании — только о факте записи. - Анализ метаданных OOXML (для .xlsx/.xlsm): - Распакуйте `file.xlsx` (это ZIP) и проверьте `docProps/core.xml`: ```xml 2024-03-15T10:00:00Z ``` - Если `modified` > даты эталонного сохранения — прямое доказательство редактирования. Дата подделывается только через распаковку и правку XML. 3. Форензика — анализ логов файловой системы ($MFT/JumpList) - NTFS $MFT (Master File Table): - Используйте `MFT Explorer` или `$MFT` парсер. - Сравните атрибуты `$STANDARD_INFORMATION` (SI) и `$FILE_NAME` (FN). - Признак редактирования: Время `$SI.Modified` — время последнего изменения данных. Если `SI.Modified` > `FN.Creation` — изменение было. - Команда извлечения (только для экспертов, читать блок RAW): ```cmd fsutil mft readFile C:\ 0x1C0 > mft_dump.txt (пример для ручного разбора) ``` - Jump Lists (Windows 10/11): Содержат историю открытия и сохранения конкретных файлов приложением (Excel, Notepad++). Анализ через `JLECmd.exe` или вручную `%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\`. - Результат: Даты последнего сохранения в Excel — если дата в Jump List позднее эталона, файл редактировали. Итоговая рекомендация для OSINT/форензики: - Наиболее надёжный метод без эталонного хэша — сопоставление атрибутов $MFT (SI vs FN) и анализ `docProps/core.xml` внутри OOXML-контейнера. - Для баз данных (SQLite/MySQL) — проверка WAL-журнала (Write-Ahead Log) — если размер журнала >0 при закрытой БД — были изменения после последнего сохранения (CHECKPOINT).

Как восстановить данные с телефона после падения в воду?

### Проблема Телефон не включается после падения в воду, данные недоступны. Риск потери информации из-за короткого замыкания и коррозии контактов. ### Причины 1. Попадание воды на материнскую плату → электролиз под напряжением → окисление контактов и дорожек. 2. Влага в разъемах (USB, SIM, карта памяти) → коррозия контактов → потеря связи с накопителем. 3. Если устройство было включено: короткое замыкание цепей питания → выход из строя контроллера NAND или eMMC. 4. Повреждение аккумулятора (вздутие, утечка) → риск воспламенения при попытке зарядки. ### Решение (легальные методы, только для собственного устройства или с письменного согласия владельца) #### Этап 1. Немедленные действия (до высыхания) - НЕ включать! Отключить питание (вынуть батарею, если съемная). - Не заряжать, не подключать к ПК — подача напряжения ускоряет коррозию. - Извлечь SIM и карту памяти — их данные часто сохраняются. Просушить карту памяти отдельно (силикагель, рис на 48 часов). #### Этап 2. Сушка и очистка - Разобрать телефон (открутить все винты, снять экран, отделить плату). - Промыть плату изопропиловым спиртом (99%) — он вытесняет воду и не проводит ток. - Ультразвуковая ванна с изопропанолом (5-10 мин, 40 кГц) — удаляет солевые отложения. - Сушка: 24-48 часов при 40-50°C (не СВЧ, не фен без контроля температуры!). Идеально — сушильный шкаф или силикагель. #### Этап 3. Диагностика и восстановление данных с телефона после падения в воду - Если плата не повреждена, но не включается: заменить аккумулятор, проверить тестером напряжение на контактах питания. Подключить через USB-тестер (ток потребления

Как увидеть, какие устройства подключались к ПК?

Вот структурированный ответ для ForensicAnvil.ru, без воды, по запросу «как увидеть, какие устройства подключались к ПК». ### Проблема: Необходимо определить, какие USB-устройства и внешние накопители когда-либо подключались к данному компьютеру Обычно требуется при расследовании инцидентов: выявление факта копирования данных на флешку, определение неизвестного устройства (мышь/клавиатура) или поиск следов подключения мобильного телефона. ### Причины: Сложность обнаружения из-за очистки журналов Пользователь мог удалить историю подключений через стандартный интерфейс. Реестр Windows или журналы событий могли быть частично перезаписаны. Требуется анализ скрытых ключей реестра и логов Plug and Play. ### Решение: Извлечение истории с помощью реестра и журналов событий Используйте только встроенные средства Windows или легальное ПО (Sysinternals, NirSoft). 1. Просмотр истории подключений USB-накопителей через реестр (USBSTOR) Самый надежный способ. Откройте `regedit` от имени Администратора. Путь: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR` Что смотреть: Каждый GUID (например, `Disk&Ven_SanDisk&Prod_Ultra&Rev_1.00`) — это уникальное устройство, подключавшееся к ПК. Дата первого/последнего подключения: Перейдите в ветку `...\Properties\{83da6326-97a6-4088-9453-a1923f573b29}` (0064 — первое подключение, 0066 — последнее). Декодируйте значение `0064` (FILETIME) с помощью PowerShell: ```powershell [datetime]::FromFileTime((Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\DISK&VEN_SANDISK&PROD_ULTRA&REV_1.00\4&1a2b3c4d&0\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0064").'(default)') ``` 2. Определение устройств, подключавшихся к компьютеру, через журналы событий (Event Viewer) Используйте для поиска конкретных дат, когда было вставлено устройство. Путь: `Приложения и службы > Microsoft > Windows > Partition > Diagnostic` Event ID 1006: Фиксирует подключение нового диска (например, флешки). Что смотреть: Вкладка «Подробно» -> `FriendlyName` (имя накопителя) и `VolumeSize` (объем). Путь: `Приложения и службы > Microsoft > Windows > DriverFrameworks-UserMode > Operational` Event ID 2003: Логирует подключение любого USB-устройства (клавиатура, веб-камера, модем). Event ID 2100: Логирует отключение. 3. Программное извлечение (легальные утилиты) Если нужно выгрузить историю в отчет без ручного копания в реестре: USBDeview (NirSoft): Показывает все USB-устройства, подключавшиеся к системе, с датами, серийными номерами и меткой «Отключено/Подключено». Не требует установки. PowerShell (встроенный): Экспорт ключей реестра в CSV. ```powershell Get-ChildItem -Path "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR" -Recurse | ForEach-Object { $_.PSPath } | Out-File -FilePath C:\usb_history.txt ``` SEO-вкрапление: Для точного просмотра истории подключений USB и определения устройств, подключавшихся к компьютеру, ключевым является анализ ветки USBSTOR. Если вы хотите увидеть, какие устройства подключались к ПК в прошлом, не полагайтесь на визуальную историю в панели управления — используйте реестр или журналы Microsoft-Windows-Partition/Diagnostic. Важно: Анализ должен проводиться на выключенной системе или смонтированном образе диска (для forensic-экспертизы). Манипуляции с реестром могут повлиять на работу системы — работайте с копией реестра или read-only.

Как проверить, с какого IP заходили в аккаунт?

### Проблема Вы подозреваете, что в ваш аккаунт (почта, соцсети, мессенджер) заходили с незнакомого IP-адреса. Необходимо извлечь и проанализировать историю входов в аккаунт по IP для выявления утечки или взлома. ### Причины - Кража пароля через фишинг или утечку БД. - Активная сессия на чужом устройстве (например, общественный ПК, VPN с вредоносным узлом). - Бездействие пользователя: не отозваны сессии, не включена 2FA. ### Решение Пошаговая инструкция по получению логов авторизации в аккаунте для наиболее популярных сервисов. #### 1. Google (Gmail, YouTube) - Перейти: `myaccount.google.com` → Безопасность → Секция «Ваши устройства» → Управление всеми устройствами. - Нажать на сессию → отобразится IP и время. Для экспорта: Журнал активности → скачать в JSON (там полные метаданные, включая User-Agent и IP). - Альтернатива: `myaccount.google.com/data-and-privacy` → Скачать данные → выбрать только «Сведения об устройствах и действиях». Это стандартный метод анализа логов безопасности Microsoft/Google. #### 2. Яндекс (Почта, Диск) - `passport.yandex.ru` → История входов (или Безопасность → Последние действия). - Время, IP, регион. Клик по записи — User-Agent. Кнопка «Завершить все сеансы». - Для глубокого OSINT-анализа по IP-адресу используйте `whois` или `ipinfo.io` прямо в браузере. #### 3. VK / Одноклассники - VK: Настройки → Безопасность → Показать историю активных сессий. - OK: Настройки → Безопасность → История входов. - Сохраняет IP, браузер, устройство. Есть отметка «мобильное приложение» и GPS-координаты (если дано разрешение). #### 4. Discord - `discord.com/settings/Authorized Apps` → Пролистать вниз → Смотреть историю входов. - IP, метка местоположения (по GeoIP), Device Fingerprint. - Команда `/sessions list` (бот Dyno или в терминале приложения) не покажет IP, только сессии — это неполноценный мониторинг входов через лог активности. #### 5. Microsoft (Outlook, Azure) - `account.microsoft.com/security` → Просмотр активности входа. - Данные: IP, приложение, успех/неудача, крайне полезно для расследования инцидентов форензики. - SSH/API: `Get-AzureADAuditSignInLogs` (PowerShell, для глобальных администраторов). #### 6. Экспорт через IMAP/POP3 (для собственного ПО) - Проверить `Received`-цепочку письма. Алгоритм: ```bash # Найти последний внешний IP перед вашим MTA curl -X VERP -T email.eml https://mxtoolbox.com/ | grep "Received: from" ``` - Для Telegram: `@userinfobot` (выдает IP пользователя, если он ввел /start — но это не история входов, а разовая проверка). ### Заключительный совет по безопасности - Включите 2FA (TOTP, а не SMS) — это снижает вероятность несанкционированного доступа по украденному IP. - После анализа журнала активности входа — смените пароль и отзовите все устройства. - Используйте VPN только с адресом, который не совпадает с вашим регионом входа (если вы в Москве, а лог из Питера — подозрительно). Легальность: все данные получаются через штатные интерфейсы сервисов (запрос данных самого пользователя). Статья 138 УК РФ не применима при анализе собственных логов.

Как восстановить файлы, если программа вылетает при открытии?

Проблема: Утилита восстановления данных (R-Studio, GetDataBack, DMDE) аварийно завершает работу при попытке открыть том или запустить сканирование. Причины: 1. Критическое повреждение файловой системы (RAW/bad boot sector): Драйвер ФС вызывает Access Violation при парсинге $MFT/FAT-таблицы. 2. Дефекты носителя (Read/Write Error): Программа пытается считать сбойный сектор, ядро ОС «вешает» вызов — таймаут, крах. 3. Проблема с виртуальной памятью (логин-сессия): Огромный образ или битый диск создает своп-файл на нестабильном винчестере. 4. Отсутствие прав администратора или конфликт драйвера низкого уровня. Решение (пошагово, без GUI, если возможно): 1. Обход краха утилиты: - Используй консольную версию той же программы (например, `R-Studio CLI`, `dmde.exe /L`). - Загрузись с Live USB (Linux LiveCD — Ubuntu/Debian) и восстановление с помощью `ddrescue` + `testdisk/photorec`. Вылеты при открытии программы Windows не повлияют. 2. Диагностика и изоляция дефектов (восстановление файлов с поврежденного диска): - Сначала создай посекторную копию диска в безопасную среду: ```bash # Linux sudo dcfldd if=/dev/sdb of=/mnt/backup/image.dd bs=512 conv=noerror,sync status=progress ``` - Затем «реконструкция» образа через тестирование поверхности. Если крах вызван битым сектором — работа только с образом с файлом лога ошибок. 3. Ремонт файловой системы без открытия тома: - Запусти `chkdsk X: /f /r` (только если не на диске с проблемой — риск). Лучше — `fsck` в Linux на отмонтированной ФС. - Используй `TestDisk` (режим Quick/Deep Scan) для перестроения таблицы разделов. Запускай из командной строки (Win/Linux) — краш утилит восстановления обычно обходится. 4. Действия в случае, когда программа вылетает при открытии файловой системы: - В DMDE: диалог выбора тома -> пропустить «Авто-детект» -> «Выбрать логический диск» -> Прочитать MBR/GPT отдельно (Ctrl+D). Если получение структуры падает — диск умер аппаратно. - Открывай образ в `HxD` (hex-редактор) — если сам редактор не падает, проблема в драйвере ФС, а не в носителе. 5. Аппаратное решение (если софт валится из-за bad blockов): - Подключи проблемный диск через USB-мост. Используй `Victoria for Windows` или `HDD Regenerator` для «обхода» уцелевших секторов (кратковременное отключение таймаутов SATA). Только если данные не критичны. Ключевой принцип: Никогда не запускай утилиту восстановления напрямую на умирающем диске — только на его образе. Сбой при открытии программы — 90% аппаратных дефектов поверхности.

Как узнать, меняли ли время на компьютере?

### Проблема Факт изменения времени — весомый аргумент в цифровой криминалистике: позволяет выявить сокрытие следов, манипуляции с логами или алиби. Задача — доказать, что системные часы были переведены вручную или с помощью стороннего ПО. ### Причины 1. Смена часового пояса — легитимно, но редко. 2. Ручная правка через интерфейс ОС или утилиты (`date`, `timedatectl`). 3. Синхронизация с NTP (ошибка сервера, подмена). 4. Сброс CMOS-памяти (разряд батарейки, отключение питания). 5. Злонамеренные действия — подмена времени для обхода лицензий, фальсификации действий в логах, алиби. ### Решение Проверка фальсификации системного времени на компьютере требует анализа журналов Windows Event Viewer (ID 1, 4616) или syslog на Linux. #### Windows 1. Откройте Event Viewer → Windows Logs → System. 2. Фильтр по ID события 1 (изменение времени) или 4616 (системное время изменено). 3. Анализ: записи содержат предыдущее и новое время, причину (ProcessId, User). Если `TimeChange` не совпадает с шагом синхронизации NTP — ручное вмешательство. Анализ событий изменения системных часов Windows через PowerShell: ```powershell Get-WinEvent -FilterHashTable @{LogName='System'; ID=1} | Format-List TimeCreated, Message ``` Ищите `Reason: Manual Time Change` или `ProcessId: 4` (System) vs другой PID. #### Linux/Unix Для инструментов для выявления подмены времени в цифровой криминалистике: - Журнал `systemd-timesync` или `chronyd` (см. `/var/log/messages`). - Команда `last reboot -F` — покажет изменения uptime, косвенно указывающие на сброс. Инструментально: ```bash grep "timedatectl" /var/log/syslog grep "time set by" /var/log/auth.log ``` Ручная смена через `date` оставит след в `.bash_history` или `auditd` (если включен). #### Дополнительные признаки - Множество записей с одинаковым временем (скоростное изменение). - Расхождение `LastBootUpTime` и времени создания файлов в теневых копиях (Volume Shadow Copy). - Для глубокой проверки — сравнение меток времени файловой системы (`MACE` атрибуты) с логами сторонних сервисов (DNS, прокси). Если время файла раньше/позже на 5+ минут, а лог изменения отсутствует — подозрение на правку. Резюме: Используйте проверку журналов событий изменения системных часов в связке с `Sysmon` (Event ID 1, 3) и `auditd` на Linux. Только это даст однозначный ответ в рамках легальных методов цифровой криминалистики.