MobileRead Forums - View Single Post - Development Possible way to enable ADB during next update

kveroneau · 12-20-2010, 02:33 AM

The updated ROMs for my device come pre-rooted, from the OpenEtna project. I think that's how it's spelt. I just take the updates as they are provided. In reality, I could just fork away more money and buy a new device with updated software, like Android 2.1. But since my carrier only let's me update my device on discount within the last year my contract(in order to get me to renew), I'm stuck with an outdated device, or paying a premuim for a brand new top of the line device. I could go used, but I don't trust used devices as much(and they also lack a warranty).

Much like a Desktop PC, the Operating system of most mobile devices can be upgraded. Since LG has been neglecting this, my only choice is to use ROMs compiled by the community with support for my device built-in. This is both the cheaper route, as well as the easiest in some cases. I currently have Android 1.6, tempted on upgrading it to 2.2, which just came out recently for the device. The only way for me to take advantage of these upgrades(which LG has neglected), is to have my phone rooted to use fastboot in order to flash the new NAND images. This is the only thing I use ROOT for, since LG does not support the device anymore, and I bought the device from a friend to replace a Nokia E71 phone I had. If I mess with the phone, and break it, I don't really have a warranty to worry about, and I'm not using it on my carriers network against terms of my contract. I have a seperate Internet key, thus replacing the tethering issue. Which doesn't make sense to me... Like come-on, they say I cannot tether on my phone, but then I can use an Internet key which can surpass the bandwidth that any tether can provide. Since they are both SIM devices, I just swap my SIM and use the data plan from my phone on my laptop via the Internet key. Well, I guess lawyers are writing these contracts, not techies.

I do try to stay on the right of the law in as many cases as possible. I only sway if there is a justification which may go through well in court. For the most part, my carrier should not be-able to detect a device with a different firmware. My device was given to me from my friend, SIM unlocked. So, my carrier really has zero knowledge about the device. As long as I don't do anything to trigger something on their end, it's all good. As for LG, they don't actively monitor their devices for firmware hacks, all they would do is void a warranty, which I don't even have. Warranties are apparently non-transferable, and the device is pretty dated. It's like the IRS stuff, you always want to keep your audits clean, just in case something comes around to get you. You never know when that cell phone carrier may just pull a monitoring log and see something that shouldn't be. Google may also trigger the same thing with their Market in the future to protect developers. Say, the Google Market can detect when a phone is rooted and refuse to execute any DRM protected apps. A special kernel module could be built for this purpose, and it does not need to be GPL'd. Yes, Google can definately make a DRM kernel module non-GPL. It taints the kernel, but under Linux these days, many modules do this, such as nvidia's GPU kernel driver, or VMWare's kernel driver. I can see this happening in Android's near future. A kernel module could also prevent root, for example. If you have seen the advances in NSA's SELinux kernel, it displays potential on what can be controlled from a mere kernel module, its powerful stuff. Although like most hackable devices, a simple buffer overflow can usually assist in gaining access(although I think SELinux has a protection against this...).

Hmm, I am actually tempted on developing a kernel module to prevent SU from working. This would be a very interesting project to see if it can be done. Since the source code for SU exists, I just need to see what system calls it uses and make the module circumvent them. Although it will break applications across the board, if not done right. I'm sure this system call is used for many applications(PAM, login, sudo, glibc, etc...), mainly to log the user in, by changing the UID. However, if the kernel module just proxied the system call, and say no allowing any UID above 1000 to use it, but proxying others through. This may also break SUID permissions as well, but not many apps use SUID for everyday applications. Apache uses it for PHP user switching, so that the scripts run as the user it was written by. But for mobile devices, it appears to be less common.

12-20-2010, 02:33 AM	#14
kveroneau Edge User	The updated ROMs for my device come pre-rooted, from the OpenEtna project. I think that's how it's spelt. I just take the updates as they are provided. In reality, I could just fork away more money and buy a new device with updated software, like Android 2.1. But since my carrier only let's me update my device on discount within the last year my contract(in order to get me to renew), I'm stuck with an outdated device, or paying a premuim for a brand new top of the line device. I could go used, but I don't trust used devices as much(and they also lack a warranty). Much like a Desktop PC, the Operating system of most mobile devices can be upgraded. Since LG has been neglecting this, my only choice is to use ROMs compiled by the community with support for my device built-in. This is both the cheaper route, as well as the easiest in some cases. I currently have Android 1.6, tempted on upgrading it to 2.2, which just came out recently for the device. The only way for me to take advantage of these upgrades(which LG has neglected), is to have my phone rooted to use fastboot in order to flash the new NAND images. This is the only thing I use ROOT for, since LG does not support the device anymore, and I bought the device from a friend to replace a Nokia E71 phone I had. If I mess with the phone, and break it, I don't really have a warranty to worry about, and I'm not using it on my carriers network against terms of my contract. I have a seperate Internet key, thus replacing the tethering issue. Which doesn't make sense to me... Like come-on, they say I cannot tether on my phone, but then I can use an Internet key which can surpass the bandwidth that any tether can provide. Since they are both SIM devices, I just swap my SIM and use the data plan from my phone on my laptop via the Internet key. Well, I guess lawyers are writing these contracts, not techies. I do try to stay on the right of the law in as many cases as possible. I only sway if there is a justification which may go through well in court. For the most part, my carrier should not be-able to detect a device with a different firmware. My device was given to me from my friend, SIM unlocked. So, my carrier really has zero knowledge about the device. As long as I don't do anything to trigger something on their end, it's all good. As for LG, they don't actively monitor their devices for firmware hacks, all they would do is void a warranty, which I don't even have. Warranties are apparently non-transferable, and the device is pretty dated. It's like the IRS stuff, you always want to keep your audits clean, just in case something comes around to get you. You never know when that cell phone carrier may just pull a monitoring log and see something that shouldn't be. Google may also trigger the same thing with their Market in the future to protect developers. Say, the Google Market can detect when a phone is rooted and refuse to execute any DRM protected apps. A special kernel module could be built for this purpose, and it does not need to be GPL'd. Yes, Google can definately make a DRM kernel module non-GPL. It taints the kernel, but under Linux these days, many modules do this, such as nvidia's GPU kernel driver, or VMWare's kernel driver. I can see this happening in Android's near future. A kernel module could also prevent root, for example. If you have seen the advances in NSA's SELinux kernel, it displays potential on what can be controlled from a mere kernel module, its powerful stuff. Although like most hackable devices, a simple buffer overflow can usually assist in gaining access(although I think SELinux has a protection against this...). Hmm, I am actually tempted on developing a kernel module to prevent SU from working. This would be a very interesting project to see if it can be done. Since the source code for SU exists, I just need to see what system calls it uses and make the module circumvent them. Although it will break applications across the board, if not done right. I'm sure this system call is used for many applications(PAM, login, sudo, glibc, etc...), mainly to log the user in, by changing the UID. However, if the kernel module just proxied the system call, and say no allowing any UID above 1000 to use it, but proxying others through. This may also break SUID permissions as well, but not many apps use SUID for everyday applications. Apache uses it for PHP user switching, so that the scripts run as the user it was written by. But for mobile devices, it appears to be less common.