nullptr-0

摸索了一晚上，发现凡是.flac.efe后缀的文件的大部分没有加密，因为改.flac后缀以后和原音频比会没有开头，所有个人猜测.flac.efe对.flac文件头做了修改，因为我不太懂音频编码，所有不知道对不对；但.efe文件还不知道是什么东西，因为改了很多文件后缀都匹配不上，不过从.flac.efe的情况看，.efe也可能是部分没加密

另外， @ix64 QQ音乐移动端还大量出现了.mggc1和.mflacc0类型的缓存文件，目前也解密不了，也建议研究一下（应该和mflac，mgg有区别，例如如图是mflacc0改成mflac0后的解密结果）  

最新发现： 1 .efe文件（不包括.flac.efe）前0x1A5位都一样，从0x1A6位开始有区别 2 .flac.efe和.efe文件头都由一段字符和一段数字组成（所以两者编码规则可能相似），其中.flac.efe在这段字符结尾附近会有“FLAC”“ARTIST=”等明文出现，.efe在这段字符开始处附近会有“INFO”字样出现，至于数字段，两者都是由按“8个0-8个数-8个0-8个数-32个0”排列的片段组成

> 根据你们提供的和我自己获取的样本来看，`.efe` `.mggc1` `.mflacc0` 都是 **不带密钥** 版本的 `.mgg` `.mflac` > （密钥存放在App数据库之中，没有嵌入到文件尾部） 但.efe文件靠前部分有一些以'00000000'开头的块，这和目前来看部分明文的.flac.efe高度相似，而与无此结构的mgg系列应该有一定差异 另外：也许能反汇编找到app数据库？ 

HTTP抓包能拿到key吗？ 如果可以拿到，也许能弄清加密方式    

> 这个应该不是 `.efe` 加密的特点； 应该只是 `.flac` 格式的Metadata Block后面一般有一个较长的 Padding Block，且 key box 比较特殊导致的 但是.efe对应的应该是ogg或mp3一类的有损格式，如果是flac的话应该对应的是.flac.efe

> 似乎并没有重写meta的逻辑？ scope.row.xxx=xxx改不了meta吗？我不太确定

@ix64 现在应该可以了。你测试一下？

> 代码仍有问题 在提交之前，可以在本地运行： `npm run build` 进行构建测试 `npm run pretty` 对源代码进行格式化 `npm run test` 进行单元测试 现在代码应该没问题了，但是这  是啥情况？ 另外，网页版的IDE好像不能安装npn

**背景和说明** 华为音乐选择下载无损品质后会下载无后缀的加密文件