1. 如何反编译D-Link路由器固件程序并发现它的后门
本来就有,不是厂商设置,就是有关部们设置的;懂的人不会问,不懂的也教不会;欢迎追问~!
2. 怎样解包安卓的固件bin文件。得到里面的文件
使用UltralISO解包需要提取的固件bin文件并将得到的文件保存在目标文件夹中即可得到里面的文件。
对于文件类资料保存到数据库中,使用分块传输与存储可以有效提高应用效率,另外通过测试关系型数据库和文件型数据库对此类应用的性能,发现文件类数据库的性能优势比较明显。
围绕二进制文件基于数据库存取存在速度慢、占用资源多的问题,通过对BS上传文件原理的分析,通过数据与文件分开存储,文件切割上传的方法实现二进制文件基于数据库的高速存取。
(2)固件反编译扩展阅读:
bin文件的作用:
二进制文件,其用途依系统或应用而定。一种文件格式binary的缩写。一个后缀名为".bin"的文件,只是表明它是binary格式。
比如虚拟光驱文件常用".bin"作为后缀,但并不意味着所有的bin文件都是虚拟光驱文件。它是机器代码,汇编语言编译后的结果,用debug、WINHEX,U_EDIT等软件可以打开。
这类所有的文件,无论后缀名是什么,一律分为两种格式".text" 和".binary"。
3. 怎么反编译D-Link路由器固件程序并发现它的后门
基于上面的字符信息可以看出,这个/bin/webs二进制程序是一个修改版的thttpd,提供路由器管理员界面操作功能。看起来是经过了台湾明泰科技(D-Link的一个子公司)的修改。他们甚至很有心计的将他们很多自定义的函数名都辅以“alpha”前缀:
明泰科技的自定义函数
这个alpha_auth_check函数看起来很有意思!
这个函数被很多地方调用,最明显的一个是来自alpha_httpd_parse_request函数:
调用alpha_auth_check函数
我们可以看到alpha_auth_check函数接收一个参数(是存放在寄存器$s2里);如果alpha_auth_check返回-1(0xFFFFFFFF),程序将会跳到alpha_httpd_parse_request的结尾处,否则,它将继续处理请求。
寄存器$s2在被alpha_auth_check函数使用前的一些操作代码显示,它是一个指向一个数据结构体的指针,里面有一个char*指针,会指向从HTTP请求里接收到的各种数据;比如HTTP头信息和请求地址URL:
$s2是一个指向一个数据结构体的指针
我们现在可以模拟出alpha_auth_check函数和数据结构体的大概样子:
struct http_request_t
{
char unknown[0xB8];
char *url; // At offset 0xB8 into the data structure
};
int alpha_auth_check(struct http_request_t *request);
alpha_auth_check本身是一个非常简单的函数。它会针对http_request_t结构体里的一些指针进行字符串strcmp比较操作,然后调用check_login函数,实际上就是身份验证检查。如果一旦有字符串比较成功或check_login成功,它会返回1;否者,它会重定向浏览器到登录页,返回-1;
alpha_auth_check函数代码片段
这些字符串比较过程看起来非常有趣。它们提取请求的URL地址(在http_request_t数据结构体的偏移量0xB8处),检查它们是否含有字符串“graphic/” 或 “public/”。这些都是位于路由器的Web目录下的公开子目录,如果请求地址包含这样的字符串,这些请求就可以不经身份认证就能执行。
然而,这最后一个strcmp却是相当的吸引眼球:
alpha_auth_check函数中一个非常有趣的字符串比较
这个操作是将http_request_t结构体中偏移量0xD0的字符串指针和字符串“xmlset_roodkcableoj28840ybtide”比较,如果字符匹配,就会跳过check_login函数,alpha_auth_check操作返回1(认证通过)。
我在谷歌上搜索了一下“xmlset_roodkcableoj28840ybtide”字符串,只发现在一个俄罗斯论坛里提到过它,说这是一个在/bin/webs里一个“非常有趣”的一行。我非常同意。
那么,这个神秘的字符串究竟是和什么东西进行比较?如果回顾一下调用路径,我们会发现http_request_t结构体被传进了好几个函数:
事实证明,http_request_t结构体中处在偏移量 0xD0处的指针是由httpd_parse_request函数赋值的:
检查HTTP头信息中的User-Agent值
将http_request_t + 0xD0指针指向头信息User-Agent字符串
这代码实际上就是:
if(strstr(header, "User-Agent:") != NULL)
{
http_request_t->0xD0 = header + strlen("User-Agent:") + strspn(header, " \t");
}
知道了http_request_t偏移量0xD0处的指针指向User-Agent头信息,我们可以推测出alpha_auth_check函数的结构:
#define AUTH_OK 1
#define AUTH_FAIL -1
int alpha_auth_check(struct http_request_t *request)
{
if(strstr(request->url, "graphic/") ||
strstr(request->url, "public/") ||
strcmp(request->user_agent, "xmlset_roodkcableoj28840ybtide") == 0)
{
return AUTH_OK;
}
else
{
// These arguments are probably user/pass or session info
if(check_login(request->0xC, request->0xE0) != 0)
{
return AUTH_OK;
}
}
return AUTH_FAIL;
}
换句话说,如果浏览器的User-Agent值是 “xmlset_roodkcableoj28840ybtide”(不带引号),你就可以不经任何认证而能访问web控制界面,能够查看/修改路由器的 设置(下面是D-Link路由器(DI-524UP)的截图,我没有 DIR-100型号的,但DI-524UP型号使用的是相同的固件):
访问型号DI-524UP路由器的主界面
基于HTML页上的源代码信息和Shodan搜索结果,差不多可以得出这样的结论:下面的这些型号的D-Link路由器将会受到影响:
DIR-100
DI-524
DI-524UP
DI-604S
DI-604UP
DI-604+
TM-G5240
除此之外,几款Planex路由器显然也是用的同样的固件程序:
BRL-04UR
BRL-04CW
4. bin文件如何反编译
用WinIso试试看
5. E4A写的APK用apktool反编译成功,但是修改后回编译时失败
1 有没有加载framework-res.apk构架?在编译一些系统程序时需要先加载framework-res.apk这个系统构架。
2 反编的文件及framework-res.apk是不是官方原版未改动过的?很多时候出错是因为反编的文件是别人或自己改动过的,建议直接从官方固件中提取文件进行编译。
3 技巧说明使用的工具是否版本过低?目前APK编译工具apktool已更新到1.5.2了,这里有本人珍藏的交互式界面版下载:点我下载
4 技巧说明以上都没有问题?反编后什么也不改回编也出错?那只有一个方法了:可以尝试一下用低版本的apktool进行反编译,然后在用高版本的apktoo工具回编译
5 打开要编译文件夹目录下的 apktool.yml,修改apkFileName参数为 非中文,问题可以解决
6 反汇编时没有生成apktool.yml,进行反汇编时,改用命令apktool d -r xx.apk xx便可以解决(加上了-r选项)
6. 路由器的固件可以自己修改并刷进去么比如只改他管理页面的一个字。
用OpenWRT,代码开源,官网可下载,允许用户自己修改、编译、增减附加功能。