LG Viper roms?
- Thread starter brandonabandon
- Start date
thenameisnigel
Well-known member
No, just make sure you put the kernel source on GitHub or something similar and post the link.
Sent from my SPH-L710 using Tapatalk
Can't upload images now, but Stock ZVK gets me 9154 on Antutu (UX Multi 1524 ; Runtime 687) (RAM Op 385 Speed 656) (CPU int 839 float 463) (GPU 2d 782 3d 3069) (I/O Storage 394 Database 355)
Quadrant 2957 (CPU 4848 Mem 2112 I/O 4791 2D 1023 3D 1992)
Thanks a bunch telosia!
I'll bump the gpu clock up to 300mhz and see how it handles it.
Just so everyone knows, the device gets a little hotter at 1.67, and the battery charge goes right down the drain(to be expected for both) so make sure to set your governor and max clock with care!
I'm having to redo my ubuntu install, doing it on my ssd this time. All of my my input devices and sound would go out all at once. Must have been a bad package i installed.
I'm a little tired from staying up late night, I'll get back to work as soon as I can.
@Nigel,
Going to try and see what I can do about the recovery_ui.c then get to work on the cm9 builds, old build enviornment got me errors in qcom display header includes, said it couldn't find qcom.h or similar. Ever have that issue?
I'll see if it happens again when I can.
I'll bump the gpu clock up to 300mhz and see how it handles it.
Just so everyone knows, the device gets a little hotter at 1.67, and the battery charge goes right down the drain(to be expected for both) so make sure to set your governor and max clock with care!
I'm having to redo my ubuntu install, doing it on my ssd this time. All of my my input devices and sound would go out all at once. Must have been a bad package i installed.
I'm a little tired from staying up late night, I'll get back to work as soon as I can.
@Nigel,
Going to try and see what I can do about the recovery_ui.c then get to work on the cm9 builds, old build enviornment got me errors in qcom display header includes, said it couldn't find qcom.h or similar. Ever have that issue?
I'll see if it happens again when I can.
Last edited:
i ported iproj. hosting soon, lets hope it boots.
edit: https://github.com/brandonabandon/lge-kernel-iproj/tree/cm10.1
^@kernel merged sprint board.
edit: do not flash to stock lmao, obviously was a brick, flashtool did not recognize, a factory reset went to recovery where i could restore. much thanks to josh or my viper days would be numbered. gotta merge vipers" usb drivers i recon'....
edit: https://github.com/brandonabandon/lge-kernel-iproj/tree/cm10.1
^@kernel merged sprint board.
edit: do not flash to stock lmao, obviously was a brick, flashtool did not recognize, a factory reset went to recovery where i could restore. much thanks to josh or my viper days would be numbered. gotta merge vipers" usb drivers i recon'....
Last edited:
im unclear on some aspects of loki. for instance, every image would need loki'd (system,boot,recovery,etc.?) or is the loki'd recovery now bypassing the bootloader therefore enableing roms/kernels to be flashed? if not, what method for flashing a rom/kernel properly?
Last edited:
to be accurate, loki is malicious in nature. it basically hijacks the aboot right before a signature check that determines if you tampered it or not, and allows aboot to run "virtually" where the sig check sees the image in flash memory, and not ram.
from what i gather, it allows you to run custom recoveries, and install custom roms just like you would on a device that allows you to disable the locked bootloader.
http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
from what i gather, it allows you to run custom recoveries, and install custom roms just like you would on a device that allows you to disable the locked bootloader.
http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Malicious to LG and sprint maybe 
. Not us end users. To us, clever little program that gives us a desired result.
Thats about the gist of it. Me and a buddy used to do this kind of thing to windows games with the goal of multiplayer on games that had limited to multiplayer. It's just a lot harder because i know practically nothing about how to disable arm binaries, x86 is much easier.
To add though, you only need to patch things handled by the boottoloader (recovery and kernel)
@brandon check out playfulgods repo for the ms840 and the one he forked from a vs840
. Not us end users. To us, clever little program that gives us a desired result.Thats about the gist of it. Me and a buddy used to do this kind of thing to windows games with the goal of multiplayer on games that had limited to multiplayer. It's just a lot harder because i know practically nothing about how to disable arm binaries, x86 is much easier.
To add though, you only need to patch things handled by the boottoloader (recovery and kernel)
@brandon check out playfulgods repo for the ms840 and the one he forked from a vs840
i merged the stock usb/charger components and verified the charger works via twrp. i didnt think of testing the charger this way initially so i will recompile my original commit and test before commiting the changes. either way, lgflashtool does not recognize. im wondering if its even possible considering the kernel would be foreign to flashtool. if thats the case, im reluctant to attempt flashing any roms along with considering it could wipe the recovery. any suggestions?
Just making sure here, you do know the recovery has its own kernel right? Any changes to the system kernel will not take affect in recovery because of this.
As far as I know Download mode is independant from the kernel, you might be having a different issue. And I don't believe you can wipe the kernel/recovery without explictly telling the device to do so. Just check what partition you are messing with and check the scripts on what you flash.
As far as I know Download mode is independant from the kernel, you might be having a different issue. And I don't believe you can wipe the kernel/recovery without explictly telling the device to do so. Just check what partition you are messing with and check the scripts on what you flash.
download mode is a soc (system on a chip) that isnt accessable even by lgtools. this is a permanent failsafe that can only be modified or repaired through chip flashing. i am not refering to flashing through software means. i am refering to the fact that it is preflashed on a hardware level before being installed on the device, and in return, would have to be replaced or physically reflashed (similar to a modchip in a system. its a hardware issue that cannot be fixed on software level alone). If you are unable to boot into download mode, you are either doing it wrong, or you simply have a damaged chip. note that the easiest meathod to boot into download mode is by holding the volume down key and plugging in the usb cord. do not release the volume down until you get download mode (if i am mistaken, try volume up as a last resort). from lg tools, you need the provided dll to get lg tools to detect your specific phone hardware and interface with it. this is not done on a kernal or recovery level and thus is why i could not make any progress through this route. this is not oden. this is something entirely different.
I also have a copy of the ZVI source code for both system and kernel. Interestingly enough, you build it using the stock ICS from google. I will host on my MEGA if your interested, but i would personally go through and do my best to alter the source code to where when compiled you have as close to stock ICS as possible. It seems there are some major alterations that were made in order to get this working on the phone, so they would be critical in moy observation to making a custom rom. other parts are security related, and removing of them could yeild in a fully future unlocked phone. I wouldnt be supprised if there is source in there to alter the bootloader to how you specify, eliminating loki altogether, though that may just be wishful thinking. what i do know is since there is a source code, that there had to be a way to flash it, even if you are not on zvi to begin with. this tells me that the new signatures for the secuity were added after the upgrade, which leads me to believe that the sourcecode contains the information to lock the bootloader and security check it. you may also be able to remove the security check for google apps and sprint apps, so we can remove things at will.
I also have a copy of the ZVI source code for both system and kernel. Interestingly enough, you build it using the stock ICS from google. I will host on my MEGA if your interested, but i would personally go through and do my best to alter the source code to where when compiled you have as close to stock ICS as possible. It seems there are some major alterations that were made in order to get this working on the phone, so they would be critical in moy observation to making a custom rom. other parts are security related, and removing of them could yeild in a fully future unlocked phone. I wouldnt be supprised if there is source in there to alter the bootloader to how you specify, eliminating loki altogether, though that may just be wishful thinking. what i do know is since there is a source code, that there had to be a way to flash it, even if you are not on zvi to begin with. this tells me that the new signatures for the secuity were added after the upgrade, which leads me to believe that the sourcecode contains the information to lock the bootloader and security check it. you may also be able to remove the security check for google apps and sprint apps, so we can remove things at will.
Good feedback. I was under the impression flashing a rom installs a new recovery ie when i was flashing cm roms @ gb, i thought a factory reset was a hang. Maybe because the kernel was unlokied. Anyhow, after testing my iproj repo,i will post results tonightish.
ok, so after thinking on this, i kinda understand what is going on behind the scenes here. try to follow me, and anyone who has better knowlege can either confirm or correct me.
phone aside, speaking entirely on system itsself:
you have the recovery (download mode) embeded. this special mode allows the device to be flashed with the inages it needs to be used. similar to a bios if you will in a sense that it is untouched by the installed system and isnt easily overwritten without special means.
next comes the core layer. this is the actual system bios of the phone (bootloader). this specific phone bootloader controls not only the initilization of the images, and links the drivers to the hardware (and preps the hardware), but seems to have specific signature checks in place. the meathod it checks the image signatures by is hash values (in this case, it checks not a CRC32, but by a SAH1). before it checks these values, as loki dev explained, it checks to see if the phone is a developer phone or not. in our case, and unlokied phone is a non dev phone.
if these values fail from the registered value, it generates a security error. next in the process is either the kernel or the recovery kernel. these need to be lokied to replace them as otherwise they would return a signature error. the recovery kernel is responsible for flashing new system packages, and in our case, different roms. under normal circumstances, it is designed to allow an emergency restore of a rom, or as a way to update the avarage consumers phone.
now to the theory, clarifying what i have deducted so far. we know that the update from ZVC to ZVI locks the bootloader. since source code was released for ZVI, it stands to reason that the source code would contain that information, otherwise we could have compiled a rom by now that easily would have left the bootloader unlocked. we already have our loki in place, so it isnt critical to work with the source for the code that locks the bootloader, but if you are able to remove it and compile a sucessful rom, the need for loki could be eliminated theoretically. the time and effort for this however, seems to be unessicary. the first step is finding out if we can modify our system to our pleasing and detirmine if if generates a security error still. if it does, that it would be wise to look into eliminating the bootloader lock from source and go from there. the next step either way would be to build a rom as purely clean as possible from ics using the google source. this time i mean no cm, aokp, or variants. if we can get a clean ics rom on our phones, its a good indication we can make others. next step would be to build CM preferably 10 - 10.1 since jellybean is a bit better in stability. after that, if i had the ability to build roms, i would try my hand at kitkat for modernization. To be honest, this device has more potential than jellybean, and a good community could mean this device lives much much longer than expected. I am not very technical on the linux specifics, but somehow i can understand what is going on under the hood.
EDIT
In reply to your comment. recovery kernel is not the same as download mode. flashing a new rom can wipe recovery if it was built to do so. if you are making a flashable rom, i would advise replacing the recovery.img with our loki one.
Btw, is anyone working on that cwm recovery? most users prefer it, myself included.
phone aside, speaking entirely on system itsself:
you have the recovery (download mode) embeded. this special mode allows the device to be flashed with the inages it needs to be used. similar to a bios if you will in a sense that it is untouched by the installed system and isnt easily overwritten without special means.
next comes the core layer. this is the actual system bios of the phone (bootloader). this specific phone bootloader controls not only the initilization of the images, and links the drivers to the hardware (and preps the hardware), but seems to have specific signature checks in place. the meathod it checks the image signatures by is hash values (in this case, it checks not a CRC32, but by a SAH1). before it checks these values, as loki dev explained, it checks to see if the phone is a developer phone or not. in our case, and unlokied phone is a non dev phone.
if these values fail from the registered value, it generates a security error. next in the process is either the kernel or the recovery kernel. these need to be lokied to replace them as otherwise they would return a signature error. the recovery kernel is responsible for flashing new system packages, and in our case, different roms. under normal circumstances, it is designed to allow an emergency restore of a rom, or as a way to update the avarage consumers phone.
now to the theory, clarifying what i have deducted so far. we know that the update from ZVC to ZVI locks the bootloader. since source code was released for ZVI, it stands to reason that the source code would contain that information, otherwise we could have compiled a rom by now that easily would have left the bootloader unlocked. we already have our loki in place, so it isnt critical to work with the source for the code that locks the bootloader, but if you are able to remove it and compile a sucessful rom, the need for loki could be eliminated theoretically. the time and effort for this however, seems to be unessicary. the first step is finding out if we can modify our system to our pleasing and detirmine if if generates a security error still. if it does, that it would be wise to look into eliminating the bootloader lock from source and go from there. the next step either way would be to build a rom as purely clean as possible from ics using the google source. this time i mean no cm, aokp, or variants. if we can get a clean ics rom on our phones, its a good indication we can make others. next step would be to build CM preferably 10 - 10.1 since jellybean is a bit better in stability. after that, if i had the ability to build roms, i would try my hand at kitkat for modernization. To be honest, this device has more potential than jellybean, and a good community could mean this device lives much much longer than expected. I am not very technical on the linux specifics, but somehow i can understand what is going on under the hood.
EDIT
In reply to your comment. recovery kernel is not the same as download mode. flashing a new rom can wipe recovery if it was built to do so. if you are making a flashable rom, i would advise replacing the recovery.img with our loki one.
Btw, is anyone working on that cwm recovery? most users prefer it, myself included.
Malicious to LG and sprint maybe
Thats about the gist of it. Me and a buddy used to do this kind of thing to windows games with the goal of multiplayer on games that had limited to multiplayer. It's just a lot harder because i know practically nothing about how to disable arm binaries, x86 is much easier.
To add though, you only need to patch things handled by the boottoloader (recovery and kernel)
@brandon check out playfulgods repo for the ms840 and the one he forked from a vs840
not meaning to doubble post, but while loki is fine for recovery and kernel, what about the error we get in modifying certain parts of the system, e.g. specific apps are uninstalled?
my thoughts exactly ed. i compiled ics since loki and lokied the boot.img, when i flashed the rom i recieved the status 7 error. does loki need to be included within the build? im pretty sure status 7 is due to tampering w/ the packaging lol. @my reasons behind asking for loki functions
edit: after reviewing the last few posts, ed seems to say a new recovery needs loki'd, meaning flashing a rom would indeed flash a new recovery? which is what i was beleiveing as well pre your saying else-wise.@josh.
edit:btw when i speak of recovery, i mean twrp,cwm. not download mode.
editjosh i am familiar with pg's repo's, i used this repo for my gb build and iproj also. which reminds me, i should edit my repo post as what the diff is.(merged sprint board)
edit: why would the open source recovery need loki'd? its the default recovery.
edit: after reviewing the last few posts, ed seems to say a new recovery needs loki'd, meaning flashing a rom would indeed flash a new recovery? which is what i was beleiveing as well pre your saying else-wise.@josh.
edit:btw when i speak of recovery, i mean twrp,cwm. not download mode.
edit
josh i am familiar with pg's repo's, i used this repo for my gb build and iproj also. which reminds me, i should edit my repo post as what the diff is.(merged sprint board)edit: why would the open source recovery need loki'd? its the default recovery.
Last edited:
quore from brandon: edit: why would the open source recovery need loki'd? its the default recovery.
because the default recovery from source is the stock recovery we just loki'd. its the one with signature checks, and thus without reloki'ing it manually or simply using the already loki'd one in a build, it reverts to an unlokied default one. i am not sure if (or how) you can build a system only rom, but either way, you need to eliminate the stock recovery. as feared, it also seems that there is more security checks in place for the apps, which means altering the bootloader from source, preferably eliminating security checks altogether, or possibly loki'ing it if possible. i will ul the source from lg themselves on my mega when i get in this evening. this can be used and abused to get a clean ics result we want. from there we can make it to where the user installs the clean ics first, or make future roms based off of this template. the hardest part is altering the bootloader in a way that makes it function but avoid security checks. theory once agains suggests that due to the nature of the bootloader, one would need to redesign it to function differently while performing the same functions. i honestly havent seen anyone use the source to create a differnt type of bootloader (example, implimenting a nexus style bootloader on a non nexus device), so your on your own there. from what i gather, there are three types of major bootloaders. the nexus ones (easily unlockable to eliminate security checks), the galaxy series (has oden as a workaround and is typically a matter of patience for a quick unlock) and the lg series which has the current security hasing in check. take this with a grain of salt however. i could be completely wrong and the act of unlocking a bootloader eliminates security checks altogether which could mean that just because we loki'd, were not out of **** creek yet. the best thing to do is rewrite the bootloader to an unlocked state through source code, eliminating security checks, which ultimately gives us complete power and control over the device, just as if it was a nexus. i will look into it some more.
because the default recovery from source is the stock recovery we just loki'd. its the one with signature checks, and thus without reloki'ing it manually or simply using the already loki'd one in a build, it reverts to an unlokied default one. i am not sure if (or how) you can build a system only rom, but either way, you need to eliminate the stock recovery. as feared, it also seems that there is more security checks in place for the apps, which means altering the bootloader from source, preferably eliminating security checks altogether, or possibly loki'ing it if possible. i will ul the source from lg themselves on my mega when i get in this evening. this can be used and abused to get a clean ics result we want. from there we can make it to where the user installs the clean ics first, or make future roms based off of this template. the hardest part is altering the bootloader in a way that makes it function but avoid security checks. theory once agains suggests that due to the nature of the bootloader, one would need to redesign it to function differently while performing the same functions. i honestly havent seen anyone use the source to create a differnt type of bootloader (example, implimenting a nexus style bootloader on a non nexus device), so your on your own there. from what i gather, there are three types of major bootloaders. the nexus ones (easily unlockable to eliminate security checks), the galaxy series (has oden as a workaround and is typically a matter of patience for a quick unlock) and the lg series which has the current security hasing in check. take this with a grain of salt however. i could be completely wrong and the act of unlocking a bootloader eliminates security checks altogether which could mean that just because we loki'd, were not out of **** creek yet. the best thing to do is rewrite the bootloader to an unlocked state through source code, eliminating security checks, which ultimately gives us complete power and control over the device, just as if it was a nexus. i will look into it some more.
lol awesome. anyhow, my cord was @ fault (earlier posts.) some ideas before going to work, 1) retry lgflashtool with iproj kernel 2) try rerooting zvk with custom stock kernel. will post results shortly. anyone wanna collab on how to make a bootable rom (loki)? i also flashed rom/flashed kernel (loki) seperately.stock or custom idc, custom preferably, maybe a device tree required.edit :lol, reroot works. heres how. if yer rooted under zvk with voodoo ota rootkeeper as i was. simply flash recovery (lok), flash stock kernel (lok), disable current root under app settings, uninstall ota rootkeeper, power off, factory reset (i think required for unlock process, not sure, i did it anyway) reboot recovery, reboot from recovery. twrp asks if you want su, swipe to agree, navigate to yer apps after rebooting, click supersu installer, click play, click update, watch the supersu widget replace the installer widget before yer very eyes! lmao. not done yet, click the now supersu widget agree to reboot recovery, after rebooting, su. byebye voodoo (for now.)
edit: lgflashtool was successful after flashing iproj kernel, just needed a new usb cord, funtime.
edit: how odd, after flashing my zvk kernel to zvi, ubuntu adb not recognizing however mtp+charging is. shows android upgrading (android+dl bar) momentarily, anyhow twrp works with zvi! (after flashing boot.lok)
Last edited:
It's getting a little hard to keep track of everyones questions, so if I miss one please respond with the things you don't understand and I'll do my best to answer them.
We should probably get an irc channel set up somewhere to better keep in touch. I'll get to work on that and post here with the details.
So to start off,
The LG Source:
The LG Source for our and many devices is made freely available from LG
It is hosted on their webpage here, OpenSource Code Distribution
And specifically our device here, https://www.lg.com/global/support/opensource/opensourceList?types=NAME&search=ls840
These packages only contain the source for the system rom and kernel. Not the bootloader, modem, or any other compiled binaries. Most android bootloaders are based off of the littlekernel project at CAF. It may be possible to try and modify the vanilla lk project to work on our device but not without considerable effort.
LG Security error:
The security error is caused by a compiled binary run by the kernel in it's initramfs ramdisk.
On our phones it is called [SUP]"wallpaper"[/SUP][SUB](can differ on other lg devices)[/SUB], clever LG thought they could disguise it. If anyone is being malicous it's them hah!
A user on XDA named shelnutt2 had figured this out for the LG G2, I sent him our kernel in hopes to remove the security error and the locked bootloader, but I did not have the knowledge I currently have.
The kernel that he gave back has commented a part of the init script that starts the security program [SUP]"wallpaper"[/SUP] which should theoretically remove the lg securtiy error when editing the system rom.
Back then this was pretty much a useless effort because we had no way to get this on to the device with a locked bootloader, I shared this information with another user name progrande and he excitedly posted it on this forum. Though no one could make use of it at the time.
Here is that forum post:
http://forums.androidcentral.com/lg-viper-4g-lte/234978-ics-boot-image-no-lg-security-error.html
The "I AGREE" link is to a kernel image with the stock kernel but a modified ramdisk. If someone were to build a kernel with the modified script in the ramdisk. It could in theory prevent the lg security error. I have been building my kernels with it, but have not yet tested it out. If someone were to give me a sure fire way of testing the security error, I could do it right now.
Sinature checking in the bootloader:
The simplest way to put this is, because of the way the bootloader works, it is possible to modify kernel and recoveries(things handled by the bootloader) so that they trick the bootloader into loading the kernel or recovery on top of the bootloader signature check and patches everything up for booting from there.
The way signature verification works, if you have say, a recovery and modifiy it in any way, even if it is the stock recovery, it will result in a differnt hash of the file and fail the boot process. Even if you take the stock recovery or kernel source and compile it, it will be a different hash because it was compiled by you.
Flashing roms & recovery images:
The way I understand it is you think that flashing something will overwrite your recovery right?
Well this can be true but only if the zip file has a script and recovery telling it to overwrite it with the one in the zip. It is possible to edit the script and disable the part wich replaces the recovery.
Just check what you're flashing before you flash.
You also don't need to loki roms, only things handled by the bootloader, recoveries or kernels.
If I missed any points or understood a question wrong please get back to me when you can, I would like to help you all where I can.
And we're up on freenode!
Server: irc.freenode.net
Channel: #ViperDev
Currently setting up a bouncer so that when I'm not there I can see the chat when i get reconnect
We should probably get an irc channel set up somewhere to better keep in touch. I'll get to work on that and post here with the details.
So to start off,
The LG Source:
The LG Source for our and many devices is made freely available from LG
It is hosted on their webpage here, OpenSource Code Distribution
And specifically our device here, https://www.lg.com/global/support/opensource/opensourceList?types=NAME&search=ls840
These packages only contain the source for the system rom and kernel. Not the bootloader, modem, or any other compiled binaries. Most android bootloaders are based off of the littlekernel project at CAF. It may be possible to try and modify the vanilla lk project to work on our device but not without considerable effort.
LG Security error:
The security error is caused by a compiled binary run by the kernel in it's initramfs ramdisk.
On our phones it is called [SUP]"wallpaper"[/SUP][SUB](can differ on other lg devices)[/SUB], clever LG thought they could disguise it. If anyone is being malicous it's them hah!
A user on XDA named shelnutt2 had figured this out for the LG G2, I sent him our kernel in hopes to remove the security error and the locked bootloader, but I did not have the knowledge I currently have.
The kernel that he gave back has commented a part of the init script that starts the security program [SUP]"wallpaper"[/SUP] which should theoretically remove the lg securtiy error when editing the system rom.
Back then this was pretty much a useless effort because we had no way to get this on to the device with a locked bootloader, I shared this information with another user name progrande and he excitedly posted it on this forum. Though no one could make use of it at the time.
Here is that forum post:
http://forums.androidcentral.com/lg-viper-4g-lte/234978-ics-boot-image-no-lg-security-error.html
The "I AGREE" link is to a kernel image with the stock kernel but a modified ramdisk. If someone were to build a kernel with the modified script in the ramdisk. It could in theory prevent the lg security error. I have been building my kernels with it, but have not yet tested it out. If someone were to give me a sure fire way of testing the security error, I could do it right now.
Sinature checking in the bootloader:
The simplest way to put this is, because of the way the bootloader works, it is possible to modify kernel and recoveries(things handled by the bootloader) so that they trick the bootloader into loading the kernel or recovery on top of the bootloader signature check and patches everything up for booting from there.
The way signature verification works, if you have say, a recovery and modifiy it in any way, even if it is the stock recovery, it will result in a differnt hash of the file and fail the boot process. Even if you take the stock recovery or kernel source and compile it, it will be a different hash because it was compiled by you.
Flashing roms & recovery images:
The way I understand it is you think that flashing something will overwrite your recovery right?
Well this can be true but only if the zip file has a script and recovery telling it to overwrite it with the one in the zip. It is possible to edit the script and disable the part wich replaces the recovery.
Just check what you're flashing before you flash.
You also don't need to loki roms, only things handled by the bootloader, recoveries or kernels.
If I missed any points or understood a question wrong please get back to me when you can, I would like to help you all where I can.
And we're up on freenode!
Server: irc.freenode.net
Channel: #ViperDev
Currently setting up a bouncer so that when I'm not there I can see the chat when i get reconnect
Last edited:
Similar threads
Trending Posts
-
Piel 6 Pro user - Upgrade to a Pixel 8 Pro, or wait for the 9Pro?- Started by Aflaaaak
- Replies: 17
-
uninstall any app using Canta without root
- Started by monkeycsk
- Replies: 4
-
Question Browser Window Repeatedly Closing Since Switching To Gesture Navigation- Started by Sizzers
- Replies: 5
-
Question Is my SD card malfunctioning? Should I worry about data corruption?
- Started by Dazzle
- Replies: 3
-
Facebook
Twitter
Instagram