defanive

回复 36# lllsoslll
修改其他进程的环境变量早已实现，无需注入也可以，CAPI的非注入版就使用的此方法
至于免杀我十分感兴趣，方法差不多不知为何他们可以做到

defanive

回复 38# 3dnowex
我的意思就是这样，批处理要判断自己是不是在x64环境下
如果是的话，批处理需要自己启动WOW64下的cmd.exe，这时候才是32位进程，才可以注入

defanive

更新：1.1, Build 1D8B0, x32

defanive

回复 32# garyng
修改函数头的JMP跳转

defanive

回复 42# garyng
不会，怎么会呢？
执行API都是把代码跳转到API的代码处执行，我把API的代码改成了JMP到我的函数
因此只要是调用API都会JMP到我的函数

defanive

回复 44# garyng
我的方法比较巧妙，不需要恢复API
原理很简单，仔细研究一下API的函数头就知道了
而且你说的也对，CMD是单线程的，不会出现这种情况
我的方法只是为了提高速度而已

defanive

回复 46# garyng
嗯都是这样的，不是么

defanive

回复 49# 3dnowex
这个比较奇怪，我试了一下，IE对象的其他方法和属性调用都正常
但是Navigate和Navigate2调用会导致崩溃
原因暂时不明，正在研究中

defanive

回复 51# 3dnowex
这正是我在开发手记里面说的那个想法，结果是失败了
一切都做得很正常，但是唯一的问题在于，新线程返回到旧的执行点的时候，会有问题
CMD不是用独立的内存保存批处理代码执行位置的，也就是说新线程的批处理代码执行位置会把旧线程的位置代替掉
所以说杯具了，尽管调用了新线程，但是没办法返回到之前执行的位置
PS 有另外一个新想法，正在试验中

defanive

回复 53# netbenton
我很喜欢返回变量名的想法，但是暂时似乎没有办法做到
set语句的处理是在cmd内部进行的，处理完最后再调用SetEnvironmentVariableW
所以除非有办法找到处理set的代码位置，不然都没办法做任何处理
对于多行命令同时执行的话，我认为没什么必要
这种多个命令同时执行是普通第三方遗留下来的传统
普通的第三方是启动新进程，因此启动进程的时间远远大于实际执行代码的时间
所以说把多行代码合并在一起就可以省去启动进程的时间
但是CAPI是基于注入的，所以说实际上跳转到钩子函数的耗时基本上非常少（我本机测试，20000条set命令，加了钩子只比不加钩子慢了0.06s）
所以说这样对速度的提升并没有很显著的效果
直接set CAPI=xxx&set CAPI=yyy基本上就可以做到一样了（虽然看起来稍微难看一点）
返回变量名是一个很好的想法，以为很直接的省去了set xxx=%CAPI_Ret%这一行命令
但是杯具的是貌似没办法做成set /CAPI ret_var=xxx的语法
最多可以做成set CAPI=ret_var xxx，但是这样大改语法结构了
总之谢谢建议，对于CAPI的语法调用问题我还是觉得很蛋疼，已经尽量尝试做到最好了
目前大致的结构是set CAPI=[主类] [子类] [标识符][参数1] [标识符][参数2] ...
将命令分成主类和子类是为了减少程序员的记忆量，也让代码容易阅读

defanive

回复 56# 3dnowex
麻烦的在于不同版本的cmd函数地址也不一样，不方便做判断
cmd没有一个开放给外界的接口，很蛋疼 = =
感觉走到最后都只能走回API Hook的路上

defanive

更新：1.2, Build 1D910, x32