CVE-2016-2431 is long fixed and downgrade protected (and masterkey isn't involved in FBE)

Thank you for the information @alecxs! Am glad to know that. I will update the post accordingly.

most promising is 3. TWRP apbf Android Pattern Brute Force. you should focus on how to use it right

> "failed to invoke decrypt command" The above was the initial error, although, I believe, the setup was quite correct with adb support and everything. I had also opened an issue, as this tool seems more promising for pattern brute forcing. It's just that I lack proper coding knowledge. He also suggested, on contacting, a custom code appropriate for me. Refer: gist.github.com/timvisee/c4f3d7a3d8630b81f969a7dcfc60e71d Also refer: github.com/timvisee/apbf/issues/2 But I will give it another try from scratch, and see if it works. Thank you again, @alecxs!

Btw, according to the author, TWRP does reach a state where it does not accept ANY PIN, right or wrong, and he also does not know the reasons or workarounds. This was the limitation. I don't know if this behavior persists in the latest TWRP versions.

that is expected behavior. gatekeeper prevents bruteforce attack by increasing timeout up to 1 attempt per day

That does make sense, yes. And that also means brute forcing got a lot more difficult, and if I was to try the tool, I'll have to be very careful with the cool down periods I specify in the code, I guess?

you should generate word list with all unlikely pins deleted (like 1111 or 1234) to reduce attempts and let run with 10 seconds timeout. if gatekeeper is restricting maybe reboot every 30 attempts is necessary

there exist paper but in my opinion it's nonsens and unproofed (afaik FBE does not even USE masterkey for encryption)

Your suggestion is good. Yes, that was what even timvisee said. Running a custom script that tries PINs that end with 7. Because that's something I remember well. And as far as the paper is concerned, yes it is not proved yet but there's another place, where it has been documented in detail and it looks promising but way too complex for an average user like me. Again, thank you alecxs! I also read your comments on a similar XDA thread! I must say, I was impressed!

if you know one digit that will decrease bruteforce time 14x times. such a script is easy done, just run a nested for loop for each digit. the only problem is figure out the right timing. nevertheless do a backup first

Yes, I am planning to pull an image of the userdata partition. (sda14, it is) And also planning to brute force it outside Android System using brute forcing tools. Don't know if there'll be any success.

once you understand android encryption you know offline bruteforce doesn't make any sense. Even if your device is only FDE encrypted it's simply impossible without the keys

in case there is no timeout increase (and no wipe) you can even try to bruteforce via OTG Hub. i did this successful on Huawei device. the only problem was phone battery, so i had to split into several parts. use the 4DigitPin sketch and concatenate suffix 7 so your 5-digit PIN should be cracked within a day. no TWRP needed

another question claims there is some cheat to by-pass gatekeeper wipe/timeout via emergency dialer (untested) android.stackexchange.com/q/232031

Thank you, @alecxs!! Whatever you said makes so much sense, and the links were really useful! After all this time and reading, thanks to you, I am now left with Brute Forcing as the only option. Now there are two ways to do it, I believe:

1. via TWRP: Using timvisee's tool apbf, I am able to run a custom executable script which tries 4 and 5 digit PINs ending with 7, and I am sure, it would not take more than 24 hours. The ONLY PROBLEM is that every time, the script tries a PIN, the message displayed in the terminal (on my PC) and in the log window (TWRP) is: No password provided. So I am not sure, if the tool is really working.

2. via Lockscreen: Using my other phone as Rubber Ducky is something I have given up. So I am left with the option you provided in the link (OTG). But there's something that maybe you'd understand and perhaps throw some light on how to use it, if you will. gist.github.com/Areizen/84be48ce9646185a9d2ecffb3a664a32

If this tool by Areizen would work, then.. Wow!

Anyways, I would like to share something that I didn't write in my original question, thinking it would make it even longer. I tweaked my settings and I am able to go past the lockscreen with my fingerprint and hence I am free to alter any settings in the phone that I want to, but of course, no apps can be started, as the data is still encrypted.

And yes, android.stackexchange.com/q/232031 This doesn't work for me, I tried!

Also, going past my lockscreen and entering PIN to change the existing PIN gives a timeout/cool down period of 240 seconds, never increasing more than that!

And never decreasing less than 240 seconds either :( I just found out.

@Nurmengardian does reboot have an effect to cool down period?

Sadly, no. That's what confuses me. The phone seems to think, even after a fresh boot and cool down period, that 15 wrong attempts have been made :(

The cool down period of 240 seconds reminded me of this: gist.github.com/Areizen/84be48ce9646185a9d2ecffb3a664a32 I know for fact that the gatekeeper is located at /system/bin/gatekeeperd

And I also asked at the official group, but no replies there, nuh-uh.