其实这个题在问:
"既然你说你懂 JS，那么能否用 JS 证明你不懂 JS ？“

第一步，用 c++实现这个功能，代码保存好，不要编译（重要）

第二步，写一个脚本，自动编译 C++代码并执行

第三步，用操作系统计划任务定时调用这个牛逼的脚本

NAT 给一般人提供了极大的保护

没有 NAT，网络世界会很不安全

适合的从业者在开始都是这种状态

但不是所有这种状态的人都成为了适合的从业者

认知曲线了解一下，四个阶段你只处于第一阶段而已

楼主考虑的对，很多留言者没考虑到需求点在哪

有人说 tls，那是对过程加密。过程上的监听者就是个假想敌，如果有人想从链路上截获你的数据的话，你基本拒绝不了。技术上拒绝，生理上也拒绝不了，多说无益。几乎没有人在链路上截获你。
但不是说不用 tls，有条件还是要上。

解压密码，最简单的是调用 7z.exe 解压，密码很容易在使用中被抓到。就算你继承了动态库、静态库，关键调用还是很容易被分析出来。如果是源码级魔改并融合 7z，那工作量是直线上升。
就算解决了加密问题，100M 的文件常规思路还是解压到临时目录来使用，很容易被发现的。全加载到内存，按数据结构组织后轻松上 500M 。

楼主的需求可以总结为：
1 、文件到了终端，依然作为一个格式不明的加密文件存在
2 、加密文件支持随机读取，不一定要读取就全部解密

推荐基于 aes 搞一个自己的加密算法。
aes 仅仅是对 16 字节的输入给出 16 字节的输出而已，距离直接应用还有一段距离。需要选择一种模式，简单的 ecb 或好一些的 cbc，密码用二进制，加密文件格式分好段，做好 padding 和校验。这一切自己完成的话，光凭一个文件，几乎是破解不了。

很多公司不需要多么高质量的项目或产品。

研发上的诸多问题最容易被发现，解决的很少。

然而很多真的不需要去解决，公司死不了的。

5 、文件内容几乎被变换全部覆盖，不存在未变换的超过 10 字节的区域，部分恢复无望

不应当是格式转化的问题，可以观察出这个文件依然是正常 xlsx 文件的变换结果，中间没有 xls 或 csv 的痕迹

正常 xlsx 本质上是 zip 文件，非固实，内容是分段存储的，会有大片连续的 0 值，和其余更多的杂乱到极致的压缩空间。观察这个错误的文件，能够发现 0 值的痕迹。

真正的 0 值是空白，这个文件中的 0 值区域仿佛是薄纱覆盖。可以得出文件被加密变换的结论。

文件可能内容并未丢失，但是被加密了。可能的加密者是电脑加密软件或勒索病毒。

从文件头 PK 变为 pK 向下推，可知错误文件和正常文件的差异是：
20 00 80 40 80 00 80 00 00 。。。。。。

观察 65 字节以后（正常文件是 0 值区域），差异是：
00 00 00 02 00 00 。。。
后边还有：
20 00 00 80 20 01 。。。

后续还有不少 0 值区域，还有文件名字符串区域，可以看出加密变换的痕迹很明显。

加密向量随机性不强，很多不变换或只变换高 16 比特，肯定不是 aes 等算法来的。加密向量是不断变化的，不是循环往复的，不容易破解。

结论：
1 、是 xlsx 直接加密变换的结果
2 、加密向量随机性低，保留了部分文件原貌，但足以破坏文档格式
3 、难以破解
4 、请查找是否有安装加密软件，或中招勒索病毒

其实很多人抑制自己的抽烟需求只是因为周围有女人

所以在男厕就可以放肆一点了

还有一点就是厕所屎尿味太重，人必然要呼吸挨臭，但如果借着抽烟把屎尿味混着尼古丁焦油从嘴里进入，就不那么臭了。

现在投资域名是不是 49 年加入国军

代码技术方面很多已经赶上来了，但是文档方面还差的很远

20 年前微软的 msdn 文档和现在的 msdn 文档有一点是一致的：一贯的严谨性
android 的文档也一样严谨

国内的文档达到这个程度的很少

能用勺子吃米饭的人，能精确的知道每一勺子有多少米饭粒吗？

安心接受被卷的命运，毕竟年轻的时候也卷过别人

很明显洗钱，这种如果赚大钱市场看不见的手会调节的，你放不下身段，有的是能放下身段的加入进来摊薄利润

唉，我大 win32 没落到如此这般了么

win32api：NetUserGetInfo 查询出 USER_INFO_1 结构

里面的 DWORD usri1_password_age;就是当前密码已存在的时间长度



正规的用法是，客户端软件选择“记住密码”，如果记住密码后，windows 密码发生了改变，则应当要求重新输入客户端密码。乌龟 svn 客户端就是这样实践的，本来都记住了密码，但是改变了 windows 密码之后，会要求重新输入。