Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » X-Ways WinHex

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

Открыть новую тему     Написать ответ в эту тему

Nep



Moderator
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Обсуждение в Варезнике


Stefan Fleischmann
WinHex - универсальный шестнадцатеричный редактор, полезный для восстановления данных, обработки данных низкого уровня, и безопасности IT. Расширенный инструмент для каждодневного и профессионального использования: просмотр и редактирование всех видов файлов, восстановление удаленных файлов или потерянных данных на жестких дисков с поврежденными файловыми системами или от цифровых камер.
Также включает:  
- Дисковый редактор для жестких дисков, гибких дисков CD-ROM & DVD, ZIP, Smart Media, Compact Flash, ...  
- Мощный браузер каталога для FAT, NTFS, Ext2/3, ReiserFS, CDFS, UDF  
- Редактор оперативной памяти, обеспечивает доступ к виртуальной памяти других процессов.
- Интерпретатор данных, знает 20 типов данных  
- Редактирование структур данных, используя шаблоны (например, чтобы восстановить таблицу разделов / загрузочный сектор)  
- Слияние и разделение файлов, объединяя и деля четные и нечетные байты/слова  
- Анализ и сравнение файлов  
- Удобный гибкий поиск и функции замены  
- Диск отображает и резервные копии (произвольно сжатый или разбитый на архивы на 650 Мбайт)  
- Программируемый интерфейс (API) и при создании сценария (профессионал и специалист лицензируют только),  
- 128-битовое шифрование, контрольные суммы, CRC32, мусор (MD5, SHA-1...)  
- Стирание конфиденциальных файлы надежно, чистка жесткого диска, чтобы защитить вашу секретность  
- Конвертация всех форматов binary, hex ASCII, Intel Hex, and Motorola S
- Наборы символов: ANSI ASCII, IBM ASCII, EBCDIC, (Unicode)
- Мгновенное переключение окна. Печать. Генератор случайных чисел.  
- Поддержка файлов размером свыше 4 Гб


Качать: здесь или здесь

Специальная русская раскладка клавиатуры для WinHex всех версий
Public Announcements

Программы аналогичного назначения:
HxD - бесплатный HEX редактор файлов и дисков с поддержкой русского интерфейса и ввода кириллицы, 100% портабелен.
Hex Editor Neo - 1 из лучших редакторов, в отличие от теперешнего WinHex
поддерживает ввод и поиск русских букв и переключение между множеством кодировок отображения,
многофункционален и создан для удобной работы.
FlexHex - сразу отображает как ASCII, так и Unicode, один из удобных HEX редакторов.
wxHexEditor
BreakPoint Software Hex Workshop
IDM UltraEdit

Всего записей: 41940 | Зарегистр. 24-06-2001 | Отправлено: 23:51 20-12-2001 | Исправлено: Komandor, 17:47 25-12-2022
Vadimka45



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

Всего записей: 237 | Зарегистр. 26-10-2005 | Отправлено: 18:01 09-12-2015
A1eksandr1



Модератор
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Vadimka45
Запускать с правами админа. Но этого едва ли достаточно будет.
Потому - запускать с LiveOS и уж там всё что душе угодно править.
 
Добавлено:
SAT311
Благодарю.

Всего записей: 7239 | Зарегистр. 10-12-2007 | Отправлено: 19:42 09-12-2015
Vadimka45



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 237 | Зарегистр. 26-10-2005 | Отправлено: 09:44 10-12-2015
Tekton_2



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ссылка на  WinHex Russian Fixer  сдохла.  
Обновите плиз.

Всего записей: 149 | Зарегистр. 24-05-2009 | Отправлено: 12:40 21-12-2015 | Исправлено: Tekton_2, 12:43 21-12-2015
vasevase

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
http://subscribe.ru/archive/comp.soft.others.6600/201106/26073224.html/
 
Внизу промотайте там, рабочая ссылка.

Всего записей: 3134 | Зарегистр. 28-08-2010 | Отправлено: 14:47 21-12-2015
SAT311

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
WinHex 18.6 SR-7
Изменения

Всего записей: 275 | Зарегистр. 08-11-2015 | Отправлено: 08:14 23-01-2016
SAT311

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
WinHex 18.7
Изменения

Всего записей: 275 | Зарегистр. 08-11-2015 | Отправлено: 14:50 28-01-2016
SAT311

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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.

Всего записей: 275 | Зарегистр. 08-11-2015 | Отправлено: 14:51 10-02-2016
Aqel



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Хорошо, что русский добавили разрабы - теперь гораздо приятнее работать с прогой.

Всего записей: 209 | Зарегистр. 22-10-2009 | Отправлено: 20:49 28-02-2016
erema36

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Подскажите, при выполнении скрипта winHex преобразовывать типы может?
Сколько гуглил, так найти и не могу
 
Пример, беру  
..
Find 0x000001FC02192C24 Down
  IfFound
    Assign firstByteBlock CurrentPos
    MessageBox firstByteBlock  
..
 
firstByteBlock - 18862245 т.е. в dec формате, а мне бы его в hex преобразовать хочу видеть 0х11FD0A5

Всего записей: 4 | Зарегистр. 14-07-2014 | Отправлено: 01:40 07-03-2016
sendeg

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

Всего записей: 94 | Зарегистр. 25-01-2014 | Отправлено: 19:40 08-03-2016
sendeg

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

Всего записей: 94 | Зарегистр. 25-01-2014 | Отправлено: 19:55 23-04-2016
SAT31



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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.

Всего записей: 9260 | Зарегистр. 11-09-2009 | Отправлено: 08:01 07-05-2016 | Исправлено: SAT31, 08:02 07-05-2016
Ciber SLasH



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Намедни пришлось разбираться с добавлением своего шаблона для поиска файла по сигнатурам.
Стал править "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. непосредственно с "е!".

Всего записей: 262 | Зарегистр. 07-04-2016 | Отправлено: 21:28 09-05-2016 | Исправлено: Ciber SLasH, 21:35 09-05-2016
sendeg

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

Всего записей: 94 | Зарегистр. 25-01-2014 | Отправлено: 20:58 12-05-2016
Ciber SLasH



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
sendeg
В некоторых флага (например: G) говорится о каком-то внутреннем алгоритме. Что это значит?

Всего записей: 262 | Зарегистр. 07-04-2016 | Отправлено: 01:08 13-05-2016
sendeg

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 тильдой (~) и идентификационным номером алгоритма.
...

Всего записей: 94 | Зарегистр. 25-01-2014 | Отправлено: 18:32 13-05-2016
Ciber SLasH



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 262 | Зарегистр. 07-04-2016 | Отправлено: 23:17 13-05-2016 | Исправлено: Ciber SLasH, 23:18 13-05-2016
sendeg

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

Всего записей: 94 | Зарегистр. 25-01-2014 | Отправлено: 18:03 14-05-2016
Ciber SLasH



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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

 
GREP-pattern:
.{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
 
[ Footer ]

Код:
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
 
01E7DF40   11 B6 6B 56 47 1F FF 10  FF FF FF FF FF FF FF FF   .¶kVG.я.яяяяяяяя
01E7DF50   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DF60   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DF70   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DF80   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DF90   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DFA0   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DFB0   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DFC0   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DFD0   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DFE0   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя
01E7DFF0   FF FF FF FF FF FF FF FF  FF FF FF FF FF FF FF FF   яяяяяяяяяяяяяяяя

 
GREP-pattern:
(.{4}\x47\x1F\xFF\x10\xFF{187}){3,}
MTS-файл заканчивается несколькими блоками ".{4}\x47\x1F\xFF\x10\xFF{187}" (но не всегда. В архиве с примерами есть файл 00006.MTS, который заканчивается не так). Таких блоков в конце файла может быть от 3 до 20 и больше (попадался файл с 23 блоками).
Загвоздка в том, что WinHex выдаёт ошибку если поставить такой Footer: (.{4}\x47\x1F\xFF\x10\xFF{187}){3,30}
 
По идеи должен работать такой шаблон для "File Type Signatures Search.txt":

Код:
\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    4    (.{4}\x47\x1F\xFF\x10\xFF{187}){3,30}

Но он не работает.
 
Тут в архиве пример микса и исходные MTS-файлы.

Всего записей: 262 | Зарегистр. 07-04-2016 | Отправлено: 04:01 15-05-2016 | Исправлено: Ciber SLasH, 04:02 15-05-2016
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

Компьютерный форум Ru.Board » Компьютеры » Программы » X-Ways WinHex


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru