Hey guys, Honestly Annoying here! I worked on rooting the G5 for about 9 months last year, and finally got it after receiving a userdebug kernel.
I spent a lot of time researching and talking with tons of different devs, and here is a list of all of the information I have collected.
UNLOCK.BIN
First of all, this is ONLY for the devices that LG officially unlocks. It is processed by fastboot (aboot partition) and unless LG unlocks it officially, it will not recognize the "fastboot flash unlock unlock.bin" command. At this point there is no point in talking about this because the T-Mobile variant does NOT accept an unlock.bin to unlock, it accepts the oem fastboot command.
TL;DR: The unlock.bin is useless for any American G6. Don't waste your time trying to spoof it.
If you still want to attempt and spoof it (for some reason), it isn't possible. Some great explanations on how it is coded and works are posted in this thread here, make sure to leave those guys a thanks.
TOT INJECTING
For the G5, this was the only way T-Mobile users could achieve root before dirtyc0w. Unfortunately, this is not a liable option for the G6 (or v20) anymore, as LG is now signing the TOTs and the LAF partition will brick the device if an unsigned TOT is flashed. I have a theory on why this is the case, but don't want to accuse anyone of something if I am wrong (if you do a bit of research about this you will understand). I would not recommend trying this out as it will brick your device.
LG LAF BACKDOOR
If you have been with the LG scene for a while, you may know about the LAF backdoor. It has been documented publicly here (PLEASE leave him a thanks!), and there are a few other things that I have discovered with this as well that are not public as of now as I am not exactly sure what to do with them (PM for details). LG did patch this tool, but part of the code still works and with some work we could possibly figure out the new code. At this point I believe this is the most likely way to flash TWRP (use the dd command), but I have not been able to look at the new LAF commands as I do not own the G6.
TL;DR: LF LAF Backdoor probably still exists, it will just take work to find it out. If someone does figure out the new codes TWRP is easily flashable
DIRTYC0W
This was patched in December/November. Don't waste your time trying this out, as it has been confirmed not to work.
This is all of the information I can think of right now, I will continue to update this thread as I can think of other things to not waste time testing.
man, good thing i didn't sell my 3t , i kind of , sort of, can't live without molesting my device.
what are the chances the at&t version will be rooted? just got mine today, really like it but no root ill be taking it back.
I believe we are on the same page of why the tot files are being signature enforced now...
Sent from my LG-H918 using XDA-Developers Legacy app
fix-this! said:
what are the chances the at&t version will be rooted? just got mine today, really like it but no root ill be taking it back.
Click to expand...
Click to collapse
I think you will be taking it back...unless you dont mind waiting for a long time.
I really like the G6. i think LG nailed it this time but for me its a paperweight since it was likely to be BL locked.
Sent from my Note 7, S7 Edge or S6
Just a heads up, carrier locked LG G5's are still unrooted. I would imagine that the G6 would follow a similar fate.
henryjumbo said:
Just a heads up, carrier locked LG G5's are still unrooted. I would imagine that the G6 would follow a similar fate.
Click to expand...
Click to collapse
I couldn't agree more. T-Mobile is the only one that allowed oem unlock in the us of all carriers so naturally it was eventually rootable.
This thread shows how to enable disabled fastboot commands on the Alcatel OneTouch Idol 3, maybe we could also use this method: https://forum.xda-developers.com/idol-3/development/6039-guide-how-to-return-fastboot-t3201077
nima0003 said:
This thread shows how to enable disabled fastboot commands on the Alcatel OneTouch Idol 3, maybe we could also use this method: https://forum.xda-developers.com/idol-3/development/6039-guide-how-to-return-fastboot-t3201077
Click to expand...
Click to collapse
Link doesn't work
Josh McGrath said:
Link doesn't work
Click to expand...
Click to collapse
Just clicked on it and it worked, you might have to go back to the first page though.
nima0003 said:
Just clicked on it and it worked, you might have to go back to the first page though.
Click to expand...
Click to collapse
That's weird, it still doesn't work for me :/ oh well, no biggie
Honestly Annoying said:
LG LAF BACKDOOR
If you have been with the LG scene for a while, you may know about the LAF backdoor. It has been documented publicly here (PLEASE leave him a thanks!), and there are a few other things that I have discovered with this as well that are not public as of now as I am not exactly sure what to do with them (PM for details). LG did patch this tool, but part of the code still works and with some work we could possibly figure out the new code. At this point I believe this is the most likely way to flash TWRP (use the dd command), but I have not been able to look at the new LAF commands as I do not own the G6.
TL;DR: LF LAF Backdoor probably still exists, it will just take work to find it out. If someone does figure out the new codes TWRP is easily flashable
Click to expand...
Click to collapse
Thank you for the information. I'd be open to trying to flash TWRP using lglaf. But too much, including my job, depends on my having a functional, non-bricked phone. If I were to give this a shot and it turns out that my phone decides it wants to punch me in the eye, would I be able to use LGUP and flash the stock KDZ and have a functioning phone again? Obviously, nobody can really give a certain "Yes" to such a question, but I'd be happy with something along the lines of, "Unless you shoot yourself in the foot and/or your phone gets struck by lightning during the flash process, you should be good."
That said, I have another question. To be honest, I don't really care if my phone is rooted or not. In fact, I like using Android Pay. All I really want to do is have a usable phone in my home, where I have almost zero mobile signal. Unfortunately, that requires making a few small changes to /system/etc/wifi/WCNSS_qcom_cfg.ini.
Last time I was in LG Land, I don't think there was yet an "lglalf" utility. There was the "send_command" utility instead. Regardless, I seem to recall using this utility to mount /system/ RW, making the changes I wanted to /system/etc/wifi/WCNSS_qcom_cfg.ini, rebooting, and having an unrooted V10 that even took OTA updates, retained my changes to that file, and had working WiFi as a result.
Any thoughts on using the same methodology with the lglaf utility on the G6? My concern is that the bootloader or some other process may be doing some kind of checksum and, if the hash doesn't match what it expects to see, it will basically crap itself and tell me my phone is not safe, etc.
P.S. I spend many work days staring at wireshark captures trying to find the source of spanning tree goofiness on networks that are /20 and /21 in size. So, staring at USB packet dumps to try to make heads or tails out of what is going on would not bother me in the slightest, should you wish to give me a push in the right direction.
I spent some time messing around with the lglaf tool today. The normal version doesn't work, most commands give error code 0x8000010a. Apparently, that is the result of some additional security LG added to the process, in the form of a handshake. I found a pull request that adds an --unlock option here: https://github.com/Lekensteyn/lglaf/pull/12 - note that the code in the pull request is not compatible with python 3, so you'll need to be on python 2 to run it. The --unlock switch is not a bootloader unlock, but it triggers the authentication handshake. Unfortunately, neither of the keys provided along with that worked with the G6. So, if there are no other changes to the laf other than a new key, figuring out the new key might be enough to make some additional progress.
any peoples out there have access to:
extra G6 boards...
or broken G6..
or bad esn/imei G6..
or bricked G6.. etc?
Would love to start poking this device but I'm still paying off my G5.
Every now n then a repair tech or service center worker comes along.. and sometimes they have access to damaged/broken devices that are just collecting dust. I'm not looking for donations or anything like that.. just need a G6 board to work with.
Hit me up on my Twitter or something if you might have access to these things... https://twitter.com/@utoprime
autoprime said:
any peoples out there have access to:
extra G6 boards...
or broken G6..
or bad esn/imei G6..
or bricked G6.. etc?
Would love to start poking this device but I'm still paying off my G5.
Every now n then a repair tech or service center worker comes along.. and sometimes they have access to damaged/broken devices that are just collecting dust. I'm not looking for donations or anything like that.. just need a G6 board to work with.
Hit me up on my Twitter or something if you might have access to these things... https://twitter.com/@utoprime
Click to expand...
Click to collapse
Autoprime, after you pay off that G5, you can call T-Mobile or contact them from Twitter and they can do JOD. 3 upgrades a year. I just paid off my G4 and am doing that now and got the S8+. Then I can jump to the V30, then jump to the Pixel 2 possible all this year.
Sent from my SM-G955U using Tapatalk
MicroMod777 said:
Autoprime, after you pay off that G5, you can call T-Mobile or contact them from Twitter and they can do JOD. 3 upgrades a year. I just paid off my G4 and am doing that now and got the S8+. Then I can jump to the V30, then jump to the Pixel 2 possible all this year.
Sent from my SM-G955U using Tapatalk
Click to expand...
Click to collapse
not a bad idea.. it's a great way to get multiple phones in a year. the only thing keeping me from hopping on JOD is that I'd probably regret giving the phones back.. never know when you need to revisit an old phone to test something. But doing something like JOD may be the only way I can get multiple phones.. we shall see when it comes time to pay off my G5
I don't even use these phones as my main device.. they never leave my desk and often never even have a sim card put in them. So if I could get my hands on just a board.. or broken phone or something that'd be most ideal for my situation. But.. we can't always get what we want now can we? :crying:
hendusoone said:
I spent some time messing around with the lglaf tool today. The normal version doesn't work, most commands give error code 0x8000010a. Apparently, that is the result of some additional security LG added to the process, in the form of a handshake. I found a pull request that adds an --unlock option here: - note that the code in the pull request is not compatible with python 3, so you'll need to be on python 2 to run it. The --unlock switch is not a bootloader unlock, but it triggers the authentication handshake. Unfortunately, neither of the keys provided along with that worked with the G6. So, if there are no other changes to the laf other than a new key, figuring out the new key might be enough to make some additional progress.
Click to expand...
Click to collapse
Yeah, I ran into some of the same error message. Check out the thread for Issue #7. (Sorry, too "new" to post a link, but it's here: https://github.com/Lekensteyn/lglaf/issues/7 ) This provides some clues as to how to possibly go about getting the right keys. I will mess around with this tomorrow.
I also noticed something about the HELO command. The protocol documentation states that arg1 is the protocol version and states, "(resp must match req.)" without further details being provided. As the documentation states, lglaf is sending a value of 0x01000001 (\1\0\0\1), but the response does not match. The response that is being sent back by the device is (little-endian) 0x01000005 (\5\0\0\1). Yet, neither the lglaf utility nor the device balk, as noted by the ability to subsequently run '!INFO GPRO \x08\x0b\0\0' and/or '!CTRL RSET'
Also, the second argument is minimum version. The device is sending a response that indicates the minimum version is 0x10000001 (\1\0\0\10). It would appear that the device is saying its minimum version is higher than our version, which is 0x01000001.
And again, not sure if it means anything at all since it does seem to be working, but for science, at least:
host to 2.2.2 (request): HELO version 0x01000001
Code:
0000 48 45 4c 4f [COLOR="Blue"][B]01[/B] 00 00 01[/COLOR] 00 00 00 00 00 00 00 00 HELO............
0010 00 00 00 00 00 00 00 00 5c b1 00 00 b7 ba b3 b0 ........\.......
2.2.3 to host (response): HELO version 0x01000005 min version 0x10000001
Code:
0000 48 45 4c 4f [COLOR="DarkOrange"][B]05[/B] 00 00 01[/COLOR] [COLOR="Red"]01 00 00 [B]10[/B][/COLOR] 00 00 80 00 HELO............
0010 02 00 00 00 00 00 00 00 9e 3c 00 00 b7 ba b3 b0 .........<......
ariesgeek said:
Yeah, I ran into some of the same error message. Check out the thread for Issue #7. (Sorry, too "new" to post a link, but it's here: https://github.com/Lekensteyn/lglaf/issues/7 ) This provides some clues as to how to possibly go about getting the right keys. I will mess around with this tomorrow.
I also noticed something about the HELO command. The protocol documentation states that arg1 is the protocol version and states, "(resp must match req.)" without further details being provided. As the documentation states, lglaf is sending a value of 0x01000001 (\1\0\0\1), but the response does not match. The response that is being sent back by the device is (little-endian) 0x01000005 (\5\0\0\1). Yet, neither the lglaf utility nor the device balk, as noted by the ability to subsequently run '!INFO GPRO \x08\x0b\0\0' and/or '!CTRL RSET'
Also, the second argument is minimum version. The device is sending a response that indicates the minimum version is 0x10000001 (\1\0\0\10). It would appear that the device is saying its minimum version is higher than our version, which is 0x01000001.
And again, not sure if it means anything at all since it does seem to be working, but for science, at least:
host to 2.2.2 (request): HELO version 0x01000001
Code:
0000 48 45 4c 4f [COLOR="Blue"][B]01[/B] 00 00 01[/COLOR] 00 00 00 00 00 00 00 00 HELO............
0010 00 00 00 00 00 00 00 00 5c b1 00 00 b7 ba b3 b0 ........\.......
2.2.3 to host (response): HELO version 0x01000005 min version 0x10000001
Code:
0000 48 45 4c 4f [COLOR="DarkOrange"][B]05[/B] 00 00 01[/COLOR] [COLOR="Red"]01 00 00 [B]10[/B][/COLOR] 00 00 80 00 HELO............
0010 02 00 00 00 00 00 00 00 9e 3c 00 00 b7 ba b3 b0 .........<......
Click to expand...
Click to collapse
I have the KILO commands here... this is the work of @FluffyMittens and our findings by using a serial port sniffer while running a word generator that sent different commands through a serial connection.
KILOCENT (this is the handshake, cleaned up)
Code:
4B 49 4C 4F 43 45 4E 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BE E3 7B 00 00 BE B4 BE B6 BE B3 BE B0
RAW HEXIDECIMAL
Code:
0x4B 0x49 0x4C 0x4F 0x43 0x45 0x4E 0x54 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (insert byte) 0xE3 0x7B 0x00 0x00 (insert byte) 0xB4
(insert byte) 0xB6 (insert byte) 0xB3 (insert byte) 0xB0
KILOMETR (cleaned up)
Code:
4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 BE B4 BE B6 BE B3 BE B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
RAW HEXIDECIMAL
Code:
0x4B 0x49 0x4C 0x4F 0x4D 0x45 0x54 0x52 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (insert byte) 0xB4 (insert byte) 0xB6 (insert byte) 0xB3 (insert byte) 0xB0
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
KILOGRAM (key)
Code:
dqoev)ohnsWu\\bk`oiicmZ_lpqe\\ealp
I don't exactly know how to use these. I know that these are supposed to be "secret" but since the LG scene has gone down recently here they are. Hopefully this helps, if anyone needs anything more I have some more commands as well.
So... I tried lglaf.py with that new kilogram key, but it didn't work. Then, I went back and took another stab at updating the version with --unlock to be compatible with python 3. I was a bit more successful this time, and it is able to complete the handshake and execute commands (like ls) without erroring out. It's using the old key - the new one you provided errors out. I don't know of a safe way to test writing data to the G6, so I will leave that to someone a bit more experienced.
I have attached my updated lglaf.py to this post. Extract it to your lglaf directory overwriting the existing lglaf.py. If you don't have lglaf yet, get it here first: https://github.com/Lekensteyn/lglaf
Requirements:
Install python3, then run: pip install pycryptodomex
Once that's done, you should be able to execute commands like this:
python lglaf.py --unlock --debug -c "!EXEC ls -l /system/\0"
Note that partitions.py is not working.
hendusoone said:
So... I tried lglaf.py with that new kilogram key, but it didn't work. Then, I went back and took another stab at updating the version with --unlock to be compatible with python 3. I was a bit more successful this time, and it is able to complete the handshake and execute commands (like ls) without erroring out. It's using the old key - the new one you provided errors out. I don't know of a safe way to test writing data to the G6, so I will leave that to someone a bit more experienced.
I have attached my updated lglaf.py to this post. Extract it to your lglaf directory overwriting the existing lglaf.py. If you don't have lglaf yet, get it here first: https://github.com/Lekensteyn/lglaf
Requirements:
Install python3, then run: pip install pycryptodomex
Once that's done, you should be able to execute commands like this:
python lglaf.py --unlock --debug -c "!EXEC ls -l /system/\0"
Note that partitions.py is not working.
Click to expand...
Click to collapse
Can it run any other commands besides "ls"? Try out "id" and "whoami"
Related
Hi, Weather Database Editor doesnt work with my Girlfriends Touch 3G (german).
Is there any Solution to manually add Cities?
Thanks. =)
Same problem here
Try this one..
http://forum.xda-developers.com/showpost.php?p=2488224&postcount=73
Thanks but it does no show any cities...
yepp, seems that the database has another filename...
i try investigating this...
Ok, found the Database. =)
Its HH_0407_WeatherCities.xml (for German Users i think).
Bad news:
Its hidden/system/in rom
Any ideas how to rename it?
I copied it to the PC and edited the Cities in but i cant copy it back to the phone...
You can easily overwrite the file with resco explorer after disabling touchflo from the today screen but I have yet to find a way to copy the file to the pc. Could you share your xml please?
Ok I am getting nearer.
Disable touchflo
Copy HH_0407_WeatherCities.xml from the /windows folder to your pc.
Edit the xml to include your new city.
Copy it back to the phone into somewhere like "My Documents" then use resco explorer to move it to /windows and overwrite the original file.
Copy manil2d.exe from windows to your pc,
download XVI32 from http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
download sign code from N2A's site http://weather.not2advanced.com/files/SignCode.zip
Open manila2d.exe in XVI32 and do a search for "weather.manila1.htc.com" ( make sure Unicode check box is checked )
You will see the update URL in unicode , which means that if you want to replace it , there has to be a hex 00 between every letter !
It needs to be changed to something like weather.not2advanced.com/htcweather/forecastdata.php?locCode=%s%s%s
save manila2d.exe and sign it using N2A's batch file
Copy it back to the phone into somewhere like "My Documents" then use resco explorer to move it to /windows and overwrite the original file.
Now I have the new city listed but when I update, all the temperatures = 0
I'm not sure what I have done wrong but I think the URL is wrong.
Any ideas?
Ok, the URL was different for me.
Done that but without the %s%s%s.
Still not working.
I can select the cities but i cant see them in the tab.
Update says that it cannot get updates for the selected city.
Hi Vibez
I reply here instead of the PM , so the others can read it aswell
I don't have a touch 3G so I cannot experiment for you , but 1 thing is sure ,
people had the same issue on the Diamond ( cities not updating after hex-edit ) when the hex-edit was not done 100% correctly ...
So 2 questions :
1) Did any of you try the reigistry hack from the diamond ?
In stock ROM, the URL used to update the weather is a specific Accuweather URL. WDE change it to point to N2A'website ( http://weather.not2advanced.com/ ).
Registry key=HKEY_CURRENT_USER\Software\HTC\Manila
String value Name=Weather.ServerURLOverride
Click to expand...
Click to collapse
2) when u tried patching , did the replacement weather string have EXACTLY the same length as the original ? On the diamond , it was an absolute no-go when the length was different
Open manila exe in XVI32 and do a search for "weather.manila1.htc.com" ( make sure Unicode check box is checked )
You will see the update URL in unicode , which means that if you want to replace it , there has to be a hex 00 between every letter !
I then replaced : http://weather.manila1.htc.com/widget/htc/forecast-data_v3.asp?locCode=%1s&?ac=TR2cra9U
with : http://weather.not2advanced.com/htcweather/forecastdata.php?locCode=%1s&ac=XDADevs1234
Those two lines have exactely the same length upto there ( That's why i added 1234 to the XDAdevs , thankfully that's ok with N2A's site ) so the rest of the URL ( &device=innovation etc.. ) can remain unchanged !
Click to expand...
Click to collapse
If that fails to work , send me a copy of the manila app ( modded and original maybe so I can see what u did ) , I'll look at it , patch it & send it back for you to try ...
I can't promise anything of course , but I'm on holidays this week , so I've got a little time to spare ;-)
cheers,
Claude
Thanks for the info!
Unicode-Strings should be NULL-terminated to, so all i've done was to zero out the remaining chars.
I give it a try and answer here asap.
//edit:
Ok, works but Temps are at 0°C.
Seems that the XML-Format has been changed.
BTW: String used for Patching Mainila2D.exe was:
000D8858 68 00 74 00 74 00 70 00 3A 00 2F 00 2F 00 77 00 65 00 61 00 74 00 68 00 h.t.t.p.:././.w.e.a.t.h.
000D8870 65 00 72 00 2E 00 6E 00 6F 00 74 00 32 00 61 00 64 00 76 00 61 00 6E 00 e.r...n.o.t.2.a.d.v.a.n.
000D8888 63 00 65 00 64 00 2E 00 63 00 6F 00 6D 00 2F 00 68 00 74 00 63 00 77 00 c.e.d...c.o.m./.h.t.c.w.
000D88A0 65 00 61 00 74 00 68 00 65 00 72 00 2F 00 66 00 6F 00 72 00 65 00 63 00 e.a.t.h.e.r./.f.o.r.e.c.
000D88B8 61 00 73 00 74 00 64 00 61 00 74 00 61 00 2E 00 70 00 68 00 70 00 3F 00 a.s.t.d.a.t.a...p.h.p.?.
000D88D0 6C 00 6F 00 63 00 43 00 6F 00 64 00 65 00 3D 00 25 00 31 00 73 00 00 00 l.o.c.C.o.d.e.=.%.1.s...
Ahw F...!
Tested the original URL:
first, city in original database:
http://htc.accuweather.com/widget/htc/forecast-data.asp?ac=TR2cra9U&locCode=EUR|DE|GM011|AACHEN
second, city manually added:
http://htc.accuweather.com/widget/h...ac=TR2cra9U&locCode=EUR|DE|GM017|SCHMALKALDEN
second URL does NOT give any information back in the XML...
Seems that the database is also online and it trys to find the city there...
OK, tried the not2advanced URL, XML Format has changed heavily...
*sniff*
Garfield1970,
Thanks for helping out.
The registry trick did not work.
I did find a patched version of manila2d.exe from another rom that works perfect on our phone, but ideally I would like to see how to patch the original version that our phone ships with. The hex surrounding the URL string in our manilla2d.exe looks a little different. I'm not 100% there is enough room to fit the full N2A url in!
I will post all 3 versions later for you to play with.
Weltherrscher said:
Ahw F...!
Tested the original URL:
first, city in original database:
http://htc.accuweather.com/widget/htc/forecast-data.asp?ac=TR2cra9U&locCode=EUR|DE|GM011|AACHEN
Click to expand...
Click to collapse
Ok
second, city manually added:
http://htc.accuweather.com/widget/h...ac=TR2cra9U&locCode=EUR|DE|GM017|SCHMALKALDEN
second URL does NOT give any information back in the XML...
Seems that the database is also online and it trys to find the city there...
Click to expand...
Click to collapse
That's normal as that city is unknown to the HTC Server
OK, tried the not2advanced URL, XML Format has changed heavily...
*sniff*
Click to expand...
Click to collapse
Indeed , I just compared the XML Outputs for Aachen from HTC & N2A , they changed the format .... But if you ask N2A very very nicely and if he has some time to spare , he might eventually adapt a version of his script to reflect the other XML format
You can clearly see the differences between the following two outputs :
http://weather.not2advanced.com/htc...hp?locCode=EUR|DE|GM011|AACHEN&ac=XDADevs1234
is the Diamond compatible format
http://htc.accuweather.com/widget/htc/forecast-data.asp?ac=TR2cra9U&locCode=EUR|DE|GM011|AACHEN
is the format the touch 3g seems to need ....
I'll crosspost the URL's to N2A's main thread so he can maybe have a look
Claude
Just for info the XML format that ships with our ROM works fine with N2A.
To me it seems N2A provides extra elements which I assume is for compatibility with HTC home.
So no need as far as I can tell to ask him to change anything.
Unless i'm getting confused in what you are saying?
vibez said:
Just for info the XML format that ships with our ROM works fine with N2A.
To me it seems N2A provides extra elements which I assume is for compatibility with HTC home.
So no need as far as I can tell to ask him to change anything.
Unless i'm getting confused in what you are saying?
Click to expand...
Click to collapse
Are you sure that the N2A output works for you ?
Because if you look at the XML's , what your device expects is to see includes blocks titled :
Today
Tonight
Tomorrow
and then the following weekdays
whereas on my Diamond it's just current and the different Weekdays being reported
Claude
I'm 100% sure it works with this version of manila2d.exe that i'm using. Now it may be that this version I have uses the old format.
We don't have
Today
Tonight
Tomorrow
we just have current temp, and hi, lo for each day
You mean using the patched manila from the other rom that you mentionned earlier ?
Might be that the format switch has happened between differen Rom versions ?
Claude
Garfield1970 said:
You mean using the patched manila from the other rom that you mentionned earlier ?
Might be that the format switch has happened between differen Rom versions ?
Claude
Click to expand...
Click to collapse
Yes it could be that. Although the end result is the same. The original version only showed Current and hi/lo temps
Ok i've attached the files
Manila2D_original.exe
This is the original unpatched file
Manila2D_original_patched_not_working.exe
This the original file I tried to patch without success
Manila2D_patched_ok.exe
This is the patched file from another rom that works ok.
my sd card slot is broken.. it does read any sd card anymore.. i did a factory reset on my rooted nook and now it is stuck to the android "Touch the android to begin" screen and when i touch the android screen nothing happens...
is there a way to enable noogie without sd card? maybe write directly to nook internal storage?
The first way would be if you had installed ClockworkMod recovery as your recovery image.
The other way is to follow the thread on bootloading the new Nook Glow 2 over USB.
http://forum.xda-developers.com/showthread.php?t=2559915
With the correct images you can boot an NST over USB.
what do u mean clockworkmod recovery as my recovery image? Instructions for cwm is to put it on sd card and boot from it... i didn't know you can flash it into the internal storage of nook?
how do you bootload the nook simple touch with glowlight over usb? i don't see how to do it in http://forum.xda-developers.com/showthread.php?t=2559915
i forgot to say it's a nook simple touch with glowlight and not the latest nook glow
edit: can you please attach the exe you have put in the other threads? i think all the attachments have somehow been deleted... i am using win7.. and it detects omap device for only 2-3 seconds... and i can't have time to install the drivers
So as not to bother the other threads with my quesitons... I am posting my results here,
I have modified my android_winusb.inf adding these lines
Code:
[Google.NTx86]
; Nook Simple Touch
%SingleAdbInterface% = USB_Install, USB\VID_2080&PID_0003
%CompositeAdbInterface% = USB_Install, USB\VID_2080&PID_0003&MI_01
; Nook Glow 2
%SingleAdbInterface% = USB_Install, USB\VID_2080&PID_0007
%CompositeAdbInterface% = USB_Install, USB\VID_2080&PID_0007&MI_01
; OMAP3630 bootloader
%SingleBootLoaderInterface% = USB_Install, USB\VID_0451&PID_D00E
; FastBoot
%SingleFastBootInterface% = USB_Install, USB\VID_0451&PID_CAFE
Code:
[Google.NTamd64]
; Nook Simple Touch
%SingleAdbInterface% = USB_Install, USB\VID_2080&PID_0003
%CompositeAdbInterface% = USB_Install, USB\VID_2080&PID_0003&MI_01
; Nook Glow 2
%SingleAdbInterface% = USB_Install, USB\VID_2080&PID_0007
%CompositeAdbInterface% = USB_Install, USB\VID_2080&PID_0007&MI_01
; OMAP3630 bootloader
%SingleBootLoaderInterface% = USB_Install, USB\VID_0451&PID_D00E
; FastBoot
%SingleFastBootInterface% = USB_Install, USB\VID_0451&PID_CAFE
Code:
[Strings]
SingleBootLoaderInterface = "Android Bootloader Interface"
SingleFastBootInterface = "Android FastBoot Interface"
When my nook starts, i don't get "Found new hardware" popup but in device manage, the omap device appears but disappears after 3seconds.... I has an "exclamation" icon to it as you can see and i don't know what this means
So i powered off the nook, ran
Code:
omap3630.exe omap3_aboot.bin u-boot13.bin
from your zip : http://forum.xda-developers.com/showpost.php?p=48633090&postcount=44&nocache=1&z=944385892387572 (that's the only zip still available from you, all your other zips are no more present.. i dunno why)
I get
Code:
Waiting for bootloader...
I powered on my nook but nothing... any idea what's wrong?
yeahman45 said:
So i powered off the nook, ran
Code:
omap3630.exe omap3_aboot.bin u-boot13.bin
...
I powered on my nook but nothing... any idea what's wrong?
Click to expand...
Click to collapse
use u-boot12.bin for a NST or NSTG. uboot13.bin is an experiment for the new NG2 and doesn't work.
straygecko said:
use u-boot12.bin for a NST or NSTG. uboot13.bin is an experiment for the new NG2 and doesn't work.
Click to expand...
Click to collapse
I did try uboo12.bin but did not work...
so decided to boot on my windows xp instead as i felt like win7 was messing up with the drivers and they were not installed properly.. it seems to work with winxp.. here my result:
Code:
U:\nook\usb_loading\experiment3>omap3630.exe omap3_aboot.bin u-boot12.bin
Waiting for bootloader... connected
Received ASIC id, 69 bytes
OMAP36XX, rev 07
Unlocked
ID12: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ID14: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRC1: EF3EBF13
CRC2: 00000000
Sending image file omap3_aboot.bin, 3480 bytes... done
Ack: AABBCCDD
Sending image file u-boot12.bin, 170572 bytes...Error sending image data
I don't know why it has an error sending image data
Yes, W7 is difficult with drivers.
I don't have a system here to check that.
They are actually just the stock Windows WinUSB drivers.
I'm not sure about the business with the co-installers.
In any case, you could have clicked on the icon with the warning and tried Update Driver.
"Error sending" is when, for whatever reason, the far end of the USB stops listening.
170572 is the right size.
Did you try it another time?
There is some goofy stuff going on here, maybe a-boot has some incompatibilities.
(Since this is all experimental, I delete older versions when I post a new one.)
I can boot my Touch into a CWR image ok, but I seem to have problems booting a (rooted) stock image over USB.
Renate NST said:
Yes, W7 is difficult with drivers.
I don't have a system here to check that.
They are actually just the stock Windows WinUSB drivers.
I'm not sure about the business with the co-installers.
In any case, you could have clicked on the icon with the warning and tried Update Driver.
"Error sending" is when, for whatever reason, the far end of the USB stops listening.
170572 is the right size.
Did you try it another time?
There is some goofy stuff going on here, maybe a-boot has some incompatibilities.
(Since this is all experimental, I delete older versions when I post a new one.)
I can boot my Touch into a CWR image ok, but I seem to have problems booting a (rooted) stock image over USB.
Click to expand...
Click to collapse
i tried update driver in win7 by manually selecting the inf but it says driver already uo to date.maybe it is cuz my win7 is 64bit. Anyway will use my beloved old good winxp lol. Yup i think my uimage is rooted. Should i do a factory restore and try again? But if that doesnt work i might lose root foreever.
Yes, I guess XP is the way to go right now.
There's a new version of omap3630.exe on the other thread.
Could you check that there and report back here?
Maybe next week I can get my hands on a Win7 box and figure out why the drivers are being such a pain.
Renate NST said:
Yes, I guess XP is the way to go right now.
There's a new version of omap3630.exe on the other thread.
Could you check that there and report back here?
Maybe next week I can get my hands on a Win7 box and figure out why the drivers are being such a pain.
Click to expand...
Click to collapse
i get an error with experiment4 : omap3630.exe is not a valid win32 application
is this for 64bit? i am on 32bit
edit: sorry was a corrupted download.. i ran it.. here's my result:
Code:
U:\nook\usb_loading\experiment4>omap3630.exe omap3_aboot.bin u-boot12.bin
Device in ADB mode
Waiting for bootloader... connected
Received ASIC id, 69 bytes
OMAP36XX, rev 07
Unlocked
ID12: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ID14: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRC1: EF3EBF13, CRC2: 00000000
Sending image file omap3_aboot.bin, 3480 bytes... ok
Ack: AABBCCDD
Sending image file u-boot12.bin, 170572 bytes...
Error 0000001F sending image data, sent 0 bytes
Apparently aboot accepted the size parameter, then shut down before the data could be loaded.
This needs some looking into.
Renate NST said:
Apparently aboot accepted the size parameter, then shut down before the data could be loaded.
This needs some looking into.
Click to expand...
Click to collapse
any idea what is wrong? can i try some other tests?
tried experiment 6 and here's the result.. it's waiting for fastboot
Code:
U:\nook\usb_loading\experiment6>omap3630.exe omap3_aboot.bin u-boot12.bin
Waiting for bootloader... connected
Received ASIC id, 69 bytes
OMAP36XX, rev 07
Unlocked
ID12: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ID14: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRC1: EF3EBF13, CRC2: 00000000
Sending image file omap3_aboot.bin, 3480 bytes... ok
Ack: AABBCCDD
Sending image file u-boot12.bin, 170572 bytes... ok
Waiting for disconnect... ok
Waiting for fastboot...
and my screen is blank...
btw thx and Merry Xmas Renate
working with experiment 6...cwm boots fine and i tried booting noogie but not sure if it's booted or not as the screen remains blank instead of "Rooting forever"
yeahman45 said:
working with experiment 6...cwm boots fine and i tried booting noogie but not sure if it's booted or not as the screen remains blank instead of "Rooting forever"
Click to expand...
Click to collapse
i think noogie is running fine as my pc detects all nook's partitions .. (boot, rom, nook, etc..) but for some reason i can't write/restore my backup img or when i flash glownooter in cwm, it reboots before flashing is complete (i think i may have not even started)
yeahman45 said:
i think noogie is running fine as my pc detects all nook's partitions .. (boot, rom, nook, etc..) but for some reason i can't write/restore my backup img or when i flash glownooter in cwm, it reboots before flashing is complete (i think i may have not even started)
Click to expand...
Click to collapse
I know you have been doing alot and please double check with others before doing what I suggest. From what I gather you have managed to get your NST running noogie and you want to restore a backup you have already made. I don't what tools you are using to restore/backup but some diskimage tools will not allow writing of partitions on a device where they already exist. So you would have to delete the partition before you restore.
See noogie guide here
Crispy3000 said:
I know you have been doing alot and please double check with others before doing what I suggest. From what I gather you have managed to get your NST running noogie and you want to restore a backup you have already made. I don't what tools you are using to restore/backup but some diskimage tools will not allow writing of partitions on a device where they already exist. So you would have to delete the partition before you restore.
See noogie guide here
Click to expand...
Click to collapse
are you sure? i am not too willing deleting my partitions... if i am not sure that i will be able to recover them... i have restored my img before with no problem using noogie booted via sdcard...
something i noticed too... when restoring my img, it fails at 10% but my nook is still ok.. shouldn't it be in "limbo" state?
also, flashing glownooter in cwm does not work either; it just reboots my nook and realise nothing happened
So did you get ADB over USB with CWM working?
If DevManager is showing ADB Composite Interface you are halfway there.
ADB has a list of known manufacturers of Android devices inside the program.
B&N is not "known".
That's why you have to have an entry in UserName\.android\adb_usb.ini
Code:
0x2080
Renate NST said:
So did you get ADB over USB with CWM working?
If DevManager is showing ADB Composite Interface you are halfway there.
ADB has a list of known manufacturers of Android devices inside the program.
B&N is not "known".
That's why you have to have an entry in UserName\.android\adb_usb.ini
Code:
0x2080
Click to expand...
Click to collapse
yup cwm is booting fine device manager detects the nook as adb composite interface but does not show up in adb devices
should i create this file as it does not exist on my winxp... when booted in noogie, i can see my partitions and the apps launcher.apk are present in system/app but when i boot my nook... it shows the android logo and says touch to begin setup.. when i touch on the android logo nothing happens... it is just stuck here... i need to touch change language to get nook setup page... and re-register my nook account... each boot is the same.. need to change language to get nook setup page and redo the whole registration setup to be able to "unlock" the nook menu
yeahman45 said:
yup cwm is booting fine device manager detects the nook as adb composite interface but does not show up in adb devices
should i create this file as it does not exist on my winxp... when booted in noogie, i can see my partitions and the apps launcher.apk are present in system/app but when i boot my nook... it shows the android logo and says touch to begin setup.. when i touch on the android logo nothing happens... it is just stuck here... i need to touch change language to get nook setup page... and re-register my nook account... each boot is the same.. need to change language to get nook setup page and redo the whole registration setup to be able to "unlock" the nook menu
Click to expand...
Click to collapse
ok i created the adb_usb.ini and it detects adb!!! will try to install relaunch and see if it will unblock it
Hi, i know there is many threads with similar problem, but nothing i've tried solved the problem, so i post a new one.
Yesterday, on my work, my phone lost signal (is common on my rom Gear CM12.1 & country) and i reboot to solve..... but only show the "samsung" and i get a bootloop in CM12 logo. i thinks is a cache problem and go to TWRP, clean cache&dalvik and reboot but i get the same problem so tried again twrp and this time i notice that show "Error: Unable to mount /efs", because of my work just turn it off to fix it later. In my home the problems is that twrc says that efs backup is wrong and can't restore it (says some md5 related).
Watever...today I did something really stupid, accidentally format the internal sd where the backup was saved, and now i can't get it back.
the current state of my S4 is:
-Fake imei (show default 00499010640000 / 01)
-Baseband: I9500XXUFNA6
-Carrier: Telcel
-Country: Mexico
-PhoneStatus: Unlocked (form factory)
-Rom: Stock 4.4 SER-I9500XXUFNB3-20140220172446.zip - I9500XXUFNB3_I9500SERFNB3_I9500XXUFNA6_HOME.tar
-I get signal (Show "Telcel, only emergency calls")
What i've tried:
1. How to fix - E:failed to mount /efs (Invalid argument) solve the efs mount problem....
2. Install stock rom 4.4 (also modem.bin)..... fake imei but correct baseband, telcel signal
3. Install stock rom 5.1 (also modem.bin)..... unknow imei and unknow baseband, no signal at all
4. Backup whit EFS Professional 2.1.80 BETA, but if restore is the fake
5. wanam's EFS☆IMEI☆Backup becaue i read efs is stored in a partition not in efs folder, but if restore efs is the fake
well, other post i tried but whit same results...
IMEI & Baseband unknow [SOLVED]
IMEI NULL fixed
also many others.... (4 pages of result on google for site:forum.xda-developers.com/galaxy-s4/help/ "imei" "i9500" )
Questions:
1. Is possible that the problem is "EMMC chip"?, many people say's this but mention that if is the problem the baseband is loset too, and i have my baseband.
2. i do this: Solved:Hex Editor Route, but the phone can't read simcard, so change the information for my phone but not work, what i'm doing wrong?
Code:
00188000: FF FF FF FF 4D 50 20 30 2E 38 30 30 00 00 00 49
00188010: 4E 55 00 00 00 00 47 54 2D 49 39 35 30 30 5A 4B
00188020: 41 49 4E 55 00 00 00 00 00 00 FF FF FF FF FF FF
MP 0.800...INU....GT-I9500ZKAINU......
00188000: FF FF FF FF 4D 50 20 30 2E 38 30 30 00 00 00 53
00188010: 45 52 00 00 00 00 47 54 2D 49 39 35 30 30 5A 4B
00188020: 41 53 45 52 00 00 00 00 00 00 FF FF FF FF FF FF
MP 0.800...SER....GT-I9500ZKASER......
Another solution
pd: sorry for my english.
Hardware damage. Your EMMC chip is damaged. Find someone who can replace it. The part is not that expensive but requires soldering.
Lennyz1988 said:
Hardware damage. Your EMMC chip is damaged. Find someone who can replace it. The part is not that expensive but requires soldering.
Click to expand...
Click to collapse
thanks for answering
in the oficial service they said they could fix it, but it would take a week.
A particular technician could restore the IMEI (or so I thought), early check start with 55 and end at 9, but when I got home confirme which is another IMEI (the IMEI of a S3).
He fix it with this tool: Z3X Box http: //z3x-team.com/
Anyone can tell me if i can change the imei on my own? or i need go to ask if they can restore my emai?
Status:
Signal: Ok (Telcel)
IMEI: Ok (but is from another phone)
Baseband: OK
Rom: Stock 4.4.2
Root & BussyBox
Efs: Backup (EFS Professional 2.1.80 BETA)
Asking whether you can change the IMEI, or how to do it, is something that can get XDA into deep s#!^. So don't do it. Keep in mind that XDA is hosted on a US server and has to abide by US law. In the US, cloning the IMEI of a phone for any reason whatsoever is illegal. Thus discussion of it falls under XDA rule 9, "Don't get us into trouble."
Strephon Alkhalikoi said:
Asking whether you can change the IMEI, or how to do it, is something that can get XDA into deep s#!^. So don't do it. Keep in mind that XDA is hosted on a US server and has to abide by US law. In the US, cloning the IMEI of a phone for any reason whatsoever is illegal. Thus discussion of it falls under XDA rule 9, "Don't get us into trouble."
Click to expand...
Click to collapse
well, i'm not trying to change my IMEI for other, I want to recover my original IMEI, so I do not think that's illegal (?) ...
Still thanks for the warning :good:
Moderators please close the thread, I will continue on my own, thanks.
When IMEI is wiped for whatever reason, your only recourse is to take it to manufacturer or Servicing Center. We do not discuss any methods pertaining to changing or restoring IMEI.
PERIOD. END OF DISCUSSION.
Thread Closed.
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
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?