Unlocking the touchpad driver when loading in recovery mode on MTK processors | android



Rep: (2217)
Unlocking the touchpad driver when booting in recovery mode on MTK processors

Device or OS, firmware: android

Unlocking the touchpad driver when booting in recovery mode on MTK processors.
Like many who build / port TWRP to devices with an MTK processor, I ran into a non-working touchpad. In the branch, one fresh Chinese smartphone appeared TWRP from a respected jemmini made throughOrder table of custom recovery (Post jemmini # 55966593), but as it turned out the touch did not work there, the one who ordered did not check, in general, a muddy story, and OTG did not have this miracle. After that, I ported TWRP from several devices on the same chip, they all loaded, but the touch did not work. Here it became clear that the matter is in the core. In search of information stumbled uponthis postwhere there were two wonderful links, one could say theory and practice. Be sure to read the article on the firstreferenceto understand the following description. In the article, the author tells in detail the theory and briefly some practice. For a second more practice. The essence of the method is that in the proceduretpd_i2c_probe looking for a place to check the boot mode get_boot_mode and this check is deleted, or the conditional jump is deleted. I propose to make the function get_boot_mode always returned boot mode NORMAL_BOOT = 0 , then the driver of the wheelbarrow will be loaded. Moreover, it is much less procedure tpd_i2c_probe , and the call to this function was not obvious to me. The finished TWRP from jemmini was taken as the test subject, well, do not lose the good.

And so we will need the following tools:IDA Pro v6.8and a small repacker withgithub. The only utility, probably out of a dozen of me tested, which is correct! I unpacked my image, but it may break off on others. AndImgTool will help many people to disassemble (in this post, an assembly of several utilities, almost a kitchen), you can unpack it with your hands,In general, this is a separate complex topic. Carefully understand the installation of IDA, be sure to installpython inside the IDA distribution. Instructions for installing IDA, though in Chinese, but there are only 3 points.

1. Copy the experimental test named recovery.img to the directory\ MTbootimg \ _in \. We parse the recovery in MTbootimg by executing unpack.bat and extract the kernel\ MTbootimg \ _work \ kernel. We need exactly the kernel kernel, its size is about 20MB, not to be confused with zImage (6-7MB)
2. Copy the filekernelin a separate place where we will work with him and load it into IDA.
Attached Image



3. Moreover, for kernels of version 4.x.x, the initial boot address is set as0xFFFFFF8008080000 for 3.x.x - 0xFFFFFFC000080000 but there may be exceptions. There were also kernels with the address 0xC0008000.
Attached Image


4. Change the bit depth of the segment. Although this is not always required.
Attached Image

Attached Image

Attached Image

Attached Image



5. Next, load the kallsyms_all.py script for parsing procedures and functions. If the body is in the hands, you can merge the kallsyms and see there (first line)
The options I have met are C0008180, C0008240, C0100000, C0200000, FFFFFF8008081000, FFFFFF8008082000, FFFFFFC000081000 ... write to you in person, add here. How to determine exactly, I do not know, everything is intuitive and brute force. If anyone knows - share.
Attached Image

Attached Image



If such an error occurs, then the address is not correct.
Attached Image


6. We are waiting for the end of the script, the named part should appear in the left part, and we find the functionget_boot_mode . To do this, sort the functions and procedures alphabetically by clicking on the header of the column. In the left column, click 2 times on the function found and it opens in the right window. You can search through the menu search, in which window the cursor is looking there. We are interested in the variable W0 . She needs to assign a value of 0, which means loading mode NORMAL_BOOT .
Attached Image



7. We will edit this line to getMOV W0, # 0 . For this is necessary in the line 0xFFFFFF8008537094 replace the first 4 bytes with 00 00 80 52 . The variable name W0 may be different, for example R0, then the replacement bytes will be different. For example, you can do a search by code
MOV R0, # 0
and spy as these 4 bytes look like.
Attached Image

Attached Image
Attached Image



8. Save changes
Attached Image

Attached Image


9. When comparing in TC a patched and bucked original, it should turn out similar to this.
Attached Image



10. Next patchedkernelwe copy with replacement in\ MTbootimg \ _work \ kerneland pack pack.bat.
Repackaged recovery is in\ MTbootimg \ _out \ boot_repack.img
I did it like thishttps://www.youtube.com/watch?v=9shCBgfS4GY

Collected on knees, does not always take into account file names
Attached fileMTbootimg.zip(2.82 MB)

AcknowledgmentsLazyC0DErand Igor Skochinsky, in the process of filling, we throw off addresses for me, I will add
Attached filekallsyms_all.zip(2.14 KB)

Adapted utility to build zImage, unfortunately not all formats are parsed / assembled correctly, thanksAnd_pdaandacdev
Attached fileAndImgTool_1_3_0_v3.zip(5.54 MB)


In general, we share information, help each other.

Post has been editedPawill - 19.12.18, 23:59



Rep: (630)
We get the address from the device:
sh -c "echo 0>/ proc / sys / kernel / kptr_restrict "
cat / proc / kallsyms | grep tpd_i2c_probe
cat / proc / kallsyms>/sdcard/symbols.txt

saved in txt
ADB shell su
Attached Image

Blackview: / $ su
su
Blackview: / # sh -c "echo 0>/ proc / sys / kernel / kptr_restrict "
sh -c "echo 0>/ proc / sys / kernel / kptr_restrict "
Blackview: / # cat / proc / kallsyms | grep tpd_i2c_probe
cat / proc / kallsyms | grep tpd_i2c_probe
ffffffc0008492b0 t tpd_i2c_probe
ffffffc000853654 t tpd_i2c_probe
Blackview: / #


Post has been editedDigins - 09.12.18, 11:28



Rep: (630)
Kernel Processing Screens v3.18.35 (Android 7 ARM x64)
LDR - MOV screenshots
looking for from the end of the function
The parser code is prescribed: Edit>Patch program>Change byte "00 00 80 52"
Attached Image

After patch
[I] [B] 00008052 [/ B] [/ I]

Attached Image

Collected TWRP works.

Post has been editedDigins - 09.12.18, 11:33



Rep: (2217)
* Digins,
I would rule the address FFFFFFC000497FB8, because this is the last W0 before exiting
Then this W0 is most likely compared to 2 in the tpd_i2c_probe procedure and either a transition is made or not

# 0x72 - not the correct value, respectively, the "magic Baitik" is also not correct.
Must be
FFFFFFC000497FB8 MOV W0, # 0


Post has been editedPawill - 06.12.18, 21:18



Rep: (630)
PaWill @ 05.12.18, 23:28*
I would rule address FFFFFFC000497FB8

I reigned in TWO places.
PaWill @ 05.12.18, 23:28*
# 0x72 - not the correct value, respectively, "magic Baitik" is also not correct.

"Magic Baitik" is also not correct, but they give the "right honey"
the parser code:
ROM: FFFFFFC000497F84; ================ SUBROUTINE ================================= =====
ROM: FFFFFFC000497F84
ROM: FFFFFFC000497F84; Attributes: bp-based frame
ROM: FFFFFFC000497F84
ROM: FFFFFFC000497F84 get_boot_mode; CODE XREF: mpu6050_unlocked_ioctl_FFFFFFC00041069C: loc_FFFFFFC000410E80p
ROM: FFFFFFC000497F84; rtc_irq_handler: loc_FFFFFFC000432668p ...
ROM: FFFFFFC000497F84
ROM: FFFFFFC000497F84 var_10 = -0x10
ROM: FFFFFFC000497F84 var_s0 = 0
ROM: FFFFFFC000497F84
ROM: FFFFFFC000497F84 ADRP X0, # 0xFFFFFFC0012C4AC8 @ PAGE
ROM: FFFFFFC000497F88 STP X29, X30, [SP, # - 0x10 + var_10]!
ROM: FFFFFFC000497F8C MOV X29, SP
ROM: FFFFFFC000497F90 LDR W1, [X0, # 0xFFFFFFC0012C4AC8 @ PAGEOFF]
ROM: FFFFFFC000497F94 STP X19, X20, [SP, # 0x10 + var_s0]
ROM: FFFFFFC000497F98 CMP W1, # 1
ROM: FFFFFFC000497F9C ADD X20, X0, # 0xFFFFFFC0012C4AC8 @ PAGEOFF
ROM: FFFFFFC000497FA0 B.EQ loc_FFFFFFC000497FC8
ROM: FFFFFFC000497FA4 LDR W0, [X0, # 0xFFFFFFC0012C4AC8 @ PAGEOFF]
ROM: FFFFFFC000497FA8 ADRP X19, # dword_FFFFFFC001084030 @ PAGE
ROM: FFFFFFC000497FAC CBNZ W0, loc_FFFFFFC000497FB8
ROM: FFFFFFC000497FB0 MOV W0, # 0x72
ROM: FFFFFFC000497FB4 BL init_boot_common.part.2
ROM: FFFFFFC000497FB8
ROM: FFFFFFC000497FB8 loc_FFFFFFC000497FB8; CODE XREF: get_boot_mode + 28j
ROM: FFFFFFC000497FB8; get_boot_mode + 7Cj
ROM: FFFFFFC000497FB8 LDR W0, [X19, # dword_FFFFFFC001084030 @ PAGEOFF]
ROM: FFFFFFC000497FBC LDP X19, X20, [SP, # 0x10 + var_s0]
ROM: FFFFFFC000497FC0 LDP X29, X30, [SP + 0x10 + var_10], # 0x20
ROM: FFFFFFC000497FC4 RET
ROM: FFFFFFC000497FC8; -------------------------------------------------- -------------------------
ROM: FFFFFFC000497FC8
ROM: FFFFFFC000497FC8 loc_FFFFFFC000497FC8; CODE XREF: get_boot_mode + 1Cj
ROM: FFFFFFC000497FC8 ADRP X19, # dword_FFFFFFC001084030 @ PAGE
ROM: FFFFFFC000497FCC LDR W3, [X0, # 0xFFFFFFC0012C4AC8 @ PAGEOFF]
ROM: FFFFFFC000497FD0 ADRP X1, #__func__.28202@PAGE; "init_boot_common"
ROM: FFFFFFC000497FD4 ADRP X0, # unk_FFFFFFC000E5B728 @ PAGE
ROM: FFFFFFC000497FD8 ADD X1, X1, #__func__.28202@PAGEOFF; "init_boot_common"
ROM: FFFFFFC000497FDC MOV W2, # 0x72
ROM: FFFFFFC000497FE0 LDR W4, [X19, # dword_FFFFFFC001084030 @ PAGEOFF]
ROM: FFFFFFC000497FE4 ADD X0, X0, # unk_FFFFFFC000E5B728 @ PAGEOFF
ROM: FFFFFFC000497FE8 BL printk
ROM: FFFFFFC000497FEC ADD X2, X20, # 8
ROM: FFFFFFC000497FF0
ROM: FFFFFFC000497FF0 loc_FFFFFFC000497FF0; CODE XREF: get_boot_mode + 78j
ROM: FFFFFFC000497FF0 LDXR W0, [X2]
ROM: FFFFFFC000497FF4 ADD W0, W0, # 1
ROM: FFFFFFC000497FF8 STXR W1, W0, [X2]
ROM: FFFFFFC000497FFC CBNZ W1, loc_FFFFFFC000497FF0
ROM: FFFFFFC000498000 B loc_FFFFFFC000497FB8
ROM: FFFFFFC000498000; End of function get_boot_mode

there is no such code
W0, # 0
and there is such a code
W0, # 0


Post has been editedDigins - 07.12.18, 17:17
Reason for editing: no such code. W0, # 0



Rep: (12)
I have adb shell addresses:
c07e44c4 t tpd_i2c_probe
c07eaf30 t tpd_i2c_probe

After running the cat / proc / kallsyms command>/sdcard/symbols.txt recognized 0xc04ae448 get_boot_mode

But IDA does not find these addresses.
What am I doing wrong?
Kernel Anroid 7.



Rep: (1255)
So ... That's what I’ve dug up by now. Fixed the touch on this device here -UHANS K5000 - Discussion (Post by nemo-nemo # 75394641). More precisely, I was able to assign the value "0" to the variable R0 - everything went correctly. The only question is whether the unpacker correctly unpacked the image. Well, I unpacked it exactly correctly, but the packing ... It seems that it was also successful, the image was going, I gave the person a check, we will wait. So:

1) Maybe I carry nonsense, but the pattern seems obvious to me. Maybe more literate people will then translate it into a scientific form. The fact is that on Linux, when unpacking various images, the kernels are obtained (at least visually) of two types:

Attached ImageAttached Image

Let's call them (purely conditional), respectively, "kernelarchival like "and" kernel ordinary like ". So, under Windows, the" archive "kernel is correctly unpacked and packaged with Mtbootimg . And it starts. So I fixed the touch on my MT6737 device. Via AndImgTools it is also unpacked and packaged, but DOES NOT START, even if the image is simply repacked unchanged.

Further, the "normal kernel" - rather the opposite: it is not even unpacked with pom. MTbootimg, but it is perfectly unpacked and packed with pom. AndImgTools. Moreover, it is not necessary with the help of the fact that in the header - AndImgTool_1_3_0_v3 - I took some of my old AndImgTools, which still works on the principle of "dragging files" onto it. He spat outunpacked Kernel in this form:

AndImgTools
Attached Image
Attached Image

2) In it, the same variable had the name not W0, but R0. I found a search for what those 4 bytes should look like that would correspond to "R0, # 0". BUT! The instructions should definitely specify how to search for this text:

- notMOV R0, # 0 as per instructions
- and notR0, # 0
- and not evenR0, # 0
- but only "R0, # 0 ". I.e,R0 comma space #0 space ! Only in this way - the search engine does not find anything else!

3) So, these 4 bytes are "00 00 A0 E3 "Here it is for them to change the first 4 bytes in a line. This combination should be entered into the" database "instructions for the case of" R0 ".

The wish for the instruction (which, fortunately, is developing and improving) is to specify in which cases the change in the bit depth of the segment to 64, and in which not. Because on my device it was necessary to change, but on the UHANS K5000 - it was not necessary. Here is a misunderstanding.

Here, while I helped as I could.

PaWill @ 12/06/18 13:05*
just the forum engine ate spaces

However, the word "MOV" in the search campaign in any should not be. Tried to search with MOV - did not betray anything. However, if the names of the variables of interest to us are limited to the letters W and R, then it does not matter anymore - the required combinations for replacement are already found: "00 00 80 52" in the case of "W", and "00 00 A0 E3" in the case of "R" .

Post has been editednemo-nemo - 06.12.18, 13:11



Rep: (2217)
srt @ gkq @ 5.12.18, 23:48*
But IDA does not find these addresses.

So say ad. If Ida does not parse the function, then drop the file here:
/sdcard/symbols.txt
I will add the address to kallsyms_all.

Post has been editedPawill - 06.12.18, 13:02



Rep: (2217)
nemo-nemo @ 6.12.18, 9:31*
search engine does not find anything!
just the forum engine ate spaces



Rep: (12)
Addresses like I find my. There is no get_boot_mode function. May not be unpacking this function. Or everything is different in kernel android 7, or in my case it is.
The work indicator, which is at the top of the IDA, is not smoothly blue in my color - which probably still does not unpack the core to the end of the IDA, for its work.
I carried out the unpacking / packing test for interest (without changing the kernel) in AndImgTool_1_3_0_v2 - everything was packed, even in Win 7 x32. Renamed to boot.img, flashed through flashlight - TWRP full functionality.

File symbols.txt add:Attached filesymbols.txt(1.55 MB)


It may be in the instruction of IDA to add screenshots with the parameters recommended, in the windows, when adding a kernel, where there are advanced parameters. Although IDA in general, not for beginners - which I am so :) maybe. I will look, I will try - maybe it will work. With the help of friends onsavagemessiahzine.com, of course.

Post has been editedsrt @ gkq - 06.12.18, 13:38



Rep: (12)
Post the modified kallsyms_all here, please. I'll try it on myself ...



Rep: (2217)
srt @ gkq @ 6.12.18, 13:24*
There is no get_boot_mode function. May not be unpacking this function.
judging by the symbols.txt, the download address in kallsyms_all should be c0100000 (the number from the first line). There is already a current kallsyms_all. Further, in paragraph 3 of the instructions you will most likely have C0008000.
Regarding the change of bit rate. I define by how Ida starts to parse. If you see long lines of numbers at the very beginning, then we change the bit rate. Compare 3 and 6 screenshots instructions.

Post has been editedPawill - 06.12.18, 17:40



Rep: (12)
Guys, if I understand everything correctly, patch in my case need address C04AE448? In symbols.txt this address corresponds to get_boot_mode.
The kallsym_all script does not work, with an error. With bitness everything seems to be fine - I actually use Win 7 x32 now, and the python is installed 2.7.15, x32. Version x64 does not want to take IDA, with the issuance of the error plugin python.p64 (of course in Win 7 x64).

What do I get ...
Before patching:
Attached Image

After patching:
Attached Image

Changed bits:
Attached Image

Did you do everything right?

Post has been editedsrt @ gkq - 06.12.18, 20:07



Rep: (2217)
srt @ gkq @ 06.12.18, 19:48*
Did you do everything right?

not
attach the unpacked kernel or something, it hurts a small piece of code

Post has been editedPawill - 06.12.18, 21:02



Rep: (12)
I found what made a mistake. When adding a kernel to IDA, I specified the starting address from symbols.txt.
Later, he repeated everything again, indicating the starting address of C0008000.
From here and patch it is necessary address РЎ04РђР•464.
Attached Image

Attached Image

TWRP starts, stitched in its section, the touch works. I check its work further.

Post has been editedsrt @ gkq - 06.12.18, 21:41



Rep: (1418)
In fact, a very useful topic created ..
Today I also had to face the core of the stonemtk6580
and if it were not for the last posts I would understand for a long time ... I send thanks to everyone in the form of pluses!

and by the way, this is exactly what recoveries (from 6580-android_7) had to unpack with utilitiesAndImgTool ..but the version that in the header for some reason cannot recover the recovery, even if it does not make any changes ...

Post has been editedLomaster_Serg - 10.12.18, 10:43



Rep: (12)
Lomaster_Serg @ 06.12.18, 22:20*
AndImgTool..but the version that in the header for some reason cannot recover the recovery, even if no changes are made ...

Everything is fine collects. By dragging and dropping the _work folder onto the pack.bat batch file, in Windows Explorer.



Rep: (2217)
srt @ gkq @ 07.12.18, 11:41*
By dragging and dropping the _work folder onto the pack.bat batch file, in Windows Explorer.

just run pack.bat and everything, even dragging is not necessary
Lomaster_Serg @ 06.12.18, 23:20*
The version that in the header for some reason can not be collected back recovery

What error does it write, or better, discard the entire recovery.img

Post has been editedPawill - 07.12.18, 12:17



Rep: (1418)
srt @ gkq @ 7.12.18, 10:41*
By dragging and dropping the _work folder onto the pack.bat batch file, in Windows Explorer.

That's exactly because I have not tried it ...
I would not even guess ... it will be necessary to try


Posted 12/07/2018 12:37 PM:

PaWill @ 7.12.18, 11:15*
just run pack.bat and everything, even dragging is not necessary

That's exactly what I did, but alas ...
Windows 7-64bit
I will throw off the error only in the evening ..
Attached filerecovery.img(16 MB)



Post has been editedLomaster_Serg - 07.12.18, 12:54



Rep: (2217)
Lomaster_Serg @ 06.12.18, 23:20*
but the version that in the header for some reason cannot recover the recovery

the program wrote why not collected
new zImage more original
Attached Image

The fact is thatAndImgTool can't pack unpack_kernel_Image.img (which we successfully pick here) in zImage . For this, a third-party script is used. zimg-packer and then AndImgTool collects the finished image in recovery.img
You compiled with the old, unadjusted zImage

Post has been editedPawill - 07.12.18, 13:05



Rep: (630)
PaWill @ 05.12.18, 23:28*
# 0x72 - wrong value

I changed the post there, please comment.


Full version    

Help     rules

Time is now: 25/08/20, 8:22