Related
Hi devs,
Are you aware of any work (for other Android phones, for instance), where an altered mtd kernel driver was used to allow (raw) root access anyplace within flash memory? (For example, maybe a raw pseudo-partition which overlaps all the other partitions?) The stock mtd driver creates devices in the kernel device tree only for specific partition slices (boot, system, recovery, data, cache) - for obvious safety and security reasons.
After all these months, I stumbled across this tonight
Code:
C:\foo>fastboot oem listpartition
...
INFO[radio]:(OTHER) block start=0, size=332 (42496 KB)
INFO[hboot]:(RAW) block start=333, size=6 (768 KB)
INFO[misc3]:(RAW) block start=339, size=2 (256 KB)
INFO[mfg]:(RAW) block start=341, size=2 (256 KB)
INFO[sp1]:(RAW) block start=343, size=6 (768 KB)
INFO[misc2]:(RAW) block start=349, size=3 (384 KB)
INFO[mfg2]:(RAW) block start=352, size=3 (384 KB)
INFO[recovery]:(RAW) block start=355, size=40 (5120 KB)
INFO[boot]:(RAW) block start=395, size=20 (2560 KB)
INFO[system]:(YAFFS) block start=415, size=1360 (179520 KB)
INFO[cache]:(YAFFS) block start=1775, size=1040 (137280 KB)
INFO[userdata]:(YAFFS) block start=2815, size=1276 (168432 KB)
INFO[misc]:(RAW) block start=4091, size=5 (640 KB)
INFO[microp]:(OTHER) block start=0, size=0 (0 KB)
INFO[nv]:(OTHER) block start=0, size=0 (0 KB)
INFO[tp-melfas]:(OTHER) block start=0, size=0 (0 KB)
OKAY [ 0.071s]
finished. total time: 0.071s
I had never seen references in the Eris forums to the misc3, mfg, sp1, misc2, or mfg2 partitions - I suppose one or more are for boot images. Maybe interesting to boot a kernel image that had access to them, and have a peek at them?
bftb0
You are venturing into an area that is slightly beyond my current level of understanding. (Although we can all learn more.)
Is this even close to what you are looking for?
http://forum.xda-developers.com/showthread.php?t=754805
I'm thinking not, since they appear to be resizing the existing partitions, which doesn't seem to be quite what you are looking for.
I was asking about this a while back to see if anyone was able to get read access to the splash1 (i'm guessing sp1) partition so we could dump the REAL original splash screen for people that needed to go back to full stock. This was basically the only thing that is left out of going to stock since the "original" boot image that I had used for the android skateboards in my post about changing the boot logo was just a resized version I found online somewhere which is slightly bigger than the original if you look closely. I had some info laying around somewhere but it was definitely something about people modifying the mtd drivers in the kernel to get this done.
Without the modified drivers there is no way to do a FULL nand dump at this point.
gnarlyc said:
You are venturing into an area that is slightly beyond my current level of understanding. (Although we can all learn more.)
Is this even close to what you are looking for?
http://forum.xda-developers.com/showthread.php?t=754805
I'm thinking not, since they appear to be resizing the existing partitions, which doesn't seem to be quite what you are looking for.
Click to expand...
Click to collapse
Well, I'd seen that before - but THANK YOU - your post encouraged me to do a better job of searching, and I came up with this:
http://forum.xda-developers.com/showthread.php?t=542688
[SIZE=+2]Awesome![/SIZE] It appears that no mtd kernel hack is needed - as long the Eris kernels we are using accept those parameters (obviously, a little additional work is needed to get the offsets correct for the Eris).
I knew that partitions could be resized - but I wasn't aware that you could add new partition definitions. If it works for the Eris, then cool. (I have to say - the G1/G2/Hero devs surely have turned over a lot of stones that have helped us.)
bftb0
Mohahahhahahahaaha (rubbing hands together deviously). I smell either some interesting development or at least some interesting information coming out of this.
It's working.
More details later.
Flash Memory Map for the Eris:
Code:
PARTITION START END SIZE(1KB) SIZE(128KB) NOTES
radio 0x00000000 - 0x02980000 42,496 332 (3)
- gap! - 0x02980000 - 0x029a0000 128 1 (3)
hboot 0x029a0000 - 0x02a60000 768 6 (2)
misc3 0x02a60000 - 0x02aa0000 256 2 (5)
mfg 0x02aa0000 - 0x02ae0000 256 2 (6)
sp1 0x02ae0000 - 0x02ba0000 768 6 (4)
misc2 0x02ba0000 - 0x02c00000 384 3 (4)
mfg2 0x02c00000 - 0x02c60000 384 3 (4)
recovery 0x02c60000 - 0x03160000 5,120 40
boot 0x03160000 - 0x033e0000 2,560 20
system 0x033e0000 - 0x0dde0000 174,080 1360
cache 0x0dde0000 - 0x15fe0000 133,120 1040
userdata 0x15fe0000 - 0x1ff60000 163,328 1276
misc 0x1ff60000 - 0x20000000 640 5
( You can verify the above on your own phone with a combination of examining /proc/mtd, "dmesg" output immediately after the boot, and output of "fastboot oem listpartition" )
(1) Note all partitions are aligned to a 128-KB boundary (0x20000 - 18 bits)
Presumably this is why "fastboot oem listpartition" reports sizes in this unit
(2) Hboot images from HTC for the Eris have always been exactly 512 KB. Slack space is here,
but I found nothing but 0xFF's in the slack area.
(3) Attempting to dump the from this partition produces many, many error messages of the form:
mtd: MEMGETBADBLOCK returned -1 at 0x02940000 (errno=5)
mtd: MEMGETBADBLOCK returned -1 at 0x02960000 (errno=5)
(4) On my phone, dumps of partitions "sp1", "mfg2" and "misc2" produced un-interesting data blobs: all 0xFF's
Note that I have never flashed a custom boot splashscreen.
(5) Nearly "empty" - bytes not 0x00 or 0xFF are all string data (including CID)
(6) Contains "interesting" string data (including handset ID, manufacturing date, etc) and other binary data. Performing interesting handset operations and then recapturing a partition dump (before/after) and performing a binary diff could reveal strategic locations.
[SIZE=+1]HOW-TO[/SIZE]
Most people have absolutely no business doing this - you have been warned.
Under no circumstances should you hand-type any of these addresses; a simple typo could lead to disaster.
Code:
fastboot -c " mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata) " boot recovery-RA-Eris-v1.6.2.img
will produce the standard kernel partition mappings. Note the leading and trailing spaces in the quoted string - and that the order of appearance is critically important
You may append one or more** of the following, separated with commas as shown in the above (standard mapping) command.
[email protected](radio)
[email protected](hboot)
[email protected](misc3)
[email protected](mfg)
[email protected](sp1)
[email protected](misc2)
[email protected](mfg2)
** I performed individual boots adding only one non-standard partition, and can not guarantee that a disaster will not result if you try to append more than one - or all of them - in one boot.
You can verify the additional partitions have been kanged into the kernel's device tree with
adb shell cat /proc/mtd
and may dump individual partitions via the command "dump_image" (provided by Amon_RA in /sbin), as in the following example:
mount /sdcard
dump_image mfg /sdcard/part.mfg.img
bftb0
If you just want to dump a specific Eris flash memory partition(s) off your phone, there is an even easier method. (Doh!)
Prerequisites:
- 1.49.2000 S-OFF bootloader is installed on your Eris.
- working device drivers on PC and fastboot utility
Steps:
1) Connect via USB to your PC and put phone in FASTBOOT mode (Power up with Send+End)
2) Get the partition names listing using
Code:
fastboot oem listpartition
3) Using the following fastboot syntax, plug in the desired partition name (PNAME):
Code:
fastboot oem saveprt2sd PNAME -n PNAME.bin -a
for example, the "sp1" partition:
Code:
$ fastboot oem saveprt2sd sp1 -n sp1.bin -a
... INFOSaveImageToSD partition file name:sp1
INFOSaveImageToSD output file name:sp1.bin
INFOCmd5 CMD_TIMEOUT
INFOsdcc_poll_status(): i=21
INFOCmd5 polling status timed out
INFOSD: CMD5 fail, rc=2 ..
INFOSD 2.0
INFOHC card
INFO Searching free data sectors....
INFO [SAVE2SD] 131072 bytes saved.
INFO [SAVE2SD] 262144 bytes saved.
INFO [SAVE2SD] 393216 bytes saved.
INFO [SAVE2SD] 524288 bytes saved.
INFO [SAVE2SD] 655360 bytes saved.
INFO [SAVE2SD] 786432 bytes saved.
INFO [SAVE2SD] Done.
OKAY [ 1.728s]
finished. total time: 1.728s
Yep, it really is that simple.
bftb0
Official LineageOS 14.1 for Samsung Galaxy Note 8.0 GT-N51xx
### REQUIRES FULL WIPE A.K.A. CLEAN INSTALL ###
# download odin for windows
http://forum.xda-developers.com/showthread.php?t=2711451
# flash this recovery via odin (AP button)
https://forum.xda-developers.com/galaxy-note-8-0/development/recovery-twrp-2-8-5-0-t3035004
# unofficial nightly build
https://visi0nary.de/builds/full/
# official weekly build - n5100 3G
https://download.lineageos.org/n5100
# official weekly build - n5110 WIFI
https://download.lineageos.org/n5110
# official weekly build - n5120 LTE
https://download.lineageos.org/n5120
# flash gapps via recovery
http://opengapps.org/
Thanks a lot to @BlueFlame4 and @walter79 for their build server !
XDA:DevDB Information
[ROM] Official LineageOS 14.1 for GT-N51xx, ROM for the Samsung Galaxy Note 8.0
Contributors
rgib
Source Code: https://github.com/LineageOS/android_kernel_samsung_smdk4412/tree/cm-14.1
ROM OS Version: 7.x Nougat
Version Information
Status: Alpha
Created 2017-01-06
Last Updated 2017-03-06
Congrats Sir. Always the best. Thank you
Congratulations Roberto! You should be really proud of this as a first release.
I promise you all you will NOT be disappointed with this first Lineage release and marshmallow will be but a distant memory..... ?
Thanks Roberto. Excellent effort. ???
Sent from my GT-N5120 using Tapatalk
Just for information, for my N5100 the SIM-card was not detected after a dirty flash. Didn't want to wipe and clean flash so I went back and can't provide logs. As written, just for information.
mielletseed said:
Just for information, for my N5100 the SIM-card was not detected after a dirty flash. Didn't want to wipe and clean flash so I went back and can't provide logs. As written, just for information.
Click to expand...
Click to collapse
New OS, therefore requires a clean flash to start with, a dirty would just cause no end of pain...
mielletseed said:
Just for information, for my N5100 the SIM-card was not detected after a dirty flash. Didn't want to wipe and clean flash so I went back and can't provide logs. As written, just for information.
Click to expand...
Click to collapse
Try to backup you cm-13.0. Then clean install my unofficial LineageOS 14.1 build and report if you get SIM-card.
Mine works.
rgib said:
Try to backup you cm-13.0. Then clean install my unofficial LineageOS 14.1 build and report if you get SIM-card.
Mine works.
Click to expand...
Click to collapse
After a full wipe I got SIM-PIN-dialog, seems to be working
No I try to use your build and restore my data ...
@rgib: an other information: there were two errors while installing.
Code:
I:operation_start: 'Flashing'
Installing zip file '/external_sd/0_Installation/lineage-14.1-20170106-UNOFFICIAL-n5100.zip'
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
I:Zip does not contain SELinux file_contexts file in its root.
I:Legacy property environment initialized.
Target: samsung/kona3gxx/kona3g:4.4.4/KTU84P/N5100ZTCNL6:user/release-keysTarget: samsung/kona3gxx/kona3g:4.4.4/KTU84P/N5100ZTCNL6:user/release-keys
detected filesystem ext4 for /dev/block/platform/dw_mmc/by-name/SYSTEM
detected filesystem ext4 for /dev/block/platform/dw_mmc/by-name/SYSTEM
about to run program [/tmp/install/bin/backuptool.sh] with 2 args
run_program: child exited with status 127
about to run program [/tmp/install/bin/otasigcheck.sh] with 1 args
Patching system image unconditionally...
performing update
Patching system image unconditionally...
blockimg version is 4
maximum stash entries 0
creating stash /cache/recovery/13c23145f94d68015632f2cd29899c1aaf9ad199/
1557766144 bytes free on /cache (0 needed)
erasing 224813 blocks
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 1024 blocks of new data
writing 757 blocks of new data
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 1024 blocks
zeroing 734 blocks
wrote 168403 blocks; expected 168403
stashed 0 blocks
max alloc needed was 4096
[COLOR="Red"]E:unknown command [log]
E:unknown command [log][/COLOR]
deleting stash 13c23145f94d68015632f2cd29899c1aaf9ad199
detected filesystem ext4 for /dev/block/platform/dw_mmc/by-name/SYSTEM
detected filesystem ext4 for /dev/block/platform/dw_mmc/by-name/SYSTEM
about to run program [/tmp/install/bin/backuptool.sh] with 2 args
/tmp/install/bin/backuptool.sh: cd: line 113: can't cd to /tmp/addon.d/
md5sum: can't open '*sh': No such file or directory
script succeeded: result was [1.000000]I:Updater process ended with RC=0
I:Legacy property environment disabled.
Updating partition details...
I:Data backup size is 0MB, free: 8872MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
I:Set page: 'flash_done'
I:operation_end - status=0
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
I:operation_start: 'Copy Log'
I:Copying file /tmp/recovery.log to /external_sd/recovery.log
@rgib
Installed your lineage-14.1-20170107-UNOFFICIAL-n5120.zip from firmware stock after a wipe data and cache.
Gps not work
Sim not work
Bluetooth instable
wifi with mac correct :works
camera works
Here my logs
Thanks for your what you are doing for us and Happy new Year!!
mielletseed said:
@rgib: an other information: there were two errors while installing.
Code:
E:unknown command [log]
E:unknown command [log
Click to expand...
Click to collapse
All cm14 based builds have given / are likely to give this error. It's nothing to bother about.
kaworuxda said:
@rgib
Installed your lineage-14.1-20170107-UNOFFICIAL-n5120.zip from firmware stock after a wipe data and cache.
Gps not work
Sim not work
Bluetooth instable
wifi with mac correct :works
camera works
Here my logs
Thanks for your what you are doing for us and Happy new Year!!
Click to expand...
Click to collapse
Flashed Rom found the same as quoted
Logs attached
Cheers
Al
tu sei il migliore
installed the 7.01.2017 build for gt-n5100 :
GPS/location works fine
SIM works fine ( incoming outgoing ok, haven't tested data though ...)
WIFI Mac ... Works fine
Bluetooth transfers ... works fine
camera can take photos but not videos app crashes in video mode
SD cards work but inbuilt file manager won't open SD card files, asks for root access mode, tried enabling root access for apps and adb in dev mode as well as file manager but nothing happens...
wish you a very Happy New Year and thank you for your efforts .....
arnob2014 said:
camera can take photos but not videos app crashes in video mode
SD cards work but inbuilt file manager won't open SD card files, asks for root access mode, tried enabling root access for apps and adb in dev mode as well as file manager but nothing happens...
Click to expand...
Click to collapse
CM file manager is very buggy still - try deleting a directory named ".android_secure" from your sdcard if it exists (but you will need different file manager to do this, others will work)
Camera - try 3rd party apps, e.g. camu, cameringo, open camera - some / all / none may work better
All work fine..thanks very much dev for your works..thumb up.!
ROM - lineage-14.1-20170107-UNOFFICIAL-n5100
GApps - open_gapps-arm-7.1-pico-20170107
Root(systemless) - SR2-SuperSU-v2.79-SR2-20170103215521
Camera - Open Camera
@rgib FYI if you wanna use the built in update mechanism from LOS use https://visi0nary.de/api as OTA host. Example: https://github.com/visi0nary/android_device_elephone_p8000/blob/cm-12.1/system.prop#L170
Buff99 said:
All cm14 based builds have given / are likely to give this error. It's nothing to bother about.
Click to expand...
Click to collapse
I can confirm that. Exactly the same errors during installation. Beside that I get the "new SIM card detected" error which was there sometimes in CM13. I need to do some further testing, but the device seems pretty stable.
rgib, you really make me appreciate my Note 8 after all this years. Thanks!
i'm very impressed with the first build ! thanks a lot Roberto !
TibReg said:
I can confirm that. Exactly the same errors during installation. Beside that I get the "new SIM card detected" error which was there sometimes in CM13. I need to do some further testing, but the device seems pretty stable.
rgib, you really make me appreciate my Note 8 after all this years. Thanks!
Click to expand...
Click to collapse
Try to update baseband
I just took delivery of a 2018 Honda Odyssey EX-L that has an Android Lollipop 5.1.1 based system.
I attempted to connect to the system to gain root following the instructions which work for a 2016 Honda Pilot which were found here: https://forum.xda-developers.com/showpost.php?p=71331595&postcount=404
I was able to connect via ADB wirelessly to the vehicle
Connecting to 192.168.1.68\n
connected to 192.168.1.68:5555
Checking for root...
No root yet, addressing the situation
Attempting to push payloads to /data/local/tmp/rootme\n
mkdir failed for /data/local/tmp/rootme, File exists
1 KB/s (60 bytes in 0.031s)
97 KB/s (10964 bytes in 0.110s)
26 KB/s (835 bytes in 0.030s)
124 KB/s (133472 bytes in 1.047s)
Exploiting dirtycow to replace factory_reset.sh with our own\n
error: only position independent executables (PIE) are supported.
Okay - should be all set, initiate factory reset and hope for the best!
Go to Home ->Settings->System->Factory Data Reset (scroll all the way down) and ititiate factory reset, press enter when unit has rebooted & reconnected to WiFi
Okay - checking for successfull root\n
connected to 192.168.1.68:5555
error: device unauthorized.
This adbd's $ADB_VENDOR_KEYS is not set; try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
Click to expand...
Click to collapse
Now I did clear out my Keys on the computer side and and tried again and got no further.
Has anyone successfully rooted a 2018 Honda system yet?
If not I am willing to be the guinea pig, but I am not an Android guy and could use some help.
Very interested in this as well. Haven't picked up my 2018 Odyssey yet but it will be very soon.
Thanks
\adb\adb.exe
Connecting
Connected
abi: armeabi-v7a
1105 KB/s (17880 bytes in 0.015s)
5 KB/s (5544 bytes in 1.000s)
WARNING: linker: /data/local/tmp/dcow: unused DT entry: type 0x6ffffffe arg 0x828
WARNING: linker: /data/local/tmp/dcow: unused DT entry: type 0x6fffffff arg 0x1
dcow /data/local/tmp/run-as /system/bin/run-as
warning: new file size (5544) and destination file size (9440) differ
[*] size 9440
[*] mmap 0x76ece000
[*] currently 0x76ece000=464c457f
[*] using /proc/self/mem method
[*] madvise = 0x76ece000 9440
[*] madvise = 0 12210747
[*] /proc/self/mem 86252832 1374063
[*] exploited 0 0x76ece000=464c457f
25 KB/s (406 bytes in 0.015s)
4727 KB/s (75348 bytes in 0.015s)
2824 KB/s (903797 bytes in 0.312s)
Reconnecting
Reconnected
WARNING: linker: /data/local/tmp/dcow: unused DT entry: type 0x6ffffffe arg 0x828
WARNING: linker: /data/local/tmp/dcow: unused DT entry: type 0x6fffffff arg 0x1
dcow /data/local/tmp/run-as /system/bin/run-as
warning: new file size (5544) and destination file size (9440) differ
[*] size 9440
[*] mmap 0x76eb7000
[*] currently 0x76eb7000=464c457f
[*] using /proc/self/mem method
[*] madvise = 0x76eb7000 9440
[*] /proc/self/mem 569631328 970293
[*] madvise = 0 15112179
[*] exploited 0 0x76eb7000=464c457f
Usage: run-as <package-name> <command> [<args>]
Any update on this?
unleash Android Auto please....
Anybody have any leads on rooting the Odyssey 2018?
Anybody have any leads on sideloading waze or gmaps?
I was able to enable USB debugging, connect via ADB and install "some" APks
I was able to get an older version of waze to work (no need to disable distracting driver mode)
{
"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"
}
They say, that unfortunately, a majority of new Unisoc (Spreadtrum) chips have bootloaders that cannot be unlocked without a key, which is not provided by the SoC manufacturer, and is beyond the control of the ODM. Many low-end Android smartphones are powered by such chips, and the end result is that root is impossible on those devices, i.e. ZTE Blade A5 2019, Doogee N10, etc. (Unisoc SC9863A)
Some have obtained the source code of the U-boot bootloader used on those devices, however, the algorithm for the key verification is stored on the Trusted Execution Environment, which means it cannot be extracted (the TEE is a SecureEnclave-like device, with no possible direct access to it's memory or storage, besides de-capping it and reading the bits with an electron microscope) -- more info here: https://source.android.com/security/trusty
However, Spreadtrum actually does verify the whole boot process, meaning that booting a modified binary is impossible. If you change the boot partition, it will infinitely reboot with a black screen and vibration. If you leave the boot as-is, but change system, it will get to the splash screen and then reboot. etc.
It genuinely does cryptographicaly verify the signature and hash of every partition. Which is great for security, in theory, unless the OS has preloaded spyware, but the secureboot process prevents you from removing it.
Been there, and I didn't even realised the cause.
MTK is quite good, but it's becoming worse in the perf/$ ratio, i.e. the SC9863A is a octa core A55 chip at 1.5GHz, while similar MTK devices are dual core A7 at 1.2 GHz. The architecture improvements alone are excellent, not mentioning the extra cores and higher clock speed.
The key is most certainly not the same, because I doubt they would go through the trouble of doing actual secure boot verification, and storing the data in the TEE, and just have the same key. Additionally, the U-boot code I obtained lies to the user about commands not being found, if the command doesn't contain a valid unlock key.
there is a dedicated thread on hovatek forum for rooitng this chipset
that thread on hovatek is thrilling...
Hovatek forums indicate you need a PAC or FDL file to do anything unless you buy extra hardware. Can anything be done for a vendor that hasn't released either? Even a temproot exploit like mtk-su is fine, if it works on Android 9.
those El-Cheapo phones are simply not supported well by hackerdom.
if we can port mtk-su to this processor or create a new temp root we are done
Skorpion96 said:
if we can port mtk-su to this processor or create a new temp root we are done
Click to expand...
Click to collapse
You cant port mtk-su. The sercuity exploit is a defect built into the CPU. A CPU is made up on millions of transistors , A transistor is a switch (On/Off) , Creates a workload that targets the switch would normally return no to yes is very difficult n can very easily destroy the CPU by creating a internal short. NOTE The device manufacturer can help provide a bootloader key if request
lepusang said:
You cant port mtk-su. The sercuity exploit is a defect built into the CPU. A CPU is made up on millions of transistors , A transistor is a switch (On/Off) , Creates a workload that targets the switch would normally return no to yes is very difficult n can very easily destroy the CPU by creating a internal short. NOTE The device manufacturer can help provide a bootloader key if request
Click to expand...
Click to collapse
i know that mtk-su can't be ported but maybe we can use the source of mtk easy su and the cve-2015-1474 to make a working app
Skorpion96 said:
i know that mtk-su can't be ported but maybe we can use the source of mtk easy su and the cve-2015-1474 to make a working app
Click to expand...
Click to collapse
Can it really be done? I have a ZTE blade vantage 2 and I'd love to root it if possible.
I just tried a zip to enable fastboot on the axon mini on my zte blade A5 2019, it flashes, fails because model is different but it is not a signature error meaning that it has the same signature. So signature is the same for every zte, now I'm asking zte Italy to help me getting the unlock file or the signature itself which is the same since or I will flash the file directly or I will sign it and flash. I hope they will help.
Useless try, they refused to help because of their policy
Went out and bought an m8l plus to try it. This is the first time I've ever dealt with a unisoc sc9863a. I was optimistic about it at first, but now I'm doubtful
*Update* found modified fastboot folder and did the following. Unlocked bootloader, about to try to root with magisk. Root achieved with magisk. Made copy of firmware, moved boot_a to phone and patched with magisk. Flashed patched boot_a with adb. Currently deleting system apps. Root is go. This is unisoc sc9863a blu m8l Android 11
Found this. Can't post the link, but I'll c&p the text:
Open the modified_fastboot folder, right-click then select Open in Terminal
Test detection using
Code:
./fastboot devices
Get Identifier Token using
Code:
./fastboot oem get_identifier_token
You should get an output like
Identifier token:
XXXXXXXXXXXXXXXXXXXXXXXX
OKAY [ 0.019s]
finished. total time: 0.019s
Copy out the Identifier token
Run this command ; replace XXXXXXXXXXXXXXXXXXXXXXXX with your Identifier token
Code:
./signidentifier_unlockbootloader.sh XXXXXXXXXXXXXXXXXXXXXXXX rsa4096_vbmeta.pem signature.bin
You should have an output like
Identifier sign script, ver 0.10
1+0 records in
1+0 records out
50 bytes copied, 0.000257562 s, 194 kB/s
Identifier sign successfully
You should also see a signature.bin file in the modified_fastboot folder
Finally, run this command
Code:
./fastboot flashing unlock_bootloader signature.bin
You should get a prompt on the device asking you to push a volume button to confirm unlock, do so
{
"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"
}
You should now have an output like
downloading 'unlock_message'...
OKAY [ 0.001s]
unlocking bootloader...
Info:Unlock bootloader success! OKAY [ 85.787s]
finished. total time: 85.788s
Reboot the device using
Code:
./fastboot reboot
Your bootloader should now be unlocked
They request you log in and register in exchange for the modified fastboot folder
you can get the modified Fastboot folder anywhere, used that trick to bl unlock all my blu and wiko phones
R41N MuTT said:
Found this. Can't post the link, but I'll c&p the text:
Open the modified_fastboot folder, right-click then select Open in Terminal
Test detection using
Code:
./fastboot devices
Get Identifier Token using
Code:
./fastboot oem get_identifier_token
You should get an output like
Identifier token:
XXXXXXXXXXXXXXXXXXXXXXXX
OKAY [ 0.019s]
finished. total time: 0.019s
Copy out the Identifier token
Run this command ; replace XXXXXXXXXXXXXXXXXXXXXXXX with your Identifier token
Code:
./signidentifier_unlockbootloader.sh XXXXXXXXXXXXXXXXXXXXXXXX rsa4096_vbmeta.pem signature.bin
You should have an output like
Identifier sign script, ver 0.10
1+0 records in
1+0 records out
50 bytes copied, 0.000257562 s, 194 kB/s
Identifier sign successfully
You should also see a signature.bin file in the modified_fastboot folder
Finally, run this command
Code:
./fastboot flashing unlock_bootloader signature.bin
You should get a prompt on the device asking you to push a volume button to confirm unlock, do so
You should now have an output like
downloading 'unlock_message'...
OKAY [ 0.001s]
unlocking bootloader...
Info:Unlock bootloader success! OKAY [ 85.787s]
finished. total time: 85.788s
Reboot the device using
Code:
./fastboot reboot
Your bootloader should now be unlocked
They request you log in and register in exchange for the modified fastboot folder
Click to expand...
Click to collapse
It succeeded ....but. when i try
fastboot flash recovery recovery.img
It says
Sending recovery... (Size shows in KB)
Then says writing recovery... Fot infinity ....
I ported custom twrp recovery using hovatek's automatic unisoc twrp porting guide....have any solution? I also tried to flash twrp by spd research tool and it stuck at probably 95/97 percent
R41N MuTT said:
Found this. Can't post the link, but I'll c&p the text: ....
Click to expand...
Click to collapse
fastboot oem get_identifier_token
Give only back the Serial Number in hexadecimal
Put your SN of your Device in a Hexeditor and change the view to Hexview
when you compare you will see its the SN
I show you the output of my Device, it's an blackview A70 Smartphone. This device is my favorite victim, because it is stubborn as a donkey.
Code:
d:\android\blackview\a70>fastboot oem get_identifier_token
(bootloader) identifier token:
(bootloader) 334b3032384137304545413037313431
(bootloader) 37
okay [ 0.031s]
finished. total time: 0.031s
(the number above in a phantasy number)
Interesting is, here are 3 lines (bootloader)
1. is title
2. is first part of SN
3. is 2. Part of SN
yes the length of the SN of this device is 17 characters. In this case you have to put line 2 and line 3 together to build the number.
If you dont do that, not success with unlock.
for example, this is my SN read with
fastboot devices
3K028A70EEA071417
fastboot oem get_identifier_token
334b3032384137304545413037313431
37
the difference is only binary and hex view
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"?