C# 正则表达式实现对淘宝 UA 文件初步反混淆

       淘宝的UA文件目前已更新为64.js。64有一个特别之处,它参数中对应于r[1163]的元素‘JR;ZNRC]Y”yQD”PVR$’可以在使用正则表达式时替换字符串”r[1163]时,在现有字符串中复制“r[1163]”后剩余的字符串并将这些字符串添加在现有字符串的后面。虽然我不明白这其中的缘由,但是阿里人的睿智实在让我敬佩不已。

       除此之外,淘宝新版 UA 文件代码反混淆分析(去数组下标)淘宝新版UA文件混淆函数清晰化处理(C#实现)这两篇文章中讲述的方法仍然适用于目前最新版的64.js,但是需要将r[1163]进行特殊处理。经过验证,字符串‘JR;ZNRC]Y”yQD”PVR$’在使用正则时会copy and paste,但是用C#的字符串的replace函数则不会。因此可以用字符串的replace来单独处理r[1163]的替换。

       出现这个现象的原因如下:C#的正则表达式中,$是一个特殊的字符,而$’ 替换将匹配的字符串替换为匹配项后的整个输入字符串。它将在删除匹配的文本时重复匹配项后的输入字符串。匹配文本前面的任何文本在结果字符串中保持不变。具体请参考:https://msdn.microsoft.com/en-us/library/ewy2t5e0.aspx#AfterMatch

       不论是巧合还是有意为之,这个现象又让我薄弱的知识库增长了一点点。

       那么我是如何发现这个问题,又是怎样验证的呢?

       昨天发现淘宝的UA文件更新了,于是我就用同样的方式处理新文件。新文件处理完成后,看起来怪怪的,对比64.js处理前后的文件,我发现处理之后的文件会多出来一堆字符串。

       经过初步判断,多出来的这一部分内容在替换数组时出现的,而且多出来的这一部分内容字符数量超过5000个。经过查看几个单步循环结果后,个人认为这些异常内容应该是一次性多出来的。为了验证异常内容的来源,我在C#代码中添加了测试代码:记录上一次循环和本次循环后输出结果的字符串长度,如果两次循环间的字符串长度差距大于5000,那么记录其输出结果和替换元素。经过验证,在替换r[1123]时一次性的多出了异常内容。接下来,我用如下代码来进一步验证我的推论。在如下代码中,strArray依次记录着参数数组的元素,用正则表达式和字符串替换时出现了不同的结果。

      新版的初步反混淆处理函数

      在淘宝新版 UA 文件代码反混淆分析(去数组下标)中有提到过如果参数数组元素中包含符号’,’,原文代码的方法比较繁琐,不过原文也提到了另外一种方法:在浏览器中获取到全部代码后,将其用notepad++的jstool–>jsformat进行格式化,然后存储为本地文件,在C#中读取本地文件再进行处理。格式化后的文件参数中的元素就可以直接用”, “进行分割。本文中给出这种方法的实现代码:

Comments

  1. By wulin76

    回复

    • By livezingy

      回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Fork me on GitHub