How to Clone any Application (Dual Apps) with EMUI’s App Twin Feature [No Root]

Huawei introduced the App Twin feature with Version 5.0 of Huawei’s EMUI, their Android skin. I believe that Huawei must consider this feature one of EMUI’s biggest selling points, since they present it in the topmost layer of the Settings application.

App Twin allows you to create a duplicate instance of an installed application so you can log-in to two different accounts at the same time. On Huawei Smartphones destined for the European Market with the Global Rom you’re able to clone WhatsApp or Facebook. On the equivalent Model for the Chinese Market you’re able to duplicate QQ or Wechat. Unfortunately these are your only options by default. I expect Huawei to add more applications to this list with upcoming version of EMUI.

When you duplicate one of those applications, a new app icon will be created on your home to start the cloned instance of the app. A small number is added to the original application icon to indicate which instance you’re using the cloned or the original application. Unfortunately, the duplicate application can only exist on Huawei’s stock launcher, and when the icon is cleared from the home screen, all the data associated with the App Twin instance is deleted.

The App Twin feature isn’t an innovative, never to be seen before concept on part of Huawei. There are several applications that perform the same function on the Google Play Store. Some of the most popular ones include App Cloner and Paralllel Space. In addition, Xiaomi’s MUI offers the same feature with greater compatibility and a larger selection of Applications. However, I would argue that by default, the third-party application alternatives are to some extent superior to Huwai’s implementation. Any application which you duplicate isn’t tied to Huawei’s stock EMUI launcher and even more importantly you aren’t limited to only 2 predetermined applications which Huawei has set.

In contrast, the third-party applications (with the exception of Xiaomi’s MIU implementation) have their own faire share of disadvantages. For example, App Cloner doesn’t work well on many applications including most Google Apps. Parallel Space is a pretty bloated application and quite the resource hog and is slow to launch any given cloned application.

I have to give Huawei credit to its implementation of the App Twin feature since it doesn’t suffer from either of this issues. However, for some odd reason Huawei decided to restrict the feature to a few apps. Despite their official claim that App Twin only works with WhatsApp/Facebook or QQ/Wechat it can actually work with pretty much any application on your device (with the exception of a few system application)

Clone any App with EMUI’s APP-Twin Feature

To clone any app you need access to the ADB shell and the application’s full package name.

First download the android SDK with the included ADB and fastboot tools or download the separate ADB binaries straight from Google:

Next install Huawei’s HiSuite which also installs the necessary drivers for ADB to work correctly. In order to be able to see the your Huawei smartphone you need to enable USB debugging in the developer settings:

Settings –> Developer options –> USB Debugging
(Tap on Build Number 7 times in Settings –> About Phone to unlock Developer options if you haven’t already done so)

Verify that ADB is set up properly by checking if adb recognises your device. Open up a command prompt and type adb devices . If you see your phone’s serial number and it doesn’t state ‘unauthorised’ then you’re good to go.

The first step in enabling the App-Twin Feature for your specific app is to find the package name of the specific application. The easiest way to accomplish this using an app like App Inspector From the Google Play Store

The package name is the first line underneath the app’s name e.g. com.google.android.apps.plus

If you don’t want to install another app just to see the package name of an installed application you can also see a list of all installed application using the following adb shell command: adb shell 'pm list packages -f

With the package name we can now enable the App-Twin feature. Start an adb shell with adb shell

Once in the adb shell enter the following command:

settings get secure clone_app_list

If you are already using the App Twin feature, then you should see either one or two package names returned with this command. If you aren’t using this feature, this string will be empty. Now, we will either append to the existing list or create a new list of apps to clone.

settings put secure clone_app_list "PACKAGE#1;PACKAGE#2;PACKAGE#3"

where PACKAGE#1…PACKAGE#3…PACKAGE#N is the full semi-colon separated list of app packagesyou want cloned. Make sure that you don’t forget to put the package list in-between quotation marks, otherwise the command won’t work.

If you are already using the App Twin feature and you received a list of packages during the“get”command, then be sure to APPEND your list to the ones that were returned. Otherwise, the existing apps will be deleted.

For example, if I want to clone Gmail, Solid Explorer, Chromium, and Reddit is Fun, I would enter the following command:

settings put secure clone_app_list "com.google.android.gm;pl.solidexplorer2;org.chromium.chrome;com.andrewshu.android.reddit"

Immediately after entering this command, you should see a toast message telling you that a cloned app has been placed on your home screen.

Upgrading Debian 8 ‘Jessie’ to Debian 9 ‘Stretch’

Intro

Debian 9 Stretch was released as the latest stable version of the Linux Distribution: Debian. While it’s always possible to install Debian 9 fresh from scratch, it’s also possible to perform an in-place upgrade from Debian 8. The following post describes the necessary steps to do so.

For a incredibly thorough documentation of the process, I suggest you also read through the official release notes.

Notes:

  • Upgrading to Debian 9 Stretch is only supported from Debian 8 Jessie. If you are running a version older than 8, you must first upgrade to 8 before working through this process.
  • The upgrade involves a kernel update, so a reboot will be required toward the end of the process.
  • It is strongly recommended that you have a full system backup or backup of any important data before proceeding with the upgrade, ensure that you have a plan to roll back. In the case of a virtual machine, take a snapshot before starting.

Performing the upgrade to Debian 9 Stretch

Before proceeding with the upgrade, please read through the list of issues to be aware of when upgrading to Stretch.

  1. It is recommended that you have your Debian 8 Jessie installation completely up to date before starting, to do this run “apt-get update” followed by “apt-get upgrade” and install available updates.
root@debian8:~# apt-get update
root@debian8:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

In this case all updates have been applied already, so it’s fine to proceed.

Edit the /etc/apt/sources.list file, my file is shown below. As you can see all of the lines are currently specifying “jessie”. Note that your mirror sources will likely be different which is fine.

deb http://ftp.ch.debian.org/debian/ jessie main
deb-src http://ftp.ch.debian.org/debian/ jessie main

deb http://security.debian.org/ jessie/updates main contrib
deb-src http://security.debian.org/ jessie/updates main contrib

# jessie-updates, previously known as 'volatile'
deb http://ftp.ch.debian.org/debian/ jessie-updates main contrib
deb-src http://ftp.ch.debian.org/debian/ jessie-updates main contrib

Change the instances of “jessie” to “stretch”, you can either do this manually, or automatically with the below sed command.

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

You can either use “stretch” or “stable”, as Debian 9 Stretch is now the current stable version as of writing. However note that if you use stable instead of the specific release name, in future when Debian 10 is released that will be the stable version so you may upgrade to that unintentionally.

The recommended way to upgrade Debian is with the ‘apt-get’ command. First update the list of available packages with the below command, as we’ve just updated the sources.list file.

apt-get update

Use “apt list –upgradable” command to quickly see what will be installed, updated, and removed during the upgrade process without affecting the system.

apt list --upgradable

Sample Output:

unattended-upgrades/stable 0.93.1+nmu1 all [upgradable from:0.83.3.2+deb8u1]
util-linux/stable 2.29.2-1 amd64 [upgradable from: 2.25.2-6]
uuid-runtime/stable 2.29.2-1 amd64 [upgradable from: 2.25.2-6]
vim/stable 2:8.0.0197-4 amd64 [upgradable from: 2:7.4.488-7+deb8u3]
vim-common/stable 2:8.0.0197-4 amd64 [upgradable from: 2:7.4.488-7+deb8u3]
vim-runtime/stable 2:8.0.0197-4 all [upgradable from: 2:7.4.488-7+deb8u3]
vim-tiny/stable 2:8.0.0197-4 amd64 [upgradable from: 2:7.4.488-7+deb8u3]

Now that the list of available packages has been updated from the mirror, run the below command to perform a minimal upgrade.

apt-get upgrade

This is known as a minimal system upgrade as it only upgrades packages that can be upgraded without needing any other packages to be removed or installed, so it’s a safe place to start. This upgraded 932 packages requiring 412MB on my system.

Now you’re ready to do the complete system upgrade, this will upgrade to the latest available version for all packages installed.

apt-get dist-upgrade

Ensure that you have enough free disk space to complete the operation, in my case it notes that afterwards 1,048MB of additional disk space will be used with 639 package upgrades and 479 newly installed packages.

During the distribution upgrade, services installed on your system needs to be restarted after up gradation of each service packages (ex. Apache, NTP) which may cause you the service interruptions. You can choose to restart automatically during upgrade or manually after the upgrade. Here, I opted to do “an automatic restart of services during the OS upgrade“.

Verify upgrade:

Reboot your machine after the distribution upgrade.

reboot

Verify the current version of Debian operating system.

lsb_release -a

Distributor ID: Debian
Description: Debian GNU/Linux 9.0 (stretch)
Release: 9.0
Codename: stretch

Users susceptible to man-in-the-middle attacks due to corporate https inspection

A large number of companies use “security” products to inspect HTTPS traffic for detecting malware and prevent other types of attacks. However, they might inadvertently make their user’s more susceptible to man-in-the-middle attacks by  decrypting and re-encrypting HTTPS connections.

The U.S. Computer Emergency Readiness Team (US-CERT) warns in an advisory that HTTPS inspection products don’t mirror the security attributes of the original HTTPS connections between the client and the server (Mirror: HTTPS Interception Weakens TLS Security | US-CERT).

HTTPS inspection is deployed in companies for checking the encrypted traffic coming from an HTTPS website to make sure it does not contain any malware or any other type of attacks. It basically performs a decryption and re-encryption of the client’s connection to an HTTPS server. The “security” products (proxy, web-gateway, firewall etc.) establish the connection on the client’s behalf by first decrypting the client’s HTTPS connection and re-encrypting the traffic sent to the HTTPS server. The client is served with a different, locally generated certificate by the security product which essentially perform a man-in-the-middle attack.

In some enterprise environments, an HTTPS connection may even be intercepted and re-encrypted multiple times. For example, at the network perimeter by a security gateway product and later, on the endpoint by a client’s antivirus program which needs to inspect the traffic for malware.

The problem revolves around the fact that the client’s browser no longer validates the real certificate issued by the server because its replaced with a locally generated certificate from the security product. In return, the task of validating the certificate now falls to the intercepting proxy.

According to the published advisory, those security products are evidently pretty bad at validating server certificates. An investigation conducted by researches from Google, Mozilla, Cloudfare, and multiple Universities states that the intercepted connections use weaker cryptographic algorithms (Source: interception-ndss17). The security products even advertise support for known-broken encryption ciphers that would allow an active man-in-the-middle attack by intercepting and downgrading a connection in order to decrypt it.

The analysis by the researches found that at least 32 percent of connections to e-comerce sites and 54 percent of Cloudflare HTTPS connections, which were intercepted, became less secure than they would have been if the user had connected directly to the server.

Browser makers had a long time to properly unterstand the quirks of TLS connections and certificate validation. Therefore, there is no better client-side implementation of TLS, the protocol used for encrypting HTTPS connection, than the one found in modern browsers.
In comparison, security product vendors use outdated, customised TLS libraries where they even back-port new protocol features. Re-implementing those features found in newer libraries makes them susceptible to serious vulnerabilities.

Furthermore, the US-CERT points out another widespread problem that many products intercepting HTTPS don’t properly validate the certificate chain presented by servers. Certificate-chain verification errors are infrequently forwarded to the client, leading the client to believe that operations were performed with the correct server.

The BadSSL website allows organisations and even employees to check if their HTTPS inspection products improperly validate certificates or allow for insecure ciphers. The client test from Qualys SSL Labs also provides checks for some known TLS vulnerabitiles and weakenesses.

 

Homebrew on macOS 10.12 Sierra

Apple introduced a few changes with the directory structure and permissions in macOS Sierra 10.12 which in the beginning broke Homebrew on macOS without some CLI magic to manually fix things. However, this has been fixed and Homebrew now full supports macOS 10.12. One of the issues was around a change in permissions on the directory /usr/local which on a new installation either doesn’t exist or wasn’t writeable.

Therefore Homebrew changed their installation routine and migrated the installation folder to /usr/local/homebrew in order to circumvent the whole permissions issues.

Install Homebrew

The following Terminal command will download and install Homebrew. Ruby comes pre-installed with macOS and therefore just copy and paste the following command in your Terminal:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Homebrew requires the command line tools which ship with Xcode. If you don’t have Xcode or the command line tools installed, macOS will automatically prompt you to install them. You can get away with the command line tools by clicking install.

However, you can also get Xcode by downloading it free of charge from the AppStore. Here, I will simply install the command line tools.

To check for any issues after the installation, run:

brew doctor

To search for an application:

brew search <application_name>

To install an application:

brew install <application_name>

To list all applications installed by Homebrew:

brew list

To remove an installation application:

brew remove <application_name>

To update Homebrew:

brew update

Fixing brew after upgrade to macOS 10.12

If you had brew installed before upgrading to macOS 10.12 you will notice that the upgrade broke brew. The following instructions will fix the broken install and will let you upgrade brew to the latest and greatest which supports 10.12

Accept the license agreement of the command line tools shipped with Xcode

sudo xcodebuild -license

Change ownership of /usr/local to yourself:

sudo chown -R $(whoami) /usr/local

Run brew doctor and brew update. The installer of the update will inform you that it will migrate the brew repository to a new directory:

brew doctor && brew update

=> Migrating HOMEBREW_REPOSITORY (please wait)...
==> Migrated HOMEBREW_REPOSITORY to /usr/local/Homebrew!
Homebrew no longer needs to have ownership of /usr/local. If you wish you can return /usr/local to its default ownership with:
sudo chown root:wheel /usr/local

Change the owner back to the defaults with:

sudo chown root:wheel /usr/local