当软件的发布流程接入了自动构建之后，不少团队习惯把Themida的保护操作直接放进批处理或是CI流水线里去执行，这时候就要搞清楚命令行方式下Themida该怎么打包，以及命令行里那些参数之间的顺序又该怎样去核对；其中比较关键的一步，是先在图形界面上把各项保护设置都保存成tmd工程文件，然后再用命令行去调用这同一套配置，免得每次都手敲一大堆选项。官方帮助文档也说明，要通过命令行完成保护，需要先建好一个Themida的项目文件，再借助保护命令去真正执行打包。

　　一、Themida命令行打包怎么使用

　　从空白的命令行参数开始摸索，并不是一个太可靠的办法，更稳的路线是，先打开图形界面把保护选项、宏设定、输出目录以及兼容性那些参数都配好，再把它们统一存进一个工程文件里，往后让命令行直接去读取它就行。

　　1、先建好tmd工程

　　打开Themida的窗口界面，把需要保护的exe或者dll载入进来，然后按照需求，把保护手段、代码虚拟化要针对哪些函数、要不要对资源部分进行加密、保护完之后输出的文件名，还有兼容性方面的几个选项，逐项都设置妥当；等用图形界面跑过一次保护并且能够正常生成，再把这份配置存为一个tmd格式的工程文件，这样就能拿来当作命令行调用的底本了，后面不需要再反复去点窗口。

　　2、用基础命令执行保护

　　往命令行里切进Themida的安装目录，随后敲入一条类似这样的命令：Themida.exe/protect YourProjectFile.tmd，官方给出的基本形式就是靠/protect这个参数加上工程文件去跑；执行成功之后，Themida会根据工程文件里面先前保存好的输入文件和输出文件设定，在指定位置生成保护过的程序，这一步操作者不用再多写其他路径，只要工程文件本身的内容是正确的就行。

　　3、临时覆盖输入和输出路径

　　如果手头有好几个不同的应用程序，但它们实际上都用同一套保护规则，那么可以在命令行里直接把输入文件和输出文件的路径给临时换掉，而不必去改动工程文件本身，写法类似这样：Themida.exe/protect YourProjectFile.tmd/inputfile App.exe/outputfile App_protected.exe，这样工具就会用后面给的App.exe作为输入，并把结果写到App_protected.exe中去；官方文档也提到，命令行保护时允许指定与项目文件里不一样的输入输出程序，这个做法在批量化处理时相当灵活。

　　4、接到批处理脚本或流水线里

　　当需要把Themida命令放进BAT、PowerShell或者CI任务中去执行的时候，最好使用绝对路径，而且路径里一旦夹着空格，务必要用双引号把整个路径包起来；同时，也建议把命令执行时产生的输出信息重定向到一个日志文件里，因为日后如果打包失败了，直接翻看保存下来的日志，比盯着屏幕上一闪而过的提示要容易定位很多。

　　二、Themida命令行参数顺序怎么检查

　　参数顺序一旦弄乱了，常见的表现是工具认不出项目文件、明明写了输入文件却被当成别的什么东西，或者输出仍然跑到了工程文件原来设定的老目录里去，所以在检查的时候，重点要盯住/protect、项目文件、/inputfile和/outputfile这几组是不是成对地放在了正确的位置。

　　1、确认/protect紧挨着项目文件

　　/protect这个参数的后面，必须紧跟着一个tmd项目文件，万一不小心把要保护的exe直接放在了/protect后面，Themida就会错误地把exe当成工程文件来读，然后马上提示项目不存在或是无效；因此，在写整条命令时，第一件事就是看/protect后面是不是正确指向了那个tmd文件，中间不能插进别的参数，这一步错了后面的配置全都白费。

　　2、检查输入和输出参数是否成对

　　/inputfile后面要紧跟准备保护的原始程序，/outputfile后面则必须是保护完成以后的目标路径，这两对最好同时出现，而且如果路径里面带有空格，一定要加上双引号，像下面这种格式就很清楚：Themida.exe/protect"D:ProtectBase.tmd"/inputfile"D:BuildApp.exe"/outputfile"D:ReleaseApp.exe"；要是少写了引号，空格前后的字符就会被当成不同的参数，执行的走向就会乱掉。

　　3、不要混用旧工程里存着的输出路径

　　如果命令行里只写了/inputfile却没有写/outputfile，那么Themida很可能继续按照工程文件原来保存的输出路径去生成结果，这样一来，可能不小心就把上一轮保留下来的文件给盖掉了；所以，在构建脚本里最好还是同时把输入和输出这两条路径都明明白白地写上去，避免依赖工程文件里存着的默认位置，这样可以减少很多意外覆盖的情况，也让每次生成的文件去向更清晰。

　　三、Themida命令行打包失败怎么排查

　　打包失败之后，别只是盯着屏幕最后那一点点提示，应当先去瞧一眼返回码，再顺着项目文件、输入文件、输出目录的权限以及宏配置这几个方向逐一去看，这样排查会比较有条理，也更容易把真实原因找出来。

　　1、先查看返回码

　　Themida命令执行结束会返回一个数字，官方帮助里列出了几个常见的返回码，比如0代表保护已经顺利完成，1表示项目文件不存在或者它的内容是坏的，2是说准备保护的那个文件打不开，3说明文件已经被保护过一遍了，4代表SecureEngine宏这边出了差错，6则是输出文件没办法写入磁盘；先把返回码抓出来再对照文档，就能快速把排查的大方向定下来，不至于盲目地去改命令。

　　2、检查文件是不是被占用了

　　如果返回的结果提示文件打不开，那么应该先想一想，原始的那个exe是不是还正在运行着，本地安装的杀毒软件有没有悄悄把它暂时锁住，又或者前面的构建工具还没有把文件句柄释放掉；而对于写入失败的情况，更要回头去看输出目录有没有写权限，以及同名文件此刻是不是正被其他程序占着，这些问题常常比命令本身更容易引发错误，所以一定要先排查。

　　3、确认是不是进行了重复保护

　　有时候，流水线里会把之前已经保护过的产物又当作原始输入传给了Themida，这样工具就会报出类似“文件已经被保护”这类的提示，所以在脚本里，一定要清楚地分清“原始构建出来的文件”和“经过保护之后的文件”这两样东西，不要让上一轮的输出一不小心就变成了这一轮的输入，只要把两者存放的目录区分开来，就可以从流程上避免掉这种尴尬。

　　总结

　　用Themida做命令行打包，比较稳当的操作顺序可以归纳为：先在图形界面里配好保护选项并保存tmd工程，再用/protect挂上工程文件去执行，必要时通过/inputfile和/outputfile临时把路径换掉；在核对参数顺序的时候，尤其要盯着/protect后面是不是项目文件、输入输出路径有没有成对出现、路径里的空格有没有用引号罩住；万一碰到打包失败，最优先的一步是去读取返回码，接着才去排查文件占用、重复保护、输出目录权限和宏配置这些问题，按照这条路线去定位，往往能少走很多弯路。