Related
I have just updated my Prime and I did not have rooted it with ICS. Is possible to root JB without previous rooting?
No. You must back up root using OTA Rootkeeper in order to regain root in JB. There is no known exploit for JB yet.
without restoring root with ota rootkeeper, try http://matthill.eu/mobile/root-trans...lybean-update/ and follow the instructions, follow the links for the files you need
tonesy said:
without restoring root with ota rootkeeper, try http://matthill.eu/mobile/root-trans...lybean-update/ and follow the instructions, follow the links for the files you need
Click to expand...
Click to collapse
lol, must be a joke.... dead link.
I have been actively pursuing this. Without bootloader unlock i dont beleive so.
If you Unlock the Bootloader or already have an Unlocked Bootloader, you can get root.
I haven't seen any exploits posted for the Prime in JB yet, so this may be your only way for now.
hx4700 Killer said:
lol, must be a joke.... dead link.
I have been actively pursuing this. Without bootloader unlock i dont beleive so.
Click to expand...
Click to collapse
He posted a bad link but doesnt work if you have no root access at all. This is just a "regain root if you have partial root" guide:
http://matthill.eu/?s=jelly+bean
Thread moved
Thread moved. This is clearly belonging into Q&A. Please post in correct Sub-Forum.
peace
jotha - forum moderator
Does any one know if one person with development capabilty is trying to find a way to root JB ?
I talked to bin4ry about his root method in hopes of working with him on modifications for the prime but he is telling me his mod is making the change he is exploiting according to what I am seeing but possibly ASUS disabled the emulator mode in this version of the OS. This is what would give you root access via ADB so changes can be made.
I couldnt get out of him what exactly his "restore timing exploit" is but I understand everthing after that
Outside of anything coming up I would say if you must have it now and don't mind voiding your warranty then use the unlocker tool and follow one of many guides on here to do it from an unlocked device.
Perhaps we can turn this thread into, or possibly start a new one about the different things people(devs and/or the technically savy) are finding in the quest for an exploit...
We could start with a list of what is known. Of particular interest would be the differences between the complete stock (me btw), was rooted but lost it, was rooted and kept it, and of course anybody who has managed to root it by messing around but not taken notes along the way.
here's what I have found.
from the PC, creating an adb shell allows me to ls /data/local/tmp/ but from a tablet's terminal emulator (shell?) I cant.
Typing id from both it becomes obvious why
From adb shell I get
Code:
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009
(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt)
,3003(inet),3006(net_bw_stats)
from the tablet I get
Code:
uid=10126(u0_a126) gid=10126(u0_a126) groups=1015(sdcard_rw), 1028(sdcard_r),
3003(inet)
I was getting excited last night (burnt the midnight oil) trying what I thought might be a possible exploit with an android supplied command called "run-as". Its limitaions became obvious when I looked at the source code for it. You need an application pakage that is debugable and it cd's to its directory to run the command and a bunch of other things, so I compiled it on C4droid using just the main functions setresuid() and setresgid() but they both failed no matter what value was plugged into them based on UID and GID found here
http://forum.xda-developers.com/showthread.php?t=442557
I have yet to exhaust this avenue. I might be able to create an empty package and sign it as a system app, make it debugable and see what that yeilds but its looking like a convoluted process, espicially considering that run as may not work as intended on prime's JB
PS I want to state that I know precious little about linux and even less about the android layer above it...
Just as an FYI the way bin4rys tool is supposed to work is an exploit in which it makes a symlink to /data/local.prop and injects ro.kernel.qemu=1 in to local.prop then reboots.
This is supposed to put the device in emulator mode and when you connect with adb shell you get a root shell prompt. All the rest is fairly straightforward/standard. Remount file system as RW, install SU and superuser.apk with their permissions set properly in the proper places then break the symlink to local.prop and reboot.
What would help a lot is if someone who is already rooted can make the attempt, set qemu = 1 in the relinked local.prop then adb shell connect to see if you get a root prompt. Trying to confirm that emulator mode is enabled and you get root access as shell to see if this is even worth pursuing.
I would just use the unlocker tool but I am 2 weeks in to ownership of a new unit.
yes I have seen that typing adb root gives the message
Code:
adbd cannot run as root in production builds
it would indeed be interesting to see if changing "qemu" flags it as a non-production build. My sgs is rooted with CM10 nightlies might try toggling the value on that and see what adb says
Run-as
abazz said:
I was getting excited last night (burnt the midnight oil) trying what I thought might be a possible exploit with an android supplied command called "run-as". Its limitaions became obvious when I looked at the source code for it. You need an application pakage that is debugable and it cd's to its directory to run the command and a bunch of other things, so I compiled it on C4droid using just the main functions setresuid() and setresgid() but they both failed no matter what value was plugged into them based on UID and GID found here
http://forum.xda-developers.com/showthread.php?t=442557
Click to expand...
Click to collapse
Yes. I noticed the permissions on that file as well. I'm not an android person, so I don't know how that end works, but the permissions do look correct (setuid root, and runnable as group shell [which we get via adb, but not locally on terminal].
Based on the little bit that I have read, it seems that it may be getting the permissions assigned to the apk and running the command line with those permissions.
If that is correct, then running it via something with c4droid probably won't work, as it's permissions are whatever group it (c4droid?) was assigned at install.
So, how do does one / can one specify that the package is supposed to be root (uid 0). I'd guess (from a standard UNIX security perspective) that you can't just push arbitrary apps to the machine with 'run me as root' permissions. Otherwise, this would be a completely non-issue. But, is there a package which is pre-installed that we can exploit the permissions of to do this? I don't know yet.
Also, if my readings / assumptions were correct above, we probably don't want to do a setreuid(), but rather call bash/busybox as the 'command' issued in the name of the apk (since it would then run as root, or the uid of the package). Either that, or a system command(s) to chown/chmod the su binary that we can upload via adb (but which comes in as shell.shell).
Did you find the source for run-as somewhere? It would be interesting to look at to see if such a thing is possible. Failing that, it would be interesting to see if there were any sorts of buffer overflows that could be run against it. I've never tried such on arm7, but I've done it under UNIX on x86 and Sparc.
Thanks
Schemm
elschemm said:
Yes. I noticed the permissions on that file as well. I'm not an android person, so I don't know how that end works, but the permissions do look correct (setuid root, and runnable as group shell [which we get via adb, but not locally on terminal].
Based on the little bit that I have read, it seems that it may be getting the permissions assigned to the apk and running the command line with those permissions.
If that is correct, then running it via something with c4droid probably won't work, as it's permissions are whatever group it (c4droid?) was assigned at install.
Click to expand...
Click to collapse
Yes you are correct. setresuid() function will not give you permissions greater than the process its running in
So, how do does one / can one specify that the package is supposed to be root (uid 0). I'd guess (from a standard UNIX security perspective) that you can't just push arbitrary apps to the machine with 'run me as root' permissions. Otherwise, this would be a completely non-issue. But, is there a package which is pre-installed that we can exploit the permissions of to do this? I don't know yet.
Click to expand...
Click to collapse
Its worse than that, the package also has to be debuggable
There is some info out there on how to sing a package with the appropriate system permissions so it would be interesting to actually do this and see what, if anything can be done.
I downloaded the asus unlock package and passed it through the apk tool to see what it does, as it obviously would need root access. As root access is all i require the code it shows is irrelevant really, its the fact that it gains root access with its signature and also the uid that is set in the manifest android.sharedUserID="adroid.uid.system". This and, most importantly android.permission.MOUNT_UNMOUNT_FILESYSTEMS. WIthoput these things we cant change anything in the directories we need
Also, if my readings / assumptions were correct above, we probably don't want to do a setreuid(), but rather call bash/busybox as the 'command' issued in the name of the apk (since it would then run as root, or the uid of the package). Either that, or a system command(s) to chown/chmod the su binary that we can upload via adb (but which comes in as shell.shell).
Click to expand...
Click to collapse
Yes thats what we would do from the run-as command. What I was attempting to see was if I could get a root uid by creating a c program that uses the setresuid() function call thereby bypassing the need to have an appropriate package installed. As it didn't work I'm having dounts whether it would work even if the right package was there. run-as did make reference to package.h which I haven't looked at, so unless there are some system parameters that package.c extracts from the apk I dont really see how this will work...
Did you find the source for run-as somewhere? It would be interesting to look at to see if such a thing is possible. Failing that, it would be interesting to see if there were any sorts of buffer overflows that could be run against it. I've never tried such on arm7, but I've done it under UNIX on x86 and Sparc.
Thanks
Schemm
Click to expand...
Click to collapse
Yeah found the source here
I also searched for linux exploits, there are massive lists of them, most of them patched by now but I assume the linux base in JB would be somewhat different to whats getting around on X86 systems
On anather note I have tried bin4ry's "root many" method , using the restore timing exploit but had no luck.
HX... I looked through the scripts and all the misc files in bin4ry's zip package and could not find anything remotely indicating an injection of the qemu value. It make a symbolic link to the build.prop in com.android.settings...../file99, which was succesfull after pressing restore but thats about it. perhaps I should fire up ubuntu and try the linux script instead of the windows .bat file
Interestingly, this guys root method for the Razr M makes use of Run-as if you look at the batch file.
He is essentially doing a "fake package" install then runs an exe that is some sort of exploit. Finally he uses run-as against what I have to assume is the bug report feature of the droid and asks you to trigger a bug report with a button sequence.
So it seems he is getting something that has root privileges (bug report) to do something that grants SU and also implimenting run-as
http://forum.xda-developers.com/showthread.php?p=32889627#post32889627
I fear that remained a few developers interested in finding a way to root transformer prime with jelly bean, because all of them had tablet already rooted with ics and managed in mantaining rooting across upgrade.
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
lionclaw said:
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
Click to expand...
Click to collapse
Wayyyy out of my area of expertise, but here's my (completely novice) best guess.
>All Chromebooks are write-protected with a screw on the motherboard
>Putting a Chromebook in developer mode allows for some tinkering ie things like chroots, and on the asus flip, the ability to install apks from unknown sources.
>Unscrewing the write-protect screw allows for the ability to completely install a new operating system or dual boot setup.
>Maybe you need to do that before you're able to accomplish root access?
My other idea would be to try and figure out a way of doing a systemless root?
Also, total aside but since this is the only thread I've found on XDA about this device, I think chroots are theoretically possible now without the need to be in developer mode via Android apps (even without root on Android). Download the GIMP port from the Play Store to see what I'm talking about. Playing around with that for a few minutes really made me wish that it didn't use emulated mouse/keyboard in it's implementation. Also, it appears that apt-get is broken, but regardless it might interest someone out there looking for a project.
back from the dead, any progress on this?
I have been able to successfully root the Android image on my Asus Flip.
I built a blank image with dd in /usr/local, formatted it with mkfs, mounted it to a folder, mounted the original system.raw.img to a folder, copied the files across, placed *all* the SuperSU files listed as 'required' in the SuperSU update-binary in the relevant places in /system in my new image, set permissions & contexts for those files, edited arc-system-mount.conf and arc-ureadahead.conf to point to the new image and, finally, patched /etc/selinux/arc/policy/policy.30 with the SuperSU sepolicy patching tool in order to boot my rooted Android instance with selinux set to enforcing.
I have created a couple of scripts which more-or-less fully automate this procedure, which can be downloaded from nolirium.blogspot.com. Please feel free to download, open the scripts in a text editor to check them out, and try them out if you like. Only tested on Asus Flip, though.
I seem to be unable to post attachments at the moment so I will just add the descriptions here, I could probably post the entire scripts here too if anyone wants. Feel free to let me know what you think.
DESCRIPTIONS:
1-3.sh
Combines the first three scripts listed below.
01Makecontainer.sh
Creates an 900MB filesystem image in /usr/local/Android_Images, formats it, then copies Android system files therein.
02Editconf.sh
Modifies two system files: arc-system-mount.conf - changing the mount-as-read-only flag and replacing the Android system image location with a new location; and arc-ureadahead.conf - again replacing the Android system image location. Originals are renamed .old - copies of which are also placed in /usr/local/Backup.
03Androidroot.sh
Mounts the previously created Android filesystem image to a folder, and copies SuperSU files to the mounted image as specified in the SuperSU update-binary.
04SEpatch.sh
Copies an SELinux policy file found at /etc/selinux/arc/policy/policy.30 to the Downloads folder, opens an Android root shell for the SuperSU policy patching command to be entered, then copies the patched policy back to the original location. A copy of the original policy.30 is saved at /etc/selinux/arc/policy/policy.30.old and /usr/local/Backup/policy.30.old
Uninstall.sh
Removes the folder /usr/local/Android_Images and attempts to restore the modified system files arc-system-mount.conf and arc-ureadahead.conf.
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
keithkaaos said:
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
Click to expand...
Click to collapse
The R13 has a 64-bit Mediatek processor, right?
I have added a version for ARM64, but I haven't tested it.
You can find the instructions and scripts at nolirium.blogspot.com
ya, its a mediatek. and thanks ill go see if i can find it
---------- Post added at 03:31 AM ---------- Previous post was at 02:58 AM ----------
wow, ok. i can do this but im not sure i want to.. after reading the possible problems i may run into. Im going to be getting the G. Home in a couple weeks and i gotta keep things running smooth. This seems like going a tad too far then i need to. The other day i had action launcher going and it looked pretty damn good but i really want to try and get the action3.apk that i have put into the pri-app folder or whatever the chromebook uses i found the syst folder but cant access it. Im wondering if i make the machine writable it would work but im afraid of losing my updates, as long as i could do them manualy, i guess that would be cool. Also since im already going on... has anyone found a way to disable the dev boot screen without tinkering with the physical chromebook yet?
SuperSU on Chromebook
Hey there I love this post but unfortunately im on the mediatek (well not unfortunately cause i love it) but i do really want super su .. But i found this other post that i tried out but i am having a problem executing the scripts. When i go to run the first one, it says can not open "name of script" but the dev takes a pretty cool approach. Im still new to Chrome OS but thanks for the post and if you have any advice on executing scripts id love to hear it!! http://nolirium.blogspot.com/
I'm guessing the above post was moved from another thread...
Anyway, it turns out that zipping/unzipping the files in Chrome OS's file manager sets all the permissions to read-only. Apologies! sudo chmod+x *scriptname* should fix it...
Regarding OS updates, I actually haven't had a problem receiving auto-updates with software write-protect switched off; the main possible potential issue I could imagine arising from the procedure I outlined would involve restoring the original conf files if both sets of backups get deleted/overwritten. This seems unlikely, but in that case either manually editing the files to insert the original string (/opt/google/containers/android/system.raw.img), or doing a powerwash with forced update might be necessary in order to get the original Android container booting again.
I don't think anyone's found a way to shorten/disable the dev boot screen without removing the hardware write-protect screw - from what I've read, the flags are set in a part of the firmware which is essentially read-only unless the screw is removed. Perhaps at some point the Chrome OS devs will get fed up of reading reports from users whose relatives accidentally reset the device by pressing spacebar, and change the setup. Here's hoping.
Hey just jumpig in the thread right quick to see if these instructions are old or what-- got a chromebook pro and the notion of having to update a squashed filesystem every timeto install su seems like a pain..
Is there any kind of authoritative documentation/breakdown regarding what Chromeos is mounting where before I start breaking things? Also anyone happen to know if there's a write-protect screw anywhere in the chromebook plus/pro?
Other questions:
* adbd is running, but is not accessible from adb in the (linux) shell, which shows no devices. Do I need to access adb from another device (i'm short a usb c cable right now) or can I use adb (which is there!) on the chrome side to access adbd on the android side?
* Anyone know if adb via tcp/ip is available? Don't see it in the android settings.
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
I'll attach them to this post in case anyone wants to take a look. There's a readme in the zip, some more details can also be found here and below
EDIT: Fixed the SE Linux issue occurring with the previous version I uploaded (it was launching daemonsu from u:r:init:s0 instead of u:r:supersu:s0).
Anyone considering giving them a spin should bear in mind that the method does involve creating a fairly large file on the device as a rooted copy of the android rootfs. (1GB for arm, 1.4GB for Intel). There's a readme in the zip but the other couple of important points are that:
a) The SuperSU 2.82 SR1 zip also needs to be downloaded and extracted to ~/Downloads on the Chromebook.
b) Rootfs verification needs to be off. The command to force this is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
or the regular command to do it is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
c) If, subsequent to running the scripts, there's a problem loading Android apps (e.g. after a powerwash or failed install), the command to restore the original rootfs image is:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Hey this is a great response.. thanks!
Nolirum said:
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
Click to expand...
Click to collapse
verity
Yeah playing with it now, I'm looking at these /etc/init/arc-*-conf files... I see that the /dev/loop# files are being set up... (more below)
Nolirum said:
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
Click to expand...
Click to collapse
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is? (update: I guess that's what rootfs verification does, and we can turn it off....)
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Nolirum said:
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
Click to expand...
Click to collapse
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Nolirum said:
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Click to expand...
Click to collapse
Heh.. not gonna be me..
Nolirum said:
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
Click to expand...
Click to collapse
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon... btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example... would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default witho no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Nolirum said:
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
Click to expand...
Click to collapse
Cool I'll take a look at these scripts.
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
fattire said:
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
Click to expand...
Click to collapse
Oh, the arc-setup-env thing is intentional. There does appear to be another issue with the x86 version though. I've written up a detailed response to your previous post; it's in a text file at the moment so I'll copy it over and format it for posting here with quotes etc now - should only take a few minutes. Yeah, sticking them on github might be a good idea; I've been meaning to create an account over there anyway.
Yeah, so... Regarding the scripts, since I've put them up here for people to download - I should mention that the first person to test them (aside from me) has reported that something's not working right (I'm waiting for confirmation but I think he tried out the x86 version). It's likely either an error on my part when copying across from my Arm version, or perhaps something not working right with conditionals, meant to deal with the various OS versions ('if; then' statements, I mean). Once I find out more, I'll edit my earlier post...
fattire said:
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is?
Click to expand...
Click to collapse
Oh, sorry for being a bit vague - I just mean perhaps implementing a kind of systemless root à la Magisk/SuperSU (from what I understand of how these work) - avoiding the need to actually replace files in /system. Since I'm mainly just using su for the privileges rather than actually wanting to write to /system, I had the idea that perhaps a sort of overlay on e.g. xbin and a few other locations, rather than actually rebuilding the whole of /system, might be an interesting approach....
Yep, I've been replacing /opt/google/containers/android/system.raw.img with a symlink to my modified image lately. Works fine... I think they've been focused on just getting the apps working properly, maybe something like dm-verity is still to come.
Although, one of the cool things with Chromebooks IMO is that once the Developer Mode (virtual) switch has been flipped, the system's pretty open to being hacked around with. I think a large part of the much-trumpeted "security" of the system is thanks to the regular mode/Dev mode feature, once in Dev Mode with verified boot disabled on the rootfs, we can pretty much do what we want (I like the message that comes up in the shell when entering the first command I posted under the spoiler - it literally says "YOU ARE ON YOUR OWN!").
So yeah, with Dev Mode switched off, verified boot switched on, we can't even get into the shell (just the walled-off 'crosh' prompt), making the system indeed rather secure (but, for some of us, rather limited).
fattire said:
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Click to expand...
Click to collapse
That's what I mean by a moving target, lol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61. Problems with being on the more 'bleeding edge' channels include:
#Sometimes stuff gets broken as they commit experimental changes.
#Any updates sometimes overwrite rootfs customizations; the higher the channel - the more frequent the updates occur.
#Some of the stuff that gets updated, may later get reverted.
And so on...
fattire said:
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Click to expand...
Click to collapse
Yeah you'd think so. Honestly, the more I use CrOS the more it seems like a (very polished) work-in-progress to me. Though, I guess most modern OSs are also works-in-progress though. (I don't mean the former statement in a critical way; I'm very happy that new features keep getting added to the OS - Android app support being a perfect case in point, that was a lovely surprise, greatly extending the functionality of my Chromebook).
fattire said:
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon...
Click to expand...
Click to collapse
Netcat's not there but socat, which I haven't any experience with but have seen described as a "more advanced version of netcat", is listed in /etc/portage/make.profile/package.installable, meaning that adding it to CrOS is supported, and as simple as:
Code:
sudo su -
dev_install #(sets up portage in /usr/local)
emerge socat
I tried socat out and it seems to work, might be interesting to play around with.
fattire said:
btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example...
Click to expand...
Click to collapse
Theres a question. I forget some of the exact details now (gleaned from browsing the developer mailing lists and the documentation on chromium.org), but from what I do remember and my experiences tinkering, I can say:
The auto-update model uses kernel/rootfs pairs, e.g. at the moment my device is booting from partition 2 (KERN-A) with the rootfs being partition 3 (ROOTFS-B). My understanding is that with the next OS update pushed to my device, CrOS will download the deltas of the files to be changed, and apply the changes to partitions 4 and 5 (KERN-B and ROOTS-B), setting new kernel GPT flags (priority=, tries=, successful=), which will, post-reboot, let the BIOS know that 4 and 5 will form the new working kernel/rootfs pair. Then the following update will do the same, but with partitions 2 and 3, and so on and so forth, alternating pairs each time. It's a pretty nifty system, and I think something similar might be happening with new Android devices from version O onward (?).
So partitions 2,3,4,5 are fair game for being overwritten (from the perspective of the CrOS updater program). Partition 1, the 'stateful partition') is a bit special, in addition to a big old encrypted file containing all of the userdata (/home/chronos/ dir?), it also has some extra dirs which get overlaid on the rootfs at boot. If you have a look in /mnt/stateful/, there should also be a dir called 'dev_image', which (on a device in Dev mode) gets mounted up over /usr/local/ at boot. As I mentioned above, if you do
Code:
sudo su -
dev_install
you can then emerge anything listed in /etc/portage/make.profile/package.installable (not a great deal of stuff admittedly, compared to Gentoo), which gets installed to subdirs in /usr/local/. So I think stuff in partition 1; /mnt/stateful/, should be safe from being overwritten with an OS update. I think crouton chroots get put there by default.
Most of the other partitions don't really get used, and shouldn't get touched by the updater, here's a design doc on the disk format, and here's a Reddit post (from a Google/Chromium employee) mentioning dual booting from partitions 6 and 7.
fattire said:
would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
Click to expand...
Click to collapse
It's not too hard to mess up the system and get it into an unbootable state, lol. The "powerwash" just seems to remove user data, mainly. If you change up (the contents of) some files in /etc, or /opt, for example, then powerwash, normally they won't get restored to their original state (unless you also change release channel).
But, as long as the write-protect screw's not been removed and the original BIOS overwritten, it's always possible to make a recovery USB in Chrome's Recovery Utility on another device, and then restore the entire disk image fresh (this does overwrite all partitions). Another thing that I did was make a usb to boot into Kali; I was experimenting with the cgpt flags on my internal drive and got it into an unbootable state, but was still able to boot into Kali with Ctrl+U, and restore the flags manually from there. (To successfully boot from USB, it was essential to have previously run the enable_dev_usb_boot or crossystem dev_boot_usb=1 command in CrOS). I understand also that the BIOS type varies with device release date and CPU architecture, and that Intel devices may have some extra potential BIOS options ('legacy boot').
fattire said:
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default with no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Click to expand...
Click to collapse
I think I saw something related to this on the bug tracker. If I come across any info, I'll let you know...
fattire said:
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Click to expand...
Click to collapse
Yeah, I haven't built Chromium OS or anything, but apparently, there's an option to create a 'private' overlay for the build, which doesn't get synced with the public stuff.
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
"That article is a little misleading in terms of open source. While the wayland-server and services that communicate with the ARC++ container are open source, the actual ARC++ container is not."
Perhaps they're waiting to see how similar implementations of Android within a larger Linux setup (e.g. Anbox) fare.
There doesn't seem to be too much that differs from AOSP in the ARC++ container - a few binaries and bits and pieces linking the hardware to the container (e.g. the camera etc), maybe some stuff related to running in a container with the graphics being piped out to Wayland?, and so on.
Oh, I was searching the bug tracker for something else, and just saw this (quoted below). Looks like it might be possible to run AOSP based images on CrOS soon!
arc: Implement android settings link for AOSP image
Reported by [email protected], Today (72 minutes ago)
Status: Started
Pri: 1
Type: Bug
M-60
When ARC started without the Play Store support there is no way for user to activate Android settings. We need implement corresponded section that has
Title: Android settings:
Link: Manage android preferences:
Inner bug: b/62945384
Click to expand...
Click to collapse
Great response! I read it once and I'll read it again in more detail then will probably have questions For whatever it may be worth, my only experience with chromiumos was building the whole thing maybe 4 years ago for my original 2011 Samsung "snow" Chromebook-- and making a bootable USB (or was it an SDcard?) to run it on (with a modified firmware that did... something I can't remember.. i think it was basically a stripped down uboot and I remember adding a simple menu or something-- I think I was trying to bypass that white startupscreen or something..). However, after doing this a few times to play with it, I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
I did have it re-partitioned to run linux as a dual boot from the SD slot or something-- I remember using that cgpt thing to select the different boot modes and vaguely recall the way it would A/B the updates (which "O" is now doing)... but anyhoo I was using the armhf ubuntu releases with the native kernel and ran into all kinds of sound issues and framebuffer only was a little crappy so...
I'm gonna re-read in more detail soon and I'm sure I'll have questions-- one of which will be-- assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
ol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61.
Click to expand...
Click to collapse
This is the -env file I'm missing, I presume?
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
Click to expand...
Click to collapse
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
* what else... I dunno watch this space.
An update from a couple of guys that have tested out the scripts on Intel: It seems to be that while they are able to launch daemonsu manually (with daemonsu --auto-daemon), it apparently does not seem to be getting launched at boot.
I am waiting for some more information on this. Previously, for Marshmallow, the script was setting up the app_process hijack method in order to to launch daemonsu at boot; to support Nougat I changed it to instead create an .rc file with a service for daemonsu, and add a line to init.rc importing it. This works for me, and from what I can gather, it copied/created all files successfully on the testers devices, too, so I'm not sure at this point what the issue is there.
Edit: Fixed the issue. I updated my previous post with further details.
fattire said:
I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
Click to expand...
Click to collapse
lol yeah. True, that.
fattire said:
...assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
Click to expand...
Click to collapse
It's literally just two things that differ: the few lines where we copy the su binary over e.g.
/x86/su.pie → /system/xbin/su, daemonsu, sugote
vs
/armv7/su → /system/xbin/su, daemonsu, sugote
...and also the size of the created container. The x86 container is about 30 percent larger than the Arm one.
I had a little look at how to determine the CPU architecture programmatically on Chrome OS a while back, but couldn't seem to find a reliable way of doing this, at least not without maybe getting a bunch of people with different CrOS devices to run something like, as you mentioned, uname -i (which returns 'Rockchip' on my device, uname -m (which returns 'armv7'), or such similar, and collating the results. It was just easier to do separate versions for x86/arm, rather than introduce more conditionals (with potential for errors). I'm certainly not averse to adding a check for $ARCH, and thus standardizing the script, as long as it's reliable.
fattire said:
This is the -env file I'm missing, I presume?
Click to expand...
Click to collapse
Yep! It's just the same few envs as in the .confs, moved into a new file. I'm fairly confident that the script's conditionals deals with them OK.
fattire said:
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Click to expand...
Click to collapse
Yeah, although the respondant there perhaps doesn't seem to realise that he's talking to a Google/Chromium dev, the way he responds. Not that that makes anything he says in his post is necessarily less valid, though.
fattire said:
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
Click to expand...
Click to collapse
Interesting... I agree, those would both be useful additions to the functionality of ARC++...
Quick question-- has Samsung provided the source for the GPL components (including the kernel, obviously)? I looked here but didn't see anything...? Previously the kernel was included along with the chromium source and there was like a kernel and kernel-next repository.. but this was like five years ago. I think the codename for the samsung chromebook pro is called caroline... let me quickly see if I can find a defconfig in the chromium source...
Back.. nothing here in the chromeos-4.4 branch. Nothing here either in the master branch. Maybe I'm looking in the wrong branches-- master is probably mainline kernel. Also the directories.. it took me five minutes to realize it wasn't going to be in arch/arm - force of habit I guess. I'll keep looking unless anyone knows. This "chromium-container-vm-x86" one seems to have dm_verity as an unused option. Ah, this is looking promising.
...and... here!
So it would seem that this would be built as part of the chromiumos build system, which seemed to be half gentoo five years ago building out of a chroot and was kind of a pain to set up... still, I'm guessing that since it's got that weird script to make the defconfig, what you could do is use google's chromiumos build script to make the kernel image (with whatever changes you want), then, assuming that it doesn't care if you replace the kernel, just throw it over the right Kernel A/B partition and see if it boots and starts up chromeos... it's weird cuz the kernel has to do double-duty for chromeos and android.. but I bet you can just replace it and it would work fine...
I had a cursory go at building a couple of kernel modules for my Flip C100 a while back - I didn't get too far though, lol. People do seem to have had success building their own kernels and running them with Chrome OS though, as with most things I suppose it's just how much time/effort you're willing to put in.
I think I used this and maybe this, from the crouton project to guide me.
From what I remember, I just got fed up of all the arcane errors/config choices. I remember that even though I'd imported my current device config from modprobe configs, there were then such an incredibly long string of hoops/config choices to have to go through one by one, to then be confronted with various errors (different every time ISTR) that I think I just thought "screw this". I think there were some other issue with the Ubuntu version I was using at the time as well. I know that sort of stuff's kind of par for the course with kernel compilation, but I was mainly only doing it so I could edit xpad in order to get my joypad working, in the end I found a different solution.
It shouldn't be too much hassle though, in theory I guess.... Oh, also, in order to get a freshly built kernel booting up with the CrOS rootfs, in addition to the gpt flags, I think you might have to sign it, too? (just with the devkeys & vbutil_kernel tool provided on the rootfs), some info here, and here.
From what I remember, the build system would do whatever key signing was necessary.... although I do now remember you're right there was some manual step when I was building the kernel, but I can't remember if that's because of MY changes or that was just part of the build process.
I I just dug out the old VM (Xubuntu) I was using to build and, well, let's just say I'll be doing a LOT of ubuntu updates before I can even realistically look at this. I do kinda recall setting up the environment was a huge pain so I'm going to see if I can just update the 5 year old source, target the pro and just build the kernel image and see what pops out the other end. At least I won't have to deal with the cross compiler, though I think it should hopefully take care of that itself.
Interesting to see that those crouton projects have emerged (no pun intended) so I'll check them out too while ubuntu updates itself
Thanks for the github links.. I'm going to go read that wiki.
Update: Looked at it-- funny they just stripped out the chromeos-specific parts they needed rather than emerge everything which is smart. My only question is now that Android is involved, there's that script I linked to earlier that seems to say "if you want Android support you'll need these bits too"-- wonder if the same config scripts apply, and if there are any other device tree considerations as well...
I may play a bit and see how smoothly it goes.. Unfortunately I don't have unlimited time either :/
Also, please do let me know if you put the scripts on github and I can send you pull requests if I come up with anything.
Update: Finally updated like 3 major versions of ubuntu... the "depot_tools" repo had its last commit in 2013, so I updated that. Wow, this is so much clearer than previous docs... it looks like something called gclient is used now, which I configured with:
gclient config --spec 'solutions = [
{
"url": "https://chromium.googlesource.com/chromium/src.git",
"managed": False,
"name": "src",
"deps_file": ".DEPS.git",
"custom_deps": {},
},
]
'
that let me do gclient sync --nohooks --no-history ...which i think is updating the ancient source. I probably should have just started over, but anyway... we'll see what happens.
Update again: After updating with this new gclinet tool, it appears that the old repo sync method is still required as described here. That hasn't changed after all, so now I'm going to go through this old method, which will probably completely overwhelm my storage as it's downloading with history.. but anyway, in case anyone is trying this-- looks like the whole chroot/repo sync thing may still be how it's done... the /src directory described above may only be for building just the browser, not the whole OS...
...and here it is. I will have zero room to actually build anything tho, but hey.
* [new branch] release-R58-9334.B-caroline-chromeos-3.18 -> cros/release-R58-9334.B-caroline-chromeos-3.18
Note to self: use cros_sdk --enter to actually get in the chroot. Then:
~/trunk/src/scripts $ ./setup_board --board=caroline
to set up the build for caroline. Then to build:
./build_packages --board=caroline --nowithdebug
Useful links:
* Building ChromiumOS
* [URL="http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq"]eBuild FAQ
[/URL]
Hello dear community, how can I root Wiko Lenny 5?
I would be very grateful for any idea. Thank you in advance!
No TWRP recovery
deadlyassin said:
Hello dear community, how can I root Wiko Lenny 5?
I would be very grateful for any idea. Thank you in advance!
Click to expand...
Click to collapse
Hi, there is no TWRP recovery at moment for this model, only unlock bootloader. Look here github com/phhusson treble_experimentations wiki Wiko-Lenny5
ROM for Lenny5
Would you mind uploading your firmware for testing? or sending a link to it...
My model: W_K400
I need to install the Recovery TWRP? Or Custom Rom? Or LineageOS? Or Root?
All nothing? Well, i am waiting. Thanks for your answer!
Wiko Lenny 5
Hey Peeps
I did some research on the Lenny 5 as i got this phone a few weeks ago.
There is at the moment, and to my knowledge, no Lenny 5 stock firmware available. I contacted Wiko Germany, asking if there is any place i missed and they answered me in the sense of:
"at the moment there is no stock firmware available online, refer to de[dot]wikomobile[dot]com/maj.php?telephone=2270 where a stock firmware should be uploaded shortly."
Still they didn't upload the file yet, so there only patience will help, if anything at all.
Another possible way i wanted to raise attention to is the site www[dot]wikogeek[dot]com/ where under www[dot]wikogeek[dot]com/index.php?telephone=LENNY5 there is a source seemingly for the phone system, although i don't know, what partitions of the phone system, if not all, are contained in the source code. Following the included Instructions, and doing some further research, i managed to compile some sort of Image which might be the way to get working partition images for the phone. I couldn't examine the image contents using a few different image explorers, so i cannot even tell how to work with the image if its of use at all.
I thought, maybe some of the more experienced users of this board could maybe work with this information to get something like TWRP to work even without having the stock firmware images. As this is my only working phone and my experience is little, i will not do any changes to the phone partitions as long as im not sure the result is a) working, as expected (no recovery required), or b) completely recoverable (at least to factory state), but maybe others are more courageous and want to try.
Hope this helps getting this topic to the latest state. Sorry for the non-URLs, i made the account specifically to contribute to this topic and my post count is to low to post complete urls.
ivelischt said:
Hey Peeps
I did some research on the Lenny 5 as i got this phone a few weeks ago.
There is at the moment, and to my knowledge, no Lenny 5 stock firmware available. I contacted Wiko Germany, asking if there is any place i missed and they answered me in the sense of:
"at the moment there is no stock firmware available online, refer to de[dot]wikomobile[dot]com/maj.php?telephone=2270 where a stock firmware should be uploaded shortly."
Still they didn't upload the file yet, so there only patience will help, if anything at all.
Another possible way i wanted to raise attention to is the site www[dot]wikogeek[dot]com/ where under www[dot]wikogeek[dot]com/index.php?telephone=LENNY5 there is a source seemingly for the phone system, although i don't know, what partitions of the phone system, if not all, are contained in the source code. Following the included Instructions, and doing some further research, i managed to compile some sort of Image which might be the way to get working partition images for the phone. I couldn't examine the image contents using a few different image explorers, so i cannot even tell how to work with the image if its of use at all.
I thought, maybe some of the more experienced users of this board could maybe work with this information to get something like TWRP to work even without having the stock firmware images. As this is my only working phone and my experience is little, i will not do any changes to the phone partitions as long as im not sure the result is a) working, as expected (no recovery required), or b) completely recoverable (at least to factory state), but maybe others are more courageous and want to try.
Hope this helps getting this topic to the latest state. Sorry for the non-URLs, i made the account specifically to contribute to this topic and my post count is to low to post complete urls.
Click to expand...
Click to collapse
Ok so Wiko Released the Firmware! Its a Windows software that downloads and flashes the ROM, and it makes a folder with stuff in it. Maybe experienced people can look into it and build TWRP?!! I would really love twrp but I don't have the experience :crying: . Hope developers see this
Matt 123456789 said:
Ok so Wiko Released the Firmware! Its a Windows software that downloads and flashes the ROM, and it makes a folder with stuff in it. Maybe experienced people can look into it and build TWRP?!! I would really love twrp but I don't have the experience :crying: . Hope developers see this
Click to expand...
Click to collapse
Would you mind adding a link to the firmware you've found?
edit: got it
Are you able to develop a TWRP?
Matt 123456789 said:
Are you able to develop a TWRP?
Click to expand...
Click to collapse
Nope, sorry. I just didn't get at first what firmware you refered to (the link i posted in the first place).
As i stated above, i don't know for sure, if the wikogeek-source really contains all of the files required to build anymore than (if even) the bootloader.
More experienced people would need to take a look into it.
Best regards
Hey again there, folks
Im not a excessive internet user and i may be off the site for months in series. i cannot guarantee any form of support, but if i happen to stumble across this thread and see questions that i can answer, i will do my best to do so. i hope i can encourage others to engage in the treble community in making this solution public. treble is not my work and i have nothing to do with it. maybe there is also a way to get twrp-treble versions, but i don't know what are the technical limits of that. what i want to say: i will not be responsable for your tries to hack your phone. if i can help i will, but i'm no pro in all of this at all!!!
This guide is quite long, but take care to not make mistakes, as it is reduced to what you really *NEED* to make this root method work. ALWAYS REMEMBER TO READ THE FULL GUIDE AND COMPLETELY PREPARING YOUR WORKSTATION BEFORE DOING ANY OF THE STEPS BELOW!!!
After some idling i decided to take another look into Lenny 5 rooting and stumbled across a way to do it pretty straightforward, but first of all:
*THIS GUIDE ASSUMES BASIC KNOWLEDGE ABOUT COMPUTERS AND FLASHING SMARTPHONES. IT ALSO ASSUMES THAT YOU KNOW WHAT ADB, FASTBOOT, ROM, IMAGE, VIRTUAL MACHINE, WORKING WITH WINDOWS AND UNIX PATHS AND OPERATING SYSTEMS, ETC. MEAN AND ARE FAMILIAR WITH THEIR USAGE. I WILL NOT PUBLISH ANY FORM OF PREPARED IMAGES NOR ANYTHING TO SPEED UP THIS PROCESS, AS IT MAKES YOU AWARE OF THE RISKS IN IT. I UNDERSTAND THIS AS SOME SORT OF COMMUNITY EFFORT, WHERE I JUST PRESENT ONE WAY OF GETTING WHERE YOU WANT TO GO. IF YOU DON'T THINK YOU CAN APPLY TO ALL OF THE REQUIREMENTS IN THIS GUIDE, YOU SHOULD CONSIDER TAKING DISTANCE FROM USING THIS GUIDE FOR YOUR ROOTING BEHALF.
DISCLAIMER: By using this method to Root your Lenny 5 you will lose all WARRANTY, DATA ON THE PHONE, YOU WILL NOT BE ABLE TO RETURN TO STOCK FIRMWARE as Wiko still did not share their SFW installer and i did not dig deeper into Source compilation. And LAST BUT VERY IMPORTANT: I DO NOT TAKE ANY RESPONSIBILITY FOR ANY DAMAGE ON YOUR PHONE. WHATEVER YOU DO IS AT YOUR OWN RISK!!! READ ALL OF THE TEXT AS THERE MIGHT BE CRUCIAL INFORMATION IN IT, WHICH I DIDN'T ESPECIALLY HIGHLIGHT. Allthough i will do my best.
DO NOT ATTEMPT ANY FLASHING UNTIL YOU GOT YOUR WORKING FIRMWARE IMAGE AT STEP 3 (3. Flashing the new Image to the Device). EXPERIENCED USERS MAY WANT TO FLASH A UNTOUCHED TREBLE IMAGE, WHICH IS ALSO POSSIBLE. YOU SHOULD ONLY EVER REFLASH YOUR DEVICE WHEN YOU ARE ABSOULTELY SURE ABOUT WHAT YOU DO AND THE (POSSIBLE) CONSEQUENCES OF WHAT YOU DO, INCLUDING, SOFT-/HARDBRICK, PERMANENT DAMAGE, AND OTHER NASTY STUFF. YOU TAKE FULL RESPONSABILITY FOR ANY OF THE STEPS YOU DO, ESPECIALLY BEYOND STEP 3!!!
I REPEAT: YOUR LENNY5 DOES NOT NEED TO BE CONNECTED OR EVEN TOUCHED TO YOUR COMPUTER AT ALL UNTIL STEP 3 (3. Flashing the new Image to the Device)!!!*
!!!READ THE BUGS LIST AND HELP OTHERS BY REPORTING OTHER BUGS YOU'VE FOUND IN THIS THREAD. IT IS IMPORTANT THAT YOU KNOW WHAT YOU ARE DOING HERE, BEFORE COMPLETELY MESSING UP WITH YOUR PHONES STORAGE!!! SO YOU BETTER READ THE WHOLE THREAD BEFORE TRYING ANYTHING
There is no Root-only method i know, SO BE AWARE, you are completely rearranging your Lenny 5 Firmware, which is the reason for complete data loss. Wiko DENIES ALL RESPONSABILITY when you unlock your bootloader, according to "phhusson", which is the reason you will lose all warranty.
Known bugs until now:
- On dual SIM handys, if you tell the handy to let you choose the sim card for each call, it will hang after choosing the Sim. The call will not happen. This is a Treble issue. To work around this, select the SIM you want to use in the preferences prior to making the call.
- It seems that after installing a newer Version of the AOSP image provided by phhusson, it is impossible to downgrade to an earlier version of the ROM. This might also be a bug in my device from tampering around with it. But it causes me to be unable to flash any other version than the newest one. If i do so, my device is stuck in a bootloop and i need to reset and reflash it via adb and fastboot. Maybe others can confirm/disregard this behaviour.
- This guide does not solve updating your phone, maybe i can deliver a solution to that at a later point. Until then, you will be urged to reflash your system each time an update is deployed.
- The configuration in this guide is gapps-less, although you might choose a treble-image, that's got them installed. I did not yet manage to install the opengapps-package seperately, as theres yet no solution to custom recovery (that i'm aware of) and i did not (yet) find out how to include it via the kitchen.
-many apps will require you to have at least basic gapps installed. you could compile treble aosp with the amount of google apps you need or use the gapps-img instead.
I will try to give an exact sequence of what to do to Root your Lenny 5 device, but some experimentation afterwards might be needed to get your best experience. Note that, depending on version and "bloating" of your new Firmware, you may experience more or less strong performance breakdowns. Be careful not to overload it, your Lenny 5's hardware is... lets say... not the best out there
Table of Contents:
0. Before starting
1. Preparing your Workstation
1.1.1 Get your copy of lubuntu 18+ (19 is recommended, the version of lubuntu i used in the whole process was 19.04)
1.1.2 Install Oracle Virtual Box
1.1.3 Install lubuntu 18+
1.1.4 Install openjdk-8+ (8 is recommended, i use that version, too)
1.1.5 Install python
1.2.1 Install samba
1.2.2 Configure samba
1.2.3 Connect to sambashare
1.3.1 A few words about handling file permissions in Linux
1.4.1 Get your copy of SuperR's Kitchen (what we do can be done in the Free version)
1.4.2 Install SuperR's Kitchen
2. Preparing your SuperR installation for your Custom AOSP Rom
2.1 Find out which Treble image you need
2.2 Copy and Extract your Treble image
2.3 Editing the contents (Rooting, etc.) of the Treble image
2.4 Repacking the Treble image
3. Flashing the new Image to the Device
4. Final words
0. Before starting
PLEASE CAREFULLY READ THESE STEPS BEFORE STARTING THE PROCESS!! There's a few things to say before starting to do this. I will use this section to note that.
ad 1.:
- If you are using (L)ubuntu 18+ or the corresponding Debian distributions, and already have OpenJDK-8(+)(-JRE) installed, you should be able to move straight to SuperR's kitchen installation. If the kitchen complains about missing OpenJDK, try installing OpenJDK-8(+)-JDK as well.
ad 1.1.1:
- I recommend placing a "Workfolder" somewhere on your host system, so you have all the corresponding data in one place. This helps accelerate the process a lot. In the rest of the document, i will always assume, that you have a workfolder and use it for all the files.
ad 1.1.3:
- i use 25GB for my virtual disk as i only unpack compiled ROMS (as for this guide). if you plan to use the VM for compiling sources, you should be well above 75 to 100GB as the source trees are HUGE.
ad 1.2.1:
- We will also create a workfolder on the virtual system, but this one we will take care of in the main tutorial steps.
- To make samba work, we need to make sure that VirtualBox connects to your Network as required. To do so, on the VirtualBox top menubar, Click on Devices -> Network -> Network Settings...
In the Drop-Down "Attached to:" choose "Bridged Adapter". Make sure that the "Name" Drop-Down shows the name of your physical LAN-Adapter. This way your Virtual Machine will obtain an IP from your local network router instead of NATing with your Host Machine as router. Click Okay. You can check the Network Mode change by using
Code:
ip a
in the terminal. If you want to make sure it changed the mode, restart your virtual machine and reopen the terminal by using CTRL+ALT+T again.
ad 2.1. the wiki-guide on Lenny 5 says "tested on v18". i had v18 installed on my system, but at some point it denied function. i don't know if this is a downgrade-issue or something else, but if you want to stick with it and are able to install it, feel free. but be aware that it does not contain the most recent security patches. i instead stick to AOSP8.1_v32 at the time of writing this guide.
ad 3. i assume that you have already installed adb. otherwise you can get it here in the forums or the specific wiko version from here. (WikoGeek Website) Just click on the download link.
it is important that you learn, that ~/android/... means the same as \\<yourvirtualdeviceip\androshare, if you closely follow this guide, especially the network and samba configuration.
1. Preparing your workstation
To prepare your workstation you must get a Debianesque Linux Environment running, as Windows (and Mac) User, the easiest way to get to this, is to install a Virtual Machine. For the sake of freelyness (is this even a word? ) we'll stick with Oracle's VirtualBox. This seems to be a lot of work, but it took me less than 2 hours to be completely ready to tamper with my image files. So lets begin.
Users on the correct systems ((L)ubuntu/Debian with Java 8 and python installed) can skip to 1.2.1
1.1.1 Get your copy of lubuntu 18+
Go to https://lubuntu.net/ and download lubuntu 18 if your pc hardware is 32-bit only, or lubuntu 19 for 64-bit hardware. You can do this by clicking the corresponding blue buttons on the main page or, if this doesn't apply anymore, find them in the Download section under the "previous lubuntu releases". Download the Image file and store it in your Workfolder
1.1.2 Install Oracle VirtualBox
From now on, all the steps mentioned will be either on the host-machine or the virtual machine i will clearly mark this out to avoid misunderstandings. Users already on correct systems will have to work-around these conceptions a little bit, but all in all the process should be the same for every workstation.
To install Virtual Box on the host-machine, get the installer for your host-system-architecture from https://www.virtualbox.org/wiki/Downloads. Follow the On-Screen-Instructions for the Installer to Setup VirtualBox for you. (I had it installed already, so i don't know the exact order of it. But maybe some of the users testing this out could come up with a quick "tutorial" for this step.) Most of the settings should be standard values.
After finishing the installation (and restarting?) you should now be able to Open the VirtualBox Manager via Desktop or Start Menu (whatever your host-OS offers, we will be sticking to Windows as host).
1.1.3 Install lubuntu 18+
In VirtualBox on your host-machine, create a "New" machine by clicking the button on the top left of the manager. As the name, choose how you want to memorize your virtual machine for later usage.
Use "Linux" as Type and "Ubuntu (32-bit/64-bit, choose appropriately)" as Version.
Your memory doesn't necessarily need to be gigantic. Still, i reserved 4GB of RAM for mine, and would recommend at least 2GB.
Check the radio button to "Create a virtual hard disk now" and click on "Create"
In the next dialog choose the Location for your VHD to be stored. The storage location should have around 25 GB of free space (read on section 0. for additional notes about storage space).
Choose your VHD size, i used 25GB to have some reserve, just in case. Click on Create. Choose your newly created virtual machine and select start from the top shortcut bar.
VirtualBox will come up with a new window and in it a dialog, asking for a installation medium for your new virtual machine. Click on the button to "Choose a virtual optical disk file..." and choose your previously stored Lubuntu disk image to mount as start-up disk. Click on Start, wait, then choose your Language. I recommend using english, so its easier to follow the tutorial, but this is up to you.
After that, you will be allowed to "Start Lubuntu" which we choose our virtual machine to do. The startup should be quite fast, from my experience. As soon as you get presented with your new (yet non-persistent) virtual desktop click on the icon to "Install Lubuntu xx.xx"
Soon the Lubuntu installer will come up, asking for the Language to be used. We'll keep American English (again, your choice) for now and click Next.
Choose your timezone and Region and click next. Choose your corresponding keyboard Layout, make sure it's the right one and click Next. In the next dialog step choose "Erase disk", leave the rest be and click Next.
On the next page, i recommend keeping it simple, as this is just a virtual machine, which ever only runs when you decide to extract and repack images. Enter "your" name, choose a login name, give the virtual machine a simple, locally-unique network name and choose a password for elevated rights operations. Remember, keep it simple, it will ease your work. I recommend to "Log in automatically without asking for the password" but i leave it to you to decide that. Click Next.
In the summary, check if you are okay with the Settings you entered, then click on Install.
Confirm the warning dialog with Install now.
Now it's all about Linux magic happening to create for you a persistent operating system on your virtual hard disk.
As the Installer asks you to Restart, do so by clicking on Done. Let the virtual machine reboot. When asked to do so, remove the installation medium (VirtualBox automatically does this for you, the options for this are under the main menu "Devices -> Optical Drives") and press ENTER.
After starting up, (and entering your password, if you didn't check the autologin checkbox), you are presented with your Desktop. On your keyboard press CTRL + SHIFT + T to open a terminal.
On a normal machine you should always keep your firewall on and setup. you can easily setup ufw for samba, but as we just crank around at a virtual machine (ideally behind a NAT-Router), it will be easier to just turn off the firewall alltogether by using
Code:
sudo ufw disable
in the terminal window (when asked for a password, enter your virtual machine user's password and press ENTER. at UNIX-like terminals it is normal that the password you enter will not be shown. don't worry, it's typing, just hiding. it will tell you after pressing ENTER, if its the right one or not.)
1.1.4 Install openjdk-8+
To install JDK on Lubuntu we use the built-in software installer. The following commands will update the system and install openjdk-8-jre
Code:
sudo apt update
you will be asked to enter your account password, enter password and confirm with ENTER
Code:
sudo apt dist-upgrade
confirm by typing "Y" into your keyboard and press ENTER.
This process will take a while, depending on your hardware and internet connection.
Code:
sudo apt install openjdk-8-jre
when asked, if you accept the changes to be made, type "Y" again and press ENTER.
this chain updates the virtual system packages and installs openjdk-8.
To check whether OpenJDK 8 JRE is installed, use the command
Code:
java --version
the output should be something like:
Code:
openjdk version "[B]1.8.0_222[/B]"
the bold part is the important, as it tells you that you have version 1.8.x, which is OpenJDK 8
Code:
OpenJDK Runtime Environment (build [B]1.8.0_222[/B]...
shows that the JRE version on your virtual machine is the same as the major openjdk version which is good.
1.1.5 Install python
To install python, use
Code:
sudo apt install python
this will install the required packages and configure them.
1.2.1 Install samba
To move files between your virtual machine and your host machine, the easiest way to do so is to use samba. It is easy to configure and fulfills our needs. To install samba enter
Code:
sudo apt install samba
into the terminal on your virtual machine and press ENTER. If asked, confirm changes with Y and ENTER.
1.2.2 Configure samba
We will configure samba in a way, so we don't need to "sudo" all of the time to use superr's kitchen, but instead use it as our autologin user. For this we will enter the following in our terminal (make sure that you didn't elevate ["sudo -i"] your terminal session, otherwise use exit, to return to unelevated session)
Code:
mkdir ~/android
chown -R [B]<yourusername>[/B]:[B]<yourusername>[/B] ~/android
cd ~/android
(the term "~/android" basically is a synonyme for "/home/<yourusername>/android; the ~ marks the path as inside your users /home/... directory)
this creates a folder called android in your virtual machine users home directory and changes the bash-path into it.
enter
Code:
sudo nano /etc/samba/smb.conf
to the terminal and press enter. this will open a console text editor with the samba configuration file. use PgDn or the Down-Arrow-Key to reach the end of the file and then append the following "code"
for <yourusername> use the username you selected during your virtual machine installation. its visible in the terminal before the ":" sign in the format
Code:
[B]username[/B]@[U]virtual[/U]machinename: ~$
Code:
[androshare]
comment = Android Share
path = /home/[B]<yourusername>[/B]/android
browseable = yes
read only = no
public = yes
create mask = 0644
directory mask = 0755
force user = [B]<yourusername>[/B]
save the changes by pressing CTRL + O on the keyboard and confirm with the ENTER key.
you can use the bash-command
Code:
testparm
and push ENTER to see your role configuration, and if you have made any mistakes in entering the configuration data.
to restart samba and make the share available enter
Code:
sudo service smbd restart
into the terminal and press ENTER.
sometimes the kitchen needs elevation for some tasks and will then write files that belong to the user "root". the easiest way to work around that is to sporadically use and memorize for later usage
Code:
sudo chown -R [B]<yourusername>[/B]:[B]<yourusername>[/B] ~/android
this will set file ownership to your user and thus allows you and shared samba-instances (as they are forced to run as your user) to regain read-write access to the respective files.
if you struggle with this, try asking in a new post (or maybe someone asked already?), maybe i or others can help you.
now you should be able to connect to your samba share.
1.2.3 Connect to sambashare
to connect to your newly created samba share, on your windows host machine use WIN + R or Startmenu -> Run... and enter \\<yourdeviceip>\androshare and press ENTER.
for other ways to connect to samba shares according to your host operating system, i must ask you to check google. this guide is long already, anyways. but its easily possible on any system (win,macos,linux,...)
to find your device ip, on the virtual machine enter the following into the terminal
Code:
ip a
you need to find the address obtained by your router. you normally find it under something like
Code:
1: lo:
...
inet 127.0.0.1/8 ...
2: enp0sX
...
inet [B]192.168.x.x[/B]
...
the bold part is important, while the upper address "127.0.0.1" is your local loopback address and not what we are looking for.
on your host machine enter the bold ip at <yourdeviceip> like this
Code:
\\[B]192.168.x.x[/B]\androshare
and press ENTER. this should open your Sambashare
1.3 A few words about handling file permissions in Linux
Sometimes SuperR's kitchen may create or modify files that are owned by root user, which prohibits you from changing these files without elevating via sudo. This is easily corrected by again using
Code:
chown -R [B]<yourusername>[/B]:[B]<yourusername>[/B] ~/android
if there are still files you can't access you can maybe fix it with
Code:
sudo chmod a+rwx ~/android/<fileyoucantmodify>
1.4.1 Get your copy of SuperR's Kitchen
SuperR's kitchen can be obtained at The Official SuperR's Kitchen Thread. Get the latest version. I use 1.2.1.1.
Download it to your host machine and put it into your host workfolder. from there, copy it to your \\virtualmachine\androshare directory.
1.4.2 Install SuperR's Kitchen
to install superr's kitchen, we need to unzip it. on the virtual host, type
Code:
cd ~/android
unzip [B]SuperRs-Kitchen_Linux-64_v1.2.1.1.zip[/B]
press ENTER and the archive should extract. if it did not extract, and instead throws an error about the package "unzip" beeing unknown to the system, use
Code:
sudo apt install unzip
to easily solve this problem, and repeat the upper step.
you can confirm that that unpacking was successfull by entering
Code:
ls -l ~/android/
into your terminal. the result should show at least a folder called "tools" and a file called "superr".
after confirming the correct extraction, use
Code:
rm [B]SuperRs-Kitchen_Linux-64_v1.2.1.1.zip[/B]
to delete the ZIP-File
replace the bold part with your SuperRs Kitchen ZIP-File Name.
Your ~/android directory should now contain 3 Elements, namely "README.md, superr" and a directory called "tools".
If everything went fine, you should now be able to start the kitchen by typing
Code:
./superr
into the terminal and pressing ENTER. if you are beeing told that you don't have permission to run this file as an executable, use
Code:
chmod ug+x ./superr
and repeat the above step. If everything worked, you should be asked to select your Language (english_srk.py). To choose it, type 1 on the keyboard.
The Kitchen will now ask you to download tools it needs to work properly. Allow it to do so by typing "Y" on the keyboard.
If everything went well, you should now be asked to enter your new Project name which identifies the folder, in which you will later store, modify and receive files. We will take care of that in the next step. This means, the Preparation process is over and you can now start using SuperR's Kitchen for your needs.
STEP 2 AND ON IN SECOND POST (CHARACTER LIMIT)
[CFW][W_K400][TREBLE] CFW and ROOT, MOSTLY-VANILLA
PART 2 OF THE POST, START WITH PART 1!!!!
2. Preparing your SuperR installation for your Custom AOSP Rom
In the Project Name we enter something identifying. Keep in mind that you may want to add multiple roms on this installation, so you should make it something rather unique. This process corresponds somewhat to Step 2.1, so you can read this one already to find out a good notation for your new project. I have already chosen my Treble image and will call mine
Code:
Enter new project name ...
lenny5_aosp8.1_vanilla_su_v32
2.1 Find out which Treble image you need
As you see in the last step, i selected a Version 8.1 "Oreo" image, where Vanilla tells you that theres no gapps at all and the suffix su means that it contains a rooted system. But later more about this. Also i chose v32 from the treble_experimentations releases.
To find your treble image, you need to have some information. First of all, read the information on this link. (phhusson's github wiki for Wiko Lenny 5)
Some informations here are important. First of all the flashing sequence, which will get important to us in a later step
Code:
Enable adb and oem unlock in developer options
adb reboot bootloader
fastboot flashing unlock
fastboot oem unlock
fastboot flash system your_gsi_path
fastboot reboot
as well as his testing notice
Code:
Flashed using Phh-Treble v18 - arm
as you can read in the Before starting section, there is a bug i could not resolve concerning installing older version ROMS, which could spontaneously start to apply to your device. i cannot "downgrade" my device, because it bootloops.
to select your image of choice, go to this site. (phhusson's treble image release site). to find v18, you will need to scroll down and go a few pages back in history.
some things to consider:
- lenny5 doesn't seem to be able to run AOSP9, so i'd recommend you stick with AOSP8.1
- there are lineageos compilations which might be interesting for some people. (i cannot tell if the root process for lineageos massively differs, as i don't use that one)
we will stick with AOSP8.1 in this guide.
first of all, you must decide if you want to stick with the go apps, install the stock gapps or go vanilla (no gapps at all). i will stick with vanilla. (note that some versions do not have the go version, others do)
then you will want to ask yourself if you want to root your phone, which we assume here to be yes.
as vanilla, like in our case, is not available with preinstalled su, we will stick with the nosu version. (which is a bit of a "hoax", as in fact this version already is rooted, you just have no way of controlling it, yet. we will take care of that in a later step.)
for our wiko lenny 5 we must choose the arm-aonly architecture. also i choose to stick with v32, the newest version per guide release date.
in my decision case, this leaves us with the following ROM:
https://github.com/phhusson/treble_experimentations/releases/tag/v32
Code:
system-arm-aonly-vanilla-nosu.img.xz
we will stick with that. if you want to use another rom, you must modify your choice. the overall process stays more or less the same. CONSIDER: It's proves easier to install some missing APK's etc. to your gapps-less system than removing unwanted gapps from your gapps-prebloated system.
click on the link and download the image file.
CONSIDER: Some of the images are in raw flashable format (the older ones), and have the extension *.img . For newer versions, the images are packed and CANNOT BE DIRECTLY FLASHED. these files are namely the ones with the extension *.img.xz
if your file has an extension that differs from *.img i strongly recommend you to use 7zip to extract the contained *.img file. 7-zip handles them all, which makes it the perfect standalone (de-)archiver on your computer. and no, i'm not getting paid by them for the advertising, it's just great and opensource.
now, if you didn't already, enter the name identifying your rom into the kitchen and confirm with ENTER.
to allow smb to write to your new project folder, reuse the command
Code:
sudo chown -R ~/android
by quitting superr (using the q key) or opening a second terminal (the easier way, in the original CTRL + ALT + T terminal on lubuntu, just doubleclick the top Tab-Bar off any other tabs and a new terminal tab will open) in which you execute this command.
now store the image file to your host workfolder and from there, copy it to your virtual workfolder's project folder (~/android/superr_<yourprojectname>/).
rename your system-arm-aonly-....img to just system.img for the kitchen to recognize it.
2.2 Extract your Treble image
To extract your Image file, on your virtual machines terminal, superr's kitchen should be running in the Main Menu.
if by any means you have stopped it, open a terminal with CTRL + ALT + T and enter
Code:
cd ~/android
./superr
press enter to execute and superr should launch. when asked for a project to load, choose the project you just created by pressing the correspondant cipher on the keyboard.
in the kitchen main menu, push cipher 4 on your keyboard to extract your obtained IMG-File. if asked, select your system.img by pressing the correspondant key and confirm the extraction with the "Y" key. wait for the process to finish. if asked, enter your virtual machine's user password. the kitchen sometimes needs to elevate some of it's processes during the extraction.
for the name of the zip, when asked, just enter "system_new". this is not so important, just dont simply call it "system", as this might confuse you under some circumstances and in the worst case overwrite your stock system.img.
for the perm type, select set_metadata by typing the "1" key on your keyboard, and you should be back in the main menu.
now your system image is unpacked into your virtual machine workfolder (~/android/<yourprojectfoldername>/system/)
2.3 Editing the contents (Rooting, etc.) of the Treble image
The editing in this guide's usecase is quite simple. We will want the following features and packages preinstalled:
- Root, of course
- including Root Management App
- BusyBox
- FDroid
- ...
you can add to this list to your hearts delight. The above will be my initial setup.
First we need to get the Root files.
These are found here
from this thread, get phh's-superuser.zip (the topmost file)
aswell as the phh's SuperUser apk file (top-second)
if you are having issues with the superuser implementation, try the bottommost element called phh's-superuser-aonly.zip instead of phh's-superuser.zip. this should normaly not be required.
copy both, the .zip and the .apk to your host workfolder.
now unpack the .zip to your host workfolder, which should create a folder "system" with 3 subfolders "bin,etc,xbin" in it.
copy this "system" folder to your virtual workfolder and into your project, so it integrates with the existing "system" folder on the virtual machine. if it asks you to overwrite, just allow it.
your virtual workfolder's project folder should now contain the following 3 files:
Code:
system/bin/phh-su
system/etc/init/su.rc
system/xbin/su
amongst the other system files.
Now download FDroid from here (the F-Droid site was temporarily down at the time of writing this guide)
Download the FDroid APK and store it in your host machine's workfolder.
After that, download the BusyBox APK from here
https://www.appsapk.com/busybox-app/
or a source you thrust more. There is a official busybox source, but i did not check which binary i must use for the Lenny 5, so i stick with the simplest method.
Download the BusyBox APK and store it in your host machine's workfolder.
Now copy the FDroid, BusyBox, and previously downloaded phh_s_SuperUser APK's from the host's workfolder to your virtual machine's project folder ~/android/<yourprojectfolder>/system/app/ (or \\<<yourvirtualmachineip\androshare\<yourprojectfolder>\system\app, respectively) to include them in your new ROM.
Thats basically all of the magic done. Your ~/android/<yourprojectfolder> should now contain the following 6 Elements
Code:
system/bin/phh-su
system/etc/init/su.rc
system/xbin/su
app/FDroid.apk
app/BusyBox.apk
app/phh_s_SuperUser_vX.X.X.X.apk
amongst the other elements from the Treble ROM.
move the APK app/FDroid.apk to a new Folder like this: app/FDroid/FDroid.apk
move the APK app/BusyBox.apk to a new Folder like this: app/BusyBox/BusyBox.apk
move the APK app/phh_s_SuperUser_vX.X.X.X.apk to a new Folder like this: app/phh/phh_s_SuperUser_vX.X.X.X.apk
as everything is sorted into folders, right?!
now we're done with modifying our treble image. lets repack it.
2.4 Repacking the Treble image
on your virtual machine terminal, with the kitchen open, go to the main menu if required and select "ROM Tools Menu" with the "8" key. You can check the "Root Menu" by pressing the "3" Key.
The Root/Unroot ROM should read (CURRENT: xbin/su) with Busybox and su.d "Disabled", which is okay, as BusyBox is not recognized, but there. If you want to utilize su.d, you must know yourself, how to do that properly. i don't know if it works as it should when done in the kitchen.
go back to the "ROM Tools Menu" with the "4" key and go to the "Build Menu" with the "7" key. Choose the option to "Build EXT4 img" by the key "2" and after the quick process finishes, in the menu "Which EXT4 img would you like to build?" select "system" by pressing the corresponding key, then select "sparse" by pressing the "2" key. for the file size, select the option to "Assume file size from project folder" by pressing the correspondent key and confirm the warning about this being BETA. Then wait for the process to finish.
The kitchen should say "system_new.img has been created in <yourprojectname>".
Now copy the newly created system_new.img from your virtual machine project directory to your host machine workfolder and we're done with editing and repacking the Image.
STEP 3 AND ON IN THIRD POST (CHARACTER LIMIT)
About TWRP and other stuff...
PART 3 OF THE GUIDE, START WITH PART 1!!!
3. Flashing the new Image to the Device
AT THIS POINT YOU SHOULD HAVE ALL YOUR DATA BACKUPED AND MAKE REALLY SURE FOR A LAST TIME, THAT YOU ACCEPT TO VOID YOUR WARRANTY AND TAKE ABSOLUTELY EVERY RISK TO YOURSELF FOR ANY CONSEQUENCES THAT COULD ARISE OF WHAT HAPPENS WITH YOUR DEVICE AT ANY TIME AFTER FOLLOWING THIS GUIDE.
The flashing process is simple. Enable Debug mode in your Phones Settings (Enable Developer Mode by taping the Build-Number several times Google: "Android Enable Developer Mode" - i really hope you know that after coming so far through this guide!!!.
When Developer Mode is activated, Go to Settings->Development Menu and activate the USB Debug Slider.
You must unlock the bootloader, at this point you must have generic adb or wiko specific adb installed, you can download it from here or get more information in section 0. "Before starting". The installation process is straightforward, possibly a restart of your host machine is required to get it running.
After installing ADB, you open the command line of your host machine and switch to your host machine workfolder by entering
Code:
cd <yourworkfolderpath>
and executing with ENTER.
use
Code:
dir
to make sure, that you are indeed in your workfolder.
when your phone is in usb debug mode, you can then reboot it into bootloader by entering
Code:
adb reboot bootloader
into your host machine command line. NOW THE DANGEROUS PART BEGINS, SO BE AWARE!!! WHEN UNLOCKING THE BOOTLOADER, YOUR LENNY5 WILL COMPLETELY WIPE ALL OF YOUR DATA AND RESET TO FACTORY SETUP!!!
by using the following commands in your command line you will unlock your bootloader, wipe your data and cache partitions including ALL PERSONAL DATA and flash your newly created ROM to the device.
Code:
fastboot flashing unlock
fastboot oem unlock
unlocks the boot loader. reenabling the debug mode (because of the factory reset) and/or rebooting the device may be required to reconnect to adb.
after that and making sure that you want to take the risk of flashing your new image, enter
Code:
fastboot flash system <yourhostworkfolderpath>\system_new.img
fastboot -w
fastboot reboot
the first command flashes your new image file, the second wipes your data and cache additionally, to make sure theres no residues there, which could mess with the first startup. after that we reboot the phone with the third command. after some loading, and a warning about the bootloader beeing unlocked, you should be greeted by AOSP's standard launcher with superuser, fdroid and busybox preinstalled.
4. Final words
After all it prove to be a quite long process, if you don't have any kitchen presetup. If the kitchen is ready, it's a thing of downloading, modifying and reflashing the device. but be careful. there's always a risk of bricking your device.
I will try to keep this guide up and running but memorize my Thread starting words.
If you think my RED BLOCKS are excessive - i'm sorry, but i care for your LENNY, too.
If you read this and are able to comply with all the steps in the guide, you are ready to flash your phone!
It's a wall of text, and i don't know if it's straight forward for all users, but it's the only way i could come up with, to root the LENNY5 phone, so it's worth it all the while, right?
I hope it helps some of you to get their Phones Unlocked and Unleashed.
Best regards
ivelischt
---------- Post added at 09:39 PM ---------- Previous post was at 09:37 PM ----------
if you find errors and mistakes in the guide, you are welcome to notice me and all the others by leaving a post in this thread.
Please ignore my posting titles, as they do not fit anymore, since i had to split from 2 to 3 posts to fit all of the text.
Okay some more words from my side concerning TWRP etc.
1. as far as i can tell, with the wikogeeks source you can indeed compile TWRP, but i'm not deep enough into it to try it.
2. with the procedure in the description above i now have a fully rooted phone
3. i am able to dump (mostly) any partition on my device (boot, recovery, system). so i have boot.img, recovery.img tested working. of course i was unable to dump my old system as it was not rooted. but i can dump my new system.img and it is also tested working, i reflashed all of the images to find it out.
4. if someone here in the forums thinks, that, with this information, you are able to port TWRP, i think we all would be glad,
because
5. i tampered around with various twrp roms. with the Jerry 3 ROM, which is out in the Net (DuckDuckGo-Search: w_k300 twrp), i thought i'd come to a point, as these are "sister-devices". in fact i had twrp running after loading the split-files (zKernel, etc...) from stock recovery to twrp recovery using the kitchen. but the screen isn't working. i need to "swipe for modifications", but i can't. as far as i can tell, it's just the touchscreen irresponsive. maybe this is something quickly fixed, maybe not.
so, i don't know if it's legal for me to share these sources here in the board but if anyone wants to test around on these write a on pm. just ask me and i will do what i can.
on my system, at the moment i have:
- stock boot.img
- stock recovery.img
- aosp8.1 system.img i use on my lenny
- semi-functional Jerry3-TWRP-Port, with the display unfunctional
let me know if you can do something with this stuff.
best regards
Matt 123456789 said:
Ok so Wiko Released the Firmware! Its a Windows software that downloads and flashes the ROM, and it makes a folder with stuff in it. Maybe experienced people can look into it and build TWRP?!! I would really love twrp but I don't have the experience :crying: . Hope developers see this
Click to expand...
Click to collapse
Hey Matt! Sorry, i completely misunderstood what you were talking about. Thats my fault
To clarify, there IS an actual Update package, just not under the various xx.wikomobile.com subdomains, but via world.wikomobile.com, using the IMEI number, you can infact get an Update.zip. I saw that really just now... The most recent update hides at https://support.wikomobile.com/maj/Lenny5_OPE_V34.zip
I don't know if this helps porting TWRP, as i'm actually experimenting with compiling it from source, for lenny 5 specifically. but to no success until this point. but whilst experimenting around, you can at the very least use it to flash to stock if required.
The update.zip contains the following:
- SPFlashTool
- MT6580 Scatterer-File
- boot-sign.img
- cache-sign.img
- lk-sign.img
- misc2-sign.img
- odmdtbo-sign.img
- recovery-sign.img
- secro-sign.img
- system.img
- tee-sign.img
- userdata-sign.img
- vendor-sign.img
- preloader_k400.bin
- as well as tons of other files
i think the stock system image is raw. to flash it you must either use the SPFlashTool or convert it to sparse format by other means...
best regards
edit: it seems, that lenny5 runs well with AOSP9, at least i upgraded my device today and it runs.
also, if you decide to install treble images by the guide above, using gapps, you will have to register your device here. (Android Device Registration)
their guide on getting the android_id may be a bit strange, i needed to progress as follows:
Code:
adb root
adb shell
inside shell type:
Code:
su <-- work as root
cd /data/data/com.google.android.gsf/databases/
sqlite3 gservices.db
this will start sqlite3 command line.
inside the sqlite3 command line enter
Code:
select * from main where name = "android_id"; <-- don't forget the semicolon!
after pressing enter, the output should be something like
Code:
android_id|[B]1234567890123456789[/B] <-- this code will be different on your device.
on the Android Device Registration page, you enter the bold part of the output and press Register. enter
Code:
.exit <-- to leave sqlite
exit <-- to leave su mode
exit <-- to leave shell
it will take a few minutes until your google services start to work properly without flooding your notifications.
you should now be able to use your gapps.
ivelischt said:
Please ignore my posting titles, as they do not fit anymore, since i had to split from 2 to 3 posts to fit all of the text.
Okay some more words from my side concerning TWRP etc.
1. as far as i can tell, with the wikogeeks source you can indeed compile TWRP, but i'm not deep enough into it to try it.
2. with the procedure in the description above i now have a fully rooted phone
3. i am able to dump (mostly) any partition on my device (boot, recovery, system). so i have boot.img, recovery.img tested working. of course i was unable to dump my old system as it was not rooted. but i can dump my new system.img and it is also tested working, i reflashed all of the images to find it out.
4. if someone here in the forums thinks, that, with this information, you are able to port TWRP, i think we all would be glad,
because
5. i tampered around with various twrp roms. with the Jerry 3 ROM, which is out in the Net (DuckDuckGo-Search: w_k300 twrp), i thought i'd come to a point, as these are "sister-devices". in fact i had twrp running after loading the split-files (zKernel, etc...) from stock recovery to twrp recovery using the kitchen. but the screen isn't working. i need to "swipe for modifications", but i can't. as far as i can tell, it's just the touchscreen irresponsive. maybe this is something quickly fixed, maybe not.
so, i don't know if it's legal for me to share these sources here in the board but if anyone wants to test around on these write a on pm. just ask me and i will do what i can.
on my system, at the moment i have:
- stock boot.img
- stock recovery.img
- aosp8.1 system.img i use on my lenny
- semi-functional Jerry3-TWRP-Port, with the display unfunctional
let me know if you can do something with this stuff.
best regards
Click to expand...
Click to collapse
Same with the display here, can't get it to work. I read that display touch malfunction is about kernel diferences, but I don't know how to modify it.
Hanthonious said:
Same with the display here, can't get it to work. I read that display touch malfunction is about kernel diferences, but I don't know how to modify it.
Click to expand...
Click to collapse
well, i then tried all the possible configurations of the following:
TWRP versions:
- self-compiled TWRP
- TWRP for some random FullHD-MTK6580 with more or less same specs as lenny 5
- K300 TWRP
kernel versions:
- twrp k300 kernel
- stock k400 kernel
- self-compiled k400 kernel
which makes quite some possible combinations. as far as i can recall, the most sucessful was the untouched k300 twrp with its k300 kernel, which managed to boot up but with the touchscreen not working.
i then tried the k300 twrp with stock and self-compiled k400 kernel, but both failed. i even tampered with the kernel adress to fit it to k400 and tried out multiple "tricks" i stumbled upon when searching the internet. but the phone always just hangs a few seconds, then boots into "normal" mode or stock recovery.
i cannot fully rule out whether its caused by me implementing the kernel in a wrong way (for me this is the most probable reason ) or if it's because SuperR's kitchen (thanks go out!) has some kind of mess while reintegrating the changed kernel, as i did all of these combine-and-retry kind of rom porting experiments with his product. maybe i am just using the tool in a wrong way.
i also compiled a stock kernel from wikogeek sources, then used that to compile twrp sources into a recovery.img, including the self-built kernel, which both, after some tinkering, built without any issue, but then also, this image just hangs for a few seconds and shows the same behavior as stated above.
whatever it is, i cannot identify it. this has two main reasons:
- first and most important: what i know is through learning-by-doing, which means, i have no degree in coding or anything. from my perspective, i feel a bit proud already, being able to compile aosp or lineage from source, even with a lot of help by those creating these mostly ready-for-use sources. :victory: learning-by-doing implicates my second point: time investment.
- i cannot afford to spend most of my time with digging into android development. and also often, i just don't have any delight in it and do other things.
also, my main purpose was to get a rooted system (with a custom rom on it), which i managed, so most of the time i spend on android stuff at the moment, is to update my build and distribute the updated images in time when security patches arrive.
short said: if twrp for k400 comes, it would be nice, but it's none of my main objectives at the moment to get this to work.
best regards
I've just had a stock OnePlus Nord N10 running Android 10. For years now I've kept a html file on the internal storage of my Android devices that I've used as a homepage for my web browsers that have all my favourite links laid out nicely. On my older OnePlus 3 running Android 8 I open this using the following URL in the browser url bar:
file:///storage/emulated/0/Dropbox/Other/Web_Links.html
And it opens fine.
On the Nord N10 it is failing with an ERR_ACCESS_DENIED error in the browser. I'm getting this in both Chrome and Edge. The URL appears to be correct (typos give me a file not found error) so I'm at a loss to know what's causing this. It feels a bit like the browsers aren't asking for the right permission to open files from file:///storage/emulated/0/ but I don't know how to get them that permission.
If I open the file from a file browser sending it to the web browser it opens fine, but gets a url in the form of content://media/external/file/39531 in the url bar only that url seems to only last until the next reboot.
Just to muddy the waters more - I had a couple of Moto G 5G Plus's running Android 10 a couple of months back that had to be returned because I just couldn't get a decent 4G signal on them and I had the same issue on them, but did "something" and got it working for the file:///storage/emulated/0/... url. Only I wasn't sure even at the time what I did to get it working.
Any help would be appreciated. Even if it's a dummy's guide to how apps relate to file:///storage/emulated/0/ and what specific permission they need to access it.
Hal18ut said:
I've just had a stock OnePlus Nord N10 running Android 10. For years now I've kept a html file on the internal storage of my Android devices that I've used as a homepage for my web browsers that have all my favourite links laid out nicely. On my older OnePlus 3 running Android 8 I open this using the following URL in the browser url bar:
file:///storage/emulated/0/Dropbox/Other/Web_Links.html
And it opens fine.
On the Nord N10 it is failing with an ERR_ACCESS_DENIED error in the browser. I'm getting this in both Chrome and Edge. The URL appears to be correct (typos give me a file not found error) so I'm at a loss to know what's causing this. It feels a bit like the browsers aren't asking for the right permission to open files from file:///storage/emulated/0/ but I don't know how to get them that permission.
If I open the file from a file browser sending it to the web browser it opens fine, but gets a url in the form of content://media/external/file/39531 in the url bar only that url seems to only last until the next reboot.
Just to muddy the waters more - I had a couple of Moto G 5G Plus's running Android 10 a couple of months back that had to be returned because I just couldn't get a decent 4G signal on them and I had the same issue on them, but did "something" and got it working for the file:///storage/emulated/0/... url. Only I wasn't sure even at the time what I did to get it working.
Any help would be appreciated. Even if it's a dummy's guide to how apps relate to file:///storage/emulated/0/ and what specific permission they need to access it.
Click to expand...
Click to collapse
If device's Android is rooted try this
Code:
adb devices
adb shell "chmod 0644 /storage/emulated/0/Dropbox/Other/Web_Links.html"
jwoegerbauer said:
If device's Android is rooted try this
Code:
adb devices
adb shell "chmod 0644 /storage/emulated/0/Dropbox/Other/Web_Links.html"
Click to expand...
Click to collapse
It's not rooted, and I don't really want to root it. The Moto wasn't rooted either.
Does Android do anything "odd" with permissions when copying files around that might be causing this? It was copied in from a memory card.
Hal18ut said:
Does Android do anything "odd" with permissions when copying files around that might be causing this? It was copied in from a memory card.
Click to expand...
Click to collapse
By default, when you create a file as a regular user, it’s given the permissions of 644 ( means: rw-rw-r– ). These permissions don't get stored with the file but within the filesystem where the file is located. Hence when you transfer a file from one filesystem ( here: external sd-card ) to another one ( here: internal sd-card ) , the initially granted permissions get lost.
jwoegerbauer said:
By default, when you create a file as a regular user, it’s given the permissions of 644 ( means: rw-rw-r– ). These permissions don't get stored with the file but within the filesystem where the file is located. Hence when you transfer a file from one filesystem ( here: external sd-card ) to another one ( here: internal sd-card ) , the initially granted permissions get lost.
Click to expand...
Click to collapse
Any tricks for copying (or moving the file) so it gets the correct permissions? Also, any non-root way of viewing them to confirm this is cause of the issue?
The best I've come up with so far is to save the .html files in Android/data/com.microsoft.emmx/files/Download/ and then reference them with file:///storage/emulated/0/Android/data/com.microsoft.emmx/files/Download/Web_Links.html which appears to work. Presumably substituting com.android.chrome for com.microsoft.emmx will work for Chrome.
Still don't understand why Edge and Chrome don't have access to URLs via file:///storage/emulated/0/ nor how I got around this on the Moto.
There might possibly be another way, but I cannot recall the details on how to do it or whether it requires root or not. Some devices have special internal URI's that enable, e.g., debug mode, which can be invoked via omnibox in the form of in-line commands. I remember in particular my car's Android head unit had this for it's native browser and after enabling debug mode,. I was able to browse `file:///` and its subdirectories. My unit did have root at the time, but I want to say that regardless this wasn't accessible without the debug command being enabled, so I would infer it might not require root (but that's purely conjecture). This is not a persistent state, but the command could be saved as a bookmarklet for ease-of-use. I've never looked into whether this is a common or unique Android function, or something the OEM developed.
Hi, few day ago I made a videos with a modded version of Google Camera 8.1,
the first one was not saved properly and was in .pending????????.mp4 state, and I erased it by mistake,
because it was first time, I was using this tool, and I didn't knew that it is a temporary file.
I tried to recover, using many tools, but I was unable to recover it, so I decided to Root my phone using Magisk,
I made some mistake and testing some FastBoot command I relocked my Unlocked phone.
I had to Unlock again by using "miflash_unlock.exe", with advertising that all my data’s will be deleted.
After I managed to patch my phone, he restarted (I don’t installed any previous apps prom store, to avoid my video to wiped by new data,
and I tried with Ult Data, Dr Phone to recover the file, but Root access was not accepted.
Then I tested lot of android tool, nothing worked, after searching a lot I found this page :
https://drfone.wondershare.com/android-recovery/phone-memory-data-recovery.html
And I tried but some command didn’t work, since I didn't have FDISK, FTPPUT on my phone file system,
after some other search I found this ancient page (2014) who seemed to be the source,
https://sudonull.com/post/108208-Recovering-data-from-internal-memory-on-Android-for-dummies
and after installing BusyBox Pro,
I managed to get missing Linux tools.
I tried the command, all worked fine,
but now I’m unable to access this one :
Code:
ftpput -v -u sally -p able -P 40 192.168.1.4 sde55.raw /cache/myfifo
because my FileZilla does not get any information.
And I receive this message :
Code:
can't connect to remote host (192.168.1.4): Connection timed out
The article is old and that guy was using U.S.B. MoDem on CyanogenMod 11.
I use Magisk pro rooting and I do not know what tool I should use to get U.S.B. link with FileZilla Server to get proper connection.
I tried many things, changing protocols, P.T.P., M.T.P., and I do not know what to do,
so I thought may be here, someone with experience could point me to a tool to use in Android 12 / 11 with my Magisk and link to FileZilla Server,
to get image of internal memory back‑up‑ed ?
Thank you in advance.
No one knows how to ?
Someone knows an other methodic to extract partition totally & perfectly ?
forum.xda-developers.com/t/guide_making_dump-files_out_of_android_device_partitions/