Wednesday, February 19, 2020

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 :)

Friday, July 26, 2019

new video by Wendell from Level1Techs on Talos II OpenPower Secure Workstation + my original comment

Wendell's video is located here: https://www.youtube.com/watch?v=5syd5HmDdGU

Forget x86; OpenPower is it! Talos II Secure Workstation!

My comment on it:
Wendell i've found some alarming stuff in my ASUS decompiled BIOS, namely while searching for strings, I found "BACKDOO" and started digging around that area, and found what essentially amounts to a literal BACKDOOR highway linked to the Windows Drivers, namely started with me investigating my ASiO.sys (which I thought was for my sound card) but its actually for Asus IO (or AsusGIO) aka AISuite aka the new Aura Sync - also linked to ATKEX.dll and PEBIOSINTERFACE32.dll - and tied to windows service atkexComSvc - for control of hardware bus devices like fan control, lighting, USB charging, that kind of thing. It seems to have a deep link straight back to the BIOS and the driver can be exploited and the BIOS seems weak. There were even CVE's posted, CVE-2018-18535 , CVE-2018-18536 and CVE-2018-18537. Now, I havent experienced anything myself but theres been reports of questionable behavior (memory leaks, unwanted internet traffic, etc) indicative of active exploits in the wild surrounding this also. Its very alarming, and I wish I had the ability to do a more complete security dissection and writeup of the decompiled BIOS but honestly I can't read IDA to save my life :) So I am passing this info onwards to you. Please forward this to anyone applicable or if thats you and you see it, please look into this info.
Sources:
1: https://packetstormsecurity.com/files/150893/ASUS-Driver-Privilege-Escalation.html
2: https://packetstormsecurity.com/files/cve/CVE-2018-18535
3: https://packetstormsecurity.com/files/cve/CVE-2018-18536
4: https://packetstormsecurity.com/files/cve/CVE-2018-18537
5: https://community.norton.com/en/forums/pebiosinterface32dll-0
6: https://rog.asus.com/forum/archive/index.php/t-11511.html

On an unrelated note, I also just discovered (maybe its known to everyone) that VMWare put a literal backdoor in for their VMWare Tools for the guest to communicate back out to the host over a high bandwidth IO channel using specific CPU registers and memory addresses. At least they were kind enough to name it "open-vm-tools/lib/backdoor/backdoor.c" and open Source it - Also worth looking into.
This is on top of the well known information you mentioned about the vulnerable Intel ME engine and danger of closed source BIOS/UEFI - so I am eagerly following th open source firmware community, like Tianocore, CoreBoot and Libreboot for Thinkpads and the like... But yes I am sortaa? getting into these deep endeavors but its extremely above my head, and I assume for most people its so deep its just off the radar. Thank you for bringing this amazing Talos/Power9 machine to light!

I wish I could respond further and in more detail but I wanted to get this posted as is first, with some links. Disclaimer: I'm not an actual security researcher, I'm just a life long nerd trying to be one.

Monday, July 22, 2019

Emmett Brown - VOID (Synthwave album on Bandcamp)



Check out Emmett Brown's music, its Synthwave, and easily some of the best stuff I've heard.
One of my favorite songs is Twin Pines Mall. and Hypercolor Tease.
Free to stream!
Right up there with Perturbator, Carpenter Brut, Kavinsky and the like.
Be sure to check out his first album MANIC too.
He's also on Spotify 

Sunday, April 29, 2018

UEFI Booting NVME on x58 Project w/ Tianocore by mrlithium (draft) 4-29-2018 - Round Two

Using a TianoCore DUET USB stick to Boot Windows 10 in EFI mode from NVME SSDs such as Samsung PM961 on Legacy Platform X58 Chipset.

Already confirmed working on Asus Sabertooth X58 motherboard and Intel 750 Series SSDs approx 2 years ago.
Since then, a nice person named AudioCricket has developed a cleaner tutorial, (see AudioCricket blog article on Booting NVME ) which made me want to revise my own process, as he credits me with thanks for knowing it was even possible. You should read his also, its got some good details.

This tutorial is meant to give you bootability on extremely high speed NVME drives. If you are not using a high speed drive, or its in a wrong slot, you may not see much benefit. The whole boot process workaround itself, from the Tianocore DUET USB, takes up a valuable 10-15 seconds at bootup. You will pay a longer price on boot, but your Windows OS will be booted onto this faster drive, and there is no substitute for that. You already could use these drives as secondary storage partitions with no configuration, but thats just boring.
Linux Note: that if you are using Linux, all my info is largely irrelevant. Linux takes entirely another approach to booting.

My Process involves using the TianoCore DUET software and UEFI bootloader to chain boot load EFI Windows from a MBR USB stick.

To redirect your BIOS Boot -> MBR of USB stick -> virtual/emulated UEFI environment (Tianocore DUET) -> load open source NVME driver -> NVME GPT / EFI Windows System boot.
1 USB Stick for TianoCore UDK_X64  (USB 3.0 maybe needs an XHCI driver)
1 USB Stick for Windows 10 Setup ISO
Executing a few commands at the shell prompt
Running the Windows Setup Installer off a 2nd USB stick, using that to lay down new partition information and blank your NVME SSD.
Installing a new copy of Windows to the NVME SSD, with its own EFI partition and GPT layout. This is the best way to get the EFI boot working.
Booting NVME cannot be done without UEFI and booting EFI must be done for Windows (winload.efi). You cannot have Windows boot MBR (winload.exe)
At this point you will have two Windows Installs, and able to dual boot to the new NVME OS drive by inserting the Tianocore USB stick and booting

Boot process summarized: (Thanks to AudioCricket for his excellent description)

  1. Computer powers on
  2. Legacy BIOS boots / initializes
  3. Tianocore DUET boots from the USB stick
  4. Tianocore DUET executes UEFI Shell
  5. UEFI Shell loads generic NvmExpressDxe-64.efi driver and remaps system block devices
  6. UEFI Shell now sees Windows 10 hidden FAT partition DIRECTLY on the NVMe
  7. UEFI Shell executes Windows 10 UEFI bootloader from that hidden NVMe FAT partion directly (\EFI\Boot\Bootx64.efi image)
  8. Windows 10 is now booting and is in full control of your computer (under UEFI mode, of course)

Tianocore USB Stick Creation:


The USB stick needs to be formatted with "HP USB Disk Storage Format Tool" as opposed to Windows, so just download that. There is a reason for needing that stupid program, The MBR and DBR / BPB boot sectors need to be written as if it was a HDD not a removable (floppy) - err don't ask - :) After you reformat it, unplug/replug it.

Start up an administrative command prompt, and cd \tianocore_uefi_duet_installer-master
or, go into the location of CreateUSB.cmd  
Replace J: with the appropriate letter for your USB stick. (double check with HP USB Tool).
.
CreateUSB.cmd J:

Make sure no errors / unsavory messages are shown,
then unplug/replug it, and run this:

CreateUSB.cmd J: UDK_X64

This copies MOST of the files. You still need to manually copy over the file Drivers\NvmExpressDxe-64.efi this can be obtained here: or you can compile your own (coming soon/later)

UEFI Interactive Shell Usage:

From now on, rebooting from the Tianocore USB will launch into a shell. It acts kind of like DOS or Linux does, a simple command shell. Here you can explore and decide what commands to run:
Hit enter after every command. Theres also tab completion. You can use dir to look around.
Green colored files are executable and just typing their name should run them, for example *.efi
FS1: for drives (like C:) and \ for directories.
FS0: should be your booted Tianocore USB drive
FS1: should be the Windows USB stick
FS2: should be the NVME SSD drive (not visible yet)
Run these two important commands:
load \EFI\Drivers\NvmExpressDxe-64.efi  (loads the .efi program for detecting NVME devices - from this root pathname on the current prompts' FS device name)
map -r  (this will make new FS2: alias, etc)
Theres also "BLK" devices that correspond; you can ignore these besides to make sure they do exist for the right USB SATA or PCIe location.

A "startup.nsh" script can also be created, to AutoRun on boot, to automate the above commands in their final form or for anything else special that you may need or want.
Startup.nsh lives at \EFI\Boot\ directory and should just be auto-executed from there.

To boot the Windows Installer on the 2nd USB stick:

FS1:\bootmgr.efi
or
FS1:\efi\boot\bootx64.efi

Follow the Windows Setup, "Install Now" and choose "Custom Upgrade" so you can pick the right drives UnPartitioned Space (If you already attempted this, its best to Delete partition and go back to UnPartitioned Space and then say yes to "Windows may create some additional system Partitions". If it complains they are not in the correct order, "Delete" and hit OK on "UnPartitioned Space" again. The installer's Partitioner should be able to see your NVME drive immediately and without any drivers needing to be loaded.  Installation is seamless from here on out, other than a few reboots. Once the Windows Installer accepts your partition layout, it lays down the EFI partition on your NVME drive,  and starts "Copying Files...".  Meaning, across reboots, you need to reboot it from the NVME drive, not the Windows Install USB stick. While you're still technically doing the Windows Install, everytime the system reboots, this is the command you want to enter at the shell prompt to continue the installation. 

To boot Windows on the NVME drive:

FS2:\EFI\Microsoft\Boot\bootmgfw.efi

FS2 should be the alias for your NVME PCIe SSD drive device, (if not- double check, find it out).
This Runs the Microsoft EFI boot manager - that supports NVME boot.
Then Microsoft takes over, and the rest is magic. Now your system is fully working.
You would want to put this command in "startup.nsh" so its automatic. Keep in mind the FS drive letters numbers may get shifted, even due to just USB sticks.

Possible Secondary Optional or Advanced Steps:

Update Driver ? - replace the Microsoft stornvme.inf driver with a Samsung NVME driver (or whichever one, Intel?).
Using USB 3.0 to boot may require: \EFI\Drivers\XhciDxe-64.efi
Eliminating the need for a permanent USB Stick by copying the partition to any other internal hard drive in your system, and making room for it and also being able to dual boot it.
Not actually installing windows, just laying the boot partition down and then re-copying an Image of windows back over to the new SSD.
Small = ~4 Few megabytes. = Can be downloaded as a Disk Image *.dd, and use RUFUS to restore it back. Should be able to replicate Tianocore USB sticks for backups/disasters.
Editing the Windows BCD to get Dual Boot or Multiple Partitions combined or something else.
Remove un-wanted drive letters of the other system after bootup.

Super Fast NVME PCIe SSD's on Legacy X58 Platform - other Practical Considerations:

*** PCI-e version revision and link width ***
PCI-e 2.0 was the max for X58, and as of today we are up to PCI-e 3.0 which doubles bandwidth by 2x.
Theres also certain slots that are PCI-e 1.0 slots (the bottom slot on Asus Sabertooth is 1.0 and the 2nd GPU x16 slot is the only next best highest speed 2.0 x4 slot :/
Benchmark overall speed drastically improved when switching slots, from around 750-770MB/s over PCI-express 1.0 x4 to 1450-1600MB/s on PCI-express 2.0 x4. (With the Samsung PM961 SSD, and tested under CrystalDiskMark and AS-SSD.)
Note this is nowhere near the drives theoretical maximum, that would requires PCI-e 3.0 and should be hitting somewhere over 2-3000 MB/s.
Also note that most slots are only physically, but not electrically, the full width of PCI-e lanes. Make sure your slot is valid.
It is advised to check in a program like HWInfo64 or AIDA64 at your Motherboard slot DMI information and for sure confirm the devices are detecting at proper revision and width. (CrystalDiskMark will say the link speed for PCI-e devices now so thats handy). If not, Power Management settings could be configured to do Link State Power Management or whatever thats called.

Friday, April 20, 2018

UltraDefrag Mod 7.0.4 alpha genBTC edition

UltraDefrag 7.04 (UDefrag) - mod by genBTC
Compiled from C++ source, and edited.  Requires WxWidgets.
Integrated StopGap software - requires Boost libs
New Build system devised for use in Visual Studio . Supports 2017 and CMAKE on Windows.
Supports Building with MSVC or MINGW G++.




Now includes Files List tab.
Also Supports finding files by LCN cluster, finding LCN cluster by filename, right click on file list.

- Development has been put on hold, and there is a great deal of work involved in this project.