Related
Alright, so the root filesystem image is in /mnt/system/androidmerged.squashfs.secure
So do a temp root, copy to /mnt/storage, and then a adb pull gets it over.
The squashfs itself is offset by 256 bytes, so:
losetup -o 256 /dev/loop0 ./androidmerged.squashfs.secure
At this point, the FS can be mounted or unsquashfs can be used to extract it.
So, what's the first 256 bytes? The secure implies some type of signature, but what kind, and what else is in all those bytes?
I'm not feeling brave enough to try just grabbing the first 256 bytes and appending a modified squashfs image to it on my device just yet, but if others try please report back. (On both if it works, and if not what it takes to recover the unit.)
how big is it? can you upload it somewhere? (or would this be illegal?)
damm.. i need my 101!
chulri said:
how big is it? can you upload it somewhere? (or would this be illegal?)
damm.. i need my 101!
Click to expand...
Click to collapse
75 MB - uploading now
Edit: And up: http://hotfile.com/dl/88050103/f99f306/androidmerged.squashfs.secure.html
thx!
how would you replace the root fs image on the device?
chulri said:
how would you replace the root fs image on the device?
Click to expand...
Click to collapse
Connect via ADB, do a temproot, put the file in /mnt/storage, then copy it into /mnt/system overwriting the existing file. /mnt/storage is an ext3 filesystem mounted read/write, however I simply do not know if it will be possible to recover the unit if there is some kind of signature verification and we fail due to a modified image.
Again, someone braver then I should make this attempt and let us know how it goes.
The source did not give all that many hints, but I need to dig through in some more detail.
zelch said:
Connect via ADB, do a temproot, put the file in /mnt/storage, then copy it into /mnt/system overwriting the existing file. /mnt/storage is an ext3 filesystem mounted read/write, however I simply do not know if it will be possible to recover the unit if there is some kind of signature verification and we fail due to a modified image.
Again, someone braver then I should make this attempt and let us know how it goes.
The source did not give all that many hints, but I need to dig through in some more detail.
Click to expand...
Click to collapse
If the unit will still boot to recovery could a full wipe and reinstall of the base AOS over USB get it back up and running?
krohnjw said:
If the unit will still boot to recovery could a full wipe and reinstall of the base AOS over USB get it back up and running?
Click to expand...
Click to collapse
Recovery shouldn't be part of the FS so at worst, you'd have to do a format/firmware install.
You can do a full system wipe/format from recovery. it's not in any damageable storage by us without flashing a new recovery image.
Interesting about the front 256 bytes. It must be a signature. Not sure what good rebuilding the squashfs will do as it'll still be read only but it's a start. We could at least update the system properly and install the appropriate apps. Maybe in make some of the system dirs symlinks to writable locations possibly.
Permroot, giving us a filesystem mounted RW and not no-suid.
Ideally, I'd like to have decent support for the internal storage being ext3 without nosuid, but first we need to be able to replace the root filesystem image.
Other notes..
Looking at the hexdumps, the 256 byte chunk does not contain the start of the md5, sha1, sha224, sha256, sha384, or sha512 checksums.
The most troubling option which comes to mind is that it is the right size for a RSA 2048 bit block, hopefully not.
Anyone have ideas on how to find the initramfs image that the bootloader is feeding the kernel?
For that matter, has anyone tried taking apart the OS update images?
zelch said:
For that matter, has anyone tried taking apart the OS update images?
Click to expand...
Click to collapse
I think the aos file or the responsible installer/updater should give us a lot of information about how this stuff can be updated.
chulri said:
I think the aos file or the responsible installer/updater should give us a lot of information about how this stuff can be updated.
Click to expand...
Click to collapse
Agreed.
It looks like usr/bin/abcbox in the root filesystem has something to do with the update process.
zelch said:
Agreed.
It looks like usr/bin/abcbox in the root filesystem has something to do with the update process.
Click to expand...
Click to collapse
And it definitely is!
On a rooted device:
Code:
/usr/bin # PATH=$PATH:/tmp
/usr/bin # ln -s /usr/bin/abcbox /tmp/cramfschecker
/usr/bin # cramfschecker
USAGE: cramfschecker FILENAME
/usr/bin # cramfschecker /mnt/system/androidmerged.squashfs.secure
cramfschecker : check against 2.0.54
cramfschecker verification OK
Anyone with some ARM disassembly skills feeling up to taking abcbox apart to see how it's doing the signature check?
And so I've been digging into this, and it turns out that this is really quite similar to how the Gen 7 Archos 5 IT is locked.
The signature there is a RSA + MD5 signature, which is really the worst case as that means a 2048 bit RSA key, so we're kinda screwed there.
http://strazzere.com/blog/?p=320 has a good description of the situation on the 5IT. Getting a flash_unlock binary should be fairly trivial, so perhaps we can tamper with the key store to add additional keys.
ah zelch, this is good stuff.
i'm gonna diff the archos gpl kernel, looking for changes at mtd stuff. maybe we can build a kernel module which enables r/w access to stage1
edit: or do we already have r/w access?
This stuff is all pretty interesting to read, but if I'm reading this correctly (and it is entirely possible I'm not) it looks kind of like this device is going to be a total pain in the ass to root, and it may take a considerable amount of time for us to get there.
Can someone who is more knowledgeable on this sort of thing verify that? Thanks for all your hard work guys. It's appreciated.
its definitly not going to be that easy as other android devices were but would it be so interesting if it wouldn't be so hard to root?
While that's true, it will make it a bigger triumph when it is finally rooted, the tinkerer in me is dying to mess with roms on this device and see what it can really do once it's cracked open. Keep up the great work guys, I'm following with baited breath.
Write to stage1 appears to exist, and indeed looking at /proc/mounts /mnt/rawfs is mounted rw. Looking at the kernel source, write support should Just Work.
So, looking through /mnt/rawfs avboot is clearly the boot loader which verifies stuff, but we lack source for it.
I have absolutely no knowledge of ARM asm, and screwing this up will absolutely brick your device, quite possibly beyond repair. (And I wouldn't bet on ArchOS being willing to replace it either, I sure wouldn't.)
So, anyone with the right background willing to step in here?
I'll keep digging, perhaps we can still find the answers.
Note: avboot has some strings which reference a development kernel, this bears some additional hunting.
I still haven't got my A101, but its finally on its way to my home.
can you please upload these files and give me kind of a tree of the folder structure?
There's been a few ROMs based on the stock kernel--one of them is mine--but nothing more in-depth. I'm setting out to change that, but I could use some help from more experienced folks.
What I've found so far:
- It uses the MSM7227_Surf Qualcomm System-on-chip (verified by disassembling a broken phone)
- which also has the Adreno200 GPU (built into MSM7227_Surf)
- It has 512MB flash partitioned very similarly to the Samsung Gio, with most partitions being at least the same if not sightly larger (with the exception of /system and /data being split differently such that /system is bigger than on the Gio and /data is smaller)
- Unlike the Ace/Gio, it uses a Broadcomm wifi chipset instead of the atheros at6000
What I'm stuck on at the moment is the partition map. How do I get the precise partition sizes when /proc/mtd doesn't exist?
I was able to figure it out. Since the partitions are nearly identical to the Samsung Galaxy Ace, I took a look at that phone's BoardConfig.mk and figured out the formula:
1) Get the partition list from 'cat /proc/partitions'
2) Multiply the reported # of blocks by 1024 to get the size in bytes
3) Convert the result from #2 to hexadecimal
Results:
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00A00000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00A00000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x0DD00000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x09800000
BOARD_FLASH_BLOCK_SIZE := 4096
EDIT: I just found where this phone puts the equivalent of /proc/mtd. It's in /proc/LinuStoreIII/bmlinfo:
Code:
FSR VERSION: FSR_1.2.1p1_b139_RTM
minor position size units id
1: 0x00000000-0x00180000 0x00180000 6 1
2: 0x00180000-0x00200000 0x00080000 2 2
3: 0x00200000-0x002c0000 0x000c0000 3 3
4: 0x002c0000-0x01bc0000 0x01900000 100 4
5: 0x01bc0000-0x024c0000 0x00900000 36 23
6: 0x024c0000-0x029c0000 0x00500000 20 25
7: 0x029c0000-0x02bc0000 0x00200000 8 5
8: 0x02bc0000-0x035c0000 0x00a00000 40 6
9: 0x035c0000-0x03fc0000 0x00a00000 40 7
10: 0x03fc0000-0x04080000 0x000c0000 3 8
11: 0x04080000-0x05980000 0x01900000 100 9
12: 0x05980000-0x13e00000 0x0e480000 914 21
13: 0x13e00000-0x1dc00000 0x09e00000 632 22
14: 0x1dc00000-0x1f500000 0x01900000 100 24
I just signed up a few minutes ago with this account to say thanks for doing this, from another guy who has just gotten this phone! (Well the Canadian version, same thing basically called the "Samsung Galaxy Q"/SGH-T589R) Not sure if I can do much, the closest thing I do compared to this is using Linux. I'll be rooting for you.
My initial goal was to get a Gingerbread kernel that a) supports the Galaxy Ace (the Gravity SMART's more popular cousin) and b) actually compiles, but I didn't have much luck. The kernel I wanted to use was built against some long-deprecated kernel source that I couldn't dig up--and applying the diff against the Samsung stock source tree failed to compile.
So, I've gotten a copy of the source to the ICS kernel developed by Maclaw & others [still too newb to post links] for the Samsung Gio and Samsung Ace.
Next step: finding the stuff unique to the Gravity SMART.
Fun fact: The Gravity SMART was originally code named the Gravity Touch 2, and this is reflected in the source code where the model's config flag is named CONFIG_MACH_GT2 (as opposed to CONFIG_MACH_COOPER for the Ace).
My initial suspicions are proving to be pretty spot-on. Quite a few of the changes involve simply adding "|| defined(CONFIG_MACH_GT2)" into an existing chain that typically includes the CONFIG_MACH_COOPER or CONFIG_MACH_GIO. However, there are a number of notable exceptions. Thanks to the power of a recursive grep, I've got a list of files and I'm slowly but surely getting the changes ported over.
I have a ways to go before I get a compiling kernel, but there's still one big hurdle to jump after I get all the changes brought in: Wifi.
The stock kernel uses a kernel module, dhd.ko, which appears to be a Broadcom driver. However, I suspect it may be customized/proprietary because the kernel config flag (CONFIG_BROADCOM_WIFI) isn't used anywhere in the source tree. Both the ICS and FroYo kernel sources have code for -other- broadcom drivers, but there may be compatibility issues. I also found a Broadcom driver on googlesource which I suspect was Samsung's starting point for the aforementioned kernel module, but it doesn't come with any instructions for compiling it so I'm not quite sure what to do with it. I'll probably start by just trying to use the kernel's built-in driver and poach the firmware file from the googlesource package, and see what happens.
OK, so a status update--
Using the list of files containing the CONFIG_MACH_GT2 tag as a guide, I went through and modified/ported the code as best seemed to make sense from the Samsung code into the ICS kernel.
Then began the fun of trying to compile the kernel.
The configuration routine wanted to eat my own CONFIG_MACH_GT2 flag, so I had to do a little more hacking to figure out how to modify the kernel configuration files to recognize it as a valid configuration option. For the benefit of others, I'll post the results of my research:
1) Edit arch/arm/tools/mach-types to add the machine type
2) Edit arch/arm/mach-msm/Kconfig to add the configuration option
3) run 'make distclean' to make sure that all the generated stuff gets regenerated properly.
Now it's recognizing the CONFIG_MACH_GT2 option, but one of the modules is failing to build. But, I'm too tired to tackle it right now so it will wait until another day.
It compiles!
... which of course doesn't mean it actually works.. I haven't had a chance to test it yet. Fortunately I have the ODIN files to restore ifwhen something goes horribly wrong.
gblues said:
It compiles!
... which of course doesn't mean it actually works.. I haven't had a chance to test it yet. Fortunately I have the ODIN files to restore ifwhen something goes horribly wrong.
Click to expand...
Click to collapse
Hoorah! Here's hoping it works!
Well, no dice. Stuck at "SAMSUNG" which, admittedly, is better than previous attempts at flashing a custom boot/recovery image (just got a blank screen on those attempts..)
In the process, though, I learned a few important things:
1) To flash any custom firmware, you need Odin 4.40 USA. Newer versions do not work.
2) How you make the .tar.md5 file matters! The files have to be added to the archive in the right order. I determined the order by extracting the stock firmware I acquired from samfirmware.com (using 'tar xvf') and then made sure that I added them in the same order when I created my version. If the files aren't in the correct order, Odin will crash when attempting to flash the phone.
Thank you!
I have been waiting for so long for someone to start something with this phone. I will help in any way I can, if you would like. I am a bit of a newb, but I have done a few things with a Dell streak 7 and an Optimus One, as well as interop unlocking my LG Quantum (a windows phone, but w/e )
I'm another step closer!
After the spectacular failure of my first attempts, I decided to try a smaller step--unpacking the stock boot image, making a useless change (putting "Hello, World!" at the top of /init.rc), packing it back up, and flashing it. When this also failed, I thought perhaps I was working against a locked bootloader.
After finding absolutely no information about the presence of a locked bootloader, and with similar phones not needing any special unlocking, I went a little more basic: what if I unpacked and repacked the boot.img without any changes? I did this, and I was surprised to find that the repacked file didn't match the original at all.
I did a little more research and playing around with mkbootimg, and successfully disassembled and re-assembled the original boot.img file (verified by comparing md5 checksums). I used the same settings to retry my "Hello World" test--and lo and behold, it WORKS!
Nicely done, I knew you could do it!
Awesome job! I can't wait to see how this works out!
Well, unfortunately, it hasn't. While I've been able to modify the contents of the ramdisk cpio, my kernels aren't booting. Or if they are, they're failing before anything useful happens.
Anyway, the trick to creating the boot.img and recovery.img:
The images are in the standard Android format, as documented here. In fact, the unpack-bootimg.pl from that page works brilliantly. However, to re-pack the image, it's best to use mkbootimg directly.
Let's say you've got your gzipped kernel named 'kernel.gz' and the gzipped cpio archive of your ramdisk named 'ramdisk.cpio.gz', and let's say you want your resulting image file to be named 'yourboot.img'. Then you'd use the following command:
Code:
mkbootimg --kernel kernel.gz --ramdisk ramdisk.cpio.gz --base 0x13600000 --pagesize 4096 -o yourboot.img
From further research, it appears that in order to boot a newer kernel than what shipped with it, the boot loaders need to be modified to accommodate it. The reason is that the access to the internal memory partitions is handled by a proprietary Samsung kernel module, which only exists for the kernel the phone shipped with. Even if I had the source for the Samsung module, the boot loader needs to support the newer version of the Samsung module.
So, what I'm going to try next is hacking the kernel to force it to report the same version as the phone expects, and see how spectacularly it fails well it works.
Well, fudging the kernel version in my 2.6.35.7 build didn't work, although just doing a straight compile of Samsung's kernel sources _did_ give me a booting kernel.
Well, the result of my extensive research is thus: there's no hope of getting Gingerbread on this phone without Samsung creating an official release. Here's why, from what I've gathered:
The bootloader does not appear to be locked; however, it does provide some key services that Samsung's proprietary kernel modules use to provide access to the flash partitions on the phone, kind of like the BIOS in your PC. The bootloader expects a specific kernel version (more specifically--and I apologize if the terminology is wrong--a specific kernel ABI). Simply faking the kernel version is not enough--it has to have exactly the same driver interface and kernel entrypoints as it expects. So even though I tried compiling the 2.6.35 kernel with a fake version number, the ABI is still wrong so the phone doesn't boot.
Hacking the boot loader is waaay outside of my skillset, although I did successfully dump it from my wife's busted phone. Judging from the results of my research, it's not something anyone's actually attempted. And given that screwing up the bootloader will hard-brick the phone, I'm not in a mood to experiment.
So basically, since Samsung is the only one with the code for the bootloader and the RFS drivers, it's up to them to create a GB release. Once they actually do so, then possibilities open up quite a bit.
Well you gave it your best shot so thank you! Maybe someone on here will come up with a way to get a non-Froyo version. Hell or even maybe if we're nice enough we'll get upcoming Jumping Jellybean available for this phone.
Thanks so much even for trying. I wish I could try and do something, but I would have no hope.
My sister's likely getting a Galaxy Q tomorrow, so I'll be following dev work on this device a bit.
Skip the RFS format. It's a pain in the neck to work with, and pretty much every benchmark out there shows it's not as fast as ext4 anyway.
Edit: Got another idea: try using the GB RFS kernel modules from the Gio/Ace/Fit/Mini...
If you want to try converting to ext4, make sure you have RFS format dumps of the /data and /cache partitions you can dd back into place in order to restore to stock.
Consider contacting Phiexz (who's sort of left XDA, but should be reachable at his own forum), Delanoister, Maclaw and the rest of the GalaxyICS team. Hyriand too. What they've done for the Gio is nothing short of outstanding.
Good luck,
Darkshado
gblues said:
my kernels aren't booting. Or if they are, they're failing before anything useful happens.
Click to expand...
Click to collapse
No ddms/logcat output, nothing?
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! I’ve come, because in my quest to root my recent Galaxy S Devices, I’ve hit a big fork in the road and I don’t have the knowledge base to answer the last few questions I have. I feel like I should know the answers here, but for some reason I am lost to what to do next. I don’t quite understand how the newer root methods work these days, since working with the system & recovery images isn’t as easy with the newer Samsungs.
I got together with a developer, @droidvoider, where together we came up with this idea to get a root shell capable of at least remounting the filesystem R/W before reboot. He coded it on 6.0.1, and I talked a whole lot while I tested it on 5.1.1.
The Greyhat Root Console post#63
droidvoider said:
Major update!
1. I have debugged the tool heavily and it appears to me that I can replace any file on the system. Testing files you can't normally read is done via code so it's slow going, let me know if you find any blocks now.
2. If you have any file that gives an error but then replaces, that's because it tried other contexts.. PUT THIS ACTION AS THE LAST ENTRY, it might not be changing back to install_recovery from some contexts
3) the su install thing is designed to give an error I didn't even try to get root with this, literally focused on getting the tool done only.
4) next is a console of sorts, with exec dcow patching.. muahahaha
https://github.com/droidvoider/CVE-2016-5195_GreyhatRootProject_Root_Console
Click to expand...
Click to collapse
droidvoider said:
post#41you start an apk with am or monkey ... Let me know if I missed any other questions I'm excited about my find
I have awesome news.. As soon as I started playing with ls -la / using both contexts with root I seen that inside /cache/recovery/ is some log files. I am pressed for time hard, however
Code:
ls -la /cache/recovery/
Attached you can see the full output acquired from ls under both contexts
Click to expand...
Click to collapse
I'll start with the fact that I do not have Cellular Service. I no longer own a Note 5 N920A. But I do still own an S5 G900V, S6 Edge G925V, and a S7 Edge G935V. They serve as Wi-Fi Only Devices, and they are owned by myself. So slightly selfishly, I concern myself only with modifications that allow the device to boot, working network services are not a primary concern of mine. As they can more than likely be configured after boot by someone smarter than me.
I know that normally DM-Verity, KNOX, Encryption, U/G IDs, and SELinux, play a big role in allowing a user to execute processes as the root user. I am running 5.1.1 Android on my S6e & 7.0 on my S7e. I have an Engineering Kernel and boots normally with ADB Root Shell access. I have an Engineering Sboot, and allows me a non Root ADB Shell while booted normally in Stock Recovery. Right now the Eng Kernel I have, sets SELinux to Enforcing Mode. If I use the stock factory binary kernel, I lose root adb shell access but gain Permissive SELinux Mode. How do I inject root from here in a stable fashion?
akiraO1 said:
post#112
But I did want to post my findings so far on my selinux adventures thus far with my note 7....
So I was able to change the root context permanently from ubject_r:rootfs:s0 to u:r:shell:s0.
This by itself isn't all that helpful except that I actually changed it, and it stuck when I rebooted the device.
I achieved this through dirtycow-ing the file_contexts file with my customs file_contexts file and the commmands restorecon -RFv / and chcon -Rhv u:r:shell:s0 / restorecon makes selinux reload the file_contexts file immediately, so it loads all or most of my custom contexts. then I do a chcon command to make sure it writes?
well thats all I have for now but im working vigorously and will keep posting my findings as I find them =)
Click to expand...
Click to collapse
Using "DD" on Android 6.0.1 post#18
droidvoider said:
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
Click to expand...
Click to collapse
Page 4 for File and GHR Console
Page 5 further discussion of Console
Page 6 GHR Console
I'm going to go into some detail here about the Firmware I've been flashing just so everyone knows without having to ask. I'm almost really hoping maybe we could all muster one more attempt at rooting this Note 5 variant.
I really feel like I really might have something here, especially with the updated binaries of "Farm Root", "CVE 2016-5195 (dirtycow)", and bootimgtools (mkbootimg & unpackbootimg). All compiled for arm64-v8a. Thanks to @droidvoider for helping to compile those. I'm not a linux Expert by any means, but I'm on a mission, and I do know a few things. With all of the Security Bulletins that have come out since November, there should be plenty of Attack Vectors for using the LL Eng Kernel or DirtyCow to gain enough Kernel Privileges to maybe even unlock the dang bootloader. Or maybe bypass the signature check for one boot. LL-based UCU1AOGG Recovery Mode does not use DM-Verity when exiting, and the Combination Firmware doesn't seem to use it at all So....
Q1.) Can someone please help me get at least a systemless root installed? WITHOUT using a custom recovery? It might need to actually be a system root though looking at the Galaxy S8.
This should be possible using the LL Engineering Kernel & Engineering Sboot for the Factory Binary. Especially since the August builds are fully exploitable by DirtyCow, and with an eng Kernel that is half the battle we were using dirtycow for in the first place. Now we should be able to use DirtyCow to finish the root injection. Because the Factory Binary does not utilize DM-Verity that is obvious. So using the Factory Combination Firmware, there may actually be a way to legit boot a custom recovery I feel, even if only for one boot, that is plenty enough if prepared when that oneshot boot happens. Once installed with the full Combination Bootloader (ODIN BL file) I can then flash any N920A LL ODIN AP File. All the way back to N920AUCU1AOGG. Warranty Bit Intact, Official Status, Normal Rebooting. In fact, after everything I've done thus far, I have still yet to trip my KNOX Warranty (Still 0x00).
**************
** MM 6.0.1 **
**************
Here are the contents of the tar.md5's:
Code:
tar -tvf AP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 28746016 2016-08-10 00:31 boot.img
-rw-rw-r-- dpi/dpi 29413664 2016-08-10 00:32 recovery.img
-rw-rw-r-- dpi/dpi 4125403456 2016-08-10 00:33 system.img
-rw-r--r-- dpi/dpi 549536816 2016-08-10 00:33 userdata.img
tar -tvf BL_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 00:31 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 00:28 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 00:28 cm.bin
tar -tvf CP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 37269840 2016-08-10 00:28 modem.bin
tar -tvf CSC_ATT_N920AATT3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 3072 2016-08-10 00:32 NOBLELTE_USA_ATT.pit
-rw-r--r-- dpi/dpi 89608656 2016-08-10 00:34 cache.img
For this MM Stock Firmware, I've also come across this Modem for a Z3X Flash Box, that is used when direct unlocking this device. I do know, that when I have this CP installed, I do have access to the APN Editor, to Add/Modify/Delete APN's:
Code:
tar -tvf N920A_UCS3BPH4_CP_FOR_UNLOCK.tar
-rw-r--r-- 0/0 37269840 2016-08-10 00:28 modem.bin
******
**************
** LL 5.1.1 **
**************
I’ve happened upon the full ODIN flash-able SW Rev 3 Factory Binary for the AT&T Galaxy Note 5. It allowed me to do a full firmware downgrade from MM 6.0.1 to LL 5.1.1 without worrying about trying to downgrade my binary counter in download mode. It’s the only 5.1.1 build I’ve seen that isn’t a binary 2-(SW REV 2) & It contains these files:
Filename: COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
Code:
tar -tvf COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 06:44 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 06:43 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 06:43 cm.bin
-rw-rw-r-- dpi/dpi 24660256 2016-08-10 06:44 boot.img
-rw-rw-r-- dpi/dpi 24754464 2016-08-10 06:44 recovery.img
-rw-r--r-- dpi/dpi 1537858544 2016-08-10 06:44 system.img
-rw-r--r-- dpi/dpi 4292768 2016-08-10 06:44 persdata.img
-rw-rw-r-- dpi/dpi 36163408 2016-08-10 06:43 modem.bin
-rw-rw-r-- dpi/dpi 3072 2016-08-10 06:44 NOBLELTE_USA_ATT.pit
Using ODIN v3.12.5, I flashed this firmware using the AP slot overtop of the Full 3BPH4, and after flashing the Factory Binary these are the build details that boot up with zero errors. Mind you, I have tried this with, and without, a sim card inserted. It is not lost on me either, that UCS3BPH4 (Stock) and UCU3APH1 (Factory) have the same build dates listed on them.
***
* Device := SM-N920A
* Android Version := 5.1.1
* Baseband Version := N920AUCU3APH1
* Kernel Version := 3.10.61 August 10th 2016
* Build Number := LMY47X.FA51_N920AUCU3APH1
* SELinux Status := Permissive
***
From @TechNyne66 I got the LL Eng Kernel from the 2APB2 build. I have yet to see any other UCE branded files.
Code:
tar -tvf N920AUCE2APB2.tar
-rwxr-xr-x 0/0 27326752 2016-02-11 01:42 boot.img
But flashing this kernel into the Factory Binary sets SELinux to Enforcing, which makes things a bit more difficult. And I don't know how to edit the Kernel in a way I can repack it for flashing. My attempts thus far have failed when trying to flash a repacked boot.img. Probably because I did not make the necessary build.prop tweaks, and because I didn't use the correct compression levels to repack. What I mentioned earlier about not understanding the filesystem all that well anymore, stems from not having a broad understanding of build/default.prop & the various .rc/init files.
This is also possibly due to Samsung using a customized header for the Kernel's Binary.
Q2.) Is there a way to update the UID/GID from 'dpi/dpi' to '0/0' without modifying the signature embedded into the tar.md5?
Q3.) Is there a way to extract the extra data from the end of the file?
Q4.) Can I examine the persdata.img directly, to see it's contents before flashing? I don't know how to view the img format and how to extract it.
My post is too long, so I'm moving to post #2
Since these are too long to fit in post 1, I was forced to double post. Here is the last bit about partition tables. The reports are long. Please, any solid advice would be helpful.
***************************
** PIT File Examinations **
***************************
Moving on, I have used "PIT Magic 1.3 Release", found here on XDA, to look at the partition tables of the .pit files included with the N920AUCS3BPH4 & N920AUCU3APH1 ODIN firmware packages. I have also included the PIT File examination from the unlocked European Firmware. Given that PIT Magic 1.3 is a few years old, the latest version I have is labeled 2012. I read about how difficult it was to get the format correctly back then, and I have no way of knowing if the PIT File format has changed since then. But it does still seem to give usable output. I just don't know how to use this output meaningfully yet.
If you could hack one of the apps that are included in the sepolicy and set the Androidmanifest.xml to include android:dubuggable="true" we can make a two stage app. read and replace as root with the cow and then reload your inits.
toolbox.c root trick:
I am working on a very very powerful tool now. I am taking farm-root toolbox.c and changing it to grab root + context but then fork a process into a loop and just keep those privs. Hopefully I can even control that loop from the command line still! Currently I can get root and system_server, install_recovery.. But today after work we find out if I can hold on to it in a loop.
recovery-from-boot.p
I researched this today because we can read/patch this file with dirtycow. This file replaces the stock recovery every time you boot if they are different. I don't know if it also uses the hardware signature verification process, if so that's a key that's hidden in the partition image (hopeless for us i bet)
So if we replace recovery we have to crush this file with dirtycow.c
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
verg0 said:
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
Click to expand...
Click to collapse
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
droidvoider said:
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
Click to expand...
Click to collapse
No bud, the phone wont boot a normal firmware as the certificate is screwed and imei 0000000000, but it will boot with combination firmware, all i need to do is gain root and disable 'frp lock' via z3x box or another method and car repair the phone... Im not fussed about the warranty being void to be honest... I have ADB but not root fix phone
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Ah cool the combination firmware i have is:
COMBINATION_FA60_G935FXXU1APB5_STEP1_OLDFW\COMBINATION_FA60_G935FXXU1APB5_CL7345605_QB8752841_REV00_user_mid_noship.tar
The kernel is 3.18.14-7345605 Thu 25th Feb 2016 so it should be exploitable I'd love to get my S7 Edge working again
droidvoider said:
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Click to expand...
Click to collapse
Do you have your toolbox on github? And is it commented decently? If so, I can look into helping with your code. I ask about comments because Ive not really looked into the whole. But if we figure out what parts samsung and at&t stripped down the AOSP toolbox, there could be a vector for completely patching the toolbox binary installed on our device.
Most root methods I see around, use busybox and su.
But our note 5 actually uses toolbox instead. Meaning, adapting a root method to use toolbox instead of busybox, eliminates that extra disk space taken up by the busybox binary, that needs to be patched in memory.
I needed to finish another piece of code before I started on toolbox, and that code is finished and on github. I need to be able to replace a list of files and know they are exact byte for byte, that's the code that I made available, which is in itself cool. Now I'm testing how to control the toolbox loop but so far if I get input from the command line the child executes one task then dies. I don't really want to fork fork fork fork things.. I need better control logic. soon i will solve it then upload a great starting point
edit: I realized there is places I can post snippets of code.. Here's the code I'm playing with but please realize some things may not work, not belong or I may have started making variables I never used.. (this is the pile of code I am using for testing).
I test code in Ubuntu first otherwise there wouldn't be enough time in a day:
gcc -o fork_u fork_u.c
./fork_u
http://pastebin.com/7nFxGcnY
Update: It's not exiting after executing a command at all. I messed up that if statement that checks for x. I am not a C programmer by trade I took it in college 20 years ago. Now I'm relearning it, so be warned on that
====>] We have changed directions back to replacing the bootloader see the next post [<====
I am exuberantly confident we can take the bootloader after the testing I've done today. This is the basics of the bootloader
https://www.xda-developers.com/galaxy-s7-bootloader-lock-explained-you-might-not-get-aosp-after-all/
===>] I need someone to copy their bootloader in both locked/unlocked status so I can find what to change. [<===
I am starting to suspect I can't simply copy an unlocked bootloader from another device. I am fairly certain that I need to pull the sboot from the device, patch it and then push it back. I need to actually look at the source code and perform any steps it does as well, such as deleting stuff.
I need someone who is vulnerable to dirtycow with an unlocked version of the Note 5 to pull their sboot in locked/unlocked status. This means they would run the hack I'm using on their device, overwrite toolbox, dumpstate and app_process temporarily to pull the partition.
====>] Plan B is downgrading then attacking an earlier version of the phone [<====
I believe I can write the original sboot.bin and system.img to the Note 5 now to do a forced downgrade. If that is true we could be dealing with trying to root an Android 5.0 device instead of Android 6.0 .. This opens the door on a million exploits!!
Plan B is all I have for now let me know if anyone can help with Plan A
**** Warning **** This is the most dangerous developer tool I've seen in a very long time. You can easily smoke your device with this without even trying.
====>] farm-root updated for Note 5 [<====
Ok guys it works for recovery or boot. It will pull an image or push an image.
https://github.com/droidvoider/Note5-Root-Farmer
toolbox directory compressed for recovery and boot, matches above code
boot push / pull --- aosp toolbox directory
recovery push / pull --- aosp toolbox directory
-DFARM_BOOT changes from recovery to boot in the shared.c
-DFARM_PULL is for pulling in toolbox,c / bridge.c, no define means compile to push.
-DDEBUG is for logcat messages, recompile minus this option to reduce binary size a lot
===>] What was wrong? [<===
When I got this working at first a couple weeks ago I thought I checked the path but I didn't. That and the updates to dirtycow are the only differences between mine and freddies version. (except that I also added push boot.img)
partitions:
/dev/block/platform/15570000.ufs/by-name/RECOVERY
/dev/block/platform/15570000.ufs/by-name/BOOT
directory containing sym links: (shell is allowed to ls -la inside this directory and view partition links!)
/dev/block/platform/15570000.ufs/by-name/
===>] So why can't we do this to the bootloader? [<===
I am now focusing just on this idea!!
Notes: I have a suspicion that if we used the bootloader from another device the numbers won't match, such as mac, and that will be permanent hard brick. I need someone to copy their bootloader partition both locked and unlocked using a tool I create for that purpose. (anyone got a friend who will help out?) Obviously this will not be an AT&T version.
===>] Basic instructions [<===
Download and unzip to a Ubuntu directory (android sdk + ndk needed)
Plug in your device and make sure you can adb shell
Add a screen lock pin to your device first
In terminal change to the directory first then make log
Open another terminal then you compile the sources for pushing or pulling as follows
make pull_boot, make pull_recovery, make_push_boot, make_push_recovery
You will be hung on "waiting for process to complete"
On your phone enter your pin, then go to settings, remove the screen lock pin..
close settings
On your phone again now go add back a lock screen pin.. close settings.
repeat the lockscreen thing it will go...
===<> Breaking my rule and playing with it now <>===
I tried boot.img altered with Assayed kitchen modified heavily but no changes, I think it was written back on reboot I bet recovery-from-boot.p really replaces this.
So I tried with recovery.img from Assayed kitchen modified heavily, I got a big blue error telling me to take my phone to AT&T
(if you get an error use heimdall to flash the specific file(s) or use odin to flash your AP file from the firmware.)
Continue Notes: I have confirmed I am replacing the boot.img and recovery.img completely freddie knocked it out of the park fellas. I have only tried heavily modified versions, I have not tried modifying the pulled version yet. If I flash anything not factory the phone has an error screen telling me to take it to at&t. pwr+vol. down I have to release and retry but eventually I get it to reboot, then download mode. Then simply flashing back what I replaced with farm-root gets me back up again.
If I flash recovery.img from t-mobile note 5 twrp it won't give me the error message until I attempt to enter recovery! After that it will always give the error. I tried putting twrp as the boot.img but that fails too, it does look like it almost loads something then I get the chain of trust error.
continuation of notes: I've still only tried heavily modified versions but I have unpacked the boot.img and recovery.img I've pulled, they are complete. If I flash recovery.img first then reboot without entering recovery it doesn't error. (until you enter recovery then it won't allow boot)... So instead I flashed boot.img also. Now boot.img isn't replaced on startup, I get the blue error message and this time I have to flash both recovery.img and boot.img to get the phone working again. (what does that mean?, mostly it confirms we wrote to both partitions which I have also confirmed through pulling / testing after writes) one thing is for sure this is a lot more fun then having nothing.
edit: nevermind on this idea I want to stay focused on unlocking the bootloader or downgrading it to Android 5.01
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
droidvoider said:
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
Click to expand...
Click to collapse
If toolbox is becoming limited, Toybox is also a partner binary that is used on the system beside toolbox.
Also if you can shrink the system partition and keep it persistent. You can shrink it from 4gb to 3.5 safely and then possibly reclaim that 500mb for your own private partition. My installed stock system uses 3.4gb of 4. That hidden partition should then remain even after a factory reset. As long as the device was not repartioned by odin or otherwise. Or as long as a new PIT isn't flashed.
This is where you can store your hacks, and have access to on device when first booting to recovery from a fresh flash.
toybox, good idea
I forgot about toybox when I get this code working I will rerun some of the test code on it to see how powerful it is.
New logic for root-farmer
root-farm will now only have 1 bridge and maybe 2 toolboxes (depending on final binary size for toolbox)
Now the files to PUSH/PULL are in a text file. Bridge copies it to cache and then toolbox can read it also.
PULL example: <= everything before the '|' is one execv command used by toolbox. => | <=== following this character is bridge copy leftvalue => | right value
of=/cache/recovery/bota0_pull.img if=/dev/block/platform/15570000.ufs/by-name/BOTA0 bs=10m|cache/recovery/bota0_pull.img|/data/local/tmp/bota0_pull.img
So push will only push a files.txt, pull_files.txt/push_files.txt is copied to /data/local/tmp/ then bridge decides if this is a push or pull depending on the text file format. After that it's pretty much business as usually toolbox uses the dd command as root+install_recovery to over write or copy anything
This code snippets are not complete. They are meant to show you what I did to test my theories.
toolbox_working example
bridge will copy files.txt to /cache, toolbox will pick it up and then spit the contents out into logcat -- success
unfinished_test_code
that's the parsing, it echos the commands it doesn't actually dd anything.. but you can see it echo what it should be copying, or dd'ing.
updated (adding sources per a users request):
brdg.c.tar.gz == linux proof of concept for bridge, i make copies, test stuff from blocks of code like this then port to android
This morning something dawned on me. If I can write to the first partitions known to the computer worlds as MBR1 512kb limit MBR2 extended mbr.. Then I already own this device. Now I need twrp with the correct addresses for my device, I simple write twrp on the device and wipe the rest.
While I think that is true 100% I have different passions then simply winning. If anyone is willing to try it I will port farm-root over to point at those partitions instead, and also to replace them in one go.
Those waiting for the finished tool I get to play today a little since I had to work Sunday! we should have a template at minimum this evening. I'm adding to sources one is the partitial conversion it will be called Android_Dirtycow_root_farmer from now on.. (because it isn't specific to any device any more it will work with any 64bit dirtycow vulnerable device)
the test zip?, man I forgot what I tested with that just type make test and watch logcat.. tests are always safe, reboot afterwards though.
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
More info on it
I updated this thread with some info first/last posts only
https://forum.xda-developers.com/no...g-dirtycow-t3559637/post71102343#post71102343
What about root right now?
If I can get system_server + root, then switch to install_recovery + root I can fork both these processes away and send commands to them through a text file just like I sent the options for push/pull. This code wasn't only to eliminate the need for multiple toolbox / bridge binaries.. It was to create a command shell that I can issue any command. Remember my examples above?
.....Work study: take the examples I created and create a loop that doesn't close but instead waits for changes to a text file. Then execv those changes returning to wait again for more changes.
I have to be away for 1 to 4 weeks I just found out.. I might be able to check messages, I dunno. not away but same as.. have fun
Im going to go over all this, this weekend. Hopefully I can work out what data to write.
If we can patch /sbin/sverifysignature then we maybe able to disable the sig check. Right now my device is without a DT_Hash, I have busybox installed and linked to /system/xbin
I also have the su binary in xbin but its not linked so apps dont know it's there. But they both persist through reboots no problem. I am currently half way rooted, with zero hiccups so far.
Im close but im running 5.1.1 with an eng kernel and eng sboot. I dont currently have a CSC installed.
The problems im running into are that most apps have always done root the same way, the way that doesnt work on this device. Root is possible, but the age old standard root injection doesnt fly here, we have to do it manually this time because the standard root install scripts expect privs we dont have in certain places. That doesnt mean we can't root, it just means we have to edit the scripts and run them from some place other than TWRP. Which is still possible.
So here is what I have:
Dm Verity verification failed... Message when entering recovery. No effect on operation.
ADB root on boot, and when charging offline.
Busybox 1.22 fully linked from /system/xbin
Chainfire supersu 2.76 su binary placed in /system/xbin unlinked, I dont know how to link it like I did with busy box.
Even though dm verity fails, I can mount the entire filesystem read/write, and all my changes are still in place after normal reboot. I can modify my system and dm verity does NOT undo my changes. I can even pull my boot img from /dev/block/sda5
What do I have in my hands right now?
HP TOUCHPAD has discovered a wonderful way to speed up the old girl, but for many it's too complicated. So here's an easy way.
Download the SKZ Kernel from here
Download Swapper from the Playstore
This creates a swapfile rather than a swap partition. There's plenty of discussion about the relative merits of each, but for normal operations, they're pretty much equivalent.
You'll need to be rooted, of course, and your ROM needs to be Dirty Unicorns. Set the swap for what you want (I used 384 MB, but you'll never need more than 1 GB). The kernel contains most of HP TOUCHPAD's changes, but I've not disabled anything in the kernel, so you can still set it any way you want.
Enjoy, and be sure and thank HP TOUCHPAD for his great work.
...
friends, I do not know how to do this, a step by step video, please refer to the step when creating the kernel installation zip file, which the user will install using TWRP.
Add a script to create the swap file and format, a video with this step please
HP_TOUCHPAD said:
__SNIP__
Add an script to create the swap file and formatted:
Working directory:
Code:
cd /boot/usr/sbin
./lvm.static vgchange -ay
./lvm.static lvcreate -l 100%FREE -C y -M y --major 254 --minor 0 -n /dev/store/swap
mkswap /dev/store/swap
__SNIP__]
Click to expand...
Click to collapse
Ok, you win. Check out my latest kernel here
...
..
HP_TOUCHPAD said:
--SNIP--
The issue it by setting the permission (set_perm), something is wrong.
Click to expand...
Click to collapse
Try this
..
HP_TOUCHPAD said:
--SNIP
Also the process of update is been done by update-binary and not busybox. The update-binary that you have is 832.7 kb the one on the Dirty Unicorn ROM zip file is 1.3 MB. I also swap the update-binary but it did not work.
I think that the reason set_perm does not work is because is not integrated in the update-binary which has all the commands to execute the update-script.
Where does the update-binary comes from? where is it generated from?
--SNIP--
Click to expand...
Click to collapse
Version with an old update-binary here. I tested it in recovery, and it seems to work, but I'm not holding my breath.
...
HP_TOUCHPAD said:
Is a good thing you did not hold your breath, other wise your skin color will be like a Smurf and not able to read this message, as you will be on the other side ;-(.
The update-binary been only 254.7 kb, is able to change the permission and also run a program and that is all we need it to do. But because the environment is not properly set in TWRP the common arguments does not work and everything must be specified. The run_program ("lvm.sh") does not work as I explained why.
Just when I thought that I knew the basics, now I am learning how Edify Code works and that is the fundamental as is the (creation), (installation) or (flashing) of everything that gets copy and executed in Recovery.
I got it working!
But I am writing everything in details to wipe out all the partitions ( a reset ) and then recreating everything including the swap partition, it should work for all models 16GB 32GB and 64GB. One single zip flash!
Will report back with the results!
Click to expand...
Click to collapse
Good luck. I'm done. I did notice, however, that you can replace the update-binary with your own shell script, but that was more than I wanted to do.
...
help!
Halloo
I'm trying to do this as my touchpad is unusably laggy using DU. I can't get it rooted though... Can someone explain the latest method? I tried various SuperSU zips, nothing works. I suspect I'm doing something wrong..
...
Thats good news! Meanwhile could you help me with the SuperSU problem?? I want to get rooted!!
...
HP_TOUCHPAD said:
--SNIP--
The swap file is not been use by the Kernel.
( keep it lean )
--SNIP--.
Click to expand...
Click to collapse
The swap file is not in use because there isn't any command to turn it on. You need to add "swapon /dev/store/swap" to the script or in the ramdisk after boot initialization.
This is where we part company. I've always wanted to provide the greatest flexibility, not the necessarily the best performance. I'm not really interested in providing the single "best" configuration since I don't know what others think is the "best". You're doing a great job - go for it. I'm outta here.
..
This is sounding good! Hope you guys are successful!
...