Поиск определенного магического байта в океане файлов

Установите диспетчер настроек CompizConfig. sudo apt-get install compizconfig-settings-manager Перейдите на вкладку Ubuntu Unity Plugin. Измените Скрыть Пусковую установку на Никогда, и вернитесь. Прокрутите вниз до вкладки «Место Windows». Поэкспериментируйте с режимом размещения, пока не найдете то, что ищете.

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

1
задан 11 February 2016 в 22:20

3 ответа

Я попробую дать вам несколько советов, чтобы вы могли самостоятельно решить свой HW.

Выполните следующие шаги:

прочитайте руководство по file, выполнив man file , Затем попробуйте file somefile и посмотрите, что произойдет. Попробуйте запустить file для разных типов файлов. Теперь вы должны понимать, как определить, является ли какой-либо файл jpeg-изображением или нет. теперь прочитайте руководство для find (или используйте google, чтобы узнать, как использовать его для поиска всех файлов в какой-либо директории и во всех подкаталогах), теперь узнайте, как использовать опцию -exec для find, чтобы соединить ее с ранее использовавшаяся команда file Теперь вы можете узнать типы файлов всех файлов в нужном каталоге и перечислить их. Теперь прочитайте о командах pipe | и grep, чтобы узнать, как фильтровать только файлы JPEG.
12
ответ дан 23 May 2018 в 13:36
  • 1
    Очень хороший ответ, научите человека ловить рыбу, не давая рыбу. Upgoated. Продолжайте делать хорошую работу! – Sergiy Kolodyazhnyy 11 February 2016 в 22:16
  • 2
    большое спасибо за ваше упрощение, прямо сейчас моей единственной проблемой является знать, использовать -exec вариант find для подключения к команде file – adib 11 February 2016 в 23:08
  • 3
    Чтение @adib это должно помочь вам. – incBrain 11 February 2016 в 23:12
  • 4
    @incBrain Я запустил код, который выглядит как find / -exec file {} \; | grep "SN", но он пробежал все файлы, которые я думаю – adib 12 February 2016 в 11:07
  • 5
    Я отправил его в качестве ответа, большое спасибо за ваши инструкции :) @incBrain – adib 13 February 2016 в 17:21

Одним из возможных решений может быть следующее: use find, который рекурсивно перечисляет обычные файлы (-type f) и выполняет команду file для каждого из них. Перенесите вывод в grep, чтобы отфильтровать типы файлов.

Однако здесь я хотел бы сделать что-то более интересное;

$ find .  -maxdepth 1 -type f -printf "%f\t" -exec hexdump -n8 {} \;  | awk '/d8ff e0ff 1000 464a/{print $1}'

Поскольку вы можете или не знать, что каждый файл имеет первые 8 байтов любого файла, обозначающий тип файла. Таким образом, используя find, мы ищем все обычные файлы, печатаем его имя, но затем выполняем hexdump для извлечения первых 8 байтов, и пусть awk фильтрует только те имена файлов, у которых эти первые 8 байтов.

Вот небольшое доказательство:

$ hexdump -n 10 1450763029649.jpg               
0000000 d8ff e0ff 1000 464a 4649               
000000a

$ hexdump  -C -n 10 1450763029649.jpg           
00000000  ff d8 ff e0 00 10 4a 46  49 46                    |......JFIF|
0000000a
2
ответ дан 23 May 2018 в 13:36
  • 1
    Хороший материал, используя hexdump +1. Однако я не уверен в первых 8 байтах. Я рассмотрел стандарт JPEG (Приложение B), и он сообщает, что первые 2 байта являются StartOfImage (SOI 0xFFD8), а затем есть 2 байта кадра и 2 байта размер кадра, следующий за кадром полезная нагрузка. Заголовок кадра 0xFFE0 относится к данным приложения, и в вашем случае длина данных приложения 2 байта равна 0x0010 = 16 байт – incBrain 12 February 2016 в 00:59
  • 2
    хорошо, поэтому для JFIF мы можем быть уверены, что после SOI будет JFIF-APP0, а первые 8 байтов этого сегмента (или первого 10 файла) будут содержать 100% строку JFIF. Я экспериментировал с перемещением этого сегмента APP в другое место в файле, и действительно file все еще распознал его как JPEG, но не как JFIF – incBrain 12 February 2016 в 01:34
  • 3
    @incBrain Ну, помните, что команда file работает практически так же - сначала проверяет несколько байтов. Но в то же время, когда вы заменяете часть APP, вы, вероятно, смещаете последовательности бит, поэтому то, что однажды могло быть 1010 в двоичном формате, теперь станет 0101 для примера. Разве это изображение все еще открыто? – Sergiy Kolodyazhnyy 12 February 2016 в 02:23
  • 4
    Кроме того, я заметил что-то очень интересное, мой процессор немного ориентирован, поэтому, как он сообщает данные, сначала младший байт. Итак, первые четыре байта 0xFFD8E0, но посмотрите, как сообщает hexdump: d8 ff e0 d8 – Sergiy Kolodyazhnyy 12 February 2016 в 02:27
  • 5
    Таким образом, это значит, что изображение может быть повреждено, но мы все еще можем знать, что это изображение только с первых двух байтов, помня о том, как обрабатываются данные – Sergiy Kolodyazhnyy 12 February 2016 в 02:43
file * | grep -i "jpeg"

Это будет поиск по каждому файлу в каталоге и возврат его типа файла. Через Pipe | эти результаты затем проверяются grep, чтобы найти файл с типом файла «jpeg» или в основном файл .jpg.

0
ответ дан 23 May 2018 в 13:36

Другие вопросы по тегам:

Похожие вопросы: