Есть 2 задачи, обе по нахождению возможной скрытой информации на разделах с файловой системой NTFS. Первая -> связана со скрытием информации в конце тома после конца файловой системы (файловую систему при этом как бы усекают) => необходимо сравнить размер тома с размеров файловой системы (по умолчанию правда размер тома должен быть на один сектор больше, т.к. в самом конце хранится копия boot сектора) Правильно ли я понимаю, что размер файловой системы храниться в системном файле $Boot, а размер тома можно найти в MBR? и как прочитать эту ячейку MBR? (подозреваю, что просто с помощью ReadSector...) Вторая задача намного сложней. Речь идёт о скрытии данных в "битых" кластерах.(например при ручном редактировании метафайла $BadClus) Вообще как я понял это некий пережиток прошлого, когда жёсткие диски не могли сами себя тестировать и заменять битые сектора (именно сектора!... в NTFS если хотя бы один сектор кластера будет 3 раза неудачно прочитан, то весь кластер будет отмечен "битым" в файле $BadClus) на сектора из резервной области. Сегодня впринципе такая функция уже не нужна, т.к. на сколько я знаю ЖД определяют битые сектора раньше чем их увидит файловая система. Однако вопрос в следующем: отмечаются ли сектора, которые NTFs воспринимает как битые, где-то в служебной области ЖД? Да и вообще целесообразно ли скрывать информацию под видом битых кластеров в файловой системе? Также хочу поинтересоваться о возможности сокрытия информации под видом используемых кластеров (банально изменяя битовую карту $Bitmap). Ведь в этом случае придётся проводить достаточно обширную проверку: действительно ли эти кластеры принадлежат како-либо файловой записи... А если количество файлов на разделе порядка тыщ этак 500..... Плюс на засыпку прошу высказать соображения по отношению помещения скрытых данных в неиспользуемые части записей MFT и атрибутов. Да, природа NTFS динамична, т.е. записи могут обновляться достаточно часто и просто затереть эти скрытые данные при выделении новому файлу, либо при расширении исходного (так происходит например с документами word). НО политика выделения записей такова, что чаще перезаписываются те записи, которые находятся ближе к началу MFT, а записи в самом конце могут сохранять какие-то старые данные достаточно долгое время.. что скажете?
check disk именно этим и занимается.. с "битыми" кластерами идея самая реальная, но такие кластера как на ладони можно стеганографию попробовать.. типа поиграться с каким-нибудь редкоиспользуемым битиком, типа "archived", и по характеру его распределения восстанавливать закодированные данные.. )))
Кстати если есть идеи про то где ещё можно спрятать данные в NTFS, напишите плиз. Буду очень благодарен. (только не пишите про дополнительные потоки данных и концы последних кластеров в файлах... это я уже собственно реализовал)
Nouzui Идея интересная канешна, но я говорю о поиске скрытых данных целиком (т.е. например если мы сняли образ ЖД возможного злоумышленника и хотим найти что-то) Короче я пишу что-то типа программы криминалистического анализа файловой системы.(кстати на эту тему советую читать Кэрриэ "Криминалистический анализ файловых систем") Кстати про идею с битыми кластерами (на уровне файл. системы) или секторами (на уровне ЖД). Если каким-то образом в системой области ЖД сектора были помечены битыми, то как программно их можно увидеть/прочитать?.... Существуют целые программно-апппаратные комплексы типа PC3000, которые лезут в системную область ЖД, причём делают это только для определённых моделей ЖД опрелённых производителей так как архитектура микроконтроллера меняется от версии к версии... Можно как-то это сделать программно, не заморачиваясь на архитектуре конкретного ЖД? Как? (подозреваю что это непосильная работа для одного программмиста....) А насчёт уровня файловой системы.... Как узнать, собственно, действительно ли какой-то сектор в кластере который указан как битый является неисправным??
программы? криминалистического?? анализа??? ну ты хватанул )) типа ПО "Гайка"? насчет реально перемещенных секторов не знаю - разве их вообще можно реаллокейтить программно? а как отличить битый от замаскированного.. протестить, наверное - читается/не читается.. хотя тоже не факт, что если сектор читабельный, то был скрыт умышленно короче, хз
Ну да типа того.. Курсовая кароче такая. Если честно то я уже успел пару раз утонуть в своём же коде, используя native api функции, параллельно вкуривая справочник Неббета и книжку Руссиновича... В общем жду с нетерпением любых соображений по теме
ntcdm я уже это реализовал, только назвал это не файловый поток, а дополнительный поток данных у определённого файла. (см. выше) Кстати, что имелось ввиду: цитирую
Чтоб не создавать тему, спрошу здесь. Как можно проверить наличие у файла дополнительного потока средствами API?
средствами Native Api -> есть такие функции замечательные NtQueryEaFile, NtQueryInformationFile. (справочник по Native Api в помощь) А если знаешь имя дополнительного потока данных у файла (папки), его можно смотреть даж с помощью командной строки. (смотри команду more, потоки данных отделяются от имени двоеточием - file.txt:field1)
