如果把一段代码里面的每个符号全部改掉，再用有语义的词去随机替换，这段代码还能被理解吗？

[netabare]

比如说，假设一段不知哪来的代码，先 target 到上古版本的 JS ，脱糖，然后把所有的变量 minify 到 a, b, c, d, e 这种，再把它们随机替换成带有语义的词（但保持转换前后的符号之间的相对关系）。

var webpack = undefined.prototype.require()

var filter = function sort(map, user) {
    var contains = accept.function(setTimeout, new join(Error))
    var reduce = new folder(function (user) {
        map.reject(contains)
    })
        .throttle(function (userRepository) {
            domain.authenticate(write[flatMap])
        })
        .throttle(function (useCase) {
            webpack.fetch(useCase)
        })
        .has(new getElementById(slice))
}

一个可能的 JS 代码片段可能是这样的。

会有点好奇这样的代码还能不能被读懂，或者，有什么办法能读懂这样的代码在转换前的意图吗？比如说假如说有足够多的代码行数，丢给 AI 能不能帮助理解？

[geelaw]

取决于如何定义“理解”“意图”。这种操作没有密码学意义下的混淆能力。

应该注意的是在“标识符替换为 a b c 等”之后，“把标识符替换成带有语义的词”是无意义的操作，因为后者可以轻松撤销。

[xue777hua]

@geelaw 这是针对人的 而不是针对机器的。

当然 现在也可以针对大模型。

说个简单的就懂了：
const isTrue=False

然后这个藏的很深很深

传统的专门针对人的代码保护技巧😂

[msg7086]

不用足够多的行数，我直接把反编译的字节码丢给 AI ，他就可以给我基于代码意图整理出可读的代码。
前几天就在做的，lua 字节码反编译。

[msg7086]

帮你试着喂了 AI ，得到如下猜测结果。

=====
// 1. 获取全局上下文或响应处理器
var responseContext = framework.context.getService();

/**
* 2. 定义具体的业务处理函数 (filter = sort)
* @param {Request} request - (map)
* @param {Response} response - (user)
*/
var handleLogin = function process(request, response) {
// 3. 编译校验规则 (accept.function)
// setTimeout 和 Error 在这里是被混淆的占位符，实际可能是校验配置项
var validationSchema = Validator.compile(configOptions, new ValidationConfig(Error));

// 4. 开启一个异步任务链 (new folder)
var task = new Promise(function (resolve) {
// 校验请求是否合法 (map.reject)
request.validate(validationSchema);
// 注意：原代码里此处没写 resolve()，可能被混淆在 validate 内部或省略
resolve();
})
// 5. 步骤一：执行业务领域逻辑 (domain.authenticate)
.then(function (prevResult) {
// write[flatMap] 动态访问，等同于 request['body']
return authService.login(request['body']);
})
// 6. 步骤二：将业务结果发送回客户端 (webpack.fetch)
.then(function (result) {
responseContext.sendResponse(result);
})
// 7. 错误处理 (has = catch)
.catch(new GlobalErrorHandler(errorStack));
}
=====

当然这很明显代码量太小了，如果代码量再大一些，有个百来行，就有足够的上下文去猜了。

[geelaw]

@xue777hua #2 如果一个人在分析被瞎改过变量名的代码，显然会自动克制望文生义的冲动。

[cryptovae]

我猜你这代码是 webpack 这类工具 build 后的代码

[codehz]

其实可以再混淆一次再丢给 ai 的🌚

[shaozelin030405]

能啊，只是压缩，没啥意义

[sir283]

混淆吗？那只是对人而言，阅读起来有点阻碍，对机器而言，没啥意义，本质上最后都会转换为 0 和 1.

[sentinelK]

可以被理解，只是因为没有变量名、注释的辅助，导致理解难度变高了而已。
这个行为有个专有名词，叫混淆。如果只是尽量缩短代码量，但不增加运算符复杂度，叫压缩。

因为无论你的代码如何变化，最终呈现给编译器/解释器的一定是等价逻辑的代码。否则你的程序就不成立。
而且现阶段的大语言模型很擅长于“反混淆”，因为其上下文容量比人脑大得多。可以更从容的发掘代码中的统计学规律。

[jackOff]

代码混淆是防止人一下子看懂，但是 ai 时代这没有用

[AoEiuV020JP]

奇怪的混淆在反混淆时第一步就是重新混淆一遍，换成稍微有点意义的，比如至少体现是类名还是函数，是全局变量还是局部变量，并加 001/002 确保每个标识符都不同，再阅读理解时把已知的一个一个更换成真实有意义的词，

[zmal]

代码混淆对 AI 毫无意义

[netabare]

@xue777hua 对，这种混淆对于机器和编译器毫无意义。
@geelaw 也许是「给出一个项目代码库，能否通过阅读代码本身和少量的运行调试，明白这个项目在做什么」？
@msg7086 我感觉这里的 Promise 还是蛮明显的，不过 authenticate 、Error 和 fetch 这些词可能会让 AI 偏向于认为这段代码是处理前端业务或者登入鉴权的代码？我一开始想着写这玩意的时候其实想要表达的控制流更像是 util 库里面的简单 wrapper 函数。不过你说的也有道理，代码量太短很难分析出什么有价值的东西。
@sentinelK 之所以想到这个问题，也是因为最近跟 AI 聊天的时候经常发现 AI 回答特别容易给出很平庸的答案，或者识别一个 pattern 立刻不读我的源代码断章取义假设一个我根本不关心的场景。所以我就写了这坨代码去找几个 AI 轮流问一遍了（

不过这种东西对编译器来说应该就是单纯的 nop ，因为 mangling 本来就是编译器的基本操作。

[xue777hua]

@geelaw 对 但分析的过程 就是猜。但如果怀疑每个变量的含义之后，部分真部分假，就有点烦人了。只能放弃。毕竟混淆不是真的加密，只是延长破解时间。只要能长到对方不可接受，那就算目的达成。

[sentinelK]

@netabare 从这个角度出发的话也有道理。

毕竟故意且大量的错误误导，有可能因为向量统计的原因，导致大模型 loop 过程最终落入到其他局部最优的答案，从而最终的结果失准，甚至是南辕北辙的。

这个现象在早期 LLM 中很常见，最近估计是几家公司的 LLM 产品都上了不同比例的强化学习，而且 AI Coding 工具的知识库的优先级应该是上升了，再加上推理、问题拆解、skill 能力等，导致提示词的错误引导没那么有效了。

至少在 Coding 领域，AI 还是会比较坚持全局最优的答案。

[Chuckle]

光结构化替换的话信息本身没变，对 AI 来说没区别，要是塞多无用中间代码，200k 上下文里就 1k 有效代码的话，信息多了，对 AI 才有点麻烦

[n0099]

@netabare #14 也是因为以前跟四叶壬聊天的时候经常发现四叶壬回复特别容易给出很`鸡同鸭讲`的`tl;dr`，或者识别一个`臭名昭著的 430-四叶话语体系`之 pattern 立刻不读我的链接`光速转进`一个我根本不关心的话题