PDA-версия форума ASUSMobile.RU

Поиск - Профиль - Войти и проверить личные сообщения - Вход - Регистрация
Форум Asus Mobile Club Russia > Полезное > Раздел Разработчика и Программиста > Таблица релоков в модуле

На страницу Пред.  1, 2, 3, 4
[Ответить на тему]

Skydance [26.04.10, 10:42] :
Извините, в выходные времени не было.
Файлик с оффсетами релоков прилагаю.

[spoiler:c5e3fe55b1=карта RAM]
804c0000 - 804c0000 L00000000 Start: start of RAM
804c0000 - 804c6000 L00006000 uninitialized data of region_2 nk.exe
804c6000 - 80593000 L000cd000 initialized data of region_3 nk.exe
80593000 - 80594000 L00001000 initialized data of region_5 nk.exe
80594000 - 80595000 L00001000 initialized data of region_6 nk.exe
80595000 - 80596000 L00001000 initialized data of region_1 hd.dll
80596000 - 8059a000 L00004000 initialized data of region_1 osaxst0.dll
8059a000 - 8059a000 L00000000 ------ start of RAM free space
[/spoiler:c5e3fe55b1]

В аттаче - список релоков, кроме тех двух, что с "битом 5". Совершенно точно bepe platform rebuilder делает на 4 изменения больше (точнее, на 5, но 5-й не есть релок, а просто page pool он там меняет).

Кстати, обе записи с "битом 5" в самом конце секции релоков, так что, думаю, вряд ли они влияют на извлечение других секций.

[Ответить на тему]   Ответить с цитатой   
Barin [26.04.10, 12:53] :
Skydance писал(а):
platform rebuilder делает на 4 изменения больше

Одно из этих изменений наверняка адрес romhdr в теле nk по адресу (romhdr.pExt - 4)

За файлик пасибо! Сравню.

Добавлено спустя 1 час 53 минуты 52 секунды:

Мда... По количеству и адресам у нас с Вами полное совпадение

[Ответить на тему]   Ответить с цитатой   
Skydance [26.04.10, 13:28] :
Нет, я адрес, куда pExtensions указывает, тоже откинул.

Именно что 4 раза по 32 бита меняются. Но найти их соответствие чему-либо я так и не смог.

[Ответить на тему]   Ответить с цитатой   
Barin [26.04.10, 14:04] :
Skydance
Однако... решил я тут "вольюнтаризьмом" заняться...
Пробегаюсь по секциям с шагом в 4 байта.
Считываю dword, если не попадает в границы realaddr<->realaddr+vsize текущей секции или других секций (.Reloc естественно вообще игнорим), то откидываю. Если не кратно 4 откидываю.
И в результате получил 6944 значения. А в наших с Вами файлах 6940.

Неужто оно? Yahoo или всё-так бред? Wacko

Это я так нахрапом... Сейчас конечно rva буду проверять в результатах...
Боюсь даже загадывать, неужели всё так просто, блин?

[Ответить на тему]   Ответить с цитатой   
Skydance [26.04.10, 14:44] :
Barin писал(а):

Пробегаюсь по секциям с шагом в 4 байта.

Ага, я тоже такой эксперимент проводил.
Однако, в продакшн-код я такое не рискну поставить. А ну вдруг будет совпадение, например, два WORD'а рядом удачно попадут...

[Ответить на тему]   Ответить с цитатой   
Barin [26.04.10, 14:56] :
Skydance
Вот сейчас и проверим на живом девайсе icon_smile

[Ответить на тему]   Ответить с цитатой   
Skydance [26.04.10, 15:06] :
Ага, "испытай неизведанное" (С)
Я вообще все-таки хочу понять взаимосвязь релоком с "битом 5" и тех четырех указателей, которые релочатся.

[Ответить на тему]   Ответить с цитатой   
Barin [26.04.10, 15:45] :
Skydance
Ну испытал - доволен и счастлив Yahoo
Тасую секции nk на 750-м как хочу, и в хвост и в гриву и всяко разно - работает icon_smile
Разница такая же как и на Лео - 4 фиксапа.

Лео только вечером попробую - сейчас рабочий аппарат нужен
Понимаю конечно, что это решение проблемы в "лоб", и так делать не стоит, но всё-таки результат положительный.


[Ответить на тему]   Ответить с цитатой   
Skydance [26.04.10, 15:58] :
Ну шож, я рад, что внес свой скромный вклад в совершенствование этого мира и наших знаний в частности Wink

...и все-таки, это уж очень неофициальный путь. Я вот на 100% уверен, что те 4 релока описаны именно в тех самых записях с "битом 5". Понять, бы, как...

[Ответить на тему]   Ответить с цитатой   
Barin [26.04.10, 16:27] :
Skydance
Я вот что увидел.... 2 фиксапа из 4-х попадают на первые 2 dword в первой секции init data и по этим адресам содержатся её же realaddr

Код:
Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   00 60 4D 80 00 60 4D 80                            .`M?.`M?


Код:
   o32[3].o32_realaddr:   804D6000
   o32[3].o32_flags:      C0000040


Самое интересное, что 2 других фиксапа (которые попадают в S000) указывают на этот же самый realaddr... Я попробую это дело учесть автоматически.

Добавлено спустя 18 минут 29 секунд:

У меня под рукой есть XIP'ы от других девайсов (Dell, HP, p526-527, Topaz, Blackstone) - везде ситуация абсолютно аналогичная.

[Ответить на тему]   Ответить с цитатой   
Skydance [26.04.10, 18:11] :
Barin писал(а):

Я вот что увидел.... 2 фиксапа из 4-х попадают на первые 2 dword в первой секции init data и по этим адресам содержатся её же realaddr

Из четырех, в смысле из тех, которые не записаны в таблице fixup'ов, но при этом содержался в init. data секциях?

У меня на этой неделе, скорее всего, не будет времени вернуться к изучению этого вопроса Sad Но я буду честно подглядывать icon_smile на между-майских вернусь... наверное.

[Ответить на тему]   Ответить с цитатой   
Barin [26.04.10, 19:55] :
Skydance писал(а):
в смысле из тех, которые не записаны в таблице fixup'ов

Да.
Skydance писал(а):
на между-майских вернусь

Ну тогда пока мы что порешим, для nk адреса подсчитываем по rva, а для остальных модулей K по vsize?
(хотя для nk у меня работает и так и так, во всяком случае на моих девайсах)
Я пока буду молча продолжать экспериментировать. Возвращайтесь, может к нам ещё кто-то присоединится, а может найдётся кто-то, кто расставит точки над ё по этому вопросу

[Ответить на тему]   Ответить с цитатой   
Barin [27.04.10, 16:37] :
Skydance
Ох, мамочки, ой, не могу ROFL
Всё вообще оказалось проще пареной репы, и дело у меня было вовсе не в последних фиксапах (у которых бит 5 = 0). Надо было просто в nk поточнее идентифицировать, к какой секции адрес относится (точнее содержимое адреса, на который указывает фиксап). И всё. Для меня проблема решилась - всё получается как надо именно по таблице фиксапов, адреса в секциях меняются корректно, секции тасуются и двигаются как надо (как я хочу), при этом никаких проблем.


[Ответить на тему]   Ответить с цитатой   
Skydance [27.04.10, 18:10] :
Не совсем понял предыдущее сообщение.
Но чисто умозрительно предполагаю, что вы пошли еще на один уровень indirect'а вниз, и проверяете не только перменные по смещениям фиксапов, но и то, куда указывают эти переменные, и даже то, куда указывают указатели указателей этих переменных.

И все же - но для чего же тогда нужны релоки с "битом 5"? Что они вообще значат, эти последние два блока?


[Ответить на тему]   Ответить с цитатой   
Barin [27.04.10, 18:20] :
Skydance писал(а):
но для чего же тогда нужны релоки с "битом 5"

Этого я к сожалению не понимаю. К тому же в nk попадаются ещё 2 непонятно каких фиксапа (для чего они нужны - тоже интересный вопрос), которые указывают в область vbase<->o32(0).o32_realaddr. Я их как откидывал, так и откидываю, все равно в этой области ничего осмысленного, кроме сигнатуры сжатия, адреса romhdr и смещения до romhdr нет. Ни один из этих фиксапов не указывает на эти величины, а попадают они пальцем в небо, например 0х29.

[Ответить на тему]   Ответить с цитатой   
Skydance [28.04.10, 08:49] :
Barin писал(а):
Ни один из этих фиксапов не указывает на эти величины, а попадают они пальцем в небо, например 0х29.[/off]

Так это и есть те фиксапы из "бита 5" icon_smile
Поясню. Эти фиксапы (0х29 и другие до 0х1000) вы берете из двух последних блоков, тех, где третий байт как раз без "бита 5".
Я эти блоки фиксапов вообще целиком отбрасываю, пока, правда, по косвенным признакам - размер блока фиксапов "3 байта", и третий байт как раз и не содержит "бит 5", и идут они в конце секции релоков.

Грубо говоря, если в блоке фиксапов (ну, который начинается с pageRVA/size) есть фиксап с битом 5, я отбрасываю блок целиком, т.к. в нем все равно нет ни одного нормального (с точки зрения стандартного алгоритма) оффсета.

[Ответить на тему]   Ответить с цитатой   
DeadMan [28.04.10, 12:45] :
2Skydance: извиняюсь что немного поффтоплю, а может напишите как дебажить с помощью KITL и какойсофт и .т.п. для этого нужно

 i  Barin:
Пока не будем считать это оффтопом.
Присоединяюсь к вопросу.


[Ответить на тему]   Ответить с цитатой   
Skydance [11.05.10, 09:54] Про KITL:
KITL сам по себе ничего не значит, это протокол для связи РС и СЕ-девайса.

Дебажащий софт входит в состав Platform Builder от MS. Это такой plug-in в MS Visual Studio (качается и ставится отдельно, там только аккуратно надо выбрать версию, которая поддерживает именно нужную версию ядра СЕ).

Короткое видео на тему: http://www.microsoft.com/showcase/en/us/details/0a8d9767-a419-4f5e-9b37-4328b0993d1d

А вообще, вот тут http://msdn.microsoft.com/en-us/library/aa915995.aspx много именно про KITL, хотя я предполагаю, вам нужен не столько KITL, сколько Platform Builder.


Теперь вернемся к теме.
Я продолжил медитировать на битики из reloc-секций (теперь, правда, я расширил [s:a0f6542d86]свое сознание[/s:a0f6542d86] свои познания - взял файлики из IMGFS). Кажется, у меня появилось еще одно предположение. Сжатые релоки по структуре блоков подозрительным образом походят на XPR-сжатые релоки любых других лежащих на IMGFS файлов.

Однако ж, простой подход "ударить XPR_DecompressOpen" впрямую не прокатил. Вероятно, из-за destination length, которая банально неизвестна (o32_psize - это source length, а o32_vsize вообще всегда имеет выравнивание по границе страницы).
Отсюда вопрос: нет ли у кого доки по XPR-компрессии?

[Ответить на тему]   Ответить с цитатой   
Barin [11.05.10, 17:04] :
Skydance
А ежели поблочно попробовать, длина каждого сжатого блока известна, а выходной буфер для блока сделать достаточно большим.

[Ответить на тему]   Ответить с цитатой   
Skydance [12.05.10, 08:23] :
Barin писал(а):

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

Это я сразу за первым способом попробовал icon_smile Разумеется, тоже не работает.
Там явно для чего-то нужны те два байта, которые идут перед размером блока.
Пока мне особо некогда к этому вернуться, но я потихоньку веду раскопки.
Одно я уже понял совершенно точно: релоки упакованы generic методом, т.е. это какой-то общеизвестный алгоритм.

PS: не LZX (который в compress_nt), его я тоже попробовал, тоже в двух вариантах icon_smile

[Ответить на тему]   Ответить с цитатой   

[Ответить на тему]

На страницу Пред.  1, 2, 3, 4
Форум Asus Mobile Club Russia > Полезное > Раздел Разработчика и Программиста > Таблица релоков в модуле