Related
Hi all,
Here I'll describe every Hack/Mod/Discovery i'll do on my phone,
the Samsung Galaxy Next/Mini/Pop GT-S5570.
ASSUMPTION : I will not install CWM.
I've already made some experiments, and bricked the phone...
... but i'm still going on.
I'll log every step i made - while expecting a repaired device from service.
Every suggestion from other experience are welcome!
Summary & Status
--------------------------------------------------------------------------------------------------
This is the summary/status of the work i made - direct on the phone (Configuration, APKs, Mods, ...)
1) Root the phone AND ADB demon. [post 3]
2) Add Essential APKs. [post 3]
3) Remove/Replace Stock applications. [post 6]
4) Got a personalized Restore. [post 6]
5) my device is back, with new GB ROM ... and personalized /system. [post 58]
--------------------------------------------------------------------------------------------------
This is the summary/status of every experiment i do with the ROM ...
1) use of ADB and related tools. [post 7]
2) backup copy of /system folder [post 7]/URL]
3) dump of partitions. [URL="http://forum.xda-developers.com/showpost.php?p=17900113&postcount=7"][post 7]
4) extract the list of partitions. [post 8]
Analizing the dumped files...
5) the dumped images can be flashed with odin !!! [post TODO]
6) extract the /system filesystem. [post 9]
7) extract the boot & recovey images. [post 12]
8) after extracting boot images...rebuild them (thanks to Doc_cheilvenerdi.org ) [post 32] and [post 40]
9) add ext4 FileSystem and busybox! (thanks to Doc_cheilvenerdi.org ) [post 44]
10) moved /data to SD !! (thanks to Doc_cheilvenerdi.org ) [post 50] and [post 52]
after explaining here how to modify the boot.img, Doc_cheilvenerdi.org wrote some exellent guides to describe his methods to to add ext4 support and move /data to SD and then move /system to SD. He also guides you in hacking the initial logos and animations and gaining root privileges on every ROM(here the IT source). Since he's not only a master in hacking and developing, but he explain it all, this 3ds are a must read !!Only... they're in italian languages... (need help in translation, please)
ToDo
...) share my PC connection to device (Reverse-Tethering) - investigation starts in [post 59]
...) understand and investigate init*** files in ramdisk ( apart from init.rc, when are they started? what they'll do ?).
...) understand and investigate the APK install process
...) understand and investigate the android framework.
...) move /data/apps/ /data/data and /data/dal***-cache to SD (should be simple, after Doc effort !!)
...) load and adapt my dumped images to androind_x86 (porting to PC/VM of android) [post ...]
--------------------------------------------------------------------------------------------------
>>> OPENED QUESTIONS <<<
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
please see also my considerations in [post27]
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
please see also my considerations in [post27]
5) what are MIBIB, QCSBL, OEMSBL, AMSS, EFS2, NVBACKUP, APPSBL, PARAM, FOTA partitions ?
6) why the kernel has a gziped part in it ?
=======================================================================================
stepph said:
1) Root the phone AND ADB demon.
Click to expand...
Click to collapse
I used SuperOneClick tool. Its easy.
Only remeber to root also the adb shell, in order to be able to acess as super user.
As you use the tool, the SuperUser.apk is added to your ROM.
This tool make a window appear every time an apps need root access, and you have a log.
Even if you reset the device, the rooting and SU will survive.
=======================================================================================
stepph said:
2) Add Essential APKs.
Click to expand...
Click to collapse
I install RootExplorer, ES_FileManager in order to be able to navigate in the filesystem.
With rooting, i can also mount /system as R/W... and RootExplorer also indicate the mountpoint of some folders...
Eploring the FS, I notice :
/system/apps - where the preloade apks are. Some are systems apps (unknow), some are apps that i have in the apps folder.
/cache - where tempoarary data are stored.
/data - where apps save info
=======================================================================================
... continue in [post 6]...
3x. Would you like to tell how you modify the recovery.img and boot.img?
dongbincpp said:
3x. Would you like to tell how you modify the recovery.img and boot.img?
Click to expand...
Click to collapse
at now i'm studing on that...
... reading "HOWTO: Unpack, Edit, and Re-Pack Boot Images".
stepph said:
3) Remove/Replace Stock applications.
Click to expand...
Click to collapse
So I manage to remove (and backup on SD and then o my PC) the unused apk
from /systems/apps/
Some APKs have odex file (that are a way to speed up loading...) - the unused one to be removed too.
After a wipe - I noticed that the apks are DEFINITELY removed - WOW i delete something from the ROM of my phone...
If i put the backup copy of the removed files back, they still work.
Instead, if i try to install them, some of them does not work anymore (why?)
I notice the SuperUser apks too... so I try to add different apk here, or change the old one with an updated version...
So when i'll wipe the phone i'll get it with what i want.
Sometimes it works, sometimes i got errors on startup, sometimes the device ignore the new apps (??)
=======================================================================================
stepph said:
4) Got a personalized Restore.
Click to expand...
Click to collapse
When I wipe the phone, widget and links are the defult ones... how can i modify this ??
I notice dat inside /data/ folder are stored the Launcher dta & options - inside a *.db file.
So i can save & restore what i set.
But i still not understand where the setting are recorder on wipe...
=======================================================================================
... continue in [post 7]...
stepph said:
1) use of ADB and related tools.
Click to expand...
Click to collapse
great ... it is like a shell working on my terminal...
i'm not so experienced with linux command, buti'll try
I also use adb mask control, thas has a GUI to rapidly make some operation.
so i push sqlite and a new version of busybox on my device
stepph said:
2) backup copy of /system folder
Click to expand...
Click to collapse
playing with mount and my adb shell, i found:
Code:
d rwx r-x r-x root root 2011-09-09 10:10 acct
d r-x --- --- root root 2011-09-09 10:10 config
d rwx r-x r-x root root 1970-01-01 01:00 lib
d rwx --- --- root root 2011-05-02 04:40 root
d rwx r-x --- root root 1970-01-01 01:00 sbin
d rwx rwx --x system system 2011-09-09 10:10 persist
d rwx r-x r-x root root 2011-09-09 10:12 dev mount from tmpfs
d r-x r-x r-x root root 1970-01-01 01:00 proc mount from proc
d rwx r-x r-x root root 1970-01-01 01:00 sys mount from sysfs
d rwx rwx --- system cache 2011-09-09 10:10 cache mount from /dev/stl14 (rfs)
d rwx rwx --x system system 2011-09-09 10:10 data mount from /dev/stl13 (rfs)
d rwx r-x r-x root root 2011-09-09 10:10 system mount from /dev/stl12 (rfs)
d rwx rwx r-x root system 2011-09-09 10:10 mnt
/mnt/asec ??
/mnt/sdcard ??
/mnt/secure ??
l rwx rwx rwx root root 2011-09-09 10:10 d link from /sys/kernel/debug
l rwx rwx rwx root root 2011-09-09 10:10 etc link from /system/etc
l rwx rwx rwx root root 2011-09-09 10:10 sdcard link from /mnt/sdcard
i simply make a backup of files in / and of /system/ on my PC...
since other folders have 'strange' mountpoints... i let them apart for now.
stepph said:
3) dump of partitions.
Click to expand...
Click to collapse
i found this list: cat proc/partition/
Code:
major minor #blocks name
137 0 513024 bml0/c
137 1 1536 bml1
137 2 512 bml2
137 3 768 bml3
137 4 25600 bml4
137 5 9216 bml5
137 6 5120 bml6
137 7 2048 bml7
137 8 8192 bml8
137 9 8192 bml9
137 10 768 bml10
137 11 6144 bml11
137 12 222464 bml12
137 13 192768 bml13
137 14 29696 bml14
138 12 214784 stl12
138 13 185600 stl13
138 14 25856 stl14
179 0 1927168 mmcblk0
179 1 1926144 mmcblk0p1
so i start with cat /dev/bml0 >/sdcard/bml0.img
and so on for each BML to 14.
Then i try with STL... and I brick my PHONE !!!
Reading around...
>>>> DO NOT TRY TO ACCESS TO STL5<<<<
Now my phone is at service for repairing - i hope they accept warranty -
I'll continue my investigations on the BMLxx.img files...
=======================================================================================
... continue in [post 8] - without phone - ...
Now, i have the segunt dumped images:
Code:
0 513024 bml0/c
1 1536 bml1
2 512 bml2
3 768 bml3
4 25600 bml4
5 9216 bml5
6 5120 bml6
7 2048 bml7
8 8192 bml8
9 8192 bml9
10 768 bml10
11 6144 bml11
12 222464 bml12
13 192768 bml13
14 29696 bml14
an easy check prove me that the first and bigger one is simply the join on the others... so first of all i look for some indication about the partitioning of BML0, from which the others are derived.
With a hex editor, I found :
Code:
00081000h: AA 73 EE 55 DB BD 5E E3 03 00 00 00 0E 00 00 00 ªsîUÛ½^ã........
00081010h: 30 3A 4D 49 42 49 42 00 00 00 00 00 00 00 00 00 0:MIBIB.........
00081020h: 00 00 00 00 06 00 00 00 12 10 FF 00 30 3A 51 43 ..........ÿ.0:QC
00081030h: 53 42 4C 00 00 00 00 00 00 00 00 00 06 00 00 00 SBL.............
00081040h: 02 00 00 00 12 10 FF 00 30 3A 4F 45 4D 53 42 4C ......ÿ.0:OEMSBL
00081050h: 31 00 00 00 00 00 00 00 08 00 00 00 03 00 00 00 1...............
00081060h: 12 10 FF 00 30 3A 41 4D 53 53 00 00 00 00 00 00 ..ÿ.0:AMSS......
00081070h: 00 00 00 00 0B 00 00 00 64 00 00 00 12 10 FF 00 ........d.....ÿ.
00081080h: 30 3A 45 46 53 32 00 00 00 00 00 00 00 00 00 00 0:EFS2..........
00081090h: 6F 00 00 00 24 00 00 00 01 11 FF 00 30 3A 4E 56 o...$.....ÿ.0:NV
000810a0h: 42 41 43 4B 55 50 00 00 00 00 00 00 93 00 00 00 BACKUP......“...
000810b0h: 14 00 00 00 01 11 FF 00 30 3A 41 50 50 53 42 4C ......ÿ.0:APPSBL
000810c0h: 00 00 00 00 00 00 00 00 A7 00 00 00 08 00 00 00 ........§.......
000810d0h: 12 10 FF 00 30 3A 41 50 50 53 00 00 00 00 00 00 ..ÿ.0:APPS......
000810e0h: 00 00 00 00 AF 00 00 00 20 00 00 00 12 10 FF 00 ....¯... .....ÿ.
000810f0h: 30 3A 52 45 43 4F 56 45 52 59 00 00 00 00 00 00 0:RECOVERY......
00081100h: CF 00 00 00 20 00 00 00 12 10 FF 00 30 3A 50 41 Ï... .....ÿ.0:PA
00081110h: 52 41 4D 00 00 00 00 00 00 00 00 00 EF 00 00 00 RAM.........ï...
00081120h: 03 00 00 00 12 10 FF 00 30 3A 46 4F 54 41 00 00 ......ÿ.0:FOTA..
00081130h: 00 00 00 00 00 00 00 00 F2 00 00 00 18 00 00 00 ........ò.......
00081140h: 01 10 FF 00 30 3A 53 59 53 41 50 50 53 00 00 00 ..ÿ.0:SYSAPPS...
00081150h: 00 00 00 00 0A 01 00 00 65 03 00 00 01 11 FF 00 ........e.....ÿ.
00081160h: 30 3A 44 41 54 41 00 00 00 00 00 00 00 00 00 00 0:DATA..........
00081170h: 6F 04 00 00 F1 02 00 00 01 11 FF 00 30 3A 43 41 o...ñ.....ÿ.0:CA
00081180h: 43 48 45 00 00 00 00 00 00 00 00 00 60 07 00 00 CHE.........`...
00081190h: 74 00 00 00 01 11 FF 00 FF FF FF FF FF FF FF FF t.....ÿ.ÿÿÿÿÿÿÿÿ
i.e.
Code:
[I]name[/I] [I]start[/I] [I]len[/I] [I]??[/I]
MIBIB 00000000 00000600 12 10
QCSBL 00000600 00000200 12 10
OEMSBL 00000800 00000300 12 10
AMSS 00000B00 00006400 12 10
EFS2 00006F00 00002400 01 11
NVBACKUP 00009300 00001400 01 11
APPSBL 0000A700 00000800 12 10
APPS 0000AF00 00002000 12 10
RECOVERY 0000CF00 00002000 12 10
PARAM 0000EF00 00000300 12 10
FOTA 0000F200 00001800 01 10
SYSAPPS 00010A00 00036500 01 11
DATA 00046F00 0002F100 01 11
CACHE 00076000 00007400 01 11
that is not only the list of the partition of BML0 in BML1..14, with the correspondant sizes, but also the name of each - they match with what i read in some posts !!
Here it is also some binary tags for ech BML; and adding a quick examiation of the head of each file, i get the following table of preliminary infos:
Code:
Disk MB KB bytes Name flags FSR_STL note Start Lenght
/dev/bml0: 525 513.024 525.336.576
/dev/bml1: 1 1.536 1.572.864 MIBIB 12 10 00000000 00000600
/dev/bml2: 0 512 524.288 QCSBL 12 10 00000600 00000200
/dev/bml3: 0 768 786.432 OEMSBL 12 10 00000800 00000300
/dev/bml4: 26 25.600 26.214.400 AMSS 12 10 ELF 00000B00 00006400
/dev/bml5: 9 9.216 9.437.184 EFS2 01 11 X dev/stl5 ! Attento! 00006F00 00002400
/dev/bml6: 5 5.120 5.242.880 NVBACKUP 01 11 X dev/stl6 (empty) 00009300 00001400
/dev/bml7: 2 2.048 2.097.152 APPSBL 12 10 arm11boot ? 0000A700 00000800
/dev/bml8: 8 8.192 8.388.608 APPS 12 10 ANDROID! - boot image 0000AF00 00002000
/dev/bml9: 8 8.192 8.388.608 RECOVERY 12 10 ANDROID! - recovery image 0000CF00 00002000
/dev/bml10: 1 768 786.432 PARAM 12 10 0000EF00 00000300
/dev/bml11: 6 6.144 6.291.456 FOTA 01 10 empty 0000F200 00001800
/dev/bml12: 217 222.464 227.803.136 SYSAPPS 01 11 X /dev/stl12 - /system (rfs) 00010A00 00036500
/dev/bml13: 197 192.768 197.394.432 DATA 01 11 X /dev/stl13 - /data (rfs) 00046F00 0002F100
/dev/bml14: 30 29.696 30.408.704 CACHE 01 11 X /dev/stl14 - /cache (rfs) 00076000 00007400
================================================== =====================================
... continue in post 9 - without phone - ...
First, i work on the BML12, that is the file related to /system folder.
I read a lot of stuff about Samsung BML, STL, RFS, and so on...
My understanding is that BML is the layer of block level devices,
and STL is the 'file system like' layer on it. I read also that STL are FAT compatible, and that images can be opened with MagicISO.
So i found in BML12.img file the signature MSWIN4.1, cut the previus part (two byte more) and i get a fat-12 image.
MagicISO was able to extract this files.
I compare the extracted /system folder wit the backup i done directly from the phone ... SURPRISE... the files i removed from ROM are there again !! why this ??
On the other side i wander where the others files in original filesystem are...
Same tecnich on BML13 & BML14 for /data and /cach partition does'n work at all -- why ?
=======================================================================================
... continue in post 12 - without phone - ...
stepph
wat ur doing here is great.
but didn u notice a few other mini threads here already..a few roms n cm7?
http://forum.xda-developers.com/showthread.php?t=1167750
http://forum.xda-developers.com/showthread.php?t=1176927
there are other threads too
---------- Post added at 02:01 PM ---------- Previous post was at 01:52 PM ----------
stepph said:
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
Click to expand...
Click to collapse
I dont think u can install any app as a system, think u can only replace an already existing system app with another of ur wish by renaming the app correctly and replacing it in /system/app
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
Click to expand...
Click to collapse
u cannot install app as a system app. as said abv u can only replace them.
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
Click to expand...
Click to collapse
maybe u need to remove them frm the dalvik-cache too
----edit------
clearly I have not played with my phone enough to be answering such questions.
roofrider said:
stepph wat ur doing here is great.
but didn u notice a few other mini threads here already..a few roms n cm7?
http://forum.xda-developers.com/showthread.php?t=1167750
http://forum.xda-developers.com/showthread.php?t=1176927
there are other threads too
Click to expand...
Click to collapse
Thank you for the links,
I notice that already...but none of them talk about HOW it was made...
... i don't want a " download and install " work, but explain to everybody what i do.
roofrider said:
I dont think u can install any app as a system, think u can only replace an already existing system app with another of ur wish by renaming the app correctly and replacing it in /system/app
u cannot install app as a system app. as said abv u can only replace them.
maybe u need to remove them frm the dalvik-cache too
Click to expand...
Click to collapse
Ok, it was what i think about 1st & 2nd point...I'll look for technical infos about those 'system' apps.
About the 3rd, you may be right if it was about a running device; but i worked on dumped images, so VM cache should not be involved... i'll investigate.
About Boot.img and Recovery.img
I tested this method on my duped BML files, and on some downloaded ROM.
in bootimg.h - from Android SDK (so i suppose, but i found in this forum)
Code:
#define BOOT_MAGIC "ANDROID!"
#define BOOT_MAGIC_SIZE 8
#define BOOT_NAME_SIZE 16
#define BOOT_ARGS_SIZE 512
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE];
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
/*
** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size != 0)
** 2. second is optional (second_size == 0 -> no second)
** 3. load each element (kernel, ramdisk, second) at
** the specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr. kernel_args[] is
** appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size != 0: jump to second_addr
** else: jump to kernel_addr
So i opened my file, and found
Code:
414E4452 4F494421 C8F42E00 00806013 0E143000 00006014 00000000 00005014 00016013 00100000 00000000 ...
that is
Code:
00000000 struct BOOT_IMG_HDR
00000000 magic[8] ANDROID!
00000008 DWORD kernel_size 3077320
0000000C DWORD kernel_addr 325091328
00000010 DWORD ramdisk_size 3150862
00000014 DWORD ramdisk_addr 341835776
00000018 DWORD second_size 0
0000001C DWORD second_addr 340787200
00000020 DWORD tags_addr 325058816
00000024 DWQRD page_size 4096
00000028 unused[2] 0
00000030 name[16] 0
00000040 cmdline[512] 0
00000240 id[8] xxxxxxx
so i calculate
Code:
n = (3077320 + 4096 - 1) / 4096 = 752
m = (3150862 + 4096 - 1) / 4096 = 770
o = (0 + 4096 - 1) / 4096 = 0
** +-----------------+
** | boot header | 1 page = 0 to 4095 (h00000FFF)
** +-----------------+
** | kernel | 752 pages = 4096 to 4096+752*4096 = 3084287 (h002F0FFF)
** +-----------------+
** | ramdisk | 770 pages = 3084288 to 3084288+770*4096 = 2378055679 (h8DBE3FFF)
** +-----------------+
so i spli the file in 3 parts : header, kernel, and ramdisk.
NOTE: at offset 18825 (h4989) i find 1F 8F that is the head of a gzipped file..
so i split kernel in kernel.head and kernel.gz => decompressed in kernel.tail.
This worked, sinc in decompressed part i found readable strings...
Ramdisk is ramdisk.cpio.gz, so i was able to decompress it and get the filesystems loaded on start.
There are many interesting files...
TASS.rle and TASS-HUI.rle (the original logo, and the logo for italy - HUI is my region)
init and init.rc - and some other script file, that i saw on root folder of my devices
some folders with bins, and so on...
When i use this method with dumped Recovery.img and downloaded ClockWorkMod_recovery.img, i get i working...
So i'll investigate about differences in ramdisk files of those...
=======================================================================================
... continued in [post 14] - without phone - ...
I'm neither an Android, nor a Linux expert but I'll try to answer your questions to the best of my knowledge:
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
Click to expand...
Click to collapse
Some system apks don't have a registered activity (meaning they don't have a UI), so they won't appear in your launcher, also (and take this with a grain of salt), I've personally found that some of the apks placed in /system/app/ need to be installed too.
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
Click to expand...
Click to collapse
Dunno about this one, but I'd dare say that it has something to do with the extra files that are placed in other folders, What apps have you had this problem with?, maybe we can find out why they have that behavior
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
Click to expand...
Click to collapse
If they're not wiped they have to be either in the system partition or in the SD
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
Click to expand...
Click to collapse
Taken from the link you put on the BML mapping thread:
What you generally see is that BML partitions contain 'static' data (bootloaders, boot / recovery images) and STL partitions contain 'live' filesystem (on android: /system, /data, /cache, /efs, /dbdata). The idea is that things directly on an BML partition don't change very often and wear leveling isn't required. Read/write filesystems however, do benefit from wear leveling and are thus placed on an STL partition.
Click to expand...
Click to collapse
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
Click to expand...
Click to collapse
You'd have to find out the partition's filesystem, I believe it's a Samsung propietary FS so you're out of luck with that one
5) what are MIBIB, QCSBL, OEMSBL, AMSS, EFS2, NVBACKUP, APPSBL, PARAM, FOTA partitions ?
Click to expand...
Click to collapse
Way above my paygrade!!
6) why the kernel has a gziped part in it ?
Click to expand...
Click to collapse
See 5
Great !!
thank you Akath19 for your contribution....
I want to continue this discussion with details on some topics...if you or someone else is able to contribute.
-------------------------------------------------------------------------
1.a) why some apk copied in /system/app/ does not work ? they do not appere in the apps list ...
A : Some system apks don't have a registered activity (meaning they don't have a UI), so they won't appear in your launcher, also (and take this with a grain of salt), I've personally found that some of the apks placed in /system/app/ need to be installed too.
Click to expand...
Click to collapse
1.b) why some apk removed from /system/app/ cannot be installed after the delete ?
A: Dunno about this one, but I'd dare say that it has something to do with the extra files that are placed in other folders, What apps have you had this problem with?, maybe we can find out why they have that behavior
Click to expand...
Click to collapse
In /system/apps i find some different kind of apps...
- those without icon, not appearing in the 'GUI' - (the app folder in launche) - i call them of 'system type' and i do not touch them.
- apps with icon, implementing important functions - gallery, phone, launcher, etc...
- Google Apps
- some other samsung/provider apps
- some 'generic' app - Analog clock, Dual clock, some widget... (i think they are inserted as demo of capabilities)
Many of those apps have related .odex file.
REMOVING Apps - and restore them
I removed the apps that i do not need - and backup the on my sdcard.
If i want to restore them, i can adb push them a their previus place, and this is the only method for odexed ones.
As alternative to reinstall i tried to do 'normal' install for the apps without .odex ... this also mean that they will be installed in /data/apps,
and they are moved from system STL12 to data STL13 - different partitions, with impact on free space)
This doesn't work for many of the apps - ??
ADDING Apps
I want to add some apps - in order to find them installed after a wipe.
This works with some apps, doesnot with others... some apps (TitaniumBackup) generate a force close on power on...
I suppose that apps in system/apps have to be differrent from those in /data/apps...
-------------------------------------------------------------------------
2) where in ROMS are stored the set up of the Launcher ? i.e. the widget and icons appearing after a wipe ?
A: If they're not wiped they have to be either in the system partition or in the SD
Click to expand...
Click to collapse
They do are wiped... so the infos are written in /data/data/(somefolder)...
But the preloade info - those appearing after a wipe - where are they ?
I suppose that a wipe completely erase /data and not preload its contents...or a part of /data is restored after a wipe ? how ??
-------------------------------------------------------------------------
3) why bloatware removed from /system are present in the dumped BML12 ? where the 'they are removed' inormation are stored ?
a: Taken from the link you put on the BML mapping thread:
What you generally see is that BML partitions contain 'static' data (bootloaders, boot / recovery images) and STL partitions contain 'live' filesystem (on android: /system, /data, /cache, /efs, /dbdata). The idea is that things directly on an BML partition don't change very often and wear leveling isn't required. Read/write filesystems however, do benefit from wear leveling and are thus placed on an STL partition.
Click to expand...
Click to collapse
This is the description of 'driver level' to access to the phisical chip...
STL are a layer up the BML, adding a wear leveling services, enabling secure r/w of bits...
I understand that in a BML dump is contained the STL dump.
This does'n explain why the apps i removed are still present in dump
(unless i make a mistake, and dumepd before removing ??)
-------------------------------------------------------------------------
4) how files inside BML13 for /data and BL14 for /cache can be extracted ?
A: You'd have to find out the partition's filesystem, I believe it's a Samsung propietary FS so you're out of luck with that one
Click to expand...
Click to collapse
You are right... unless we find the source of RFS, in order to be compiled for linux, the only way i have to correctly mount, is on my device - that support RFS.
RFS is reported to be FAT compatible, in fact i was able to extract files form BML12 - aftre some editing - with MagicISO. I suppose that this SW read it as a FAT12 partition - or at least, I found a valid FAT12 heder.
This method does'not work with BML13 and BML14, thas seem to have many FAT12 section in it - but each unreadable.
-------------------------------------------------------------------------
... continue in [post 24] - with Doc_cheilvenerdi.org great contribution
No worries man, I'm also really interested in learning and this is a much better way than just downloading and flashing files.
Anyways, on to the discussion:
stepph said:
REMOVING Apps - and restore them
I removed the apps that i do not need - and backup the on my sdcard.
If i want to restore them, i can adb push them a their previus place, and this is the only method for odexed ones.
As alternative to reinstall i tried to do 'normal' install for the apps without .odex ... this also mean that they will be installed in /data/apps,
and they are moved from system STL12 to data STL13 - different partitions, with impact on free space)
This doesn't work for many of the apps - ??
Click to expand...
Click to collapse
Well if the apps are odexed, they won't work (not even if you install them), 'cause you'd need to deodex them first before trying to install them (learned this the hard way while theming my stock Phone.apk)
For the other apps I guess trying on a case by case basis would be the answer, give me a list of the apps that don't work I'll try to figure out why.
stepph said:
ADDING Apps
I want to add some apps - in order to find them installed after a wipe.
This works with some apps, doesnot with others... some apps (TitaniumBackup) generate a force close on power on...
I suppose that apps in system/apps have to be differrent from those in /data/apps...
Click to expand...
Click to collapse
Personally I don't use TB, I think manually saving apks and configs works better, also I've heard numerous horror stories regarding TB.
What I do in order to keep stuff after a wipe is, I make a small CWM flashable zip that has all the info that I want to keep, and I just flash it after wiping.
stepph said:
They do are wiped... so the infos are written in /data/data/(somefolder)...
But the preloade info - those appearing after a wipe - where are they ?
I suppose that a wipe completely erase /data and not preload its contents...or a part of /data is restored after a wipe ? how ??
stepph said:
I don't exactly know if this is true but I'd dare say some settings are saved inside the apk itself, so that the user has some "default" settings ready available
Also, no part of /data/ is restored after a wipe.
stepph said:
This is the description of 'driver level' to access to the phisical chip...
STL are a layer up the BML, adding a wear leveling services, enabling secure r/w of bits...
I understand that in a BML dump is contained the STL dump.
This does'n explain why the apps i removed are still present in dump
(unless i make a mistake, and dumepd before removing ??)
Click to expand...
Click to collapse
I guess this question would need someone extremely knowledgeable about the underlying subsystem (someone like Darky), but IMHO the phone must copy the STL contents into BML every certain amount of time or something like that.
stepph said:
You are right... unless we find the source of RFS, in order to be compiled for linux, the only way i have to correctly mount, is on my device - that support RFS.
RFS is reported to be FAT compatible, in fact i was able to extract files form BML12 - aftre some editing - with MagicISO. I suppose that this SW read it as a FAT12 partition - or at least, I found a valid FAT12 heder.
This method does'not work with BML13 and BML14, thas seem to have many FAT12 section in it - but each unreadable.
Click to expand...
Click to collapse
If the partitions have a true RFS FS you could just mount them as a loopback device, that's what I did in order to check the contents of BML5, if there are mutliple partitions I guess you would need to find that start and end of each and split them in order to read them
Click to expand...
Click to collapse
Click to expand...
Click to collapse
This is really what I expected from this 3d !!
Akath19 said:
For the other apps I guess trying on a case by case basis would be the answer, give me a list of the apps that don't work I'll try to figure out why.
Click to expand...
Click to collapse
I'll post the list of the removed apps... but need to wait for it since i'm without phone and - don't ask too much to my memory - i have to re-check the ones loading.
Akath19 said:
What I do in order to keep stuff after a wipe is, I make a small CWM flashable zip that has all the info that I want to keep, and I just flash it after wiping.
Click to expand...
Click to collapse
Good ... else - i do not want to use CWM - i was unable to prepare update.zip for original recovery. This could be another discussion...
Akath19 said:
I don't exactly know if this is true but I'd dare say some settings are saved inside the apk itself, so that the user has some "default" settings ready available
Also, no part of /data/ is restored after a wipe.
Click to expand...
Click to collapse
this is also my guess.
-->> and now the important part... <<---
Akath19 said:
I guess this question would need someone extremely knowledgeable about the underlying subsystem (someone like Darky), but IMHO the phone must copy the STL contents into BML every certain amount of time or something like that.
If the partitions have a true RFS FS you could just mount them as a loopback device, that's what I did in order to check the contents of BML5, if there are mutliple partitions I guess you would need to find that start and end of each and split them in order to read them
Click to expand...
Click to collapse
I tried mounting with loopback - my experiments are slowly migrating to linux - but it works only for STL12 /system. It doesn't work for others, nor splitted parts - they result in unreadbles files with unreadable filenames.
Does'n work even with bml5 ... but i probably have a corrupted dump, since after that - by reading STL5 - the phone is gone...
.
Have you gotten your phone back yet stepph, 'cause I'm eager to start tinkering with our phones but I can't do it alone!!
I got it yesterday... with a russian gingerbread FW (who knows where it was downloaded ), but without radio FW, and shutting down every minute...
... The guy of the service was not so able... and he doesn't work with 'official' FW... I have to take the phone back to him - for warranty at least.
I'm tempted to do it by myself - but if EFS is gone ?
Meanwhile, i'm working with androidx86 - a porting for PC - on a virtual machine... it seems great for testing some mods on /system - but kernel, executables, and libraries are recompiled...
And i'm tryng revskill - in order to understand AMSS - the free version seem good... but is limited...
If i get some new results, i'll post it...
(interested in matlab scripts for codig/decoding RLE logos ?)
Download the official Euro FW via checkfusdownloader and flash it through ODIN, those FWs come directly from Samsung servers so you shouldn't have a problem.
I checked out that port but I didn't quite like it (too slow for my taste).
What's revskill (forgive my ignorance)
Meanwhile I'm looking into porting voodoo kernel (from SGS) into our minis, mainly to get better audio support through voodoo sound.
(Ewww, I hate matlab!!)
Akath19 said:
Download the official Euro FW via checkfusdownloader and flash it through ODIN, those FWs come directly from Samsung servers so you shouldn't have a problem.
Click to expand...
Click to collapse
just tried...ODIN reported success, but now the phone does'nt boot anymore...
Hello
Not sure if this is the right place, but I don't think development is the right thread either as I simply need a one time tester and there is already a dev thread for the tool in Optimus Black Forums.
I have developed a tool that extracts LG's bin firmware. I extended it to extract tot files as well. As some of you might know the tot files splits some partitions up into multiple files. I already managed to extract the tot file into their various part, but I have only recently added the ability to merge the parts to it's partition
I don't have enough bandwidth to download one of your firmware files to test it so can someone please test the tool.
Heres the dev thread : link
Heres the git : link
You'll have to compile it with gcc/mingw. The tools name must be BinExtractor(.exe) or it won't remove the first argument (usually the tool path and then it will keep on showing the usage no matter what)
Run it with
Code:
BinExtractor -daph Path/To/Tot/File/firmware.tot
and see if it displays the header info. If that succeeds please test the extraction
Code:
BinExtractor -extract Path/To/Tot/File/firmware.tot
It should prompt you that it detected data blocks with identical names and ask you if you want to merge them. And you want to merge them . After it extracted the files can you please check that the various partitions that it extracted are correct.
To check the system partition mount or extract the system partition in Linux and in Windows use a tool like ext2read to check it.
If it fails with an error please post the results from -daph (and -extract if it happened there) and the first meg of the tot file you used.
If the partitions aren't extracted properly (or merged properly) and -daph succeeded please post just the output from -daph and in what way the output is faulty.
Thanks in advance.
Wow it moved out of page 1 already.
Bump.
It was ignored because the Nexus 4 doesn't use LG .bin files, it uses standard .img files.
Rusty! said:
It was ignored because the Nexus 4 doesn't use LG .bin files, it uses standard .img files.
Click to expand...
Click to collapse
Thanks for responding, but according to this: [Stock] Stock ROMs Collection US/CA/EU/AU
These files are in TOT format
Click to expand...
Click to collapse
And theres a DL link that I presume contains a tot file
LGE960AT-00-V10c-NXS-XX-OCT-25-2012-JVP15Q-USER+0
Click to expand...
Click to collapse
Can you please explain since the info I have atm is a bit contradictory.
Thanks for this xonar. Much appreciated.
Would anyone be able to compile a Windows binary for me and upload it please? Thanks.
Sent from my Nexus 4 using Tapatalk 2
efrant said:
Thanks for this xonar. Much appreciated.
Would anyone be able to compile a Windows binary for me and upload it please? Thanks.
Sent from my Nexus 4 using Tapatalk 2
Click to expand...
Click to collapse
I just compiled it with mingw, but it's not behaving as it's Linux counterpart.
If j is 1024 why isn't the output file 512kB ?!? (Tested with P970 bin)
Code:
for(j = 0; j < tmp.pent_arr[i].file_size; j++)
{
/*DO 512 BLOCK*/
fread(buff, sizeof(char), 512, f);
fwrite(buff, sizeof(char), 512, out);
}
fclose(out);
EDIT: Had a facepalm moment
Windows needs to specify reading and writing in binary. I'll give you exe in a moment.
EDIT2: I attached a zip with the exe inside.
To get it working in Windows I changed read access to binary everywhere theres a fopen and I initialized some thing to 0 as Windows unlike Linux doesn't start you of with a nice clean slate.
I'll push changes to git tomorrow morning to make it work on Windows aswel and from now on I'll actually test the windows exe on windows and not through wine.
Hope it works. I'm going to bed now.
xonar_ said:
I just compiled it with mingw, but it's not behaving as it's Linux counterpart.
If j is 1024 why isn't the output file 512kB ?!? (Tested with P970 bin)
Code:
for(j = 0; j < tmp.pent_arr[i].file_size; j++)
{
/*DO 512 BLOCK*/
fread(buff, sizeof(char), 512, f);
fwrite(buff, sizeof(char), 512, out);
}
fclose(out);
EDIT: Had a facepalm moment
Windows needs to specify reading and writing in binary. I'll give you exe in a moment.
EDIT2: I attached a zip with the exe inside.
To get it working in Windows I changed read access to binary everywhere theres a fopen and I initialized some thing to 0 as Windows unlike Linux doesn't start you of with a nice clean slate.
I'll push changes to git tomorrow morning to make it work on Windows aswel and from now on I'll actually test the windows exe on windows and not through wine.
Hope it works. I'm going to bed now.
Click to expand...
Click to collapse
Thanks so much. I'll try to give it a shot tomorrow. If it doesn't work, I guess I could always use cygwin.
Sent from my Nexus 4 using Tapatalk 2
Doesn't seem to work on Bell Optimus G:
Code:
BinExtractor.exe -extract "LGE973AT-00-V10f-BELL-CA-OCT-24-2012+0.tot"
Reading AP Header...
Unknown Magic Number at 0x8 : AF 33 BF DE
Writing Files...
Finished
Running the info command:
GPT HEADER
----------
Signature 45 46 49 20 50 41 52 54
Revision 65536
Header Size 92
CRC32 of Header B2 64 10 F5
Current Header LBA 1
Backup Header LBA 61071359
First Usable LBA 34
Last Usable LBA 61071326
Disk GUID 32 1B 10 98 E2 BB F2 4B A0 6E 2B B3 3D 00 0C 20
Start of Partition Entries 2
Number of Partition Entries 36
Size of Partition Entries 128
CRC32 of Partition Array 71 79 32 B7
PARTITION ENTRIES
-----------------
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 7B 6F 3E CF 28 B7 86 F3 6A AE 46 69 B1 BC 9A 08
First LBA 16384
Last LBA 147455
Attributes 8
Partition Name modem
PARTITION ENTRY
---------------
Partition Type GUID 2C BA A0 DE DD CB 05 48 B4 F9 F4 28 25 1C 3E 98
Unique Partition GUID BC D0 5B BC 05 A5 44 30 8E 88 59 5C 87 19 A1 08
First LBA 147456
Last LBA 148479
Attributes 0
Partition Name sbl1
PARTITION ENTRY
---------------
....
zivan56 said:
Doesn't seem to work on Bell Optimus G:
Code:
Unknown Magic Number at 0x8 : AF 33 BF DE
Click to expand...
Click to collapse
The tool doesn't support Bell OG yet. I made a guess at what the format could be but I can't say for certain that it will work. I'll push changes in a moment.
Someone tested it on another OG firmware, but it fails to mount the image with:
Code:
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Code:
EXT4-fs (loop0): bad geometry: block count 389120 exceeds size of device (360576 blocks)
Click to expand...
Click to collapse
Can anyone give me the output from -dgpt with at&t OG or sprint OG?
or the first meg of the tot file of Nexus 4 or Bell OG along with -dgpt output?
EDIT: If possible use pastebin to display dgpt output as it might be fairly long.
I known what the problem is. Great thanks to SnowLeopardJB for testing and correspondence
The file that was being created doesn't have 'space' up until the end of the partitions. (It was left out since thats where it stops in the file) but on the actual disk still has 'space' after the last bit of data.
So it can be fixed with
Code:
#VAL is the value that is supposedly outside the device from the err msg
VAL=389120
#This will say already that size, but the file itself will change size
resize2fs system.img $VAL
#Not sure if this last step is then necessary
fsck.ext4 -f system.img
#Now you can mount is as any other partition :laugh:
I'll make the program add the 'space' and see if it produces a immediately mountable file.
I also totally changed the way it handles 44 DD 55 AA files for future flexibility and it's a step closer to being able to make it use predefined files as formats.
The latest version in git seems to extract the Bell Optimus G firmware properly now. I tried mounting the resulting radio image section and it worked fine, so I assume it knows the proper partition boundaries now.
Btw, I would recommend posting some instructions how to compile it. Not everyone is savvy enough to know how to use gcc.
Likewise, your program is hardcoded to look for its name when looking for parameters. Since there was no makefile it defaulted to a.out, which, the way it is coded, would never accept any parameters unless renamed to LGBinExtractor.
zivan56 said:
The latest version in git seems to extract the Bell Optimus G firmware properly now. I tried mounting the resulting radio image section and it worked fine, so I assume it knows the proper partition boundaries now.
Click to expand...
Click to collapse
Only merged partitions was affected by 'space' bug, plain extraction should have been correct for Bell OB after bb697c27e5. I haven't commited 'space' fix yet.
In retrospect using fseek to create 'space' between image parts might not have been such a good idea either and might also be causing problems.
zivan56 said:
Btw, I would recommend posting some instructions how to compile it. Not everyone is savvy enough to know how to use gcc.
Click to expand...
Click to collapse
Adding a makefile is on my todo list.
zivan56 said:
Likewise, your program is hardcoded to look for its name when looking for parameters. Since there was no makefile it defaulted to a.out, which, the way it is coded, would never accept any parameters unless renamed to LGBinExtractor.
Click to expand...
Click to collapse
Yea, not one of my better choices. I changed it to remove the first arg if it doesn't start with '-'.
Okay Merging partitions should work now. I'm waiting for confirmation then I'll ask mod to close the thread.
xonar_ said:
Okay Merging partitions should work now. I'm waiting for confirmation then I'll ask mod to close the thread.
Click to expand...
Click to collapse
Hello i'm try test with LG Optimus tag working:laugh:
Code:
AP HEADER
----------
Magic Number 44 DD 55 AA
Number of Partitions 32
PARTITION ENTRIES
-----------------
PARTITION ENTRY
------------
Data Block Name MODEM
Data Block ID 1
Size on File 47104
File Offset 0
Size on Disk 65537
Disk Offset 0
PARTITION ENTRY
------------
Data Block Name SBL1
Data Block ID 2
Size on File 1024
File Offset 47104
Size on Disk 2048
Disk Offset 65537
PARTITION ENTRY
------------
Data Block Name SBL2
Data Block ID 3
Size on File 1024
File Offset 48128
Size on Disk 2048
Disk Offset 67585
PARTITION ENTRY
------------
Data Block Name EXT
Data Block ID 4
Size on File 1024
File Offset 49152
Size on Disk 12287
Disk Offset 69633
PARTITION ENTRY
------------
Data Block Name RPM
Data Block ID 5
Size on File 1024
File Offset 50176
Size on Disk 16384
Disk Offset 81920
PARTITION ENTRY
------------
Data Block Name SBL3
Data Block ID 6
Size on File 2048
File Offset 51200
Size on Disk 16384
Disk Offset 98304
PARTITION ENTRY
------------
Data Block Name ABOOT
Data Block ID 7
Size on File 2048
File Offset 53248
Size on Disk 16384
Disk Offset 114688
PARTITION ENTRY
------------
Data Block Name BOOT
Data Block ID 8
Size on File 15360
File Offset 55296
Size on Disk 32768
Disk Offset 131072
PARTITION ENTRY
------------
Data Block Name TZ
Data Block ID 9
Size on File 1024
File Offset 70656
Size on Disk 16384
Disk Offset 163840
PARTITION ENTRY
------------
Data Block Name MODEM_ST1
Data Block ID 10
Size on File 0
File Offset 71680
Size on Disk 16384
Disk Offset 180224
PARTITION ENTRY
------------
Data Block Name MODEM_ST2
Data Block ID 11
Size on File 0
File Offset 71680
Size on Disk 16384
Disk Offset 196608
PARTITION ENTRY
------------
Data Block Name PERSIST
Data Block ID 12
Size on File 16384
File Offset 71680
Size on Disk 16384
Disk Offset 212992
PARTITION ENTRY
------------
Data Block Name RECOVERY
Data Block ID 13
Size on File 17408
File Offset 88064
Size on Disk 32768
Disk Offset 229376
PARTITION ENTRY
------------
Data Block Name MDM
Data Block ID 14
Size on File 57344
File Offset 105472
Size on Disk 65536
Disk Offset 262144
PARTITION ENTRY
------------
Data Block Name M9K_EFS1
Data Block ID 15
Size on File 0
File Offset 162816
Size on Disk 16384
Disk Offset 327680
PARTITION ENTRY
------------
Data Block Name M9K_EFS2
Data Block ID 16
Size on File 0
File Offset 162816
Size on Disk 16384
Disk Offset 344064
PARTITION ENTRY
------------
Data Block Name M9K_EFS3
Data Block ID 17
Size on File 0
File Offset 162816
Size on Disk 16384
Disk Offset 360448
PARTITION ENTRY
------------
Data Block Name FSG
Data Block ID 18
Size on File 0
File Offset 162816
Size on Disk 16384
Disk Offset 376832
PARTITION ENTRY
------------
Data Block Name SSD
Data Block ID 19
Size on File 0
File Offset 162816
Size on Disk 32768
Disk Offset 393216
PARTITION ENTRY
------------
Data Block Name BSP
Data Block ID 20
Size on File 0
File Offset 162816
Size on Disk 16384
Disk Offset 425984
PARTITION ENTRY
------------
Data Block Name BLB
Data Block ID 21
Size on File 0
File Offset 162816
Size on Disk 32768
Disk Offset 442368
PARTITION ENTRY
------------
Data Block Name TOMBSTONES
Data Block ID 22
Size on File 1024
File Offset 162816
Size on Disk 147456
Disk Offset 475136
PARTITION ENTRY
------------
Data Block Name DRM
Data Block ID 23
Size on File 0
File Offset 163840
Size on Disk 16384
Disk Offset 622592
PARTITION ENTRY
------------
Data Block Name FOTA
Data Block ID 24
Size on File 0
File Offset 163840
Size on Disk 49152
Disk Offset 638976
PARTITION ENTRY
------------
Data Block Name MISC
Data Block ID 25
Size on File 0
File Offset 163840
Size on Disk 16384
Disk Offset 688128
PARTITION ENTRY
------------
Data Block Name TZ_BKP
Data Block ID 26
Size on File 0
File Offset 163840
Size on Disk 16384
Disk Offset 704512
PARTITION ENTRY
------------
Data Block Name SYSTEM
Data Block ID 27
Size on File 1720320
File Offset 163840
Size on Disk 1720320
Disk Offset 720896
PARTITION ENTRY
------------
Data Block Name CACHE
Data Block ID 28
Size on File 0
File Offset 1884160
Size on Disk 655360
Disk Offset 2441216
PARTITION ENTRY
------------
Data Block Name WALLPAPER
Data Block ID 29
Size on File 0
File Offset 1884160
Size on Disk 16384
Disk Offset 3096576
PARTITION ENTRY
------------
Data Block Name USERDATA
Data Block ID 30
Size on File 0
File Offset 1884160
Size on Disk 4587520
Disk Offset 3112960
PARTITION ENTRY
------------
Data Block Name MPT
Data Block ID 31
Size on File 0
File Offset 1884160
Size on Disk 32768
Disk Offset 7700480
PARTITION ENTRY
------------
Data Block Name GROW
Data Block ID 32
Size on File 20480
File Offset 1884160
Size on Disk 21000000
Disk Offset 7733248
Code:
Reading AP Header...
Writing Files...
Writing File : 1-MODEM.img -- DONE --
Writing File : 2-SBL1.img -- DONE --
Writing File : 3-SBL2.img -- DONE --
Writing File : 4-EXT.img -- DONE --
Writing File : 5-RPM.img -- DONE --
Writing File : 6-SBL3.img -- DONE --
Writing File : 7-ABOOT.img -- DONE --
Writing File : 8-BOOT.img -- DONE --
Writing File : 9-TZ.img -- DONE --
Writing File : 10-MODEM_ST1.img -- DONE --
Writing File : 11-MODEM_ST2.img -- DONE --
Writing File : 12-PERSIST.img -- DONE --
Writing File : 13-RECOVERY.img -- DONE --
Writing File : 14-MDM.img -- DONE --
Writing File : 15-M9K_EFS1.img -- DONE --
Writing File : 16-M9K_EFS2.img -- DONE --
Writing File : 17-M9K_EFS3.img -- DONE --
Writing File : 18-FSG.img -- DONE --
Writing File : 19-SSD.img -- DONE --
Writing File : 20-BSP.img -- DONE --
Writing File : 21-BLB.img -- DONE --
Writing File : 22-TOMBSTONES.img -- DONE --
Writing File : 23-DRM.img -- DONE --
Writing File : 24-FOTA.img -- DONE --
Writing File : 25-MISC.img -- DONE --
Writing File : 26-TZ_BKP.img -- DONE --
Writing File : 27-SYSTEM.img -- DONE --
Writing File : 28-CACHE.img -- DONE --
Writing File : 29-WALLPAPER.img -- DONE --
Writing File : 30-USERDATA.img -- DONE --
Writing File : 31-MPT.img -- DONE --
Writing File : 32-GROW.img -- DONE --
Finished
PS : @xonar_ If you need any flash file LG pm me i have all files LG
---------- Post added at 01:25 AM ---------- Previous post was at 12:25 AM ----------
LG Optimus LTE2 F160 working
Code:
GPT HEADER
----------
Signature 45 46 49 20 50 41 52 54
Revision 65536
Header Size 92
CRC32 of Header 93 23 A2 52
Current Header LBA 1
Backup Header LBA 30535679
First Usable LBA 34
Last Usable LBA 30535646
Disk GUID 32 1B 10 98 E2 BB F2 4B A0 6E 2B B3 3D 00 0C 20
Start of Partition Entries 2
Number of Partition Entries 32
Size of Partition Entries 128
CRC32 of Partition Array 2A A9 B7 BD
PARTITION ENTRIES
-----------------
PARTITION ENTRY
---------------
Partition Type GUID A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7
Unique Partition GUID 72 05 1F 0E 0C 89 89 B5 F4 D4 0E 5D 04 65 52 1E
First LBA 16384
Last LBA 147455
Attributes 8
Partition Name modem
PARTITION ENTRY
---------------
Partition Type GUID 2C BA A0 DE DD CB 05 48 B4 F9 F4 28 25 1C 3E 98
Unique Partition GUID 9A 00 DF 9C DE F9 95 65 62 3C 0F 15 D6 1A 75 6B
First LBA 147456
Last LBA 148479
Attributes 0
Partition Name sbl1
PARTITION ENTRY
---------------
Partition Type GUID AD 52 6B 8C 9E 8A 98 43 AD 09 AE 91 6E 53 AE 2D
Unique Partition GUID F1 EC 20 B2 C4 FA 8B FC 06 D2 4F 33 72 B6 0F D2
First LBA 148480
Last LBA 149503
Attributes 0
Partition Name sbl2
PARTITION ENTRY
---------------
Partition Type GUID DF 44 E0 05 F1 92 25 43 B6 9E 37 4A 82 E9 7D 6E
Unique Partition GUID A8 87 F8 53 B8 47 22 FA A9 2B 91 26 94 F6 19 2B
First LBA 149504
Last LBA 151551
Attributes 0
Partition Name sbl3
PARTITION ENTRY
---------------
Partition Type GUID CD FD 0F 40 E0 22 E7 47 9A 23 F1 6E D9 38 23 88
Unique Partition GUID 2A D1 EA 8A 29 76 F5 14 50 CD FA D5 2D 9F 41 26
First LBA 151552
Last LBA 152575
Attributes 0
Partition Name aboot
PARTITION ENTRY
---------------
Partition Type GUID 93 F7 8D 09 12 D7 3D 41 9D 4E 89 D7 11 77 22 28
Unique Partition GUID F7 5A 4B 53 B7 53 FB FF 4C F1 26 3A AD 9D C9 12
First LBA 152576
Last LBA 153599
Attributes 0
Partition Name rpm
PARTITION ENTRY
---------------
Partition Type GUID 86 7F 11 20 85 E9 57 43 B9 EE 37 4B C1 D8 48 7D
Unique Partition GUID 7A C9 D2 E5 B5 2A 04 6C BE 24 C7 AE 35 55 01 B2
First LBA 163840
Last LBA 188415
Attributes 8
Partition Name boot
PARTITION ENTRY
---------------
Partition Type GUID 7F AA 53 A0 B8 40 1C 4B BA 08 2F 68 AC 71 A4 F4
Unique Partition GUID F9 09 61 B9 4F 99 AF 89 FF C3 F3 16 99 B0 E3 A9
First LBA 196608
Last LBA 197631
Attributes 0
Partition Name tz
PARTITION ENTRY
---------------
Partition Type GUID 38 68 4A 00 2A 06 DF 44 81 52 4F 34 0C 05 22 5D
Unique Partition GUID BC 83 9C AC D5 BF F4 36 1C 0F D4 63 6F AD 23 07
First LBA 197632
Last LBA 197633
Attributes 0
Partition Name pad
PARTITION ENTRY
---------------
Partition Type GUID 3E 37 13 20 C4 1A 31 41 B0 F8 91 58 F9 65 4F 4F
Unique Partition GUID 46 F4 88 C2 2C 7A 4A AD 17 28 DD 70 10 8B BD AD
First LBA 197634
Last LBA 203777
Attributes 0
Partition Name modemst1
PARTITION ENTRY
---------------
Partition Type GUID 3E 37 13 20 C4 1A 31 41 B0 F8 91 58 F9 65 4F 4F
Unique Partition GUID 0A E8 2B 7F B8 CF 52 3E C2 7E 52 26 3E 03 B5 35
First LBA 203778
Last LBA 209921
Attributes 0
Partition Name modemst2
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID 85 78 29 24 17 62 3D 36 A4 4B E9 47 10 87 AD 67
First LBA 212992
Last LBA 229375
Attributes 8
Partition Name sns
PARTITION ENTRY
---------------
Partition Type GUID 54 05 D3 6C 5D 5F EF 40 82 FE 10 92 35 9F 92 EE
Unique Partition GUID DC BF D4 C1 2E 63 5D 16 3F 45 88 4F 2A 36 86 3C
First LBA 229376
Last LBA 262143
Attributes 0
Partition Name misc
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID 8E C6 02 A3 3F DC 79 98 12 7F 02 BE 38 F7 D4 6B
First LBA 262144
Last LBA 2359295
Attributes 8
Partition Name system
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID E2 F2 D0 8D 3E D2 D0 90 E9 45 09 EA 7E 8F 2C 97
First LBA 2359296
Last LBA 29589503
Attributes 8
Partition Name userdata
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID F7 2D 03 28 16 E8 78 07 D0 84 1B 08 6F 5B 6D 39
First LBA 29589504
Last LBA 29605887
Attributes 8
Partition Name persist
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID 21 6C AF DC 30 3D D9 D9 3F AE 56 42 4C 0F 66 AC
First LBA 29605888
Last LBA 30146559
Attributes 8
Partition Name cache
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID 26 4F D8 D1 AC 24 CC CA EA 7F E1 F0 E5 6C FD 61
First LBA 30146560
Last LBA 30294015
Attributes 0
Partition Name tombstones
PARTITION ENTRY
---------------
Partition Type GUID 86 7F 11 20 85 E9 57 43 B9 EE 37 4B C1 D8 48 7D
Unique Partition GUID BB 74 76 DD 1D 6B 07 56 23 FB 94 96 7A 52 0A DC
First LBA 30294016
Last LBA 30318591
Attributes 8
Partition Name recovery
PARTITION ENTRY
---------------
Partition Type GUID 3E 37 13 20 C4 1A 31 41 B0 F8 91 58 F9 65 4F 4F
Unique Partition GUID 7C 48 3D 02 F0 90 E3 39 F7 14 BA D1 D9 BD 76 C8
First LBA 30318592
Last LBA 30324735
Attributes 8
Partition Name fsg
PARTITION ENTRY
---------------
Partition Type GUID 42 E7 86 2C 5E 74 DD 4F BF D8 B6 A7 AC 63 87 72
Unique Partition GUID 9B 2F 13 2B 51 11 1E C2 30 66 A0 E7 08 BC BF DF
First LBA 30324736
Last LBA 30324751
Attributes 8
Partition Name ssd
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID 75 44 C3 7D E2 05 C3 88 22 1B 8A 2D D1 D9 E4 FA
First LBA 30326784
Last LBA 30343167
Attributes 0
Partition Name drm
PARTITION ENTRY
---------------
Partition Type GUID AC 9C 14 00 9B ED 01 48 9A E9 6D F9 60 3A 18 27
Unique Partition GUID 55 D9 D2 33 14 1A 58 56 F8 47 15 23 E1 B9 A4 07
First LBA 30343168
Last LBA 30408703
Attributes 0
Partition Name fota
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID 38 9D 3B B9 01 35 EA F7 BA 61 44 35 4F AE 2C 73
First LBA 30408704
Last LBA 30474239
Attributes 0
Partition Name mpt
PARTITION ENTRY
---------------
Partition Type GUID BB 51 9C 73 F9 7A 0A 45 88 49 FF 4F 3D 94 CC AF
Unique Partition GUID EB 58 E9 92 44 82 6E A3 9C 07 F8 60 1D 46 AB 8E
First LBA 30474240
Last LBA 30475263
Attributes 0
Partition Name tzbak
PARTITION ENTRY
---------------
Partition Type GUID 11 84 CC 6A A5 68 18 41 BA B0 07 FA 12 72 B4 9B
Unique Partition GUID 8C 02 6E 7C 87 46 63 0D 71 93 68 7C 2A 4A D8 73
First LBA 30475264
Last LBA 30476287
Attributes 0
Partition Name rpmbak
PARTITION ENTRY
---------------
Partition Type GUID 95 F5 3E 32 7A AF FA 4A 80 60 97 BE 72 84 1B B9
Unique Partition GUID 47 79 8A 0B 52 C4 79 9B 2A 90 81 4E FC A8 E0 77
First LBA 30476288
Last LBA 30477311
Attributes 0
Partition Name encrypt
PARTITION ENTRY
---------------
Partition Type GUID 73 75 D2 A7 3C A5 E7 4C 87 BC 4D 35 12 FF C8 64
Unique Partition GUID 96 9C 90 E9 54 25 10 09 5A B6 CB 7E D3 1E 79 1D
First LBA 30490624
Last LBA 30523391
Attributes 8
Partition Name reserved
PARTITION ENTRY
---------------
Partition Type GUID AF 3D C6 0F 83 84 72 47 8E 79 3D 69 D8 47 7D E4
Unique Partition GUID 88 8D 1A E1 EF BF 80 A7 58 89 13 B3 AF AD 5E A3
First LBA 30523392
Last LBA 30535646
Attributes 0
Partition Name grow
Q:\LG\LG-F160L>
Not work on my G
it forceclose when i try to use -daph
KhmerHacker said:
it forceclose when i try to use -daph
Click to expand...
Click to collapse
What firmware did you try it on?
Succes with your tools
Thanks xonar. with your tools, I successed with Optimus Vu F100L rom: F100L29j_00.kdz. But the tools ext2read you metioned cannot see the ext4 26-SYSTEM.img, but I mount in linux and get the right result as below
mkdir
mount -t ext4 -o loop 26-SYSTEM.img /tmp
thanks very, a question:
after I make change to the img file, how can I repacked the img to tot file? need a change the wdb dll wdh file also?
anyone can give help is wellcome.
flyhigher76 said:
Thanks xonar. with your tools, I successed with Optimus Vu F100L rom: F100L29j_00.kdz. But the tools ext2read you metioned cannot see the ext4 26-SYSTEM.img, but I mount in linux and get the right result as below
mkdir
mount -t ext4 -o loop 26-SYSTEM.img /tmp
Click to expand...
Click to collapse
Not sure why ext2read don't work
,but if it works in Linux it should be correct.
flyhigher76 said:
thanks very, a question:
after I make change to the img file, how can I repacked the img to tot file? need a change the wdb dll wdh file also?
anyone can give help is wellcome.
Click to expand...
Click to collapse
It's possible to recreate the tot file from the extracted partitions,but a mistake can make your phone Hard Bricked. I wouldn't recommend doing that.
change Optimus Vu Languge
xonar_ said:
Not sure why ext2read don't work
,but if it works in Linux it should be correct.
It's possible to recreate the tot file from the extracted partitions,but a mistake can make your phone Hard Bricked. I wouldn't recommend doing that.
Click to expand...
Click to collapse
I like the Optimus Vu very much, fot it's unique size and it's first-class panel display attract me. But unfortunately, it is not in Chinese, also when I make a call I must choose to call local or call Korea. I'm tired of this, so I want to have a custom system for my own. The difficult is that I cannot get control the /system for root fails many times, so I cannot change any apk and jar in /system. I hope I can modify the rom as I have do with galaxy note, and forturely find this thread.
I know tot format file since I own this optimus Vu, so I have no idea about this format. Can you give me some information about this format, like some website?
vmt.
flyhigher76 said:
I know tot format file since I own this optimus Vu, so I have no idea about this format. Can you give me some information about this format, like some website?
vmt.
Click to expand...
Click to collapse
Theres the source code of my tool.
I had search lot of thread which write "busybox dd if=/system/framework/xxxx.odex of=/data/local/tmp/odex/xxx.odex bs=1 count=20 skip=52 seek=52 conv=notrunc".according to http://source.android.com document(odex/dex format), signature don't start at 0x34!
why?how to calculate is 52bytes(0x34)?THX
according to dex/odex format( http://source.android.com ),signature should start at 0x0c,not 0x34.so skip=52 seek=52 should skip = 12 seek= 12.But in lots of thread write 52 bytes,so i dont understand.
quywz said:
I had search lot of thread which write "busybox dd if=/system/framework/xxxx.odex of=/data/local/tmp/odex/xxx.odex bs=1 count=20 skip=52 seek=52 conv=notrunc".according to http://source.android.com document(odex/dex format), signature don't start at 0x34!
why?how to calculate is 52bytes(0x34)?THX
Click to expand...
Click to collapse
Did I understand you right that you want to know how 0x34 can be 52? Well, it's a hexadecimal number. Strike the '0x'(not part of the number) out and you have '34'. Hexadecimal is base 16, so it's:
4*16^0=4 and 3*16^1=48, together it makes 52.
dark_knight35 said:
Did I understand you right that you want to know how 0x34 can be 52? Well, it's a hexadecimal number. Strike the '0x'(not part of the number) out and you have '34'. Hexadecimal is base 16, so it's:
4*16^0=4 and 3*16^1=48, together it makes 52.
Click to expand...
Click to collapse
NO,according to dex/odex format( http://source.android.com ),signature should start at 0x0c,not 0x34.so skip=52 seek=52 should skip = 12 seek= 12.But in lots of thread write 52 bytes,so i dont understand.
quywz said:
I had search lot of thread which write "busybox dd if=/system/framework/xxxx.odex of=/data/local/tmp/odex/xxx.odex bs=1 count=20 skip=52 seek=52 conv=notrunc".according to http://source.android.com document(odex/dex format), signature don't start at 0x34!
why?how to calculate is 52bytes(0x34)?THX
according to dex/odex format( http://source.android.com ),signature should start at 0x0c,not 0x34.so skip=52 seek=52 should skip = 12 seek= 12.But in lots of thread write 52 bytes,so i dont understand.
Click to expand...
Click to collapse
Indeed, this is an interesting question. With the 8 "magic" bytes and the 4 bytes of the checksum, the signature should begin at 12 (0x0c), not 52.
Maybe this is related to the .odex format. I was only able to find documentation for the .dex format, and maybe the optimization process adds 40 bytes at the beginning of the file. I'll try to look into the source code, but if someone has the answer, I'll be glad to hear it as well.
EDIT : Found in libdex/DexFile.h
Code:
/*
* Header added by DEX optimization pass. Values are always written in
* local byte and structure padding. The first field (magic + version)
* is guaranteed to be present and directly readable for all expected
* compiler configurations; the rest is version-dependent.
*
* Try to keep this simple and fixed-size.
*/
struct DexOptHeader {
u1 magic[8]; /* includes version number */
u4 dexOffset; /* file offset of DEX header */
u4 dexLength;
u4 depsOffset; /* offset of optimized DEX dependency table */
u4 depsLength;
u4 optOffset; /* file offset of optimized data tables */
u4 optLength;
u4 flags; /* some info flags */
u4 checksum; /* adler32 checksum covering deps/opt */
/* pad for 64-bit alignment if necessary */
};
This additional header for optimized .dex files (.odex) is indeed 40 bytes-long.
Einril said:
Indeed, this is an interesting question. With the 8 "magic" bytes and the 4 bytes of the checksum, the signature should begin at 12 (0x0c), not 52.
Maybe this is related to the .odex format. I was only able to find documentation for the .dex format, and maybe the optimization process adds 40 bytes at the beginning of the file. I'll try to look into the source code, but if someone has the answer, I'll be glad to hear it as well.
EDIT : Found in libdex/DexFile.h
Code:
/*
* Header added by DEX optimization pass. Values are always written in
* local byte and structure padding. The first field (magic + version)
* is guaranteed to be present and directly readable for all expected
* compiler configurations; the rest is version-dependent.
*
* Try to keep this simple and fixed-size.
*/
struct DexOptHeader {
u1 magic[8]; /* includes version number */
u4 dexOffset; /* file offset of DEX header */
u4 dexLength;
u4 depsOffset; /* offset of optimized DEX dependency table */
u4 depsLength;
u4 optOffset; /* file offset of optimized data tables */
u4 optLength;
u4 flags; /* some info flags */
u4 checksum; /* adler32 checksum covering deps/opt */
/* pad for 64-bit alignment if necessary */
};
This additional header for optimized .dex files (.odex) is indeed 40 bytes-long.
Click to expand...
Click to collapse
struct DexOptHeader is 40 bytes-long,but already include magic + checksum.pls look at dexOffset which is file offset of DEX header and depsOffset which is offset of optimized DEX dependency table.so, maybe the pos of signature is magic + checksum +dexOffset +depsOffset.right?
maybe the dexOffset and depsOffset are according to device models have different value.
I copy aheader 40 bytes from classes.dex(836KB).
Code:
64 65 78 0a 30 33 35 00 a1 f6 7a 1b e6 a3 fb 35
5b d5 66 72 b8 33 36 3a 40 a1 4b ea 40 2f d3 fc
58 0e 0d 00 70 00 00 00
but In Dalvik Executable Format document,dex header is 112 bytes.
according to struct DexOptHeader, checksum = 0x70.dexOffset is so large!depsOffset is large too!
DexOptHeader seem unused.
I copy aheader 40 bytes from classes.dex(836KB).
Code:
64 65 78 0a 30 33 35 00 a1 f6 7a 1b e6 a3 fb 35
5b d5 66 72 b8 33 36 3a 40 a1 4b ea 40 2f d3 fc
58 0e 0d 00 70 00 00 00
but In Dalvik Executable Format document,dex header is 112 bytes.
according to struct DexOptHeader, checksum = 0x70.dexOffset is so large!depsOffset is large too!
DexOptHeader seem unused.
quywz said:
I copy aheader 40 bytes from classes.dex(836KB).
Code:
64 65 78 0a 30 33 35 00 a1 f6 7a 1b e6 a3 fb 35
5b d5 66 72 b8 33 36 3a 40 a1 4b ea 40 2f d3 fc
58 0e 0d 00 70 00 00 00
but In Dalvik Executable Format document,dex header is 112 bytes.
according to struct DexOptHeader, checksum = 0x70.dexOffset is so large!depsOffset is large too!
DexOptHeader seem unused.
Click to expand...
Click to collapse
Actually, you're looking at a .dex file header, not a .odex file header, so I'm not sure what you're looking for. Here there is no dexOffset, nor depsOffset, and the checksum is "a1 f6 7a 1b".
For the magic bytes + checksum, maybe these are redundant, and the optimization process only add a 40 bytes header without altering the old one.
To be sure, we would need to look into a .odex file header.
EDIT : Here are the 0x40 first bytes of systemUI.odex
Code:
000000 [B][COLOR="Red"]64 65 79 0A 30 33 36 00[/COLOR][/B] [B][COLOR="YellowGreen"]28[/COLOR][/B] 00 00 00 58 57 09 00
000010 80 57 09 00 C0 02 00 00 40 5A 09 00 38 16 01 00
000020 00 00 00 00 A2 E1 D9 FA [B][COLOR="Red"]64 65 78 0A 30 33 35 00[/COLOR][/B]
000030 E9 5F F1 ED B3 06 98 D7 80 5D 7D EF 63 7B D7 23
000040 5D 79 05 67 EF 1B 35 E7 58 57 09 00 70 00 00 00
We can see that there are indeed two sets of magic bytes, one beginning at 0 (the .odex magic bytes), and one beginning at 40 bytes (the .dex magic bytes).
As a side note, dexOffset is indeed 0x28 (40).
Einril said:
Actually, you're looking at a .dex file header, not a .odex file header, so I'm not sure what you're looking for. Here there is no dexOffset, nor depsOffset, and the checksum is "a1 f6 7a 1b".
For the magic bytes + checksum, maybe these are redundant, and the optimization process only add a 40 bytes header without altering the old one.
To be sure, we would need to look into a .odex file header.
EDIT : Here are the 0x40 first bytes of systemUI.odex
Code:
000000 [B][COLOR="Red"]64 65 79 0A 30 33 36 00[/COLOR][/B] [B][COLOR="YellowGreen"]28[/COLOR][/B] 00 00 00 58 57 09 00
000010 80 57 09 00 C0 02 00 00 40 5A 09 00 38 16 01 00
000020 00 00 00 00 A2 E1 D9 FA [B][COLOR="Red"]64 65 78 0A 30 33 35 00[/COLOR][/B]
000030 E9 5F F1 ED B3 06 98 D7 80 5D 7D EF 63 7B D7 23
000040 5D 79 05 67 EF 1B 35 E7 58 57 09 00 70 00 00 00
We can see that there are indeed two sets of magic bytes, one beginning at 0 (the .odex magic bytes), and one beginning at 40 bytes (the .dex magic bytes).
As a side note, dexOffset is indeed 0x28 (40).
Click to expand...
Click to collapse
right.
thank for your libdex/DexFile.h.
Pls take note of dexOffset is file offset of DEX header.Refer original android.policy.odex,I guess odex header format is DexOptHeader + dex's Header.now,the signature pos is dexOffset + magic(dex's magic) + checksum(dex's checksum).view original android.policy.odex,we will find dexOffset value is 0x28.so signature = 0x28 +0x8 + 0x4=0x34
quywz said:
right.
thank for your libdex/DexFile.h.
Pls take note of dexOffset is file offset of DEX header.Refer original android.policy.odex,I guess odex header format is DexOptHeader + dex's Header.now,the signature pos is dexOffset + magic(dex's magic) + checksum(dex's checksum).view original android.policy.odex,we will find dexOffset value is 0x28.so signature = 0x28 +0x8 + 0x4=0x34
Click to expand...
Click to collapse
Exactly. When optimizing an .dex file, the process adds the DexOptHeader at the beginning of the file. Thus, the resulting header is DexOptHeader + DexHeader (DexHeader beginning at 0x28), and the new position of the signature is 0x34 = 52 bytes
Einril said:
Exactly. When optimizing an .dex file, the process adds the DexOptHeader at the beginning of the file. Thus, the resulting header is DexOptHeader + DexHeader (DexHeader beginning at 0x28), and the new position of the signature is 0x34 = 52 bytes
Click to expand...
Click to collapse
THX.
Next topic.If you have time,pls help http://forum.xda-developers.com/showthread.php?p=41254960#post41254960:)
dark_knight35 said:
Did I understand you right that you want to know how 0x34 can be 52? Well, it's a hexadecimal number. Strike the '0x'(not part of the number) out and you have '34'. Hexadecimal is base 16, so it's:
4*16^0=4 and 3*16^1=48, together it makes 52.
Click to expand...
Click to collapse
If you have time,pls help http://forum.xda-developers.com/show...#post41254960:)
thx.
Hi everyone,
My brother has a Motorola XT1072 (Moto G - 4G LTE 2nd Gen) and he has bricked the device. He was playing with fastboot...
So, currently he has a totally dead phone (can't boot, no LED when charging, etc.)
When I plug the device to my computer, the only thing I see is that it's detected as qhusb_bulk (under windows and before the driver installation) and as Bus 001 Device 014: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode) (under linux with a lsusb).
I finally found a solution to a similar problem : http://forum.xda-developers.com/moto-g/help/how-to-revive-hard-bricked-moto-g-t2833798
So I tried qboot on Linux and Windows, and always failed with the same error : FAILED (blank-flash:greet-device:unexpected packet).
Qboot is detecting my device :
Code:
[[email protected] blankflash]# ./qboot devices
/dev/ttyUSB0 "QCOM emergency download"
But when I try a blank flash, it doesn't work :
Code:
[[email protected] blankflash]# ./qboot blank-flash --debug=2
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
FAILED (blank-flash:greet-device:unexpected packet)
And my qboot.ini :
Code:
# MSM8626
[config 0x801]
programmer=programmer_8626.mbn
singleimage=singleimage_8626.bin
[config 0x805]
programmer=programmer_8926.mbn
singleimage=singleimage_8926.bin
[diag error.0x0001090D]
count=5
message="blank-flash:greet-device:error reading packet"
last-seen="Sat Oct 24 16:48:18 2015, CEST"
first-seen="Sat Oct 24 16:15:24 2015, CEST"
chip=
chip.sn=0x0
chip.id=0x0
chip.rev=0
chip.sv-sbl=0
qboot.version=2.4
hostname=rincevent
[diag blank-flash]
fail=5
pass=0
yield=0.00%
dphu=100.00
Conclusion : qboot is detecting my device but can't flash it. They don't speak the same language :'(
My Goal : Reinstalling Flashboot on my device
Now, I'm only guessing, and will take any advice which could help me.
--> I suppose that I need a newer version of qboot, or at least a newer version of programmer.mbn and singleimage.bin
--> I've found this repository, which aims to ease qboot usage : https://gitlab.com/Negan1911/motoflasher/tree/master/MotoFlasher
There is a repository inside, with many qboot version : https://gitlab.com/Negan1911/motoflasher/tree/master/MotoFlasher/Component
I don't understand what are falcon and ghost, how this guy found this files, etc.
I'm a bit lost, here are some question :
I can't find any other qboot version. Is it a leak ? or community made ?
What are falcon_444, falcon_50, ghost, ... ? What is the code name of my phone ?
How do I know which version of programmer.mbn and singleimage.bin I need ? And what is the number : programmer_8926.mbn; programmer_8626.mbn
Can someone with a XT1072 can rip programmer.mbn and singleimage.bin for me ?
Are programmer.mbn and singleimage.bin are community made ? Or is it a leak ?
Can I use another tool (other than qboot) to communicate with my device (this "QCOM emergency download") ? Is there a specification somewhere to understand how it works ?
Is my previous android version important ? Why ? Fastboot is changing between android version ? I read somewhere that's encrypted, isn't it ?
Could I use a tool like emmc_recover[y] and how ? http://forum.xda-developers.com/showpost.php?p=23566551&postcount=249 or https://github.com/Fuses/emmc_recover
Thanks by advance for your help,
Please be comprehensive if I've forgotten a rule of this board, I'll do my best to correct this post if necessary.
superboum said:
Hi everyone,
My brother has a Motorola XT1072 (Moto G - 4G LTE 2nd Gen) and he has bricked the device. He was playing with fastboot...
So, currently he has a totally dead phone (can't boot, no LED when charging, etc.)
When I plug the device to my computer, the only thing I see is that it's detected as qhusb_bulk (under windows and before the driver installation) and as Bus 001 Device 014: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode) (under linux with a lsusb).
I finally found a solution to a similar problem : http://forum.xda-developers.com/moto-g/help/how-to-revive-hard-bricked-moto-g-t2833798
So I tried qboot on Linux and Windows, and always failed with the same error : FAILED (blank-flash:greet-device:unexpected packet).
Qboot is detecting my device :
Code:
[[email protected] blankflash]# ./qboot devices
/dev/ttyUSB0 "QCOM emergency download"
But when I try a blank flash, it doesn't work :
Code:
[[email protected] blankflash]# ./qboot blank-flash --debug=2
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
I - opening device: /dev/ttyUSB0
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - No data from serial, retrying...
D - No data from serial, retrying...
D - Dumping 16 bytes read
D - 00000000 04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00 |................|
E - Unexpected packet: 4. Was expecting: 1
FAILED (blank-flash:greet-device:unexpected packet)
And my qboot.ini :
Code:
# MSM8626
[config 0x801]
programmer=programmer_8626.mbn
singleimage=singleimage_8626.bin
[config 0x805]
programmer=programmer_8926.mbn
singleimage=singleimage_8926.bin
[diag error.0x0001090D]
count=5
message="blank-flash:greet-device:error reading packet"
last-seen="Sat Oct 24 16:48:18 2015, CEST"
first-seen="Sat Oct 24 16:15:24 2015, CEST"
chip=
chip.sn=0x0
chip.id=0x0
chip.rev=0
chip.sv-sbl=0
qboot.version=2.4
hostname=rincevent
[diag blank-flash]
fail=5
pass=0
yield=0.00%
dphu=100.00
Conclusion : qboot is detecting my device but can't flash it. They don't speak the same language :'(
My Goal : Reinstalling Flashboot on my device
Now, I'm only guessing, and will take any advice which could help me.
--> I suppose that I need a newer version of qboot, or at least a newer version of programmer.mbn and singleimage.bin
--> I've found this repository, which aims to ease qboot usage : https://gitlab.com/Negan1911/motoflasher/tree/master/MotoFlasher
There is a repository inside, with many qboot version : https://gitlab.com/Negan1911/motoflasher/tree/master/MotoFlasher/Component
I don't understand what are falcon and ghost, how this guy found this files, etc.
I'm a bit lost, here are some question :
I can't find any other qboot version. Is it a leak ? or community made ?
What are falcon_444, falcon_50, ghost, ... ? What is the code name of my phone ?
How do I know which version of programmer.mbn and singleimage.bin I need ? And what is the number : programmer_8926.mbn; programmer_8626.mbn
Can someone with a XT1072 can rip programmer.mbn and singleimage.bin for me ?
Are programmer.mbn and singleimage.bin are community made ? Or is it a leak ?
Can I use another tool (other than qboot) to communicate with my device (this "QCOM emergency download") ? Is there a specification somewhere to understand how it works ?
Is my previous android version important ? Why ? Fastboot is changing between android version ? I read somewhere that's encrypted, isn't it ?
Could I use a tool like emmc_recover[y] and how ? http://forum.xda-developers.com/showpost.php?p=23566551&postcount=249 or https://github.com/Fuses/emmc_recover
Thanks by advance for your help,
Please be comprehensive if I've forgotten a rule of this board, I'll do my best to correct this post if necessary.
Click to expand...
Click to collapse
man, you could 'unbrick' your device? if yes, teach me how... i'm facing the same problem ç.ç
Blank-flash not available for LP
Bootflash tools are not available for 41.18 Lollipop bootloaders yet, and I think they will never be because our phones are already in the 6.0 soak test phase. If somehow, the Marshmallow bootflash tools get leaked then maybe you could flash a Marshmallow bootloader to the qhsusb and install a Marshmallow firmware and lesson learned. I think the best thing you can do is leaving the XT1072 in a shelf until bootflash tools get released/leaked someday.
Yeah. Bootflash tools are leaked, from Motorola service centers I think.
Bootflash tools from KitKat won't work on boards that already have the 41.18 low-level anti-downgrade lock.
Moto G phones are good perfomance/price buys, but surprisingly easy to brick. That's why I keep my brand new XT1072 in a stock state (i want to root it and install CM & Viper4Android but don't want to lose my warranty yet so i keep my bootloader locked).
The best think we can do right now is wait for the public release of Marshmallow update.
man i dont think you can flash this normal blankflash in lte version , both of you should give the phone to service centre
---------- Post added at 06:43 PM ---------- Previous post was at 06:41 PM ----------
falcon is codename for dual sim xt1033 moto g 1st gen version phone , yours must be different
[WIP]Dissecting the bootloader aka: get rid of annoying "Your device is corrupt"
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
Code:
> adb shell
# dd if=/dev/block/bootdevice/by-name/abl_b of=/sdcard/img.abl_a
# <ctrl-D>
> adb pull /sdcard/img.abl_a
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
Code:
> binwalk -e img.abl_a
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
4488 0x1188 Certificate in DER format (x509 v3), header length: 4, sequence length: 1279
5771 0x168B Certificate in DER format (x509 v3), header length: 4, sequence length: 1133
6908 0x1AFC Certificate in DER format (x509 v3), header length: 4, sequence length: 1149
12408 0x3078 LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 487624 bytes
I am thinking that bytes 0...4487 is the real bootloader code, so:
Code:
> head --bytes=4488 img.abl_b > abc
> file abc
abc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, corrupted section header size
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
Code:
> readelf abc
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x9fa00000
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NULL 0x000000 0x00000000 0x00000000 0x00094 0x00000 0
NULL 0x001000 0x9fa30000 0x9fa30000 0x01988 0x02000 0x1000
LOAD 0x003000 0x9fa00000 0x9fa00000 0x30000 0x30000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
Elf file type is EXEC (Executable file)
Entry point 0x9fa00000
There are 3 program headers, starting at offset 52
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
foobar66 said:
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
I am thinking that bytes 0...4487 is the real bootloader code, so:
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
Click to expand...
Click to collapse
Wow! Excited to see this! Thanks
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
foobar66 said:
This is WIP (work in progress) ... posting this as a separate thread to get other people involved so we can try to get rid of the annoying "Your device is corrupt" thing.
On the back of my thread on the splash screen (see https://forum.xda-developers.com/oneplus-6t/development/tool-splash-screen-modification-t3874158), @AnoopKumar and I started checking the bootloader.
The bootloader is in the partition called: abl_a (and/or abl_b) depending on whether you boot from A or B slot.
(https://forum.xda-developers.com/showpost.php?p=78409574&postcount=28)
All below is on Linux ... I am not a Windows guru ...
Take a raw dump of the abl_a partition. Reboot into TWRP, once there do: "adb shell".
Code:
> adb shell
# dd if=/dev/block/bootdevice/by-name/abl_b of=/sdcard/img.abl_a
# <ctrl-D>
> adb pull /sdcard/img.abl_a
You will now have the dump of the bootloader partition in the file
Then, use "binwalk" to see what is inside the abl_a image:
Code:
> binwalk -e img.abl_a
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
4488 0x1188 Certificate in DER format (x509 v3), header length: 4, sequence length: 1279
5771 0x168B Certificate in DER format (x509 v3), header length: 4, sequence length: 1133
6908 0x1AFC Certificate in DER format (x509 v3), header length: 4, sequence length: 1149
12408 0x3078 LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 487624 bytes
I am thinking that bytes 0...4487 is the real bootloader code, so:
Code:
> head --bytes=4488 img.abl_b > abc
> file abc
abc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, corrupted section header size
Not sure why it says "corrupt section header size".
Then check the detail of the ELF file:
Code:
> readelf abc
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x9fa00000
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NULL 0x000000 0x00000000 0x00000000 0x00094 0x00000 0
NULL 0x001000 0x9fa30000 0x9fa30000 0x01988 0x02000 0x1000
LOAD 0x003000 0x9fa00000 0x9fa00000 0x30000 0x30000 RWE 0x1000
There is no dynamic section in this file.
There are no relocations in this file.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
Elf file type is EXEC (Executable file)
Entry point 0x9fa00000
There are 3 program headers, starting at offset 52
The bootloader binary code is in the LOAD segment
More to follow later ... have to catch some sleep now ...
Click to expand...
Click to collapse
Good job, if needed i can help with the checking
tech_head said:
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
Click to expand...
Click to collapse
abl.img is not the bootloader i guess.
tech_head said:
It doesn't matter if you find it.
I don't think you can flash a modified BL partition and have the device boot.
This is part of secure boot. The notice will always be there with an unlocked BL.
It's on all devices that have ARM trust zone and secure boot, if they run Android.
This is part of Google's requirements.
Click to expand...
Click to collapse
On other devices they've been able to swap this image with another one to "hide" the message, to "get rid of it".
Would we sweet if we could get rid of the unlocked bootloader message too.
dennisbednarz said:
Would we sweet if we could get rid of the unlocked bootloader message too.
Click to expand...
Click to collapse
+1
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
jacksummers said:
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
Click to expand...
Click to collapse
Different issue.
They are not trying to get rid of the red warning but the yellow warning for an unlocked BL.
On this phone, if you have a "red" warning you use the MSMDownload tool and go back factory including locking the BL.
This is a different case.
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
Code:
> lsusb
Bus 001 Device 034: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
And then:
Code:
> dmesg
[ 9395.999112] usb 1-1: new high-speed USB device number 34 using xhci_hcd
[ 9396.149376] usb 1-1: New USB device found, idVendor=05c6, idProduct=9008
[ 9396.149380] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9396.149383] usb 1-1: Product: QUSB_BULK_CID:0402_SN:33B9DDAC
[ 9396.149386] usb 1-1: Manufacturer: Qualcomm CDMA Technologies MSM
[ 9396.150184] qcserial 1-1:1.0: Qualcomm USB modem converter detected
[ 9396.150372] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
foobar66 said:
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
Code:
> lsusb
Bus 001 Device 034: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
And then:
Code:
> dmesg
[ 9395.999112] usb 1-1: new high-speed USB device number 34 using xhci_hcd
[ 9396.149376] usb 1-1: New USB device found, idVendor=05c6, idProduct=9008
[ 9396.149380] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9396.149383] usb 1-1: Product: QUSB_BULK_CID:0402_SN:33B9DDAC
[ 9396.149386] usb 1-1: Manufacturer: Qualcomm CDMA Technologies MSM
[ 9396.150184] qcserial 1-1:1.0: Qualcomm USB modem converter detected
[ 9396.150372] usb 1-1: Qualcomm USB modem converter now attached to ttyUSB0
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
Click to expand...
Click to collapse
Use this https://forum.xda-developers.com/oneplus-6t/how-to/tool-6t-msmdownloadtool-v4-0-oos-9-0-5-t3867448
Should try for several times with instruction here
Question - when does device show red warning? When u disable dm verity?
I unlocked and rooted but only had yellow warning, but when i installed aosp gsi i had a red warning. Once of the step to install the rom was flashing vbmeta and disabling dm verity.
patelparth120595 said:
Question - when does device show red warning? When u disable dm verity?
I unlocked and rooted but only had yellow warning, but when i installed aosp gsi i had a red warning. Once of the step to install the rom was flashing vbmeta and disabling dm verity.
Click to expand...
Click to collapse
Disabled dm-verity caused red warning, i guess.
---------- Post added at 10:01 AM ---------- Previous post was at 09:58 AM ----------
foobar66 said:
Well ... bad luck ... I tried to change abl_b and reflash it ... phone is sort of *dead* now.
Does no longer boot at all.
However, when I plug it into the PC, I can see:
And then:
So it is not completely *dead* but in some sort of Qualcomm low level mode. I found some info here: https://together.jolla.com/question...ss-modem-any-chance-to-bring-it-back-to-life/ but did not make any progress yet.
EDIT: looking at MsmDownloadTool to debrick the phone ...
Click to expand...
Click to collapse
Edited abl.img ? and flashed via recovery/fastboot ?
AnoopKumar said:
Edited abl.img ? and flashed via recovery/fastboot ?
Click to expand...
Click to collapse
No, just flashed using dd command in TWRP shell.
foobar66 said:
No, just flashed using dd command in TWRP shell.
Click to expand...
Click to collapse
Phone still dead ?
OK ... I managed to recover my phone !
A windows PC with the MSM program did the trick.
I am now back to stock 9.0.5
foobar66 said:
OK ... I managed to recover my phone !
A windows PC with the MSM program did the trick.
I am now back to stock 9.0.5
Click to expand...
Click to collapse
I assume that, there is nothing to do with the abl.img. Only thing we can do with it is change the default strings to a song lyric or something. abl.img is the uefi firmware i guess. Bootloader is using the images stored in the logo partition.
Gsi's flash without breaking verity if u flash to both slots. And totally format. Fastboot -w. The phone sees any changes to partitions as corruption and breaks verity, hence red warning.. if someone would be inclined to talk to invisiblek from the essential threads, he could tell u of a fix. The solution is not in abl. It's in the stock boot.img. if I had more time, I would help
---------- Post added at 02:52 PM ---------- Previous post was at 02:51 PM ----------
tech_head said:
Different issue.
They are not trying to get rid of the red warning but the yellow warning for an unlocked BL.
On this phone, if you have a "red" warning you use the MSMDownload tool and go back factory including locking the BL.
This is a different case.
Click to expand...
Click to collapse
No, they are talking about breaking verity also. Seems to be both messages, but more recently the broken verity message. Which there is two types, one u can boot from, one u cannot.
jacksummers said:
U guys should talk [email protected] We had this issue of broken verity with the essential phone and he came up with a redboot.img that u flash and it bootloops the phone and fixes verity. It keeps bootlooping till.it fixes it, then u flash a proper kernel and you are good. Cuz as It stands one can only resolve this properly with the tool
Click to expand...
Click to collapse
I would love that idea. That would be really nice to have on our device