[G4 General] steadfasterX:
current state and (unsorted) to-do list for the public release (the major ones)

For stuff already

DONE

(only release stuff not the whole story which would break XDA.. ;) ) click the button:

build kernel with 20a sources and checking defconfig! --> 100%

I need to prepare an UsU LAF partition

selinux=permissive --> 100%

UsU stuff --> 100%

Enhance UsU flashing!... a

LOT

!

include UsU laf (dl mode) --> 100 %

include rawres (real model detection, boot logos) --> 100 % - ha ! that one is nice .. each model can have a different GPT and while laf and aboot are always at the same sectore for all the raw_resources one can be different. SALT will parse the current active GPT and so identifies the correct start sector for flashing..

prepare a full debug AOSCP build for those encountering a bootloop after flashing

build and test --> 100 %

TWRP

add new UsU kernel (correction of backup path etc) --> 100%

adapt TWRP UsU detection to new UsU kernel --> 100%

stuff that happens on the way..

currently my device bootloops into dl mode --> WTH?! - lol during all the journey I never had seen this behaviour but it seems it occurs when a partitions flashed is not compatible.. flashed back my whole stuff and back in the game. nice LG.

Reviewing new exploit: https://alephsecurity.com/2018/01/22/qualcomm-edl-1/ --> 100% (nothing I can do - and its not needed due to UsU)

adding UsU kernel configs for every model --> 100% introduced by this commit

release SALT v3.6 --> 100%

[/U]release FWUL v2.5 --> 100%

YEA! finally. FWUL v2.5 contains latest and full working SALT release so if you wanna prepare yourself download FWUL v2.5 (I

highly

recommend to use any of the

persistent

variants!)

re-upload all UsU files for each model

prepare due to massive UsU changes --> 100 %

upload --> 100 %

release FWUL v2.5 --> 100%

Create generic laf partition for SALT (enable flashing) --> 100%

implement a detection in SALT for incompatible laf version 100%

second H810 test --> 100% ok. The first h810 unlock was a success for sure but the user encountered bootloops so I decided to give it a go with another h810. The h810 is very strict in many terms. AT&T has limited the download mode and as we know today even the modem partition has its own life. The good: bootloop fixed for that special device!

fix the baseband modem identifier (producing crashes if the device is not prepared)

override-kernel h815 --> 100% Unfortunately modifying the kernel cmdline does not fix the modem crash :(

dtb appended kernel test --> 100%

I have only one issue left: writing the model name not hardcoded but based on the kernel defconfig. --> 100%

Porting DirtySanta kernel patch to

h815 TITAN

--> 100%

Porting the patch to aoscp N --> 100% ( commit )

creating UsU kernel configs including the new UsU kernel patch --> 100% ( nougat, oreo )

AMAZING break through here! In plain words: After flashing UsU it was not possible to use the basebands of N modem - now

it IS

!

As this is a kernel change the ROMs will need to apply this ofc. Regardless UsU will be released together with a workaround TWRP zip which can be flashed for ROMs not having my kernel patch.

H818 Touch is not working (this will

not

delay the release - I very likely will release without support for the h818 first)

--> H818 override kernel: 100%

--> H818 TWRP: 100%

--> Unbrick jmefcon's device (he accidentially bricked it before I was able to do anything): 100%

--> Test H818 TWRP: 100%

Porting & testing DirtySanta kernel patch on 20g/h --> 100%

build kernel with 20g sources and checking defconfig! --> 100%

unify REAL model detection

As the kernel driver way is maybe too hard (for me) I go in parallel the other way:

Creating device tree for H810 --> 100%

ROM build for H810 --> 100%

H818 Touch is not working (this will

not

delay the release - I very likely will release without support for the h818 first)

I need to fix or at least get a proof of a workaround if someone encounters issues like the h818. For this I work together with jmefcon as I do not own that device but we both have a real life so it takes its time

if you have C knowledge and want to help? Click the button:

--> analyzing root cause (again) and identify the real issue -> 20%

Current assumption: the lge.sim_num=2 is not enough and it seems it "just" can not load the firmware PLG468 maybe due to a wrong smem address

Besides that the 2 dmesg files are from different devices and they seem to have a different LCD panel?! wtf..

If anyone wants to help:

Working

H818 dmesg,

Non-Working

H818 dmesg

H818 kernel sources

Product ID ident: here

The complete diff 1 (left = working, right = not working) => https://www.diffchecker.com/TDXZ6i6U

The complete diff 2 (left = working, right = not working) => https://www.diffchecker.com/0kaYDl9h

unify REAL model detection

As the kernel driver way is maybe too hard (for me) I go in parallel the other way:

INITRD approach for a unified UsU detection --> 80% . Kernel seems to be very hard. Building just for every model a ROM bc of a proper detection is stupid. So I decided to try again the same way as I implemented the unification in TWRP which works great so far but does not happen in the kernel (so initrd). That is not so much fantastic as a kernel implementation would be .. but hey.. if it works and keeps away the work to build ROMs for every model just bc of this its worth it. It would have one "limitation" (its just cosmetic i would say as of today): it will not modify/change the cmdline as I could do in the kernel part but it should bring up everything properly in the android settings etc.

unified UsU kernel --> 22% Thanks to [MENTION=3299677]ArchangelofDeath[/MENTION] and [MENTION=3482571]shane87[/MENTION] I have still a bit of hope for this way.

Anyone else here with C knowledge willing to help? This part is f** hard. Atm I'm really sick of this.. so if you have C knowledge and want to help? Click the button:

The idea is "easy" ;)

https://github.com/Suicide-Squirrel...lob/UsU_testing/drivers/soc/qcom/usu_detect.c

I want to:

Step 1:

Open a file (in this case a device) read from a given offset and print the result. Tbh for devices which are not unlocked by UsU it will contain binary stuff so we need to ensure it is readable but that's for step 2.

Step 2:

Detect unreadable output i.e binary crap and replace it by an empty string nor sim throng

Step 3:

Based on the result of 1 and 2 I want to modify the cmdline as the REPLACE stuff does here:

https://github.com/Suicide-Squirrel...5ce6#diff-603376ac7b8737d94a63e7a29e1574b7R88

Tbh I want to just call my own function before the replace happens.

The goal is to replace LS991 by the real model taken from 1 but only if it was not empty / binary crap.

Thats it.. lol. Atm I'm able to see the print statements so my functions get called but as soon as I try to use file_read it just hang on boot. No last kmsg ramoops after that or kernel crash. Just hang.

As this is kernel level we have to use vfs_read..

Keep in mind that I can speak Bash even when sleeping and a bit of python but all this low level C coding is... Well if can read and modify but writing.. Is a complete different story.

stuff that happens on the way..

omg.. During my tests with another h810 user I found that I need to use a better verification when flashing UsU. The thing is.. This requires to re-generate and then re-upload all flashing zips again.. Sigh... --> 0%

NEW:

wtf? All newer aoscp oreo builds stops working shortly after booting into android. I can't say atm when exactly this began bc last time I tested aoscp 5.2 all worked fine but it seems all newer 5.2 builds have this issue --> 100% fixed in latest 5.3 build (at least there)

NEW:

second H815 test --> 100% not needed tbh but [MENTION=5125041]ling751am[/MENTION] was one of my previous testers and he got a new device so I gave him the improved guide and new UsU files for testing (with success ofc ;) )

creating release thread including the full glory guide

Content --> 99%

Release thread --> 0%

Getting a proof for every device (would be nice but optional / running in parallel)

Keep in mind: UsU will work for

ANY

LG G4 model and does not care about country specific ones, too! When I say:

ANY

, I

MEAN

any!

The only device which is a real special one because of different hardware (2 SIM slots) is the

H818

which

can

be unlocked but has issues (see above)

F500 --> I need

you

- write me a PM with the model name as subject plus a link to your SALT debug log (while phone is connected)!

H810 (confirmed) --> https://xdaforums.com/showpost.php?p=75126190&postcount=298 and https://xdaforums.com/showpost.php?p=75736723&postcount=456

H812 (confirmed) --> https://xdaforums.com/showpost.php?p=75126190&postcount=298

H815 (confirmed) --> My own one! and https://xdaforums.com/showpost.php?p=75086602&postcount=276 and https://xdaforums.com/showpost.php?p=75737617&postcount=458

H818 (confirmed)* --> https://xdaforums.com/showpost.php?p=75133410&postcount=307 * SEE ABOVE REGARDING THE CURRENT ISSUES

H819 --> I need

you

- write me a PM with the model name as subject plus a link to your SALT debug log (while phone is connected)!

LS991 (confirmed) --> mine and 2 others (no link available - IRC only)

US991 --> I need

you

- write me a PM with the model name as subject plus a link to your SALT debug log (while phone is connected)!

VS986 (confirmed) --> https://xdaforums.com/showpost.php?p=75109841&postcount=293

Thx all for your patience

sfX