Related
Looking at the boot.img that came with the Lollipop update, I see that it starts with "ANDROID!" and the regular Android boot image header, instead of whatever was being used before.
Further, there is a file in the update called kk2lp_partition.tbl which seems to include GPT partitions for boot and recovery.
With this information it sounds like building and flashing custom recovery and kernel/OS should be easier than it has been.
I tried using "fastboot boot boot.img" but unfortunately that still doesn't work ("stubbed on this platform").
I just made a copy of boot.img and stripped the signature(? blob at the end that doesn't get counted in the ANDROID! header, so I'm assuming) and flashed it, supposedly successfully, and booted. Either it didn't actually flash or this now has the "developer" mode enabled by default.
I'll try more later. If somebody has a recovery to try, let me know.
EDIT: Also, if anyone has an idea where I could post the update.zip I'd be happy to upload it (It's 923MB).
EDIT2: For the record I pulled an adb bugreport during the OTA download and it downloaded from some cloudfront server with a Signature and an Expire flag and when I try to re-use the URL it gives me an error page.
To me sounds like your already unlocked your bootloader in 4.4.4 and this update didn't lock it back nor should it. Now if you didn't unlock your bootloader prior to updating to lollipop, flashing the boot.img should have left the tablet unbootable.
Just guess as I don't have the tablet, the tablet I do have once unlocking bootloader I can go up or down on the 3 OS available and none relock the bootloader.
A better test would be someone who hasn't unlocked their bootloader to flash modifed boot.img.
Did you make the boot.img unsecure? if not you should, that way you will know if your modified boot.img flashed or not, by booting up and looking at the file you edited.
I tried modifying the boot image and it lets me flash it but then it doesn't boot. I think maybe when I tried it the first time, since the signature (must be what it is) was at the end of the file it didn't get overwritten in storage, and the otherwise-unmodified boot.img verified against it. But when I added some extra junk on the cmdline, it dropped back to recovery when I tried to boot. Reflashing the original boot.img gets me booting again.
So we'll have to wait for the dev. edition firmware again to get this thing running unsecured images in Lollipop.
Its probably the same format as the nexus player with the bootstub at the end of the image maybe you could upload?
Does any one have the ota so I can patch the stock firmware to investigate rooting it?
social-design-concepts said:
Its probably the same format as the nexus player with the bootstub at the end of the image maybe you could upload?
Does any one have the ota so I can patch the stock firmware to investigate rooting it?
Click to expand...
Click to collapse
@xBIGREDDx appears to have it, I am thinking this is like samsung's boot.img use unpackbootimg to unpack.
vampirefo said:
@xBIGREDDx appears to have it, I am thinking this is like samsung's boot.img use unpackbootimg to unpack.
Click to expand...
Click to collapse
If its not full uefi it should still be using the bootstub like the nexus player but they could of added a separate bootloader like Sammy does with sboot on their Intel tab but nexus player formatted image would make more sense to me would still start with the android header what I fear killed root is the commit added that doesn't run console as root user. But have to see the image
xBIGREDDx said:
Looking at the boot.img that came with the Lollipop update, I see that it starts with "ANDROID!" and the regular Android boot image header, instead of whatever was being used before.
Further, there is a file in the update called kk2lp_partition.tbl which seems to include GPT partitions for boot and recovery.
With this information it sounds like building and flashing custom recovery and kernel/OS should be easier than it has been.
I tried using "fastboot boot boot.img" but unfortunately that still doesn't work ("stubbed on this platform").
I just made a copy of boot.img and stripped the signature(? blob at the end that doesn't get counted in the ANDROID! header, so I'm assuming) and flashed it, supposedly successfully, and booted. Either it didn't actually flash or this now has the "developer" mode enabled by default.
I'll try more later. If somebody has a recovery to try, let me know.
EDIT: Also, if anyone has an idea where I could post the update.zip I'd be happy to upload it (It's 923MB).
EDIT2: For the record I pulled an adb bugreport during the OTA download and it downloaded from some cloudfront server with a Signature and an Expire flag and when I try to re-use the URL it gives me an error page.
Click to expand...
Click to collapse
hey，I just made a big mistake. that i didn't read this before i update my dell 7840.
So, here is the problem, and I really need your guys' help.
I can't enter recovery!!!!! every time there is just one f***ing intel icon..
Somebody save me !!!
social-design-concepts said:
If its not full uefi it should still be using the bootstub like the nexus player but they could of added a separate bootloader like Sammy does with sboot on their Intel tab but nexus player formatted image would make more sense to me would still start with the android header what I fear killed root is the commit added that doesn't run console as root user. But have to see the image
Click to expand...
Click to collapse
Ok looked at boot.img Samsung style ie use unpackbootimg to unpack boot.img, boot has own partition like Samsung and this new elite 7QS walmart $50 tablet I just got.
Looking at recovery.fstab all parts have it's own partition.
#size_hint=16
/dev/block/by-name/boot /boot emmc None length=0
#size_hint=16
/dev/block/by-name/recovery /recovery emmc None length=0
#size_hint=16
/dev/block/by-name/fastboot /fastboot emmc None length=0
new thing to me is verity_key
it's in both boot.img and droidboot.img
looks like simple unpack repack to me, for root and recovery.
vampirefo said:
Ok looked at boot.img Samsung style ie use unpackbootimg to unpack boot.img, boot has own partition like Samsung and this new elite 7QS walmart $50 tablet I just got.
Looking at recovery.fstab all parts have it's own partition.
#size_hint=16
/dev/block/by-name/boot /boot emmc None length=0
#size_hint=16
/dev/block/by-name/recovery /recovery emmc None length=0
#size_hint=16
/dev/block/by-name/fastboot /fastboot emmc None length=0
new thing to me is verity_key
it's in both boot.img and droidboot.img
looks like simple unpack repack to me, for root and recovery.
Click to expand...
Click to collapse
verity_key might have to do with verified boot another Intel commit relates to 3 boot modes secure boot insecure boot and verified boot.
There is another Intel commit relating to partlink and mapping the those images to block by name
it be interesting to see if those are physical block devices or virtual ones using the mapping once the device is rooted.
Playing with the kid havnt had time to play with electronics today yet.
Looked at the partition table awesome stuff there can't wait to play now
this is of great interest: flash_osiptogpt_partition("/tmp/kk2lp_partition.tbl") || abort("OSIP to GPT partitionning failed");;
haven't inspected but this is probably the boot loader package_extract_file("sl_vmm.bin", "/tmp/sl_vmm.bin");
social-design-concepts said:
verity_key might have to do with verified boot another Intel commit relates to 3 boot modes secure boot insecure boot and verified boot.
There is another Intel commit relating to partlink and mapping the those images to block by name
it be interesting to see if those are physical block devices or virtual ones using the mapping once the device is rooted.
Playing with the kid havnt had time to play with electronics today yet.
Looked at the partition table awesome stuff there can't wait to play now
this is of great interest: flash_osiptogpt_partition("/tmp/kk2lp_partition.tbl") || abort("OSIP to GPT partitionning failed");;
haven't inspected but this is probably the boot loader package_extract_file("sl_vmm.bin", "/tmp/sl_vmm.bin");
Click to expand...
Click to collapse
I just got time to unpack system, real large system over 2GB image, 1.6GB used, droidboot contains trigger 3, (stop_partitioning) has other possibilities also does not contain unlock for (fastboot oem unlock), would have been to easy, lol.
pojoker said:
hey，I just made a big mistake. that i didn't read this before i update my dell 7840.
So, here is the problem, and I really need your guys' help.
I can't enter recovery!!!!! every time there is just one f***ing intel icon..
Somebody save me !!!
Click to expand...
Click to collapse
You will need xfstk-downloader and also the firmware files which are part of the OTA update.zip.
Looks like anggusss uploaded the OTA here.
Inside the update.zip, there is a zip file called "ifwi.zip" and in there you take "dnx_fwr_blackburn_qs_qs.bin" and "ifwi_qs.bin" and flash with the downloader tool.
I just looked at the images they are as I suspected the same format as the nexus player with the bootstub at the end of the image followed by an Intel not sure which version signature $MOSS follows but it is a signed image
sl_vmm.bin ? So Intel / Dell is running Android 5.x.x through a virtual machine on this device?
vampirefo said:
That's good, is bootloader still locked on 7840?
Click to expand...
Click to collapse
Just pm'd you @vampirefo , I got something i really need you to look at before i share it. . . . . .
social-design-concepts said:
Just pm'd you @vampirefo , I got something i really need you to look at before i share it. . . . . .
Click to expand...
Click to collapse
Any chance you'd mind sending that something my way?
@xBIGREDDx these link cover the new image format used :
http://events.linuxfoundation.org/sites/events/files/slides/ABS Lollipop MR1 Verified Boot.pdf
the pdf is directly link from this article : https://lwn.net/Articles/638627/
it's a good read
this is the part i was asking @vampirefo about
Bootloader Lock States
• A verified boot capable loader has 3 different security states • Locked, Verified, Unlocked
• State transitions done via Fastboot commands
• Any state transition should erase all user data • Defense against attackers with physical access to the device, so that they cannot flash a hacked boot image and
access userdata contents
• /data partition zeroed out; on next boot, fs_mgr will see this and initiate reboot into Recovery to create a
filesystem
• Any state transition should require the user to physically confirm with the device’s buttons that the
state transition is actually desired • Defense against malware which could otherwise surreptitiously issue ADB and Fastboot commands to unlock the
device without user’s knowledge
• Setting device to “unlocked” state requires option change in Settings app Developer Options • Not enabled by default, user with proximate access must get past the lock screen to change this
• More details later under Persistent Data Block slides
• Specific commands may vary across implementations • In Kernelflinger: “fastboot oem {lock|unlock|verified}
Bootloader States (Continued)
• “Locked” state • Devices ship to the end user in this state
• No images may be flashed or erased with Fastboot
• Boot/Recovery images verified by the bootloader using enrolled keystore
• “Verified” state • A subset of targets/partitions may be flashed or erased with Fastboot • bootloader, boot, system, oem, vendor, recovery, cache, userdata
• Boot/Recovery images verified by the bootloader using enrolled keystore
• Good state for running user-built Android images or third-party images like Cyanogenmod • Device is still secure, may have to deal with a prompt at boot if keystore isn’t signed by OEM
• “Unlocked” state • Device may not be unlocked if flag in Persistent Data Block is not set via Settings app
• All Fastboot commands available
• User keystore may be enrolled or erased • Erasing keystore causes loader to fall back to OEM Keystore for image verification
• “fastboot flash keystore <path to keystore binary>” or “fastboot erase keystore”
• Unlocked devices do not verify boot or recovery images
• User may be warned at boot that the device is unlocked and requires physical interaction to proceed
Persistent Data Block (PDB)
• Implemented as a small “persistent” partition in the fstab • Raw data, does not contain a filesystem
• The very last byte in the partition stores whether unlocking is enabled • Must contain value 0x01 or unlocking is forbidden
• Not all methods of doing a Master Clear are the same • A Master Clear initiated by the Settings app will zero the persistent partition along with user data • Considered trusted as user would have to get past lock screen to do this
• Erasing userdata from Recovery Console or Fastboot in “verified” state does not allow this
• Relevant code • frameworks/base/services/core/java/com/android/server/PersistentDataBlockService.java
• packages/apps/Settings/src/com/android/settings/MasterClearConfirm.java
• packages/apps/Settings/src/com/android/settings/Utils.java
• Devices with Google Mobile Services store additional user data in the PDB • Untrusted resets will require Google account sign-in of an account that has been already used by the device,
before the device can be used again
• Discourages thieves
• All bets are off if the device can be rooted
what we can't tell is if this is the lock state for the anti-theft feature or the bootloader ?
Ah, yeah, Google has a page up about that as well:
https://source.android.com/devices/tech/security/verifiedboot/verified-boot.html
Looks like the boot flow is a little bit different from what the Intel paper describes; I'm guessing one is a newer revision of the spec than the other.
Delete Me Please
@alexenferman
AFAIK the bootloader is the program that starts whenever a device is powered on to activate the right operating system - that's true for all computers.
In the world of Android devices the bootloader determines when to run Android or when to enter Recovery mode. Bootloader is a low-level code it contains the instructions that tell a device how to start up and find the system kernel. The bootloader setups the network, memory etc which requires to run Kernel.
The bootloader verifies the integrity of the boot and recovery partitions before moving execution to the Kernel.
Wondering what sense it makes to replace an existing bootloader?
Look inside here if your time allows.
Delete Me Please
Heya guys,
Been reading up again on some new tablets+phones and thinking about flashing new ROMs etc.
I've done some a while ago, and since I use Linux as an OS and don't have Windows, it pays me to understand a bit more about the whole process since lots of guides try to specify using Windows-only tools, but also it helps if things go belly-up.
So, I've been looking around, and I just wanted to check if I understand things right, and also if there are more sources out there to read up on (since things I have found don't always seem to give the detail).
And I really only care about Android 10 or later - older android is in the past.
[sources]:
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/The-Android-Booting-process/ta-p/1129182
https://www.cnblogs.com/shangdawei/p/4513604.html
https://source.android.com/devices/tech/ota/ab
[some others like Wiki]
So, most phones / tablets, go through the bootloader straight into the newest Android "system" partition (a/b).
When pressing the buttons on boot-up, the bootloader redirects into the "recovery" mode partition... Basically this is another partition with the code that runs.
When flashing TWRP, that image goes into the "recovery" partition of the disk layout and replaces it.
Fastboot is, either a part of the bootloader, or loaded over the USB cable when entering it?
Also - this is where Samsung's "download" mode is... Is is a mode or a part of the recovery partition?
When flashing a custom ROM / LineageOS, you put the image into a "system" partition (a/b) .. I don't recall seeing any sort of switch in the TWRP to switch between a/b partition?
I would have thought that flashing a LineageOS image would replace the partition completely rather than just overwriting files - is this the case?
I assume the Kernel images are on the "system" partition?
"/boot" partition I assume is the "bootloader", which isn't touched much as part of normal flashing...
Is the above correct?
Thanks for all info provided.
--
Paul
** UNOFFICIAL A-TEAM RELEASE**
*******Testing ONLY*******
**testing has only been done on GN2200 July patch device but should atleast boot into twrp on other sec patch on GN2200 devices***
***Let us know if not***
*****HEED THE WARNING OF IMPENDING APOCALYPSE, DOOM, BOOTLOOPS , BRIMSTONE AND FIRE, AND ALSO TWRP ******
***NOBODY IS RESPONSIBLE FOR WHAT YOU DO WITH THIS EXCEPT YOU***
***DO NOT BUILD AND FLASH THIS UNLESS YOU KNOW EXACTLY WHAT YOUR DOING***
****DONT DO ANYTHING I SAY, I CANT BE HELD RESPONSIBLE FOR WHAT I SAY OR DO*****
**THIS IS AN ** UNOFICIAL RELEASE ** SO DONT GO CRYING TO ANYONE THAT YOU MADE YOURSELF AN EXPENSIVE PAPERWEIGHT IF YOU USE ANYTHING IN THIS POST***
********* THE RESPNSIBILITY LIES SOLELY UPON YOU***
***FLASHING IN CURRENT STATE DOES NOT BOOT INTO SYSTEM****
****READ EVERYTHING BEFORE YOU DO ANYTHING******
******ONLY POSTING THIS FOR DEV PURPOSES*******
******Huge THANKS to PizzaG for this!!!******
***Thanks to Eduardo as well for his contributions, he may still be working on his own release***
Am posting this with a copy/paste i posted in telegram group..
We need people with the knowledge/skills and experience to help get this TWRP finished AND/OR work out the bugs.
GitHub - PizzaG/recovery_device_oneplus_OP515AL1
Contribute to PizzaG/recovery_device_oneplus_OP515AL1 development by creating an account on GitHub.
github.com
*this is not ready for release but the source is here for anyone who can build upon it*
touch is not working
you cant fastboot boot on this device so DO NOT flash this to your device without a backup of your stock/current boot image
issues we are having is no touch, can't mount /data, and so far cant boot into system with the recovery installed so if you want to use it youll need to flash this to boot, use it for whatever and then flash stock boot back, if your magisk patched youll need to flash the backup of that patched boot image you made before flashing this in order to get back into your system....... i have sort of found a slight work around for having to keep flashing the boot partitions until someone can get this to boot by placing my current boot image on an sdcard along with the twrp, flash the twrp to the active boot partition, boot into twrp, install image and install your backed up boot image to the current slot, then go back to advanced and install twrp to ramdisk and select and install the twrp image to the ramdisk, if your magisk patched you need to flash magisk zip right now, you can adb shell into twrp to pull a copy of this boot image if you want and i have flashed my "twrp-ramdisk installed boot image" on the Slot that my system is on and stock/backup boot image to inactive slot because its the only way to boot back to system for now without reflashing the stock(backed up) boot image back to the slot. and reboot into bootloader, change active and reboot and your back into your system.... when you need twrp you can set active to the other slot, it will bootloop once into bootloader and choose recovery to get back to twrp... when done reboot to bootloader and set active back to the other slot and reboot into system.............otg mouse works, adb works, mtp works, some work has been done on the touch but thats still not working yet, everything seems to be mounting except data............. big shout out to PizzaG for this
***this is a very round-about way to get a currently buggy twrp on the device but if you have a usb-c adapter and mouse you can navigate twrp....***
PizzaG doesnt have the device and has spent more time than anyone could possibly ask someone to spend on this for free... I dont have the skills required yet to really work on this. I have tested as much as possible and here it is for those who can build and work on it. i dont recommend releasing in its current form because im sure alot of people will be complaining and bricking their devices. if you can build it im sure you can work on it and should have the skills to atleast recover and have the sense to make backups first.......
Thanks again to everyone who has already donated the valuable time working on this for us and to everyone who will follow and build upon this!
You can find the telegram group for our device here:
You can find the A-Team in telegram
Also FYI in case you missed the post about our kernel source, it can be found here:
GitHub - OnePlusOSS/android_kernel_msm-5.4_oneplus_sm6375 at oneplus/sm6375_r_12.0.1_oneplus_nord_n20_5g
Contribute to OnePlusOSS/android_kernel_msm-5.4_oneplus_sm6375 development by creating an account on GitHub.
github.com
If anyone with experience building twrp and especially for OnePlus devices needs a tester or any files from the device hit me up on telegram @PsYk0n4uT2 and I will do my best to provide whatever you need and test builds along with providing logs.
heres a compiled boot image from the above tree as of 10/02/2022.
**remeber it DOES NOT boot to system, this is twrp only, not installed into recovery ramdisk yet. so BACKUP YOUR STOCK(current) boot image FIRST**** you will have to flash your stock(current) boot image back to boot back into your system. you can sort of get around this by above mentioned method BUT here it is for the GN2200 anyways. working on my July patched device and my May patched device so it should work for other GN2200 sec patches too...
***BACKUP BACKUP BACKUP*****
also cant change active slot from twrp, must reboot to bootloader to change active slot
Heres TWRP installed to ramdisk on a july patched boot image. does not boot to system but since it doesnt you should still be able to use this on any patch for testing purposes.....
You can backup your boot image and flash your current boot image to inactive slot and flash this to active slot by selecting recovery from bootloader after it loops once.... use twrp then go back to bootloader and change active and reboot to get back into your system.
**BACKUP YOUR CURRENT BOOT IMAGE****
***DOES NOT BOOT TO SYSTEM**
***YOU WILL NEED YOUR CURRENT BOOT IMAGE TO BOOT YOUR SYSTEM< YOU SHOULD ALREADY HAVE A BACKUP OF YOUR STOCK IMAGE IN THE CASE THAT YOU ARE MAGISK PATCHED ALREADY< KEEP A COPY OF BOTH IN CASE YOU DECIDE TO WIPE DATA< YOU WILL NOT BOOT BACK INTO YOUR SYSTEM WITH A MAGISK PATCHED BOOT IMAGE IF YOU WIPE DATA*******
if someone can get their system to boot after installing the TWRP from post 4 or their own build after personal edits please post here how you were able to achieve the install and maintain booting into system..
currently twrp indicates that path to /mnt could not be found and cant mount /data .. i think if someone could fix this maybe some progress could be made
ScarletWizard said:
I wonder if TWRP will work for devices with a serial number defeicy
Click to expand...
Click to collapse
halfway working on mine, just isnt finished yet, we need someone who knows alot more about this than i do. another dev is working on twrp but needs a device. the serial wont affect anything else other than the oneplus care app and getting the unlock token..... other than that u have full functionality.... the one posted above needs ALOT of work to finish. no touch yet but it could work for SOME things....
I know C/C++ at a decent level, however; I don't have much experience with low level stuff (especially dealing with bootloaders and other specific proprietary android kernel stuff). If there is anything that needs testing, I am down for it since this is just a secondary phone for me and I won't be too upset if it explodes.
I'm going to attempt this
[ SOLUTION ] [ MTK ] to Fix Touch not Working on TWRP / Philz Due to Kernel Disabled Touch.
In this tutorial, i'm going to show how i managed to patch kernel to enable touch in recovery TWRP / Philz. WARNING : This worked fo...
factopea.blogspot.com
It's written for mtk device but might have similar enough instructions to port for qcom kernel,
But I believe this is what is needed to get the TWRP touch going
Is the trwp.fstab using the right version? Both have different
Code:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,resize,check,formattable,fileencryption=aes-256-xts:aes-256-cts:v2+inlinecrypt_optimized+wrappedkey_v0,keydirectory=/metadata/vold/metadata_encryption,metadata_encryption=aes-256-xts:wrappedkey_v0,quota,reservedsize=128M,checkpoint=fs
Try this instead in twrp.fstab
Code:
/data f2fs /dev/block/bootdevice/by-name/userdata flags=fileencryption=ice:aes-256-cts;wrappedkey;keydirectory=/metadata/vold/metadata_encryption
Techted89 said:
Is the trwp.fstab using the right version? Both have different
Code:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,resize,check,formattable,fileencryption=aes-256-xts:aes-256-cts:v2+inlinecrypt_optimized+wrappedkey_v0,keydirectory=/metadata/vold/metadata_encryption,metadata_encryption=aes-256-xts:wrappedkey_v0,quota,reservedsize=128M,checkpoint=fs
Try this instead in twrp.fstab
Code:
/data f2fs /dev/block/bootdevice/by-name/userdata flags=fileencryption=ice:aes-256-cts;wrappedkey;keydirectory=/metadata/vold/metadata_encryption
Click to expand...
Click to collapse
i just unpacked the twrp image with AIK and made the suggested edits and repacked, reflashed, same...... another person is working on twrp and has gotten much of the fstab corrected in their build but their keeping their source closed til they get it ready for release and is still very far from being finished with it and doesnt have much time to work on it right now so we are just kinda stuck waiting on someone that knows what their doing to help get this going. the other person has touch working on theirs so i know its possible i just dont know how long it will be before we see a beta even
Techted89 said:
Is the trwp.fstab using the right version? Both have different
Code:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,resize,check,formattable,fileencryption=aes-256-xts:aes-256-cts:v2+inlinecrypt_optimized+wrappedkey_v0,keydirectory=/metadata/vold/metadata_encryption,metadata_encryption=aes-256-xts:wrappedkey_v0,quota,reservedsize=128M,checkpoint=fs
Try this instead in twrp.fstab
Code:
/data f2fs /dev/block/bootdevice/by-name/userdata flags=fileencryption=ice:aes-256-cts;wrappedkey;keydirectory=/metadata/vold/metadata_encryption
Click to expand...
Click to collapse
also i see a recovery.fstab instead of twrp.fstab in /system/etc. is this what your referring to?
You need both from what iv read ,. TWRP.flags is a module that rewrites the stab at a certain point which may be the reason it's not compiling but I will post. Recovery.fstab is supposed to be a copy paste from the boot.img and gives the general mount partitions locations,. TWRP.fstab is mounted using the same partitions but different format/flag structure to be available to TWRP .
Techted89 said:
You need both from what iv read ,. TWRP.flags is a module that rewrites the stab at a certain point which may be the reason it's not compiling but I will post. Recovery.fstab is supposed to be a copy paste from the boot.img and gives the general mount partitions locations,. TWRP.fstab is mounted using the same partitions but different format/flag structure to be available to TWRP .
Click to expand...
Click to collapse
Interesting article above. Were you able to get that to work? I know it says MTK but seems like mechanism should be the same, or atleast I would assume anyways that the function would be very similar in the case of a flag. Was told you needed to use original kernel but then I couldn't get that to boot period. I'm out of my area of knowledge at this point but always willing to learn.
Also I tried messing around a little with the f stab and TWRP flags I was told that TWRP flags is pretty much the same as the twrp.fstab... also this build needs to have something added to the drivers I do believe that this is somehow related to USB touch it is a goodix gt9886 touch panel using the Samsung 9886 drivers. Maybe the init's need some help here as well.
I have the programming knowwledge that TWRP would require, but have not as of yet created one as my devices were typically readily complete before-hand. Once my device is back up, and running I am going to boot into Ubuntu and give it a go.
I need some excuse to have learned assembly x86, c, c++, Java, Python, and rust and have been eyeing learning scripting so it could be a fun side project assuming it is still incomplete as of the moment?
Is it normal for manufacturers to use components from other's in their builds? The kernel posted seemed to indicate at least a couple Samsung files included.
Well C is a guarantee possibly some C++ as well and definitely some sh scripting if you know rust and know how to attach it to C well enough that could add more possibilities I would imagine. The recovery is from my understanding in the boot image Android Image Kitchen would help you see it unmodified if that is the case.
I found a unofficial TWRP that flashes to the boot partition, and works pretty damn well, id have to say! I am not an experienced developer, I just like to flash around on my phone in my spare time.. Anyways here y'all go:
I am down while I got partitions backed up to the cloud.
Looking out for help
I need to edit the boot.img but my problem is that every time i unpack the img and repack it the phone doesnt boot anymore (even w/o modifyng the boot.img only unpacking and repacking) it enters into a bootloop
is this bcs the boot.img are signed ? or that theyre in a different fromat like ext4?
Im flashing the boot.img with SPFlash tools
I got the Custom Rom and the boot.img from this thread https://forum.xda-developers.com/t/...om-firmware-root-playstore-certified.4405615/
Some boot images are AVB0 signed. Hard to tell if that's even checked.
You've got to tell us how new/old, how fancy your boot image is.
My best advice (as always) is don't take apart a boot image if you don't need to.
You can always use my ImgUtil.
At the very least you can use it to see what you're dealing with.
Code:
C:\>imgutil.exe /v /l myboot.img
Renate said:
Some boot images are AVB0 signed. Hard to tell if that's even checked.
You've got to tell us how new/old, how fancy your boot image is.
My best advice (as always) is don't take apart a boot image if you don't need to.
You can always use my ImgUtil.
At the very least you can use it to see what you're dealing with.
Code:
C:\>imgutil.exe /v /l myboot.img
Click to expand...
Click to collapse
Thanks for your fast reply. is it possible to repack with the imgUtil tool?
what im trying to achieve is to block the access to the recovery menu on the phone
Just do the imgutil command above. It won't affect anything but it will tell us what we're dealing with.
I don't know why/what you want to do to recovery.
@Renate Oh my goodness, thank you! This is precisely where I left off last night I finally learned how to unpack the boot image (using linux wahh) and now you share such a cool tool! GOSH AND ITS WINDOWS TOO. Thank you! There's literally so much junk tools out there it held me up a year x.x Miss Renate do you have tools for the system images too? TBH I just used superrs kitchen to unpack my stock image, but i'm not sure the tool will work for repacks bc I tried in the past and kept getting boot loop but i suspect that's something to do with whatever is stored in the kernel and ram disk? Sorry last question, have you wrote up something somewhere that I could read about what to do with the ramdisk or kernel?? Thank you for always being on here
Renate said:
Just do the imgutil command above. It won't affect anything but it will tell us what we're dealing with.
I don't know why/what you want to do to recovery.
Click to expand...
Click to collapse
I did imgutil /i and worked !!! thanks a lot this is a great tool
how can I modify the recovery menu this is the file I get (attached) I tried with Hex and notepad++ but couldnt find the entries of the menu
What Im looking here is to remove the option to wipe and format the phone from the recovery menu
Or maybe I should modify the init.rc ? to create a reboot command when entering recovery
but how can I send this command ?
this is my init.rc
There are 5 versioned types of Android images plus the latest unversioned type.
The kernel could be compressed with gzip or lzma with/without a stub or uncompressed.
It could have the dtb appended to the kernel or in its own section or not present
It could have AVB0 signing or not.
Your image could be padded or even truncated.
I still don't know what device or what type of image we're talking about here.
Please quote at least the lines out of imgutil.exe myimage.img /v
Yes, the whole point of imgutil.exe is that you don't have to explode everything and park it in Windows directories and then try to put it all back.
I'm still unclear what the point of this whole project is.
Is it to prevent yourself from accidentally wiping your device in recovery by hitting the wrong key?
Or is it to prevent some evil person from wiping your device?
Me, I don't mess around with the recovery menu.
I make sure that I have rooted ADB available in recovery and just disable the whole recovery executable/menu.
Anything that I want to do I can do over ADB in recovery.
Renate said:
There are 5 versioned types of Android images plus the latest unversioned type.
The kernel could be compressed with gzip or lzma with/without a stub or uncompressed.
It could have the dtb appended to the kernel or in its own section or not present
It could have AVB0 signing or not.
Your image could be padded or even truncated.
I still don't know what device or what type of image we're talking about here.
Please quote at least the lines out of imgutil.exe myimage.img /v
Yes, the whole point of imgutil.exe is that you don't have to explode everything and park it in Windows directories and then try to put it all back.
I'm still unclear what the point of this whole project is.
Is it to prevent yourself from accidentally wiping your device in recovery by hitting the wrong key?
Or is it to prevent some evil person from wiping your device?
Me, I don't mess around with the recovery menu.
I make sure that I have rooted ADB available in recovery and just disable the whole recovery executable/menu.
Anything that I want to do I can do over ADB in recovery.
Click to expand...
Click to collapse
The point of this project is to prevents employees of a company to wipe their phones.. this phones are locked to some spcecific apps and nothing else, the company doesnt want their employees to have another apps on the phone.
How is it possible to disable the recovery from ADB?
I tried removing the recovery file but when accesing the recovery via adb reboot recovery the phones gets stucked at the boot logo and needs flashing back the boot.img to turn back on the system.
That is why I wanted to insert a reboot command in the init.rc from the ramdisk.
Please tell me what do you think is the best option and how can I achieve this.
The phone Im dealing with its a Xiaomi Qin F21 Pro
Thanks
Well, security is not my field of expertise (or passion), but:
Make sure ADB works in recovery
Set ro.adb.secure=1 to enforce ADB authentication
Generate some ADB keys and make sure that you have a safe copy
Put the public key in /adb_keys
Make sure that it all works
In init.rc under the recovery service add "disabled"
Now you've got a recovery that shows as a blank screen. ADB is present but will only work on your authorized keys. If you have a need for the recovery menu just type start recovery in ADB.
Now, there may be a problem that people can get to recovery but it keeps on going back to recovery. That may depend on who/what is supposed to wipe the BCB or /misc. When testing you can start recovery and exit that way. You may need to have a script or something wipe the BCB or /misc.
While ro.adb.secure=1 is no security in the regular system, in recovery it should be a guarantee as there is no confirm dialog possible. But check.
Renate said:
There are 5 versioned types of Android images plus the latest unversioned type.
The kernel could be compressed with gzip or lzma with/without a stub or uncompressed.
It could have the dtb appended to the kernel or in its own section or not present
It could have AVB0 signing or not.
Your image could be padded or even truncated.
I still don't know what device or what type of image we're talking about here.
Please quote at least the lines out of imgutil.exe myimage.img /v
Yes, the whole point of imgutil.exe is that you don't have to explode everything and park it in Windows directories and then try to put it all back.
I'm still unclear what the point of this whole project is.
Is it to prevent yourself from accidentally wiping your device in recovery by hitting the wrong key?
Or is it to prevent some evil person from wiping your device?
Me, I don't mess around with the recovery menu.
I make sure that I have rooted ADB available in recovery and just disable the whole recovery executable/menu.
Anything that I want to do I can do over ADB in recovery.
Click to expand...
Click to collapse
This is what I get:
imgutil.exe boot.img /v
Header2: 1,660 (0000067c)
Kernel: 11,291,051 (00ac49ab) 00000800
Ramdisk: 7,875,739 (00782c9b) 00ac5800 2022-11-09 17:08
DTB: 98,837 (00018215) 01248800
Signature: 1,600 (00000640) 01261000
Command: bootopt=64S3,32N2,64N2 buildvariant=user
Renate said:
Well, security is not my field of expertise (or passion), but:
Make sure ADB works in recovery
Set ro.adb.secure=1 to enforce ADB authentication
Generate some ADB keys and make sure that you have a safe copy
Put the public key in /adb_keys
Make sure that it all works
In init.rc under the recovery service add "disabled"
Now you've got a recovery that shows as a blank screen. ADB is present but will only work on your authorized keys. If you have a need for the recovery menu just type start recovery in ADB.
Now, there may be a problem that people can get to recovery but it keeps on going back to recovery. That may depend on who/what is supposed to wipe the BCB or /misc. When testing you can start recovery and exit that way. You may need to have a script or something wipe the BCB or /misc.
While ro.adb.secure=1 is no security in the regular system, in recovery it should be a guarantee as there is no confirm dialog possible. But check.
Click to expand...
Click to collapse
When I add disabled in the init.rc under recovery If the phone gets into recovery with adb it gets stucked a the boot logo.
Also I had some trouble creating the keys
Anyway I would like to say Thank you for all of your help
isach59 said:
When I add disabled in the init.rc under recovery If the phone gets into recovery with adb it gets stucked a the boot logo.
Click to expand...
Click to collapse
If you disable recovery the screen when it boots will be whatever. The important thing is if you have ADB running correctly. Moreover, if you get lonesome you only need to start recovery
isach59 said:
Also I had some trouble creating the keys
Click to expand...
Click to collapse
Recovery has a ramdisk. You need to add the adb_keys to that. If you're having trouble don't set ro.android.secure until you resolve it.
isach59 said:
Looking out for help
I need to edit the boot.img but my problem is that every time i unpack the img and repack it the phone doesnt boot anymore (even w/o modifyng the boot.img only unpacking and repacking) it enters into a bootloop
is this bcs the boot.img are signed ? or that theyre in a different fromat like ext4?
Im flashing the boot.img with SPFlash tools
I got the Custom Rom and the boot.img from this thread https://forum.xda-developers.com/t/...om-firmware-root-playstore-certified.4405615/
Click to expand...
Click to collapse
Hello and good morning, @isach59
Welcome to XDA. I hope you'll always get the support you require.
However, prior to your next posting please read the guidances that are stuck on top of every forum like
[ATTN] : Read before posting - Any questions posted here will be MOVED or CLOSED
Please read the below before posting. Any questions not development related will be moved or closed. Forum Searching | Posting | The Basics: (Make sure you've read them before starting a new thread) Forum Rules Forum Search Google Forum...
forum.xda-developers.com
and the others. I've moved your thread to Android Q&A.
Thanks for your cooperation!
Regards
Oswald Boelcke
Senior Moderator