Thougts to Share! Share Some Thoughts!

Just a week after Apple released its brand new iPhone X on November 3, a team of researchers has claimed to successfully hack Apple's Face ID facial recognition technology with a mask that costs less than $150. They said Apple iPhone x face id can be hacked with silicon mask easily.

apple iPhone x face id hacked
Yes, Apple's "ultra-secure" Face ID security for the iPhone X is not as secure as the company claimed during its launch event in September this year.

"Apple engineering teams have even gone and worked with professional mask makers and makeup artists in Hollywood to protect against these attempts to beat Face ID," Apple's senior VP of worldwide marketing Phil Schiller said about Face ID system during the event.

"These are actual masks used by the engineering team to train the neural network to protect against them in Face ID."

However, the bad news is that researchers from Vietnamese cybersecurity firm Bkav were able to unlock the iPhone X using a mask.

Yes, Bkav researchers have a better option than holding it up to your face while you sleep. Bkav researchers re-created the owner's face through a combination of 3D printed mask, makeup, and 2D images with some "special processing done on the cheeks and around the face, where there are large skin areas" and the nose is created from silicone.

The researchers have also published a proof-of-concept video, showing the brand-new iPhone X first being unlocked using the specially constructed mask, and then using the Bkav researcher's face, in just one go.

"Many people in the world have tried different kinds of masks but all failed. It is because we understand how AI of Face ID works and how to bypass it," an FAQ on the Bkav website said.

"You can try it out with your own iPhone X, the phone shall recognize you even when you cover a half of your face. It means the recognition mechanism is not as strict as you think, Apple seems to rely too much on Face ID's AI. We just need a half face to create the mask. It was even simpler than we ourselves had thought."

Researchers explain that their "proof-of-concept" demo took about five days after they got iPhone X on November 5th. They also said the demo was performed against one of their team member's face without training iPhone X to recognize any components of the mask.

"We used a popular 3D printer. The nose was made by a handmade artist. We use 2D printing for other parts (similar to how we tricked Face Recognition 9 years ago). The skin was also hand-made to trick Apple's AI," the firm said.

The security firm said it cost the company around $150 for parts (which did not include a 3D printer), though it did not specify how many attempts its researchers took them to bypass the security of Apple's Face ID.

It should be noted that creating such a mask to unlock someone's iPhone is a time-consuming process and it is not possible to hack into a random person's iPhone.

However, if you prefer privacy and security over convenience, we highly recommend you to use a passcode instead of fingerprint or Face ID to unlock your phone.

Related word

1. Overview

Is an elf32 static and stripped binary, but the good news is that it was compiled with gcc and it will not have shitty runtimes and libs to fingerprint, just the libc ... and libprhrhead
This binary is writed by Ricardo J Rodrigez

When it's executed, it seems that is computing the flag:

But this process never ends .... let's see what strace say:

There is a thread deadlock, maybe the start point can be looking in IDA the xrefs of 0x403a85
Maybe we can think about an encrypted flag that is not decrypting because of the lock.

This can be solved in two ways:

static: understanding the cryptosystem and programming our own decryptor
dynamic: fixing the the binary and running it (hard: antidebug, futex, rands ...)

At first sight I thought that dynamic approach were quicker, but it turned more complex than the static approach.

2. Static approach

Crawling the xrefs to the futex, it is possible to locate the main:

With libc/libpthread function fingerprinting or a bit of manual work, we have the symbols, here is the main, where 255 threads are created and joined, when the threads end, the xor key is calculated and it calls the print_flag:

The code of the thread is passed to the libc_pthread_create, IDA recognize this area as data but can be selected as code and function.

This is the thread code decompiled, where we can observe two infinite loops for ptrace detection and preload (although is static) this antidebug/antihook are easy to detect at this point.

we have to observe the important thing, is the key random?? well, with the same seed the random sequence will be the same, then the key is "hidden" in the predictability of the random.

If the threads are not executed on the creation order, the key will be wrong because is xored with the th_id which is the identify of current thread.

The print_key function, do the xor between the key and the flag_cyphertext byte by byte.

And here we have the seed and the first bytes of the cypher-text:

With radare we can convert this to a c variable quickly:

And here is the flag cyphertext:

And with some radare magics, we have the c initialized array:

radare, is full featured :)

With a bit of rand() calibration here is the solution ...

The code:
https://github.com/NocONName/CTF_NcN2k15/blob/master/theAnswer/solution.c

3. The Dynamic Approach

First we have to patch the anti-debugs, on beginning of the thread there is two evident anti-debugs (well anti preload hook and anti ptrace debugging) the infinite loop also makes the anti-debug more evident:

There are also a third anti-debug, a bit more silent, if detects a debugger trough the first available descriptor, and here comes the fucking part, don't crash the execution, the execution continues but the seed is modified a bit, then the decryption key will not be ok.

Ok, the seed is incremented by one, this could be a normal program feature, but this is only triggered if the fileno(open("/","r")) > 3 this is a well known anti-debug, that also can be seen from a traced execution.

Ok, just one byte patch, seed+=1 to seed+=0, (add eax, 1 to add eax, 0)

before:

after:

To patch the two infinite loops, just nop the two bytes of each jmp $-0

Ok, but repairing this binary is harder than building a decryptor, we need to fix more things:

The sleep(randInt(1,3)) of the beginning of the thread to execute the threads in the correct order
Modify the pthread_cond_wait to avoid the futex()
We also need to calibrate de rand() to get the key (just patch the sleep and add other rand() before the pthread_create loop

Adding the extra rand() can be done with a patch because from gdb is not possible to make a call rand() in this binary.

With this modifications, the binary will print the key by itself.

More info

Thougts to Share! Share Some Thoughts!

1225 hash passwords

APPLE IPHONE X FACE ID CAN BE HACKED WITH SILICON MASK

Related word

NcN 2015 CTF - theAnswer Writeup

Acrostic Poems

Current Events

All About Harry Potter!

Heros

Thoughts to Share!

Sharings