BurpCrypto未来开发计划

不知不觉中BurpCrypto从诞生到现在已经一岁半了,在这段时间里我对插件的基础功能进行了持续的Bug修复与优化,并在0.1.9版本中加入有史以来最重磅的功能 — 多JS引擎切换功能。

为什么需要多JS引擎切换

因为各个JS库的兼容性、功能完善性和运行性能差异问题,我加入了市面上最常见的三种可以嵌入Java内的运行库。

Rhino

Rhino运行库为目前兼容性最强的库,也是目前的默认引擎,其目前由Mozilla基金会负责开发与管理,没错就是Firefox相同的开发团队,这意味这它将会最快的获得最新的Js特性。除了不支持XHR以外,它几乎是最完美的JS引擎。不过从网络上也搜集到了关于Rhino直接调用Java组件实现网络请求的方式,如果可能的话,后续将会提供直接在该引擎内使用Java的org.apache.commons.httpclient组件实现网络请求的方法。

Jre Built-In

顾名思义,该引擎是集成在Jre中的ScriptEngine组件,也是BurpCrypto最初使用的JS引擎,这意味着它将获得最强的稳定性,但是也意味着它的功能陈旧,JS兼容性较差,不过好在性能还算可以,所以在0.1.9版本以引擎切换的契机重新回归。

HtmlUnit

该组件为0.1.9中新加入的引擎,该引擎最大的亮点为不仅支持JS引擎,而且支持无头HTML渲染,同时它也是目前唯一的,支持XHR的JS引擎,这将使网络请求支持成为现实,但是它也有不可避免的缺陷,该组件的冷启动极慢,组件体积较大(0.1.9版本文件体积直接接近20MB),内存、CPU占用率高,如果是性能较差的电脑可能在点击Start Attack后直接卡死 😥。

多种引擎切换的到来也导致上手难度直线上升,可能大多数用户需要爬不少坑才会领会各个引擎的特点与功能优势,于是我在某天突然有个想法,为什么不像maven一样做一个官方的JS仓库自动解决依赖关系呢,于是BurpCrypto-JsLibrary诞生了。

该仓库主要解决的问题是,在面对复杂系统的时候降低重复的工作量,对市面上常见的加解密、编解码库进行收集,并预先测试其兼容性,提供引擎使用建议、JS库的代码提示,用户使用时像maven一样使用UI直接搜索关键字引入即可,同时为了降低贡献门槛、提供较强可读性,使用yaml作为库描述文件,目前初步的schema如下:

- name: MD5                                     # 库的名字,唯一的
  description: MD5 Message-Digest Algorithm     # 库的描述信息
  author: Whwlsfb(https://github.com/whwlsfb/)  # 作者信息 
  engine:                                       # 您测试通过的并且推荐使用的JS引擎,可写多个,目前可用的引擎有:[Rhino, JreBuiltIn, HtmlUnit]
    - Rhino
  path:                                         # 您的JS库在本项目中的路径,可写多个。将按照顺序载入。
    - lib/md5.js
  functionCase:                                 # JS库的函数列表,用户将通过该信息直接插入函数。
    - functionName: md5
      useCase: |                                # $PARM$ 是用户在代码编辑器中选中的文字,将会被`useCase`替换.
        md5($PARM$);
  example: |                                    # 该代码库的使用示例.
    md5('123456');
    > e10adc3949ba59abbe56e057f20f883e

目前设想的远程ExecJs模块的运行逻辑大概如下:

目前该功能仍处于规划阶段,如果各位师傅有什么建议也欢迎提出。

其他功能

BurpCrypto走到今日,除部分小众功能外(国密算法、ExecJS直接调用内置模块),功能已经接近过饱和,在远程ExecJs模块开发完成后将逐渐走入Bug修复阶段并不再加入新功能,留出时间开发新工具。

留下评论

您的电子邮箱地址不会被公开。 必填项已用*标注