Related
I just upgraded my X10 mini to Eclair by editing my build.prop and letting SEUS do the rest. However, I wonder how long we SE-Users must wait for Froyo and upcoming.
My idea now: did anyone think of compiling Froyo for X10 mini or other phones? I am interested in starting a project for this if none exists right now, provided the most relevant issues can be solved.
So, I'd like to know
- if there's a way to make all hardware (WLAN,3G,USB...) running without proprietary drivers (don't know yet if e.g. SE uses publically undocumented hardware)
- if its' legal to extract drivers from the proprietary image - if possible anyway (should be technically)
- what about encrypted device storage, meaning parts of bootcode and so on?
- what about testing a potentially self-compiled android on a real phone without the risk to cause unwanted behaviour in the public, meaning, e.g. paralyzing parts of the GSM network...
Always keeping in mind that staying legal is directive #1.
And yes, I can hardly assume how much work this could become. But there are other open source project showing that interesting projects can become a good thing. (writing this on a debian-powered machine...) ;-)
Any chance?
Yours
dkn8
Thread moved to x10 General
This is a good place to start and gather required information -
http://forum.xda-developers.com/showthread.php?t=726813
Yes, thats a long thread, but invaluable if you want to make custom ROMs
>>>> 22Jan2012: linboothkvc v1.0 source released in my linboothkvc thread. It works successfully on Omap3 and Omap4 based devices including NookTab. And with minimal changes/love can work with any rooted arm based linux device <<<<
>>>> 17Jan2012: Kernel module SUCCEEDS on NookTab to reboot into NIRVANA - NO NEED to BREAK the default SECURE BOOT CHAIN and NOTE THAT EVEN THIS CAN WORK ON ANY ROOTED DEVICE and not just NT, with minimal love so ENJOY <<<<
>>>> 16Jan2012: My kernel module based path (linboothkvc) to running custom kernels and roms is almost done, except for a __small part__ to get it running on NT now - IF ONLY PEOPLE HAD WAITED ...., we could have reaped the potential benefit in future, Why not !!!! why not ....WHY NOT !?!?. NOTE that it can allow one to run custom kernel/roms WITH OUT MODIFYING ANY CRITICAL PARTITIONS provided one sets it up properly/appropriately. Source for beta version available in my linboothkvc thread, for the interested developers/experimenters for now ... <<<<
>>>> I may not respond to the posts on this thread currently, because I am trying to get a alternate option called linboothkvc using kernel modules up and running (which will occupy my free time), which AVOIDS the NEED for this flaw in the first place for most of the people out there (i.e Custom ROMS with different kernels). However over the weekends, I will go thro all the posts on this thread <<<<
>>>> 14Jan2012: Initial pre-alpha version of kernel module path based source code uploaded to my linboothkvc thread for those still interested to experiment
http://forum.xda-developers.com/showthread.php?t=1427610
<<<<
Hi All,
If you have been following my posts over the last few days
NOTE: To people frustrated with UART requirement - I understand the restrictions of UART access, but a lot of ROMS can be done with 2ndihkvc or equivalent methods and with out needing a Custom kernel. If someone is talking about Custom/New kernel for Android 4.0 (ICS). Then do note my statement (in NOP BYPASS thread) on POWER of KERNEL MODULES in Linux, IT CAN BE USED TO ACHIEVE what you want to achieve, only that it requires bit more effort, which I or some one else has not put currently... thats all. AND THAT By holding off now, we can _potentially_(Risk is always there) reap the benifit with next years NEXT GEN Nook Tab+ or what ever they call it.
a) I have implemented 2ndihkvc, which follows the same fundamental concept as 2nd-init, but achieves it in a simpler way (Needed because some of the calls used in original 2nd-init doesn't work on NookTab, or have unnecessary dependencies (in this given context, otherwise they are good in them selves) which can be avoided with my simpler method)
b) I have provided the NOP Bypass method of running a modified Ramdisk and also 90% a modified kernel, provided UART access is there.
c) There is still the power of linux KERNEL MODULES to EXPLOIT. (Haven't had time on that yet).
If you ask me, this should cover all category of people. Be it people who want to run custom Roms, or people who want to experiment with Kernel and or other low level stuff for the fun of it.
There is a 4th method which will allow one to achieve (b) above with out requiring UART access or even uSD (potentially . If one reads between the lines from all my posts till date, the answer is hidden in there. Only that I haven't spelt it out directly or in the face. The reason is because It is a fundament flaw (rather there are potentially two at two different levels - one relatively simple and one relatively bit more involved - One I know for sure, another I have to dig bit more) in the way things are done currently in the secure boot chain on this device as well as potentially other devices with same or similar SOC (and or different SOC but with similar boot chain s/w components.
SHOULD WE BE WASTING i.e providing a solution which uses it, when there is already 2ndihkvc and NOP Bypass over UART and also the Linux KERNLE MODULE ROUTE to cater to most peoples needs.
Because if we do, then even the Device manufacturers and their partners will come to know about it and can easily fix it in their Newer/NextGen devices. While if we withhold it for now, we may be able to get access to it on their Next generation Devices with hopefully Arm A15 core or .... (NOTE: Depending on the boot sequence ROOT access may or may not be required for this).
The reason I am asking now is because, few people are asking my help on certain things and the reality is I know that the concept for which they want my inputs/guidance, can be applied at a more fundamental level here (or even at the same level), but that I have not ventured into it because of my delimma above.
NOTE: People who wanted my inputs/guidance wrt uSD, you all know who you are, I know the flaw to achieve what you want to achieve, but it is more powerful than what you all are currently thinking of doing/ ristricting yourselves to (You all have one input/... in there wrt devices . Unless let me think thro further and see if something can be done differently, with out exposing the flaw I have in mind to help you achieve what you want, otherwise i.e if there is nothing else I can come up with, and in turn if you people experiment further and are able to come up with the solution on your own, I would suggest that hold off on it for few days, think thro all the implications keeping what I have mentioned in this thread, and then take a call one way or the other.
Please provide your thoughts on this after thinking thro the options already available on NookTab (root access, kernel modules, UART UBoot access and inturn 2ndihkvc and NOP Bypass or equivalents)
Based on all the feedbacks as well as bit more thinking from my side, I will take a call on this.
Forum moderators I know this is the development portion of the forum, but I wanted feedback from Developers also that is the reason why I have posted here. But beyond that I leave it to you, whether you want this to continue here or move it out.
UART access is not sufficient, as it is required during every reboot of the device if we wanted to have a custom kernel and ROM. This is simply an unacceptable state of affairs. (Say, my tablet turns off while on holiday, or at the airport. What then am I to do? Let is sit and wait off until I can get back home to my UART equipment in order to reboot?
The idea that the UART work around is sufficient is a nice one, however it is wrong.
---
Oh also, it's just a matter of time before they patch the u-boot in the Nook Tablet anyways... so it's not like this UART method is going to stick around forever anyways.
cfoesch said:
UART access is not sufficient, as it is required during every reboot of the device if we wanted to have a custom kernel and ROM. This is simply an unacceptable state of affairs. (Say, my tablet turns off while on holiday, or at the airport. What then am I to do? Let is sit and wait off until I can get back home to my UART equipment in order to reboot?
The idea that the UART work around is sufficient is a nice one, however it is wrong.
---
Oh also, it's just a matter of time before they patch the u-boot in the Nook Tablet anyways... so it's not like this UART method is going to stick around forever anyways.
Click to expand...
Click to collapse
Hi
I understand the restrictions of UART access, but a lot of ROMS can be done with 2ndihkvc or equivalent methods and with out needing a Custom kernel. If someone is talking about Custom/New kernel for Android 4.0 (ICS). Then note my statement (in NOP BYPASS thread) on POWER of KERNEL MODULES in Linux, IT CAN BE USED TO ACHIEVE what you want to achieve, only that it requires bit more effort, which I or some one else has not put currently... thats all.
By holding off now, we can potentially reap the benifit with next years Nook Tab+ or what ever they call it.
Im not a Developer but I've got a few questions. NOP requires to open up your device, so I think probably 95% won't open their device for ICS and I think since the device had a dual core CPU we should get ICS roms. Now my actual question how does your 2init work or how do you install it on our device? But great work so far keep on.
Sent from my SGH-T989
Just out the flaw now. Someone else might reveal it and you won't get the credit.
Don't you want a Wikipedia entry saying that you found this flaw? lol.
PM me about the flaw, I'll see if we should have it outed yet or not (sorry guys, but if it's a decent exploitable flaw and we have other methods, I'm pretty sure I'm with hkvc on it.)
xdahgary said:
Just out the flaw now. Someone else might reveal it and you won't get the credit.
Don't you want a Wikipedia entry saying that you found this flaw? lol.
Click to expand...
Click to collapse
Not worried for 2 reasons,
a) It doesn't bother if my name comes or not. I am exploring just for the fun of exploring.
AND MORE IMPORTANTLY,
b) Actually I have already revealed the flaw in my NOP Bypass thread, indirectly, if only, one reads carefully all my lines as well as between them. Only that I have just replaced one or two of the steps with a different steps thats all for now.
If someone else find the same flaw, he will realise the same, if he reads my posts once again with his new knowledge.
What an awesome idea, we can have a root for the Nook Tablet+ or whatever else in a years time!
...
So, um... what do I do now with my Nook Tablet? It's a piece of garbage now, I guess, so, I'll just return it since it's still within the Holiday return period? I suppose I'll just have to wait for the Nook Tablet+ to have a custom ROM running on my Nook... ("But you can UART hack it!" ... *sigh* I've already explain that that is not sufficient. The UART hack is a stop gap, and should only be stopped at if that is the absolute only option available.)
And I mean no disrespect to xIndirect, but why should he be the lone gatekeeper of what exploits and hacks are out there for the Nook Tablet? I would rather see this exploit before making a decision as well, but I don't think it fair that someone should have privileged access to the exploit. Either release it to everyone or DON'T SAY ANYTHING IN THE FIRST PLACE.
cfoesch, I have no plans to be using the exploit shown for myself. I am not going to be the "lone gatekeeper" I just want to know what it is before I give my full opinion. Chill.
Motorola Defy was locked bootloader too, may be to try and run port Defy bootmenu for Nook Tablet?
source: github.com/CyanogenDefy/android_external_bootmenu
Indirect said:
cfoesch, I have no plans to be using the exploit shown for myself. I am not going to be the "lone gatekeeper" I just want to know what it is before I give my full opinion. Chill.
Click to expand...
Click to collapse
If you buy a plot of land and the seller has accidentally left seeds there and isn't coming back for them, do you grow a garden on your current plot of land, or do you decide not to plant them and hope that the next time you buy a plot of land they might forget some seeds again?
I would rather tend the garden I own than hope for a better plot of land with seeds I may never have.
Cheers!
-M
XDA member since 2007
Sorry if my post is offtopic, I just want to help with development.
My SE Xperia x10 came worh a locked bootloader and devs figured out how to make a bootable recovery (xrecovery) based on CWM, may be with an adaptation for the NT we can get the world of custom roms, even with locked bootloader this crappy phone got cuatom kernels by bypassing the bootloader, hope this give little ligth to you guys the real Developers.
If this post is garbage mods please delate it.
Sent from my BNTV250 using xda premium
Hello, I beleive if there is a software way to get ICS + maybe overclocking it should be tried first as this IS what most people are waiting for. That's the big dream they got. If someone knows how to implement that, then please by all means do so ..
P.S. you said so much where to look for the flaw in your posts that if I was a programmer from B&N I'd know where to look like everybody else. Assuming they are not complete morons they can already figure it out too. Can they plug the hole or not? Is it oversight or permanent design flaw ? We'll see. Best way to keep a secret is to " keep it secret " , ie not talk about it at all. Especially if soft mod ICS, hw acceleration and overclocking already available.
Sent from my LG-P500 using Much Love
First of all hkvc +1 for your efforts.
I voted yes, the NT developers can read between the lines in your posts as well.
Whats life without risks once in a while
Hi All,
I understand very well that even BN devs will be looking and potentially can figure out and fix it. That is the risk, but at one level I don't mind taking the risk and see if it works out to my/our advantage (i.e the bug being still open in a new device (From BN or any other Vendor)) or disadvantage(the bug is either way fixed).
Also the flaw can affect ANY DEVICE (Not just NOOK TAB) using similar secure boot chain not just NookTab, that is also one reason why I am bit wary of releasing the info or a implementation which uses it just like that.
I will share my finding with few people on the forum/outside in few days time so that even If I loose interest in this, there will be few people with the required knowledge (i.e if they haven't already figured out on their own by then (and released something or not ...)).
Also I haven't taken a final call on this yet. I am in a delima, so getting all your opinions also before I decide.
Time permitting I will also attack/explore the KERNEL MODULE PATH in a few days time, so that people don't have to depend on this flaw in the first place, but use the wonderful world of Linux Kernel Modules to achieve what they want.
LexS007 said:
Motorola Defy was locked bootloader too, may be to try and run port Defy bootmenu for Nook Tablet?
source: github.com/CyanogenDefy/android_external_bootmenu
Click to expand...
Click to collapse
Hi,
With my modified 2nd-init (2ndihkvc), you can run bootmenu or any other user space mechanisms already on NookTab
absolutely YES, we r all xdaers, right hehehe. Thanks all devs especially hkvc for the efforts
hkvc said:
Hi,
With my modified 2nd-init (2ndihkvc), you can run bootmenu or any other user space mechanisms already on NookTab
Click to expand...
Click to collapse
It's very good. Thanks!!!
First off, not a dev but read religiously.
2nd, release it if the people who would take advantage of it agree. The rest of us say "great,woohoo!" But I must admit, I can't take advantage of it. But I certainly don't want to make a hardware uart to boot custom roms.
That being said, if its more complicated to install with a different method, that's fine. As long as it doesn't include a soldering iron.
But if it were easier to make a custom rom, or open up more capabilities of the kernal or whathaveyou, well that would attract more developers to make roms, etc. and so on and so forth.
Btw. Yes, exploit may exist if outedin a later tablet, but you found this one.... I have faith the next flaw will be found in the next one too.
A bird in the hand is worth two in the bush.
Posted from my B&N Nook Tablet... rooted of course!
jotekman said:
A bird in the hand is worth two in the bush.
Click to expand...
Click to collapse
I would say this summarizes everything I want to say on the topic.
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
I wish somebody participated in this with you. I need it also /
funkydaemon said:
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
Click to expand...
Click to collapse
Good idea. Although most probably it'll all be native C code compiled into binary form, not amenable to decompiling.
So you'd probably need a very good debugger and a system call tracing facility in strace.
I guess hell might also break loose because SIM encryption(?), voice encoders(?), network locking(?) and god knows how many of those proprietary tidbits may be sitting in there.
SIM encryption broken leading to duplication of SIMs and leading to smartcard encryption and open source tools to reprogram your credit cards with more money.
That's not hell. That's hell in a hand basket with us enjoying the ride
Keep us posted. It's guys like you who think outside the radio that gave us the TV
For Qualcomm based devices you need to decompile Hexagon code.
For other Intel XMM6260 etc based devices suffice IDA (ARM).
In both cases the raw binary blobs may be encrypted, but extractable from running machine.
I'm working on it, in a fashion, and am writing up a document compiling everything that has been done on cellphone radio hacking. I've not found much on baseband firmware; there's a lot of info out there but it's been tough to find amongst all the other hacking that has similar keywords. Currently most quality info around this subject involve an extra (and depending on desired features; expensive) bit of hardware and two open source software packages with their decencies. As the hardware is currently outside my budget ($300 for the best bang for buck) I'll be working on getting the software to recognize the hardware built in my Android devices. Provided that all goes well I should be able to read and write on the frequencies that the in-built hardware supports and hopefully, as I always get an identical device when getting one, read and write with my backup android device. Be warned if you decide to follow me down this path; there are laws restricting what non-licensed persons/companys can do on certain RF frequencies and this depends on where you live, I'm no expert only a person capable of reading lots of dry informative documents, provided I do achieve direct contact between devices this hack could (and likely will) fry one of my antennas so be warned you'll likely do the same :banghead: so do this on an old device that you don't care about before ever trying on something you use daily. With the warning out of the way lets get down to the quick version.
~~~~~~~~~~~~
Currently all the developing I've found educational has involved the before mentioned "expensive hardware" known as software defined radio, shortened to SDR, go a head and pop open a new tab and Google search either. You'll eventually find that cellphone manufacturers have likely already put these into many devices. You'll also hopefully find the two kickstarters, HackRF ~$300 and bladeRF ~$400, these are likely what I'll be saving up for; HackRF for sure as the next release will likely be able to send and receive at the same time instead of switching quickly between modes. If you dig deep enough you'll find a blog post from a hacker that plugged an Android into a much more expensive SDR and was able to place calls and send/receive text; the blog poster stated something to the effect that this was not a useful hack but I believe that it's a great proof of concept and totally worth another look. However, this hacker has also almost been sewed for some of the demonstrations with this kind of technology involving the capture and description of calls and texts so tread carefully.
The software I mentioned before boil down to GNU Radio and Open BTS; there's dependencies for each but all seem to be installable on Linux running on top of Android. Furthermore I see that someone (I'll edit your name in in a sec Edit: idcrisis ) previous mentioned wanting c or c++ support, GNU Radio uses these languages perhaps I can ask for some help when I get a little further in porting this to run without Linux in the middle so much? I think if we use the GPS to set the time then the signal shouldn't drift to much.
I'm using an app called Debian Kit to give me a flavor of Linux called Squeeze for testing the software. If you choose to try what I'm doing then make use of the readme that the developer wrote or the guide I wrote for general Linux on Android installation and interaction fund in my sig to get started. If you want access to the document I'm compiling then you'll want to PM me at this moment as the chances of hardware frying is high and I'll share a link to Google docs; I'll be releasing a full guide when I've figured out how to avoid damage.
Eventually I hope to port many of the functions in GNU Radio into an app that makes use of internal hardware. Currently I've found a few that make use of hardware plugged into Android through USB "on the go" or "host mode" just search "RTL SDR" in the app store and you'll see'em, but, currently nothing making use of internal hardware. If any are interested in joining forces and helping figure out how to do all this I'd be glad to offer any support I can.
Other things related to cellular antenna hacking other than the above mentioned software and hardware that I'm compiling into the same document. Well this is where we get into the parts I'm hitting the wall on. It looks like I'll have to get into Kernel modification as this is one of the things used to communicate between software and hardware. There's also the flashable files known as radios and I'll be digging further in how these files are modified.
Basically this is a very tough question to answer and has taken many months of reading, searching, and more reading to get this close bit if we all work together I know that we'll be able to modify how the antennas in our devices work.
Edit 01142014- Found a guide on reverse engineering embedded device firmware, the guide is on a router but as the chips in our phones are embedded perhaps the steps are similar
http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/
Sent from either my SPH-D700 or myTouch3gs or M470BSA
Guide for running Linux on Android that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
^^ NO! The embedded chips in the Linksys routers are MIPS based and not ARM like all our Androids. Very different, although technique is the same.
But thanks, for taking time to check up on all this.
Any updates ?
Hey Guys,
I'm looking into this, I've successfully extracted files from the OnePlus One's baseband, its running RtOS called REX, QC calls it AMSS.
Have a look at the thread here: http://forum.xda-developers.com/oneplus-one/general/discussion-hlos-reverse-engineering-t3292829
Waiting for the OsmocomBB update it projects
QCOM modem leaked sources.
Type in google/bing: "AU_LINUX_ANDROID_JB_MR1_RB1.04.02.02.050.116_msm8974_JB_MR1_RB1_CL3904528_release_AU"
Hi,
I'm interested in purchasing a Nexus 4 I have no cellphone plan, nor do I want one; instead I intend to use the phone as a tablet or PDA.
I would like to hear some feedback on how feasible it is to low-level remove the cell and gps antennas' capabilities. Is there a driver or kernel module of some sort that could be removed to 'neuter' the phone? Can the hardware run the antennas without the ROM or kernel's consent?
I've already read about the code to reach a developer menu and 'disable radio' as well as 'airplane mode'. Neither of these fit the bill, I want the phone to be incapable of transmitting cell/gps information.
I would love to join the android community, but I will not feel comfortable until I know that the device isn't going to hand over my location to anyone with a crafty enough story at the police department, which I believe makes this question one of security rather than battery life or functionality.
My apologies if this is posted in the wrong section, I decided that the android forum would be most appropriate because I'm curious about how android manages the cellular antenna rather than something specific to the Nexus.
Thanks!,
BigBubbaX said:
Hi,
I'm interested in purchasing a Nexus 4 I have no cellphone plan, nor do I want one; instead I intend to use the phone as a tablet or PDA.
I would like to hear some feedback on how feasible it is to low-level remove the cell and gps antennas' capabilities. Is there a driver or kernel module of some sort that could be removed to 'neuter' the phone? Can the hardware run the antennas without the ROM or kernel's consent?
I've already read about the code to reach a developer menu and 'disable radio' as well as 'airplane mode'. Neither of these fit the bill, I want the phone to be incapable of transmitting cell/gps information.
I would love to join the android community, but I will not feel comfortable until I know that the device isn't going to hand over my location to anyone with a crafty enough story at the police department, which I believe makes this question one of security rather than battery life or functionality.
My apologies if this is posted in the wrong section, I decided that the android forum would be most appropriate because I'm curious about how android manages the cellular antenna rather than something specific to the Nexus.
Thanks!,
Click to expand...
Click to collapse
I am also interested in this...
I bet if one can compile a kernel for his own device, it is possible to disable the GPS and related drives in the module/kernel config.
and this would completely kill the feature... so no risk of any spyware app triggering it etc...
however it may not make sense to use maps on the device... unless you want to bluetooth pair it to another GPS device.
Nexus is great... but I want to be able to do this for a different phone which may not be as popular on here.. than what ?
G
ghatothkach said:
I am also interested in this...
I bet if one can compile a kernel for his own device, it is possible to disable the GPS and related drives in the module/kernel config.
and this would completely kill the feature... so no risk of any spyware app triggering it etc...
however it may not make sense to use maps on the device... unless you want to bluetooth pair it to another GPS device.
Nexus is great... but I want to be able to do this for a different phone which may not be as popular on here.. than what ?
G
Click to expand...
Click to collapse
Hi ghatothkach,
I'm still working on this. First I need to assemble a x64 computer capable of compiling a ROM from source, then I'll see if I can find a way to nullify the radio drivers. If it's possible for the Nexus, I'm pretty sure a similar workflow will be available for your phone.
There are also some other aspects of Android that I'd like to look at for security concerns, such as the way that the phone currently broadcasts a list of wireless networks which it is associated with.
I apologize for digging up an old thread, but has there been any development on this subject? Or physically removing or disabling the GPS receiver on a phone?
6 years later..
Question remains.
Is that possible to root the device and delete the gps driver/kernel completely?
If yes which of the file as to be removed
0
Hi everyone
I have an LG Optimus Vu device and due to LG's tremendous support for this phone, the operating system is still ICS and the kernel version is 2.6.39 (even the I/O scheduler for this phone is set to noop, and there aren't any alternatives :| ). It could be all good and well if there aren't hundreds of crashes appearing every day about different applications, which is driving me crazy. I've searched and searched and it seems that there are no custom ROMs for this phone, nor is there any custom recovery application. I could barely find an application to root this phone.
To get to the point; I'm considering to make a custom ROM for this phone, but I am a noob in these kind of stuff.
I have the kernel source and the original ROM zip file. Since the original OS version is 4.0.4, is it possible to bring the required proprietary drivers from the original and use it in a newer Android version like 4.4.x?
Can I use Google's recent Tegra 3 kernel (3.10) and port those LG specific drivers from the older kernel?
Am I even starting this process in the correct way?
Any help is appreciated.
set-0 said:
Hi everyone
I have an LG Optimus Vu device and due to LG's tremendous support for this phone, the operating system is still ICS and the kernel version is 2.6.39 (even the I/O scheduler for this phone is set to noop, and there aren't any alternatives :| ). It could be all good and well if there aren't hundreds of crashes appearing every day about different applications, which is driving me crazy. I've searched and searched and it seems that there are no custom ROMs for this phone, nor is there any custom recovery application. I could barely find an application to root this phone.
To get to the point; I'm considering to make a custom ROM for this phone, but I am a noob in these kind of stuff.
I have the kernel source and the original ROM zip file. Since the original OS version is 4.0.4, is it possible to bring the required proprietary drivers from the original and use it in a newer Android version like 4.4.x?
Can I use Google's recent Tegra 3 kernel (3.10) and port those LG specific drivers from the older kernel?
Am I even starting this process in the correct way?
Any help is appreciated.
Click to expand...
Click to collapse
Hate to be the bearer of bad news, but you're pretty much stuck. LG has locked the bootloader on it and has said they have no plans on unlocking it. Since the phone is around a year and a half old or older, I'd imagine they aren't going to change their minds all of a sudden for the relatively small amount of people still using the phone.
http://forum.xda-developers.com/showthread.php?t=2055272 - discussion about your phone here
FYI
What is a bootloader?
The bootloader is the first thing that starts up when a phone is turned on. At its most basic level, a bootloader is the low-level software on your phone that keeps you from breaking it. It is used to check and verify the software running on your phone before it loads. Think of it like a security guard scanning all the code to make sure everything is in order. If you were to try to load software onto the phone that was not properly signed by the device vendor, the bootloader would detect that and refuse to install it on the device.
When we speak about locked bootloaders, the context is often used to give meaning to the term “locked.” Almost all phones ship from the factory with locked bootloaders, but some are encrypted as well. It is this encryption that most reports are referring to when using the term “locked.” If a bootloader is encrypted, users can’t unlock it to load custom software of any sort. The device will be restricted to running software ROMs provided by the manufacturer.
Now, there are ways to unlock or circumvent bootloaders in special situations, but with ones that have no dev support like yours, it's pretty much a lost cause and most likely way beyond your capabilities to figure out without spending 100s of hours of learning about Android stuff. This is not a knock on you or anything of the sort, but it is what it is. It is a very difficult thing to figure out encrypted bootloaders even for the most experienced android developers and hackers and depending on how they are encrypted, there just might not be a way (ask the older Moto phones, especially from VZW).
es0tericcha0s said:
Hate to be the bearer of bad news, but you're pretty much stuck. LG has locked the bootloader on it and has said they have no plans on unlocking it. Since the phone is around a year and a half old or older, I'd imagine they aren't going to change their minds all of a sudden for the relatively small amount of people still using the phone.
...
Now, there are ways to unlock or circumvent bootloaders in special situations, but with ones that have no dev support like yours, it's pretty much a lost cause and most likely way beyond your capabilities to figure out without spending 100s of hours of learning about Android stuff. This is not a knock on you or anything of the sort, but it is what it is. It is a very difficult thing to figure out encrypted bootloaders even for the most experienced android developers and hackers and depending on how they are encrypted, there just might not be a way (ask the older Moto phones, especially from VZW).
Click to expand...
Click to collapse
Two thumbs up for the detailed reply.
Shame really. The phone was released in November 2012 but there wasn't a single OS update...
I guess I would have to give up on that, but I'm interested in system level developments for both Android and desktop systems. Any idea where to start?
set-0 said:
Two thumbs up for the detailed reply.
Shame really. The phone was released in November 2012 but there wasn't a single OS update...
I guess I would have to give up on that, but I'm interested in system level developments for both Android and desktop systems. Any idea where to start?
Click to expand...
Click to collapse
Yea, it does suck. That's one of the downfalls to making 8 million different phones. You have no incentive ($$$), no interest, and no manpower to be able to update them all in a reasonable fashion. But it's not like LG is alone. All of the manufacturers have had decent phones just...disappear in regards to updates or anything of the sort.
As far as getting started, there is a ton of info right here on XDA:
http://xda-university.com/
Modify hashes?
Hi!
Sorry for digging out a dead thread, but for the p895 probably all threads are more or less dead...
I wonder if it is really necessary to decrypt the bootloader. Since it must be able to boot different versions of the stock roms, it would probably only calculate a hash value of some files and compare that to a value stored elsewhere.
By comparing different versions of stock roms it might be possible to get some information about what files are hashed. If it is a standard hash algorithm and the comparison value the bootloader uses is stored in plain text (hope....!) there might be an atack vector in
comparing several known plain texts.
I also noticed, that the p895 has a "software integrity check" in the hidden menu that shows has values for some (a lot) of files. these hash values are likely already calculated when entering that menu option (i am pretty certain because they show immediately), so they might belong to the files checked at boot time and also hint to the hash algorith used.
The idea is to calculate a hash value for the custom rom and put it in the appropriate place so the bootloader thinks of the rom as an update.
These are just vage ideas, but i have no intention whatsoever to buy a new phone anytime soon and I guess I could as well spend "some" time tinkering and learning the tech details...
thank you!