LovelyRitoru续篇-插件流程梳理

作者Tokeii不知为什么把项目给删了。这里简要谈谈项目思路

插件分三类

check_plugin

base_plugin

ex_plugin

‍

具体执行顺序是

check_plugin=>base_plugin=>ex_plugin=>check_plugin

每个插件类型内部还有小循环。生成的新文件全部放入output文件夹里，新的文件会继续运行插件，直到当前插件类型已经没有新文件产生。接着进入下一个循环。

给出的示例里，checkplugin有check_flag check_password。一个可以获得flag，一个可以获得password。

base_plugin的示例里面是unzip和base64

ex_plugin里则是exiftool

‍

尽管如此，在实际执行中，存在顺序上的问题，最后一次执行时并不能正确识别之前生成的内容，所以开发时修改了代码逻辑，在走完一遍check_plugin=>base_plugin=>ex_plugin逻辑后，对output文件夹里的内容，额外进行一次check_plugin。

‍

同时思考这三类插件的定位。

check_plugin一定是用于最基础的，获取flag,填充password。毫无疑问是归类于check_plugin。但是思考整个流程unzip应该在base_plugin吗？

未必见得，unzip可能放在check_plugin更合适，因为在一道题的起点，很可能需要解压缩，因此解压缩的位置应当在流程里尽可能的靠前。

接着base_plugin位于整个流程的中间，应当尽可能的把会产生新文件的流程放在这里，把base64解码放在这里是合适的。按照定义，把gif图片分解的插件也应当放在这里。

最后是ex_plugin，由于在流程最后，这里不再适合生成很多新的文件了，最好把能直接出flag的步骤放这里，最后一步，诸如隐写之类的，放在这里是合适的。

‍

理清插件流程后，下一步就是在此基础上开发插件。

这个模块对应的目标是解单文件的、套娃的隐写题目，包括图片隐写、文本隐写、音频隐写、视频隐写、压缩包隐写等模块。

‍

下一篇开始介绍插件编写和实际运行中产生的新问题。

‍

原文始发于微信公众号（BlueIris）：LovelyRitoru续篇-插件流程梳理