神奇的Unicode编码_强制改变选中顺序

（1）前言

博主刷题时瞬间懵了，尽然卡在一道签到题。等等，这选中是什么东西。

（2）题目

就一个简单的传参题。

（3）分析
由于源码有点猫腻，我们先是打开了码源进行分析，发现这个问题仍然存在。那就往更底层看看。

我们可以发现在通过十六进制转换后整个代码变了很多，其中多了很多奇奇怪怪的符号。

//翻译一下
E2 80 AE    ‮
E2 81 A6    â
20 46 6C 61 67 21         Flag!
E2 81 A9    â
E2 81 A6    â
4E 31 53 41 43 54 46            N1SACTF

E2 80 AE    ‮
E2 81 A6    â
55 67 65 69 77 6F E2    Ugeiwo
E2 81 A9    â
E2 81 A6    â
63 75 69 73 68 69 79 75 61 6E    cuishiyuan

可以发现这问题的关键在于E2 80 AE，E2 81 A6，E2 81 A9，这里面。

E2 80 AE E2 81 A6 20 46 6C 61 67 21 E2 81 A9 E2 81 A6 4E 31 53 41 43 54 46

E2 80 AE E2 81 A6 55 67 65 69 77 6F E2 81 A9 E2 81 A6 63 75 69 73 68 69 79 75 61 6E

（4）百度一下

1.从右至左强制：U+202E（UTF-8 E2 80 AE）Unicode名称 Right-To-Left Override

作用：根据内存顺序从右至左显示字符。

2.從左到右隔離：U+2066（UTF-8 E2 81 A6）Unicode名称 Left-To-Right Isolate

作用：这之间的字符从左到右显示，不影响外围字符。

3.流行定向隔離：U+2069（UTF-8 E2 81 A9）Unicode名称 Pop Directional Isolate

作用：作为RLI、LRI、FSi翻转结束的标识

eg：HelloCTFer

浏览器进行解析的时候，自然是按照上方十六进制的顺序进行解析，但是解析并不代表着输出，浏览器的输出结果需要根据底层字符的含义进行输出，当浏览器看到E280AE时，就知道后面的字符需要从右到左显示，而解析到E281A6时，浏览器就会知道将后面的字符从左往右输出，也就是CTFer输出结果仍然为CTFer而不是reFTC。当浏览器按照这样的规则把Hello解析完成之后，便会根据E280AE的从右往左输出的原则，将CTFer与Hello两个交换顺序，最终我们在浏览器中看到的结果便是HelloCTFer。

即使输出的结果是HelloCTFer，符合我们的认知，但是当我们用鼠标进行拖动的时候，电脑还是会那么贴心的帮我们把特殊符号加上，导致我们拖动Hello的时候，CTFer也被选中了

（5）构造payload

也就是说我们在复制的时候复制的是被符号转变后的字符，那么我们只要传入对应的hex的值，即还没进行转移的值就可以了。

payload:

http://1.14.71.254:28518/?ahahahaha=jitanglailo&%E2%80%AE%E2%81%A6%55%67%65%69%77%6F%E2%81%A9%E2%81%A6%63%75%69%73%68%69%79%75%61%6E=%E2%80%AE%E2%81%A6%20%46%6C%61%67%21%E2%81%A9%E2%81%A6%4E%31%53%41%43%54%46

（6）爆出flag。