Facebook now lets your friends see that you are watching the same live stream


It looks like Facebook rolled out this update letting you know that your friends are also watching/listening to the same live stream. Which means your friends can also see that you are watching the same streaming. I believe this is privacy sensitive information and it shouldn’t be turned on by default.

iswatchingThough this is supposed to be private unless you interact with the streaming (for example react or share), just opening the streaming link informs your friends that you’re on the same thing.

The other problem is that I don’t seem to find the setting to turn off this ‘feature’. And I don’t understand why Facebook turns this kind of privacy sensitive options on  by default.

Let me know if you find the location to turn off this stupid feature.



java.lang.VerifyError error after instrumenting/transforming Android apps

You might have encountered the java.lang.VerifyError DEX verification error when developing an Android app. There are several reasons for this. Most commonly being the IDE messing up with the build process and cleaning and rebuilding might solve the problem. In some cases it could also be tools that we use (for example, security tools for obfuscation). There are several resources for this case on the net and is relatively easy to fix.

However, what I wanted to write about in this post is not from the developer point of view, but rather from automated software testing point of view (that involves instrumentation or code transformation), where you have hundreds or even thousands of Android apps to test and you don’t have their source code. Here is my experience.

For a given security testing experiment of Android apps, I had to mutate apps that satisfy some mutation criteria. After the mutation is applied, I had to automatically verify whether the mutation didn’t break the app. To achieve this, I had to apply the mutation (and all the steps necessary to make app ready for install), then install the app on the emulator and test the mutated component if it crashes. In order to understand if the crash is caused by the applied mutation, I wrap the introduced statements within try-catch block and log the exception.

However, running the mutated apps on the emulator failed with the java.lang.VerifyError. The strict Runtime refused to load the “inconsistent” bytecode into the VM because it found a “Bad method” or some other reasons. This might depend on the level of instrumentation that you are applying and hence if you’re just introducing, say, a log statement only, maybe you will not encounter this problem and the instrumented app might run without a problem.

Since mutation is applied automatically in different real world apps, addressing the problem for each app is a bit difficult. For example, it is known that the Runtime will report error if we try to wrap a  synchronized block in a  try-catch block. Therefore, while doing the mutation, it will be a bit difficult (but not impossible) to first know if a call that I wrapped in a  try-catch block will eventually have a synchronized block in it. Even if I know this in advance (say, for example, during static analysis to check mutation criteria), it has no help as I cannot skip the  try-catch block since I need it to see if failure is caused by mutation and I cannot also remove the synchronized block since I will interfere with the design of the app.


This is just one case as the Android Runtime checks for several inconsistencies that were ignored during the Dalvik VM time. To mention some of inconsitences that are caught by the new Runtime:

  • extending a class that was declared final
  • overriding a package-private methods
  • invalid control-flow
  • unbalanced moniterenter/moniterexit (this might be the reason for the synchronized block but I haven’t checked the final bytecode for the said inconsistency)
  • passing wrong argument to a method


A more general solution would have been understanding what modifications are making the verification fail and improving the instrumentation. However, that is out of my scope for the moment.

So, the solution that I found is specific to my problem. Considering that the ART is introduced in Android 5 (API 21), the easiest workaround I found was using an emulator running, say, API 20. Since I know what kind of mutations I am applying and I also monitor executions, resorting to a less restrictive Runtime would’t affect the general behavior of the app under test.

Therefore, if your instrumented Android app isn’t running on the emulator for ART  java.lang.VerifyError  error, just use emulators running API level below 21 and it should be an easy workaround.


Chrome Extension “Video Downloader GetThemAll 30.0.2” might contain malware


So I have been using this extension for a while and all of a sudden it was disabled. When going to the extension to see what happened, Chrome reports that the extension contains malware and for this reason it is disabled.

What could have happened?

As it happened to other popular extensions, it could have been modified to include malicious behavior, transferred ownership to potential malicious owners, have been hacked or update included policy violating feature (e.g., download from YouTube)–but we don’t know. There is also a rumor that the extension was mining cryptocurrency. It is time to analyze version 30.0.2 in details in order to understand what information could have leaked, if any.

Though GetThemAll 30.0.3 is already available on Chrome web store, probably it is better to stay away until further results on what happened on the previous version.

A quick look at the diff of version 30.0.2 and 30.0.3 shows, the earlier has a suspicious obfuscated “background.js” file that accesses the images/video_help.png file, which also exists only in version 30.0.2.


Problems with the Moto X Style/Moto X Pure Edition (Mostly the Battery)

from: neurogadget

The Moto X Style is one of the Motorola’s flagship phones released in September 2015. It comes with Android 5.1.1 and upgradeable to Android 7 (Nougat). But the upgrade is so slow that in September 2017, they still haven’t covered many countries. Some of the specifications of the phone are as follows;

Network: GSM / CDMA / HSPA / LTE


  •  microSD, expandable up to 256GB
  • Internal 16/32/64 GB, 3GB RAM

Camera: 21MP back camera, 5MP font camera with flash


  • Hexa-core (4×1.4 GHz Cortex-A53 & 2×1.8 GHz Cortex-A57)
  • Qualcomm MSM8992 Snapdragon 808
  • GPU Adreno 418

As it can be seen, the phone has a very good specification. One of the feature that I like about this phone is the fact that it has two stereo FRONT speakers! Yes! I pretty much enjoy watching episodes on Netflix right from my phone.

The other feature that I like is the fact that when the phone is on a desk, the screen illuminates by just passing my hand over the screen to see if there are any notifications. However, other phones have a dedicated LED light showing notification (which also exists on the Moto X Style, however needs rooting and programming the phone to use the LED for notification. The only time I have seen this LED turning on is when the battery is completely dead and the phone is attached to the charger.)

Another interesting feature about this phone is the way to turn on the camera. Yes, you just shake the phone and you have the camera open. I almost never found error in the sensors and always picks up the camera whenever I shake the phone.

All these and other interesting features are useless if the phone has a bad battery. Yes, the phone comes with a very bad battery. It’s less than 2 years since I had this phone and it is already messed up. For an expensive phone like this one (500 euros in October 2015), it’s unacceptable to have a very poor quality battery. Some of the weird characteristics of the phone in relation to the battery are as follows:

  • Phone shuts down even if the battery is above 25% and won’t start unless it’s attached to the charger
  • The moment the charger is attached, the battery shows 25% (or above)
  • The phone shuts down even if the battery is above 60% when the camera (or an app using the camera) is opened
  • If you let the phone off for a while, it finally will open (as if it wants to cool down)

Since it was a weird characteristics, I didn’t think it was a battery problem. I assumed it was software issue (either some apps or the platform itself). I reset the phone and didn’t see any improvement. That’s when I decided to change the battery. I bought a kit with several screwdrivers and a non-OEM battery. I removed the back cover, unscrewed 19 of the 20 screws and had a stripped-screw on the last one. Tried for a couple of hours to unscrew this damn screw to no avail. So finally screwed back the 19 screws and attached the back cover again. Probably will try again soon when I have time.

Conclusion, the phone is very good. It has good spec, good usable features. Camera is good, screen is big and has good resolution. But, the battery sucks. It’s also impossible to get the OEM replacement battery. Therefore, unless you’re fine with carrying a power-bank all the time, I would not recommend buying this phone.


Correlation attack on a simple toy stream cipher

Let us assume a simple toy stream cipher (it could be any of the famous GSM A5/1, Bluetooth E0… stream ciphers) but with 5 registers defined by the following primitive polynomials

p[1] = x2 +               x + 1 ;          11
p[2] = x3 +               x + 1 ;         101
p[3] = x4 +               x + 1 ;       1001
p[4] = x7 +               x + 1 ;  1000001
p[5] = x8 + x7 + x2 + x + 1 ; 11000011

and a non-linear combining function f defined below

f = x1•x2•x3•x4•x5 ⊕ x4•x5 ⊕ x5;

And let’s say we know the first 32 bytes of the clear-text and cipher-text. From these we can retrieve the key-stream used for the first 32 bytes of clear-text as follows

key-stream = clear-text ⊕ cipher-text

Now we have 256 bits of key-stream. What do we want? Well, we want to know the initial states of the 5 registers so that we will be able to break later communications after the 256th bit. How can we do that? One way is to brute force all the possible value combinations of the 5 registers. That is 28 * 27 * 24 * 23 * 22 = 224 number of checks. If the polynomials were of higher order, brute forcing wouldn’t be feasible. So we need another technique to minimize our work. Now we need to see the correlation between the registers and all possible values of combining function. We use Truth Table of five variables and a 6th column holding output of f. Then we compare the output of each register and the 6th column for matches.







0 0 0   0   0   0
0 0 0 0 1 1
0 0 0 1 0 0
0 0 0 1 1 0
0 0 1 0 0 0
0 0 1 0 1 1
0 0 1 1 0 0
0 0 1 1 1 0
0 1 0 0 0 0
0 1 0 0 1 1
0 1 0 1 0 0
0 1 0 1 1 0
0 1 1 0 0 0
0 1 1 0 1 1
0 1 1 1 0 0
0 1 1 1 1 0
1 0 0 0 0 0
1 0 0 0 1 1
1 0 0 1 0 0
1 0 0 1 1 0
1 0 1 0 0 0
1 0 1 0 1 1
1 0 1 1 0 0
1 0 1 1 1 0
1 1 0 0 0 0
1 1 0 0 1 1
1 1 0 1 0 0
1 1 0 1 1 0
1 1 1 0 0 0
1 1 1 0 1 1
1 1 1 1 0 0
1 1 1 1 1 1

We see that register 5 is correlated to f (25/32 matches). Note that we can exploit the correlation of other registers as well. If we used both register 5 and other correlated register together, our final brute force attack would be significantly fast. But for now, let’s just take register 5 only and brute force the rest of the registers. Now that we know register 5 is correlated, we try all the 256 possible values of it to find the one that results with the maximum match with the key-stream. We use the following simple C code

for (i=1; i<256; i++) {
	ivR5 = i;
	for (j=0; j<256; j++) {
		R5 = (ivR5&1)==1?1:0;
		lfsr(polyR5, &ivR5, 1, 8);
	match = 0;
	for (j=0; j<256; j++) {
		if (r5[j] == key_stream[j]) match++;
	matches[i] = match;

After this run, matches[] contains the number of matches of the key-stream and the output of all possible values of register 5. Note that the lfsr() function is a modified version of Linear Feedback Shift Register (LFSR) taking the polynomial, the initial value of the register, the number of bits to output and the length of the polynomial as argument and returns the output of the register (1 or 0). Now we need to select the maximum as follows

for (i=0; i<max_match; i++) {
		max_match = matches[i];
		idx_max = i;
// idx_max will hold the initial value of R5

At this step we have the initial value of register 5. We can proceed to 27 * 24 * 23 * 22 = 216 checks for the rest of the registers (in reality, this would be significant as we eliminated the register with the highest degree). A sample code could look like the following for brute forcing the other registers.

        ivR5 = idx_max;
	for (i=1; i<128; i++) {
	   for (j=1; j<16; j++) {
              for (k=1; k<8; k++) {
		  for (l=1; l<4; l++) {					
		     ivR4 = i;
		     ivR3 = j;
		     ivR2 = k;
		     ivR1 = l;

By now we have the initial values of the 5 registers. We can decrypt and read any communication between the two parties without knowing the symmetric key they used to generate the key-stream. Cheers!

Sources of dangerous vulnerabilities

There are a lot of whitehat and blackhat security researchers out there. While the whitehat researchers inform the target company before disclosing vulnerabilities, the blackhats either use the vulnerabilities for personal activities or sell them on black market. But both kinds of researchers spend a lot of time stepping through codes around where potential vulnerabilities might exist (e.g. around input manipulation code in a hunt for buffer overflow or format string vulnerabilities).

But there are a couple of other potential tricks to facilitate the hunt. One of this is comparing binaries of critical updates that are pushed by the vendor. If we consider Windows as an example, if Microsoft pushed a critical update, say, for one of the services handled by svchost.exe, an attacker may compare the old binary with the new updated version to see where Microsoft patched the vulnerabilities. In some cases reverse-engineering the patch might also reveal the vulnerabilities. The vulnerabilities found might interest the attacker if they have remote code execution ability, local privilege escalation or any arbitrary code execution. Since not all people update their system as soon as the update is pushed, the attackers will have enough time to craft their exploit and start using. If I remember correctly, the Sasser worm (2004) used the vulnerability discovered in this way to exploit MS04-011.

The other potential source of information is Dr. Watson of Windows. When applications crash, the error reporting feature on Windows XP and later versions might leak some important information on source of error. A reverse-engineering around the location might provide information about a vulnerability in the target application. Gathering the error reporting might be done on a lab computer or from different compromised computers.

These definitely are not going to be the only ways to identify vulnerabilities from binaries.

You’re a money mule and you don’t know it?!

When I hear a news like “40 million credit card details stolen“, I used to wonder how the hackers cash out and get the money on their hands. Since it is traceable, they cannot buy anything or transfer the money. Let’s face it, hacking the accounts might be “easy” but getting the money is a bit challenging. So how do they get the money? Some of the hackers sell the credit card or bank account details to third parties to avoid the risk of getting caught while cashing out. Imagine stolen 40 million credit cards details sold at $20 each; it is still worth it for the hackers. But the story is still not complete. How do the people who bought the details get the money then? Transferring still will not work because it is traceable. Sell it to somebody else? Maybe. Keep reading.

Recently, somebody told me that he found an online job from a credible source. He told me that some people contacted him through e-mail claiming they read his CV on a career search website. And since he recently posted his CV on the website, he thought they are 100% legit. They offered him a very good salary for something that didn’t need much of his time; a 10% commission on each transaction and bonus. They also promised him a raise after the first 1 month of probation period. He was happy about it and filled in some forms and started the job. What does he have to do? Simple, give out his bank details (normally IBAN but they said he will have extra 200 euro bonus if he hands over his username and password for his online banking which obviously is to steal money from his bank account), then they will transfer him some money, then he has to withdraw 90% of the money (10% is his commission) and send it to them via Western Union. Money laundrying made easy!

But what is really going on? OK, here is the deal.  These people have a lot of stolen accounts on their hands. Since they cannot transfer the money to their account, for obvious reasons, they hire somebody (called money mule) to do the risky job. This guy told me he thought he was working with a 20+ years old financial company. Normally, since the person who is hired does not know he is doing a crime, he will go to his bank, withdraw the money and send it to the thieves. In order to avoid being traced, these people might have a fake identity to claim the money from Western Union (or related service). The money is gone. When the person who was stolen reports to the police, the police asks the bank and the bank says there was a transfer to this account. It is only the mule that will be caught while the original thieves are enjoying the money.

After doing a little research I found out that most of the thieves are from Eastern Europe. In fact, the guy told me he was supposed to send the money to Ukraine. I also noticed that most frauds (be it the Nigerian 419 scam) involve Western Union. Couldn’t this problem be minimized if Western Union outlets had asked some questions where the money came from before accepting and sending the money when the destined person resides in these countries? Off the top of my head, it seems a solution to me.

Have you ever been a money mule? Or do you know someone who was a money mule?