base64

MISC 签到题 扫码关注微信公众号即可获得flag 这是一张单纯的图片 用UE打开如图，在ascii码最下面发现一串编码，发现是字符实体编码。 https://www.qqxiuzi.cn/bianma/zifushiti.php 网站在线解码可得flag 隐写 打开图片，先用stegsolve跑一边没有发现什么，LSB也没有什么，用UE打开也没有什么奇怪的。用binwalk跑一边，没有隐藏文件。 所以考虑是不是高度修改，在IHDR后面将高度改大一些，果然发现flag ## telnet 用wireshark打开流量包，在telent包的data中发现flag 眼见非实(ISCCCTF) 下载文件后，用UE打开发现是PK开头，则是zip压缩包 改后缀后解压得到一个docx文件，猜测可能是zip包。 docx文件本质上就是一个zip压缩包，文件内容在zip压缩包中（文本内容，字体格式等等）。 改后缀为zip后打开 发现一些文件，没有明显的flag信息，但应该就在这些文件里。 一个个用firefox打开，F3快速查找。 得到flag. 啊哒 下载后发现是jpg文件，可能不是LSB隐写（png才有lsb隐写），用stagsolve跑了一下果然没有。用UE打开发现文件比较大，可能有藏东西。 用binwalk跑一下，果然有zip文件。 而且就是flag.txt

什么是JWT 　　Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（ (RFC 7519 ).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。 Token认证和Session认证的区别　 　　传统的session认证 　　　　我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。 但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来. 　

看到之后有点懵逼 然后下载 下载之后发现是一个pacp后缀的流量数据包 然后用wireshark 然后只想到了 http过滤 然后发现不对 然后参考其他人的博客 经大佬提示， 一般 getshell 流的 TCP 的 报文中很可能包含 command 这个字段， 我们可以通过< 协议 contains “内 容” >来查找 getshell 流 通过追踪 tcp 流， 我们可以看到一段 base64 字符串 base64 解密， 得到 flag 总结 这题主要难在不知道怎么找 getshell 流， 需要对各种报文以及 wireshark 的使 用方法比较熟悉， 可以参考下面的博客去进行学习 https://www.cnblogs.com/dragonir/p/6219541.html 作者：Ro0t 链接：https://www.jianshu.com/p/3efa609cc652 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 来源： https://www.cnblogs.com/ainv-123/p/12293559.html

https://www.cnblogs.com/keeye/p/12250864.html 来源： https://www.cnblogs.com/dosu/p/12290563.html

https://www.cnblogs.com/chnking/archive/2007/08/12/852669.html 一、 BASE64 编码 把byte[]中的元素当做无符号八位整数转换成只含有64个基本字符的字符串，这些基本字符是： l 大写的A-Z l 小写的a-z l 数字0-9 l '+' 和 '/' 这64个字符构成BASE64的字符集。‘=’，为填充字符，结尾处可以填充0-2个填充字符 Base64是将原文按照每 3 个字节一组分开，这个 3 字节组中的每一组将被按照位分解成 4 个部分，每个部分 6 个位，在这 4 个部分的每个部分高位加上 2 个 0构成一个新的 4 字节组，新的字节组中，每个字节只有 6 位，能表示64个值。 在原文在转换为BASE64编码时，试是以3个字节为一组转换成4字节一组的BASE64编码。如果原文不是三字节的倍数，可能多出一个字节和两个字节，分别会被转为2字节和3字节的BASE64编码，这时编码系统应该在形成的BASE64编码最后添加上填充符”=”，保证BASE64编码长度是4的倍数。所以在BASE64编码后添加的填充符”=”可能为0-2个。 BASE64编码对照表如下： Value Encoding Value Encoding Value Encoding Value Encoding 0 A 16 Q 32 g 48 w

语法  alt text:可选,图片标签,用来描述的关键词,图片加载错误时候的替代文本,也可用于SEO. uri: 可选,图片链接,可以是本地/网络/base64编码地址. optional title:可选,鼠标移动到图片上显示的标题. 本地图片  本地图片可以使用绝对路径/相对路径,不便于分享. 网络图片  网络图片存在于你的/别人的服务器上,可通过网络地址直接引用,但依赖网络. base64编码图片  上面的base64图片用法,通常会文章中间出现一大长串base64字符,非常影响编写排版和复用,可以如下独立复用. ![base图片][image-base64Str] # .md 文章末尾统一写复用的内容 [image-base64Str]:data:image/png;base64,dsjkadd... 不过base64也有个问题,比如我要在多篇文章中使用同一个图片呢? So,大家看着用吧... 来源： https://www.cnblogs.com/taadis/p/12285525.html

1.Tomcat服务器是一个免费的 开放源代码 的 Web 应用服务器。是一个小型的轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP程序的首选，实际上Tomcat部分是Apache服务器的扩展，但它是独立运行的，所以当你运行tomcat时，它实际上作为一个与 Apache 独立的 进程 单独运行的。 　　　　　　　　Tomcat 默认路径 ： manger/html 　　　　　　　　　　　默认密码：tomcat : tomcat 　　　　　　　　　　　端口号：8080 2.一些网站管理人员利用方便，不会去更改管理地址。可以很简单的使用默认路径去找到对方后台登录。或者利用一些常见的路径或者burp中的目录抓取去找到对方后台登录。 　　找到后台以后可以尝试弱口令或者默认密码去尝试，或者使用弱口令字典去跑。例如：burp 或者自己编写脚本。 　 案例： 　　　（1）.对方开启tomcat服务。 　　　（2）.尝试以上方法找到对方后台。 　　　（3）.进行弱口令密码破解。 　　　　　　使用burp抓包： 　　　　　　　　　　　　 　　　　　明明使用的是明文，抓取的确实加密过的。base64进行解密后发现是我自己的明文。个人猜测：前端做了base64的加密。 　　　　　使用burp进行暴力破解，那就需要使用base64的加密去跑字典。