|
本帖最后由 keke1023 于 2023-12-23 15:26 编辑
既然日志里能看到加解密的指令,那么这个指令到底来自于哪里呢,昨晚用ida看了一下cmapd引用的几个so终于找到了,这下满足了哈哈哈
--------------------------------再次探索的分割线--------------------------------
根据lgs2007m的提醒,原来从日志可以看到配置文件加解密的具体指令,那这样就可以直接解密配置文件修改后再恢复啦~具体过程在
https://www.right.com.cn/forum/f ... 70&pid=19453894
https://www.right.com.cn/forum/thread-8316001-1-1.html
我之前没看到这两个帖子,不知道原来日志里有详细的指令,还想着是不是要逆向那两个elf。。。
--------------------------------探索的分割线--------------------------------
首先要感谢nyin发布的贴子rax3000m 1027的最新版-免拆开启 ssh-简单制作,这里实际上已经提供了可用的配置文件,但是说是稍后会写的制作过程暂时还没看到,我就自己先研究一下
他的研究过程我猜测是通过ttl修改配置后备份出来实现的,而我因为有了他的成果,可以直接开了ssh后再去探索,就不用拆机啦~
下来我提供一下我的探索过程,有助于大家以后研究相近的情况
1.首先就是使用nyin发布的配置导入后开启ssh,备份出所有的分区
2.在这些分区中,发现了fwk和fwk2分区各有一个系统,以及ubi分区里也是有两个系统
3.解包发现ubi分区里的是原生openwrt固件,fwk分区的是运营商固件
4.在运营商固件的/www/admin/js查到两个js文件,分别是chunk-2d0c1589.1696818048446.js和chunk-2d0dda1e.1696818048446.js,里面提到了调用的过程
exportConfig: function() {
var e = this;
this.$loading_tool({
loading: !0
}), this.$axiosRequest_un({
key: "cmap",
method: "configexport",
cmd: 255
}).then((function(t) {
e.$loading_tool({
loading: !1
}), t.success ? (e.$message.success(e.$t("tips.setSuccess")), e.$refs.export_config.click()) : e.$message.error(e.$t("tips.setFail"))
}))
},
downloadFile: function(e) {
var t = this,
n = "";
n = "log" == e ? this.filepath : "/aptmp/cfg_export_config_file.conf";
var a = new XMLHttpRequest;
a.open("GET", n, !0), a.responseType = "blob", a.onload = function() {
if (200 === a.status) {
var e = a.response,
o = new FileReader;
o.onloadend = function() {
o.readyState === FileReader.DONE && t.$axiosRequest_un({
key: "deletefile",
path: n,
cmd: 255
})
}, o.readAsDataURL(e)
}
}, a.send()
},
也就是它执行的过程是先导出配置,然后紧接着就下载并删除源文件
5.在原生系统里发现了/usr/bin/fwk.sh,发现他们之间的关系,运营商固件运行在容器里挂载在/tmp/cmcc/framework,可以通过fwk.sh console进入跟它的交互
6.在进入容器交互界面,再在网页端进行操作时,可以在交互界面看到相应的日志信息,备份配置时可以看到
[middleware_cgi.c][api_process,1318]: key:cmap
[middleware_cgi.c][api_process,1318]: key:cmap.deletefile
[middleware_cgi.c][api_process,1530]: File deletion succeeded
这个信息就跟之前js文件的发现对应上了,但是到这里我还是不知道是通过什么方式调用的cmap
7.通过在原生系统文件的发掘发现了/tmp/cmcc/framework/rootfs/etc/init.d/hmzj文件里HMZJ_DISABLE=`ubus-out.sh call cmap.hmzjconfig get | grep hmzjdisable |awk -F ":" '{print $2}'`这一句提到了cmap的调用
8.通过查看ubus-out.sh明白了实际上是通过ubus在调用cmap,在容器里通过ubus-out.sh call cmap configexport就可以导出配置(其实不进容器直接ubus call cmap configexport是一样的),通过monitor看到了整个过程和json内容
<- b5125f64 #00000000 lookup: {"objpath":"cmap"}
-> b5125f64 #00000000 data: {"objpath":"cmap","objid":-1809144147,"objtype":1792171111,"signature":{"upgrade":{"downurl":3,"isreboot":5},"configimport":{"file":3},"configupgrade":{"file":3},"reboot":{},"reset":{0,"resetlevel":5},"configexport":{},"tcpdump":{"interface":5,"captime":5}}}
-> b5125f64 #00000000 status: {"status":0}
<- b5125f64 #942aa6ad invoke: {"objid":-1809144147,"method":"configexport","data":{}}
-> 266a634d #b5125f64 invoke: {"objid":-1809144147,"method":"configexport","data":{},"user":"root","group":"root"}
<- 266a634d #b5125f64 data: {"objid":-1809144147,"data":{"result":"0"}}
-> b5125f64 #942aa6ad data: {"objid":-1809144147,"data":{"result":"0"}}
9.然后就可以在/tmp下找到cfg_export_config_file.conf文件,因为没有执行后面的deletefile,所以文件还在,初始状态下有26k
10.在原生luci里执行配置备份,这是一个没有加密过的tar.gz压缩包,解压记录下备份的所有文件,然后开始删减/etc文件夹中对应的文件
11.发现group,passwd不能删除,不然ubus将没法调用
12.最终将配置备份里对应的文件删除至只剩下/etc/config/dropbear(开ssh),/etc/config/uhttpd(开原生luci),/etc/group(必须),/etc/passwd(必须),/etc/shadow(原生luci和ssh密码)这五个文件,然后再次执行ubus-out.sh call cmap configexport
13.在/tmp文件夹得到最终的cfg_export_config_file.conf,不到2k,这就是最终精简的配置文件了(跟nyin的相同,他就保留的这五个吧),还可以根据自己需求删改/etc/config/uhttpd和/etc/shadow
14.cfg_export_config_file.conf通过用winhex查看是Salted__开头的加盐加密文件,解不开所以只能制作需要的配置备份来实现
这就是我昨天到今天研究的过程了,虽然看起来好像挺简单的,就是ubus调用一下cmap,但是想要找出这个过程还是挺花时间,希望对大家有启发
下来就看有没有大佬能逆向出加密的过程,可能跟middleware_cgi和cmapd有关吧
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
×
|