(а то старая демка что-то залежалась с 2004 года)
список ограничений demo-версии от 30 ноября 2010:
- поддержка только файлов PE 32бит
- нет ассемблера
- нет 64битного дизассемблера
- нет ARM дизассемблера
- нет поддержки логических/физических дисков
- нет модуля крипта
- нет обработки ini-файла
- нет sav-файла
- нет клавиатурных макросов
- нет записи/чтения имен (names)
- нет загрузки HEM (Hiew External Modules)
по многочисленным :) просьбам убрал лимитацию размера файла.
SEN, верни ассемблер и crypt !!!!
ОтветитьУдалитьИ многие будут пользоваться этой демкой а не ворованными версиями.
на то это и DEMO чтобы чего-то не хватало,
ОтветитьУдалитьа чем пользоваться каждый для себя сам решает.
Рекомендую внедрить фитчу - поиск по памяти компьютера (аттач к процессу и поиск в памяти)
ОтветитьУдалитьзачем ? для этого отладчики есть
ОтветитьУдалитьхиев всегда был для файлов только
для поиска в памяти можно и ArtMoney пользоваться :)... ну да штука не тока что бы в играх денюжку делать больше
ОтветитьУдалить> зачем ? для этого отладчики есть
ОтветитьУдалитьхиев всегда был для файлов только
Файлы могут быть и в памяти и ТОЛЬКО в памяти :). В целом такая фитча ОС зависима.
Есть еще одно пожелание - по alt+F9 в фаре есть разворот на весь экран(восстановление первоначального вида) - было бы неплохо иметь такое в hiew.
Сам юзаю свою разработку - плагин к far для 64бит(но он приватный и выложить - продать не могу) - hiew очень редко только для 16 бит програм, но случается.
>ТОЛЬКО в памяти
ОтветитьУдалитьэто повод к hiew отладчик приделать ?-)
одного ReadProcessMemory() маловато будет
>разворот на весь экран
еще со времен дос изменения размеров экрана никак не предусмотрены
Для просмотра памяти (а так же портов IO и прочего) есть утилита AXE из дистрибутива Miraculix OS, интерфейс создан по образу и подобию HIEW.
ОтветитьУдалитьKreoton
Предложения по доработке.
ОтветитьУдалить1. Было бы очень полезно добавить ещё 1 тип тип адреса (отображаемый в колонке слева) - RVA. Многие смещения в файле хранятся именно в RVA, вручную пересчитывать и переходить не удобно.
2. В таблице секций отображать сначала адрес rva объекта, затем его длину, для файлового смещения так же. Сейчас отображается длина, затем начальный адрес, как хранится в таблице секций.
1. зачем что-то добавлять если переходить можно как по va так и по rva; в 64битных PE базу можно менять без сохранения, в 32битных можно сделать дубль с нулевой базой.
ОтветитьУдалить2. отображается так как в оригинале, и это не просто так.
1. Возможно я просто что-то не знаю, или не то нажимаю. 8)
ОтветитьУдалитьЗадание новой базы (имеется ввиду Ctrl-F5 ? ) предполагает, что смещение для всех секций одинаковое (rva-physofs), а это не всегда так.
Тогда при просмотре разных секций понадобится постоянно менять базу. при отображении rva это не требовалось бы.
И эту базу (rva-physofs) еще нужно посчитать, даже если она одинаковая для всех секций.
Пример rva-physofs
база 0с00:
.text 000175C2 00001000 00017600 00000400 60000020
база 5000:
.idata 00000900 00020000 00000A00 0001B000 C0000040
ну и так далее.
А можно просто было бы rva адрес автоматически в колонке адреса показать, и тогда считать ничего не нужно.
2. По отображению секций. Да, это чисто субъективно и вопрос привычки.
Но гораздо нагляднее, когда отображается сначала адрес объекта (в памяти или в файле), затем его длина.
Таблица получается отсортирована по адресам.
Да и в программировании, при передаче параметров в функции в большинстве случаев передаётся начальный адрес, затем длина.
Если к указателю p добавить число 1000, получим указатель за концом этой области.
А тут получается к числу 1000 добавили указатель на начало. Это, как бы, ошибкой не будет, но так не пишут 8).
Ну и что, что внутри таблицы секций хранится наоборот. Там пусть хранится, а отображать лучше, как нагляднее.
Не настаиваю, просто описал своё видение этого момента.
ctrl-f5 не для этого, в PE надо менять image base в самом заголовке PE, либо через редактирование заголовка либо напрямую в дампе.
ОтветитьУдалить