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

| Сообщение посчитали полезным:

Есть четыре вопроса:
1) Зачем тебе это надо?
2) И что ты дальше будешь делать с кучей дампов?
3) Это что попытка создать новую ArtMoney?
4) Самому написать влом ?

| Сообщение посчитали полезным:

Объясняю .
1. Есть программа к взлому (на предмет снятия ограничений демо версии). Читает данные из внешних таблиц, но ограничивается ста пятьюдесятью записями. Распаковку сделал. Колхозный способ поиска константы 96h (97h) по коду не проканал. Тратить две недели на лобовую трассировку влом (прога не так чтобы очень маленькая). Отсюда мысль - сделать пару дампов и методом сравнения определить локацию, где прописано количество. Затем отслеживаем изменения этого участка под отладчиком. Разумеется гарантий никаких, но прежде чем тратить кучу времени на стэпы хотелось бы проверить простые способы.
2. Смотри п 1.
3. Определенно нет (даже не знаю что это такое).
4. Я не крэкер (был таким лет этак 10-12 назад, но давно в завязке - ломаю только то, что нужно для работы - раз-два в год) - времени и желания заниматься этим нет, работа с взламываемым софтом мне сейчас интереснее и важнее.

| Сообщение посчитали полезным:

agent Cooper пишет:
Я не крэкер
Я тоже. Ну и что.

Любой более-менее нормальный дампер умеет показывать области памяти и конечно же сохранять их в файл.

По-моему тебе стоит все-таки взламывать, а не играться с дампами.
А насчёт лобовой трассировки я не понял. Если программа считывает данные, то достаточно поставить точку остановки в этом месте.

| Сообщение посчитали полезным:

Наиболее глупого метода отлома демки имхо придумать еще не удавалось...

| Сообщение посчитали полезным:

Barakuda пишет:
Я тоже. Ну и что.

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

Barakuda пишет:
Любой более-менее нормальный дампер умеет показывать области памяти и конечно же сохранять их в файл.

Так дай же мне имя (а лучше ссылку :s15 на нормальный дампер - я уже полтора дня угробил на поиски (еще столько же и, пожалуй, действительно проще было самому написать). Перебрал некоторое количество дамперов (PE Tools etc.), но до аллокированных блоков они не докапываются - дампят только статику (ну или у меня ручки кривые и я что-то не то с ними делаю, но вроде до сих пор дебилом не считался :s14.

Barakuda пишет:
А насчёт лобовой трассировки я не понял. Если программа считывает данные, то достаточно поставить точку остановки в этом месте.

Под лобовой трассировкой я понимаю разумеется не стэпанье от точки входа в пронрамму. Считывание данных я обнаружил, и определение количества записей при считывании тоже. Но вот дальше там идут кубометры кода по обработке считанных данных и растусовыванию их во внутренние структуры данных. И отсечка записей делается не до них, а где-то внутри. Поэтому я хотел для начала обнаружить "главную" (конечную) переменную, где хранится количество записей, ну и дальше методом обратной трассировки выйти на код, ответственный за отсечение.

| Сообщение посчитали полезным:

Ara пишет:
Наиболее глупого метода отлома демки имхо придумать еще не удавалось...

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

| Сообщение посчитали полезным:

agent Cooper пишет:
ограничивается ста пятьюдесятью записями
отсюда и нужно плясать.
Пробуй трейсить до eax(ebx) == 96
А вообще ещё проще в запросы на взлом программы, если собственно методика взлома не интерессна.

| Сообщение посчитали полезным:

agent Cooper пишет:
динамически аллокированные им блоки памяти
Это речь идет об участках памяти, созданных прогой или протектором при помощи VirtualAlloc? Я правильно понял или нет?

| Сообщение посчитали полезным:

tar4 пишет:
Это речь идет об участках памяти, созданных прогой или протектором при помощи VirtualAlloc? Я правильно понял или нет?

Именно так.

| Сообщение посчитали полезным:

agent Cooper пишет:
Перебрал некоторое количество дамперов (PE Tools etc.), но до аллокированных блоков они не докапываются - дампят только статику
В том же PE Tools выбираешь в контекстном меню Dump Region... и смотришь на фрагменты памяти.

Если уж хочется тебе возится с дампами (хозяин- барин), есть утилита Рихтера:



87f7_04 ProcessInfo.exe

| Сообщение посчитали полезным:

SLayer пишет:
отсюда и нужно плясать.

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

SLayer пишет:
Пробуй трейсить до eax(ebx) == 96

В смысле автоматическим трейсером ? Спасибо, попробую, хотя что-то мне подсказывает, что если константы нет в коде в явном виде, то скорее весго вместо "if n>150 then n = 150" уважаемые разработчики устроили что-нибудь навроде "if n*2>300 then n = 75;n=n*2".

SLayer пишет:
А вообще ещё проще в запросы на взлом программы, если собственно методика взлома не интерессна.

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

| Сообщение посчитали полезным:

Тогда какие проблемы с дампом этих участков? Запускаешь прогу в отладчике, прерываешь исполнение проги в том месте, где исследуемый участок уже создан и в него записаны данные, запускаешь паралельно
любой PE-редактор, делаешь attach этого процесса и дампишь этот участок (dump region) с помощью редактора. А можно дампить этот участок и средствами отладчика (без PE-редактора).
И вообще, извини за нотацию, сразу бы объянил нормальным языком, чего хочешь - а то придумываешь какие-то слова типа "аллокированные" и думай, что это значит.

| Сообщение посчитали полезным:

Ксати, такой вопрос по этому поводу. =) Бывает, что динамически аллокированный адрес в запротекченных прогах меньше чем imagebase самой проги. Как в таком случае прицеплять сдампленную секцию ? - Переправлять все адреса в ней ? или может есть способ попроще ?

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Smon пишет:
Переправлять все адреса в ней ? или может есть способ попроще ?
Мне кажется, здесь два пути:
1. Переправлять адреса, ссылающиеся на эту секцию
2. Самому создать этот участок (через VirtualAlloc) и затем скопировать весь код из прикрепленной секции во вновь созданный участок.

| Сообщение посчитали полезным:

tar4 пишет:
Тогда какие проблемы с дампом этих участков? Запускаешь прогу в отладчике, прерываешь исполнение проги в том месте, где исследуемый участок уже создан

Проблема именно в том и состоит, чтобы найти, куда именно (адрес) в памяти программы ложится в конце концов количество записей. Я вижу под отладчиком первоначальное считывание и определение количества (ложится в регистр). Дальше, как я уже писал, хренова куча кода, через который мне лень продираться. А потом их становится 150, но вижу я это не в памяти, а банально в интерактиве - на экране. Более того - если бы у меня был требуемый дампер, то можно было бы запустить в параллелке два отладчика с копиями проги, натравленными на таблицы разных размеров и периодически сравнивая дампы определить критический момент.

tar4 пишет:
И вообще, извини за нотацию, сразу бы объянил нормальным языком, чего хочешь - а то придумываешь какие-то слова типа "аллокированные" и думай, что это значит.

Забавно . Дело в том, что в программистских сообществах, в которых я вращаюсь, подобный слэнг является настолько родным, что мне и в голову не приходило, что для кого-то это не так. Сорри .

| Сообщение посчитали полезным:

Barakuda пишет:
В том же PE Tools выбираешь в контекстном меню Dump Region... и смотришь на фрагменты памяти.

Если уж хочется тебе возится с дампами (хозяин- барин), есть утилита Рихтера:

Насчет Dump Region - каюсь, просмотрел (решил, что если есть команда Dump Full, то там наверняка включено и все то, что в остальных двух). Так что спасибо (если б там еще group selection для блоков имелся :s4 !

Насчет утилиты Рихтера - там только список блоков, никаких дампов.

| Сообщение посчитали полезным:

tar4
В том то и хрень, что иногда в такой секции бывают жестко прописанные адреса типа mov регистр,адрес;call или jmp регистр; или просто call в секции, потому кроме адресов в проге приходится переправлять и их

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

agent Cooper пишет:
Насчет утилиты Рихтера - там только список блоков, никаких дампов.
Естественно. Рихтер дампами не балуется Утилиту дал для сравнения с блоками что показывает Pe Tools.
Если так хочется дампить автоматом, то могу дать исходники этой утилиты, там всего лишь надо дампинг дописать.

| Сообщение посчитали полезным:

agent Cooper ïèøåò:
Не соблаговолит ли почтенный гуру научить оболтуса уму и разуму ?
Если опустить Ваш сарказм и вышестоящие поводы по поводу дампа (который стопудофф ничего полезного не даст), то причину чтения только 150 записей стоит искать в самой программе. И константу искать бесполезно, т.к. запись врядли будет равняться 1 байту, чтобы искать именно 150 байт. Реальнее отлавливать процедуру чтения из файла, дальше смотреть, читается ли весь файл ( а скорее всего читается весь), и что делается с записями, которые ограничены. Если конечно они записываются в файл, по идее их там и не должно быть, коль это демо...

| Сообщение посчитали полезным:

Barakuda пишет:
Если так хочется дампить автоматом, то могу дать исходники этой утилиты, там всего лишь надо дампинг дописать.

Буду признателен.

| Сообщение посчитали полезным:

Ara пишет:
Не соблаговолит ли почтенный гуру научить оболтуса уму и разуму ?
Если опустить Ваш сарказм

Никакого сарказма - одно лишь смирение .

Ara пишет:
И константу искать бесполезно, т.к. запись врядли будет равняться 1 байту, чтобы искать именно 150 байт. Реальнее отлавливать процедуру чтения из файла, дальше смотреть, читается ли весь файл ( а скорее всего читается весь), и что делается с записями, которые ограничены.

Процедуру чтения из файла отловил первым делом - читается он полностью, для того чтобы автоматически определить типы столбцов, их максимальную длину, разделитель. Константу искать небесполезно хотя бы потому что, как я уже писал, предыдущая версия проги сломалась именно таким способом. Но с нынешней не помогло. Кроме того представьте, что Вы пишете демо-версию программы с подобным ограничением - как бы Вы это сделали ? Худший вариант - статический массив размером 150*максимальный размер записи - в этом случае предстоит немаленький геморрой по увеличению его размеров. Но в принципе, как ни крути, где-то должна быть прямая или косвенная проверка соотношения считанного количества с числом 150. И дамп представляется мне всего лишь шансом найти эту проверку быстрее пошаговой трассировки.

| Сообщение посчитали полезным:

agent Cooper
Исходник завтра. А сегодня... Ara дело говорит. То что данные считались а потом с ними работает куча процедур это прекрасно. Но ведь формат записи известен ? Поставь брейк на память, и выясни в каком месте эти записи формируются и по какому принципу они обрезаются. Другими словами тебе нужно место формирования, а для этого как никак лучше подходит BPM чем дампинг.

| Сообщение посчитали полезным:

А вообще, количество считанных записей можно подсчитывать не только константой
If (size > 150)

но и переменной,
int MaxSize = 150;
If (size > maxSize)

а также через sizeof(),
If( sizeof(Data) > 150 * sizeof(_structData) )
да мало ли какими вариантами, так что «колхозный способ» это не самый лучший вариант поиска проблемы.

| Сообщение посчитали полезным:

Barakuda пишет:
А вообще, количество считанных записей можно подсчитывать не только константой
If (size > 150)

но и переменной,
int MaxSize = 150;
If (size > maxSize)

а также через sizeof(),
If( sizeof(Data) > 150 * sizeof(_structData) )
да мало ли какими вариантами, так что «колхозный способ» это не самый лучший вариант поиска проблемы.

Все перечисленные тобой варианты предполагают нахождение где-либо в коде программы цифры 96h (97h) в явном виде (хотя не спорю - возможны и альтернативы - приведенные мною if n*2>300).

"Колхозный" вариант естественно не гарантия - просто хороший шанс сэкономить время.

Barakuda пишет:
Поставь брейк на память

Работает прога примерно так - считывает файл в массивы - затем куча операций, затем все оказыватся в каких-то рекордсетах, найти адреса которых не слишком просто - опять же, помог бы дампер.
Мне к сожалению неизвестны способы ставить брейки на чтение на x86 (возможно спец. отладчики навроде Soft Ice позволяют ?) - поэтому самый естественный способ - поставить брейк на чтение из первоначальных массивов, который сработал бы на каком нибудь VAX/VMS не канает.

| Сообщение посчитали полезным:

agent Cooper пишет:
Все перечисленные тобой варианты предполагают нахождение где-либо в коде программы цифры 96h (97h) в явном виде (хотя не спорю - возможны и альтернативы - приведенные мною if n*2>300).

Первый вариант: поиск в распакованой проге Hiew-ом F7->F7->"cmp ?, 96"
Второй вариант: в Hiew F7->"96" а дальше поиск ссылок F6.
Третий вариант: так как sizeof() вычисляется компилятором ещё на стадии трансляции, то "150 * sizeof(_structData)" будет какое-то большое число. Так что приехали.

agent Cooper пишет:
Мне к сожалению неизвестны способы ставить брейки на чтение
СТОП! Я не понял, а чем ты программу отлаживаешь ?

| Сообщение посчитали полезным:

Barakuda пишет:
Первый вариант: поиск в распакованой проге Hiew-ом F7->F7->"cmp ?, 96"

Первое что я сделал. И даже не только cmp, но и sub. И даже (пустившись во все тяжкие) просто 096. No result.

Barakuda пишет:
СТОП! Я не понял, а чем ты программу отлаживаешь ?

Сейчас меня всем форумом с наслаждением отлупят веником . Студией масдайной. Работаю я в ней постоянно, ну и отлаживаю соответственно тоже.

| Сообщение посчитали полезным:

Barakuda пишет:
150 * sizeof(_structData)" будет какое-то большое число. Так что приехали.

Исключается, так как структура записи проге изначально неизвестно - определяет при чтении.

| Сообщение посчитали полезным:

agent Cooper пишет:
Студией масдайной
Мда. Но ничего страшного. Я сам этим иногда грешу

agent Cooper
Так. У меня экстрасенсорные возможности плохо развиты.
Если хочешь сам это сделать то давай ссылку на прогу, а там видно будет.
Если нет, то пишы в запросы на взлом.

| Сообщение посчитали полезным:

А то что сейчас кого-то будут веником, это точно, и не тебя одного. 29 ответов на тему а всё бестолку, один флуд выходит

| Сообщение посчитали полезным: