OllyDbg & msr

я не пойму вообще - при чем тут сохранит msr-ы или нет? как-только аппаратный бряк сработал - так и читай msr-ы. Контекст тут вообще не при чем. Они "глобальные" если можно так выразиться. В качестве аттача прикладываю выдранные из своей книги про отладчик софтайс страницы про эти MSR-ы





_1563769973__MSR.zip

 

Broken Sword

Это перевод мануалов Интела

Вот как раз почитав эти доки у меня сложилось впечатление что прежде чем читать LastBranchToIP/LastBranchFromIP нужно записать что-то в DebugCtlMSR чтоб активировать нужный режим..



Вот какой-то кусок непонятного сорца или патча к сорцу:

Код (Text):

1. void
2.  kdba_installdbreg(kdb_bp_t *bp)
3.  {
4. @@ -708,6 +742,11 @@
5.  {
6.  u32  lv, hv;
7.  
8. +/* Does the P5 have this? */
9. +if (kdba_msrtype != IntelP6) {
10. +return;
11. +}
12. +
13.  rdmsr(DEBUGCTLMSR, lv, hv);
14.  lv |= 0x1;/* Set LBR enable */
15.  wrmsr(DEBUGCTLMSR, lv, hv);
16. @@ -734,6 +773,11 @@
17.  u32  bflv, bfhv;
18.  u32  btlv, bthv;
19.  
20. +if (kdba_msrtype != IntelP6) {
21. +kdb_printf("Last branch information not supported on this CPU.\n");
22. +return;
23. +}
24. +
25.  rdmsr(LASTBRANCHFROMIP, bflv, bfhv);
26.  rdmsr(LASTBRANCHTOIP, btlv, bthv);
27.  kdb_printf("Last Branch IP, from: 0x%x  to 0x%x\n",
28. @@ -1087,6 +1131,7 @@
29.  void
30.  kdba_init(void)
31.  {
32. +checkcpu();
33.  kdba_enablelbr();
34.  
35.  return;

 

так понятно что кроме интела про их процы никто писать не будет прежде чем читать эти регистры нужно установить в единицу LBR. Больше ничего!

 

У меня, кстати, AMD, SoftIce тоже показывает эти LastBranchToIP/LastBranchFromIP, здесь возникает вопрос как насчет совместимости AMD и Intel'а, и какие процы отбрасывать при проверке проца.

Кстати, насчет сорца, кажется это линух, может кто-нить приведёт полный сорец..



> прежде чем читать эти регистры нужно установить в единицу LBR. Больше ничего!



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

 

ну почему не хочешь читать мануалы? (или на худой конец пришпиленный мной перевод). там же сказано - если ентот бит стоит, то при выполнении команд переходов (CALL и LOOP в т.ч.) автоматом в MSR-регистры занесется инфа "откуда" и "куда". Т.е. походу выполения проги они обновляются тысячи раз. Как только сработал бряк - бит LBR тут же сбрасывается. И мы видим "окаменелости" последнего перехода. Обработчик должен по выходу восстанавливать LBR.

 

Кстати, у меня на INTEL celeron 1700 этих регистров НЕТ

 

Broken Sword

> или на худой конец пришпиленный мной перевод



И правда, я что-то в первый раз не дочитался..

Осталось разобраться в каком виде читаются эти данные если читать/писать недокументированным способом при помощи функции ZwSystemDebugControl как в примере по ссылке приведенной ранее и можно будет пробовать

 

Кстати, а Целерон это у нас что, отбракованный P-III или P-IV ??

 

Asterix

celeron 1700 - p4 кастрированный.

msr вроде только у P6 Family присутствуют, так что у P4 их нет.

 

> "msr вроде только у P6 Family присутствуют, так что у P4 их нет"



Как это нет ? Есть конечно, но на то они и model specific, что могут отличаться в разных моделях.

Заглянем а IA-32 часть 3, разделы 15.5-15.7 "LAST BRANCH, INTERRUPT, AND EXCEPTION RECORDING" и Appendix B "Model-Specific Registers (MSRs)" и увидим, что в P4: бит LBR остался на своем месте (только название регистра 1D9h изменилось), а вот хранение FromIP и ToIP изменилось существенно. P4 может хранить инфу о 4, а в model 3 аж о 15 последних переходах. Соответственно и число регистров увеличилось, и организованы они в виде кольцевого стека (circular stack), а на последнее значение указывает регистр индекса вершины стека MSR_LASTBRANCH_TOS.



PS: "ну почему не хочешь читать мануалы?" (C) Broken Sword, 2005

 

Если ещё актуально: нашёл черновой вариант дрова с DR и MSR.

Каркас от Four-F, работа с MSR и DR от Intel. Проверял, кроме Intel'a, на AMD K7- работает.

1709225706__DrLog.rar