I know this is a pissed off issue by many of you but I want to use my archos as an industrial tablet.
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
br, sodjas
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Sad news modinfo shows:
alias: char-major-10-243
license: Proprietary
description: flashrw
author: Archos
depends:
vermagic: 2.6.10_mvl402 ARMv5 gcc-3.4
It is Proprietary
Hi sodjas,
you should do a little more research on this issue.
sodjas said:
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
Click to expand...
Click to collapse
As you started to point out, there are different bootlogos for the differnt stages on start-up.
1. bootloader logo
2. ramdisk bootlogo
3. Android logo (animated)
The logo inside Android could be easily removed or replaced (at least using Urukdroid).
Also the ramdisk logo could be modified with some technical skills (ramdisk needs to be rebuild and replaced).
Replacing the first hardcoded bootloader logo, is something for the freaks, but in fact it is possible.
First of all you'll need read/write access to the mtd block devices created by the kernel. This would require at least SDE or Urukdroid installation.
The Archos tablets use embedded MMC as persistant storage.
All partitions of this device are mounted as block devices and could be tweaked by directly accessing them (e.g. using dd for low level access).
One could start by reading some sectors of the first raw partition, examine the structure, do some disassembly and find the location where the bootloader logo is stored. Not sure if it could be deleted without changing some lines of code.
In fact this is an expert thing, if something goes wrong, you'll have a true brick .
There'd been some posts around covering this topic.
sodjas said:
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Click to expand...
Click to collapse
AFAIK, there's no need for this kernel module on gen8 devices.
The gen8 devices do not use any raw NOR flash or NAND devices.
All access to the eMMC is done with mtd kernel driver using the OMAP mmc interface.
BTW there might be some parts of storage used as hidden sectors, but this is a kernel thing only.
But back to topic:
In fact you'll need to find the bootlogo in raw data of the bootcode, determine the format and replace the raw blocks of memory.
Maybe you'll also need to tweak the security checks in bootcode as well, because checksum will change is the bootlogo is replaced.
Anyway it's slightly difficult to do so, but it's not impossible
Have fun,
scholbert
Lot of interesing information thank you, I'll check the hints out... The checksum thing sounds serious
Anyway, thank you very much for your answer it contains a lot interesting and useful things for me!
br, sodjas
Hi sodjas,
you're welcome!
This might be of interest to:
http://forum.xda-developers.com/showthread.php?t=1018260
This guy already made a disassembly of boot code.
http://forum.xda-developers.com/showthread.php?t=1214674
This guy wrote some tools for mmc low level access.
Maybe they might help you as well.
Keep on posting, this is an interesting topic
Regards,
scholbert
@sodjas:
Just being curious, why do you want the archos as an industrial PC?
I'M asking because we have bought a very cheap development board
http://embedded-computing.com/low-runs-main-line-linux-android
where you can install everything you want.
It is definately not as powerfull as the archos, but it costs less then half of it.
And if you search for OK6410 you will find others that even have the Android 2.3 for that.
@scholbert:
Thank you very much one more time , hope we can bring out something interesting
@fzelle:
The answer for this is the circumstance when you are at a software development deparment surrounded with high level software guys and have an interesting and impressing task to build an RFID enabled industrial terminal with WIFI capability and a platform where you can easly build fancy touch based UI-s in just 3 months then you made choices like these -> to have a proof of concept thing -> to prove that your software is unique and feasible to develop -> to be able to go to exhibitions to make this interesting to investors -> later it is more then possible that we will say somebody who has the experience in hw building: OK we have this HW build us a similar one from OEM parts bundled in an industrial box...
@both:
Thank you guys for replying, this is such a nice community!
br, sodjas
Hey Guys!
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Sorry for the lots of questions, I'm still very green on low level
br, sodjas
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
br, sodjas
Of course i understand that, i'm a sw dev for 25 years.
I was lucky to see that board before we had some similar needs as you have.
What do you use for the rfid part?
Hi sodjas,
it's late but i'll try to answer your questions
sodjas said:
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
Click to expand...
Click to collapse
So this is the firmware structure before it is installed on the device.
The update process is done by the bootcode and there's not that much information about it and not much we could actually do with these files.
So you'd better have a look at the installed partitions and the way to modify thoose.
sodjas said:
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Click to expand...
Click to collapse
No, the squashfs file is the final rootfs mounted as a loop device by the stock firmware.
It's possible to modify this file, but if you do the checksum won't match and you'll have to tweak bootcode to ignore security checking.
So in fact this is not very comfortable, but doable.
The ramdisk is the the cpio file archive also beeing updated and included in the update. Don't know the structure right now because it's on my linux laptop.
sodjas said:
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Click to expand...
Click to collapse
I don't know this tool and i guess it has been made for the older platforms.
sodjas said:
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
Click to expand...
Click to collapse
Yeah, as i pointed out:
By extracting the update file you got an "external view" of the system.
After the firmware is placed on the device these files are flashed to eMMC and got mounted as block devices.
So it's little different then.
sodjas said:
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
Click to expand...
Click to collapse
It's a bit complicated to explain... but quite easy in the end.
You'll have to read out the partitions as raw blocks.
All the low level stuff is mounted as /dev/block/mmcblk0p1
Please read out first using the dd command.
It will give a file at about 32MByte, ands it's all cryptic binary format (rawfs and below).
So if you like to enter this, there's not much information here and you'll have to digg out pieces.
Maybe it's better to modify the higher level parts...
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Attached you'll find the mounts of stock and Uruk firmware.
I know that this is little abstract right now, but i'll have to take some sleep
Have fun!
scholbert
@fzelle:
the rfid part is for workflow monitoring in glass houses. we would like to deploy N terminals in each house and the workers can check-in, define a task they are working on and after they've finished can check out... simple but all info is gathered on a central place and is in order to make easier planning/observing/and calculating financial/investment related things...
the only problem is the musb_hdrc.ko -> it is not picking the FTDI chip if its plugged-in with the OTG cable at the same time. It is a known issue but I still have a lots of problem here:
1. if a change musb_hdrc.ko to my instance musb_hdrc.ko in /lib/modules it is not working at all, if I check it with modinfo it is different than the one in the GPL release. I guess these files under /lib/modules are also proprietary
2. I degbugged around and saw that the state changes for musb only work well if you first attach the OTG micro which has a grounded 5th pin ->then the state goes to a_idle and then attach the FTDI chip -> this is a working scenario
3. If you attach the OTG with already connected FTDI then it stuck at b_idle mode...
I started a thread about this:
http://forum.xda-developers.com/showthread.php?t=1288522
but it seems the proprietary drivers will be the root of the problem here...
@scholbert:
a mininum thing I owe you is a beer a lot of useful infos here again I'll check around and come back if there are some updates.
thank you guys!
br, sodjas
Hi,
thanks for appreciating.
But stupid me, i forgot one thing...
Quoting myself:
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Click to expand...
Click to collapse
So there's a kernel driver for rawfs of course
The rawfs parts got mounted to /mnt/rawfs and present themselfs as files (avboot, banner,...).
No need to fiddle with the raw binaries to investigate the structure.
You'll have to be root to access this directory.
I'll do some research about the file format of the banner file
EDIT:
O.K., here we go... it is a gz compressed file representing raw pixel data.
So in fact this is the very first boot logo!
Should be possible to import this file to gimp or something.
Don't know if it breaks the avboot security check if it get's replaced. So please be careful!
EDIT2:
I got a Archos 101 so filesize will vary on other platforms.
The pixel data is put into 32bit format so each pixel requires a 4-byte value.
On A101 the resulting file size is of the uncompressed banner file is 2457600 bytes -> 1024x600x4
The simple framebuffer inside avboot uses only the lower 24bit of 32bit pixel data.
The most significant byte of each pixel is always set to 0xFF (0xFF000000 written as MSB first)
To completely blank screen (delete archos logo) you'll need to blank out all pixel.
Pixel data should look like this:
Code:
0xFF000000 x 1024 x 600 (for A101)
0xFF000000 x 800 x 480 (for A70)
You might create such a file with a hex-editor or use some scripting.
Good luck with your USB driver stuff!
Regards,
scholbert
Update
I modified both mmcblk0 and mmcblk0p1, my tab is still booting.
The modification of /mnt/rawfs/banner directly was my idea too, but I'm still afraid of some parts
I pulled the banner file and on ubuntu I can list the content, but can't extract it, and there are lots of questions like:
1. The file inside banner is named i240x400 -> this means that it is a 240x400 image but it would be more logical that it is 400x240 based on how "Entertaiment your way " looks...
2. Ubuntu's file roller can't extract it
3. When I open it in hex editor it has some meta info at the start of the file
and a question at the end:
How did you uncompress your banner file? I always get errors, maybe I used wrong syntax...
br, sodjas
Hi Sodjas,
Let me jump in on this to complement your study:
First, a BIG WARNING: touching any of this without patching signature check will result in bricking device.
Second BIG WARNING: Vitalif's mmc offsets for bootloader patches are valid for his device only. Mine has completely different values, I presume there are multiple bootloader versions out there. If patch is incorrect, or not done in the right order, instant brick.
7_MMC and 8_MMC are indeed interesting parts, these are the kernel+initrd images for android and recovery.
As stated by scholbert, to get a better understanding, you should take a look at /mnt/rawfs:
You'll see few files there:
avboot (second stage bootloader)
init (normal boot android, kernel+initrd)
recovery (recovery boot, kernel+initrd)
custom (sde boot, kernel+initrd)
banner (boot logo as it seems)
7_MMCF is flashed to init
8_MMCF is flashed to recovery
Splitting these files into zImage+initrd.gz is quite easy, I can give you some hints if you want. But I don't think it would serve you much for what you're trying to do: what you want is changing bootloader logo, so your goal is avboot+banner.
But again, don't modify anything on mmc0 until you're sure of what you do. First bootloader checks avboot signature and avboot checks init and recovery signature for sure. Without patch, you'll brick your device.
I don't know if avboot checks banner file though.
Hi Letama,
Thank you for joining.
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Two big questions still open for me:
1. How to modify banner in an efficient way?
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Update 2
In the meantime I uncompressed it on win with 7-zip I see the content I should modify to 0xFF000000 but I'm still not sure how flush this to all 0xFF000000 because there is some meta info at start. And as second, how to compress it, maybe the gzip -9 i240x400 will do its job as it was described at Gen5 boot logo tutorial...
br, sodjas
sodjas said:
because there is some meta info at start.
br, sodjas
Click to expand...
Click to collapse
Sorry AFAIK, no metainfo, just the pure 0xAABBCCDD 32bit values as scholbert told me before, sorry for that
br, sodjas
I realized again I'm a fool, or just archos guys wanted to make a joke
1. the banner file is named i240x400 BUT
2. when you extract it you got a 1 536 000 bytes sized file
3. I used my awsome maths skills and found out that: 1 536 000 / 4 <byte> = 384000 / 800 <pixels> = 480
So the raw image size is 800x480 and no 240x480 as the file name indicates...
I just need to flush 0xFF000000 384000 times in a file I think.
br, sodjas
sodjas said:
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
Click to expand...
Click to collapse
Yes, search pattern was the same for me too, only different offsets. Good thing that code didn't change.
sodjas said:
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Click to expand...
Click to collapse
I only modified init and recovery, but I guess they wouldn't implement a specific signature check for boot logo. I'm suspecting that there is no signature check at all on it but I never checked avboot for that.
sodjas said:
1. How to modify banner in an efficient way?
Click to expand...
Click to collapse
To modify init and recovery, I wrote a small app that directly open /dev/block/mmcblk0p1, seek for the right position (with some file signature check to be sure I'm doing it right) then write. I make sure that I don't write a bigger file than current ones and it works fine for init/recovery. I believe that archos flasher does the same as existing file sizes are bigger than the firmware dump file sizes.
For your needs, I don't know if you will have to adjust size in the rawfs directory entry and/or avboot. Rawfs is quite straightforward, you can take a look at linux driver if you need to adjust directory entry.
sodjas said:
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Click to expand...
Click to collapse
A dd of mmcblk0 (not mmcblk0p1, you need also first bootloader) should do the trick if the hardware doesn't change and doesn't need a different bootloader. I think that there is multiple revisions of hardware out there, improper bootloader for a specific hardware revision could not boot.
Safest bet would be to write a small patcher that would check pattern and stop if you don't have a known bootloader.
Related
Hi tereg,
[SIZE=-1](If you are not tereg, you can stop reading this. I didn't PM because I needed to ship an attachment)[/SIZE]
Have a look at the attached (custom) recovery (pick it apart and diff it against the leak-V3/RUU recovery.img) using split_bootimg.pl and the gunzip | cpio pipeline.
You can flash it to your recovery partition and run it if you like, it doesn't do anything dangerous. Basically, it is the same thing as the Leak-V3(=RUU = OTA-2.1) recovery, with two major changes:
- /sbin/recovery service is turned off so this doesn't run automatically (and as a result you won't see the splash screen change from the 3 skating droids). You can run it manually, though, from the adb shell - just wait 8-10 seconds and adbd will come up.
- I added the shell (sh) and a few of the diagnostic tools (dmesg, dumpstate, logcat... and supporting dynamic link libraries, the linker, etc), and dropped in there both /system/bin/toolbox (HTC) and /system/xbin/busybox and created some of the symlinks so that an adb shell has a useful set of tools available. (Oh yeah, I added an /etc/fstab as a convenience for /system/xbin/mount. Note the system mtd partition mounts at /os-system so it won't cover up all the installed tools underneath /system in the boot image)
- I altered the init.rc (and default.prop) so that adbd will always come alive - not just when a race is won.
The base of this image (kernel, bootscripts, /sbin), is the leak-V3 recovery.img; everything else such as dynamicly linked executables and supporting dynamic libraries comes from Jcase's Plain Jane, which in turn comes from Leak-V3/OTA/RUU, so, essentially everything in this bootable recovery comes from HTC except the version of busybox in /system/xbin and mods to the init scripts and default.prop
Note that the NAND flash partition in the mtd device for the recovery is only something like 5.2 MB - I would have added more, but was starting to get tight on space.
If you want it to run as close as possible to the timing of the HTC leak-V3 recovery.img, what I would do would be the following:
- defer all the symlinking in init.rc (except for the "sh" and "ln", of course) and package that up into a shell script that you can run after the recovery has booted
- uncomment (re-enable) the "recovery" service (/sbin/recovery)
- maybe experiment and see if you can get the complete kernel boot sequence from dmesg without starting logcat as the first service (that's not done in the normal recovery).
The only other useful piece of info that I can think of at the moment is that you need to use the ---base option with mkbootimg with an address that starts with something like 0x11208000..... (I can't recall and my machine is down - crap.) You can discover the value of the kernel base address load offset for the Eris by snooping through a hexdump of the beginning of any valid Eris bootable image
cheers
bftb0
MD5s
5801babcdf4e6e5d51e5f775aad0a09e ErisNoRecovery-recovery-v0.9.0.img.zip
4d280b367be75e7e75563a6357575ea7 ErisNoRecovery-recovery-v0.9.0.img
Sent via my nearly dead crap Pentium II booted from a 2003 version of Knoppix - 256 megs of EDO RAM - woot!
Sorry, here's the attachment
I read it anyway.
Suck it.
Hungry Man said:
I read it anyway.
Suck it.
Click to expand...
Click to collapse
Same Here Brosidon,
Well, actually i attempted to read it. Then I got confused and went and got some beef jerkey.
mmm beef jerky. i read it to maybe there will be a fresh recovery menu for the eris.
i read somones got beef jerkey and not sharing *waves fist* four messin up kid
j/k
it would be nice if we got an updated recovery. especially now learning that we won't need/be able to format our sdcards using FroYo.
Actually, I don't mind if anybody reads or uses that - it just gets me off the hook when somone asks
"But what is this for?"
Now someone will ask, LOL
bftb0
bftb0 said:
Actually, I don't mind if anybody reads or uses that - it just gets me off the hook when somone asks
"But what is this for?"
Now someone will ask, LOL
bftb0
Click to expand...
Click to collapse
but what is this for??? can i root my eris 2.1 v3 leak??? can it make pizza out of code? jk jk lol,
Thank you, I got it now.
I will definitely be experimenting with this. I'll let you know if I have further questions.
Tereg, I'll be online tonight and can help with testing.
WHAT'S IN THE RAMDISK
So anyone who has compiled a kernel (for the X8) or is about to step into the world of developing android awesomeness through kernel building, should know that there are 2 (two) parts to the kernel:
The kernel image compiled from source code, and
The ramdisk
Both are equally important and are inter-dependent; without the kernel, the ramdisk is nothing (unless of course the devs come up with any other use) and without the ramdisk, the kernel is incomplete (again, this may change in the near future).
You (XDA-ians as I like to call you guys), especially those in the X8 sub-forums must have read viper001's kernel building guide. If you haven't, and do not want to read just 4 posts because of your laziness, it tells you how to compile your kernel image. Hah, now you are almost dying to read it. Well go ahead, read it.
Done reading. Well if you followed that guide to the letter (which I am sure many of you haven't), you'll have compiled your kernel with the FXP ramdisk. Now you want to build it from another source. It's pretty much the same process. However the FXP ramdisk won't work with this kernel. Not a chance (maybe a little). You need the ramdisk so you unpack the kernel using DooMLorD's tool (and forget to thank him; go thank him right now) and see a folder named kernel.sin-unpacked. You open it and see a bunch of files that you've never even heard of. You drop the kernel-building project.
This guide will hopefully eradicate that fear, or ignorance (maybe), and cover up what's in the ramdisk.
The parent (or root) directory of the ramdisk folder itself contains a bunch of files and folsers, which also contain more files.
Let's look at the contents in the root directory:
1 “modules” folder – This one is pretty easy. It contains the kernel specific modules that are loaded up at boot.
2 “res” folder – This folder contains another folder named “images” which contains images to be used in the recovery (more on that later).
3 “sbin” folder – Inside this folder are about 200 files (may vary), most of which are responsible for basic functioning of the phone.
4 default.prop – This file contains only a few lines of code that allow adb to run (line 4) and also makes the kernel insecure to give us permanent root.
5 init – This program initializes elements of the android OS and looks at the two following files:
6 init.rc – This file contains generic initialization code
7 init.<machine_name>.rc – This file contains device-specific initialization code.
8 initlogo.rle – This is the bootlogo (not the bootanimation which comes with the ROM).
9 pre_hw_config.sh – This file is executed at boot to get settings like cpu freq and governors just right.
10 recovery.fstab – This file specifies how the different partitions and file systems are to be mounted.
11 ueventd.rc – This file sets user or group (or root?) permissions on /dev nodes. (I got this line from the Internet and have no idea myself what the hell this means o_0).
12 ueventd.goldfish.rc – This file is empty in our kernels. Dunno why, though.
Now for the files in the /res/images directory:
1 icon_clockwork.png – This is the background seen in CWM.
2 icon_error.png and icon_firmware_error.png – These images are displayed on the screen when there is an error. Not sure though as I have never encountered any such error before in my life.
3 icon_firmware_install.png and icon_installing.png – These images are displayed when installing anything via CWM.
4 indeterminateX.png (where X is a number from 1 to 6, both inclusive) – This is basically the animation of the progress bar (the grey stripes moving forwards, or backwards, or both).
5 progress_empty.png – This is the progress bar during the initial stages of flashing anything in CWM.
6 progress_fill.png – This is the progress bar fill.
These are the files in the /modules folder:
1 sdio.ko – This is a file related to WiFi.
2 tiwlan_drv.ko – This is the tiwlan WiFi driver module.
3 tiap_drv.ko – This is the tiap WiFi driver module.
4 x8uv.ko – This is the undervolting module.
5 synaptics_i2c_rmi4_no_dt.ko – This disables dual touch in Synaptics.
6 synaptics_i2c_rmi4_dt.ko – This enables dual touch in Synaptics.
NOTE: I am not an expert.
More to come soon. See you and I hope sincerely that I do not get banned for this.
THE DREADED SBIN DIRECTORY
Going into the /sbin directory, we see a lot of files, the names of each sending shivers down your spine. But fear not, for sgt. meow will help you understand the functions of some important ones:
1. adbd – The file that allows you to use the adb shell. “adbd” stands for “Android Debugging Bridge Daemon”.
2. bootlogo – This file starts the kernel bootlogo (according to some user on the androidcentral forum; just saw a snippet on google search, opened the page and there was no thread).
3. bootrec – This file basically tells a kernel how to boot up a recovery
4. busybox – It lets you run LINUX / UNIX based commands (ls, gzip, uname etc.) that are required for root-level tasks.
5. dmesg – It is the Linux kernel's own logging system and is similar to logcat.
6. fix_permissions – This file applies and fixes permissions on the Android data folders.
7. insmod – This file is basically what is executed when you type insmod /..../../../../ xxx.ko (or similar) to load up the modules. An alternative way to do this is to write the line in hw_config.sh of /system folder (I guess) to load up modules at every boot. Or you could place the modules in the /modules directory of the kernel.
8. killrecovery.sh – This file, as the name suggests, kills the recovery when you exit it and boots into Android.
9. nandroid – The file responsible for nandroid backups.
10. nandroid-md5.sh – This file generates MD5 checksums for nandroid backups to verify its integrity.
11. reboot – This file reboots the phone when prompted to.
12. recovery – This is the recovery binary. For our devices, it is CWM recovery. This file can be changed easily (what I did with oxydo ICS) to other recoveries for this device for that version of Android.
Most of the other files are LINUX / UNIX based commands and some are files the functions of which cannot be explained by me.
More to come soon. Hope you enjoyed it so far.
FILES YOU CAN EASILY EDIT IN THE RAMDISK
There are some files in the ramdisk that can be edited pretty easily. There are also other files editing which means you gotta be RD or gotta have similar talent. Let's not go into that for now. The easy ones are:
1. initlogo.rle - The file that is easiest to edit. Basically you can convert any image to .rle format and replace it. make sure it is the right resolution.
2. /sbin/recovery - You can use recovery from another kernel (for the same Android version)and replace it in yours. You can also compile your own recovery binary by issuing the make recovery command after a successful CM build.
3./sbin/bootrec - You may have to change this when you change the recovery. Just a simple copy paste, that's all.
4. /sbin/rec_input - This file may need changing too when you change recovery.
5. /res/images/.. - Every .png file in this directory can be easily changed to any other .png file. Just make sure the resolutions are right, or else you will not be able to navigate properly in recovery.
6. init.rc - This file is easily changeable but you need to know what you are doing, otherwise you may mess up the boot sequence.
You can have a shot at changing other files, too. Lemme know how it goes.
CREDITS:
1. Allah Almighty (yes I'm a Muslim)
2. All XDA-ians, especially those in the X8 sub-forum for help (and for pressing thanks)
3. The Internet (Google, Wikipedia and Github mostly) for info
4. Me, for spending hours behind this guide.
5. My family, for not disturbing me while I was doing this. LOL
thank you
that is what i'm trying to understand :good:
This is for sure a valuable thread. Thanks for this!!
Sent With My Brains To Yours. Duh.
Nice thread , Captain Meow Meow
Sent from my X8 using xda app-developers app
sbin will take some time to cover but i will try my best.
sgt. meow said:
sbin will take some time to cover but i will try my best.
Click to expand...
Click to collapse
Its good to see that you are working hard...
Keep it up
great thread.thanks
sent from my x8™ using gingerzaraki®
THREAD UPDATED WITH SBIN CONTENTS. OMG. :wink:
Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.
RohinZaraki said:
Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.
Click to expand...
Click to collapse
And link to your sources as an example for others..
Banned? And why? This is usefull =))
Sent from my E15i using xda premium
@Rohin
yeah I might
@Elmir
that was a joke
@all
THREAD UPDATED WITH FILES THAT CAN BE EDITED AND CREDITS. :BIG GRIN:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
What exactly lies in the mmcblk0p7 partition?
MOVZX said:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
Click to expand...
Click to collapse
PER - Per device provisioned data or per device calibration.
A cursory scout around XDA suggests this contains sensor calibration and such like.
http://forum.xda-developers.com/showthread.php?t=1739119
(edit: checkout the last posts by osm0sis - this guy knows his stuff when it comes to partitions).
I'm pretty sure it isn't the BOOTLOADER partition...
I would tentatively suggest you're OK for a reboot. I can't think of what else you can do, to be honest.
-----------
If you must flash a recovery using the dd command use the by-name syntax...
su
dd if=/sdcard/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS
Rgrds,
Ged.
@GedBlake
Thanks for the info. I was asking, because if it didn't vary from device to device I could probably dd up a backup of the partition and upload it here for the user to dd into his partition in his tablet.
That being said, I'll keep an eye on this thread for further consequences or the like.
@MOVZX
Please state whether you have a Grouper or Tilapia device, and the approximate manufacturing date, if known.
The PER partition is formatted as a FAT filesystem**. It seems to contain measurement data created during factory testing procedures. See here.
Note that there seem to be differences from device to device (compare the two posts in the above link). Here are the two critical questions:
1) What is the exact FAT format? (There are a couple of different FAT variants)
2) Does the bootloader read this partition during hardware initialization?
I seem to remember a thread here in the Nexus 7 forums where someone was claiming to adjust the ambient light sensor by altering a file in the PER partition. If that is correct, then indeed this partition *could* be critical to correct operation of the device.
I think you are being prudent about not rebooting. I also think that you should find someone to volunteer to give you a raw image dump (dd) from a device that is as close to yours as possible. Note that like many other devices, the N7 has hardware variants, and the PER partition seems to reflect that.
The calibration data for your device is now permanently lost, and you are the unfortunate experimenter who will find out the consequences of that.
**If you can not get someone to help you, the issue of the filesystem formatting can be solved by one of us by:
- raw dumping our PER partition, loopback mounting it, removing all files, unmounting it, and then giving that to you.
At least you would then have the correct filesystem formatting, but empty.
Also, please do a
dd bs=1024 of=/dev/null if=/dev/block/platform/sdhci-tegra.3/by-name/PER
to let us know what size your partition is.
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
bftb0 said:
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
Click to expand...
Click to collapse
Interesting stuff, bftb0, as always...
So what, in your opinion, is the worst case scenario?
If the bootloader is still accessible, couldn't the OP just fastboot flash back to stock?
(Assuming a simple reboot doesn't fix it).
Or does this not touch the PER partition? I would have thought that running the flash-all.* script would reset all partitions back to their default values.
I'm probably missing something here, so apologies - just a suggestion.
Rgrds,
Ged.
@GedBlake
The factory install procedure doesn't touch anything but the "usual suspects".
We sort of already know what the worst case is. As to whether to bootloader "needs" the PER partition or not, I don't really know. At this point my bet is that it does not, but that is purely an educated guess.
@MOVZX
I am attaching a "PER-empty.zip" file to this post. It is tiny because it is an almost empty FAT32 filesystem image (PER.img), so it compressed by nearly 100%. (When you unzip it, the "PER.img" image file should be 5,242,880 bytes, or 5120 kB) If you want to, feel free to un-zip it, and then flash the extracted "PER.img" file to the PER partition on your device.
Assuming you are using adb from your PC with the custom recovery still running:
Unzip PER-empty.zip, then
Code:
adb push PER.img /sdcard/PER.img
adb shell dd if=/sdcard/PER.img bs=1024 of=/dev/block/platform/sdhci-tegra.3/by-name/PER
What this will do is install an almost empty FAT32 filesystem which was created with the exact parameters used on my device. (I assume that your device also has a 5120 kB PER partition, but you have not replied.) The almost part is that I truncated every file in my image to zero length.
That's not much, but at least you will have a valid filesystem and most files of the correct name, even if they are zero length.
Note that once you have a filesystem in the PER partition, you are free to mount it using the custom recovery, and do whatever you please, e.g.:
Code:
adb shell mkdir /data/local/tmp/permount
adb shell mount -t vfat /dev/block/mmcblk0p7 /data/local/tmp/permount
adb shell
$ cd /data/local/tmp/permount
... do whatever you want in here...
$ sync
$ exit
adb shell umount /data/local/tmp/permount
adb shell rmdir /data/local/tmp/permount
good luck with your tablet - let us know how everything turns out.
.
I'm using Nexus 7 WiFi 16GB.
I almost have all the required files. The sensors and lightsensor directories were found mounted at /data/sensors and /data/lightsensor, so I copied it.
Here is the content of my sensors & lightsensore files:
lightsensor/AL3010_Config.ini
1476
Click to expand...
Click to collapse
sensors/AMI304_Config.ini
921368
2048 2048 2048
0 0 0
600 600 600
210 42 -256
0 0 0
0 0 0
103 100 101
0
Click to expand...
Click to collapse
sensors/KXTF9_Calibration.ini
1071 -1035 1034 -1030 -1097 1213
Click to expand...
Click to collapse
The FAT partitions is now Ok.
Now, I'm missing these files:
adc-rawdata.csv
ISN
KXTF9_Calibration.ini
prom-filter-rawdata.txt
rawdata.csv
rek-prom-rawdata.txt
SSN
Click to expand...
Click to collapse
I'm having no confidence to reboot this device yet
Hey, I noticed while looking through the Stock Firmware AP file, that in meta-data/fota.zip there are .jar files that have to do with package signing. Only issue is that the zip is password protected. If someone has the Compute power and skills to decrypt a zip and look at the jar files and ****, maybe we could find a way to sign our own TWRP recoveries and roms. Just a thought, i'll post a link to the fota.zip file i was talking about in a bit if anyone wants to take a crack at it. (Google drive is taking forever to upload cause of AT&T's ****ty DSL speeds, sorry)
Download Link: htt*ps:/*/drive.*google*.com/file/*d/0B9tb-svjqaVD*b3Y0V0tXR3drSzA/vie*w?usp=sharing (Remove all *'s from link, stupid 10 post until you can post links limitation)
Thanks,
Lavavex
Did you saw this Thread?
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
About fota.zip...
Did you heard about plain text attack?
In few Seconds... minutes done... no password required but you can unpack.
Best Regards
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
adfree said:
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
Click to expand...
Click to collapse
Which will allow unpacking of the above zip? I thought it needed a zip password.
osm0sis said:
Which will allow unpacking of the above zip? I thought it needed a zip password.
Click to expand...
Click to collapse
We never found the Password... but for Decryption you need only these 3 Keys...
They can be easily found in few Minutes... with the right Tool...
Code:
2b4d493c
6142b289
1b7024aa
Here Key0 Key1 Key2 for Samsungs fota.zip...
This is really no rocket science...
Simple read about plain-text attack...
You can see all filenames...
You can see all filesizes etc...
Many files are floating around the Internet... to create ZIP for attack...
Then result is in few Minutes possible... :angel:
Use these 3 Keys in Tool:
Code:
Advanced Archive Password Recovery
And try self to unpack...
Best Regards
Edit 1.
Screenshot added...
Then maybe more clear...
Trial Version have mabye limtations... but to see it work... it is enough to play with trial.
@adfree or to anyone who can answer.
Quick question, what are the legal limitations to what is going on here? I may or not have a file from inside the fota.zip, but will sharing it put me in the legal wrong? If it is within the legal boundaries, I'd be happy to upload it for anyone to take a look at, but I don't want to land on the wrong side of the law by doing so. Please do let me know, as this is the most exciting development we've had when it comes to bootloader unlocking in a while. Also, it seems as though we can't view the entirety of the contents of the fota.zip with the trial version of the zip extraction tool mentioned in this thread, so if someone with more knowledge about this can confirm we could unlock our bootloaders with the contents of the zip (based on what is currently known about this), I'd be happy to bite the bullet of paying for the premium version given we can do this within the boundaries of the law.
Thanks.
1.
Maybe you can answer your question self...
Samsung PROTECTED this ZIP with password.
2.
IMHO it is Kernel related...
Yeah I know... Boot is every irritating...
But it is not sboot.bin related...
3.
About decrypting all files...
There are floating around Command Line Tool...
Code:
pkcrack
Try to Google it...
I have not tried...
I am 1 click Button user...
Best Regards
zipdecrypt from the pkcrack package plus those 3 keys worked flawlessly. :good:
Edit: Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
the password for that zip is fotatest1234
Correct. All fota zips passwords are fotatest1234
Drdra3 said:
Correct. All fota zips passwords are fotatest1234
Click to expand...
Click to collapse
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Delgoth said:
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Click to expand...
Click to collapse
Presumably what I previously said still stands:
osm0sis said:
Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
Click to expand...
Click to collapse
Hello,
I managed to break my fingerprint reader. I don't think the problem is my /persist because all sensors work fine. But unfortunately, I had never backed up the rest of the sensitive partitions: vbmeta, vbmeta_system, keystore, keymaster, odm, core_nhlos, secdata, abl, cmnlib, cmnlib64, devcfg, dsp, hyp, xbl, xbl_config, tz, rpm, aging, aging_mod.
Could someone on a TMO 7t Pro 5G McLaren (with a working fingerprint reader preferably running the latest 10.0.35 software, please pull and post these partition img files? If you don't know how, it's very simple, please ask.
I point to this because my previous phone, Essential PH1, had similar issues, but at least Essential had posted all of the firmware images on their website every month, and flashing the above partitions would fix it. 1+ doesn't provide anything and even the MSM doesn't restore all of these partitions.
Thanks so very very much in advance!
Edit: If possible, could one extract all partition img files from 10.0.35 in addition to those requested above?
EDIT2: ODM partition has 1st priority for anyone who can help.
Edit3: odm is fine. After looking through some logs,
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.
You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..
ttabbal said:
You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..
Click to expand...
Click to collapse
If you don't already have a backup of every partition, please please please do so urgently. Or an RMA will most likely be in your future. That should be in huge bold print with a link to instructions at the very top of the root and bootloader unlock threads.
I've never had a device with these issues before. It's starting to get ridiculous.
Edit: If you didn't take backups before unlocking the bootloader, Widevine L1 support (being able to watch Netflix in HD instead of 480p crap on our giant beautiful screens) is lost forever (except for RMA). And just flashing a "bad" canary version of magisk was enough to kill the fingerprint sensor. Of course I didn't learn any of this until it was too late.
MSM will get your phone back to life but not fully heal it. Basically all the MSM is guaranteed to do is get the phone to boot. No sensors, no fingerprint, no Widevine L1, no IMEI and wifi Mac address fix (if one is really screwed). And 1+ didn't take any measures to protect the sensitive partitions once bootloader is unlocked. It's all just a clusterf**k
Same issues on 7T and 8 and 8pro if that makes you feel any better ¯\_(ツ)_/¯
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
Yeah, system, vendor, product, and odm are stored in super.img on Android 10. But u found it. Find out what slot you are on, running 10.0.35, and you'd want the _a or _b files that match your current slot.
ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?
starcms said:
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?
Click to expand...
Click to collapse
Doesn't look really interesting to me, but here's the ls output.
Code:
OnePlus7TProNR:/sdcard/img # ls -l /odm
total 20
drwxr-xr-x 4 root root 4096 2008-12-31 17:00 etc
drwx------ 2 root root 16384 2008-12-31 17:00 lost+found
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc
total 12
-rw------- 1 root root 2735 2008-12-31 17:00 build.prop
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_dirs
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_files
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 selinux
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 vintf
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/selinux/
total 728
-rw-r--r-- 1 root root 733547 2008-12-31 17:00 precompiled_sepolicy
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.plat_sepolicy_and_mapping.sha256
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.product_sepolicy_and_mapping.sha256
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/vintf/
total 16
-rw-r--r-- 1 root root 5300 2008-12-31 17:00 manifest.xml
-rw-r--r-- 1 root root 1369 2008-12-31 17:00 manifest_ese.xml
-rw-r--r-- 1 root root 622 2008-12-31 17:00 manifest_noese.xml
I can try, but my upstream sucks. It might be faster for someone else to grab them.
-rw-r--r-- 1 travis travis 816K Jun 4 15:40 img/odm-verity.img
-rw-r--r-- 1 travis travis 1.3G Jun 4 15:41 img/product-verity.img
-rw-r--r-- 1 travis travis 2.2G Jun 4 15:40 img/system_root-verity.img
-rw-r--r-- 1 travis travis 884M Jun 4 15:43 img/vendor-verity.img
After looking through some logs, you can ignore most of that.
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.
Thanks for all of your time @ttabbal. Sorry if I'm driving you crazy Been driving myself crazy trying to fix this for 2 weeks now lol
My /odm seems to be fine. Matches yours. I was mainly concerned about those 2 files with 0 size. But I don't have any of the -verity.imgs from /dev/block/mapper. I'm pretty sure they are supposed to be created and mounted at boot (from super.img and by verity/vbmeta). I'm hoping those 2 vbmeta partitions will fix things up. If not, then I'll try keystore and keymaster. And then I'll have to send it in...
Edit:. Just curious, I'm assuming you are bootloader unlocked and running Magisk? Just confirming since you have those -verity.imgs
ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.
ttabbal said:
ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.
Click to expand...
Click to collapse
Well, not exactly lol.
Flashed your two images via fastboot, still broken fingerprint and still missing -verity files from /dev/block/mapper/ , went to flash my backups of vbmeta and vbmeta_system via fastboot, got into a bootloop, and after a couple hours of screwing with it, finally got back where I started from...except using your images.
I don't understand. vbmeta and vbmeta_system are NOT device specific. One from my phone, one from your phone, one from anyone's phone running 10.0.35 should be exactly the same.
What exact method did you use to pull the images? dd to a tmp dir on device and then adb pull img? dd directly to computer? or adb pull the partitions themselves direct to computer? Shouldn't all 3 methods return the same results?
I swear, after the RMA I really don't know if I am going to risk unlocking the bootloader again (this is coming from someone who has had s-off/bootloader unlock/root/su/Magisk on every single android device ever owned over the past 10 years...without ever having any problem I couldn't fix by myself)
It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.
ttabbal said:
It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.
Click to expand...
Click to collapse
What is the need or result of the "bs=1M" in the command? I've never seen that before in other threads. I'm assuming it means block size equal to 1MB. Is that definitely required to get a good pull? Same bs for any/all partitions?
If you have persist and both EFS images backed up, you should be okay. The MSM tool can restore I think everything else. I'd keep a backup especially of any partitions that don't end in _a or _b. The MSM tool definitely takes care of the rest (those ending in _a and _b). I just hate using it because there's no way to make it not wipe userdata. And without being able to make a nandroid backup due to no fully working twrp due to A10, it's just a giant pain.
And unfortunately we can't just OTA our way to the latest, at least not by manually downloading an OTA from 1+. Only way to update is with a real OTA update from T-Mobile.
The A/B partitioning isn't the problem with development. That's been around since Android 7 or 8. It's the new dynamic partitioning format that all phones that launch with Android 10 (or newer) have. Even the Pixel 4 doesn't have fully working twrp yet. It's coming soon though...
Edit: Also, for the dd commands, did you use /dev/block/actual_partition or /dev/block/by-name/friendly_name_of_partition? Again, should it really make a difference?
Edit2: All of these issues have a root cause from Android 10. The new required partitioning system for any phones that launch with it. That's why unlocking the bootloader wipes reserve.img. Because it's in userdata (cause of A10) and 1+ forgot about that and didn't rewrite the algorithm used when the bootloader is unlocked. It's also their negligence (combined with A10) which causes persist (and other key partitions) to become so easily corrupted. Virtually all devices launched since Android 7 use "fastboot flashing unlock" and then "fastboot flashing unlock_critical" to allow changes to device specific partitions. For some reason 1+ still is using the antiquated "fastboot oem unlock" command which unlocks literally everything, even some stuff that unlock_critical doesn't, and which in the old days, didn't matter. A10 especially should not ever be used with fastboot oem unlock. Google says so lol.
If it makes you feel better, this isn't unique to this phone. It's a problem on every device 1+ has launched with A10 and still is (OP7T/TPro/OP8/Pro). Because of A10 partitioning combined with the use of an antiquated bootloader that only supports "fastboot oem unlock"
The block size doesn't matter for the pull and doesn't change the image at all. It just reads in chunks, making it faster.
Yes, I used by-name and it shouldn't matter if you use that or the sd# names.
It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.
LLStarks said:
It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.
Click to expand...
Click to collapse
The issue is I had a backup of my unique persist. And restoring it doesn't fix the dang fingerprint. That's why I was thinking the issue had to be elsewhere