Чтение данных из физической ячейки памяти
От: SPavel Украина  
Дата: 17.01.03 08:33
Оценка:
Привет Всем.
Требуется прочитать данные из ячейки физической памяти по адресу 0xF000EC71. Длиной около 21 байта. Чтение должно производиться в системах Win 95/98, Win 2000/XP. Поэтому средства ассемблера сразу отпадают.
Что предпринималось: была написана тестовая программа
#include <stdio.h>
void main()
{
    char * addr = (char *) 0xF000EC71;
    printf ("Read data = %s\n", addr);
/* или так:
    int * addr = (int *) 0xF000EC71;
    printf ("Read data = %d\n", * addr);
*/
}

Однако это не сработало — и под Win 98, и под Win 2000.
Вероятно, данная ячейка является защищаемой областью памяти.
Поиск в Инете по ключевым словам "Чтение ячейки памяти известному адресу" ничего не дал
Подскажите, пожалуйста решение данной проблемы или путь поиска решения.
С уважением, Павел
Re: Чтение данных из физической ячейки памяти
От: Whisperer  
Дата: 17.01.03 09:01
Оценка:
Здравствуйте, SPavel, Вы писали:

Драйвер.
Re: Чтение данных из физической ячейки памяти
От: Snax Россия  
Дата: 17.01.03 09:06
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Требуется прочитать данные из ячейки физической памяти по адресу 0xF000EC71.


Касаемо NT, есть такой драйвер, \device\physicalmemory через
него можно читать именно ячейки физической памяти. Только вот...
Это ж в районе 4-х гигибайт! (0xf000ec71 == 4 026 592 369).

Касаемо 98. Виртуальная память по таким адресам используется
драйверами и даже доступна для записи. Смотрите у Риштера
"Windoze для профессионалов", глава 4. Опять повторюсь, это
касаемо виртуальных адресов.

Павел.
Re: Чтение данных из физической ячейки памяти
От: kmn Украина  
Дата: 17.01.03 09:16
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Привет Всем.

SP>Требуется прочитать данные из ячейки физической памяти по адресу 0xF000EC71. Длиной около 21 байта. Чтение должно производиться в системах Win 95/98, Win 2000/XP. Поэтому средства ассемблера сразу отпадают.
SP>Что предпринималось: была написана тестовая программа
SP>
SP>#include <stdio.h>
SP>void main()
SP>{
SP>    char * addr = (char *) 0xF000EC71;
SP>    printf ("Read data = %s\n", addr);
SP>/* или так:
SP>    int * addr = (int *) 0xF000EC71;
SP>    printf ("Read data = %d\n", * addr);
SP>*/
SP>}
SP>

SP>Однако это не сработало — и под Win 98, и под Win 2000.
SP>Вероятно, данная ячейка является защищаемой областью памяти.
SP>Поиск в Инете по ключевым словам "Чтение ячейки памяти известному адресу" ничего не дал
SP>Подскажите, пожалуйста решение данной проблемы или путь поиска решения.
SP>С уважением, Павел

Если речь идет, действительно, о физической памяти по адресу 0xF000EC71, то Вам необходимо ознакомиться с формирование физического адреса в расширенном (защищенном) режиме (скорее всего, придется писать драйвер).

Если это адрес в пределах адресного пространства процесса, то вот что пишет Д. Рихтер по этому поводу:

Win95:

0xC0000000:0xFFFFFFFF — Регион размером 1Гб для драйверов виртуальных устройств, диспетчера памяти и кода файловой системы; доступен всем Win32 процессам для чтения и записи (но лучше туда ничего не записывать).


WinNT:

0x80000000:0xFFFFFFFF — Регион размером 2Гб для операционной системы (не доступен)



Может, если Вы напишете, для чего Вам необходимо обращаться по этому адресу, то будет легче решить проблему.
Re[2]: Чтение данных из физической ячейки памяти
От: SPavel Украина  
Дата: 17.01.03 09:42
Оценка:
Здравствуйте, kmn, Вы писали:

kmn>Если речь идет, действительно, о физической памяти по адресу 0xF000EC71, то Вам необходимо ознакомиться с формирование физического адреса в расширенном (защищенном) режиме (скорее всего, придется писать драйвер).


kmn>Если это адрес в пределах адресного пространства процесса, то вот что пишет Д. Рихтер по этому поводу:


kmn>Win95:

kmn>

kmn>0xC0000000:0xFFFFFFFF — Регион размером 1Гб для драйверов виртуальных устройств, диспетчера памяти и кода файловой системы; доступен всем Win32 процессам для чтения и записи (но лучше туда ничего не записывать).


kmn>WinNT:

kmn>

kmn>0x80000000:0xFFFFFFFF — Регион размером 2Гб для операционной системы (не доступен)


kmn>

kmn>Может, если Вы напишете, для чего Вам необходимо обращаться по этому адресу, то будет легче решить проблему.

Действительно, проблема обстоит несколько иначе — требуется выяснить ID материнской платы. Была предпринята попытка выяснения этого номера средствами ОС. Не получилось (данных не хватает). К сожалению, на данном форуме неоднократно звучал вопрос о выяснении серийного номера материнской платы. Конкретных ответов я не нашёл. Поэтому решил подойти к проблеме с другой стороны:
Было выяснено, что искомая информация содержится по адресу 0xF000EC71. Вот и всё.....

С уважением, Павел
Re[3]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 17.01.03 11:06
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Не получилось (данных не хватает).

Каких именно данных не хватает?

SP>К сожалению, на данном форуме неоднократно звучал вопрос

К счастью!

SP>Конкретных ответов я не нашёл.

А вот это — к сожалению.

SP>Было выяснено, что искомая информация содержится по адресу 0xF000EC71.

Как уже выяснили, это не физическая память, а ВАП ядра. Потому чтоб оттуда читать — надо писать драйвер. Однако, есть ее WMI, которая на Win2k очень даже работает.
Васкецов Сергей
http://registry.km.ru
Re: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 17.01.03 11:46
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Привет Всем.

SP>Требуется прочитать данные из ячейки физической памяти по адресу 0xF000EC71. Длиной около 21 байта. Чтение должно производиться в системах Win 95/98, Win 2000/XP.

Насчет Win 95/98 — читай Питрека (Matt Pietrek) "Секреты системного программирования по Windows 95". Книга издавалась на русском, в интернете я встречал только английский вариант, откликается на PietrekBook.pdf.

SP>Поэтому средства ассемблера сразу отпадают.


Почему? Ассемблер != драйвер. Кроме того, очевидно, что для 95 и 2000 задачу придется решать разными способами.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 17.01.03 11:57
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Почему? Ассемблер != драйвер.

Правильнее было бы написать, "а при чем тут вообще ассемблер?"
Васкецов Сергей
http://registry.km.ru
Re[4]: Чтение данных из физической ячейки памяти
От: SPavel Украина  
Дата: 17.01.03 12:14
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Как уже выяснили, это не физическая память, а ВАП ядра. Потому чтоб оттуда читать — надо писать драйвер. Однако, есть ее WMI, которая на Win2k очень даже работает.


Однако требуется, чтобы работало и на Win 95/98.
По поводу WMI — этот вариант я рассматривал (ознакомительно — просматривал статьи). Нужной информации не нашёл. Возможно, не заметил нужной инфы. К тому же, как я понял — WMI предназначается для управления, и информации относительно выуживания серийных номеров не заметил.

С уважением, Павел
Re[5]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 17.01.03 12:22
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Однако требуется, чтобы работало и на Win 95/98.

Пишите драйвер, честнее будет.
Васкецов Сергей
http://registry.km.ru
Re[5]: Чтение данных из физической ячейки памяти
От: VVV Россия  
Дата: 17.01.03 12:32
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Здравствуйте, vasketsov, Вы писали:


SP>По поводу WMI — этот вариант я рассматривал (ознакомительно — просматривал статьи). Нужной информации не нашёл. Возможно, не заметил нужной инфы. К тому же, как я понял — WMI предназначается для управления, и информации относительно выуживания серийных номеров не заметил.


SP>С уважением, Павел


Попробуй этот скрипт (сгенерён с помощью Scriptomatic) запиши скрипт в файл baseboard.vbs и запусти cscript baseboard.vbs или просто даблкликом.


On Error Resume Next
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_BaseBoard",,48)
For Each objItem in colItems
    Wscript.Echo "Caption: " & objItem.Caption
    Wscript.Echo "ConfigOptions: " & objItem.ConfigOptions
    Wscript.Echo "CreationClassName: " & objItem.CreationClassName
    Wscript.Echo "Depth: " & objItem.Depth
    Wscript.Echo "Description: " & objItem.Description
    Wscript.Echo "Height: " & objItem.Height
    Wscript.Echo "HostingBoard: " & objItem.HostingBoard
    Wscript.Echo "HotSwappable: " & objItem.HotSwappable
    Wscript.Echo "InstallDate: " & objItem.InstallDate
    Wscript.Echo "Manufacturer: " & objItem.Manufacturer
    Wscript.Echo "Model: " & objItem.Model
    Wscript.Echo "Name: " & objItem.Name
    Wscript.Echo "OtherIdentifyingInfo: " & objItem.OtherIdentifyingInfo
    Wscript.Echo "PartNumber: " & objItem.PartNumber
    Wscript.Echo "PoweredOn: " & objItem.PoweredOn
    Wscript.Echo "Product: " & objItem.Product
    Wscript.Echo "Removable: " & objItem.Removable
    Wscript.Echo "Replaceable: " & objItem.Replaceable
    Wscript.Echo "RequirementsDescription: " & objItem.RequirementsDescription
    Wscript.Echo "RequiresDaughterBoard: " & objItem.RequiresDaughterBoard
    Wscript.Echo "SerialNumber: " & objItem.SerialNumber
    Wscript.Echo "SKU: " & objItem.SKU
    Wscript.Echo "SlotLayout: " & objItem.SlotLayout
    Wscript.Echo "SpecialRequirements: " & objItem.SpecialRequirements
    Wscript.Echo "Status: " & objItem.Status
    Wscript.Echo "Tag: " & objItem.Tag
    Wscript.Echo "Version: " & objItem.Version
    Wscript.Echo "Weight: " & objItem.Weight
    Wscript.Echo "Width: " & objItem.Width
Next


также посмотри http://www.rsdn.ru/Forum/Message.aspx?mid=126901#126901
Автор: VVV
Дата: 06.11.02
там есть пример как перевести скрипт на C++
Re: Чтение данных из физической ячейки памяти
От: Roman_M rgmroman.narod.ru
Дата: 17.01.03 12:35
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Привет Всем.

SP>Требуется прочитать данные из ячейки физической памяти по адресу 0xF000EC71. Длиной около 21 байта. Чтение должно производиться в системах Win 95/98, Win 2000/XP. Поэтому средства ассемблера сразу отпадают.
SP>Что предпринималось: была написана тестовая программа
SP>
SP>#include <stdio.h>
SP>void main()
SP>{
SP>    char * addr = (char *) 0xF000EC71;
SP>    printf ("Read data = %s\n", addr);
SP>/* или так:
SP>    int * addr = (int *) 0xF000EC71;
SP>    printf ("Read data = %d\n", * addr);
SP>*/
SP>}
SP>

SP>Однако это не сработало — и под Win 98, и под Win 2000.
SP>Вероятно, данная ячейка является защищаемой областью памяти.
SP>Поиск в Инете по ключевым словам "Чтение ячейки памяти известному адресу" ничего не дал
SP>Подскажите, пожалуйста решение данной проблемы или путь поиска решения.
SP>С уважением, Павел

Такой код не сработает практически никогда. Под NT системы, как уже говорилось есть \device\PhysicalMemory, нужны только права администратора, под W9x наверное придется писать драйвер, который будет делать
 VMMCall _MapPhysToLinear, <PhysAddr, nBytes, flags>

PhysAddr = 0xF000E000
nBytes = 0x1000
flags = 0

и потом читать данные по полученному линейному адресу+0xC71. Хотя вероятно удасться обойтись без VxD, если написать программу под DPMI. Программа будет делать
 mov   (e)ax, 800h
 mov   (e)cx, 0E000h
 mov   (e)bx, 0F000h
 mov   (e)di, 1000h
 xor   (e)si, (e)si
 int    31h
потом, при необходимости, создавать селектор с базовым адресом, который будет в BX:CX после int 31h, при условии CF=0, а после этого читать значение по нужному адресу. При желании это можно попытаться выполнить в Win16 DLL, которую можно вызвать из Win32 программы через thunk.
Re[6]: Чтение данных из физической ячейки памяти
От: Whisperer  
Дата: 17.01.03 12:51
Оценка:
Здравствуйте, vasketsov, Вы писали:

ДрайверА
Re[2]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 17.01.03 13:11
Оценка:
Здравствуйте, Roman_M, Вы писали:

RM>есть \device\PhysicalMemory,

Читает именно физическую память, а не ВАП ядра.
Васкецов Сергей
http://registry.km.ru
Re[3]: Чтение данных из физической ячейки памяти
От: Roman_M rgmroman.narod.ru
Дата: 17.01.03 13:24
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, Roman_M, Вы писали:


RM>>есть \device\PhysicalMemory,

V>Читает именно физическую память, а не ВАП ядра.

Так там, вроде, и нужна физическая память, а не виртуальная.
Re[4]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 17.01.03 13:28
Оценка:
Здравствуйте, Roman_M, Вы писали:

RM>...там, вроде, и нужна физическая память

Не-а. В принципе нереально, чтобы что-нибудь располагалось фиксировано по ТАКОМУ адресу в физической памятию Потому что памяти чаще меньше.
Васкецов Сергей
http://registry.km.ru
Re[3]: Чтение данных из физической ячейки памяти
От: SPavel Украина  
Дата: 17.01.03 13:32
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, Roman_M, Вы писали:


RM>>есть \device\PhysicalMemory,

V>Читает именно физическую память, а не ВАП
Хорошо — а как им воспользоваться? В MSDN об этом написано крайне скудно

The PhysicalMemory property gives the size of the installed RAM in Megabytes

И как я понимаю, это не совсем то, что имелось в виду под "\device\PhysicalMemory"
Re[4]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 17.01.03 13:34
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Хорошо — а как им воспользоваться?

В DDK и на sysinternals.com есть примеры, и еще куча их разбросано.
Васкецов Сергей
http://registry.km.ru
Re[5]: Чтение данных из физической ячейки памяти
От: Roman_M rgmroman.narod.ru
Дата: 17.01.03 13:42
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, Roman_M, Вы писали:


RM>>...там, вроде, и нужна физическая память

V>Не-а. В принципе нереально, чтобы что-нибудь располагалось фиксировано по ТАКОМУ адресу в физической памятию Потому что памяти чаще меньше.

Очень даже реально. Вам не доводилось программировать вывод графики под DOS в разрешени 640x480 и выше через Linear Frame Buffer (VBE 2.0 +) ? Так вот Frame Buffer вполне может располагаться на подобных адреса, если не верите, посмотрите "Свойства системы"->"Диспетчер устройств"->"Видеоадаптеры"->"Свойства"->"Ресурсы". А также можно посмотреть ресурсы устройства "системная плата" (вроде бы нужен её номер), там адреса будут именно такими.
Re[5]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 17.01.03 13:45
Оценка:
Здравствуйте, vasketsov, Вы писали:

RM>>...там, вроде, и нужна физическая память

V>Не-а. В принципе нереально, чтобы что-нибудь располагалось фиксировано по ТАКОМУ адресу в физической памятию Потому что памяти чаще меньше.

Смотря что понимать под физической памятью. Если RAM, то вряд ли. А вот если I/O порты, на память мапленные, то очень даже реально. Вот например на компьютере, за которым я сейчас сижу, Device Manager показывает, что System Board зарезервировала себе кусок памяти FFFE0000 — FFFFFFFF. Почему бы ей не выдавать при чтении из какого-то из этих адресов регистры чипсета, свой ID и прочее?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[6]: Чтение данных из физической ячейки памяти
От: Михаил Можаев Россия www.mozhay.chat.ru
Дата: 17.01.03 13:49
Оценка: -1
Здравствуйте, Roman_M, Вы писали:

RM>Очень даже реально. Вам не доводилось программировать вывод графики под DOS в разрешени 640x480 и выше через Linear Frame Buffer (VBE 2.0 +) ? Так вот Frame Buffer вполне может располагаться на подобных адреса, если не верите, посмотрите "Свойства системы"->"Диспетчер устройств"->"Видеоадаптеры"->"Свойства"->"Ресурсы". А также можно посмотреть ресурсы устройства "системная плата" (вроде бы нужен её номер), там адреса будут именно такими.


Неа
Речь идет о физической (!!!!!) памяти. А эти адреса — виртуальные.
"Почувствуйте разницу..." (С)Реклама на ТВ
... << RSDN@Home 1.0 beta 4 >>
Re[6]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 17.01.03 13:50
Оценка:
Здравствуйте, Sergey, Вы писали:

Вот вы попробуйте из этой секции прочитать по этому адресу, тогда и поговорим.
Васкецов Сергей
http://registry.km.ru
Re[7]: Чтение данных из физической ячейки памяти
От: Михаил Челноков Украина  
Дата: 17.01.03 13:59
Оценка:
Здравствуйте, Михаил Можаев, Вы писали:

RM>>Очень даже реально. Вам не доводилось программировать вывод графики под DOS в разрешени 640x480 и выше через Linear Frame Buffer (VBE 2.0 +) ? Так вот Frame Buffer вполне может располагаться на подобных адреса, если не верите, посмотрите "Свойства системы"->"Диспетчер устройств"->"Видеоадаптеры"->"Свойства"->"Ресурсы". А также можно посмотреть ресурсы устройства "системная плата" (вроде бы нужен её номер), там адреса будут именно такими.


ММ>Неа

ММ>Речь идет о физической (!!!!!) памяти. А эти адреса — виртуальные.

Отнюдь. Эти адреса, как раз физические.
Кто Вам сказал, что все физические адреса относятся к RAM? Этот "кто" Вас обманул...
Re[8]: Чтение данных из физической ячейки памяти
От: SPavel Украина  
Дата: 17.01.03 14:09
Оценка:
Здравствуйте, Михаил Челноков, Вы писали:

ММ>>Неа

ММ>>Речь идет о физической (!!!!!) памяти. А эти адреса — виртуальные.

МЧ>Отнюдь. Эти адреса, как раз физические.

МЧ>Кто Вам сказал, что все физические адреса относятся к RAM? Этот "кто" Вас обманул...


Хм..... О чём спор, уважаемые? Он беспредметен. При формулировании вопроса было указано — физический адрес. Уточню — по этому адресу хранится серийный номер материнской платы (я думаю, что биоса). И это вероятно ROM.

С уважением, Павел.
Re[4]: Чтение данных из физической ячейки памяти
От: Roman_M rgmroman.narod.ru
Дата: 17.01.03 14:15
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Здравствуйте, vasketsov, Вы писали:


V>>Здравствуйте, Roman_M, Вы писали:


RM>>>есть \device\PhysicalMemory,

V>>Читает именно физическую память, а не ВАП
SP>Хорошо — а как им воспользоваться? В MSDN об этом написано крайне скудно
SP>

SP>The PhysicalMemory property gives the size of the installed RAM in Megabytes

SP>И как я понимаю, это не совсем то, что имелось в виду под "\device\PhysicalMemory"

Да, это что-то другое. Вот ссылка на исходник от Руссиновича.


http://groups.google.com.ru/groups?q=device%5C%5CPhysicalMemory&amp;hl=ru&amp;lr=&amp;ie=UTF-8&amp;oe=UTF-8&amp;selm=378B46B8.E8091D97%40ssti.fr&amp;rnum=4
Re[6]: Чтение данных из физической ячейки памяти
От: Saddam Россия http://saddam.narod.ru
Дата: 17.01.03 14:34
Оценка:
Здравствуйте, VVV, Вы писали:

SP>>С уважением, Павел


VVV>Попробуй этот скрипт (сгенерён с помощью Scriptomatic) запиши скрипт в файл baseboard.vbs и запусти cscript baseboard.vbs или просто даблкликом.


Вот, что он выдал:
Даже не пахнет сериалом
- Вы знаете — жаль, просто по-человечески жаль Памелу Андерсон, которая никогда не сможет сыграть на баяне...
Re[7]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 17.01.03 15:02
Оценка: 21 (1)
Здравствуйте, vasketsov, Вы писали:

V>Вот вы попробуйте из этой секции прочитать по этому адресу, тогда и поговорим.


Попробовал. То, что хотел SPavel, сидит по адресу 0x0FEC71 — он, IMHO, линейную адресацию с сегментной попутал. Но насчет старших адресов ты все равно не прав:

:PEEK d 0xfffFEC00
0x00000000   00000000000000000000000000000000   0
:PEEK d 0xfffFE000
0x72617741   01110010011000010111011101000001   1918990145
:PEEK d 0xfffFEA00
0x00000000   00000000000000000000000000000000   0
:PEEK d 0xfffFEAFF
0x00000000   00000000000000000000000000000000   0
:PEEK d 0xfffFE004
0x6F422064   01101111010000100010000001100100   1866604644
:PEEK d 0xfffFE008
0x6C42746F   01101100010000100111010001101111   1816294511
:PEEK d 0xfffFE00A
0x636F6C42   01100011011011110110110001000010   1668246594
:g
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[7]: Чтение данных из физической ячейки памяти
От: AssAsin  
Дата: 18.01.03 01:24
Оценка: 7 (1)
Здравствуйте, Whisperer, Вы писали:

W>ДрайверА


Как нынче в Win32 с драйверами, я не знаю, но под Windows 3.11 мне приходилось писать виртуальный драйвер (именно VxD: нулевое кольцо, FLAT-модель) для доступа к физической памяти (для работы с шиной VME, адресное пространство которой отображалось в верхние адреса оперативной памяти). По другому никак не выходило, потому что и процессы, и даже виртуальные драйвера оперируют линейными адресами, которые отображаются на физические через механизм виртуальной памяти (постраничная подкачка), которым можно управлять только с уровня VxD. Конкретно я делал следующее:

1. При инициализации своего VxD вызывал функцию, отменяющую пейджинг на нужном мне диапазоне адресов, в результате чего видимые моему драйверу линейные адреса в этом диапазоне совпадали с физическими. Но эти линейные адреса доступны только VxD-драйверам во FLAT-модели, а прикладные программы оперируют каждая своим собственным линейным адресным пространством, ничего общего с FLAT-моделью не имеющим.

2. Поэтому драйвер экспортировал функции Read/WriteMemory(address, data, size), которые вызывались из прикладной программы, и выполняли собственно обращение к физической памяти. Вызов драйвера из программы представлял отдельный геморрой, про который вообще ничего не помню. Сначала, кажись, нужно было получить хэндл драйвера по имени, или что-то в этом духе, ну и т.д.

Видите, как все было просто! Интересно, изменилось ли что в Win32? Думаю, в Win9x — вряд ли.
Re[7]: Чтение данных из физической ячейки памяти
От: AssAsin  
Дата: 18.01.03 01:29
Оценка: 28 (2)
Здравствуйте, Михаил Можаев, Вы писали:

ММ>Речь идет о физической (!!!!!) памяти. А эти адреса — виртуальные.


Шина VME фирмы Industrial Computers (один из главных субподрядчиков американской оборонки) вешает свое адресное пространство чуть ли не в 0x80000000-... Sorry, точно не помню. И перед ее базовым адресом получается приличных размеров дыра. Что не мешает системе нормально работать, непонятно каким чудом.
Re[8]: Дополнение
От: AssAsin  
Дата: 18.01.03 01:34
Оценка:
AA>Шина VME вешает свое адресное пространство чуть ли не в 0x80000000-... Sorry, точно не помню.

Почитав другие посты, добавлю: обращаются к ней как к обычной RAM: чтение, запись. Но эти обращения прозрачным образом передаются портам присоединенных к шине внешних устройств, или даже в адресное пространство другого компьютера, висящего на этой же шине, при этом для оповещения об изменении данных в памяти резервируется IRQ.
Re[8]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 19.01.03 07:15
Оценка:
Здравствуйте, Sergey, Вы писали:

[]

Я не заю, что у Вас за PEEK и что он делает, Вам виднее, но имхо он ВАП ядра читает.

Вот вывод програмки от Руссиновича (PHYSMEM.EXE).

Physmem v1.0: physical memory viewer
By Mark Russinovich
Systems Internals — http://www.sysinternals.com

Enter values in hexadecimal. Enter 'q' to quit.

Address: f000ec71
Bytes: 21
Could not map view of F000EC71 length 21: The parameter is incorrect.

Address: fec71
Bytes: 21
000FE000: 41 77 61 72 64 20 53 6F -66 74 77 61 72 65 49 42 Award SoftwareIB
000FE010: 4D 20 43 4F 4D 50 41 54 -49 42 4C 45 20 34 38 36 M COMPATIBLE 486
000FE020: 20 42 49 4F 53 20 43 4F -50 59 52 49 47 48 54 20 BIOS COPYRIGHT
000FE030: 41 77 61 72 64 20 53 6F -66 74 77 61 72 65 20 49 Award Software I
000FE040: 6E 63 2E 6F 66 74 77 61 -72 65 20 49 6E 63 2E 20 nc.oftware Inc.
000FE050: 41 77 03 0C 04 01 01 6F -66 74 77 E9 11 14 20 43 Aw.....oftwщ.. C
000FE060: 1B 41 77 61 72 64 20 4D -6F 64 75 6C 61 72 20 42 .Award Modular B
000FE070: 49 4F 53 20 76 34 2E 35 -31 50 47 00 DB 32 EC 33 IOS v4.51PG.█2.3
000FE080: EC 35 EC 38 EC 3C EC 41 -EC 47 EC 4E EC 77 61 72 .5.8...A.G.N.war
000FE090: 2C 43 6F 70 79 72 69 67 -68 74 20 28 43 29 20 31 .Copyright .C. 1
000FE0A0: 39 38 34 2D 39 38 2C 20 -41 77 61 72 64 20 53 6F 984.98. Award So
000FE0B0: 66 74 77 61 72 65 2C 20 -49 6E 63 2E 00 74 77 61 ftware. Inc..twa
000FE0C0: 4E 41 53 55 53 20 50 32 -2D 39 39 42 20 41 43 50 NASUS P2.99B ACP
000FE0D0: 49 20 42 49 4F 53 20 52 -65 76 69 73 69 6F 6E 20 I BIOS Revision
000FE0E0: 31 30 31 31 00 42 65 74 -61 20 30 30 38 00 00 00 1011.Beta 008...
000FE0F0: 00 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 00 ................
000FE100: 00 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 31 ...............1
000FE110: 20 49 42 4D 20 49 53 20 -41 20 54 52 41 44 45 4D IBM IS A TRADEM
000FE120: 41 52 4B 20 4F 46 20 49 -4E 54 45 52 4E 41 54 49 ARK OF INTERNATI
000FE130: 4F 4E 41 4C 20 42 55 53 -49 4E 45 53 53 20 4D 41 ONAL BUSINESS MA
000FE140: 43 48 49 4E 45 53 20 43 -4F 52 50 2E 55 8B EC 56 CHINES CORP.UЛ.V
000FE150: 1E C5 76 02 81 3C 0F 05 -74 3E 81 3C 0F 04 74 17 .┼v.Б...t.Б...t.
000FE160: 80 3C F0 74 0A 80 3C F2 -74 05 80 3C F3 75 04 46 ..Ёt...Єt...єu.F
000FE170: 89 76 02 1F 5E 5D CF E9 -32 2C 20 00 00 08 00 00 Йv....╧щ2. .....
000FE180: FF FF 00 00 0F 9B 00 00 -00 00 00 00 00 00 00 00 .....Ы..........
000FE190: 00 00 00 00 00 00 00 00 -33 C0 8E D8 8E C0 8E 16 ........3└.╪.└..

Я вижу данные только BIOS.
Это все — на тестовой ASUS-овской мамке, ОЗУ — 384 мега, ткните носом, где серийный номер ASUS-а?
Васкецов Сергей
http://registry.km.ru
Re[9]: Чтение данных из физической ячейки памяти
От: Михаил Челноков Украина  
Дата: 19.01.03 14:11
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Хм..... О чём спор, уважаемые? Он беспредметен. При формулировании вопроса было указано — физический адрес. Уточню — по этому адресу хранится серийный номер материнской платы (я думаю, что биоса). И это вероятно ROM.


Спора никакого нет, просто там, где ты поскипал, было неверное утверждение одного товарища, к твоему вопросу напрямую не относящееся.

Кстати, у меня по нужному тебе адресу находится строка
02/06/2002-i815E-W83627H-6A69RA1KC-7U

"Серийным номером" материнки это не назовешь. Дата и версия BIOS'а, не более того. Эта же строка выводится внизу экрана при включении питания.
И, IMHO, если какие-нибудь производители и прошивают серийный номер материнки куда-нить, то это жутко непортабельно. Увы...
Re[9]: Чтение данных из физической ячейки памяти
От: Andrew S Россия http://alchemy-lab.com
Дата: 19.01.03 21:12
Оценка: 9 (1)
Ткнуть?? Запросто. Читайте спецификацию DMI и SMBIOS

Там ясно сказано, как найти таблицы DMI и что где и как расположено.

таблица DMI ищется в 128 кб начиная с физического адреса 0xE0000. Ищется строка _SMBIOS_, просматриваются блоки по 16 байт, т.к. эта строка проалигнена на 16 байт. Собственно, далее идет entry-point DMI со всеми делами — указателем на таблицы и т.п. Это все разбирается, в результате получаем кучу системной инфы. И серийный номер Shassis в том числе.


V>Я вижу данные только BIOS.

V>Это все — на тестовой ASUS-овской мамке, ОЗУ — 384 мега, ткните носом, где серийный номер ASUS-а?
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[10]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 04:29
Оценка:
Здравствуйте, Andrew S, Вы писали:

AS>Ткнуть?? Запросто.

Я имел в виду на предоставленном мной листинге, а не в теории.
Васкецов Сергей
http://registry.km.ru
Re[11]: Чтение данных из физической ячейки памяти
От: Andrew S Россия http://alchemy-lab.com
Дата: 20.01.03 04:36
Оценка:
Ну так предоставьте листинг 128 кб начиная с адреса 0xe0000 — тогда ткнем не в теории
(на самом деле DMI почти всегда находится выше 0xf000, но не все же не всегда)
V> Я имел в виду на предоставленном мной листинге, а не в теории.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[12]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 04:44
Оценка:
Здравствуйте, Andrew S, Вы писали:

[]
И не собираюсь
Я просто опровергал посты, в которых это утверждалось для адресов 0xF000EC71 и 0xFEC71, первый вообще не прочитался (не знаю кто как там это пробовал делать, якобы удачно, некоторые даже под досом ), второй я вывел тут.
Васкецов Сергей
http://registry.km.ru
Re[13]: Чтение данных из физической ячейки памяти
От: Andrew S Россия http://alchemy-lab.com
Дата: 20.01.03 04:52
Оценка:
V>И не собираюсь
И праально.

V>Я просто опровергал посты, в которых это утверждалось для адресов 0xF000EC71 и 0xFEC71, первый вообще не прочитался (не знаю кто как там это пробовал делать, якобы удачно, некоторые даже под досом ), второй я вывел тут.

Прикол в том, что есть несколько материнских плат (IBM), в которых область DMI таблиц лежит как раз выше 0xF???????. Что это — ошибка в entry point биоса или еще что — для меня осталось загадкой. Я просто ограничил область положения DMI первыми 64 кб выше первого мегабайта. Но тем не менее — факт, что некоторые материнские платы отдают похожие адреса.
В данном случае, конечно, автор постинга скорее всего просто ошибся в адресе.
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[9]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 20.01.03 08:04
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Я не заю, что у Вас за PEEK и что он делает, Вам виднее, но имхо он ВАП ядра читает.


Я приводил кусок лога SoftIce'а. Если верить документации, команда PEEK читает именно по физическим адресам. В той же доке читаем "PEEK is useful for reading memory-mapped I/O registers.", которые, IMHO, и наблючаются на моем компьютере по адресам 0xfffFE000 и т.д.

V>Вот вывод програмки от Руссиновича (PHYSMEM.EXE).


V>Address: f000ec71

V>Bytes: 21
V>Could not map view of F000EC71 length 21: The parameter is incorrect.

Заметь, это PHYSMEM прочитать ничего по этому адресу не может, а ты утверждаешь, что оттуда вообще никак читать невозможно. Это немного разные вещи. Я могу придумать десяток причин, почему \Device\PhysicalMemory предоставляет доступ не по всем физическим адресам.

V>Address: fec71

V>Bytes: 21
V>000FE000: 41 77 61 72 64 20 53 6F -66 74 77 61 72 65 49 42 Award SoftwareIB

V>Я вижу данные только BIOS.

V>Это все — на тестовой ASUS-овской мамке, ОЗУ — 384 мега, ткните носом, где серийный номер ASUS-а?

И где в там адрес F000EC71 или 000FEC71? Дамп ты почему-то на 000FE19F закончил.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[10]: Чтение данных из физической ячейки памяти
От: SPavel Украина  
Дата: 20.01.03 08:42
Оценка:
Здравствуйте, Михаил Челноков, Вы писали:
МЧ>
МЧ>02/06/2002-i815E-W83627H-6A69RA1KC-7U
МЧ>

МЧ>"Серийным номером" материнки это не назовешь. Дата и версия BIOS'а, не более того. Эта же строка выводится внизу экрана при включении питания.
МЧ>И, IMHO, если какие-нибудь производители и прошивают серийный номер материнки куда-нить, то это жутко непортабельно. Увы...

ВОТ! Именно эта информация мне и нужна! Именно эта! Тут есть дата, модель, и серийный номер. И действительно — это инфа биоса.
Скажите, пожалуйста, каким образом Вы её получили?

С уважением, Павел
Re[10]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 09:11
Оценка:
Здравствуйте, Sergey, Вы писали:

[]

При загрузке BIOS не может быть спроецирован на физическую память за 0xF0000000, потому что неизвестно, поддерживает ли этот регион система. Однако, он проецируется на нижние адреса (при загрузке системы данные из BIOS, в том числе, по дискам, шинам и устройствам и выделенным для них пулам, получает ntdetect.com, которая 16-разрядная, реального режима, даже если Windows устанавливает свои порты, то не факт, что устройства будут работать, ибо они могут быть и без Plug'n'play и драйвера у них могут быть без P'n'P, так что изменение номеров портов может быть невозможным), потом диспетчер памяти организует доступ из ВАП ядра по адресу 0xFxxxxxxx так, чтобы адресовались именно биосовские страницы. Так что физически памяти 0xFxxxxxxx может не быть (у меня, например, нет), а если она и есть — уж точно там никаких биосов и устройств (если только их разработчики не совсем еще кретины) быть не может. А та память, что выделяется — из ВАП ядра, в том числе и из подкачиваемого пула, физические адреса — только нижние, ибо верхние могут не поддерживаться самими устройствами. Как пример — данные о векторах прерываний, в ВАП ядра они за 0x80000000 идут, а физически — наверное сами знаете где.

S>И где в там адрес F000EC71 или 000FEC71? Дамп ты почему-то на 000FE19F закончил.

Согласен, проглядел, вот оно:
-- more -- ('q' to abort)
000FEB60: 11 05 83 4E 16 01 E8 35 -E6 5D 07 1F 5F 5E 5A 59 ...N..ш5ц..._.ZY
000FEB70: 5B 58 CF 8A 46 0F A8 FE -75 D2 F6 06 27 00 80 74 .X¦.F.и.uTЎ....t
000FEB80: DD 34 01 04 F4 E8 24 E6 -75 CE E8 D3 F9 EB D7 80 ¦4..Їш.цu+шL•ы+.
000FEB90: 26 26 00 F8 B0 FF E8 13 -E6 75 BD E8 C2 F9 75 C6 ...°..ш.цu-шT•u¦
000FEBA0: E8 FC F9 74 B3 88 46 0E -E8 F4 F9 74 AB 88 46 0F ш.•t¦.F.шЇ•tл.F.
000FEBB0: EB 90 80 7E 0F 06 77 9A -B0 F3 E8 EF E5 75 99 E8 ы.....wЪ.єшяхuЩш
000FEBC0: 9E F9 75 A2 8D 36 DD EB -32 E4 8A 46 0F 03 F0 2E Ю•uвН6¦ы2ф.F..Ё.
000FEBD0: AC E8 D8 E5 74 02 EB 80 -E8 85 F9 EB 89 0A 14 28 мш+хt.ы.шЕ•ыЙ...
000FEBE0: 3C 50 64 C8 80 7E 0F 03 -76 03 E9 65 FF B0 E8 E8 .PdL....v.щe..шш
000FEBF0: BA E5 74 03 E9 61 FF E8 -66 F9 74 03 E9 67 FF 8A ¦хt.щa.шf•t.щg..
000FEC00: 46 0F E8 A7 E5 74 03 E9 -4E FF E8 53 F9 E9 56 FF F.шзхt.щN.шS•щV.
000FEC10: EA 00 80 08 00 65 20 49 -6E 63 2E 20 41 77 61 72 ъ....e Inc. Awar
000FEC20: 64 20 53 6F 66 74 77 61 -72 65 20 49 6E 63 2E 20 d Software Inc.
000FEC30: C3 CB 06 06 07 06 04 02 -06 07 04 02 06 04 02 05 +...............
000FEC40: 03 06 07 04 02 05 03 06 -04 02 00 05 03 01 06 07 ................
000FEC50: 04 02 00 05 03 01 2E 20 -41 E9 34 C0 64 20 53 6F ....... Aщ4Ld So
000FEC60: AA 1E 14 61 72 65 20 49 -6E 63 2E 20 41 77 61 72 ...are Inc. Awar
000FEC70: 1A 31 30 2F 32 31 2F 39 -39 2D 69 34 34 30 5A 58 .10.21.99.i440ZX
000FEC80: 2D 50 32 2D 39 39 42 2D -30 30 00 30 30 00 30 30 .P2.99B.00.00.00
000FEC90: 30 30 43 2D 30 30 00 E8 -06 00 75 03 E9 27 F6 CF 00C.00.ш..u.щ.Ў¦
000FECA0: 1E 50 B8 40 00 8E D8 F7 -06 15 00 08 00 58 1F C3 .P¬...+ў.....X.+
000FECB0: B0 F2 E8 F7 E4 74 03 E9 -9E FE E8 A3 F8 74 03 E9 .Єшўфt.щЮ.шг°t.щ
000FECC0: A4 FE E8 DA F8 74 06 88 -46 0F E9 75 FE E9 88 FE д.ш-°t..F.щu.щ..
000FECD0: 94 72 01 AA 4D 1A 4D 1A -AA 74 77 61 72 65 20 49 Фr..M.M..tware I
000FECE0: 50 32 2D 39 39 42 00 72 -64 20 20 20 00 00 77 61 P2.99B.rd ..wa
000FECF0: E9 A9 CD 50 B0 20 E6 A0 -58 CD 0A CF 64 20 53 6F щй=P. цаX=.¦d So

Все равно не вижу .
Васкецов Сергей
http://registry.km.ru
Re[11]: Чтение данных из физической ячейки памяти
От: SPavel Украина  
Дата: 20.01.03 09:56
Оценка:
Здравствуйте, vasketsov, Вы писали:
Вот как я написал программу под Дос:
void Asm(char * num)
{
  char     mb[40];
  int     i = 0;
  char    nm;
  asm  push ax
  asm  push ds
  asm  push si
  asm  push cx

  asm      mov    ax,             0xF000
  asm      mov     ds,             ax
  asm      mov     si,             0xEC71
  asm   mov    cx,             40
  asm   cld
Repiat:;
  asm   lodsb
  asm      mov    [nm],            al
  mb[i] = nm;
  ++i;
  asm   or    al,            al
  asm    jne    Repiat

  Exit:;
  asm  pop cx
  asm  pop si
  asm  pop ds
  asm  pop ax
  strcpy(num, mb);
}


И прога вытягивает нужную и правильную инфу (работает под Досом)
Здесь видно, что адрес имеет значение F000 EC71.

Однако в программе Русиновича в качестве адреса вводим fec71, byte: 21. Программа выдаёт длинный листинг, в котором и просвечивается искомый серийный номер. Привожу фрагмент:

000FEC50: 04 02 00 05 03 01 2E 20 -41 E9 E4 9E 64 20 53 6F ....... AщфЮd So
000FEC60: 00 00 00 00 00 00 00 00 -14 63 2E 20 41 77 61 72 .........c. Awar
000FEC70: 26 30 33 2F 30 31 2F 31 -39 39 39 2D 69 34 34 30 .03.01.1999.i440
000FEC80: 4C 58 2D 53 4D 43 36 30 -32 2D 32 41 36 39 4A 58 LX.SMC602.2A69JX
000FEC90: 33 42 43 2D 30 30 00 E8 -06 00 75 03 E9 27 F6 CF 3BC.00.ш..u.щ.Ў?

Тут серийным номером является 2A69JX3BC.
Пределать прогу под свои нужды не представляется сложным. Однако physmem НЕ работает под Win9x! Таким образом, для меня проблема оказалась решённой только наполовину.
Re[11]: Чтение данных из физической ячейки памяти
От: Hacker_Delphi Россия  
Дата: 20.01.03 09:56
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, Sergey, Вы писали:


V>[]


V>При загрузке BIOS не может быть спроецирован на физическую память за 0xF0000000, потому что неизвестно, поддерживает ли этот регион система.

А вот тут ты не прав... после пуска процессора старше чем 486 (про 386 — не помню, но вроде бы так же) процессор находится в R режиме, при этом:
"... Отметим, что невидемые части регистров CS и DS инициализированы на значения, которые допускают начать работу, хотя сегменты еще не определены. Базовый адрес сегмента кода установлен на 64К ниже верха физического адресного пространства..." (c) "Микропроцессор i486. Архитектура и программирование"
Enigma-Enigma 'Principles of Lust'
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Re[11]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 20.01.03 10:15
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>При загрузке BIOS не может быть спроецирован на физическую память за 0xF0000000, потому что неизвестно, поддерживает ли этот регион система.


Не совсем понял это утверждение. Какая загрузка имеется в виду? Если под загрузкой понимается начальное исполнение кода BIOS, aka "Cold boot", то в этот момент BIOS'у как раз очень хорошо известно, на какой железяке он работает и что там поддерживается. Соответственно, на некоторых железяках он вполне может оказаться где угодно.
Кроме того, я не утверждал, что BIOS обязательно сидит по адресам выше 0xF0000000 — IMHO, там живет memory-mapped I/O.

V>Однако, он проецируется на нижние адреса (при загрузке системы данные из BIOS, в том числе, по дискам, шинам и устройствам и выделенным для них пулам, получает ntdetect.com, которая 16-разрядная, реального режима, даже если Windows устанавливает свои порты, то не факт, что устройства будут работать, ибо они могут быть и без Plug'n'play и драйвера у них могут быть без P'n'P, так что изменение номеров портов может быть невозможным), потом диспетчер памяти организует доступ из ВАП ядра по адресу 0xFxxxxxxx так, чтобы адресовались именно биосовские страницы.


При чем здесь вообще порты и драйвера устройств?

V>Так что физически памяти 0xFxxxxxxx может не быть (у меня, например, нет), а если она и есть — уж точно там никаких биосов и устройств (если только их разработчики не совсем еще кретины) быть не может.


Может быть, а может не быть. Не вижу связи с предположительным кретинизмом разработчиков устройств. Ладно, берем доку на Savage4, читаем:

MMIO enabled is the power-on default, allowing PCI software immediate access to all registers and the ability to relocate the
address space. There are two MMIO address mappings, as determined by the state of CRB0_7. By default, CRB0_7 = 1, which
selects Mapping 0. The definitions of Mapping 0 and Mapping 1 change from Rev. A silicon to Rev. B silicon, as explained below.
For processors that support it, the address ranges with bases specified by PCI14, 18, 1C, 20 and 24 should be marked as write
combining.
... поскипано...
PCI Base Address 0 (PCI10) — Mapping 0 and Mapping 1
For Rev. A silicon, bits 31-24 of the base address are programmable, resulting in a 16-MByte address space being claimed. For
Rev. B silicon, bits 31-19 are programmable, resulting in a 512-KByte address space being claimed. The default base address is
7000 0000H. Write combining cannot be used for this address range.
... поскипано...
PCI Base Address 1 (PCI14) — Mapping 0) (Rev. A or Rev B)
Bits 31-27 of the base address are programmable, resulting in a 128-MByte address space being claimed. The default base
address is 6000 0008H (prefetching allowed).


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

V>А та память, что выделяется — из ВАП ядра, в том числе и из подкачиваемого пула, физические адреса — только нижние, ибо верхние могут не поддерживаться самими устройствами. Как пример — данные о векторах прерываний, в ВАП ядра они за 0x80000000 идут, а физически — наверное сами знаете где.


Причем здесь вообще память из ВАП ядра, когда речь идет о том, что где расположено на "железном" уровне?

S>>И где в там адрес F000EC71 или 000FEC71? Дамп ты почему-то на 000FE19F закончил.

V>Согласен, проглядел, вот оно:
V>Все равно не вижу .

IMHO, ему нужно было вот это: 10.21.99.i440ZX.P2.99B.00.00

PS:
Доку на савадж могу выслать, если на слово не веришь.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[12]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 20.01.03 10:26
Оценка:
Здравствуйте, SPavel, Вы писали:

SP>Вот как я написал программу под Дос:

SP>[ccode]
SP> asm mov ax, 0xF000
SP> asm mov ds, ax
SP> asm mov si, 0xEC71
SP>И прога вытягивает нужную и правильную инфу (работает под Досом)
SP>Здесь видно, что адрес имеет значение F000 EC71.

Здесь, однако, видно, что адрес имеет значение 000FEC71
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[12]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 10:47
Оценка:
Здравствуйте, Hacker_Delphi, Вы писали:

H_D>процессор находится в R режиме

1) Кто его туда переводит? Если он сам, не противоречит ли это возможности запуска Dos 3 на 4-ках?
2) А где это верх физического адресного пространства в данном случае?
Васкецов Сергей
http://registry.km.ru
Re[12]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 11:25
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Не совсем понял это утверждение. Какая загрузка имеется в виду? Если под загрузкой понимается начальное исполнение кода BIOS, aka "Cold boot", то в этот момент BIOS'у как раз очень хорошо известно, на какой железяке он работает

Во-первых, нет, ибо существуют PnP (и вообще факты игнорирования настроек BIOS в виндах) и удаленная загрузка.
Во-вторых, имелась в виду операционная система.

[]
S>При чем здесь вообще порты и драйвера устройств?
А как по твоему общение с устройством происходит? Мне известен только один физический способ, запись в порт воода/вывода и чтение оттуда. То, что над этим может быть вроде бы явная запись в память, разруливается никак не самим устройством.

S>Может быть, а может не быть.

Об этом и речь. Если туда что-то мапится — это его проблемы и проблемы использования памяти, зачем дублировать данные физически снизу и тут — вопрос еще тот.

S>Причем здесь вообще память из ВАП ядра, когда речь идет о том, что где расположено на "железном" уровне?

Еще раз. Предположим, есть не-PnP-устройство и для него установлен не-PnP-драйвер. Такое устройство не поддерживает изменение базового адреса проекции своей памяти на физическом уровне (сказали SoundBlaster-у, что он на 0x220 живет — там и будет жить до перезагрузки). Такое устройство не может иметь собственной замапленной физической памяти в высоких адресах (ибо тогда это устройство, скажем, с минимальными требованиями типа 486+WinNT, об этом и была речь по разработчиков, кстати, Savage — это круто? ), потому что неясно, как с ним общаться со старой машины, потому для него обязательно должно быть выделено пространство снизу (собственно, порт — это оно и есть), а если так, зачем его выделять сверху?

По поводу \Device\PhysicalMemory. Устроена она ОЧЕНЬ просто, там именно читается физическая память, безо всяких проверок. И если при чтении оттуда выдается ошибка — именно физической памяти там и нет (даже если указанному месту не соответствует выделенный фрагмент виртуальной памяти, все равно прочитать оттуда можно). Так что речь нео 10 причинах, почему там высокие адреса не читаются, а об одной, о ВАП ядра, о которой здесь упорно ведется речь.

S>IMHO, ему нужно было вот это: 10.21.99.i440ZX.P2.99B.00.00

Что-то здесь слабо улавливается серийный номер, вижу только BIOS revision, чипсет и торговое наименование, ничего уникального.

S>PS:

S> Доку на савадж могу выслать, если на слово не веришь.
Спасибо, но все равно не видел ни одной документации без ошибок, а надо будет — сам найду.
Васкецов Сергей
http://registry.km.ru
Re[13]: Чтение данных из физической ячейки памяти
От: Hacker_Delphi Россия  
Дата: 20.01.03 11:26
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, Hacker_Delphi, Вы писали:


H_D>>процессор находится в R режиме

V>1) Кто его туда переводит? Если он сам, не противоречит ли это возможности запуска Dos 3 на 4-ках?
нет. дело в том, что он как бы в реальном режиме работает... просто в Shadow регистре лежит не 0x000F0000 (CS = 0xF000), 0xFFFF0000. после первого же дальнего перехода все восстанавливается... процессор проваливается в честный R-mode....
V>2) А где это верх физического адресного пространства в данном случае?
конкретно адрес (физический!!!) 0xFFFFFFF0.
это — стартовый адрес для BIOS.
Enigma — I love You... I'll Kill You (The Cross of Changes)
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Re[14]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 11:36
Оценка:
Здравствуйте, Hacker_Delphi, Вы писали:

[]

Так процессор же вроде сам эти 0xFFFF0000 подправит, или ругнется (собственно, так вроде бы сообщается о невыделенной физической памяти). В том смысле, что даже под досом нечто вроде mov 0xFFFF0000, 0 не приводит к записи в физическую память по адресу 0xFFFF0000. Потому о том, что 0xFFFF0000 — это именно физическая память (то есть, после трансляции адресов), я бы говорить не стал.
Васкецов Сергей
http://registry.km.ru
Re[13]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 20.01.03 12:48
Оценка:
Здравствуйте, vasketsov, Вы писали:

S>>Не совсем понял это утверждение. Какая загрузка имеется в виду? Если под загрузкой понимается начальное исполнение кода BIOS, aka "Cold boot", то в этот момент BIOS'у как раз очень хорошо известно, на какой железяке он работает

V>Во-первых, нет, ибо существуют PnP (и вообще факты игнорирования настроек BIOS в виндах) и удаленная загрузка.

Какие то настройки BIOS'а игнорируются, какие-то нет. Например, поддержка ACPI не игнорируется, а с дисками винда предпочитает работать напрямую. И что это доказывает? Да ничего, просто общие слова не по теме. BIOS знает, что за чипсет стоит на материнской плате (в том смысле, что умеет разрешать/запрещать запись в те страницы памяти, где физически находится flash rom и управляет тем, ROM или RAM виден по этим адресам) — иначе он просто не мог бы работать. Например, AWARD'овский BIOS сидит в ROM в запакованном виде, при старте машины распаковывается в ОЗУ, передает управление распакованному образу, говорит чипсету "сделай так, чтоб по адресам E0000 — FFFFF был виден RAM, а не ROM", потом "разреши запись по адресам по адресам E0000 — FFFFF", потом переписыват себя (распакованного) по этим адресам, и наконец "запрети запись по адресам по адресам E0000 — FFFFF". Для этого ему нужны достаточно интимные сведения о чипсете. И ежели какой чипсет позволяет физически отобразить область E0000 — FFFFF на старшие адреса, не вижу причин, по которым бы BIOS не мог бы этого сделать.
Помимо этого, BIOS в процессе загрузки несколько раз переключается в защищенный режим и обратно — но это так, к слову.

V>Во-вторых, имелась в виду операционная система.


А при чем тут загрузка операционной системы?

S>>При чем здесь вообще порты и драйвера устройств?

V>А как по твоему общение с устройством происходит? Мне известен только один физический способ, запись в порт воода/вывода и чтение оттуда.

Ну тогда давай поговорим про то, как это устроено на аппаратном уровне. При записи/чтении из памяти сигнал M/IO# выставляется в 1, при обращении к портам — в 0. Грубо говоря, это и есть вся разница между портами и памятью, если оставить в стороне кэширование и буферизацию.

V>То, что над этим может быть вроде бы явная запись в память, разруливается никак не самим устройством.


Не над этим, а вместо этого или параллельно этому. И если часть портов устройства доступна, когда M/IO# выставлен в 1, никакая операционка к этому отношения не имеет.

S>>Может быть, а может не быть.

V>Об этом и речь. Если туда что-то мапится — это его проблемы и проблемы использования памяти, зачем дублировать данные физически снизу и тут — вопрос еще тот.

Дублировать — для удобства и скорости. Да и памяти в пределах первого мегабайта маловато. Тот же савадж 4 все регистры, доступные через порты (кроме 3С3) мапит на память. Ну и фреймбуфер тоже мапит, само собой. Вот подумай, удобно ли к 32 Мб памяти (или даже к 4 Мб) иметь доступ только через окно в пределах первого мегабайта? А доступ к фиговой туче регистров 2D/3D ускорителя иметь в EGA-стиле? Да и вообще лезть к регистрам устройства через порты?

S>>Причем здесь вообще память из ВАП ядра, когда речь идет о том, что где расположено на "железном" уровне?

V>Еще раз. Предположим, есть не-PnP-устройство и для него установлен не-PnP-драйвер.

Ты видел хоть одно PCI'ное не-PnP-устройство? Я говорил именно про PCI маппинг портов на память, ISA'шные девайсы, AFAIK, этим не балуются.

V>Такое устройство не поддерживает изменение базового адреса проекции своей памяти на физическом уровне (сказали SoundBlaster-у, что он на 0x220 живет — там и будет жить до перезагрузки). Такое устройство не может иметь собственной замапленной физической памяти в высоких адресах (ибо тогда это устройство, скажем, с минимальными требованиями типа 486+WinNT, об этом и была речь по разработчиков, кстати, Savage — это круто? ), потому что неясно, как с ним общаться со старой машины, потому для него обязательно должно быть выделено пространство снизу (собственно, порт — это оно и есть), а если так, зачем его выделять сверху?


Порты снизу оставлены для совместимости (с VGA, в данном случае), 64К адресного пространства портов для новых устройств — мало. А если учесть, что на AT вообще только 10 бит адресной шины использовались... Вспомни, как EGA/VGA через порты программируются — это ж тихий ужас. А насчет того, что "Savage — это круто?" — так просто других даташитов подходящих под рукой не обнаружилось.
Если у тебя есть на NV25 — поделись, а?

V>По поводу \Device\PhysicalMemory. Устроена она ОЧЕНЬ просто, там именно читается физическая память, безо всяких проверок. И если при чтении оттуда выдается ошибка — именно физической памяти там и нет (даже если указанному месту не соответствует выделенный фрагмент виртуальной памяти, все равно прочитать оттуда можно). Так что речь нео 10 причинах, почему там высокие адреса не читаются, а об одной, о ВАП ядра, о которой здесь упорно ведется речь.


Если нет проверок, кто вернет ошибку? И что значит, нет физической памяти? Сколько себя помню, если прочитать что-нибудь по адресу, по которому нет ни физической памяти, ни порта ввода, вернется FF (шина к питанию резисторами подтянута). Раз нет проверок, значит, там происходит банальный трап по выходу за границы сегмента. Та же проверка, вид в профиль.

S>>IMHO, ему нужно было вот это: 10.21.99.i440ZX.P2.99B.00.00

V>Что-то здесь слабо улавливается серийный номер, вижу только BIOS revision, чипсет и торговое наименование, ничего уникального.

Это уже к SPavel, он говорил именно про эти данные. Он это называет серийным номером.

S>>PS:

S>> Доку на савадж могу выслать, если на слово не веришь.
V>Спасибо, но все равно не видел ни одной документации без ошибок, а надо будет — сам найду.

Докам ты не веришь, SoftIce'у не веришь. Веришь только \Device\PhysicalMemory. Тогда разговор продолжать смысла нет.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[11]: Чтение данных из физической ячейки памяти
От: Михаил Челноков Украина  
Дата: 20.01.03 13:10
Оценка: 8 (1)
Здравствуйте, SPavel, Вы писали:

МЧ>>
МЧ>>02/06/2002-i815E-W83627H-6A69RA1KC-7U
МЧ>>

МЧ>>"Серийным номером" материнки это не назовешь. Дата и версия BIOS'а, не более того. Эта же строка выводится внизу экрана при включении питания.
МЧ>>И, IMHO, если какие-нибудь производители и прошивают серийный номер материнки куда-нить, то это жутко непортабельно. Увы...

SP>ВОТ! Именно эта информация мне и нужна! Именно эта! Тут есть дата, модель, и серийный номер. И действительно — это инфа биоса.

SP>Скажите, пожалуйста, каким образом Вы её получили?

Нет тут никакого серийного номера. Это просто дата и версия прошивки BIOS'а.
А получил я ее очень просто — по упоминавшемуся тут уже адресу 0xFEC71. Заметь — не 0xF000EC71, а 0xFEC71. Почему-то к 0xF000EC71 доступа не было дано. Можешь считать, что BIOS физически проецируется в оба этих места, но доступно из-под Windows NT только 0xFEC71.

Есть книга Коберниченко "Недокументированные возможности Windows NT". Там в 5-й главе показано, как из user level получить доступ на чтение к физической памяти (через объект ядра \Device\PhysicalMemory). Используются недокументированные возможности — функции ntdll.dll. Точнее, функции документированы, но только для kernel level. Использование их (точнее, их user level отражений) не документировано.
Итак, находишь примеры к этой книге. Берешь файл chapter5\phystest.c и меняешь там
LARGE_INTEGER offset={0,0};

на
LARGE_INTEGER offset={0x0F0000,0};

И там, где у Коберниченко printf'ы векторов прерываний (и прочей информации из первых 64K физической памяти), можешь смело использовать указатель
((const BYTE*)base)+0xEC71

Должно работать на всех NT-системах (3.51, 4, 2000, XP). У меня работает под WinXP Home Edition.
Удачи!..

По поводу Win9X можно посоветовать DOS-программу (которой система обязана давать доступ к 0xFEC71). Возможно также, что и у обычных Win32-приложений под Win9X по этому адресу находится то же самое. Не знаю. Уже 3 года не видел 9X...
Re[12]: Чтение данных из физической ячейки памяти
От: Andrew S Россия http://alchemy-lab.com
Дата: 20.01.03 13:48
Оценка:
SP>И прога вытягивает нужную и правильную инфу (работает под Досом)
SP>Здесь видно, что адрес имеет значение F000 EC71.

Здесь адрес не 0xF000EC71. А 0xF000 << 4 + EC71. Что дает нам FEC71 физического адреса. Двойка вам за младшие классы информатики, товарищ
http://www.rusyaz.ru/pr — стараемся писАть по-русски
Re[14]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 13:58
Оценка:
Здравствуйте, Sergey, Вы писали:

S>И ежели какой чипсет позволяет физически отобразить область E0000 — FFFFF на старшие адреса, не вижу причин, по которым бы BIOS не мог бы этого сделать.

А мне не видно причин, зачем это делать, это замечательно реализуется подсистемой управления памятью.

S>А при чем тут загрузка операционной системы?

А все опреацонные системы достают до 0xFxxxxxxx?

S>И если часть портов устройства доступна, когда M/IO# выставлен в 1, никакая операционка к этому отношения не имеет.

Как это? Если процессор подерживает трансляцию адресов (x86), то система региструет обработчики и обрабатывает его прерывания и реагирует соответствующим образом (по крайней мере NT). Регистрирует вектора именно операционная система (описание как это делается и как по этому получить текущую информацию, есть в "Inside Windows 2000"). Вот порты как раз — физическая память, тут я не спорю, а выделяемая память проецируется на ВАП ядра, тот же буфер видео.

S>Дублировать — для удобства и скорости. Да и памяти в пределах первого мегабайта маловато. Тот же савадж 4 все регистры, доступные через порты (кроме 3С3) мапит на память.

Ага, только виртуальную.

S>Вот подумай, удобно ли к 32 Мб памяти (или даже к 4 Мб) иметь доступ только через окно в пределах первого мегабайта?

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

S>Ты видел хоть одно PCI'ное не-PnP-устройство?

Ага, у меня как раз такой "саундбластер" был, пока я его Военной кафедре не подарил. Кроме того, достаточно не-PnP драйвера, а их достаточно (NT старые же работали как-то).

S>Если у тебя есть на NV25 — поделись, а?

Не, этого нету.

S>SoftIce'у не веришь.

Отнюдь. Я попробовал так получить память по двум базовым адресам в ВАП ядра, по которым загружены драйвера. Представь себе, первые 2 буквы в обоих случаях — MZ.
Васкецов Сергей
http://registry.km.ru
Re[15]: Чтение данных из физической ячейки памяти
От: Roman_M rgmroman.narod.ru
Дата: 20.01.03 14:28
Оценка:
Здравствуйте, vasketsov, Вы писали:


S>>Вот подумай, удобно ли к 32 Мб памяти (или даже к 4 Мб) иметь доступ только через окно в пределах первого мегабайта?

V>А где я это утверждал? Имхо, потому так и делается, что за организацию ВП отвечает операционная система, а конкретный драйвер для нее работает не в обход трансляции адресов на процессоре.

Так все же, где находится frame buffer ? Отнюдь не только окно 0A0000h в 1 мегабайте. Его физический адрес есть в свойствах видеоадаптера. У меня на ATI SoftIce работает в окне, fb находится по адресу 0F6000000h, и если я делаю в SoftIce "poked f6000100 00ffffff" на экране появляется белая точка. Разрешение 1024x768 (32 bit). Причем тут вообще может быть какой-либо ВАП ?
Re[16]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 14:35
Оценка:
Здравствуйте, Roman_M, Вы писали:

RM>Причем тут вообще может быть какой-либо ВАП ?

А при чем здесь физическая память? Этот адрес все-таки проходит еще трансляцию. Куда он реально мапится — мне неведомо.
Васкецов Сергей
http://registry.km.ru
Re[15]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 20.01.03 15:08
Оценка:
Здравствуйте, vasketsov, Вы писали:

S>>И ежели какой чипсет позволяет физически отобразить область E0000 — FFFFF на старшие адреса, не вижу причин, по которым бы BIOS не мог бы этого сделать.

V>А мне не видно причин, зачем это делать, это замечательно реализуется подсистемой управления памятью.

Например, затем, чтобы не занимать драгоценное адресное пространство в пределах первого мегабайта — там всякие legacy железяки любят свои буфера держать. Вот, например, есть у нас BIOS размером 256К, который желает, чтоб его код был доступен юзерам. И что теперь, ему занимать не только E0000-FFFFF, но и C0000-DFFFF? А благодарные юзеры со старинными NE2000-compatible сетевухами идут лесом? А не проще те 128К биоса, которые отвечают за legacy, оставить в E0000-FFFFF, а полные 256К отобразить куда нибудь, куда Макар телят не гонял, и не иметь геморроя ни с совместимостью со старыми железками, ни со старыми ОС, которые такой подлянки, как занятие адресов C0000-DFFFF от системного биоса никак не ожидают?

S>>А при чем тут загрузка операционной системы?

V>А все опреацонные системы достают до 0xFxxxxxxx?

А какая разница? Если операционка не достает до 0xFxxxxxxx, значит, пусть работает со старыми сервисами из первого мегабайта, про новые она все равно не знает.

S>>И если часть портов устройства доступна, когда M/IO# выставлен в 1, никакая операционка к этому отношения не имеет.

V>Как это? Если процессор подерживает трансляцию адресов (x86), то система региструет обработчики и обрабатывает его прерывания и реагирует соответствующим образом (по крайней мере NT). Регистрирует вектора именно операционная система (описание как это делается и как по этому получить текущую информацию, есть в "Inside Windows 2000").

При чем здесь прерывания? M/IO# — ножка процессора, на которую выдается 0 в результате выполнения команд in/out, и все. А в mov'ах всяких туда единичка выставляется. А вектора прерываний для legacy железа еще до операционки биос устанавливает, в том числе для защищенного режима (IMHO, это для всяких DOS4GW). Операционка их, конечно, меняет, если умеет.

V>Вот порты как раз — физическая память, тут я не спорю, а выделяемая память проецируется на ВАП ядра, тот же буфер видео.


Чтоб буфер видео (и регистры) куда-то спроецировать, сначала надо, чтоб их на шине видно было.
А порты вообще не память, они читаются, если сигнал M/IO# в ноле. Память читается, если на M/IO# единица.

S>>Дублировать — для удобства и скорости. Да и памяти в пределах первого мегабайта маловато. Тот же савадж 4 все регистры, доступные через порты (кроме 3С3) мапит на память.

V>Ага, только виртуальную.

На виртуальную — уже потом. Я тебе про совершенно элементарную вещь говорю — если в компьютере стоит этот Savage 4, инициализированный по дефолту, и если процессор выдал на шину (в команде чтения памяти) адрес 0x700003C4, то прочитается инедксный регистр секвенсора, тот, который доступен при чтении из порта 3C4. А если я этому саваджу запишу нолик в бит 0 регистра PCI04, то нихрена по адресу 0x700003C4 читаться не будет. Вернее, читаться будет всегда -1, чтоб этом регистре секвенсера не лежало. А вот если запишу в регистр PCI10 не дефолтный 0x70000000, а, скажем, 0x8000000, то читаться индексный регистр секвенсера будет по физическому адресу 0x800003C4. А вот какой физический адрес процессор на шину выставит, если в программе написать mov eax, 0x700003C4, уже от организации ВП зависит.

S>>Вот подумай, удобно ли к 32 Мб памяти (или даже к 4 Мб) иметь доступ только через окно в пределах первого мегабайта?

V>А где я это утверждал? Имхо, потому так и делается, что за организацию ВП отвечает операционная система, а конкретный драйвер для нее работает не в обход трансляции адресов на процессоре.

Да где я говорил про обход трансляции адресов на процессоре? Это просто разные уровни маппинга — от организации ВП зависит, какой адрес процессор выдаст на шину, а от того, как запрограммирован маппинг I/O на адресное пространство зависит по какому физическому (выставленному на шину) адресу прочитается тот или иной регистр видеокарты или иной железяки.

S>>Ты видел хоть одно PCI'ное не-PnP-устройство?

V>Ага, у меня как раз такой "саундбластер" был, пока я его Военной кафедре не подарил.

Значит, он не соответствовал спецификации PCI, только и всего.

V>Кроме того, достаточно не-PnP драйвера, а их достаточно (NT старые же работали как-то).


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

S>>SoftIce'у не веришь.

V>Отнюдь. Я попробовал так получить память по двум базовым адресам в ВАП ядра, по которым загружены драйвера. Представь себе, первые 2 буквы в обоих случаях — MZ.

Т.е., для этих адресов PEEK и D возвращали одно и то же?
А вывод команды PHYS что при этом говорил? Может, просто маппинг виртуальных адресов на физические в этом контексте такой был?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[17]: Чтение данных из физической ячейки памяти
От: Roman_M rgmroman.narod.ru
Дата: 20.01.03 15:36
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, Roman_M, Вы писали:


RM>>Причем тут вообще может быть какой-либо ВАП ?

V>А при чем здесь физическая память? Этот адрес все-таки проходит еще трансляцию. Куда он реально мапится — мне неведомо.

При том, что poke пишет по физическим адресам, очевидно, что F6000000h — физический. Это адрес Linear Frame Buffer на моей карточке, памяти на компьютере всего 294364 KB. Линейный адрес F6000000h (из ВАП) у меня не мапится никуда, проверено с помощью команды PAGE в SoftIce. Все еще не очевидно, что память и регистры устройств могут быть доступны через верхний диапозон адресов физической памяти ? В отличии от lfb, ряд устройств могут вообще не проецироваться в ВАП , так как не подерживаются драйверами. PCI-биос по идее должен выдавать диапозон физических адресов, на которые отмаплены устройства, и, вроде, даже позваляет менять эти адреса.
Re[16]: Чтение данных из физической ячейки памяти
От: vasketsov Россия http://ntprog.by.ru
Дата: 20.01.03 15:52
Оценка:
Здравствуйте, Sergey, Вы писали:

S>..., а полные 256К отобразить куда нибудь, куда Макар телят не гонял

А как они узнают, куда Макар угнал-таки телят?

S>А какая разница? Если операционка не достает до 0xFxxxxxxx, значит, пусть работает со старыми сервисами из первого мегабайта, про новые она все равно не знает.

А их уже угнали ...

S>На виртуальную — уже потом. Я тебе про совершенно элементарную вещь говорю — если в компьютере стоит этот Savage 4, инициализированный по дефолту, и если процессор выдал на шину (в команде чтения памяти) адрес 0x700003C4, то прочитается инедксный регистр секвенсора, тот, который доступен при чтении из порта 3C4.

А если на это компе стоит 8 гигов оперативной памяти? Этот кусок использоваться не будет? Ибо винда на настройки дыры в биосе имхо кладет по полной. Кроме того, где гарантия, что видеоадаптер — не EGA какой-нибудь, и он только через порты и нижний буфер достижим?

S>Может, просто маппинг виртуальных адресов на физические в этом контексте такой был?

Да, я и сам подумал об этом, 2 — еще не критерий, может так случано вышло, проверю, как смогу.

Хочется просто описать свою позицию, ибо мы далеко от темы ушли.
Мое мнение — гарантировать, что по 0xFxxxxxxx что-то будет определенное (равно как и по 0x6xxxxxxx) — нельзя. Область определения — скажем, все машины, на которых запустится какая-нибудь винда.
Васкецов Сергей
http://registry.km.ru
Re[17]: Чтение данных из физической ячейки памяти
От: Sergey Россия  
Дата: 20.01.03 16:32
Оценка:
Здравствуйте, vasketsov, Вы писали:

S>>..., а полные 256К отобразить куда нибудь, куда Макар телят не гонял

V>А как они узнают, куда Макар угнал-таки телят?

Ровно тем же способом, как и тот факт, что по адресу 3C4 сидит индексный регистр секвенсора — кто-нибудь (AWARD, например) введет "стандарт де-факто". Я, например, совершенно не уверен, что на машине с каким-нибудь MrBIOS по адресу 000FEC71 лежит название/ревизия биоса. Но вот на авардах вероятность этого близка к 100%.

S>>На виртуальную — уже потом. Я тебе про совершенно элементарную вещь говорю — если в компьютере стоит этот Savage 4, инициализированный по дефолту, и если процессор выдал на шину (в команде чтения памяти) адрес 0x700003C4, то прочитается инедксный регистр секвенсора, тот, который доступен при чтении из порта 3C4.

V>А если на это компе стоит 8 гигов оперативной памяти? Этот кусок использоваться не будет?

IMHO, не будет. Это уже забота "материнского" чипсета — исключить соответствующий кусок оперативки. Но утверждать тут ничего не могу, я ни на одной машине с более чем 1 Гб памяти с железом не игрался. Хотя, IMHO, не зря производители "домашних" чипсетов слишком много памяти поддерживать не любят — хлопотно это, видимо.

V>Ибо винда на настройки дыры в биосе имхо кладет по полной.


Но вот на то, что она получает от шины PCI — не кладет. Иначе бы просто ничего не работало.

V>Кроме того, где гарантия, что видеоадаптер — не EGA какой-нибудь, и он только через порты и нижний буфер достижим?


А очень простая гарантия. На шине PCI надо спросить, есть ли в компьютере видеоадаптер, с которым ты умеешь по-особенному работать (с нужными vendor ID и device ID), и если есть, то где у него какой буфер.

S>>Может, просто маппинг виртуальных адресов на физические в этом контексте такой был?

V>Да, я и сам подумал об этом, 2 — еще не критерий, может так случано вышло, проверю, как смогу.

Тут и 4 не критерий — может, винда намеренно драйвера так мапит.

V>Хочется просто описать свою позицию, ибо мы далеко от темы ушли.

V>Мое мнение — гарантировать, что по 0xFxxxxxxx что-то будет определенное (равно как и по 0x6xxxxxxx) — нельзя.

Нельзя, конечно. PCI BIOS их при загрузке рассадит так, чтоб они друг с другом или ISA'шными девайсами не конфликтовали или повырубает, в крайнем случае. Поэтому сначала надо девайсы перенумеровать, потом у каждого спросить, кто какой диапазон адресов занимает. Собственно, винда так и делает, AFAIK. А, еще перед этим неплохо даташиты (и стандарты, ежели имеются) на девайсы, с которыми работать собираешься, почитать. Я б на месте SPavel вообще с чтения спецификаций DMI и ACPI начал.

V>Область определения — скажем, все машины, на которых запустится какая-нибудь винда.


Ну, на такой области определения нельзя гарантировать даже наличие видеоадаптера или мышки.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[15]: Чтение данных из физической ячейки памяти
От: Hacker_Delphi Россия  
Дата: 21.01.03 04:06
Оценка:
Здравствуйте, vasketsov, Вы писали:

V>Здравствуйте, Hacker_Delphi, Вы писали:


V>[]


V>Так процессор же вроде сам эти 0xFFFF0000 подправит, или ругнется (собственно, так вроде бы сообщается о невыделенной физической памяти).

да нет там никакого выделения памяти... процессор тока пихает адрес в адресную шину и значение пишет/читает в шине данных, а выделением памяти занимается ОС...
V>В том смысле, что даже под досом нечто вроде mov 0xFFFF0000, 0 не приводит к записи в физическую память по адресу 0xFFFF0000. Потому о том, что 0xFFFF0000 — это именно физическая память (то есть, после трансляции адресов), я бы говорить не стал.
То под DOS'ом.
Еще раз описываю работу процессора:
[q]CS, DS — сами регистры, а [CS], [DS] — их Shadow части, то есть предзагруженые селекторы в процессоре (для ускорения работы используется...
итак.[list]
  • Произошел RESET (аппаратный сигнал на ногу процессора пришел) регистры:
  • процессор переключается в режим R-mode, но (!!!) внимательно читай значения Shadow регистров, по которым происходит реальная работа до первого перехода/изменения сегментного регистра.
    регистры:
    AX - 0 если Self test прошел успешно, не 0 (там есть свои коды) если была ошибка
    DX - DH - номер семейства процессора (4 - для 486) DL - версия ядра процессора (версия трафарета).
    IP - 0xFFF0 
    CS - 0xF000
    DS - 0x0000
    [CS] - 0xFFFF0000 (!!!)
    [DS] - 0x00000000 (!!!)

  • после первой же команды дальнего перехода/вызова регистр [CS] станет равен (CS << 4) как и должно быть в R-mode ...

    PS
    Я же тебе говорю: это — чтобы BIOS мог инициализироваться нормально, не пересекаясь с обычной памятью...
    например в процессорах 8086 это был бы физический адрес 0xFFFF0, а в 286 — 0xFFFFF0 и т.д. это — просто фича, аналогичная BOOT. вот и все.
    А то, что вякие BIOS мапятся на старшие адреса физической памяти — это факт... и то, что нонешние BIOS'ы умеют это разруливать — тоже факт... у меня вот щаз две видюхи..
    одна: по адресу 0xE0000000-0xE3FFFFFF (физические адреса на шине данных!!!) и 0x000A000-0x000AFFFF (это — та карточка, которая первой в BIOS стоит.
    вторая: 0xE9000000-0xE9FFFFFF и 0xD8000000-0xDFFFFFFF ...
    причем если оставить тока вторую — она гораздо меньше диапозонов займет, но зато займет и диапозон 0x000A000-0x000AFFFF ...
    Enigma — The Eyes of Truth (The Cross of Changes)
  • Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
    Re[12]: Чтение данных из физической ячейки памяти
    От: Hacker_Delphi Россия  
    Дата: 21.01.03 04:06
    Оценка: -1
    Здравствуйте, Sergey, Вы писали:

    S>Кроме того, я не утверждал, что BIOS обязательно сидит по адресам выше 0xF0000000 — IMHO, там живет memory-mapped I/O.

    нет там однозначно живет BIOS...
    Enigma — The Eyes of Truth (The Cross of Changes)
    Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
    Re[17]: Чтение данных из физической ячейки памяти
    От: vasketsov Россия http://ntprog.by.ru
    Дата: 21.01.03 04:13
    Оценка:
    Здравствуйте, vasketsov, Вы писали:

    V>Мое мнение — гарантировать, что по 0xFxxxxxxx что-то будет определенное (равно как и по 0x6xxxxxxx) — нельзя. Область определения — скажем, все машины, на которых запустится какая-нибудь винда.


    В качестве подтверждения , на той же мамке, видео ASUS 3800M 16 мб, Windows 2000 AS + SP3 + fixes.

    peekd f6000100
    0xFFFFFFFF 111111111111111111111111 -1
    poked f6000100 00ffffff
    peekd f6000100
    0xFFFFFFFF 111111111111111111111111 -1

    То же самое для 60000000 и f000ec71.
    Естественно, никаких белых точек.

    Про MZ — все-таки случайно.
    Васкецов Сергей
    http://registry.km.ru
    Re[16]: Чтение данных из физической ячейки памяти
    От: Andrew S Россия http://alchemy-lab.com
    Дата: 21.01.03 09:29
    Оценка: 14 (1)
    Можно ссылочку на то, откуда Вы брали состояния shadow регистров и сами их описания? Интересно очень... B непонятно, при чем тут shadow регистры и CS — как они связаны???... Насколько я помню, есть просто 36 битный регистр текущего адреса, он формируется исходя из CS (либо селектора либо смещения) и EIP. Соответственно, после сброса он указывает на 16 байт ниже верхнего предела адресного окна (для 8086 это 0xFFFF0). При первом же дальнем переходе он формируется исходя из значений, указанных в команде данного перехода. Собственно, кешировать сам CS смысла нет — это же просто смещение в таблице селекторов в P режиме...

    H_D>PS

    H_D>Я же тебе говорю: это — чтобы BIOS мог инициализироваться нормально, не пересекаясь с обычной памятью...
    H_D>например в процессорах 8086 это был бы физический адрес 0xFFFF0, а в 286 — 0xFFFFF0 и т.д. это — просто фича, аналогичная BOOT. вот и все.
    H_D>А то, что вякие BIOS мапятся на старшие адреса физической памяти — это факт... и то, что нонешние BIOS'ы умеют это разруливать — тоже факт... у меня вот щаз две видюхи..

    Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000. А видео — да. Она берет себе подходящую свободную часть адресного пространства при помощи PCI.

    PS
    Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...
    http://www.rusyaz.ru/pr — стараемся писАть по-русски
    Re[17]: Чтение данных из физической ячейки памяти
    От: Sergey Россия  
    Дата: 21.01.03 09:57
    Оценка:
    Здравствуйте, Andrew S, Вы писали:

    AS>Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000.


    Вот насчет того, что не мэпятся никогда, я б не стал утверждать. И не все в 128К помещаются. Зачем им это надо, не знаю, но вот кусочек кода из исходников биоса (AWARD, 6.0):

    OverlayBios64Kb:
    ;R136 - start
    ifdef    ICH
            dd    0ffb00000H    ;32-bit low address
            dd    0        ;32-bit high address
            dd    5*1024*1024     ;32-bit length low dword
            dd    0        ;32-bit length high dword
            dd    MEM_RESERVED    ;remapped system bios at end of addr.
    else;    ICH
    ;R136 - end
            dd    0ffff0000H    ;32-bit low address
            dd    0        ;32-bit high address
            dd    64*1024        ;32-bit length low dword
            dd    0        ;32-bit length high dword
            dd    MEM_RESERVED    ;remapped system bios at end of addr.
    endif;    ICH                ;R136


    Эта хрень лежит в файле ATORGS.ASM. В более старых версиях было только:

    OverlayBios64Kb:dd    0ffff0000H    ;32-bit low address
            dd    0        ;32-bit high address
            dd    64*1024        ;32-bit length low dword
            dd    0        ;32-bit length high dword
            dd    MEM_RESERVED    ;remapped system bios at end of addr.


    Так что, оно похоже даже где-то используется. Где, зачем и почему — не знаю, не интересно мне это было.

    AS>PS

    AS>Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...

    Да это я почти сразу понял, но с BIOS'ами в наше время тоже все не так просто.
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[17]: Чтение данных из физической ячейки памяти
    От: SPavel Украина  
    Дата: 21.01.03 09:58
    Оценка:
    Здравствуйте, Andrew S, Вы писали:

    AS>PS

    AS>Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...
    Хм... действительно, чушь я спорол с физическим адресом. Признаю. Он действительно имеет значение fec71. Но сейчас не в этом дело.
    Подведу итог всей дискуссии:
    1. Выяснили, что под WinNT (права админа) данные по этому адресу можно вытащить средствами \device\PhysicalMemory (см. реализацию Русиновича) или средствами WMI
    2. Под Win9x предлагалось писать VxD. По моему мнению это не только сложно, но и неудобно в практическом применении. Ведь данное средство разрабатывается для защиты программы от взлома. А VxD IMHO для этих целей не удобно.
    3. По поводу уникальности этого номера — действительно, он не так уж и уникален. (как я понимаю, это относится не для всех версий биоса). Но ведь применяться будет не только защита по номеру материнки — это только одна из частей защиты.

    Ваши реальные предложения по пункту 2.
    PS/ Прошу сильно не пинать, если что-то пропустил в обсуждении.

    С уважением, Павел
    Re[18]: Чтение данных из физической ячейки памяти
    От: Andrew S Россия http://alchemy-lab.com
    Дата: 21.01.03 10:14
    Оценка:
    SP>2. Под Win9x предлагалось писать VxD. По моему мнению это не только сложно, но и неудобно в практическом применении. Ведь данное средство разрабатывается для защиты программы от взлома. А VxD IMHO для этих целей не удобно.

    Под 9х область первого мегабайта мапится в аналогичные виртуальные адреса процесса. Т.е. читая просто по смещению 0x0e0000 вы читаете начало биоса. Никакой VxD не нужен.
    http://www.rusyaz.ru/pr — стараемся писАть по-русски
    Re[18]: Чтение данных из физической ячейки памяти
    От: Sergey Россия  
    Дата: 21.01.03 10:17
    Оценка:
    Здравствуйте, SPavel, Вы писали:

    SP>2. Под Win9x предлагалось писать VxD. По моему мнению это не только сложно, но и неудобно в практическом применении. Ведь данное средство разрабатывается для защиты программы от взлома. А VxD IMHO для этих целей не удобно.


    Я уже говорил — посмотри книгу Питрека "Windows 95 System programming SECRETS". Там любопытная програмка PHYS описывается.

    SP>3. По поводу уникальности этого номера — действительно, он не так уж и уникален. (как я понимаю, это относится не для всех версий биоса). Но ведь применяться будет не только защита по номеру материнки — это только одна из частей защиты.


    IMHO, дурацкая это затея. Прошьет юзер новый биос, и номер этот уже другой станет. Да и модифицировать этот номер прямо в ОЗУ при загрузке винды не намного сложней, чем прочитать, так что такую защиту без особого труда отломать можно. Так что только легальным пользователям геморроя добавишь, а кракерам — пофигу.
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[18]: Чтение данных из физической ячейки памяти
    От: Andrew S Россия http://alchemy-lab.com
    Дата: 21.01.03 10:21
    Оценка:
    Хм. Нда. На нечто похожее я наталкивался, когда получал указатель на область DMI примерно в таком диапазоне. Но. Фишка в том, что даже под NT туда не замапится... Странно все это.
    http://www.rusyaz.ru/pr — стараемся писАть по-русски
    Re[19]: Чтение данных из физической ячейки памяти
    От: Sergey Россия  
    Дата: 21.01.03 10:40
    Оценка:
    Здравствуйте, Andrew S, Вы писали:

    AS>Хм. Нда. На нечто похожее я наталкивался, когда получал указатель на область DMI примерно в таком диапазоне. Но. Фишка в том, что даже под NT туда не замапится... Странно все это.


    BIOS вполне может средствами чипсета туда страницу мапить, чисто железячно, безотносительно к виртуальному адресному пространству. Если, конечно, чипсет такое умеет. Например, если просто игнорировать старший бит адреса — получим дублирование нижних 2 Гб на верхние. Доки на чипсет (а второй кусок был для i430TX) у меня дома, так что это не более чем предположение. Но вроде что-то подобное припоминается.
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[20]: Чтение данных из физической ячейки памяти
    От: Andrew S Россия http://alchemy-lab.com
    Дата: 21.01.03 10:50
    Оценка:
    Может, конечно. Ну а какого фига тогда NT туда не позволяет доступаться — она же физическую память позволяет замапить на адресное пространство юзера (\device\PhysicalMemory). Странно все это.

    S>BIOS вполне может средствами чипсета туда страницу мапить, чисто железячно, безотносительно к виртуальному адресному пространству. Если, конечно, чипсет такое умеет. Например, если просто игнорировать старший бит адреса — получим дублирование нижних 2 Гб на верхние. Доки на чипсет (а второй кусок был для i430TX) у меня дома, так что это не более чем предположение. Но вроде что-то подобное припоминается.
    http://www.rusyaz.ru/pr — стараемся писАть по-русски
    Re[21]: Чтение данных из физической ячейки памяти
    От: Sergey Россия  
    Дата: 21.01.03 11:00
    Оценка:
    Здравствуйте, Andrew S, Вы писали:

    AS>Может, конечно. Ну а какого фига тогда NT туда не позволяет доступаться — она же физическую память позволяет замапить на адресное пространство юзера (\device\PhysicalMemory). Странно все это.


    Ну так RAM-то с "дырками" получится. А сегмент с дырками не сделаешь. Если страницы транслировать, то уже не физическая память получится. Ну а людям из мокрософт зачем-то понадобилось сегмент не на все 4 Гб сделать, а только на имеющеся в системе ОЗУ. IMHO.
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[22]: Чтение данных из физической ячейки памяти
    От: Andrew S Россия http://alchemy-lab.com
    Дата: 21.01.03 12:04
    Оценка:
    Честно говоря, не понял, в чем проблема. Физическая память в NT и так транслируется в адресное пространство процесса при помощи MapViewOfSection. И никаких препятствий сделать это путем простой трансляции страниц я не вижу. Скорее всего, причина в другом. Трансляция на mapped io ports работает же...

    S>Ну так RAM-то с "дырками" получится. А сегмент с дырками не сделаешь. Если страницы транслировать, то уже не физическая память получится. Ну а людям из мокрософт зачем-то понадобилось сегмент не на все 4 Гб сделать, а только на имеющеся в системе ОЗУ. IMHO.
    http://www.rusyaz.ru/pr — стараемся писАть по-русски
    Re[17]: Чтение данных из физической ячейки памяти
    От: Hacker_Delphi Россия  
    Дата: 21.01.03 12:16
    Оценка:
    Здравствуйте, Andrew S, Вы писали:

    AS>Можно ссылочку на то, откуда Вы брали состояния shadow регистров и сами их описания?

    В.Л.Григорьев "микропроцессор i486. Архитектура и программирование" в 4 книгах, книга 1. стр. 267-270...
    ISBN 5-900676-01-3 (c) ТОО "ГРАНАЛ" 1993 г.

    Классика...
    AS>Интересно очень... B непонятно, при чем тут shadow регистры и CS — как они связаны???...
    AS>Насколько я помню, есть просто 36 битный регистр текущего адреса, он формируется исходя из CS (либо селектора либо смещения) и EIP.
    нет... для каждого селектора (CS/ES/SS/DS/FS/GS) есть теневой регистр, который является копией записи в GDT/LDT...
    AS>Соответственно, после сброса он указывает на 16 байт ниже верхнего предела адресного окна (для 8086 это 0xFFFF0). При первом же дальнем переходе он формируется исходя из значений, указанных в команде данного перехода.
    на эту тему я уже все написал в предыдущих постингах...

    AS>Собственно, кешировать сам CS смысла нет — это же просто смещение в таблице селекторов в P режиме...


    Угу и при выборке каждой очередной команды мы будем:
    1. лезть в GDT/LDT (через регистр)
    2. проверять, что селектор не за границей GDT/LDT
    3. находить через селектор описание сегмента
    4. из него считать базовый адрес и
    5. потом уже вычислять линейный адрес.

    Shadow регистры для всех селекторов созданы для того, чтобы не лазить при каждом обращении в память дополнительно в соотв. таблицы (что просто замедляет комп, т.к. кже на 486 DX2 процессор был в два раза быстрее памяти)...

    AS>Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000. А видео — да. Она берет себе подходящую свободную часть адресного пространства при помощи PCI.

    Я тебе только что написал, куда они мапятся...
    AS>PS
    AS>Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...
    А это уже не важно....
    Enigma — The Eyes of Truth (The Cross of Changes)
    Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
    Re[23]: Чтение данных из физической ячейки памяти
    От: Sergey Россия  
    Дата: 21.01.03 12:24
    Оценка:
    Здравствуйте, Andrew S, Вы писали:

    AS>Честно говоря, не понял, в чем проблема. Физическая память в NT и так транслируется в адресное пространство процесса при помощи MapViewOfSection. И никаких препятствий сделать это путем простой трансляции страниц я не вижу. Скорее всего, причина в другом.


    Да может и можно было, но обломились.

    AS>Трансляция на mapped io ports работает же...


    У меня — не работает (с адресами со старшим ненулевым байтом). По крайней мере, утилитка Руссиновича их не показывает.
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[18]: Чтение данных из физической ячейки памяти
    От: Sergey Россия  
    Дата: 21.01.03 12:38
    Оценка:
    Здравствуйте, Hacker_Delphi, Вы писали:

    AS>>Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000. А видео — да. Она берет себе подходящую свободную часть адресного пространства при помощи PCI.

    H_D>Я тебе только что написал, куда они мапятся...

    Ты уж извини, но написал ты полную фигню. При старте BIOS (если он 128 Кб) сидит по адресам E0000 — FFFFF. И выполнение начинается 0xFFFF0, а не с 0xFFFFF0. На первом пне, по крайней мере. Я уж не говорю про 286. А с RAM он не конфликтует потому, что RAM в этот момент нет вообще (по крайней мере, в конце первого мегабайта), она выключена средствами чипсета. Дальнейшее зависит от биоса, AWARD'овский копирует себя куда-то то ли в 30000h, то ли в 50000h, выключает доступ к ROM, включает R/W доступ к RAM E0000 — FFFFF и копирует себя туда. Потом запрещает W по этим адресам.
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[19]: Чтение данных из физической ячейки памяти
    От: Hacker_Delphi Россия  
    Дата: 21.01.03 12:56
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Ты уж извини, но написал ты полную фигню. При старте BIOS (если он 128 Кб) сидит по адресам E0000 — FFFFF. И выполнение начинается 0xFFFF0, а не с 0xFFFFF0. На первом пне, по крайней мере. Я уж не говорю про 286. А с RAM он не конфликтует потому, что RAM в этот момент нет вообще (по крайней мере, в конце первого мегабайта), она выключена средствами чипсета. Дальнейшее зависит от биоса, AWARD'овский копирует себя куда-то то ли в 30000h, то ли в 50000h, выключает доступ к ROM, включает R/W доступ к RAM E0000 — FFFFF и копирует себя туда. Потом запрещает W по этим адресам.


    нет это ты извини... как уже писалось, адрес с которого начинается выполнение BIOS кажется (и является) адресом CS:IP, но с 286 процессора (как тебе, наверное известно) CS ничего не говорит о физическом размещении памяти...
    Я, между прочим, ссылку на книгу дал, в которой это написано... и я писал, что данный адрес (0xFFFFFFF0) — это для 486-го процессора... я даже привел адреса для 8086 и 80268... так что ты не прав в корне...
    Enigma — I love You... I'll Kill You (The Cross of Changes)
    Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
    Re[18]: Чтение данных из физической ячейки памяти
    От: Andrew S Россия http://alchemy-lab.com
    Дата: 21.01.03 13:28
    Оценка:
    H_D>нет... для каждого селектора (CS/ES/SS/DS/FS/GS) есть теневой регистр, который является копией записи в GDT/LDT...
    Правильно. Записи в LDT/GDT. Но он никак не CS или еще там что. Это связка регистров, и она хранит дескриптор ЦЕЛИКОМ, ну или почти целиком. По крайней мере так было для 486-х. Соответственно, для дальнейших поколений x86 процессоров все еще более сложно. И EIP внутри тоже как такового нет — есть некий указатель на текущий физический адрес выборки команд, к тому же 36 битный, да еще и не один — а для каждого конвейра несколько... Так что говорить о значениях "теневых" CS по меньшей мере неразумно, т.к. нет их. Есть кеширование дескрипторов. Более того. Есть еще и кеширвание страничных таблиц. Но это уже другая тема.

    Так, про начальный адрес выполнения тебе уже сказали, далее..

    H_D>Угу и при выборке каждой очередной команды мы будем:

    H_D>1. лезть в GDT/LDT (через регистр)
    H_D>2. проверять, что селектор не за границей GDT/LDT
    H_D>3. находить через селектор описание сегмента
    H_D>4. из него считать базовый адрес и
    H_D>5. потом уже вычислять линейный адрес.

    H_D>Shadow регистры для всех селекторов созданы для того, чтобы не лазить при каждом обращении в память дополнительно в соотв. таблицы (что просто замедляет комп, т.к. кже на 486 DX2 процессор был в два раза быстрее памяти)...


    Правильно. Только они хранят не значение селектора, а сам дескриптор. CS — просто индекс в таблице дескрипторов. Очевидно, даже хряня "теневой" индекс мы не получим требуемого быстродействия, т.к. будем ползать в таблицу каждый раз для вычисления физ. адреса.

    Процессор 486 был не в 2 раза (!!! Откуда такие точные данные Цикл по шине занимал больше одного такта. Даже при пакетной 16-байтовой передаче), а гораздо быстрее памяти. Даже своего кеша первого уровня Именно из-за своей конвейерной архитектуры.

    H_D>А это уже не важно....

    Это важно Т.к. вопрос был задан неправильно, в связи с чем все полезли в дебри, тогда как все решается простым чтение по физ. адреса 0xF????. Нда.
    http://www.rusyaz.ru/pr — стараемся писАть по-русски
    Re[20]: Чтение данных из физической ячейки памяти
    От: Sergey Россия  
    Дата: 21.01.03 13:57
    Оценка:
    Здравствуйте, Hacker_Delphi, Вы писали:

    S>>Ты уж извини, но написал ты полную фигню. При старте BIOS (если он 128 Кб) сидит по адресам E0000 — FFFFF. И выполнение начинается 0xFFFF0, а не с 0xFFFFF0. На первом пне, по крайней мере. Я уж не говорю про 286. А с RAM он не конфликтует потому, что RAM в этот момент нет вообще (по крайней мере, в конце первого мегабайта), она выключена средствами чипсета. Дальнейшее зависит от биоса, AWARD'овский копирует себя куда-то то ли в 30000h, то ли в 50000h, выключает доступ к ROM, включает R/W доступ к RAM E0000 — FFFFF и копирует себя туда. Потом запрещает W по этим адресам.


    H_D>нет это ты извини... как уже писалось, адрес с которого начинается выполнение BIOS кажется (и является) адресом CS:IP, но с 286 процессора (как тебе, наверное известно) CS ничего не говорит о физическом размещении памяти...

    H_D>Я, между прочим, ссылку на книгу дал, в которой это написано... и я писал, что данный адрес (0xFFFFFFF0) — это для 486-го процессора... я даже привел адреса для 8086 и 80268... так что ты не прав в корне...

    Признаю, заглянул в манул на процессор и понял, что прогнал. Первая команда действительно идет на 0xFFFFFFF0. VIA'шный чип VT82C693 область памяти FFFEFFFF-FFFFFFFF мапит на 000Fxxxx. Не понятно только, постоянный это алиас или только на время загрузки, херовые у них даташиты (скорее всего постоянный). Но, насколько я понял, он для RAM тоже действует. И в любом случае AWARD'овский биос ведет себя так, как я написал — это я весьма детально разглядывал когда-то. Для этого тоже средства предусмотрены.
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[3]: Чтение данных из физической ячейки памяти
    От: Аноним  
    Дата: 11.02.03 14:04
    Оценка:
    SP>Было выяснено, что искомая информация содержится по адресу 0xF000EC71. Вот и всё.....


    Это частный случай для AWARD BIOS
    В других биосах искосая информация находится по другому адресу
    Re[9]: Чтение данных из физической ячейки памяти
    От: Sasha K  
    Дата: 28.07.03 08:11
    Оценка:
    Вот фрагмент из библиотеки читающий номер биоса
    Работает под 9Х
    void numbios(ParamBlk *parm){
    int *address;
    int value;
    address=(int *)0xFEC71;
    value=*address;
    _RetInt(value,20);
    }
    Но к сожалению под NT не пашет.
    Александр
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.