HFSEC——Crypto两道(base64 more和base64 harder)

  最近准备比赛,因为本身汇编学的很差,逆向和pwn没打算练,目前在网上各大CTF平台找web中下难度题目和Crypto题目练手,就在刚才,作web题目查阅资料时,突然发现这个知识点应该是以前一个Crypto题目的解法,因而兴奋地找到原题目,一番折腾后终于成功了,因而就赶忙过来发泄下本身的喜悦,而后再记录下解题过程。php

  HFSEC的两道Crypto题目都是深刻到base编码原理的。html

  第一道 base64 more
web

  题目:base64默认的字符表被修改过了~正则表达式

  给的是源码,仔细一看仍是很好理解的,是让你get方法传入字符串,可是除非传入的是正确的flag,否则必定会输出编码后的flag。浏览器

  再看加密过程,发现出了编码表变了顺序以外,和base64原版加密没有任何不一样,都是每三个字节为一组进行处理,经过左右移位,而后拼接补位处理,凑出四个字节,对应编码表输出便可,这也是base64的代码实现。函数

  那么就很容易了,base64解密过程也是不变的,修改后的编码表源码已经给出,直接使用这张表对给出的flag码值进行base64解密便可,须要本身编码实现,网上不少,这里就不贴代码了。网站

  第二题 base64 harder
编码

  题目:此次连默认编码表都不让看了,再试试?加密

  

 

 

  此次的题目须要get的参数更多了,并且echo的输出也再也不仅仅是flag的编码值了,并且还会输出用户传入的code的编码值,不过此次,源码里没有修改后的编码表了。url

 

  还好题目给了参考文章的连接:爆破非默认base64编码表,这里的做者很详细的给咱们介绍了base64编码过程以及利用逆向思惟,如何反推出编码表。我按照博主的代码,成功本身反推了一遍,总结来讲,他给的代码最终获得的是BaseTable表:

 

 

 

  而这个BaseTable表,就是咱们通过计算逆推代码实现的48位的一串字符串,它的做用是,能够按照做者一开始的目的,通过base64原理拼接成64位比特后,正好对应码值从0-63,那么对应的输出就是修改后的base64编码表。

 

  当时看到这儿可给我高兴坏了,这做者思路真的刁钻,还能这么破解?!不过确定是无懈可击的逻辑,如今咱们的任务就是生成这个BaseTable,做为加密的输入传给这个网站,而后网站就会本身输出他的编码表,以后咱们再用第一个题目的思路来解密。

 

  问题就出在这一步,花了我一夜加一中午的时间去尝试各类办法。

 

  产生问题的缘由是,这个BaseTable里大部分是不可见ASCII码,按理说只能用二进制或者16进制等传入,可是直接?code=\x00\x.......的话,会被直接看成字符串,而不会被转义。

 

  那么我当时就想到俩方法:给这串十六进制编码;或者搜索如何使转义字符生效。

 

  过程其实很漫长很枯燥很崩溃,我尝试了编成中文,用unicode/utf-8,可是先不说会不会最终按照这种编码被解析,这些16进制也不能被变成中文,尤为是第一个\x00,这转成二进制就是0000,加到后面的二进制前面以后,就没了,它就这样没了!由于他是0,仍是一串二进制前几位,因此直接被截了,可这BaseTable仨仨是一个不可分的总体,分割或者修改都会直接影响结果!

 

  而后尝试直接输入ASCII码,转码后一堆乱码,贴上去,果真不行,由于url确实不认这些,可是只要被识别了,绝对是能够成功的。

 

  以后就是php相关,如何使转义符生效,虽然最终没找到答案,可是确实学到了不少php字符串和字符串处理函数的细节,好比PHP里单引号里无视转义符(除非\\等极少用法),get方法不能传递二进制以及正则表达式等等。

 

  无奈放弃,去作web题目,好巧不巧的是,我却在搜索相关资料时,碰到了其余题目的WP:

 

  我当时觉得这就是urlencode吧,已经试过了,没用,但是当我把那串奇怪字符输入在线urlencode后,发现和WP给的结果不一样!瞬间灵机一动,把base harder的网站简单复现,把那串ASCII乱码从php文件echo输入到页面上,

 

 

 

而后按照WP的脚本去读取,果真获得了所有由%编码的编码:

 

 

 

 

  把这一串拿出前48字节输入原网站,果真出了它的编码表,以后把这个编码表做为base64-more的编码表解密,成功获得flag:

 

 

  那么题目作完了,我立刻去搜索这神奇的脚本到底读的是什么编码,结果居然就是urlencode,但是我为何直接在线urlencode不行呢?

 

  我立刻把这串编码拿去在线urlencode区解码,解出来确实是那一串乱码,可是再点编码,却再也不是原来那串url编码了。那么这个现象出现的根本缘由究竟是什么呢,原谅我才疏学浅,相关问题还真没怎么接触过,但能够确定的是显示的乱码对于机器来讲是有语义的,多是不一样的编码方式致使的,毕竟quote不是urlencode,不过浏览器和php都识别就是了。

 

  对于最后这个问题,若是有大佬明白的,而且能够顺便指点下小弟的,感激涕零~

相关文章
相关标签/搜索