对 JS 逆向感兴趣的老哥可以看看这个组织，里面有一些 JS 逆向相关的工具，今年有计划发布一款 JS 混淆还原工具：

https://github.com/JSREI

当用到了 action 的时候要注意防止供应链攻击，不要合并不可信的代码和引入不可信的依赖库，否则就可能会被盗取 security token 之类的，比如下面就是一个通过 action 盗取 security token 的示例：
https://github.com/no-one-sec/github-action-secrets-stealer

op 牛蛙牛蛙，官网界面很酷

https://github.com/JSREI 专注 JS 逆向工具开发
https://github.com/JSREP 专注 JS 逆向实例练习

感兴趣的老哥来康康

@blackeeper 飞速奔向“未来”哈哈哈

@ww2000e 老哥 gentoo 怎么样 😀

@server manjaro 体验怎么样，还没想好装哪个发行版

@YaD2x 我尽量多坚持几天哈哈哈😀

@melkor 就是有点受不了 wsl 了，游戏还好基本不玩 PC 游戏没啥好留恋的

@kaiveyoung 老哥牛

@invadv 在下载镜像、备份文件，说不好过几个小时就哭着来论坛里求助了。。。 😂

@Oliveria 是这个项目老哥： https://github.com/JSREI/ast-hook-for-js-RE ，有兴趣可以一起维护哈 😀

@unregister #44 啊老哥如果是内部框架的话谨慎着点，对于内部框架的快速上手可以多问问周围的同事领导，模仿着他们的方式去使用比较稳，而且这种内部自研框架一般坑会非常多，这种内部框架一般都是 fork 开源的框架进行二次开发甚至就是完全模仿，底层是照抄的，上层的 API 啥的改一改就变成自研的了，你花费在内部框架上面的时间学到的技能很可能不具有通用性，可以把精力着重放在学习内部框架的底层原理上，或者更多的是结合内部框架来理解它模仿的那个框架（比如某些公司基于 gprc 封装自己的 rpc 框架搞出来一堆上层的规范和协议啥的，这个时候就可以下钻把精力更多的放到更底层的 gprc 上而不是纠结于最上层的 API 啥的怎么调，底层原理这个技能是通用的，你离开了这家公司也有用，并且对你以后发展也有用），总结下来就是尽量去卷能够在你整个职业生涯中都能发挥作用的技能，加油祝好！ 😋

@somebody1 心理活动估计跟 #10 楼所说差不多，或者更严重一点的：

- 心里已经觉得你技术不太行或者出活不太行（大概率是出活，毕竟这个会影响到他 KPI ，如果只是技术不太行不影响到他利益的话他可能不会多嘴），但是又还没差到要干掉你的程度或者他因为个人情感啥的不太想干掉你（毕竟没有谁心理变态整天要开人，人都是有感情的，马仔能凑活着用就凑活着用），但是他能看到事情已经是在向很不好的那个方向发展了

- 考虑到你的自尊心他不能说得太直白，就随便聊聊估计

- 如果持续一段时间他觉得还没啥改善，估计就会着手开始换人了。。。

op 可以主动找 Leader 聊一聊，看看有没有更具体的建议啥的，如果只是某项技能上的缺失（比如某个技术框架、或者某些软素质的方法论啥的），你卷一卷学会了受益最大的是你自己，但是如果是要靠延长工作时间才能改善的，就只能六字真言，要么忍要么滚。。。 😂

七年过去了，op 怎么样了，得到当初想要的东西了吗

@nuk 是的老哥，所以压缩分为了两部分：

1. 一部分是栈内部的压缩，这一步相当于是所有的栈共享了一个全局字典来压缩自己内部的重复部分

2. 一部分是栈之间的压缩，完全相同的栈就直接引用同一个 id ，有点类似于 jvm 里的 fast throw 机制，完全相同的栈从第二次开始就是引用的之前的 id 而不重复存储，相当于把整个栈压缩为一个整数

对了怪我的背景故事介绍不完整，他那个工具调用栈不只是异常抛出，他那个工具是通过 java agent 技术给代码添加 hook 点来检出漏洞（原理跟 arthas 类似），每个 hook 点都会有对应的调用栈，hook 点是用户可配置的不可控，甚至可能会出现用户把每行代码都 hook 的情况。。。

@1423 #6 哈哈哈我有点慌呗，我在压缩这块还没太多经验属于刚入门还在各种探索寻找案例练手，我怕自己有想不到的点导致后面全都是错的心态就真崩了那，发到论坛里让大家喷一喷聊一聊能更完善一些有问题我也能及时调整，我之前出现过埋头造轮子造完才发现因为最开始一个很基础的东西没想对到后面全都是错的整个都白费劲哈哈哈。。。😂

@1423 预训练字典的方式也跟那个工具的作者讨论过他否定了，他的业务场景不太满足，数据拿不到那是个类似私有部署的 CLI 工具，要训练只能在用户自己的电脑上训练。。。🤣

@1423 通用的压缩算法大部分都是基于字典和偏移尽量消除重复数据，比较依赖的是压缩的时候的字典窗口大小和一次性被压缩的数据量的大小，调用栈是热数据需要能够随时查询不适合批量压缩，如果 gzip 只能针对单条调用栈进行压缩，那个工具的开发者现在已经是在这么做了，消耗的资源（ gzip 的内存、CPU 消耗等）与效果做性价比的话不是很理想（但也能凑活用。。。），所以才想着看看探索更极致的优化，当然这也只是一次尝试，也很可能还不如通用的压缩算法也说不好 😅