|
|
本帖最后由 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有关吧
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？立即注册
×
|
简体中文
繁體中文
English
日本語
Deutsch
한국 사람
بالعربية
TÜRKÇE
português
คนไทย
IP卡
狗仔卡
置顶卡
沉默卡
喧嚣卡
顶贴卡
显身卡
