Related
Hi,
Here a release of kboot.
Kboot permit to boot multiple os with different kernel.
It's based on a buildroot environment.
The source to make your own kboot filesystem are available here
The kernel source are available here
You can download the install archive :
ARCHIVE VERSIONS
0.0. Unstable release. Freeze bug. Install release ARCHIVE (Obsolete)
0.1. Fix freeze. Python bytecode generation (pyc files) is naturally not friend with squashfs. Install release ARCHIVE (Obsolete)
0.2. STABLE Release. Display timeout, migration from squashfs to initramfs. Install release ARCHIVE
The archive looks like :
zImage and initramfs.cpio.gz to flash in SDE menu
a directory kboot which contain:
conf directory : configuration file
os directory : os to boot
images directory : background menu image
Installation
Kboot directory
Copy the kboot directory on your archos in /mnt/storage/, you should have this path /mnt/storage/kboot. The path should be exactly the same otherwise kboot will not be launched
Flash zImage and initramfs.cpio.gz
Follow this link to setup SDE on your archos http://forum.xda-developers.com/showthread.php?t=930197
After Reboot
You should have the following screen. Note: after installing Kboot the device permanently reboot in Kboot.
The main menu will display the os put in os directory (see in Configuration OS boot menu to see how to include your os), advanced menu and halt.
Boot menu
OS boot menu
I have tried to make things simple. To add an OS, all you need is to create a directory in /mnt/storage/kboot/os/ and put in this newly created directory the files zImage and initramfs.cpio.gz.
Important, the name should be exactly zImage and initramfs.cpio.gz, if one file is missing or misnamed the menu item don't appear
For example, the menu above have the following content in /mnt/storage/kboot/os :
Code:
/mnt/storage/kboot/os/Android Froyo:
drwxrwxrwx 2 2000 2000 4096 Feb 27 23:42 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 726520 Feb 27 23:39 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2564460 Feb 27 23:39 zImage
/mnt/storage/kboot/os/Android Honeycomb:
drwxrwxrwx 2 2000 2000 4096 Feb 27 16:46 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 zImage
/mnt/storage/kboot/os/UrukDroid 1.6:
drwxrwxrwx 2 2000 2000 4096 Feb 28 15:03 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 2874800 Jan 3 19:41 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2302252 Jan 3 19:26 zImage
Note : for specific kernel you can add a file named cmdline containing kernel parameters
Advanced boot menu
Boot init : boot into android, if android kernel was uninstalled, this item didn't appear
Boot recovery : boot into recovery
Soft boot : For details about omap soft reboot see the discussion here
Configuration
There is a configuration file in kboot/conf directory named config.ini. This file is divided into 3 section
init
telnet : 1 to enable telnet, 0 to disable
usbip : set the ip address of usb ethernet interface
Code:
[init]
telnet = 1
usbip = 192.168.10.1
kboot
last_selection : enable (1) or disable (0) the boot by default of the last selectioned entry after a configured timeout
last_selection_timeout : timeout in second
softboot : enable or disable softboot menu
title_font_size : set the title font size
menu_font_size : set the menu font size
title_color : title color in r,g,b format
menu_item_color : menu unselected color in r,g,b format
menu_item_selected_color : menu selected color in r,g,b format
Code:
[kboot]
# boot last selection if no key pressed after 30 seconds
last_selection = 1
last_selection_timeout = 30
# enable soft boot menu (bootloader dev only)
softboot = 1
# some tuning
title_font_size = 36
menu_font_size = 32
# change the color, R,G,B format
title_color = 255,255,255
menu_item_color = 92,97,98
menu_item_selected_color = 0,0,255
softboot
item<n> : the boot sequence wanted
Code:
[softboot]
# put a list of items to display in Soft boot menu
# item<n> = sequence
item1 = uart,usb,mmc1,mmc2
item2 = uart,usb
item3 = mmc1,mmc2
background image
To customize the background image, just replace the file kboot/images/bkg.png with your own and adapt if necessary the size and the font color.
BUGS
Feedbacks are welcome
Cool stuff bro!
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
It seems to be good.I have tested it on my A101 and it can boot both openaos and urukdroid.
Thanks.
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
fzelle said:
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
Click to expand...
Click to collapse
As an early release I didn't take the time to put the different resolution. The background image have a 1500x1200 resolution, so on 101 it didn't display right too. However kboot adapt resolution for corresponding board. kboot didn't boot on 70s or display wrong the background image ?
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to test urukdroid on mine.
The menu is not readable because the resolution adaption is not doing what it should do.
fzelle said:
The menu is not readable because the resolution adaption is not doing what it should do.
Click to expand...
Click to collapse
I have uploaded a new archive here.
Replace rootfs.squashfs with the new one. Fixed : resolution was wrong for 70S and 70H*.
The zImage in new archive should be flashed, it seems to fix the random freeze.
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to say sorry again that Kboot can boot Urukdroid properly.It was because I copied my backup file to my archos by using MY PC.That is why I cannot boot urukdroid.Maybe I didn't find the real cause. I'm now using Kboot to boot Urukdroid and Openaos.
Really very well!!
Sorry For My Bad English
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
fzelle said:
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
Click to expand...
Click to collapse
. Kernel natively support usb gadget ethernet, when kboot is launched a telnetd is started, an interface usb0 is configured with ip address 192.168.10.1.
if you are on linux it should automatically detect this and on your pc an ifconfig let appear usb0 interface. On your pc type :
Code:
ifconfig usb0 192.168.10.2 netmask 255.255.255.0 up
telnet -l root 192.168.10.1
.
If you can paste a ps output, to see if it detect you board correctly.
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
fzelle said:
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
Click to expand...
Click to collapse
Its fixed now . Replace rootfs by this one
alephzain said:
Its fixed now . Replace rootfs by this one
Click to expand...
Click to collapse
Please adapt the first post also so that future users have the correct files.
Maybe add a version number....
---------- Post added at 04:27 PM ---------- Previous post was at 04:12 PM ----------
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
fzelle said:
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
Click to expand...
Click to collapse
Not really possible because the stock firmware (initramfs) always uses the same location for the root file system.
You could do it but it needs some changes to the initramfs that is placed in the dirs.
wdl1908 said:
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Click to expand...
Click to collapse
Files on first post have been updated, but you're right a better presentation to avoid confusion is necessary.
Simply because I use python (pygame which use sdl) to code Kboot. Python lib dir is about 13M ... . A minimal filesystem (compressed initramfs) for kboot work is about 8M + ~2M for the kernel give 10M, and it's too big to flash in SDE max 8M. But if i can optimize the size ... I will do
alephzain thanks for the sources on gitorious, I hope I have some time in the weekend to try it out
divx118
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Hi,
im just about testing...
But sadly I can't get it to work.
Each time the menu starts up i can navigate nicely though the menues.
But whenever I select an entry - noting happens
After that I can still navigate ONCE (up or down) to the next entry and then the device freezes.
It doesn't matter wich entry i select as it seems. I tested Boot init, and my custom entries (UrukDroid and BullRC) yet. But all behave the same.
Any ideas ?
Btw: I tested it with the acutal squashfs and the one packed in the zip (even they seemed to be the same in size)
EDIT:
SOLUTION: I had usb cable attached (since flash) and that made it freeze - juts removed the cable and all is fine
Thanks and gr8 work - was looking for this since ages
fzelle said:
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Click to expand...
Click to collapse
Yes, no problem.
Ran into this off Reddit. Includes instructions. Thought people might be interested. Damn impressive.
http://thomaspolasek.blogspot.ca/2012/04/arch-linux-lxde-w-xorg-mouse-keyboard_16.html
Looks like I got something to do after getting through this current barrage of Uni assignments
Oh, that is impressive. Something I'll have to try, for sure.
umm...yeah...i'm gonna try this out for sure
\O/
Sent from my NookColor using XDA
So, how does it work??????
Okay, I'd like to report that it works... pretty well!
I started with PengDroid, so I got Debian instead of Arch. Then installed:
Code:
xinit xserver-xorg-core xserver-xorg-video-fbdev xserver-xorg-input-mtrack lxde
I also don't have a spare USB keyboard and mouse, so I decided to skip the keyboard and try to use the touchscreen as a pointing device. So here's my /etc/X11/xorg.conf:
Code:
Section "ServerLayout"
Identifier "Layout0"
InputDevice "Mouse0" "CorePointer"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mtrack"
Option "Device" "/dev/input/event2"
EndSection
Section "Device"
Identifier "Adapter0"
Driver "fbdev"
Option "fbdev" "/dev/graphics/fb0"
EndSection
As you can see, I'm using the mtrack driver, which makes the screen behave as a giant trackpad (with two-point touch = right-click). I have not been successful in getting proper touchscreen support working with evdev, but I suspect it might require the mtev driver.
Anyway, to start this thing off via adb:
Code:
ln -s Xorg /usr/bin/X
setprop ctl.stop media
setprop ctl.stop zygote
killall bootanimation
xinit /usr/bin/lxsession
... and to go back to Android,
Code:
^C
setprop ctl.start zygote
@bassrebel: Do you want technical details... or an answer involving unicorns?
Thats awesome that the touchscreen does work though. How about sound? I use my nook as my car stereo and would like to see if linux has any better audio drivers than android... also, xmbc on nook in a car would be awesome!
I haven't tried getting sound output, but I know it'd require getting ALSA/OSS set up with something like PulseAudio.
inportb said:
Okay, I'd like to report that it works... pretty well!
I started with PengDroid, so I got Debian instead of Arch. Then installed:
Code:
xinit xserver-xorg-core xserver-xorg-video-fbdev xserver-xorg-input-mtrack lxde
I also don't have a spare USB keyboard and mouse, so I decided to skip the keyboard and try to use the touchscreen as a pointing device. So here's my /etc/X11/xorg.conf:
Code:
Section "ServerLayout"
Identifier "Layout0"
InputDevice "Mouse0" "CorePointer"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mtrack"
Option "Device" "/dev/input/event2"
EndSection
Section "Device"
Identifier "Adapter0"
Driver "fbdev"
Option "fbdev" "/dev/graphics/fb0"
EndSection
As you can see, I'm using the mtrack driver, which makes the screen behave as a giant trackpad (with two-point touch = right-click). I have not been successful in getting proper touchscreen support working with evdev, but I suspect it might require the mtev driver.
Anyway, to start this thing off via adb:
Code:
ln -s Xorg /usr/bin/X
setprop ctl.stop media
setprop ctl.stop zygote
killall bootanimation
xinit /usr/bin/lxsession
... and to go back to Android,
Code:
^C
setprop ctl.start zygote
@bassrebel: Do you want technical details... or an answer involving unicorns?
Click to expand...
Click to collapse
I prefer the unicorns method!
racks11479 said:
I prefer the unicorns method!
Click to expand...
Click to collapse
+1 for unicorns.
I got to the part where I try to install the mtrack driver but I get:
Code:
E: Unable to locate package xserver-xorg-input-mtrack
EDIT:
I was able to get it running but since no mtrack driver no input so I just restarted. I'm so close, I tried adding repositories to apt and updating but still stuck.
Hi I hope anybody will read this. I really try to get this work but after pacman -Syu I get this error output:
Code:
"[[email protected] /]# pacman -Syu
:: Synchronizing package databases...
core 38.8 KiB 53.8K/s 00:01 [######################] 100%
extra 428.5 KiB 286K/s 00:01 [######################] 100%
community 421.6 KiB 450K/s 00:01 [######################] 100%
alarm 6.0 KiB 5.20M/s 00:00 [######################] 100%
aur 11.7 KiB 1964K/s 00:00 [######################] 100%
:: The following packages should be upgraded first :
pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n] y
resolving dependencies...
looking for inter-conflicts...
Targets (1): pacman-4.0.3-3
Total Download Size: 1.00 MiB
Total Installed Size: 3.38 MiB
Net Upgrade Size: 0.00 MiB
Proceed with installation? [Y/n] y
:: Retrieving packages from core...
pacman-4.0.3-3-armv7h 1019.7 KiB 262K/s 00:04 [######################] 100%
(1/1) checking package integrity [######################] 100%
(1/1) loading package files [######################] 100%
(1/1) checking for file conflicts [######################] 100%
warning: could not get filesystem information for /mnt/asec: No such file or directory
warning: could not get filesystem information for /mnt/obb: No such file or directory
warning: could not get filesystem information for /rom: No such file or directory
warning: could not get filesystem information for /system: No such file or directory
warning: could not get filesystem information for /data: No such file or directory
warning: could not get filesystem information for /cache: No such file or directory
warning: could not get filesystem information for /mnt/sdcard: No such file or directory
warning: could not get filesystem information for /mnt/secure/asec: No such file or directory
warning: could not get filesystem information for /mnt/sdcard/.android_secure: No such file or directory
warning: could not get filesystem information for /mnt/emmc: No such file or directory
warning: could not get filesystem information for /data/pengdroid: No such file or directory
(1/1) checking available disk space [######################] 100%
error: Partition / is mounted read only
error: not enough free disk space
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded."
I think I unterstand the problem but how can I fix it.
I had that problem too when I tried to get this running. I ended up searching the problem and had to change a configuration file. I dont really think this linux is worth it to try yet. If only the touchscreen worked though.
Hey folks, thanks to @iElvis sharing his or her logo 'data' from the OP6. I have adapted my previous OnePlus programs that let you change the splash screen to work with the OP6. This means that the encoding of the data structure and the encoding of the image data are done. I do not have a OP6 and can not test certain things like where to put the modified file. In the past, flashing was always easy (and always has been especially with the OnePlus models).
My holdup and why I need the XDA/OP6 community support is to find out where to exactly put this modified file. In the past I haphazardly made a super fast in-memory program for altering the splash screen for the Nexus 6p that was (and is currently) at a roadblock for one reason. That reason was Google used ELFs to populate partitions (not short people with pointy ears and green clothing), and at that time utilized separate partitions that the ELFs populate. Not all were ELF generated, but that is outside of the scope of what I do because to a certain point the ones that I wanted to change were generated that way.
This concept of splitting partitions, back then, was just trying to grab a footing on seamless upgrades initially from what I have read up until this newer style. I have put some research into some things involving this, but Google is kind of bland in it's description of what this all means. This is different than the Nexus 6P that I mentioned previously, and if you read that last link, it may be just as easy as flashing it to both partitions logo_a & logo_b. One partition is always active and has two different statuses, which make the device 'ideally' always bootable after an OS update.
Most of my research was done through reading a lot of the open source code put out by the AOSP for "fastboot". You can learn more than you can ever derive from documentation in this realm. I hope to hear some feedback of attempts so that I can delete all of this up above
Please read below so you can better understand this type of encoding being used:
What Is A Raw Image?
A raw image, whether it be a file or an image in memory, is simply pixel data. There is no extra information like width, height, name, end of line... Absolutely nothing, just pixel data. If you have an image that is raw and the resolution is 1080x1920 and you are using a typical RGB24 or BGR24 (like the ones used here), then your exact filesize or size in memory will be 1080x1920x3! We use 3 here because there is one byte for the R or red component, one for the G (green), and one for the B(blue).
What Is A Run Length Encoded Image?
A run length image encoding uses a count ;usually a single byte (char), 2 bytes (short int), or 4 bytes (long int); and then the pixel components. So instead of writing out 300 bytes of '0's to make a line of 100 black pixels. Black is RGB(0,0,0). You could encode this as 100, 0, 0, 0. And only use 4 bytes of data to get the exact same image as the 300 byte raw image. All the run length encoding I've found, except the Motorola style which is a little different, use a run length encoding that is pixel-oriented like this.
Now I've found this new one and it is a byte-oriented run length encoding. This is for runs of bytes, not pixels. You may think, well whats the big deal? When you add a little area of color, you increase the run length encoded image in you logo.bin immensely! You use 6 bytes per pixel if there aren't any runs of color data. If you had an image that was a 1080x1920 black image with a 25 pixel horizontal line in the middle. The encoder would be doing runs of black data efficiently until it reached the red area.
.....0 255 0 255 0 255 0 255 0 255 0 133 /// we've reached the top left corner of the red line /// 13 1 30 1 255 1 // << that was just one red pixel!! in bgr color order (13, 30, 255) <<// And it keeps going through the rest of the red pixels on that line using 6 bytes per pixel, which is the opposite of compression. Before reaching the red line the encoding was decoding to 255 zeros over and over, until finally 133 zeros. 255 zeros is 85 black pixels stored in just 2 bytes!
This type of encoding is ONLY good for grey scale images. It is not good with color, but it still will handle color of course. In grey scale, the Red, Blue, and Green data components are always the same values. All the way from black (0,0,0) to white (255, 255, 255); including every shade of grey in between>>>(1,1,1) (2,2,2) (3,3,3)....(243, 243, 243) (254, 254, 254)<<<
One other difference in this method of run length encoding is that the color byte is before the count, which is backwards from all of the other methods.
The attachment contains the executable that was compiled using mingw32 on a 64 bit Windows 10 PC. The awesome PNG library that I used for generating the pngs is LodePng, the source can be found here.
To use the OnePlus 6 Logo Injector:
Decode your logo.bin:
Code:
OP6Logo -i logo.bin -d
All the PNG 's will be extracted from logo.bin. Edit the PNG(s) that you want to change...
Note:
Your original "logo.bin" file is never changed, it is just read. If the file you try to load isn't a logo file, or a different style, then the program will tell you and exit.
Inject the image(s) back in to the logo.bin:
Code:
OP6Logo -i logo.bin -j fhd_oppo fhd_at
To list whats in your logo file:
Code:
OP6Logo -i logo.bin -l
For a more detailed list:
Code:
OP6Logo -i logo.bin -L
If the colors are messed up use the "-s" switch while decoding.
Code:
OP6tLogo -i logo.bin -d -s
If you had to use the "-s" switch to decode properly, you'll have to use it to inject also:
Code:
OP6Logo -i logo.bin -j image_name -s
Note:
You can put as many names after "-j" as you want, and it's not case sensitive. You also don't have to put the whole name. If you just put "-j fhd" every image in the logo.bin that starts with "fhd" will be injected. There has to be a PNG with the name in the directory though
The size of your modified.logo.bin will displayed along with the original size, if everything went good. The 'splash' partition is 16 MB on the OP6. If you use too much color on too many of the images you will easily go over 16 MB. The program will tell you and delete the "modified.logo.bin" that was created. If for some strange reason you would like to keep it, use the "-B" flag on the command.
The last step is to flash the modified logo file via fastboot with the command
Code:
fastboot flash LOGO modified.logo.bin
Use this at your own risk.
Always make backups.
Always.
Source
Source:
I haven't had a chance to work up a custom splash and flash it just yet, in part because I realized that on this phone, the splash screen only shows up for a split second before it's replaced by the "Your phone is unlocked and insecure, don't put sensitive files on it blah blah" warning. So I'm not sure this is going to do a whole lot for us. I'm going to try later tonight or this weekend and report back. Pretty sure "flash logo" should work fine, but it will flash only to the active partition. We may need to "flash logo_a" and "flash logo_b" to get it on both partitions.
Also, thanks for posting the source. I'm going to see if I can get this to compile in Xcode so we have an OSX version.
Edit 6/10: I can't get it to compile in Xcode, but I'm sure it's something I'm doing wrong.
Anyone tested it splash screen
Okay, welp, I'm throwing in the towel on this one. The bootloader warning is not in text like it was on the HTC phones I've modded to remove it. On those phones, the text showed up in the bootloader file in a hex editor, and could be replaced with empty spaces to remove it.
I pulled the boot file from /dev/block/bootdevice/by-name/ and searched through it. None of the text in the warning can be found with a simple search. As I suspected, that warning screen looks like it's a function coded into the boot process, which means removing it is probably impossible.
work Fine !
file :
lodepng.h
lodepng.c
OP6Logo.c
# gcc lodepng.c -c
# gcc OP6Logo.c -c
# gcc *.o -o OP6_prog OR # gcc lodepng.o OP6Logo.o -o OP6_prog
# ./adb shell
# su
# cd /dev/block/bootdevice/by-name
# ls --color --all
lrwxrwxrwx 1 root root 16 1970-01-06 04:29:20.549999999 +0100 LOGO_a -> /dev/block/sde20
# dd if=LOGO_a of=/sdcard/LOGO_a
exit
# ./adb pull /sdcar/LOGO_a ./
# OP6_prog -i LOGO_a -d
MODIFY YOUR PICTURE .....
# ./OP6logo -i LOGO_a -j fhd_
you have modified.logo.bin
Just dd if of and work fine !
And for the Real Splash :
./adb pull /system/media/bootanimation.zip ../
God bless
gao0309 said:
file :
lodepng.h
lodepng.c
OP6Logo.c
# gcc lodepng.c -c
# gcc OP6Logo.c -c
# gcc *.o -o OP6_prog OR # gcc lodepng.o OP6Logo.o -o OP6_prog
# ./adb shell
# su
# cd /dev/block/bootdevice/by-name
# ls --color --all
lrwxrwxrwx 1 root root 16 1970-01-06 04:29:20.549999999 +0100 LOGO_a -> /dev/block/sde20
# dd if=LOGO_a of=/sdcard/LOGO_a
exit
# ./adb pull /sdcar/LOGO_a ./
# OP6_prog -i LOGO_a -d
MODIFY YOUR PICTURE .....
# ./OP6logo -i LOGO_a -j fhd_
you have modified.logo.bin
Just dd if of and work fine !
And for the Real Splash :
./adb pull /system/media/bootanimation.zip ../
God bless
Click to expand...
Click to collapse
Way to remove bootloader unlocked warning?
NO
Please create flashable zip. Of splash screen
I'm trying this on linux on a 6T boot splash screen but I get a segmentation fault:
Code:
__________________________________________________________-_-
OP6 Logo Injector v1
Written By Makers_Mark @ XDA-DEVELOPERS.COM
_____________________________________________________________
FILE: logo.bin
_____________________________________________________________
RGB is the color order. Use "-s" switch to change it to BGR.
#01: Offset:0
Header=SPLASH!!
Width=1080
Height=1920
Data Length=81798
Special=1
Name=
Metadata=
Segmentation fault
Any idea why?
foobar66 said:
I'm trying this on linux on a 6T boot splash screen but I get a segmentation fault:
Any idea why?
Click to expand...
Click to collapse
For 6T, maybe you need look at this thread
https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158
Sent from my ONEPLUS A6000 using XDA Labs
I tried to report that the error memory could not be read under Windows 10 and wimdows7. Then I executed the following instructions under Linux and still reported the error. What can I do, oneplus 6, Android 9.0?
gcc lodepng.c -c
gcc OP6Logo.c -c
gcc *.o -o a.out
./a.out -i logo.bin -d
The following are the results of implementation：
__________________________________________________________-_-
OP6 Logo Injector v1
Written By Makers_Mark @ XDA-DEVELOPERS.COM _____________________________________________________________
FILE: logo.bin _____________________________________________________________
BGR is the color order. Use "-s" switch to change it to RGB.
#01: Offset:0
Header=SPLASH!!
Width=1080
Height=1920
Data Length=77716
Special=1
Name=
Metadata=
Segmentation fault
Code:
C:\Users\denie\Documents\logo>OP6Logo -i logo.bin -d
__________________________________________________________-_-
OP6 Logo Injector v1
Written By Makers_Mark @ XDA-DEVELOPERS.COM
_____________________________________________________________
FILE: logo.bin
_____________________________________________________________
BGR is the color order. Use "-s" switch to change it to RGB.
#01: Offset:0
Header=SPLASH!!
Width=1080
Height=1920
Data Length=81798
Special=1
Name=
Metadata=
C:\Users\denie\Documents\logo>
Any ideas?
Does this work?
Prakyy said:
Does this work?
Click to expand...
Click to collapse
There's no way to hide the Google warning about unlocked bootloaders, if that's what you mean.
iElvis said:
There's no way to hide the Google warning about unlocked bootloaders, if that's what you mean.
Click to expand...
Click to collapse
Really... This is what I've been searching all over for for my 6t... Get rid of the stupid bootloader unlock warning. On all my other devices we always used a custom made boot-logo.bin and installed it on slot a and slot b using fastboot.. I guess if it could be covered up it definitely would have by now. ?
Edit added: I just read the thread. From what I've gathered basically this device (6&6t) is designed different and that's why we can't tamper with/cover up the bootloader warning message.
flash713 said:
Really... This is what I've been searching all over for for my 6t... Get rid of the stupid bootloader unlock warning. On all my other devices we always used a custom made boot-logo.bin and installed it on slot a and slot b using fastboot.. I guess if it could be covered up it definitely would have by now. ?
Edit added: I just read the thread. From what I've gathered basically this device (6&6t) is designed different and that's why we can't tamper with/cover up the bootloader warning message.
Click to expand...
Click to collapse
I gave up after a lot of experimenting. I'm not aware of anyone managing it.
iElvis said:
I gave up after a lot of experimenting. I'm not aware of anyone managing it.
Click to expand...
Click to collapse
You should get an award for your XDA signature. ?? It's funny because it's real and oh so true! The way some people comment on things never ceases to blow me away. I see some posts and I think to myself, "what the hell?" "Who raised this person!?" There are definitely many different types of humans out there in the world that's a fact. I try and stay out of it as much as possible. ? lol.
It sucks we can't just make a ton of boot logos and cover that up. Oh well the 6 & 6t are awesome devices!! Usually whenever I end up on down the road selling my phone and purchasing another one from eBay or swappa things similar to this begin to be solved and then 15 custom roms all drop outa nowhere all at once. ? Happens every...single...time...haha!! Thanks for giving it a shot! :good:
Hello,
I have problem with my Lenovo P1m. After changing unresponsive screen with aftermarket one, phone is not booting. To be explicitly specific, phone is booting OEM ROM correctly, but I was using custom ROM of LineageOS 14.1 before screen replacement and now it is not working. My problem is - I can compile my own kernel with different screen drivers / options / etc as I am familiar with linux kernel itself, BUT - how do I debug bootloop, when the only thing I can dig from phone via TWRP recovery is following line from /proc/last_kmsg which, honestly, tells me nothing
Code:
ram console header, hw_status: 2, fiq step 0.
(previously, I got some error message about wrong kernel header as I was trying to compile kernel myself, but this is solved now - but no luck with bootloop either)
Scenario is like this: after power on, I have vibration and normal white Android screen, which if normal boot, is followed by animation and OS welcome. But now, the screen after is black, and after few seconds everything starts from begining - vibration, white android screen etc...
I cannot use adb at all, as it is not catching the phone in this situation, probably kernel is failing before adbd itself starts. I am using TWRP to extract /proc/last_kmsg but as mentioned before, no usable information.
Is there any other way to get kernel messages from boot process? (It would be besto to have something like dmesg output)
So, I see that nobody knows or wants to help, so I helped myself. Made cable as seen here: h t t p: // w w w .stevenhoneyman.co.uk/2014/11/mtk-mediatek-debug-cable.html
And now I at least have serial console. BUT - all output ends exactly when kernel is loaded. Any ideas how to get verbose output from kernel to uart? I tried to add printk.disable_uart=0 ignore_loglevel into commandline arguments for kernel, but no luck.
End of console output looks like:
Code:
[5940] [PROFILE] ------- boot_time takes 3053 ms --------
[LK_ENV]get_env hibboot
[LK_ENV]get_env resume
[5940] booting linux @ 0x40080000, ramdisk @ 0x44000000 (1611013)
[5940] [LEDS]LK: leds_deinit: LEDS off
[5940] [LEDS]LK: red level is 0
[5940] [LEDS]LK: green level is 0
[5940] [LEDS]LK: PMIC Type: 7, Level: 0
[5940] [LEDS]LK: blue level is 0
[5940] DRAM Rank :2
[5940] DRAM Rank[0] Start = 0x40000000, Size = 0x40000000
[5940] DRAM Rank[1] Start = 0x80000000, Size = 0x3ffc0000
[5940] cmdline: console=tty0 console=ttyMT0,921600n1 root=/dev/ram vmalloc=496M androidboot.hardware=mt6735 slub_max_order=0 slub_debug=O bootopt=64S3,32N2,64N2 androidboot.selinux=permissive buildvariant=userdebug printk.disable_uart=0 ignore_loglevel lcm=1-ili
[5940] lk boot time = 3053 ms
[5940] lk boot mode = 0
[5940] lk boot reason = wdt_by_pass_pwk
[5940] lk finished --> jump to linux kernel 64Bit
[5940]
[LK]jump to K64 0x40080000
[5940] smc jump
Key to get kernel boot output was finally in console on ttyMT1 instead of ttyMT0 (console=ttyMT1,921600n1)and also nousb parameter, so usb port will not switch to real usb during boot and remains uart. Now, I have found out that my kernel is missing some LCM driver, which was then re-compiled and now I have to find out what else is wrong...
Running out of ideas. Phone boots with old broken OEM display. If I connect new aftermarket display, it bootloops. Kernel logs attached for every case: old display, new display. Any ideas what goes wrong with new display?
NEW: https://pastebin.com/Ewz8FF5h
OLD: https://pastebin.com/CjtmA0aB
Code:
[ 14.143167] (0)[1:swapper/0][FTS] Step 1:Reset CTPM
[ 14.243788] (0)[1:swapper/0]hidi2c_to_stdi2c successful.
[ 14.263168] (0)[1:swapper/0][FTS] Step 2:Enter upgrade mode
[ 14.313857] (0)[1:swapper/0][FTS] Step 3: CTPM ID,ID1 = 0x0,ID2 = 0x0
[ 14.314917] (0)[1:swapper/0]ft5x0x 1-0070: [FTS] Step 3 fail: CTPM ID,ID1 = 0x0,ID2 = 0x0, 0x54, 0x2c:
[ 14.423169] (0)[1:swapper/0][FTS] Step 1:Reset CTPM
[ 14.473714] (0)[1:swapper/0]hidi2c_to_stdi2c successful.
[ 14.493166] (0)[1:swapper/0][FTS] Step 2:Enter upgrade mode
[ 14.543852] (0)[1:swapper/0][FTS] Step 3: CTPM ID,ID1 = 0x0,ID2 = 0x0
[ 14.544707] (0)[1:swapper/0]ft5x0x 1-0070: [FTS] Step 3 fail: CTPM ID,ID1 = 0x0,ID2 = 0x0, 0x54, 0x2c:
[ 14.653167] (0)[1:swapper/0][FTS] Step 1:Reset CTPM
THIS is the reason of problems. When I deconfigure FT5446 driver from kernel, system boots without problems. Only thing is that touchscreen is inoperative because of disabled driver. How to debug this issue?
I have resolved this issue for me. Hardcode-edited driver for FT5446 IC touchscreen to workaround firmware upgrade checking. Now I have operational P1m with aftermarket display under LOS 14.1 on 3.18.19 kernel. If anybody interested, here is boot.img for darklords LOS14.1 ROM lineage-14.1-20171119_095733-UNOFFICIAL-P1m.zip but I think it will work also for his other versions
https://uloz.to/!cuEWkiCv9flq/boot-img
can you share the changes you made to the kernel source
i have compared some changes that you shared , they can be seen in here
Hi guys, I am asking you some help due to an emergency.
I had to downgrade an Android 10 rom where I had encryption turnen on (rom).
All I did was flashing a previous (minor) version of the rom via TWRP with just a "wipe cache/dalvik".
After rebooting my pin was not recognized anymore by both Android and TWRP.
I did many tentatives and at some point I typed "default_password" as pin, when asked by Android during the boot, and there was a important change:
1. After rebooting I typed my old pin, and now Android always tells me: "The password you entered is correct, but unfortunately your data is corrupt".
2. Now when TWRP asks for the password, it accepts the old pin too. But it is "unable to mount storage".
3. The system partition's contents are now visible: before they were not showing at all. The data partition is not accessible (error decrypting…).
I have done a lot of studying and tentatives to get the phone working without formatting and losing the data, but I could not solve the issue. I don't think the data is actually corrupted, because the rom downgrade was a minor version and it did not modify anything about encryption.
Could you please point me to the right direction? I am trying to understand what could have gone wrong, and find some possible solution.
EDIT: more details and list of the attempted solutions in this post: https://forum.xda-developers.com/t/...sue-after-rom-downgrade.4168821/post-85210619
JackSlaterIV said:
After rebooting I typed my old pin, and now Android always tells me: "The password you entered is correct, but unfortunately your data is corrupt".
Click to expand...
Click to collapse
Look inside here.
jwoegerbauer said:
Look inside here.
Click to expand...
Click to collapse
Both methods cause /data to be erased, which is what I don't want. Thanks anyway.
guess if something has changed since your dirty flash, it must be something in last 16384 bytes where the crypto footer is
there are some bytes which are most likely one or eight flag(s)
Flags : 0x00000000
you can locate and copy the crypto footer like this
- check fstab for location if it says encryptable=footer (or see recovery.log)
- get partition size and calculate the offset -16384
- extract the footer to /sdcard with dd (any file name)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
on PC open that file with Hex Editor
- the crypto footer will start with magic 0xD0B5B1C* (little endian). in my case it's C5 B1 B5 D0 as it's a samsung device.
- you should also see a string aes-cbc-essiv:sha256 (in my case aes-xts)
inspect the crypto footer with python script. you can't decrypt since android uses scrypt+keymaster but it will give you a nice layout
- install python 2.7
- run that script bruteforce_stdcrypto.py
Code:
Android FDE crypto footer
-------------------------
Magic : 0xD0B5B1C4
Major Version : 1
Minor Version : 3
Footer Size : 2352 bytes
Flags : 0x00001008
Key Size : 128 bits
Failed Decrypts : 36
Crypto Type : aes-xts
Encrypted Key : 0xCCE7D93B501B400D3D81726806F92936
Salt : 0x51B68B017C2A181E3ABD0B041FBFAA14
KDF : scrypt+keymaster
N_factor : 15 (N=32768)
r_factor : 3 (r=8)
p_factor : 1 (p=2)
crypt type : PIN
FS size : 52453304
encrypted upto : 52453304
-------------------------
as you can see in your case the flags are 0x00001008 so you can easier locate that in your Hex Editor
- convert the string little endian 0x00 00 10 08 -> 08 10 00 00
- you will find that four bytes at offset 13 in the first line
- reset the flags to 00 00 00 00 and save the file
if you prefer linux you can also use that shell script for doing that. fde_crypto.sh
Before messing up your data partition do a full dump for backup purposes (because we don't know what we are doing here, encryption is complicated stuff). In case you broke something you can just adb push it later
Code:
adb pull /dev/block/bootdevice/by-name/userdata
Now, write the new crypto footer back to end of userdata partition
- copy the file back to the device (another file name)
- get partition size and calculate the offset -16384
- write the footer to offset with dd (seek)
Code:
adb push data-footer.bin /sdcard
adb shell
cd /sdcard
blockdev --getsize /dev/block/bootdevice/by-name/userdata
dd bs=512 seek=$((52453336-32)) count=32 if=data-footer.bin of=/dev/block/bootdevice/by-name/userdata
Note: i don't know if that works. indeed, that's all guesswork based on your input in pm. good luck!
Hi and thanks again. As you wrote we spoke a lot via PM before your post.
I reset the footer flags to 00 00 00 00. Then used dd as you suggested to overwrite the userdata footer.
During the first Android boot, it asked me to enter the pin, but then it failed to decrypt, and now is always showing the old message "The password you entered is correct, but unfortunately your data is corrupt" .
So looks like the flag at least reset the default mode.
And TWRP still can't decrypt the partition.
It's no surprise because, as you showed me, the userdata partition may be corrupted.
I wanted to get the updated footer back from the phone to my PC. I used this:
dd bs=512 seek=$((52453336-32)) count=32 if=/dev/block/bootdevice/by-name/userdata of=/tmp/data-footer-new.bin
32+0 records in
32+0 records out
16384 bytes (16.0KB) copied, 0.009945 seconds, 1.6MB/s
Then Adb pull tmp/data-footer-new.bin
But it started downloading a few GB of data. I checked the size via ls -l:
-rw-rw-rw- 1 root root 26856108032 Dec 20 14:04 data-footer-new.bin
What I did wrong? Is it a bug?
usage problem - this is expected behavior for dd seek. when the output file is too small or doesn't exist, a zero padding is filled to create a big file before the offset starts, where it finally starts to write the real data (32 x 512 bytes)
you have mixed up parameters skip/seek, in your case copied first 16384 bytes from userdata into the end of a big file data.footer.bin
btw the userdata partition is not corrupt per se (or at least there is no proof i could show ever) you will never find ext4 file system magic 0xEF53 on encrypted userdata, only on dm-0 (if decrypted successfully). but true, mounting is a different case, indeed mount may fail even for successfully decrypted file system (like for Redmi 5). so the safest way to know if decrypted successfully is looking for zero paddings, first 1024 bytes will have enough of it...
you can try lot of other values for this flag (0x00001000 like for LG?) or try other (undiscovered) flags. you need a lot patient and time as you are the first one trying this. also reset the failed decrypts counter as this may important for gatekeeper timeout
i recommend to decrypt straight from twrp command line, should "work" without reboot
edit: i could even imagine automatizing that with script (10 sec/attempt - min timeout)
edit 2: interesting too would be binary (or checksum) compare of userdata before/after failed attempt (without footer) to figure out if changes happen elsewhere (other than footer)
even more interesting, you could factory reset and reproduce the mistake, make a snapshot before/after and bitwise compare where the changes happen
if the key itself has changed, there is no possible way to revert as the old key is lost
but decryption should still be possible on the newer android version, all you need is working twrp that fits
edit: factory reset is maybe not the best idea! turns out for FBE file-based-encryption the KEK is stored in TEE and depending on rollback resistance (not related to version binding) master key may deleted on factory reset. FBE is introduced with Android 7.1 - your device is still running good old FDE full-disk-encryption - but who knows what additional protections Android 10 enforces? can't guarantee that KEK is encrypted by hardware-backed RSA-2048 private key and screenlock credentials only and everything is stored in crypto footer only, although the documentation doesn't indicate contradictory
aIecxs said:
usage problem - this is expected behavior for dd seek. when the output file is too small or doesn't exist, a zero padding is filled to create a big file before the offset starts, where it finally starts to write the real data (32 x 512 bytes)
you have mixed up parameters skip/seek, in your case copied first 16384 bytes from userdata into the end of a big file data.footer.bin
Click to expand...
Click to collapse
Can you confirm this is the correct command to get the new footer?
dd bs=512 skip=$((52453336-32)) count=32 if=/dev/block/bootdevice/by-name/userdata of=/tmp/data-footer-new.bin
I think that this new big file may have caused some corruption.
I want to restore the userdata partition backup, but I read it's not easy as a simple adb push: https://android.stackexchange.com/q...n-image-of-android-partition-from-my-linux-pc
Can you tell me any reliable way to do this, apart using busybox as in the above replies?
btw the userdata partition is not corrupt per se (or at least there is no proof i could show ever) you will never find ext4 file system magic 0xEF53 on encrypted userdata, only on dm-0 (if decrypted successfully). but true, mounting is a different case, indeed mount may fail even for successfully decrypted file system (like for Redmi 5). so the safest way to know if decrypted successfully is looking for zero paddings, first 1024 bytes will have enough of it...
Click to expand...
Click to collapse
Thanks for clarifying this.
you can try lot of other values for this flag (0x00001000 like for LG?) or try other (undiscovered) flags. you need a lot patient and time as you are the first one trying this. also reset the failed decrypts counter as this may important for gatekeeper timeout
i recommend to decrypt straight from twrp command line, should "work" without reboot
edit: i could even imagine automatizing that with script (10 sec/attempt - min timeout)
edit 2: interesting too would be binary (or checksum) compare of userdata before/after failed attempt (without footer) to figure out if changes happen elsewhere (other than footer)
Click to expand...
Click to collapse
Indeed I had already tried 0x00001000 and resetting the counter, before the mess up with my dd command.
Do you know any other combination I could try?
Something I could try is see what happens to /userdata if I type default_password at the first boot.
yes, that is the right command
no, you didn't mess up with big file because of= is the only thing written (and /tmp is only in RAM)
yes, simple adb push is fine and works quite well for single partition. the link is talking about something different (whole eMMC including gpt and bootloader)
no, i have no clue about the flags. the source code might help but it's above my knowledge (yet)
found some explanation for flags
https://www.0xf8.org/2019/01/analyz...axy-s7-data-partition-with-samsung-encryption
have implemented the above link, not sure if i am doing it right but have a look into script fde_crypto.sh
Hello alecxs, thanks for your last messages. Sorry for this long delay.
I did not write any update because I couldn't find anything useful in the footer and the full data images. The phone is still not in use, in a drawer.
I had tried different flags, but after each tentative I had the same result. The "system" tells that data may be corrupted and updates the flag accordingly.
I had compared before vs after data images and did not find any difference. There is only one field in the footer that is modified after each tentative: the sha256 of the footer (offset 90c).
Without further information I cannot tell what causes this issue, if the data is corrupt or not. It would be useful having a more verbose mode in the mount command, so that it shows the reason of the failed mount. I guess it's not possible.
i think it is caused by rollback resistance and you should try higher android version (that one that messed up everything) with compatible TWRP. besides recovery.log you can check dmesg and logcat for additional information
Hi again,
I am attaching dmesg and recovery log, taken from TWRP after a failed mount of the data partition, using my pin, with the crypto footer flags reset to zero.
I could not find anything, so I hope someone reading this could give me a hint.
From what I can see, anti rollback and verified boot are disabled in Mi5 and in LineageOS based roms (see here).
Regarding TWRP I always used the same version recommended by the rom developer.
EDIT: file attachment not working for me...
See them here:
dmesg.log
Shared with Dropbox
www.dropbox.com
recovery.log
Shared with Dropbox
www.dropbox.com
looks like double encryption bug. try to dump content of dm-0 and restore it to userdata, that should at least eliminate the FDE encryption. second encryption is FBE? let binwalk analyze usually there is unencrypted area
aIecxs said:
... you should try higher android version [...]
Click to expand...
Click to collapse
just as a reference: for this you would find errors like
E vold : upgrade_key failed, code -38
E Cryptfs : Failed to upgrade key
which is not the case here.
(note: yes it says "upgrade" but in my example the installed key is from a higher version so actually a downgrade would be needed - which is not possible at all.)
(see a full example and details here and google details here)
JackSlaterIV said:
Hi again,
I am attaching dmesg and recovery log, taken from TWRP after a failed mount of the data partition, using my pin, with the crypto footer flags reset to zero.
I could not find anything, so I hope someone reading this could give me a hint.
From what I can see, anti rollback and verified boot are disabled in Mi5 and in LineageOS based roms (see here).
Regarding TWRP I always used the same version recommended by the rom developer.
EDIT: file attachment not working for me...
See them here:
dmesg.log
Shared with Dropbox
www.dropbox.com
recovery.log
Shared with Dropbox
www.dropbox.com
Click to expand...
Click to collapse
the interesting part is here:
Code:
<3>[ 5.880909] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -65,app_id = 0,lstr = 12288
<3>[ 6.007678] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -71,app_id = 0,lstr = 12288
<3>[ 6.007697] QSEECOM: __qseecom_set_clear_ce_key: process_incomplete_cmd FAILED, resp.result -71
<3>[ 6.007716] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.007726] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
<3>[ 6.098357] scm_call failed: func id 0x72000501, ret: -2, syscall returns: 0xffffffffffffffbf, 0x0, 0x0
<3>[ 6.225071] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -71,app_id = 0,lstr = 12288
<3>[ 6.225082] QSEECOM: __qseecom_set_clear_ce_key: process_incomplete_cmd FAILED, resp.result -71
<3>[ 6.225096] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.225104] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
the main error is likely:
Code:
<3>[ 5.880909] QSEECOM: __qseecom_process_incomplete_cmd: fail:resp res= -65,app_id = 0,lstr = 12288
[..]
<3>[ 6.007716] QSEECOM: qseecom_create_key: Failed to create key: pipe 2, ce 0: -22
<3>[ 6.007726] QSEECOM: qseecom_ioctl: failed to create encryption key: -22
-65 means: ATTESTATION_APPLICATION_ID_MISSING whatever that means actually.
aIecxs said:
looks like double encryption bug. try to dump content of dm-0 and restore it to userdata, that should at least eliminate the FDE encryption. second encryption is FBE? let binwalk analyze usually there is unencrypted area
Click to expand...
Click to collapse
interesting idea especially as it actually can decrypt /dev/dm0 according to the recovery.log but then failing to mount it.
I would +1 here and try if you can dump the content of /dev/dm0 after trying the decryption ( e.g. when you have an ext sdcard: `dd if=/dev/dm0 of=/external_sd/dump.img bs=4096` )
Other then that it might be an issue with your blobs - either in TWRP, or the device
i think your issue is bit different and the links provided are about FBE. afaik FDE does not hold keys in TEE (except for hardware-backed RSA-2048 private key which is not flushable) so i am not sure if upgradeKey affects crypto-footer but deleteKey is clearly some keystore thing
to eliminate issues with TWRP i would do decryption test on working block encryption (and maybe try OrangeFox) only then you can determine issues with faulty crypto-footer
Hello guys, thanks for your help.
I dumped both sda14 and dm-0 partitions (using adb dump).
The dm-0 ("decrypted" partition) is a smaller binary file (26.856.091.648 bytes) vs sda14 (26.856.108.032 bytes).
I compared these binary files using HxD and they look different. dm-0 does not contain the crypto footer section (the 16384 bytes difference).
I just installed binwalk for the suggested purpose, and started analyzing dm-0 (binwalk dm-0). It is outputting something and I don't have any idea of how much time it would take to complete the task.
Let's see if I can attach a screenshot..
okay not sure binwalk may just false detect random data or it may real files. anyway you can concatenate dm-0 with crypto-footer from userdata and check what TWRP says about this garbage then
aIecxs said:
okay not sure binwalk may just false detect random data or it may real files. anyway you can concatenate dm-0 with crypto-footer from userdata and check what TWRP says about this garbage then
Click to expand...
Click to collapse
Yes indeed.
I did not find any text in the dm-0 binary.
Can you suggest me how I concatenate these files? I have dm-0 and crypto-footer in separate files. EDIT: just by using HxD.
To overwrite the partition can I use "adb push dm-0-new /dev/block/sda14"?