Версия 2.1

Обновленные диалоги поиска/редактирования. Поддержка ieee754 одинарной/двойной точности, а так же 8 байтовых констант.

Теперь программа будет работать и на андроид 4.0 (раньше выпадало при открытии диалога поиска)

Корректное отображение ошибок в интерпретаторе (в прежних версиях строка и номер показывались из кода, обработанного препроцессором). Так же появилась возможность объявления нескольких переменных/массивов одной строкой

hexEdit.apk ( 898.73 КБ )

Версия 2.1.1

Появилась возможность обратного поиска, поиска в выделении. Также добавлена кнопка Find next (не связана с текущим выделением, в отличие от after change)

Допилена темная тема, сепараторы в диалогах, стили кнопок и тд. Диалог File structure теперь вызывается из action bar

hexEdit.apk ( 909.62 КБ )

Спасибо за программу. По описанию выглядит просто замечательно!
А почему поиск обязательно ограничивается 1, 2, 4 или 8 байтами? Понятно, что короткие шаблоны можно удлинить ?? (знаками вопроса), а как быть с более длинными?
И ещё нельзя ли сделать возможность вводить прямую последовательность байтов, а не обратную, как сейчас?
Есть ли пример скрипта поиска и замены hex-последовательности? Я, к сожалению, полный профан в программировании. Скрипт написал, и он даже что-то ищет, но работает только с последовательностью в 4 байта, да и пишет децимальные значения, а не хексовые, незначащие нули пропускает. :( Какой же это hex-редактор?

Сообщение отредактировал OsitKP - 26.11.15, 19:35

OsitKP,
По поводу поиска/редактирования констант - в машине обычные числовые константы представляют из себя перевернутую цепочку байт, поэтому такие "проблемы". Более подробно можете почитать во вступлении любой книги по ассемблеру, например. То же самое вы увидите в любом другом hex редакторе, т.к. это особенность работы не программы, а машины.

Вопросами нельзя ничего "удлинить". Знак '?' означает неизвестный полубайт, только и всего. По сути вы можете искать только константы указанной размерности, записанные в различных форматах или же строки в заданной кодировке. Позже, возможно, добавлю возможность поиска цепочки байт, однако работать это будет, как и поиск строки, медленнее поиска константы.

Насчет вывода в недесятичном виде - используйте функцию print, передавая вторым параметром нужную вам систему счисления для вывода, например:
print VALUE, 16

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

UPD2: для ввода недесятичных значений с помощью input следует использовать ту же запись, что и в коде (0xXXX, 0oXXX, 0bXXX). Это я как-то упустил в инструкции, позже внесу изменения.

Сообщение отредактировал First Row - 22.12.15, 16:54

Это я уже пробовал, незначащие нули при этом не печатаются. :(
Поиск последовательности из инструкции (80??3344) не проходит, выдаётся cообщение incorrect value.
Считываемые значения ограничены 4-мя байтами, несмотря на заданную размерность 8.

Сообщение отредактировал OsitKP - 24.12.15, 20:34

OsitKP,
Незначащие нули и не должны печататься. Почему? Все просто.. сама функция print, как вы могли заметить, не принимает параметром размерность, потому "не знает", сколько нулей вам нужно. Печатается просто значение в заданной системе счисления. Стандартная размерность переменных - 8 байт, а перегружать функции ввода-вывода лишними параметрами я смысла не вижу, так как в любом случае на практике необходимы значения.
Обычно такие вещи делаются уже при компоновке строки с результатом перед выводом, но так как в макро пока что нет строк, увы.. Честно говоря, полезность строкового типа, с учетом специфики программы, сомнительна, но, возможно, добавлю в дальнейшем.

Насчет последовательности - вы точно задали HEX template в соответствующем выпадающем списке? В любом случае, это моя ошибка, я не отредактировал шапку после введения изменений в интерфейс..

Чтение проверю позже. Речь идет о чтении в макро или о поиске?

UPD: в макро 8 байтовое чтение/запись прекрасно работают. Возможно проблема в знаке.. Так как в java нет unsigned, возможное значение, которое можно считать/записать будет от 0 до 0x7fffffffffffffff, иначе возможны сбои.. Если в редактировании и поиске эту проблему можно решить использованием двух переменных для хранения одного значения, то в макросистеме это неприемлимо в силу "корявости кода" и удара по быстродействию. Но проблему можно решить в самом коде макроса, записывая, скажем, правую и левую часть в две разные переменные..

Сообщение отредактировал First Row - 25.12.15, 03:15

Моя ошибка. Был просто выбран HEX.

Очень сомнительно. Вот примитивный макрос, который я использую:
while i<SIZE
getVal cur,i,4
print cur,16
i=i+1
done
В результате печатается какая-то ерунда. Разной длины последовательности (я понимаю, из-за имеющихся нулей), мало того, ещё и появляется впереди знак минус. Что-то до сих пор на подобное в других редакторах не натыкался...

Ну и, главное, раз в редакторе ищется последовательность, значит, и макрос для её поиска можно написать?

Сообщение отредактировал OsitKP - 25.12.15, 14:06

OsitKP,
Знак '-' идет из за того, что считываемое значение отрицательное. А, как я говорил выше, в java, к сожалению, доступны лишь signed типы из тех, размерность которых > 1 байта. Пока что накладывание необходимых масок взвалено на плечи "макрописателя", так как такой вариант мне кажется более правильным. Делайте следующим образом и все будет работать:
i=0
while i<SIZE
getVal cur,i,4
cur=cur&0xffffffff
print cur,16
i=i+1
done

Только учтите, если вы хотите отпечатать файл, как набор последовательно идущих 4 байтовых констант, то следует исправить так же i=i+1 на i=i+4

По поводу разной длины - это уже "человеческое" отображение. Наш формат записи один, в машине другой.. Функция вывода НЕ знает, какова размерность той или иной считанной константы, так как она хранится в 8 байтовой переменной..

PS: Разумеется, написать можно все, для этого макросистема и нужна. Хотя, использовать ее для поиска не лучшее решение из за скорости работы.. В качестве примера могу скинуть несколько макросов различной сложности, из тех, что сам использую.

PS2: По поводу чтения 8 байтовых констант, действительно нашел ошибку у себя(фактически пишутся 4 байта), фикс войдет в ближайшее обновление. Тестировал это только на чтении/записи с AND с небольшими значениями, потому как то упустил эту проблему.. Вам спасибо за внимательность.

Сообщение отредактировал First Row - 25.12.15, 16:24

Версия 2.1.2

"важные" диалоги теперь не прикрываются при повороте экрана

Фикс функции getVal в макро (чтение 8 байтных констант теперь работает корректно)

Добавлен help, но пока что работа над ним ведется. Окончательный вариант будет готов после доведения до ума макросистемы и добавления всего задуманного.

hexEdit.apk ( 932.46 КБ )


Сообщение отредактировал First Row - 25.12.15, 16:22

Не будет.
Я пробовал этот вариант ещё раньше. Вот результат печати:
е2233068
ее22330
ее223
52000ее2

При этом файл выглядит так:
68 30 23 Е2 0Е 00 52
Понятно, что с нормальным шаблоном, если он содержит нули в первом полубайте, совпадения никогда не будет.

P.S. Поизвращался с шаблоном, в принципе, получил желаемый результат. Но, если последовательность окажется длиннее 8 байт, будет сложно. :)
Я пропустил, или просто нет варианта вернуться в окно просмотра после выполнения скрипта? Или же вообще запускать из терминала выполнение скрипта?

Сообщение отредактировал OsitKP - 26.12.15, 11:12

OsitKP,
Тык вывод правильный же:
68 30 23 Е2 - е2233068 в перевернутом виде
Остальной выхлоп вы уверены, что написали правильно и увеличивали на 1 или на 4? Со знаком в 4 байтовых при наложении маски проблем быть не должно, но сейчас проверю у себя.

Как я уже говорил - поиск осуществляется не последовательностей, а констант. Формат хранения обычных числовых констант - в перевернутом виде. Если серьезно, на практике необходимы именно значения в нужных полях/строки.. Остальное можно назвать извратом.

PS: если есть сомнения в корректной работе скрипта, можно скрины hex отображалки, кода макроса и результата (просто сейчас тестирую ваш макрос у себя, все работает, в т.ч. с отрицательными значениями)?

Сообщение отредактировал First Row - 26.12.15, 11:43

Естественно. Это же видно, специально вывел весь кусок. Сдвиг идёт на один байт, а с появлением незначащих нулей получается ерунда. Как перед нулями появились цифры/символы, нули начали отображаться.

Ну, а если мне нужно искать именно последовательность?
Кстати, проверил на реальном файле (около 800кб). Результат плачевный. 0х1000 адресов по 4 байта считывает больше минуты.
При длине файла в С46В0 (в 12 раз дольше) время получается довольно-таки мрачным. При этом поиск из редактора работает влёт. Похоже, придётся всё-таки работать руками. :(


Сообщение отредактировал OsitKP - 26.12.15, 12:31

OsitKP,

Для чего нужно, если не секрет? Начнем с самого определения бинарного файла. Фактически это структура данных, соответствющая некоему формату. Может быть заголовок или несколько, данные, хранимые в различных форматах, например тот же исполняемый код. Данные, записанные в файле, в свою очередь отвечает тем же правилам (структура с известными полями, заполненными некими значениями). Hex редактирование же заключается в поиске/изменении значений в неких полях. С чем бы вы ни работали, будь то исполняемый файл, или видео/аудио и т.д., правила будут одни и те же. Потому я и называю это извратом. Поиск цепочки байт (не строки и не константы) может быть действительно полезен на практике лишь в случае, если какой-либо формат данных не поддерживается самим редактором..


А чего вы хотели от макро? Интерпретируемый код по определению будет работать в тысячи раз медленнее компилируемого. Макросистема может быть незаменима, например, в действиях внутри выделения или в небольших кусочках файла, парсинга заголовков/вывода нужных полей ну и тд. Никак не для поиска внутри больших файлов или их разбора "по байтам".

За скриншоты, как и за наблюдения, спасибо. Попробую воссоздать проблему у себя.

Сообщение отредактировал First Row - 26.12.15, 13:41

Да не секрет, для патчинга кода. Это гораздо проще, чем декомпилировать библиотеку и искать нужные команды, править, снова компилировать.

OsitKP,
Если речь идет о поиске последовательности команд, то, пожалуй, использовать поиск фрагмента будет действительно проще. На этот случай, пожалуй, все таки добавлю поиск фрагментов в следующих версиях.

Если же необходимо найти/заменить одну или несколько команд в разных местах, проще(и быстрее) искать их, как значения. В ARM-то команды не имеют сложной структуры и представляют собой 2 или 4 байтовую константу, в зависимости от режима..

Да, но если их несколько в файле? Приходится удлинять шаблон. Если при смене версии код модифицируется, меняются данные/адреса. Приходится использовать маски. :)
Для меня идеалом было бы что-то а-ля DUP Patcher.
Возвращаясь к моим баранам, а нельзя ли скрипты прикрутить к редактору?

Сообщение отредактировал OsitKP - 26.12.15, 14:26

OsitKP,
Вообщем-то в данной программе я делаю, в основном "универсальный" функционал, свойственный для именно HEX редакторов, а не программ для патчинга. Для частных случаев есть макро. Не панацея, конечно, в силу скорости работы. А вот в плане функционала будет расширяться. В ближайших версиях, думаю, добавлю байтовые массивы и возможность чтения в них цепочек байтов.. ну и пофикшу чтение.

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

Спасибо, но, боюсь, это для меня сложно. :(

OsitKP,
Кстати, чтение работает правильно. Путаница из-за длины.. Смотрите (со второй строки выхлопа на скрине):
ee22330 == 0x0e e2 23 30, те 30 23 e2 0e в файле
дальше:
ee223 == 0x00 0e e2 23 или 23 e2 0e 00
И так далее.. Вообщем ошибка не в интерпретаторе, а в невнимательности (на первый взгляд мне результат тоже показался ошибочным)

PS: пожалуй, над вводом строк в макросистему всеже стоит подумать.. Чтобы была возможность вывода результата в более удобном для восприятия виде.

Сообщение отредактировал First Row - 26.12.15, 15:27

Так я сразу и написал, что проблема только в незначащих нулях, когда последовательность начинается с них. Собственно, трабла только в представлении чисел с незначащим нулем.