[Сергей]

Пишем сюда

[666]

Очень хочется драйвер для считывателя под 64-битные ОС (Vista, XP). И не сочтите за наглость также хотелось бы Flash Reader и Flash Extractor для Mac OS X

[asm]

Хочется увидеть настраиваемый Viewer для нормального просмотра флешек где служебка 512/26. Ну и как вариант сделать что область со служебкой была на другом фоне.

Также увидить в Dump Search возможность анализа служебки для 512/26

пока что вопросы успешно решались с помощью Sector Mutate (начиная с 4.02) но все же может быть ситуация где только с этой функцией будет сложновато.

[done]

[Сергей]

Вот этим вопросом заняты все мои мысли последнее время :)

Особенно неудобно разглядывать сектор:
512/26.....512/26....512/26....512/34

То есть он очень длинный и не равномерный.

Если есть мысли как это сделать удобно, с удовольствием послушаю.
Sector_Mutate - это как костыль, он по суте своей не верный.

[done]

[asm]

сделать для вьвера настройку.

отображать первый сектор 512/26 второй 512/26 третий 512/26 четвертый 512/34

то есть строку вида

512/26/512/26/512/26/512/34

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

при задании адреса делаем деление на размер блока с остатком. и дальеш смотрим в остатке на какой номер сектора выпадает соглсно описания структуры. Думаю вряд ли вас затруднит эта процедура.

кстати можно ввести что переход не на адрес а на номер сектора. проще будет сопоставлять с конечным дампом. (номер внутриблочный, то есть понадобиться еще указывать размер блока) Хорошо будет в случае одинаковый номеров в одном блоков в одном банке анализировать что пойдет в конечный дамп. Меньше считать придется

[done]

[Сергей]

Идея понравилась
А как быть с 7/512/9 или 176/4/168/4/168/8?

Я ещё думал сделать весь сектор на экран с цветным выделением и вторую полосу прокрутки, если не влезает

[done]

[asm]

Вводить описание блока. размер если блок из нескольки секторов. (и служебка к группе секторов)

строго отображать служебку внизу. и давать описание сектора или блока (блок - группа секторов)

допустим 0/7/512/9
отображаем данные 512

а в поле служебки пишем первые 7 байт и последние 9.
просто как например описываем банки в утилитах, то в таком же духе описывать конфигурацию каждого сектора в одном блоке. для тех случаев где сектора получаются разной длины.

если идет группа из секторов с нестандартным конфигом тогда больше описания входных данных.

например имем блок в котором сектора в таком виде (ну чисто абстрактно допусти такую кашу)
0/4/128/4/128/4/128/4/128/0
0/7/256/4/256/5
128/8/384/8
512/26
вот сделали описание этого блока и пишем что должно отобразиться
512/16
512/16
512/16
512/26

или ваиант. начальный параметр
4096/208
отображать как обычные сектора 512 байт и служебку каждому
т.е.
512/26
512/26
512/26
512/26
512/26
512/26
512/26
512/26


собственно выборку сделать нужных байт для правильного отображения несложно. единственное что раз уже отказываемся от Sector Mutate придется сделать подсветку фактического места в блоке. т.е. смещение от начала. ЧТобы правильные маркеры ставилисть для утилит разбора

Ну и контроль всего дела что количество байт в описании на входе должно быть количеству в описании на выходе и собственно размеры служебки и данных по сумме одни и те же

[done]

[Masterclass]

Было бы здорово если при возникновении ошибок верификации чтения была возможность посмотреть в HEX редакторе что именно не совпало и предлагалось пользователю либо проигнорить ошибку либо её исправить. Что-то на подобие FineReader. Кроме того, в конце верификации было бы полезно видеть не большой столбик из Diff, а их количество (ошибок)

[vlad_krsk]

Надо исправить неверное отображение номера блока в Block Number 0000\Conflicts при изменении размеров банка.

[nor2]

1. Добавить в HEX редакторе возможность сохранить полностью блок, а не только 300кБ или задавать длину сохранения.
2. Block Number 0000\Conflicts - возможность записи группы конфликтных блоков в файлы для последующего сравнения и выбора наилучшего кандидата.
3. MIX редактор - возможность записи в файл конечного дампа (с убранными миксами) (не через RAW с хитрыми параметрами).

[Сергей]

Image_Explorer
Пропускать сохранённые файлы

возможность выделять сразу несколько папок которые нужно скопировать. Например удерживая CTRL.

[akozlov]

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

2. сделать возможность в Translator-ах листинга служебки не по всему дампу а по любому диаппазону адресов

3. была бы удобна возможность как в FlashExtractor, так и в ImageExplorer сохранять в файл любой диаппазон адресов дампа/образа...

прошу прощения, если что-то из этого есть, а я не нашел...

[Yakov-K]

Jpeg scaner:

1. Избавиться от такого уродства, как юникод в текстовичках. Потом править их, что руками, что на автомате каким-нибудь ФАРом - не очень удобно. Хотя я правил, и автоматическую поиск-замену делал, но в обычном ANSI было бы приятнее.

2. Крайне необходимая штука - вывод картинки в процессе сборки. Понимаю, что просто так не внедришь, но оно будет того стоить. Коментарии тут излишни.

3. Нужен авторежим на недостроенных фотках (Half-ах).

4. Обязательно нужно добавить возможность задания произвольного размера начального фрагмента у Header-ов, у всех разом. (чтобы ФАРом не мучаться и пр.)

5. Ну и самое главное - сделать автоматический анализ первого фрагмента Header-ов. Это нужно для более полной и эффективной работы на автомате (а это несколько часов, иногда ночь). Т.е. с правильно рассчитанными заголовками нам останется не 50-60% потом собирать руками, а только 5-10%. Перед анализом надо задать:
5.1. Шаг блока (Jump step)(не путать с отдельно заданным размером блока для сборки). Как правило, это будет размер логического кластера (узнается из Boot).
5.2. Направление (Direction) - т.е. либо идем от минимума (ставим размер блока фрагмента равным Jump step) и потом дискретно увеличиваем, либо от максимума - задаем количество шагов, либо напрямую вводим размер, но тогда надо самому следить, чтобы он был кратен Jump step. Типовой пример - шаг 0х8000 (пусть по дефолту и стоит. как правило, кластер такой и есть, 64 сектора в десятичке), а максимальный блок, подбираемый эмпирически по артефактам на картинке - 0х40000.
5.3. Вид конечного критерия для анализа, пока придумал только два:
5.3.1. По анализу Scan data (пока оно OUT, т.е. битовый поток декодируется верно, без вылетов на отсутствующий Huffman code), и как только встречаем любую ошибку (неверный маркер, зигзаг, не обнаружен код, или еще что-то) - откатываемся на Step назад и запоминаем этот размер фрагмента в заголовке (сохраняем в текстовичок), переходим к следующему Header-у.
5.3.2. По анализу пробной сборки самого первого фрагмента, точнее, стыковки к нему следующего. Т.е. тогда надо будет задать еще и Quality treshold. Практика показывает, что если второй фрагмент прицепился к первому с высоким качеством, то с вероятностью 85% эта фотка соберется в Good.
5.4. Не забываем чекбокс, при нажатии на котором после всех этих анализов сразу начнется процесс автосборки Header-ов. Хоть это и кажется излишеством, но один только анализ с помощью Quality treshold, особенно, если фоток несколько сотен, может занять часа два, поэтому неплохо бы экономить время на "длительных оставлениях сканера без присмотра". p.s. Пункт 5 ввиду его отсутствия на данный момент, делал руками, убил на 200 фоток часа 4...автомат был бы очень кстати, машина должна и думать и работать

6. Ну а если прикрутить скрипт, хоть какой-нибудь...критерий выхода из цикла скрипта - 100% Good, 0 Errors, 0 Half. Чтобы например менялось качество, размер блока сборки (уменьшался с определенным шагом), и т.п.

7. Если из п.1-п.6 никто ничего не понял, это нормально, пишу здесь только в качестве памятки Сергею.

[vlad_krsk]

Неудобно выводятся диффы. Лучше исползовать шаблон

"Diff # %-.6d: 0x%-.8X"

[Yakov-K]

Опять про джипег сканер.
Понял наконец-то, что там будет обеспечивать эффективность автомата, например, на тех же Олимпусах. Это волшебное слово - Align. Оказывается, они очень любят постоянно уходить внутри блока, например, на 0х4000, на 0х8000...
Для каждого свой размер блока при сборке, естественно. Дольше, но зато меньше ручной работы. Сортирую пока руками, хочется удобства .
И еще одна расходная статья - заметил, что очень много ручного времени уходит на заход в Properties конкретного файла и подстройку там размера блока (или последнего размера блока, если фрагмент не один). СИЛЬНО облегчит задачу задействование курсорных клавишь вправо-влево прямо на списке файлов, с обязательным апдейтом картинки (и Apply по дефолту, конечно же, можно опционально). Ну, при этом, конечно, я должен видеть где-нибудь сверху в поле, какие текущие фрагменты и каков их размер. Ну и про сам алгорим сравнения MCU - что-то в нем не совсем так. Например, может оказаться ПРАВИЛЬНО подобранный блок с Quality 0, что само по себе нонсенс (и на стыках есть как мелкие детали, так и градиенты). Еще постоянно сталкиваюсь с тем, что блок по данному Align ТОЧНО присутсвует (проверяется простым увеличением на этот блок в Properties и видно правильное продолжение картинки), а автомат не находит, причем часто предлагает на первом месте (видно после сортировки Find Next) совсем неправдоподобный кусок, а нужный потом не находится в списке даже в первых двух сотнях. Ну это если в кратце пока...