Jump to content

OK so how can we get Lollipop rooted ?


Guest samac
 Share

Recommended Posts

@vampirefo I'm still on kitkat as i can't afford to lose root. Does what you are saying mean that if @samac share his zip, i can get rooted 5.1 by using your tethered twrp?

If so, what state will my Hudl be in if the installation barfs? Still kitkat or 5.1?

If done correctly you would be rooted in 5.1, but with current news that hudl2 is being phased out, I am not sure Tesco will warrant your tablet if something went wrong.

I think for the time being wait for app exploit at the time I suggested using twrp Tesco hadn't lost their android people, nor was there any reason to think they would kill off hudl2.

If something goes wrong with your hudl2 you maybe out of luck.

Not worth the risk.

Link to comment
Share on other sites

I wouldn't trust my Android skills, until I had tested my zip, as I mentioned earlier my Linux skills are OK but I'm an Android Newbie. However I believe that there are 5.1 images available on the net, but I would get an expert to confirm this.

 

samac

Link to comment
Share on other sites

An app like kingroot in time should add an exploit once they find one for 5.1.

The root master app that was uploaded contains no binaries to root x86 only able to root arm, so no it didn't root hudl 2 as claimed by poster.

Link to comment
Share on other sites

So I can fully explode boot.img, droidboot.img and system.new.dat. So it should be possible to modify them to remove or change various aspects of the Hudl2 OTA update. Can someone point me to, or explain, the Android update procedure. In other words how does the OTA go about replacing the installed system.

samac

 

Link to comment
Share on other sites

@robin0800 Thanks for the info.

I'm not a programmer and don't recognise the scripting language, but what I get is:

 

Check the bios version

Check the build date and only update if update is newer

Make sure it is installing on a Hudl2

block_image_update("/dev/block/by-name/system" NOT SURE WHAT THIS DOES

Extract and copy to correct location system.new.dat

Extract and copy to correct location boot.img

Extract and copy to correct location esp.zip

Flash esp.zip

Extract and copy to correct location droidboot.img

wipe cache

 

OK so that is how the OTA update gets on to the Hudl2, but the update was a major update which changed many things, for example there is no mention of signatures, encryption, partitioning, permissions etc. This just seems to be a "make sure I'm on the correct device and copy everything over to make it ready for updating."

How does the upgrade happen?

 

samac

Edited by samac
Link to comment
Share on other sites

From what I seen the update package puts all the files in the correct places then when the phone boots the update is then applied and files changed etc. I've never seen android update like that before.

Link to comment
Share on other sites

So what is the first file called?  Is it init from boot.img, droidboot.img or the files copied into place. Or have they used some other odd method?

samac

Edited by samac
Link to comment
Share on other sites

So what is the first file called?  Is it init from boot.img, droidboot.img or the files copied into place. Or have they used some other odd method?

samac

Im guessing that boot.img checks for the update files (file copied in place) and then the files will be installed or do whatever they do. Im new to this stuff so im not sure.

Link to comment
Share on other sites

  • 2 weeks later...

Many of us I suspect were waiting and hoping that @PaulOBrien would come to the rescue after telling us that he'd acquired another Hudl2. Sadly no further message since October 28...

Link to comment
Share on other sites

I would love to help. I can get into all parts of the update, modify it any way I choose, but until I find out which init file is called first then I'm stuck. Normally for linux the installation media starts a small linux system that sets up your hard drive and then installs the new linux system, when you reboot the new system takes over.

I need to know if is is the same with Lollipop on the Hudl2 and if the setup image is boot.img or droidboot.img or if it is a completely different method, then perhaps I can make the partitions writeable, then possibly and only possibly I might have a rooted image.

samac

Link to comment
Share on other sites

Didn't you say you could read all files inside boot.img?

So I can fully explode boot.img, droidboot.img and system.new.dat

Why don't you check inside them to find out what file is init from 

Link to comment
Share on other sites

There is an init system in each of them and it would be kind of nice if someone actually answered the question which I have asked in several different ways ie. what is the boot procedure for the update.

My intention on starting this thread was to get a number of people to actually collaborate to try to  A) root the new update and B) learn something. As I have mentioned on a number of occasions I know Linux but am an Android Newbie. It is not and has never been my intention to do all the work. So if any one else would like to chip in .....

Once the question has been fully dealt with then I might be able to get a bit further, however I'm just not interested enough to put all the hours in myself.

samac

Link to comment
Share on other sites

I get your point. That might take hours to do. I guess nobody really 1. Wants to try and find out 2. Don't live in UK and so don't have hudl2  3. People don't care

Link to comment
Share on other sites

So you say your linux skills are good? Android technicly is linux. So maybe its the same method as what linux would do. Like i said in an earlier post. boot.img might be the init file.

EDIT: boot.img. The boot.img from the hudl itself or a modded one for rooting puposes? I may have something if its root purposes

Link to comment
Share on other sites

If it is a modded one. Its most likely going to init from boot.img and use droidboot.img to create the droidboot bootloader and that will also load root. Im only taking a guess but its what is most likely going to happen.

Link to comment
Share on other sites

OK so looking at init in boot.img makes me think that it is the one to play with, but we would also have to modify other parts of the system such as fstab

/dev/block/by-name/factory	/factory	ext4	nosuid,nodev,noatime,barrier=1,data=ordered                        	wait                                            
/dev/block/by-name/system 	/system 	ext4	ro,noatime                                                         	wait,verify                                     
/dev/block/by-name/cache  	/cache  	ext4	nosuid,nodev,noatime,barrier=1,data=ordered                        	wait,check                                      
/dev/block/by-name/config 	/config 	ext4	nosuid,nodev,noatime,barrier=1,data=ordered                        	wait                                            
/dev/block/by-name/data   	/data   	ext4	nosuid,nodev,noatime,discard,barrier=1,data=ordered,noauto_da_alloc	wait,check,forceencrypt=/factory/userdata_footer
/dev/block/by-name/logs   	/logs   	ext4	nosuid,nodev,barrier=1,data=ordered                                	wait,check                                      
*/block/mmcblk1*          	auto    	vfat	None	wait,voldmanaged=sdcard1:auto,noemulatedsd                    
*/block/sd*               	auto    	vfat	None	wait,voldmanaged=usbcard1:auto                                

This is where system is made ro and the encryption is called and the nosuid bit is set.

However I'm still at a loss as to why there is apparent duplication in droidboot.img

samac

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.