-
Notifications
You must be signed in to change notification settings - Fork 0
/
readme.txt
170 lines (118 loc) · 12.7 KB
/
readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
DRAW_HOOK / Перехват фукции DrawObject
(с)Dimadze
(!)Чтобы всё полностью работало нужен ELFPAck 2.3 24bit+alpha или актуальная версия EP3!
V1.9
Доступно для:
-------------------------------------------
CX75v25
C75v22
SL65v53
CX70v56
S65v58
SK65v50
-------------------------------------------
ELFPack'и 2.3 24bit+alpha для SGold X65 можно взять отсюда \elfpacks\
Можно положить фулл VKP\MODELvFIRMWARE\FF.bin для автоматического вычисления старых данных для патча
Например:
MODELvFIRMWARE - SL65v53
Описание.
Патч, следит за функцией DrawObject(), через которую отрисовывается практически всё на Siemens,
т.е. когда параметр содержит указатель на 5ый объект отрисовки (`IMGHDR+RECT), патч проверяет
на альфа-канал, если его нет (bpnum!=0x0A), то всё отрисовывается стандартным образом, иначе
в дело вступает самописная ф-ия отрисовки, она сделана максимально оптимизированной.
В основе её работы лежит запись битмапа изображения прямо в промежуточный буфер отрисовки,
я назвал его RamScreenPhoneCache (есть аналогичный для Java) c вычислением цвета при альфа - канале.
В итоге на SGold X65 могут отрисовывться 32 битные (24bit+alpha) изображения в эльфах, а также менять
графику используя все 32 бита, а не 8 и 16.
Даже на CX75 видна разница, по стандарту видны "разводы", с патчем изображение рисуется совершенно чётко.
Скорость отрисовки с патчем и без по моим наблюдениям не меняеться.
Зачем на X65 нужен спецальный ELFPack.
Дело в том, что поддержку загрузки 32 битного битмапа из png на X65 спецально урезали в ELFPack 2.3,
так как телефон всё-равно не может его отрисовывать, зачем лишнее место занимать, правда же?
Но теперь телефон научился, и соответсвенно ему нужен ELFPack 24 bit + alpha.
Как портировать.
Проект настроен, и готов к компиляции.
Я уже сделал 3 конфигурации, SL65v53, CX70v56, S65v58
При портировании следует обратить внимание на эти 2 фаила в папке \config\:
- MODELswFIRMWARE.xcl (SL65v53.xcl)
- drawhook.h
//MODELswFIRMWARE.xcl
PATCH_BODY,CODE ... - это пустое место под тело патча
PATCH_DRAWOBJECT_OBJ05 - адрес ф-ии подпрограммы DrawObject()
PATCH_DRAWOBJECT_OBJ17 - адрес ф-ии подпрограммы DrawObject()
И в дополнении для X75 надо:
PATCH_REPAIRJUMP145 - Место 8 байтного перехода на GBS_GetCurCepid
PATCH_REPAIRJUMP100 - Место 8 байтного перехода на GBS_SendMessage
PATCH_DRAWOBJECT_OBJ05_J32 - PATCH_REPAIRJUMP100 + 0x04 (дополнительное место для 32bit Branch'a)
PATCH_DRAWOBJECT_OBJ17_J32 - PATCH_REPAIRJUMP145 + 0x04 (дополнительное место для 32bit Branch'a)
PATCH_LOCALJUMP145 - Адрес GBS_GetCurCepid (0x145)
PATCH_LOCALJUMP100 - Адрес GBS_SendMessage (0x100)
//drawhook.h
Для X75:
#define EXC_CSM_MP - CSM Медиаплеера
#define EXC_CSM_ZP - CSM Функции Zoom
Ну а дальше искать ничего не нужно, но эту информацию я оставлю ...
Как искать RamScreenPhoneCache.
Для его нахождения открыть фулл в IDA, перейти на адрес ф-ии DrawObject
(берём из swilib.vkp, возможно их там будет несколько, берите любой).
Дизассемблим (THUMB), видем первую попавшуюся команду BL, переходим по ней, смотрим в окрестности,
находим команду LDR c загрузкой в регистр RAM-адреса, нашли?
Включаем ArmDebugger, переходим на этот адрес, видим указатель, дебаггер его выделит желтым,
переходим (просто нажимаем на него), теперь берём этот адрес (На CX75v25: 0xA84AE7B8)
и прибавляем к нему 0xAC (Ну это на CX75v25, а что у вас там я хз), получим 0xA84AE7B8+0xAC = 0xA84AE864.
Это и есть адрес того самого буфера. Если включить режим Monitor (M) в ArmDebugger,
и на телефоне поставить белую фон, белую заставку, что угодно, увидим массив байт 0xFF,
откуда он начался там и начальный адрес буфера.
Правда на SL65v53 я прибавил не 0xAC, а 0x1C5B4, вот так то ...
Ну или могу предложить вам следующий способ:
Отключаем overlay view (если он был и перерзагружаем телефон).
Включаем ArmDebugger переходим на RamScreenBuffer (0x0E0, берём с swilib.vkp),
и от начала буфера копируем байт 60. Теперь перейдём на 0xA8400000,
И отсюда начинаем поиск этих 60 байт, при этом телефон дожен работать в одном этом же окне,
типа, если был на IDLE, то и дожен оставаться на IDLE до окончания поиска.
RamScreenPhoneCache он всегда до RamScreenBuffer (но и до RamScreenJavaCache, это тоже промежуточный буфер. но для Java)
Ну и, если вы не устали читать, то третий способ:
Поиск по паттерну Smelter'oм или вручную
Проверено на SL65/53, CX70/56, S65/58:
ADDR:char *RamScreenPhoneCache()=&(??,48,??,22,??,21,00,90,??,48,02,92,04,22,01,91,00,23,A4,38 ) // SGold X65
Проверено на С75/22, CF75/23, CX75/25:
ADDR:char *RamScreenPhoneCache()=&(??,49,??,22,??,48,02,92,04,22,00,23,0C,39,00,90 ) // SGold X75
История версий:
1.0 - Первая публичная версия
1.1 - Проведена небольшая оптимизация
1.2 - Добавлена поддержка автоперерисовки экрана
Оказывается, DrawObject после помещения обьекта в буффер сразу же перерисовывает экран, а моя спец - ф-ия,
естественно, это делать не умела, но если попутно с полупрозрачной картинкой рисовалась, например линия,
то экран благополучно бы перерисовался вместе с картинкой, но а если нет ничего, кроме альфа-картинки?
Правильно, рисовалась бы пустота, что мы и видели на примере эльфа Turnoff'a, поэтому решено в отрисовку
32-битной картинки вставить ма-а-а-ленький однобитный IMGHDR (1x1) и баг исчез.
1.3 - Перерисовка полупрозрачных изображений в текстовом поле
В текстовом поле, как мы знаем, должны быть символы, но а также есть возможность добавлять туда
картинки, то есть спецсимволы, зашифрованные как картинки, ну и поэтому в DrawObject приходили символы,
а не картинки, и перехват не работал, в итоге пустота. Но таки нашёл место, где они (картинки-символы)
приходят в "чистом" виде и там тоже установил перехват, ну и как вы догадались - картинки видны на экране.
1.4 - Патч переписан по-другому, уменьшен размер патча, дополнительная автоперерисовка экрана больше не нужна.
1.5 - Ещё одна перестановка
Разгрузил врезки, оставил одну команду в каждой, т.е. уменьшил лишний восстановительный код,
Добавлена поддержка полупрозрачности картинок в текстовом поле Java, теперь патч легко портируем,
т.е. надо найти врезки и всё, никаких дополнительных ROM/RAM адресов.
А также ведётся учёт глобальных границ отрисовки, т.е. картинка не вылезет туда куда нельзя.
но врезки действителны в пределах +/- 4 Мб, поэтому на X75 никак не достанут до тела патча.
Да и впрочем, влезать в прошивку с таким "хирургическим" вмешательством - это не есть хорошо,
из плюсов: небольшое преимущество в качестве отрисовки, а из минусов - баги, лаги, раздербаненная
ф-ия DrawObject.
1.6 - Прорисовка полупрозрачных изображений в Java и иправлены некоторые баги
1.7 - Добавлена поддержка отрисовки 32х разрядного пакованного битмапа 0x8A
Дело в том, что алгоритм расшифровки RLE, на чём основана паковка битмапа, не полностью работает,
но пока нет для меня доказательств, что он не достаточен для полноценной отрисовки.
В любом случае буду искать более универсальные и оптимальные пути решения этой проблемы.
1.8 - Поправлена отрисовка 32х разрядного пакованного битмапа 0x8A
Теперь она работает на 100%, механизм RLE для пакованного битмапа 0x8A полностью поддерживаеться.
И эта ф-ия оснащена защитой от зависания, если ей дали неверно составленный битмап.
Дело в том, что при неправельном исполнении битмапа, вся последовательность пикселей идёт наперекосяк,
это может вызвать многократное ложное считывание повторений и тогда отрисовка выходит далеко за пределы
битмапа в RAM'e. Ну и так как снежный ком, телефон так и будет заниматься этой отрисовкой - в итоге зависание.
1.9 - Немного упорядочен механизм отбора картинок, а также убирание глюка в медиаплеере на X75
Более тщательно изучил ф-ию DrawObject, а точнее, её механизм распределения отрисовок обьектов, не знаю
поможет это в скорости, но такой кашы в исходниках больше нет. Так ничто другого не придумав, убрать глюк
в медиаплеере на X75 пришлось огорождением Draw Hook от него, т.е от его CSM.