Под 9x: обязательно ли должна юзаться RtlMoveMemory, или есть другие способы (кроме реестра)?

ps
Кстати, прога при запуске точно юзает RtlMoveMenory (точнее, выполняется ее код в Kernel).
Но место вызова отловить не получается: на бряке падает Олька, а если зациклить -- подвисает ось.
Пробовал дойти до события (падения Ольки) по F8/F7, но раз на раз не приходится (хитрый код). Удалось только грубо вычислить километровую процедуру, перепрыгивать которую нельзя...
Что посоветуете?

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

function GetBIOSDate: string;
{получение даты BIOS в Win95}
var
s: array[0..7] of char;
p: pchar;
begin
p := @s;
asm
push esi
push edi
push ecx
mov esi,$0ffff5
mov edi,p
mov cx,8
@@1:mov al,[esi]
mov [edi],al
inc edi
inc esi
loop @@1
pop ecx
pop edi
pop esi
end;
setstring(result, s, 8);
end;

//-----------------------------------------------------
procedure TBIOSInfo.GetRegInfoWinNT;
var
Registryv: TRegistry;
RegPath: string;
sl: TStrings;
begin
Params.Clear;
RegPath := 'HARDWAREDESCRIPTIONSystem';
registryv := tregistry.Create;
registryv.rootkey := HKEY_LOCAL_MACHINE;
sl := nil;
try
registryv.Openkey(RegPath, false);
ShowMessage('BIOS Date: ' + RegistryV.ReadString('SystemBiosDate'));
sl := ReadMultirowKey(RegistryV, 'SystemBiosVersion');
ShowMessage('BIOS Version: ' + sl.Text);
except
end;
Registryv.Free;
if Assigned(sl) then
sl.Free;
end;

-----
Сколько ни наталкивали на мысль – все равно сумел увернуться

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

WinNT
Дату биоса не пробовал, но серийник когда-то получал. Делал приблизительно так:
Поскольку ROM BIOS маппится на адреса 0xF9000-0xFFFFF, то задача сводится до прочитки этой памяти.
Для этого нужны 3 функции
1. NtOpenSection
2. NtMapViewOfSection
3. NtUnmapViewOfSection

далее код

HANDLE hSectionHandle,
PDWORD pAddress, //физический адрес
DWORD dwLength, //длина сегмента
PDWORD pVirtualAddress //наш адрес
PHYSICAL_ADDRESS ViewBase;

UNICODE_STRING szPhysmemString;
OBJECT_ATTRIBUTES oaAttributes;

RtlInitUnicodeString( &szPhysmemString, L"devicephysicalmemory" );
InitializeObjectAttributes( &oaAttributes, &szPhysmemString,OBJ_CASE_INSENSITIVE, NULL, NULL );

NtOpenSection( &hSectionHandle, SECTION_MAP_READ, &oaAttributes );

ViewBase.QuadPart = (ULONGLONG) (*Address);

// собственно получаем указатель на область физической памяти

pVirtualAddress = NULL;
ViewBase.QuadPart = (ULONGLONG) (pAddress);
ntStatus = NtMapViewOfSection
(
hSectionHandle(HANDLE) -1,
(PVOID) &pVirtualAddress,
0L,
dwLength,
&ViewBase,
&dwLength,
ViewShare,
0,
PAGE_READONLY
);

// copy all data from pVirtualAddress to local or stack memory.
....

NtUnmapViewOfSection(-1,pVirtualAddress);
CloseHandle(hSectionHandle);
Возможно эту процедуру можна также использовать для получения даты. В device manager посмотреть память на которую маппится CMOS таймер и читать оттуда.

Также рекомендую посмотреть книгу Коберниченко "Недокументированные возможности Windows NT" - возможно даст новые идеи и статью
МЕНЕДЖЕР ПАМЯТИ И ПРОЦЕССЫ
http://gl00my.chat.ru/nt/mem.txt http://gl00my.chat.ru/nt/mem.txt

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

ValdiS пишет:
function GetBIOSDate: string;
{получение даты BIOS в Win95}
Прям внаглую, без ни каких АПИ? И как же эту жуть с ружжом в коде найти?

ps
А в NT -- дай Бог, чтоб из реестра брало! Там тоже есть и более наркоманские способы: через драйвер, ну и тот, что amely написал (правда, последний не проверял)

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

ValdiS пишет:
-- skipped --
mov esi,$0ffff5
-- skipped --
Поскольку взятие даты, серийника и тп из биоса сводится к прочитке некоторого куска памяти - тогда можна попробовать прочитать память по адресу $0ffff5 (входит в регион 0xF9000-0xFFFFF ) подставив pAddress = 0ffff5.
В Win98 к адресам памяти 0xF9000-0xFFFFF есть прямой доступ, в WinNT надо извращатся

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

0xy пишет:
И как же эту жуть с ружжом в коде найти?
нацелить ружжо на константу $0ffff5 и стрелять (искать)

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

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

-----
Сколько ни наталкивали на мысль – все равно сумел увернуться

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

ValdiS пишет:
Ставь бряк по адресу 0х0ffff5 и от него пляши дальше
Дык нету у меня такого адреса!



4de3_20.11.2006_CRACKLAB.rU.tgz - MemoryMap.png"

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

0xy пишет:
MemoryMap.png"
Чего-то не то прицепил. Пустой файл. В имени не должно быть " Точнее, когда их 2, можно пробелы использовать.

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

0xy
Что за программа? Сколько весит? Давай линк...

-----
Сколько ни наталкивали на мысль – все равно сумел увернуться

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

Тут дело не в проге! А втом, что диапазон памяти FA000-FFFFF под Олькой у меня всегда отсутствует! (независимо от того, какую прогу отлаживаю)
-->См. скрин<-- http://i80.front.ru/CL/MemoryMap.png

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

0xy пишет:
диапазон памяти FA000-FFFFF под Олькой у меня всегда отсутствует
Ну это ведь физические адреса. Как ставить бряки на физические адреса я незнаю, даже незнаю возможно ли это Можно посмотреть с какими адресами в адресном пространстве процесса работает функция RtlMoveMemory и на них ставить бряки.

есть программа PhysMem от Mark Russinovich download.sysinternals.com/Files/PhysMem.zip - которая читает физическую память. Подробности о программе здесь www.microsoft.com/technet/sysinternals/information/TipsAndTrivia.mspx

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

amely пишет:
Можно посмотреть с какими адресами в адресном пространстве процесса работает функция RtlMoveMemory и на них ставить бряки.
RtlMoveMemory в явном виде не вызывается!

ValdiS пишет:
Ставь бряк по адресу 0х0ffff5
Так все-таки, возможно ли это сделать в моем случае, и как?

ps
Пробовал код mov eax,[fffff5] работает нормально. Причем Олька еще до выполнения этого mov видит, что лежит по этому адресу, а вот отобразить его в дампе почему-то НЕ ПОЗВОЛЯЕТ! Т.е. бряк ставить не на что

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

0xy
1. Искать констанду 0ffff5 в коде (если она есть в чистом виде).
2. Посмотреть дату биоса, ставить бряки в коде и искать эту дату как константу в коде и далее все refferences на нее.
Должна ведь программа копировать эту дату в адресное пространство своего процесса - дата ведь как строчка представлена.

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

amely пишет:
1. Искать констанду 0ffff5 в коде (если она есть в чистом виде).
В чистом виде не наблюдается.
amely пишет:
Должна ведь программа копировать эту дату в адресное пространство своего процесса - дата ведь как строчка представлена.
Не факт, что как строчка: прога хитрая, может и по быйтам разбросать. Так сто лет искать можно

ValdiS
Как же все-таки поставить бряк на ffff5, если Олька не видет этого диапазона???

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

0xy пишет:
Не факт, что как строчка:
имелось ввиду, что дата представлена как строчка в биосе. Возможно прога по байтам разбрасывает эту строчку, а возможно и нет.

Все-таки ставить бряку на адреса не в аддресном просторе процесса думаю невозможно. хотя возможно я ошибаюсь.

Можно еще идти по пути хуков - смотреть Hooking the native API или использовать программы которые показывают какие native API вызывает программа и смотреть работают ли они с нужными адресами.

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

amely пишет:
Можно еще идти по пути хуков - смотреть Hooking the native API или использовать программы которые показывают какие native API вызывает программа и смотреть работают ли они с нужными адресами.
Млин, но не юзаются ни какие апи! Тупо: mov eax,[ffff5] -- и получаем дату! Т.е. отлаживаемая прога имеет доступ к этому ffff5. А вот для Ольки он почему-то недоступен

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

0xy пишет:
Млин, но не юзаются ни какие апи! Тупо: mov eax,[ffff5] -- и получаем дату!
В NT этот адрес обычно прогами не используется. Значит в твоей проге этот диапазон открыт на доступ. Чудес не бывает - использовано какое-то API. Смотри карту памяти и следи.
RtlMoveMemory тут не при чем - она только проверяет легальность адресов.

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

0xy
0xy пишет:
Тупо: mov eax,[ffff5] -- и получаем дату!
Тут надо оговорить, что это в Win9x. Попробуй ставить в командной строчке Olly, hr 000FFFF5, где hr(hardware break on access) или mr(memory break on access). Поскольку нет Win9x - проверить нет возможности.

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

Народ, давайте по порядку:
tundra37 пишет:
В NT этот адрес обычно прогами не используется
Речь об 9x!
mov eax, [ffff5] нормально срабатывает в ЛЮБОМ месте ЛЮБОЙ(!) проги (хоть на EP).
А вот Олька этого диапазона НЕ видит!

amely пишет:
Тут надо оговорить, что это в Win9x
Уже оговорили
amely пишет:
hr 000FFFF5, где hr(hardware break on access) или mr
Не ставится

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

0xy пишет:
А вот Олька этого диапазона НЕ видит!
А мы то здесь при чем ?! Действительно не видит. Но кроме нее есть еще куча других отладчиков.
Например, софтайс, который под 98-м все показывает.

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

Всё же меня интересует, как можно ткнуть носом Олю, чтоб она увидела этот диапазон? (или любой другой, которого она почему-то не увидела)?

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

0xy пишет:
как можно ткнуть носом Олю
Олю никак. Так она написана. Либо из соображений безопасности ситемная область закрыта от доступа - видимо в 98-м отсутствует защита на запись. Либо автор не особо заботился об удобстве работы именно в 98-м. В любом случае лучше автору претензии выставить.
И никто не мешает поотлаживать саму олю Можешь другую тему создать, если хочешь чтобы знающие люди ответили. Про БИОС и смотреть никто не будет.

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

Ok. Закрыли.

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

0xy пишет:
Закрыли.
А зря. Все на самом деле гораздо проще. Попалась утилита SMBIOS - 16-битная, но работает под ХП и 98.
Версия от этого года Думал придется лезть в отладчик или IDA подключать, но авторы выложили инфу "на блюдечке". Значит так : входим в debug.exe и ищем сигнатуру _SM_ Со сдвигом на 18 адрес мапы "железного БИОС"(а может и он сам). Там видим дату и все остальное.
Любопытные могут залезть внутрь и поиметь алгоритм, но думаю все сводится к чтению памяти, правда в 16-битном режиме.


db3b_22.12.2006_CRACKLAB.rU.tgz - smbiosw.zip

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