Database Users

Need help extracting files from ETEN M600 ROM

Okay, so I've tried everything. PDOCREAD, DUMPROM, pget, grab_it, testdump.exe, FiziFetch. I need help with getting at all of the files and doing a complete ROM dump of the device. The only ROM Dump I have is the one that ETEN provides for upgrading the phone, I have attached that here. EUU.exe is the exe you run on the pc, and normally the rom file is called temp.dat, and it uses the other .exe which is compiled for windows ce to the phone to do the updating process.
Any help here would be greatly appreciated. In particular I want btagext.dll in the /Windows directory and full instructions on how to do it myself for other protected files.
The ROM can be obtained by going to updates.eten.ch and downloading the latest English ROM file for the M600. The direct link is here:
ftp://support.com:[email protected]/Download/Updates/M600/ENG/EUU_M600_WWE_R01_100_0171.EXE
To get the ROM file and the update file, goto your documents and settings/profile name/local settings/temp folder and clear out all the files.
Run the .exe you downloaded from above, and then look in the temp folder you just cleared. You should see a temp.dat which is the ROM file, EUU.exe which is the file that facilitates the transfer of the file to the ETEN M600 and another file USBDLUpdate_Console.exe which is a windows CE compiled file that facilitates the flashing process in some way.
Pdocread part of the itsutils is able to read see some of the information on my device:
pdocread –l lists the following:
122.19M FLASHDR
| 1.03M Part00
| 1.52M Part01
| 33.98M Part02
| 85.47M Part03
1.89G DSK1:
| 1.89G SD
STRG handles: a34cc21e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.89G) e3b41b8a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 85.47M) e3b4153e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 33.98M) 83b41436
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.52M) a3b412be
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
( 1.03M)
However it is not able to do anything other then that. All attempts at trying to access those partitions or device (flashdr) fail with errors such as these (this is just a small list of commands command options i've tried):
C:\itsutils\build>pdocread -d DSK1
ERROR: ITTFFSGetInfo - The handle is invalid.
C:\itsutils\build>pdocread -d DSK1:
ERROR: ITLogDiskInfo - An exception occurred in the service when handling the co
ntrol request.
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C:\itsutils\build>pdocread 0x0 0x200 foo.bin
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CopyTFFSToFile(0x0, 0x200, foo.bin)
ERROR: ITReadDisk - An internal error occurred.
C:\itsutils\build>pdocread -o -p part03
ERROR: ITTFFSGetInfo: outbuf==NULL
WARNING: using default 512 bytes for sectorsize
C:\itsutils\build>pdocread -d FLASHDR -w
ERROR: ITTFFSGetInfo - The handle is invalid.

Re: Need help extracting files from ETEN M600 ROM will pay $
I don't think that you'll be able to get a working dump of btagext.dll or any other system DLL. It does not have relocation information.
temp.dat in eten upgrade is in some strange format, it seems that data blocks are mixed.
What is the result of testdump.exe? I've attached the WM5 build of this program.

Re: Need help extracting files from ETEN M600 ROM will pay $
I've tried that before. That just dumps some information that is in memory. You can see calendar information, contact information, etc. If you put in 128mb which is the ROM size, it says DUMP OK this time (it had filesys errors the time I tried it a couple weeks ago) See here:
http://www.eten-users.net/topic1085
Anyways, in the end it dumps a 64 meg file instead of the 128 you specified, which is just the stuff in memory the 64 megs of RAM that this thing is suppose to have. If you use romdump on that file it doesn't get to many files, just about 30 or so and none of them are very important (most you can get via windows explorer and activesync)
FB

Re: Need help extracting files from ETEN M600 ROM will pay $
why do you think that eten has 128Mb OS ROM? It has only 48Mb ROM, other is left to persistent storage. So these tools would never dump full 128Mb, only 64Mb max.
You should upload somewhere the output of testdump tool, so I can look at it. It should produce _correct_ ROM dump. You just cannot extract files from it correctly. "dumprom" is for older oses, and with "-5" switch it would extract only files from XIP section (about 20 files). Use my "viewimgfs" tool to get everything from IMGFS.

I looked in the control panel, you are right it appears that the system part takes up about 48 mb, with the rest of the 128mb as user storage. It's kind of wierd though that testdump would stop at 64mb, wouldn't it stop at 48mb instead? If not why is it not doing the full 128 mb.
I tried what you had suggested and unfortunately that doesn't work either. I dumped a 64mb image, and a 48mb image. viewimgfs.exe didn't work on those images. I tried prepimgfs on the 48mb one and it couldn't find imgfs start location. I tried it on the 64mb one and it found it but the resulting file was about 256kb with a 4kb "removed_data" file which is definately not right.
I tried it without first running prepareimgfs and it just says "unable to load compress .dll".
I can't send a rom dump of what I have yet as it contains all of my contacts and calender information in looking at the memory dump in a hex editor, I'll have to whip the device clean again and I can send one but that may take awhile, i've got a lot of stuff setup right now.
Any other suggestions?

I found another bit of information. I played around with MTTY, which I know is for HTC devices, just to see what it would do though I thought I would try. It connects to the bootloader, however you never get to a command prompt. It appears that i can send a command, but then it trys to just download a file (the updated ROM). So I'm not sure if anything else can be done with this, I was hoping I could do something like "d2s" but it appears that with MTTY that doesn't seem possible.
I'm wondering if there is some way to map a USB port to a COM port so I can use regular hyperterminal. Does anyone know how to do this as Hyperterminal only supports COM ports...

MTTY is identical to hyperterminal

Ahh okay, it must be that they haven't implemented a nice interface like HTC devices where you can issue all of those commands

Hi!
Until now can you dump it? I can help you dump....
PM me,OK?

Okay, so i've finally been able to get these files from Vijay, however I'm still running into issues as describe here:
http://www.eten-users.net/topic1500
Anyone have any information on how to reconstruct PE files?

how to restore original OS to my Polaris

i need send my polaris to HTC for repair, so i need restore original ROM.
before i flash coke rom, i dump original rom.
dump rom log
===========================
C:\itsutilsbin-20080602>pdocread.exe -l
211.00M (0xd300000) FLASHDR
| 3.12M (0x31f000) Part00
| 4.63M (0x4a0000) Part01
| 89.75M (0x59c0000) Part02
| 113.50M (0x7180000) Part03
7.61G (0x1e6e80000) DSK1:
| 7.60G (0x1e6a80000) Part00
STRG handles:
handle 65cb4f5e 7.60G (0x1e6a80000)
handle 4747afde113.50M (0x7180000)
handle e749a586 89.75M (0x59c0000)
handle 8749a552 4.63M (0x4a0000)
handle 8749a392 3.12M (0x31f000)
disk 65cb4f5e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 4747afde
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk e749a586
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 8749a552
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 8749a392
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C:\itsutilsbin-20080602>pdocread -w -d FLASHDR -b 0x800 -p Part00 0 0x31f000 Par
t00.raw
CopyTFFSToFile(0x0, 0x31f000, Part00.raw)
C:\itsutilsbin-20080602>pdocread -w -d FLASHDR -b 0x800 -p Part01 0 0x4a0000 Par
t01.raw
CopyTFFSToFile(0x0, 0x4a0000, Part01.raw)
C:\itsutilsbin-20080602>pdocread -w -d FLASHDR -b 0x800 -p Part02 0 0x59c0000 Pa
rt02.raw
CopyTFFSToFile(0x0, 0x59c0000, Part02.raw)
C:\itsutilsbin-20080602>pdocread -w -d FLASHDR -b 0x800 -p Part03 0 0x7180000 Pa
rt03.raw
CopyTFFSToFile(0x0, 0x7180000, Part03.raw)
C:\itsutilsbin-20080602>
=================================
now, i have 4 raw files
i try to follow below guide
The reverse process is:
'dump' directory ---(ImgfsFromDump)---> imgfs-new.bin ---(ImgfsToNb)--->
OS-new.nb.payload ---(NBMerge)---> OS-new.nb ---(*NBHGen)--->
RUU-signed-new.nbh
(The tools marked with '*' are not part of the ImgfsTools, but are also available for free from xda-developers.com. There is also one additional tool, NBInfo, in this package.) in post http://forum.xda-developers.com/showthread.php?t=298327
i rename the 4 raw files to bin then run ImgfsFromDump.exe but i get below err
C:\ImgfsTools 2.1rc2>ImgfsFromDump.exe Part00.bin Part00-new.bin
ImgfsFromDump 2.1rc2
Compression DLL does not support compression type ''!
any bros know what is the problem.

Try this one
http://forum.xda-developers.com/showthread.php?t=337066
Point 3!
Note:
Compatible with polaris, but at the and of the process, in HTC Rom tool you have to write POLA***** not KAIS*****
Of course, you have to use a Polaris base rom....
(With this I succesfully reconstruced the 1.28.457.2 dumped polaris rom)

i also try to follow jcespi2005 guide http://forum.xda-developers.com/showthread.php?t=337066
but not success

fktsndr said:
http://forum.xda-developers.com/showthread.php?t=337066
Point 3!
Note:
Compatible with polaris, but at the and of the process, in HTC Rom tool you have to write POLA***** not KAIS*****
Of course, you have to use a Polaris base rom....
(With this I succesfully reconstruced the 1.28.457.2 dumped polaris rom)
Click to expand...
Click to collapse
Thx, i will try again.

fktsndr said:
http://forum.xda-developers.com/showthread.php?t=337066
Point 3!
Note:
Compatible with polaris, but at the and of the process, in HTC Rom tool you have to write POLA***** not KAIS*****
Of course, you have to use a Polaris base rom....
(With this I succesfully reconstruced the 1.28.457.2 dumped polaris rom)
Click to expand...
Click to collapse
Hi fktsndr,
according jcespi2005
3. Download the modified version by Alex of Kaiser Kitchen here, that allows to reconstruct the ROM from the dump. The Kaiser Kitchen allows to cook a ROM from a dumped one and from base NBH shipped one. You need to put the NBH file from the step before in the BaseROM folder, and put the RAW files too. Then execute the KAISERKITCHEN.CMD and choose the next options from the menu it this order:
could u tell where i can get the NBH file?

scholescheng said:
Hi fktsndr,
according jcespi2005
3. Download the modified version by Alex of Kaiser Kitchen here, that allows to reconstruct the ROM from the dump. The Kaiser Kitchen allows to cook a ROM from a dumped one and from base NBH shipped one. You need to put the NBH file from the step before in the BaseROM folder, and put the RAW files too. Then execute the KAISERKITCHEN.CMD and choose the next options from the menu it this order:
could u tell where i can get the NBH file?
Click to expand...
Click to collapse
Download the offical base rom:
http://rapidshare.com/files/9162747....1_radio_sign_25.65.30.04_1.58.21.23_Ship.rar
Extract it, you will find an RUU_Signed.NBH file.

Or you just flash the Rom from link above, if you send your polaris for service they dont know what rom you had in your device? right

Or ask the HTC Cutstomer Service to send the rom you have.
An xda-user, Uton did this, and he got the 1.28.457.2 rom.

omaga said:
Or you just flash the Rom from link above, if you send your polaris for service they dont know what rom you had in your device? right
Click to expand...
Click to collapse
my polaris is CHT ROM when i bought it. so i need flash back to CHT version.

my polaris hold on this screen
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
hi all bros, any comment

scholescheng said:
my polaris hold on this screen
hi all bros, any comment
Click to expand...
Click to collapse
lol.........

reyjabs said:
lol.........
Click to expand...
Click to collapse
We got your point, but why the FULL QUOTE all the time...in every thread..??

I burn Polaris Project 0.3 Vanilla or the Polaris_WWE_0.67_Premium_bepe and then burned the original RUU_Polaris_HTC_WWE_1.25.405.1_radio_sign_25.65.30.04_1.58.21.23_Ship ROM and UDK screen disappear.

http://forum.xda-developers.com/showthread.php?t=405903&page=2
Post nr 13.. flash that !

omaga said:
http://forum.xda-developers.com/showthread.php?t=405903&page=2
Post nr 13.. flash that !
Click to expand...
Click to collapse
how to flash???

reyjabs said:
lol.........
Click to expand...
Click to collapse
what is your means?

sagytb said:
I burn Polaris Project 0.3 Vanilla or the Polaris_WWE_0.67_Premium_bepe and then burned the original RUU_Polaris_HTC_WWE_1.25.405.1_radio_sign_25.65.30.04_1.58.21.23_Ship ROM and UDK screen disappear.
Click to expand...
Click to collapse
my polaris can not boot to windows. how can i flash other rom???
could you hlep???

i also try flash rom using micro sd card http://forum.xda-developers.com/showthread.php?t=384084 , but not work.
hold on this screen

Take a deep breath my friend - things may not be as bad as they seem.
Maybe you need to do some more reading and less writing?
Take a look at this: http://forum.xda-developers.com/showthread.php?t=381600
Might provide you with the answer to your problem.
Good luck !

cr1960 said:
Take a deep breath my friend - things may not be as bad as they seem.
Maybe you need to do some more reading and less writing?
Take a look at this: http://forum.xda-developers.com/showthread.php?t=381600
Might provide you with the answer to your problem.
Good luck !
Click to expand...
Click to collapse
Thx bro, i have read this post long long time ago.
but i just want to konw how to flash my brick!!!!

Jelly-scrolling Kernel test

Browsing through the kernel source, I got very curious about the flag "qcom,mdss-dsi-panel-inverted" being commented out in this file:
https://github.com/OnePlusOSS/andro...qcom/dsi-panel-samsung_s6e3fa5_1080p_cmd.dtsi
Could an experimented kernel builder create a kernel with this flag enabled, and check if the refresh direction of the panel changes, or the jello effect is diminished ?
I don't want to unlock my bootloader just yet

Hmmm.... Interesting...

maybe we will end up with a 180° inverted display.

Watching the thread

paratox said:
maybe we will end up with a 180° inverted display.
Click to expand...
Click to collapse
That is easy to fix in software though The HW is a *****

This flag is not in the documentation, it is not mentioned anywhere else in the kernel source, only oneplus devices have it in their source. For the prop to actually be readable it needs to be recognized in other parts of the kernel like this.
So, at best, the device will boot with no changes because the flag won't be recognized.

Flar2 mentioned that this change doesn't impact jelly affect...

ram4ufriends said:
Flar2 mentioned that this change doesn't impact jelly affect...
Click to expand...
Click to collapse
nah he just said "It doesn't seem to make any difference"
and the second response is "I'm not sure. I think if it was easily fixed, OnePlus would fix it in an update."
thats all

dukat0s said:
nah he just said "It doesn't seem to make any difference"
and the second response is "I'm not sure. I think if it was easily fixed, OnePlus would fix it in an update."
thats all
Click to expand...
Click to collapse
Which means that flag fix didn't work, isn't it?

ram4ufriends said:
Which means that flag fix didn't work, isn't it?
Click to expand...
Click to collapse
? what " flag fix" u talking about ? : >

ram4ufriends said:
Which means that flag fix didn't work, isn't it?
Click to expand...
Click to collapse
I know what you mean and no, it didn't work.

ZakooZ said:
This flag is not in the documentation, it is not mentioned anywhere else in the kernel source, only oneplus devices have it in their source. For the prop to actually be readable it needs to be recognized in other parts of the kernel like this.
So, at best, the device will boot with no changes because the flag won't be recognized.
Click to expand...
Click to collapse
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
Code:
.1 .2 .3 .4 .5 .6 .7 .8 .9 # decode of byte .8
#=============================================
05 01 00 00 14 00 02 11 00 # DCS exit_sleep_mode
15 01 00 00 00 00 02 35 00 # DCS set_tear_on
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 B0 04 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 04 B4 06 0C 12 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
15 01 00 00 00 00 02 53 20 # ?? undocumented
15 01 00 00 00 00 02 55 00 # ?? DCS_WRITE_CABC
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 C3 01 # ?? undocumented
39 01 00 00 00 00 02 B0 18 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 02 C3 00 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
05 01 00 00 00 00 02 29 00 # DCS set_display_on
In the MIPI DCS specification, one can control the Device Line Refresh Order:
1155 Bit B4 – Display Device Line Refresh Order
1156 This bit controls the display device’s horizontal line refresh order. The image shown on the display device
1157 is unaffected, regardless of the bit setting.
1158 ‘0’ = Display device is refreshed from the top line to the bottom line
1159 ‘1’ = Display device is refreshed from the bottom line to the top line
Click to expand...
Click to collapse
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Code:
15 01 00 00 00 00 02 36 10
or
Code:
15 01 00 00 00 00 02 36 00
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?

ddalex said:
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
In the MIPI DCS specification, one can control the Device Line Refresh Order:
1155 Bit B4 – Display Device Line Refresh Order
1156 This bit controls the display device’s horizontal line refresh order. The image shown on the display device
1157 is unaffected, regardless of the bit setting.
1158 ‘0’ = Display device is refreshed from the top line to the bottom line
1159 ‘1’ = Display device is refreshed from the bottom line to the top line
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
15 01 00 00 00 00 02 36 10 or
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
Click to expand...
Click to collapse
Interesting. I could only recommend you to try to get in touch with @flar2 - Dev of the EX kernel. He might be eventually able to do some experiments (as he already did with "inverted" command).

ddalex said:
Fair enough, I didn't check whenever this symbol is further referenced. Moreover, in MIPI DCS language, 'inverted' refers to 'color-inverted' display, not 'orientation-inverted'.
So I got curious, and took the DTSi file for the panel and the patch to enable the closely related S6E3FA0 panel on Exynos (never made it upstream), and decoded the `qcom,mdss-dsi-on-command` sequence, since it seems the best place to insert a command to rotate the display, if it exists; my decoding is below (references https://www.tonylabs.com/wp-content/uploads/MIPI_DCS_specification_v1.02.00.pdf)
Code:
.1 .2 .3 .4 .5 .6 .7 .8 .9 # decode of byte .8
#=============================================
05 01 00 00 14 00 02 11 00 # DCS exit_sleep_mode
15 01 00 00 00 00 02 35 00 # DCS set_tear_on
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 B0 04 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 04 B4 06 0C 12 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
15 01 00 00 00 00 02 53 20 # ?? undocumented
15 01 00 00 00 00 02 55 00 # ?? DCS_WRITE_CABC
39 01 00 00 00 00 03 F0 5A 5A # MCS_KEY_LEV1
39 01 00 00 00 00 02 C3 01 # ?? undocumented
39 01 00 00 00 00 02 B0 18 # MCS_GLOBAL_PARAMETER
39 01 00 00 00 00 02 C3 00 # ?? undocumented
39 01 00 00 00 00 03 F0 A5 A5 # MCS_KEY_LEV1
05 01 00 00 00 00 02 29 00 # DCS set_display_on
In the MIPI DCS specification, one can control the Device Line Refresh Order:
Things I would try:
Find Samsung references for the display controller so we can find the undocumented commands below
Use command DCS set_address_mode 36h to flip the display: insert before the last line:
Code:
15 01 00 00 00 00 02 36 10
or
Code:
15 01 00 00 00 00 02 36 00
and see what we get on display and if we can change the refresh direction. In worst case, we need to try all values from 00 for FF for the last byte in the command.
Anybody with a unlocked bootloader and time to recompile the kernel to test this ?
Click to expand...
Click to collapse
This looks correct. I wondered about this but couldn't find a DCS spec sheet.
Could you specify what 15 01 does? Put the device into command mode or something?
Looking at the command documentation these bytes '#9' could be useful:
0x10 - scan from bottom to top (top to bottom in reality)
0x04 - latch from right to left (left to right in reality) (reverses tilt of the active scan line)
0x14 - combine previous 2
There are 2 problems that can come out of this:
1. The panel itself just doesn't support setting these bits and will just ignore them
2. "qcom,mdss-dsi-panel-orientation" might actually call that same command after qcom,mdss-dsi-on-command and override the settings we added in. This would show the same symptoms as problem 1), nothing would change in the display. I've been looking at the dsi panel init source code but it's a bit of a rabbit hole so I don't know if this is the case. Luckily the code is full of debug prints, so it is relatively easy to enable them and see what is actually happening in the dmesg.

who's gonna try this then ?

ZakooZ said:
This looks correct. I wondered about this but couldn't find a DCS spec sheet.
Could you specify what 15 01 does? Put the device into command mode or something?
Click to expand...
Click to collapse
Each line in there is a MIPI DCS packet - first byte is the packet type, with the defines below
Code:
/* dcs read/write */
#define DTYPE_DCS_WRITE 0x05 /* short write, 0 parameter */
#define DTYPE_DCS_WRITE1 0x15 /* short write, 1 parameter */
#define DTYPE_DCS_READ 0x06 /* read */
#define DTYPE_DCS_LWRITE 0x39 /* long write */
The complete header definition is:
Code:
struct dsi_ctrl_hdr {
char dtype; /* data type */
char last; /* last in chain */
char vc; /* virtual chan */
char ack; /* ask ACK from peripheral */
char wait; /* ms */
short dlen; /* 16 bits */
} __packed;
After the header, the payload follows directly.
ZakooZ said:
Looking at the command documentation these bytes '#9' could be useful:
0x10 - scan from bottom to top (top to bottom in reality)
0x04 - latch from right to left (left to right in reality) (reverses tilt of the active scan line)
0x14 - combine previous 2
Click to expand...
Click to collapse
Yep, we need to test these - the problem is that we don;t know if there is another piece of code that resets this flag after the initial init, you correctly touch on this below.
ZakooZ said:
There are 2 problems that can come out of this:
1. The panel itself just doesn't support setting these bits and will just ignore them
2. "qcom,mdss-dsi-panel-orientation" might actually call that same command after qcom,mdss-dsi-on-command and override the settings we added in. This would show the same symptoms as problem 1), nothing would change in the display. I've been looking at the dsi panel init source code but it's a bit of a rabbit hole so I don't know if this is the case. Luckily the code is full of debug prints, so it is relatively easy to enable them and see what is actually happening in the dmesg.
Click to expand...
Click to collapse
Or, possible but not probable outcome no. 3: the HUT (Hardware Under Test) is damaged by this testing
:victory:

That flag is shipped in this commit: https://github.com/MoKee/android_ke...mmit/7ca61f58d8b59a4ae716e08405df8368a45407fb
As I am a Chinese, this commit message indicates the screen is upside-down. This flag is not as others say, only see in Oneplus devices. It is a flag introduced by CAF, to support
upside-down screens: https://github.com/MoKee/android_ke...mmit/63203b502ef862f756535e080c4261031eb4110f. Further research shows that it actually does is to make the display oriented: https://github.com/MoKee/android_ke...f9e1a022ef5/include/uapi/linux/msm_mdp.h#L254.
Oneplus seems to take entire CAF solution in kernel. But actually it is something besides than kernel. But I doubt there is something in closed-source vendors as well (third-party roms still have this effect).

aviraxp said:
That flag is shipped in this commit: https://github.com/MoKee/android_ke...mmit/7ca61f58d8b59a4ae716e08405df8368a45407fb
As I am a Chinese, this commit message indicates the screen is upside-down. This flag is not as others say, only see in Oneplus devices. It is a flag introduced by CAF, to support
upside-down screens: https://github.com/MoKee/android_ke...mmit/63203b502ef862f756535e080c4261031eb4110f. Further research shows that it actually does is to make the display oriented: https://github.com/MoKee/android_ke...f9e1a022ef5/include/uapi/linux/msm_mdp.h#L254.
Oneplus seems to take entire CAF solution in kernel. But actually it is something besides than kernel. But I doubt there is something in closed-source vendors as well (third-party roms still have this effect).
Click to expand...
Click to collapse
Yes, but we don't need to reverse the screen, we need to set the inverse refresh.
Inviato dal mio ONEPLUS A5000 utilizzando Tapatalk

robertogl said:
Yes, but we don't need to reverse the screen, we need to set the inverse refresh.
Click to expand...
Click to collapse
I referenced above the Display Line Refresh Order option on the MIPI DCS standard set_address_mode option, that maybe could inverse the refresh. We need somebody to build the kernel with the command added in the DTSi file, and test it. Maybe @Sultanxda ?

Someone really should try this :0
Sent from my SM-A510M using Tapatalk

VS995 - Error using Uppercut - Cannot decide device boot mode. set Unknown Mode

I recently acquired a Verizon-branded LG V20 (VS995) and I my eventual goal is to put TWRP and LineageOS on it like my last phone. The first step is to downgrade it to a vulnerable stock image using UPPERCUT. However, I'm finding that LGUP is unable to begin to perform the flash.
My setup/procedure is as such:
1. Fresh Windows 7 x64 installation in Virtualbox 5.2.16 on Arch Linux
1a. USB filter setup so that USB 1004:633a is always passed through to Windows 7
2. Installed drivers: LGMobileDriver_WHQL_Ver_4.2.0.exe
3. Installed LGUP 1.14: LGUP_Store_Frame_Ver_1_14_3.msi
4. Insert battery into LG V20 VS995
5. Insert USB into computer
6. Hold VOLUP while inserting USB-C into V20
7. Wait as "download mode" message appears and then changes to "Firmware Update" screen.
8. Wait for Windows to install all drivers, ensuring devmgmt.msc shows COM port
9. Launch UPPERCUT v1.0.0.0, granting admin permissions
10. Wait for LGUP to launch, initialize, and show a VS9951CA device
11. Select the December 2016 KDZ: VS99512A_06_1114_ARB00.kdz
12. Select UPGRADE and hit Start
After waiting for the 15 second initialization period, LGUP displays the error "Cannot decide device boot mode. set Unknown". If left in this state for several minutes, LGUP will eventually bring up a dialog saying "Error: 0x2000, Port open error (COMX)". LGUP sometimes says it is on a step which I have not transcribed correctly but resembles "_prepareAndDL" before showing the "Cannot decide device boot mode. set Unknown" error, but I've only seen this step once or twice.
SHA1 sums of the files I'm using:
eac54e3e0cfe6e8d7cd395e245170e13de4fcd67 lgmobiledriver_whql_ver_4.2.0.exe
f7b41f77047698bc8e030dddf4ef6fbdb5c3af41 lgup_store_frame_ver_1_14_3.msi
46c9a349d62287d81c94ce7148233c0922604273 uppercut_1.0.0.0.zip
3104b93b7243e3274932b2c56b8383cdecf7ede3 vs99512a_06_1114_arb00.kdz
Is UPPERCUT still the recommended tool to flash stock firmware for this model? Should I be installing it via fastboot instead (if so, is there a thread to follow)? Is the 1CA update no longer downgradable?
--------------------
I tried to use the patched LGUP tool instead of UPPERCUT to see if that helped at all. I did not try to flash the KDZ, but rather just tried to DUMP the existing partitions. I ran into the same error as the post title again.
Procedure:
0. In the LGUP program files directory:
1. Copy the original LGUP.exe to LGUP.original.exe
2. Copy the patched LGUP.exe into it's place
3. Copy in the 'model/common' directory from the patched LGUP zip
4. Steps 4->8 from above
9. Launch patched LGUP (no UPPERCUT)
10. Same as above
11. Select DUMP, hit start, select dump location
SHA1 sum of additional files:
242640ddb023308b9a103e0a767f27511c9a2db0 lgup_v20dll_patched.zip

I captured a trace of the USB communication with wireshark. I used the LG LAF protocol plugin (can't post links yet: github com/Lekensteyn/lglaf/blob/master/lglaf.lua) and it didn't find any USB frames that matched the protocol. I'm no USB wire protocol expert, but it looks like the phone is sending a response:
Code:
0000 1b 00 10 b0 62 03 80 fa ff ff 00 00 00 00 09 00 ...°b..úÿÿ......
0010 01 02 00 01 00 83 03 97 00 00 00 ef a0 00 00 00 ...........ï*...
0020 00 00 56 53 39 39 35 00 00 00 00 00 56 53 39 39 ..VS995.....VS99
0030 35 31 43 41 00 00 00 00 00 00 00 00 00 00 00 00 51CA............
0040 00 00 00 00 00 00 00 00 00 00 01 33 35 39 39 36 ...........35996
0050 38 30 37 32 39 39 39 30 37 36 00 00 00 00 00 60 8072999076.....`
0060 1e 41 6e 64 72 6f 69 64 00 00 00 37 2e 30 00 00 .Android...7.0..
0070 00 00 00 00 00 3X 3X 3X 3X 3X 3X 3X 3X 3X X9 00 .....XXXXXXXXXX.
0080 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 31 63 6f 6d 6d 6f 6e 00 00 00 ......1common...
00a0 56 5a 57 31 00 00 00 00 00 00 00 00 00 00 7d 5d VZW1..........}]
00b0 86 7e .~
There were five such frames, all essentially identical less a byte or two. I suspect if I had let the capture go they would have continued to arrive at an interval. So it's possible the LGUP tool just is not recognizing the ping that the phone is sending?

Install the VirtualBox extension pack and set your USB config for that VM to 2.0 or 3.1, and you should be good.
1CA is definitely downgradable. This is a USB communication problem.
-- Brian

I re-confirmed that I had the guest extensions installed (VM has no nic and all files were transferred in via shared folders, which requires guest extensions). But it turns out I did have the USB bus set to USB 2.0. After setting that to USB 3.0 and installing the Intel USB3 drivers for Windows, LGUP started the download without issue. This is still the patched LGUP (no UPPERCUT) and using the UPGRADE option with the KDZ mentioned in the OP. Oddly enough, it did not clear my data, as it asked for my encryption passphrase when it rebooted. It did successfully downgrade me, so I just did a factory reset to clear my old data and apps. As a reminder, the LG out-of-the-box experience starts checking for OTA updates as soon as the phone starts up, so remove your SIM before you start.
1. Remove SIM
2. Do one of the following:
CLI:
Code:
vboxmanage modifyvm $vmname --usbehci off && vboxmanage modifyvm $vmname --usbxhci on
UI: Right click VM > Settings > USB > USB 3.0 (XHCI) Controller

Root with CVE-2019-2215?

Anyone have any luck running [the poc exploit](https://forum.xda-developers.com/ga...ompiled-executed-zero-day-exploitcve-t3978059) for CVE-2019-2215 on an Oreo LG V20? It's listed as one of the affected devices in the news reports. I'd love to get even a temp root.
For me (LS997) the poc stops with writev returning 0x1000 (it should return 0x2000 if the poc is working).
I have played around with the poc.c source code and noticed that if I change WAITQUEUE_OFFSET to 0x90, the device crashes and reboots. Since an untrusted app isn't supposed to be able to reboot a device, this suggests that there may be an exploitable thing around there somewhere.

Looking at the kernel source on the LG site (at least for the LS997), the LGV20 does have the bug in the kernel. However, the LGV20's kernel has a different layout of struct binder_thread than the version of the kernel the poc is designed for. And unfortunately it's not just a trivial fix, because the poc assumes the waitqueue field is 16-byte aligned, while on the LGV20 it's only 8-byte aligned (because there is one less field in the struct). There is probably a way around this, but I am not good at this sort of stuff: I don't really understand how the poc works. If anybody here does, maybe we can pool our minds and work together.

arpruss said:
Looking at the kernel source on the LG site (at least for the LS997), the LGV20 does have the bug in the kernel. However, the LGV20's kernel has a different layout of struct binder_thread than the version of the kernel the poc is designed for. And unfortunately it's not just a trivial fix, because the poc assumes the waitqueue field is 16-byte aligned, while on the LGV20 it's only 8-byte aligned (because there is one less field in the struct). There is probably a way around this, but I am not good at this sort of stuff: I don't really understand how the poc works. If anybody here does, maybe we can pool our minds and work together.
Click to expand...
Click to collapse
what is the waitqueue offset in the binder_thread struct in your kernel?

chompie1337 said:
what is the waitqueue offset in the binder_thread struct in your kernel?
Click to expand...
Click to collapse
0x98=152, assuming the kernel source I downloaded is correct and assuming I counted all the fields right. Here is my count (counting 64-bits at a time):
Code:
struct binder_thread {
struct binder_proc *proc; // 1
struct rb_node rb_node; // 4
struct list_head waiting_thread_node; // 6
int pid;
int looper; /* only modified by this thread */ // 7
bool looper_need_return; /* can be written by other thread */ // 8
struct binder_transaction *transaction_stack; // 9
struct list_head todo; // 11
struct binder_error return_error; // 15
struct binder_error reply_error; // 19
wait_queue_head_t wait; // spinlock_t + list_head
struct binder_stats stats;
atomic_t tmp_ref;
bool is_dead;
struct task_struct *task;
};

hmm. i see what you mean by alignment now.
this define
Code:
#define IOVEC_ARRAY_SZ (BINDER_THREAD_SZ / 16) //25
makes me believe that the size of iovec_array[ IOVEC_ARRAY_SZ] defined on line 75, has to equal size of struct binder_thread this is because somehow, the contents iovec_array overwrites the contents of a binder_thread structure. which means, that iovec_array[IOVEC_INDX_FOR_WQ] should contain the contents of binder_thread->wait.
wait_queue_head is defined as:
Code:
struct wait_queue_head {
spinlock_t lock;
struct list_head head;
};
meaning you have to make sure that the values in iovec_array[IOVEC_INDX_FOR_WQ] correspond correctly to the wait_queue_head but also line up so the writev works. there's definitely some trickery you could do to make this work. my first thought is you know that &iovec_arrary[9].len (offset 0x98) should point to values that make sense for a wait_queue_head struct. i'm working on understanding this better, though.

don't you guys think that 0xDEADBEEFs should go away before this so-called poc start working? any ideas on that one?

GoofMan69 said:
don't you guys think that 0xDEADBEEFs should go away before this so-called poc start working? any ideas on that one?
Click to expand...
Click to collapse
that's where the use after free bug should come in.
Code:
ioctl(binder_fd, BINDER_THREAD_EXIT, NULL);
when this is called, the binder_thread structure is freed in the kernel.
immediately after the parent process calls,
Code:
b = writev(pipefd[1], iovec_array, IOVEC_ARRAY_SZ);
in the kernel, memory is allocated to copy over iovec_array from userspace. this poc depends on the pointer from this allocation, to be the same as the recently freed binder_thread memory.
then, when the child process exits, the EPOLL cleanup will use the waitqueue in the binder_thread structure, that has been overwritten with the values in iovec_array. when EPOLL cleanup unlinks the waitqueue, 0xDEADBEEF will get overwritten by a pointer in kernelspace. this has to happen just before the writev call in the parent process starts to copy over the second buffer, which gets us a kernel space memory leak.
if writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.

One simplifying issue is that with Kernel 3.18, we don't have KASLR, so we don't need to leak the kernel address. Hence the first part of the poc is unnecessary, assuming we can get the addresses.
Are there any rooted LGV20 variants using the 3.18 kernel? If so, it might help if someone with one of these were to post a copy of /proc/kallsyms

try
lg q710 kernel 3.18
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

chompie1337, thank you for such detailed description.
So, child must exit and epoll-cleanup code should be done to the time when parent's writev() starts to copy 2nd buffer (as you say, 0xdeadbeef will be replaced by that time). But there's a sleep(2) in the child. Do you think it is appropriate? Hardly it'll take writev 2s to copy first buffer, maybe 2ms or smth?
Also, why does child call epoll_ctl(EPOLL_CTL_DEL)? Isn't it a thing, that we should NOT do for the bug to come in?

From reading the poc, it looks like deleting the event from the epoll queue, after the binder thread has terminated, (somehow) causes the pointer wq->task_list->prev to have the value &(wq->task_list->next). If the kernel allocates its copy of the iovec array in the same place as the old binder_thread structure was, the wq->task_list->prev pointer will fall in an iov_base location in the array, and hence an iov_base will get overwritten. Moreover, the poc ensures this happens AFTER the kernel has checked that the iovec is one the user has permission to use for reading or writing. In the clobber function, then, the epoll event deletion makes the iov_base point to a position in the kernel heap--indeed, inside the kernel's pre-checked copy of the iovec array--which the poc leverages to write data to any location the kernel has access to (by first rewriting the next little bit of the pre-checked iovec array).
Unfortunately, with the 3.18 kernel, the event deletion causes a value to be written to an iov_len location in the iovec array, which allows one to change the amount of data being written but not the location being written to. This is good enough for crashing the device and probably for leaking a lot of data, but I have not been able to figure out how to use it for rooting.
If the kernel could be manipulated to allocate its copy of the iovec array 8-bytes further down in the heap, that would solve the problem, but I don't know if it can be done: I don't think the kmalloc-512 allocator will do that. But I could be wrong. Otherwise, I think one needs some other technique than the readv/writev trick used in the poc.
I am, unfortunately, quite new to this kind of thing. An experienced kernel hacker can probably see in an instant what to do.

I'm not sure the PoC crash is entirely because of the kernel version. My device (not the V20, just here to cooperate to develop the exploit) has kernel version 4.4 but it crashes at the first EPOLL_CTL_DEL. Where does the V20 crash when you change the WAITQUEUE_OFFSET?

Oh, I see... So writev would block after writing first dummy_page_4g_aligned of length 0x1000, because pipe's queue is full (pipe size is also 0x1000). So there isn't actually any timing tweak required, right?
Btw, i've managed to get some memory from kernel (from my device, not the V20) and non-null curent ptr, but kernel_read fails, even when reading 4 bytes from cur_ptr without any offset
Can anyone comment on line 119:
current_ptr = *(unsigned long *)(page_buffer + 0xe8);
What is 0xE8? Where does it come from?
Another strange thing: if i run poc with wd offset like for ex. 0xb0 right after reboot - i get another reboot right away, repeatability 100%. but if i run at first with offset like 0xc0 - of course i get writev 0x1000 and poc exits, but if i rerun poc with 0xb0 right after that - it will not cause reboot, but correct leak of mem happens

GoofMan69 said:
Oh, I see... So writev would block after writing first dummy_page_4g_aligned of length 0x1000, because pipe's queue is full (pipe size is also 0x1000). So there isn't actually any timing tweak required, right?
Click to expand...
Click to collapse
The sleep(2) is needed to make sure the THREAD_EXIT, which frees the binder_thread object, as well as the subsequent allocation of the iovec buffer in kernel memory take effect before the EPOLL_CTL_DEL. The pipe blocking happens only after the the EPOLL_CTL_DEL.
Can anyone comment on line 119:
current_ptr = *(unsigned long *)(page_buffer + 0xe8);
What is 0xE8? Where does it come from?
Click to expand...
Click to collapse
I'm guessing that 0xe8 comes from the author's looking at a hexdump of the page to find where there is a pointer to kernel stuff to help figure out where the address limit is held in memory, so it can be clobbered.

GoofMan69 said:
Oh, I see... So writev would block after writing first dummy_page_4g_aligned of length 0x1000, because pipe's queue is full (pipe size is also 0x1000). So there isn't actually any timing tweak required, right?
Btw, i've managed to get some memory from kernel (from my device, not the V20) and non-null curent ptr, but kernel_read fails, even when reading 4 bytes from cur_ptr without any offset
Can anyone comment on line 119:
current_ptr = *(unsigned long *)(page_buffer + 0xe8);
What is 0xE8? Where does it come from?
Another strange thing: if i run poc with wd offset like for ex. 0xb0 right after reboot - i get another reboot right away, repeatability 100%. but if i run at first with offset like 0xc0 - of course i get writev 0x1000 and poc exits, but if i rerun poc with 0xb0 right after that - it will not cause reboot, but correct leak of mem happens
Click to expand...
Click to collapse
page_buffer + 0xe8 should point to the current thread's thread_info structure, where the addr_limit is held
---------- Post added at 08:35 AM ---------- Previous post was at 08:19 AM ----------
arpruss said:
From reading the poc, it looks like deleting the event from the epoll queue, after the binder thread has terminated, (somehow) causes the pointer wq->task_list->prev to have the value &(wq->task_list->next).
Click to expand...
Click to collapse
yes, you are correct. i believe it is because remove_wait_queue is called for the wait_queue_head found in the binder_thread structure which eventually results in a call to __list_del where this happens:
http://androidxref.com/kernel_3.18/xref/include/linux/list.h#87

I can now leak data on my LGV20 with the 3.18 kernel using this modified poc: https://github.com/arpruss/cve2019-2215-3.18
The key is to realize that the following happens during the after-free cleanup at least on my 3.18.71 kernel:
1. The spinlock appears receive the value 0x10001
2. The prev and next pointers in the queue head point to the queue head.
If everything works, you will have a bunch of hex data, which starts with two 8-byte pointers with equal values.
This may or may not get us closer to actually elevating privileges, but I thought I'd share it to help others.
Code:
1|elsa:/data/local/tmp $ uname -a
Linux localhost 3.18.71-perf+ #1 SMP PREEMPT Tue Jul 17 14:44:34 KST 2018 aarch64
elsa:/data/local/tmp $ ./poc98
Starting POC
PARENT: Calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial page
CHILD: dummy data
CHILD: leak data
writev() returns 0x12001
CHILD: Finished write to FIFO.
PARENT: Done with leaking
00000000 a0 f8 c4 f3 c0 ff ff ff a0 f8 c4 f3 c0 ff ff ff |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

arpruss said:
I can now leak data on my LGV20 with the 3.18 kernel using this modified poc: https://github.com/arpruss/cve2019-2215-3.18
The key is to realize that the following happens during the after-free cleanup at least on my 3.18.71 kernel:
1. The spinlock appears receive the value 0x10001
2. The prev and next pointers in the queue head point to the queue head.
If everything works, you will have a bunch of hex data, which starts with two 8-byte pointers with equal values.
This may or may not get us closer to actually elevating privileges, but I thought I'd share it to help others.
Code:
1|elsa:/data/local/tmp $ uname -a
Linux localhost 3.18.71-perf+ #1 SMP PREEMPT Tue Jul 17 14:44:34 KST 2018 aarch64
elsa:/data/local/tmp $ ./poc98
Starting POC
PARENT: Calling WRITEV
CHILD: Doing EPOLL_CTL_DEL.
CHILD: Finished EPOLL_CTL_DEL.
CHILD: initial page
CHILD: dummy data
CHILD: leak data
writev() returns 0x12001
CHILD: Finished write to FIFO.
PARENT: Done with leaking
00000000 a0 f8 c4 f3 c0 ff ff ff a0 f8 c4 f3 c0 ff ff ff |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Click to expand...
Click to collapse
Nice work. Now without the spinlock issue crashing, the kernel write is failing. This is because the recvmsg implementation for the 3.18 kernel checks each address right before it's copied over to the buffer. In the writev/readv the access check for addresses are all done at once at the beginning of the call, so that's why the leaking works. Working now on trying to use readv instead of recvmsg

chompie1337 said:
Nice work. Now without the spinlock issue crashing, the kernel write is failing. This is because the recvmsg implementation for the 3.18 kernel checks each address right before it's copied over to the buffer. In the writev/readv the access check for addresses are all done at once at the beginning of the call, so that's why the leaking works. Working now on trying to use readv instead of recvmsg
Click to expand...
Click to collapse
It was tricky to get it working, but I can now write to an arbitrary kernel address using: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-overwrite-pipe.c
Unfortunately, one more ingredient is needed: I need the address of the thread_info structure in order to modify addr_limit. On 4.4+, this is easy, as it's part of the task_struct, which the leaked current_ptr points to. On 3.18, thread_info is at the beginning of the kernel stack. So what we need to do is to leak the kernel stack location. If you know how to do that -- e.g., extracting it in some way from the big kernel heap leak -- let me know.
Or one use some other method. For instance, one can heap spray with a bunch of struct file objects, use the big kernel heap leak to find one of the sprayed objects (e.g., one can seek to a unique random location in a sparse file, and search for that offset in the leaked kernel heap), and modify its ops pointer to point to a doctored list of ops that calls a user function. I think this should work, unless we're unlucky and the binder_thread object is not anywhere near one of the sprayed file objects.
Or else if someone has the exact same kernel on a rootable device, they could send me the output of cat /proc/kallsyms, and one could modify some syscall to call a user function.
Now that I have a big kernel heap memory leak plus arbitrary address writing it's just a matter of time before we have a full exploit, I expect.

arpruss said:
It was tricky to get it working, but I can now write to an arbitrary kernel address using: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-overwrite-pipe.c
Unfortunately, one more ingredient is needed: I need the address of the thread_info structure in order to modify addr_limit. On 4.4+, this is easy, as it's part of the task_struct, which the leaked current_ptr points to. On 3.18, thread_info is at the beginning of the kernel stack. So what we need to do is to leak the kernel stack location. If you know how to do that -- e.g., extracting it in some way from the big kernel heap leak -- let me know.
Or one use some other method. For instance, one can heap spray with a bunch of struct file objects, use the big kernel heap leak to find one of the sprayed objects (e.g., one can seek to a unique random location in a sparse file, and search for that offset in the leaked kernel heap), and modify its ops pointer to point to a doctored list of ops that calls a user function. I think this should work, unless we're unlucky and the binder_thread object is not anywhere near one of the sprayed file objects.
Or else if someone has the exact same kernel on a rootable device, they could send me the output of cat /proc/kallsyms, and one could modify some syscall to call a user function.
Now that I have a big kernel heap memory leak plus arbitrary address writing it's just a matter of time before we have a full exploit, I expect.
Click to expand...
Click to collapse
Amazing work! Going to try it out now. How do you know that current_ptr points to task_struct? On my Pixel (3.18 kernel) current_ptr points to thread_info. Wondering why that's different?
edit: nvm, i see now. it's in an offset of the binder_thread structure.

arpruss said:
It was tricky to get it working, but I can now write to an arbitrary kernel address using: https://github.com/arpruss/cve2019-2215-3.18/blob/master/poc98-overwrite-pipe.c
Unfortunately, one more ingredient is needed: I need the address of the thread_info structure in order to modify addr_limit. On 4.4+, this is easy, as it's part of the task_struct, which the leaked current_ptr points to. On 3.18, thread_info is at the beginning of the kernel stack. So what we need to do is to leak the kernel stack location. If you know how to do that -- e.g., extracting it in some way from the big kernel heap leak -- let me know.
Or one use some other method. For instance, one can heap spray with a bunch of struct file objects, use the big kernel heap leak to find one of the sprayed objects (e.g., one can seek to a unique random location in a sparse file, and search for that offset in the leaked kernel heap), and modify its ops pointer to point to a doctored list of ops that calls a user function. I think this should work, unless we're unlucky and the binder_thread object is not anywhere near one of the sprayed file objects.
Or else if someone has the exact same kernel on a rootable device, they could send me the output of cat /proc/kallsyms, and one could modify some syscall to call a user function.
Now that I have a big kernel heap memory leak plus arbitrary address writing it's just a matter of time before we have a full exploit, I expect.
Click to expand...
Click to collapse
Isn't thread_info pointed by the stack field of task_struct?