Исследование механизма работы ПО MMCS

Bedolaga · 07.06.2011, 12:59

Позволю себе небольшую мутную ремарку, касающуюся технического аспекта взлома кода MMCS:

Посмотрев файлы из директории MODULES загрузчика, увидел файл с прикольным названием "jitdbgr.exe", судя по которому он должен был бы быть связан с механизмом Just In Time Debugging.

И точно, беглый анализ его содержимого указывает на то, что это JIT обработчик исключений. Это обычная вещь, он на всех осях стоит, ловит деление на ноль, нарушение привилегий, выдает посмертные дампы и т.п.

А это значит, что в принципе можно пытаться как-то зряче в динамике отлаживать свои наработки в MMCS используя этот модуль. Поясню:

В теле исследуемой программы можно в нужные места вставлять инструкцию "BRK" и я так полагаю, что после нее управление переходит аккурат в модуль "jitdbgr.exe", где можно как-то это событие обработать.

Ёжик Пых · 07.06.2011, 16:47

Цитата:

Сообщение от Bedolaga

...
Посмотрев файлы из директории MODULES загрузчика, увидел файл с прикольным названием "jitdbgr.exe", судя по которому он должен был бы быть связан с механизмом Just In Time Debugging.

Вот оно как. А я думал это с JTAG связано

.

Bedolaga · 07.06.2011, 18:09

Цитата:

Сообщение от Ёжик Пых

Вот оно как. А я думал это с JTAG связано

.

Убедитесь сами на примере начального фрагмента:

Код:

.text:00013A64                 .export start
.text:00013A64 start:
.text:00013A64                 mov.l   r8, @-r15
.text:00013A66                 mov.l   r9, @-r15
.text:00013A68                 mov.l   r10, @-r15
.text:00013A6A                 mov.l   r11, @-r15
.text:00013A6C                 mov.l   r12, @-r15
.text:00013A6E                 mov.l   r13, @-r15
.text:00013A70                 sts.l   pr, @-r15
.text:00013A72                 add     #-h'68, r15
.text:00013A74                 mov     r6, r8
.text:00013A76                 mov.l   @(h'28C,pc), r4 ; [00013D04] = aStartJitdebugg
.text:00013A78                 mov.l   @(h'28C,pc), r9 ; [00013D08] = _NKDbgPrintfW
.text:00013A7A                 jsr     @r9 ; _NKDbgPrintfW
.text:00013A7C                 nop
.text:00013A7E                 mov.l   @(h'28C,pc), r4 ; [00013D0C] = aSetJitDebugger
.text:00013A80                 jsr     @r9 ; _NKDbgPrintfW
.text:00013A82                 nop

где NKDbgPrintfW - это штатная ВинЦе функция отладочного вывода.

Вот Вы ранее писали:

Цитата:

Нужен дамп RAM запущеной системы...

а ведь jitdbgr это фактически умеет делать, да еще при своем вызове пишет логи на "Disk2" в файл HL.TXT:

Код:

 
.text:00016404                 mov.l   @(h'B0,pc), r4 ; [000164B8] = aLgd1
.text:00016406                 mov.l   @(h'B4,pc), r3 ; [000164BC] = _CreateFileW
.text:00016408                 jsr     @r3 ; _CreateFileW
.text:0001640A                 mov     #0, r6
.text:0001640C                 cmp/eq  #-1, r0
.text:0001640E                 bt/s    loc_16448
.text:00016410                 mov     r0, r8
.text:00016412                 mov     #8, r3
.text:00016414                 mov.l   r13, @(h'1C,r15)
.text:00016416                 add     r14, r3
.text:00016418                 mov.l   @(h'A4,pc), r6 ; [000164C0] = aHl_txt
.text:0001641A                 mov.l   r3, @(h'18,r15)
.text:0001641C                 mov     #4, r3
.text:0001641E                 mov.l   r3, @(h'14,r15)
.text:00016420                 add     r14, r3
.text:00016422                 mov.l   r3, @(h'10,r15)
.text:00016424                 mov     #h'C, r7
.text:00016426                 mov.l   @(h'9C,pc), r3 ; [000164C4] = _DeviceIoControl
.text:00016428                 mov     #0, r5
.text:0001642A                 jsr     @r3 ; _DeviceIoControl
.text:0001642C                 mov     r8, r4
.text:0001642E                 cmp/eq  #1, r0
.text:00016430                 bf/s    loc_16442
.text:00016432                 mov     r8, r4
.text:00016434                 mov.l   @(4,r14), r6
.text:00016436                 mov     r14, r7
.text:00016438                 mov.l   @(h'8C,pc), r3 ; [000164C8] = _WriteFile
.text:0001643A                 mov     r12, r5
.text:0001643C                 jsr     @r3 ; _WriteFile
.text:0001643E                 mov.l   r13, @(h'10,r15)
.text:00016440                 mov     r8, r4

Ёжик Пых · 08.06.2011, 01:01

Цитата:

Сообщение от Bedolaga

а ведь jitdbgr это фактически умеет делать, да еще при своем вызове пишет логи на "Disk2" в файл HL.TXT:

Алексей, позвольте на "ты", если нет возражений ?

Этот Disk2 спокойно может оказаться RAM диском, я видел ссылки на его создание в коде. Жесткий диск система обзывает по моему HDD1, HDD2 и т.д.

---------- Добавлено в 01:35 ---------- Предыдущее сообщение было написано в 01:01 ----------

Цитата:

Сообщение от Filly

уважаемые одноклубники,
живу в славном городе Саратове, кто нибудь может наладить навигацию по городу? у меня почему то нету ее....если есть желающие помочь пишите в ЛС плиз)

Читайте внимательно шапку темы и сдклайте сами. В версии карт 2010-А Саратов нарисован достаточно подробно.

Bedolaga · 08.06.2011, 02:50

Цитата:

Сообщение от Ёжик Пых

Алексей, позвольте на "ты", если нет возражений ?

Этот Disk2 спокойно может оказаться RAM диском, я видел ссылки на его создание в коде. Жесткий диск система обзывает по моему HDD1, HDD2 и т.д.

Конечно, Дмитрий.

По поводу DSK2:
там вот какие еще фрагменты есть:

Код:

 
.text:00013B62                 mov.l   @(h'210,pc), r4 ; [00013D74] = aDsk2
.text:00013B64                 mov.l   @(h'1C0,pc), r3 ; [00013D28] = _CreateFileW
.text:00013B66                 jsr     @r3 ; _CreateFileW
.text:00013B68                 mov     r10, r5
.text:00013B6A                 cmp/eq  #-1, r0
.text:00013B6C                 bf/s    loc_13B7C
.text:00013B6E                 mov     r0, r8
.text:00013B70                 mov.l   @(h'204,pc), r4 ; [00013D78] = aCouldNotOpenHd
.text:00013B72                 mov.l   @(h'194,pc), r3 ; [00013D08] = _NKDbgPrintfW
.text:00013B74                 jsr     @r3 ; _NKDbgPrintfW
 
....
 
.text:000114B0 aCouldNotOpenHd:                        ; DATA XREF: start:off_13D78o
.text:000114B0                 unicode 0, <Could not open HDD device(DSK2). STANDBY IMMEDIATE failed>

все это говорит, за то, что JIT дебаггер открывает файл на HDD для логгинга и пишет туда. Я конечно не ратую прямо вот сейчас все это ковырять, но думаю как способ делать дампы на диск и управлять процессом в динамике - это хороший, годный способ.

Update:

что радует, в MMCS режим JIT отладки включен, т.е. не нужно мучительно править и перешивать реестр, как описано здесь.

Действительно, смотрим содержимое реестра посредство loadingview (см. вложенную картинку). Режим отладки включен. Значит можно этим пользоваться.

Update2:

еще немного поковырявшись с использованием в MMCS JIT отладчика и функции вывода отладочных сообщений NKDbgPrintfW могу высказать предположение, что та маленькая дырочка с торца экрана (типа аудиоджека) это COM порт, через который в частности может проводится отладка MMCS посредством Platform Builder'a. Так-то вот.

Alex01 · 08.06.2011, 13:31

Цитата:

Сообщение от Bedolaga

По поводу DSK2:

все это говорит, за то, что JIT дебаггер открывает файл на HDD для логгинга и пишет туда.

на жестком диске есть пустой раздел, возможно он как раз для этих целей и существует..

AS21 · 24.02.2014, 08:35

Цитата:

Сообщение от Bedolaga

Позволю себе небольшую мутную ремарку, касающуюся технического аспекта взлома кода MMCS:

В теле исследуемой программы можно в нужные места вставлять инструкцию "BRK" и я так полагаю, что после нее управление переходит аккурат в модуль "jitdbgr.exe", где можно как-то это событие обработать.

JTag я нашел, но для него надо еще программу, и он нужен на этапе отладки ядра
Мы это прошли. У нас нет уже вечного ребут
Далее -> вставлять инструкцию "BRK"...

Добавлено через 1 минуту

Цитата:

Сообщение от MadLord

может Отаку про что-то другое говорит?.

именно...

MadLord · 24.02.2014, 09:38

Цитата:

Сообщение от AS21

JTag я нашел

прямо контакты на плате?...можешь показать?...

AS21 · 24.02.2014, 09:55

Цитата:

Сообщение от MadLord

прямо контакты на плате?...можешь показать?...

См почту

Добавлено через 2 минуты
Кто может помочь разобраться взаголовке PE format:
Для запуска файл должен быть в формате PE, минимально необходимо для этого, чтобы он был: во-первых EXE (байты по смещению 0h равны 5A4Dh – "MZ"), во-вторых, слово по смещению 18h должно быть >=40h, тогда и только тогда поле смещения PE Header по адресу 3Ch имеет смысл.

Для нахождения заголовка PE в файле воспользуемся полем Offset to PE Header, находящемуся по смещению 3Ch от начала файла.
1) 00h - 40h - dosHeader
2) 40h - 80h - dosCode
3) 80h - E0h - ???

Если у меня слово по смещению 3Сh =E0h -> далее идет PE и т.д.
Для чего адрес 80h - E0h - я находил как мин 2 варианта заполнения, на что его содержание влияет?

// followed by something unknown

// 0000080: bf 1a f4 da fb 7b 9a 89 fb 7b 9a 89 fb 7b 9a 89 .....{...{...{..

// 0000090: fb 7b 9b 89 fa 7b 9a 89 66 5b ba 89 f8 7b 9a 89 .{...{..f[...{..

// 00000a0: 82 5a be 89 fa 7b 9a 89 52 69 63 68 fb 7b 9a 89 .Z...{..Rich.{..

// 00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Во 2-м варианте
0x0e, 0xdb, 0x6d, 0xde, 0x4a, 0xba, 0x03, 0x8d, 0x4a, 0xba, 0x03, 0x8d, 0x4a, 0xba, 0x03, 0x8d,
0x5a, 0xb2, 0x5a, 0x8d, 0x49, 0xba, 0x03, 0x8d, 0x4a, 0xba, 0x02, 0x8d, 0x69, 0xba, 0x03, 0x8d,
0x64, 0x9f, 0x33, 0x8d, 0x55, 0xba, 0x03, 0x8d, 0x5a, 0xb2, 0x5b, 0x8d, 0x4b, 0xba, 0x03, 0x8d,
0x23, 0xb3, 0x3b, 0x8d, 0x4b, 0xba, 0x03, 0x8d, 0x5a, 0xb2, 0x55, 0x8d, 0x4b, 0xba, 0x03, 0x8d,
0x52, 0x69, 0x63, 0x68, 0x4a, 0xba, 0x03, 0x8d, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

и еще:
что это за код: 52 69 63 68 -> Rich
Может этот участок зависии от процессора? Вряд ли

MadLord · 24.02.2014, 11:19

Цитата:

Сообщение от AS21

и еще:
что это за код: 52 69 63 68 -> Rich
Может этот участок зависии от процессора? Вряд ли

http://exelab.ru/art../?action=view&id=146
Адрес таблицы отладочной инфы - не оно?

Добавлено через 5 минут
Хотя нет, это вроде что то недокументированное
http://rcecafe.net/?p=27