» X-Ways WinHex

WinHex 18.5 SR-3
[more=Изменения]SR-1:
* Opening the entire memory of a running process failed in the 32-bit edition since v18.4. That was fixed.
* Prevented "Invalid file" error message, which some users experienced repeatedly during volume snapshot refinement. (For those who thought that the only way to stop it was the terminate X-Ways Forensics with the Windows Task Manager, please be reminded that you can abort operations such as volume snapshot refinements by clicking the "x" in the upper right corner of the progress indicator window.)
* Fixed potentially incomplete output of the Export List command with the clipboard option depending on the (invisible) "Max. lines per file" setting.
* Some minor improvements.

SR-2:
* Fixed an exception error that could occur when matching files against the FuzZyDoc hash database.
* Fixed an infinite loop that could occur when carving certain rare corrupt zip archives.
* Prevents redundant line breaks in the Metadata columns.
* Prevents some garbled characters in the registry report for Windows 10 System hives when created with the 64-bit edition.
* Some minor improvements.

SR-3:
* When searching in files that were opened through the operating system (through your own drive letter), when also searching in their directory browser cells, in GREP syntax, without allowing overlapping hits, if there was a hit in a directory browser cell, additional hits in the file contents were ignored. That was fixed.
* The raw Base64 to binary conversion now ignores space and tab characters in addition to line breaks.
* Fixed a rare exception error that could occur when viewing an Ext* .journal file.
* Russian and Chinese translation of the user interface updated.
* Fixed a formatting error in metadata extraction in the previous release.
* The evaluation version of WinHex may now be used free of charge to interpret evidence file containers that contain no more than 1000 objects. (subject to change)
* Some minor improvements.[/more]

WinHex 18.5 SR-7
[more=Изменения]SR-4:
* Proper type display and file type treatment for files carved in unpartitioned space on physical media.
* Sector sizes other than 512 bytes supported for Ext file systems.
* Fixed omission of file system level timestamps of certain files without file contents in the event list.

SR-5:
* v18.5 parsed certain directories in exFAT volumes incompletely. That was fixed.
* Some minor improvements.

SR-6:
* Fixed an error that could occur when interpreting images that are stored in other images or disks without copying them off the image or disk first.
* Fixed a rare error that could occur during e-mail extraction from Outlook Express DBX files.
* Fixed inability to display the cell texts of events that are not related to any file.
* Fixed certain occurrences of the error message "The viewer component does not accept your path for temporary files" in v18.5.

SR-7:
* Now supports path lengths of 255 characters for the temp directory of the viewer component in case the path consists of pure ANSI code page characters only. If at least 1 true Unicode character is present in the path, the limit is 127 characters. In v18.4 and earlier the limit was 255 ANSI code page characters, and true Unicode characters were not allowed. In v18.5 prior to SR-7 the limit was 127 characters, and Unicode characters were allowed.
* MSG file processing slightly revised.
* No skin color percentages or PhotoDNA hash values are computed any more for JPEG pictures that are considered too corrupt, e.g. truncated in such a way that more than 50% missing.
* PhotoDNA hash values are now stored in the volume snapshot for re-matching and deduplication even for trivial single-color pictures.
* Some other minor improvements.[/more]

WinHex 18.6
Изменения
* Option to limit the number of produced video stills per video as defined by the user (1-255), no matter the play length. Useful to significantly decrease the output compared to fixed-length still intervals for longer videos. (Fixed-length intervals result in number of stills that grows proportionally with the play length.) This may decreases your workload a lot if you are going to look at all stills in the gallery, and also decreases the time to process long videos, but of course at the cost of being less thorough and an increased risk of missing something should any suspect hide relevant content somewhere within an innocuous video. X-Ways Forensics tries to extract the fixed number of stills evenly from all over the video to give a representative impression of it.
* Revised detection of and protection against of zip bombs. Newly introduced detection of and protection against recursive zip and gz archives and possibly other archive types. Protection means that processing will stop at a certain level once the malicious nature of the archive is detected. Archives identified in this fashion will be marked as already processed and added to a special internal report table. Please note that if afterwards you wish to manually dig deeper than the level at which the recursive automatic exploration stops, you can do so by marking the inner-most archive reached as still to be processed (by pressing Ctrl+Del) and then applying the Explore command in the context menu to it manually.
* Maximum length for the simple search and replace functions extended from 50 to 100 bytes.
* Lists groups and group members in the registry viewer and register report.
* Unix and DOS attributes of files in zip archives are now output in Details mode in a decoded form.
* Some minor improvements.
* Same fix level as v18.5 SR-2.

Случайно перезаписал txt фаил с таким же именем
Как восстановить старый фаил?
Кто то подскажет сигнатуру для txt фаилов ?

MarioN777

Цитата:

Случайно перезаписал txt фаил с таким же именем...

Переписали где, в какой-то Windows-системе? Там у текстовых файлов сигнатуры никакой нет. Перечень разных сигнатур для поиска есть в папке самого Winhex-а. Называется File Type Signatures Search.txt.

WinHex 18.6 SR-2
SR-1:
* Improved FuzZyDoc matching results for PDF documents.
* Time zone awareness of timestamps now defined on a per-file basis in exFAT.
* Ability to find the virtual allocation table of virtual UDF partitions on certain non-standard (incomplete) disk images as produced by other software.
* Fixed an exception error that occurred in v18.6 when carving files in a data window that represents a single file with no volume snapshot and no directory browser.
* Fixed effect of unselected "List internal file system files" option for files in archives.
* Fixed unsuccessful conversion of certain Base64 code.
* Prevented an extremely rare exception error that could occur when matching hash values against the hash database.

SR-2:
* Fixed inability of X-Ways Imager 18.6 to image disks.
* Some minor fixes.

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

A1eksandr1
посмотрите тут - http://winhex.ru.uptodown.com/old

Народы!
Мне нужно забить нулями 32-ой и 33-й сектора на системном разделе. Использую RePack от A1eksandr1 (WinHex 18.1 SR-01 x32&x64_Eng-Rus Registered). Система - Win 7 Максимальная 64 bit. Запускаю WinHex, выбираю раздел, перехожу на нужный сектор, обнуляю, жму сохранить сектора и - ФИГВАМ! Прога пишет, что заблокировать раздел С не удалось, т.к. он может использоваться другими приложениями. И все, ничего сделать нельзя.
Подскажите, плиз, как выйти из ситуации.

Vadimka45
Запускать с правами админа. Но этого едва ли достаточно будет.
Потому - запускать с LiveOS и уж там всё что душе угодно править.

Добавлено:
SAT311
Благодарю.

Цитата:

Потому - запускать с LiveOS и уж там всё что душе угодно править.

Я тоже об этом подумал, но не нашел пока ни одного LiveCD с WinHex на борту.
Пробовал из-под LiveCD запускать WinHex-portable с флешки, но он не корректно загрузился (не нашел там чего-то в системе). Сейчас ищу те приложения (сервисы), которые мониторят эти (32 и 33) сектора жесткого диска, чтобы отключить их.

Ссылка на WinHex Russian Fixer сдохла.
Обновите плиз.

http://subscribe.ru/archive/comp.soft.others.6600/201106/26073224.html/

Внизу промотайте там, рабочая ссылка.

WinHex 18.6 SR-7
[more=Изменения]SR-3:
* Fixed occasional incomplete extraction of embedded JPEGs in PDF documents.
* Fixed potential time zone information error in the properties of evidence objects with a Windows installation.
* Fixed an exception error that could occur with certain corrupt Zoom Browser files (Canon).
* Some other minor fixes.
* Some minor improvements.

SR-4:
* Fixed time zone conversion in the second column of previews of certain index.dat files.
* Fixed occasional incomplete exclusion of duplicates based on hash values.
* Deduplication of multiple very similar PhotoDNA hash values now even when importing them into an empty (newly created) PhotoDNA hash database.
* Since v18.6, if a new PhotoDNA hash value is close enough to be considered a match for an existing one, but different enough to warrant a separate entry in the PhotoDNA hash database, the existing entry is updated and the new one added. This double entry previously did not happen if both similar hash values were added during the same import operation, but now does.
* Some other minor fixes and improvements.

SR-5:
* Fixed size detection of Ext* partitions larger than 2^32 blocks in situations where they are not referenced by any partition table.
* Fixed memory leak in HFS file system support.
* Fixed inability to deactivate all filters with a single mouse click in SR-4.

SR-6:
* Fixed an exception and instability error that could occur when extracting metadata from certain documents in OLE2 format.
* In Ext4 file systems, some very rare files with uninitialized parts were previously read with partially incorrect data. That was fixed.
* Fixed parsing of FAT32 file systems with cluster sizes of 128 KB or more in X-Ways Forensics.
* Ability to show rough pixel counts for pictures that have PhotoDNA database matches.
* investigator.ini options related to the new Description filter did not work in v18.6. That was fixed.
* Some minor improvements.

SR-7:
* Fixed a rare exception error that could occur when generating HTML previews of files of certain types.
* Fixed potential inability to select thumbnails in the gallery while viewing pictures with the viewer component.
* Improved stability for processing of SQLite databases.
* Improved imaging behavior after media disconnect error.
* Prevented way around investigator.ini option +51 in v18.6.
* Some minor fixes.[/more]

WinHex 18.7
[more=Изменения]* As part of the volume snapshot refinement, X-Ways Forensics can generate thumbnails of high-quality digital photos to accelerate the gallery. It is now possible to select the resolution (maximum width or height in pixels) and quality (JPEG compression factor) in the user interface. However, the maximum amount of data that can be stored in the volume snapshot for a thumbnail is limited, to 64 KB, so if a generated thumbnail gets larger than that, X-Ways Forensics will automatically reduce the user-defined resolution accordingly.
* Smaller versions of pictures can now optionally be generated specifically for the report, to greatly reduce the memory requirements of the Internet browser or word processing application when loading the HTML report, and to accelerate. This can make a big difference for reports with many high-resolution photos. The JPEG compression factor is user-definable. The resolution depends on the specified "maximum dimensions of pictures".

The checkbox that represents this option is a 3-state checkbox. If half checked, the smaller versions of the pictures are used only for the preview directly in the HTML report. If fully checked, even when clicking the picture in the report you will only see the smaller version, and the original larger file is not included in the report at all. This can be beneficial if your main concern is the drive space requirement of your report with linked files, not the output quality of pictures.
* The report can now optionally also show previews/thumbnails of non-picture files, e.g. Office documents, e-mails, web pages, programming source code, etc. etc., similar to the gallery. You can shrink the preview representation slightly or a lot or not at all, to either be able to read some of the text right in the report without opening the document or to get a better impression of the overall formatting of the text and just see logos etc.
* If you output one specific report table in the case report, the suggested report name is now automatically based on the name of that report table.
* In the properties of a case you can now specify whether you prefer to have X-Ways Forensics use the case-specific directory of temporary files (the _temp subdirectory of that case) instead of the general one, when that case is active.
* Loose $MFT files can now be directly and conveniently interpreted as if they were NTFS volumes, to get at least a full listing of all files and directories, with their paths, timestamps and attributes. It's possible to open resident files (files whose contents is small enough to fit into the FILE records), but no other files, of course. Useful if in special situations all you have is the $MFT, not the entire volume.
* Finds more sessions of multi-session CDs/DVDs with CDFS immediately, without having to run a particularly thorough file system data structure search.
* Avoids session duplication on CDs/DVDs with CDFS where additional sessions are found only through a particularly thorough file system data structure search.
* The "1 hit per file needed only" option of the logical simultaneous search now no longer skips the slack of a file once a hit in the logical part has been found if "Open and search files incl. slack" is fully checked. It will check the slack for at most 1 additional hit as well.
* Previews and views of pictures (not with the viewer component) now additional show the names of associated report tables in the upper left corner and the names of matching PhotoDNA categories in the lower right corner.
* There is now an option to limit the search for lost partitions on physical media to the sectors that follow the current cursor position.
* Reports the total number of unreadable sectors in the disk imaging log in addition to the affected sector ranges.
* Same fix level as v18.6 SR-1.[/more]

WinHex 18.7 SR-2
SR-1:
* If multiple images were added to a case simultaneously, they had to be closed and re-opened in v18.7 to get the volume snapshot taken. That was fixed.
* File type recognition of certain lose Hotmail e-mails improved.
* Some minor improvements.

SR-2:
* Fixed blank Owner column in v18.7 for NTFS file systems.
* Fixed inability of 18.7 to maximize the detached lower half of a data window in most modes.
* Edit box histories now accessible additionally by scrolling with the mouse wheel and by pressing the Down cursor key.
* Fixed bad quality carving of NTFS-compressed files in recent versions.
* Improved interaction with MPlayer.
* Some minor issues resolved.

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

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

Пример, беру
..
Find 0x000001FC02192C24 Down
IfFound
Assign firstByteBlock CurrentPos
MessageBox firstByteBlock
..

firstByteBlock - 18862245 т.е. в dec формате, а мне бы его в hex преобразовать хочу видеть 0х11FD0A5

erema36
Так без разницы, для внутреннего представления в программе всё едино, что hex (с префиксом 0x), что dec (без этого префикса), число-то от этого не меняется.
Возможно, что позиция будет отображаться hex числом, если в редакторе включить hex-отображение смещения (Offset).

Вышел WinHex18.8
Список изменений почти из 80 позиций, правда большинство из них касаются xwf, однако есть изменения касательные например Recover/Copy, Disk imaging, Data Interpreter, быстрый алгоритм для simultaneous search.

WinHex 18.8 SR-1
Изменения:
* The option "Default to evidence object folders for output" did not have any effect on the Recover/Copy functionality in the original v18.8 release. That was fixed.
* The case report option "Copy and link each file only once" counted even previous report outputs if the order of files in the case root window was used. That was fixed.
* v18.8 miscounted directories recreated by the Recover/Copy command. That was fixed.
* The option to exclude all but one duplicate in each group did not have an effect in all situations in v18.8. That was fixed.
* PhotoDNA matching did not have any effect when not computing skin tone percentages at the same time. That was fixed.
* Avoids a time-out when loading certain corrupt picture files with the internal graphics viewing library.
* Some minor improvements.

Намедни пришлось разбираться с добавлением своего шаблона для поиска файла по сигнатурам.
Стал править "File Type Signatures Search.txt", чтобы добавить свою группу "*** Custom" и свой тип файла.
В процессе начал читать доку "winhex.chm\Menu Reference\Tools Menu\File Recovery by Type", там на странице ссылка на страницу "File Type Definitions" той же доки. И вот тут так сходу стало не понятно назначение флагов.
Начал переводить на русский. Мануал от версии 18.7.
Вот то, что получилось (коряво). Правка приветствуется:

Цитата:

File Type Definitions
=====================

[ 7th column: Flags ]

Необязательная колонка. Можете далее скроить вырезание файла для определенных типов файлов. Это ещё один индикатор того, какое сложное и сильное вырезание файла присутствует в X-Ways Forensics.

b (нижний регистр): сигнатура ищется на байт-уровне, когда предоставляется выбор. Особенно полезно для "точек входа/записей/микро-форматов/артефактов памяти" (т.е. не полных обычных файлов), которые обычно не выровнены по какому-любо сектору или границы кластера.

B (верхний регистр): предотвращает поиск на байт-уровне для этой сигнатуры из соображений производительности.

c (нижний регистр): если брать в расчёт (зависит от настройки пользовательского интерфейса), игнорирует header-сигнатуры, которые не выровнены на границах кластера. Может быть полезно для некоторых типов файлов, чтобы избежать ложных срабатываний.

C (верхний регистр): обозначает сигнатуры типов файлов, которые не должны быть использованы для поиска файлов, сжатых средствами NTFS, если активна компенсация сжатия NTFS, потому что они слишком неэффективны и принесут слишком много ложных срабатываний или не будут действительно храниться в сжатом виде.

u (нижний регистр): расшифровывается как "незанятый". Позволяет вырезать файлы только в кластерах, которые помечены свободными в файловой системе.

U (верхний регистр): позволяет вырезать файлы только в кластерах, которые помечены свободными в файловой системе, а также не используются предыдущим существующим файлом, содержащемся в снимке тома.

f (нижний регистр): указывает, что заданная footer-сигнатура используется для поиска данных, которые не входят в файл и должны быть исключены. Обычные footer-ы включены в вырезаемый файл. Полезно для тех форматов файлов, которые не имеют чётко определённых окончаний (footer-ов), где конец файла можно обнаружить по появлению данных, которые больше не принадлежат файлу. Это может быть такой же сигнатурой, как header-сигнатура (если файлы этого типа встречаются, как правило, в группах, вплотную друг к другу) или просто \х00 (для форматов файлов, таких как текстовые файлы, которые не содержат нулевое значение байта, где однако \х00 можно встретить с высокой вероятностью в стеке ОЗУ). Такие footer-сигнатуры должны быть отмечены как исключённые, поскольку соответствущие им данные не является частью самого файла.

F (верхний регистр): заставляет X-Ways Forensics отбросить найденное по файловой header-сигнатуре, если не найден соответствующий footer, при условии, что footer-сигнатура указана в определении. Может быть полезно, чтобы уменьшить количество или полностью избежать ложных срабатываний.

h: указывает, что заданная header-сигнатура используется для поиска данных, которые не являются частью самого файла. Это означает, что header будет исключён из вырезанного файла. Вырезанный файл начнётся после заголовка.

G: означает "жадный". Исключительно жадно выделяет все сектора. Сигнатура типа файла продолжает искаться дальше файловых заголовков только после предполагаемого окончания таких файлов. Может быть полезно, если реализован внутренний алгоритм, определяющий, что вырезанный файл содержит достоверные данные, так что нет необходимости искать другие файлы внутри ранее вырезанных файлов. Флаг действует только в том случае, если header-сигнатура файла находится на границе секторов.

g (нижний регистр): слабая версия того же флага. Только если существует внутренний алгоритм обнаружения размера файла для типа файла и, если файл с тем же стартовым номером сектора уже существует с тем же размером файла, "g" флаг заставит X-Ways Forensics пропустить затронутые сектора. Это может помочь предотвратить наложение на zip-файлы и тем самым избежать дубликаты файлов. Не имеет эффекта при сочетании с b.

S: отмечает сигнатуры, что достаточно хороши для поиска файловых header-сигнатур (возможно в сочетании с алгоритмом вырезания файлов), но не для проверки типа файла ввиду случайных ошибок идентификации. Этот флаг может быть очень редко нужен.

t: не позволяет X-Ways Forensics для предоставленного типа вырезанных файлов сразу же быть подтверждённым. Полезен, например, для семейных форматов файлов, таких как XML, чтобы определить точный подтип позже в ходе проверки типа файла.

e: расшифровывается как "встраиваемый". Если тип файла имеет алгоритм тильду (~) в столбце Footer и отмечен этот флаг, он может быть найден встроенным в некоторые другие файлы в процессе уточнения снимка тома, всегда на байт-уровне.

E: никогда не вырезать, если файл является встроенным в другие файлы.

W (верхний регистр): определяет header-сигнатуры, которые слишком слабы, чтобы заново определить тип файла, и используется лишь для подтверждения типа рекомендуемого расширением имени файла.

y: определяет типы файлов, которые, как известно, используют внутреннее шифрование, которое позволяет пометить вырезаемые файлы из этих типов в столбце Attr. непосредственно с "е!".

wh/xwf - программа сложная, мощная, богатая функциями, разобраться в них не просто. Я пытался систематически читать руководство и справку, держать всё в памяти трудно, приходится прыгать туда-сюда. Пытался переводить, столкнулся с терминологической проблемой. У автора, на самом деле, очень чёткая терминология на английском (напрашивается список терминов), но адекватно перевести её на русский и, тем более, на протяжении всего перевода её использовать... Переводил, переводил, возвращался, читал перевод, - не то: понимал, что теперь перевёл бы не так, термин бы выбрал другой, или прояснилась суть, всплыли важные мелочи, которых не понял раньше (каждый раз обнаруживал тёмные углы)... Понял одно, эффективно работать с wh/xwf можно лишь проштудировав руководство.
Раздел 8 "Восстановление данных" я тоже перевёл, но очень сыро.
В тексте выше я использовал терминологию:
- "сигнатура заголовка" вместо "header-сигнатура"
- "подпись" вместо "footer-сигнатура"
- "уточнение снимка тома" совпало!
- "вырезаемые файлы" совпало!
...
Впрочем, у каждого в голове своя картина мира складывается, а предела к совершенству нет, поэтому приходится разбираться самому.

sendeg
В некоторых флага (например: G) говорится о каком-то внутреннем алгоритме. Что это значит?

Ciber SLasH
Всё равно лучше сформулировать пока не смогу, поэтому сырой перевод из раздела 8 руководства:
...
Внутри работают различные алгоритмы, которые пытаются определить исходные размеры файлов многих разных типов (среди прочих - JPEG, GIF, PNG, BMP, TIFF, Nikon NEF, Canon CR2 raw, PSD, CDR, AVI, WAV, MOV, MPEG, MP3, MP4, 3GP, M4V, M4A, ASF, WMV, WMA, ZIP, GZIP, RAR, 7Z, TAR, MS Word, MS Excel, MS PowerPoint, RTF, PDF, HTML, XML, XSD, DTD, PST, DBX, AOL PFC, Windows Registry, index.dat, Prefetch, SPL, EVTX, EML) проверкой их структур данных. Это применяется к записям в базе данных определений типов файлов, которые имеют "~" в колонке Footer. Эти записи не должны быть изменены, чтобы обнаружение размера и типа работало для этих типов файлов. Альтернативно, подпись (footer signature) может также помочь найти конец файла. Файлы, для которых ни внутренний алгоритм, ни определение подписи не существуют, или файл, об исходном размере которого существующий внутренний алгоритм не имеет данных и для которого не найдена подпись, - восстанавливаются с размером по-умолчанию, указанным в байтах в базе данных определений типов файлов. Будьте щедрым при указании такого размера, ведь несмотря на "весьма большой" размер восстановленного файла, он по-прежнему может быть открыт своим связанным приложением, досрочно усечённые же файлы - не могут, так как они незавершённые. Попытка обнаружить исходный размер файлов некоторых типов поиском подписи ограничена пределом обнаружения размера (size detection limit), который опционально указан в базе данных после размера по-умолчанию и прямого слэша (/). Такой предел необходим для предотвращения поиска подписи данного файла по всему тому, который может быть весьма долгим, если том большой. Кроме того, уменьшается вероятность найти правильную подпись (footer), если она не в непосредственной близости от заголовка, и даже если она найдена очень далеко, такой файл, скорее всего, фрагментирован или частично перезаписан и т.п. Стандартный размер по-умолчанию (если не указан) - 1 Мб. Стандартный максимальный размер (если не указан) - в 64 раза больше размера по-умолчанию.
...
5 колонка: Footer
Опционально. Подпись (последовательность байтов),которая достоверно обозначает конец файла, указана в GREP-синтаксисе. GREP-выражения, представляющие данные переменной длины могут работать не так как ожидается. Подпись (footer signature) может помочь выполнить восстановление с корректным размером файла. Алгоритм восстановления не ищет подпись за пределами указанного максимального количества байтов размера файла от начала заголовка.
Ещё лучше чем подпись - это потенциальная возможность применения внутреннего алгоритма xwf, который знает формат файла и может обычно отыскать корректный размер файла, если файл не фрагментирован, полон и не испорчен. Такой алгоритм указывается в колонке Footer тильдой (~) и идентификационным номером алгоритма.
...

Цитата:

Ещё лучше чем подпись - это потенциальная возможность применения внутреннего алгоритма xwf, который знает формат файла и может обычно отыскать корректный размер файла, если файл не фрагментирован, полон и не испорчен. Такой алгоритм указывается в колонке Footer тильдой (~) и идентификационным номером алгоритма

Вот и не понятно, какой алгоритм, под каким идентификационным номером... где это смотреть?

Мне вот что видится:
На то он и внутренний алгоритм, автор его под конкретные типы файлов настраивает сам, присваивая разным типам разные идентификаторы. Для пользователя доступ к внутренностям этого алгоритма закрыт, да и не нужен, ведь для новых типов, отсутствующих в базе данных "File Type Signatures Search.txt", имеется механизм подписи (footer), хотя автор и намекает, что это менее эффективный механизм.

sendeg
Прошу помощи в составлении вырезания MTS-видео-файлов.
[ Header ]

Код: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000000 00 00 00 00 47 40 00 10 00 00 B0 11 00 01 C1 00 ....G@....°...Б.
00000010 00 00 00 E0 1F 00 01 E1 00 24 AC 48 84 FF FF FF ...а...б.$¬H„яяя
00000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
00000030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
00000040 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
00000050 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
00000060 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
00000070 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
00000080 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
00000090 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
000000A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
000000B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF яяяяяяяяяяяяяяяя
000000C0 00 00 55 05 47 41 00 10 00 02 B0 40 00 01 C3 00 ..U.GA....°@..Г.
000000D0 00 F0 01 F0 0C 05 04 48 44 4D 56 .р.р...HDMV

Я же прошу помощи для составления паттерна для xspf плейлистов. проблема в том, что это обычный xml-формат. И на него похожи первыми символами например fb2 или конфиги различных прог. Так вот для того, чтобы выделить данный тип из других и нужно составить специальный паттерн.

Ciber SLasH
Я создал файл "File Type Signatures user Search.txt", он подгрузился в wh.
У вас похоже просто опечатка в подписи, должно быть: (.{4}\x47\x1F\xFF\x10\xFF{184}){3,30}
Колонки разделены табулятором.

[начало файла]
Description    Extensions    Header    Offset    Footer    Default size    Flags
*** test_for_mts
MTS    MTS;mts    .{4}\x47\x40\x00\x10\x00\x00\xB0\x11\x00(\x00|\x01)\xC1\x00\x00\x00\x00\xE0\x1F\x00\x01\xE1\x00(\x23\x5A\xAB\x82|\x24\xAC\x48\x84)\xFF{163}.{4}\x47\x41\x00\x10\x00\x02\xB0.\x00\x01.\x00\x00\xF0\x01\xF0\x0C\x05\x04HDMV    0    (.{4}\x47\x1F\xFF\x10\xFF{184}){3,30}    10000000/1610612736    b
[конец файла]

открыл mix.bin в wh и запустил Tools | Disk Tools | File Recovery by Type...
там выбрал test_for_mts. У меня нашёлся один файл полностью, тот который 00001.mts, а 00006.mts нашёлся обрезанным, так как не была найдена подпись, а её и у исходного файла 00006.mts нет.
Так что всё работает и не ругается.


Добавлено:
VidelSamogO
Речь о шаблоне (template) или о вырезании файла xspf из другого файла?