Netguard 2 Firewall for Android - Unlocking the registration challenge response activation license code to authorize the Pro version

NetGuard - Firewall for Android (NetGuard2)
https://github.com/M66B/NetGuard/
https://github.com/M66B/NetGuard/releases/download/2.273/NetGuard-v2.273-release.apk

Successfully Unlocking the registration challenge & response code for NetGuard 2:
 (by genBTC) @ February 19, 2020.
Android <=7.0 CONFIRMED (NOT confirmed on 8.0 Oreo + above, but likely works)

Background
-------------------
NetGuard / NetGuard2 is a great firewall program for Android, and is unique in its functionality.
However, the pro features are all paid addons.
This program is fully open source though, and the .apk can be downloaded from F-Droid or straight from Github. This makes instant in-app payments impossible (as opposed to when from the Google Play Store). Also, there is NO remote server to "call home" to verify the authentication, because it has to work in this standalone mode too. This is even stated in the README by the author.
I have no issue with the developer receiving payment for his efforts, but,
One of the main PRO features is selective blocking/filtering, the main thing a firewall should be able to do, and is the main reason I downloaded and wanted to use this program.
The only other programs for Android I've found were "NoRoot Firewall" which I used previously and does do this, and "AFWall+" which uses linux IPtables internally and as a result won't work if the phone is not rooted.
Without the paid unlock, the program is only able to block whole applications (or system-wide).
For example, if we want to block say Reddit from accessing "facebook.com", that requires the paid version. Unacceptable.

So I begin the task of reverse engineering the authentication mechanism.
---------------------------------------------------------------------------------------------
It starts here: https://github.com/M66B/NetGuard/search?q=challenge
We search the code for "challenge" since that appears in the GUI.
Most of the results are *.xml files which contain strings and do not interest us.
The 2nd result is jackpot. app/src/main/java/eu/faircode/netguard/ActivityPro.java
We can see theres actual code calling something called menu_challenge()
https://github.com/M66B/NetGuard/blob/f408a3140925252742b5ed1e7e60711b87a16b4f/app/src/main/java/eu/faircode/netguard/ActivityPro.java#L273
As it turns out, menu_challenge() is in this same file, right below that. Line 288.
Jackpot! This is the entire challenge and response function!

Long Explanation
----------------------
Even without knowing Java, you can read this code. Here I will explain it in English:
A Layout is Inflated (stubbed out) and an Alert Dialog is created. (the GUI)
Now 3 Variables are created. android_id , challenge, seed.
Lets skip android_id for a minute.
Lets explain the code syntax. These are commonly called "Ternary" or conditional if statements. Basically an If/Then/Else command. Imagine the Equal sign being an "if", the ? turns into a "Then", and the : turns into an "Else"
Result = ConditionA ? AnswerA : AnswerB;
These say: If the Android we're on is < less than the version Code for the letter O, aka Android Oreo.
Android Oreo is 8.0 and SDK version 26)
Challenge = (If Android Version < Oreo ), just use the Build.SERIAL number. otherwise use "O3" + android_id. You can view this serial number in Settings.
Seed = (If Android Version < Oreo ), just use the word "NetGuard2" . otherwise use "NetGuard3"
This is both good news, we now know the scheme, but bad news if you are on Android Oreo 8.0 or above.
Continuing on, "display the Challenge in a TextView", and set up a Clipboard Listener to enable a Copy to Clipboard button"
The "//Response" area is next. All handled by the TextChangedListener.
The line of main interest is Line 319:             final String response = Util.md5(challenge, seed);
This is the verification function.
A MD5 Hash is generated from the "challenge" and "seed" variables from Android before.
Whatever we type as a response will be compared to this.
What you need to know. MD5 is only considered a hash function, an insecure one at that, and is 100% deterministic. This means that the output is exactly the same every time for a given input. Of note, an MD5 function typically only takes 1 input, but here we have two (the challenge and the seed). A seed is normally used as an additional source of randomness in other crypto algorithms. This term is incorrect here. Here it would be considered a Salt (cryptography) @ Wikipedia
Given that it is a fixed salt, and we can read the value from the source code, it would be trivial to perform an MD5 hash collision brute force attack on the hash, so this "seed" (salt) actually does nothing to protect anything. But a brute-force attack is not even needed.
Not only this, the actual secret input is not even a secret. We fully know the first half too ("challenge"), because the software outright displays it as the "challenge" field.
Also, at least up until Android 8.0, its also viewable from Android system settings.
(Android Settings > General > About this phone > Hardware Info > GOTA Serial number.)
So this function was/is extremely broken and did not serve any technical protection, it only serves as a lesson for what not to do. Which is why I'm making this public. The author must have eventually been told something similar and once he found out, implemented the "NetGuard3"/Oreo 8.0 version to prevent this, but still left the old one in for compatibility, and still implemented it wrong by displaying the "challenge" and having a fixed "salt".

continued confirmation:
We have almost all the information we need now.
We should investigate this Util.md5() function further, just to double-check what its doing with the 2nd parameter ("seed").
Searching for "Util.md5" doesn't lead you to it, because of how Java works, "Util." refers to the "Util.java" file in the same directory as the file we were just in, and inside is a function named simply "md5".
https://github.com/M66B/NetGuard/blob/f408a3140925252742b5ed1e7e60711b87a16b4f/app/src/main/java/eu/faircode/netguard/Util.java#L636
We can see it does:      MessageDigest.getInstance("MD5").digest((text + salt)
This says, "Create an Instance of the MD5 (message Digest function) and provide it 1 parameter (text + salt)."
In Java (and others), using + on two strings, combines the strings together (aka concatenates).
So "Text"+"Salt" == "TextSalt".
The rest of the code just takes the UTF-8 string encoding and outputs it as hex bytes ready to display, standard behavior, and thus is irrelevant to analyze.
So you can see in fact, MD5 DOES only take 1 parameter, and no other functions are being relied on for secret behavior.


Putting 2+2 Together (Android < 8.0):
-------------------------------------------------
We take "challenge", in this case, "LGLS992" (this is my phone's model number) and combine it with the ID "20d7f703" (Build.SERIAL)
This is available from Android Settings > General > About this phone > Hardware Info > GOTA Serial number.
We take the "seed", in this case, "NetGuard2". (always)
We combine them all together to form "LGLS99220d7f703NetGuard2" (USE YOUR OWN)
We run any MD5 function on it.
It outputs a sequence of 32 hex values. (A-F 0-9) like: 449d0a063a3cd230e1ffd57759b9852b
We type that number into the response code box.
It will auto-apply and once the last character is typed, it will auto-activate.
DONE! Activated! That simple! (and obviously just copying my key won't work).

We didn't even have to run any of his code, or use Java.
I ran my MD5 in Python, in about 5 seconds, like this.
Start up a Python prompt in a terminal, (python.exe or python) - interactive interpreter mode.

resp = "LGLS99220d7f703NetGuard2"
import hashlib
hashlib.md5(resp).hexdigest()

OR - You can also use an online MD5 hashing service, such as: www.md5hashgenerator.com , onlinemd5.com etc.
Any data you submit there is not private, but it also is not dangerous in this case.
(and obviously just copying my key won't work).

Android 8.0 > above (unconfirmed Method)
---------------------
In the exact same way, we can copy and paste the visible "challenge" plaintext + "NetGuard3" salt combined together, and MD5 hash that to form the key.

Some thoughts:
FUTURE THOUGHTS AND NOTES:
"Challenge" is a result of "O3" + a query to Settings.Secure.ANDROID_ID variable instead.
I'm not an Android dev, so how to query Settings.Secure is new to me, and I'm not sure if this is even accessible outside. We may need code running on the device to query that. Using this makes it way more secure, but the current implementation is still broken regardless. And nothing is impossible.
"On Android 8.0 (API level 26) and higher versions of the platform, a 64-bit number (expressed as a hexadecimal string), unique to each combination of app-signing key, user, and device." from https://developer.android.com/reference/android/provider/Settings.Secure
This seems to indicate that this value is indeed secret and unique to code running specifically in the Netguard application context (based on the authors app-signing source code verification key)... So if we want to crack it, we must use another method, such as recompiling it ourselves. I will revisit this approach at another time, if this MD5 trick gets patched out. I wanted to get this uploaded first.
UNRELATED RAMBLINGS:
This reminds me of a related story recently about Android app-signing keys still using MD5 are becoming deprecated and banned from the Play Store. Keep in mind, that doesnt refer to the MD5 unlock license key we just bypassed, it refers to the entire application .apk. However from the Settings.Secure.ANDROID_ID description, in this program the license key code seems to rely on this app-signing key code. IMO if we can crack the app-signing itself, we can crack the license key too. So I checked this .apk status, its currently signed by "faircode.eu" using a SHA256+RSA2048 algo. Darn, now thats out of the question. Cracking that is above my paygrade, literally, 2048 bit RSA keys - 140.8 CPU years, (the cost of $20,000 - $40,000) as I last checked. Not impossible, but not a trivial thing. BTW, we all should be using 4096 bit RSA keys as of now. I would consider 4096 way more safe from brute force attack, even for a rich person. At least until Quauntum Computers :)