static {        System.load(b.e(String.valueOf(String.valueOf(Platform.is64Bit() ? "x64" : "x86")) + "/jsyunew3.dll").getAbsolutePath());    }    public static native int GetVersion(final String p0);    public static native int GetVersionEx(final String p0);    public static native long GetID_1(final String p0);    public static native long GetID_2(final String p0);    public static native long get_LastError();    public static native String FindPort(final int p0);    public static native String NewReadString(final int p0, final int p1, final String p2, final String p3, final String p4);    public static native int ReSet(final String p0);

然后我就想到了第二个破解思路：能不能让这个return直接返回这个硬编码的字符串，以及那个FindPort函数能不能直接返回一个正确的值，这样就可以比较小的修改了，然后结果就是，不会！然后当场放弃。

7.png

5. 编译
   然后就编译呗！用winrar打开jar，把编译后的这个jsyunew3.class替换掉,运行那个.exe，哦吼！
   

   8.png

   
   那还能怎么办，搜呗，既然是在窗口里，那很有可能在launcher这个里，用jad搜字符串找呗，然后就发现这个玩意果然在，那么，统统注释掉！
   

   9.png

   
   然后编译，打开！一路确认，然后又来一个，同样的操作，去jad里搜呗。
   

   10.png

   
   嗯？没有？
   

   11.png

   
   那肯定在其他类里，又不是只有一个类可以创建窗口，翻！
   结果翻遍了每一个类，没有！
   事情变得复杂了起来。那只有去分析main函数具体都做了什么了，然后看看为什么没有这一个字符串。
6. 回头继续分析main
   

   12.png

   
   分析得出： 这个while是不断地弹框，如果没有插加密狗，肯定读不出来l 就会是上边第4里边return的空字符串，因为已经硬编码写死返回值了，所以这个while直接跳过，进入最终的KenjoyDrawLauncher.j.a();
7. 追a();
   哟，这不是刚注释了弹窗的那个方法嘛，接着往下看吧
   

   13.png

   
   继续往下分析，从上往下，这是根据l创建了个json，然后操作了一番，咱这l肯定没有问题，就不管对l做什么了，没有意义。
   

   14.png

   
   看最后，this.a(jsonObject);
   不用说，追进去。
   长这样
   

   15.png

   
   简单解释一下代码吧：
   if这里判断了是否存在，追进去看
   b=D.b() 追进去D.b()发现用了core这个文件。那这个core应该也是个jar，然后WinRar打开试试，发现打不开，010打开看文件头，啥也不是。不是jar，往后继续分析代码
   往下看发现，又用到了l，先看看this.a(b) 看看对文件core做了什么
   看不懂（破解到后边看懂了，实则是解密byte流），但是看得出来输出了一个前缀xxx后缀xxx的临时文件，退出时删除，然后最后返回值就是这个临时文件。那咱就去看看！
   把这个临时文件复制出来之后，尝试用WinRar打开，哎呀，打开了，反编译！
8. 反编译！
   直接碰壁，一个源代码都反编译不出来。会不会是jadx不够强大，换换工具试试看，jd，luyten都试了，哪个都不行！
   

   17.png

   
   先保存一下进度，把这个临时文件重命名成core，替换掉安装目录里的core，然后让上边那个函数返回this.g的，直接返回file（执行了一堆寂寞）
   然后我就去万能的Q群求助了，经过麦兜指点，忽略了一个问题，class的文件头（魔数）不对，不是class的文件头，也是这个时候知道了，文件头还叫魔数
   既然文件头不对，那肯定就是加密了。继续分析！看看哪里解密class文件了！
9. 寻找解密class的地方
   那就继续找第7步第三个图的C.a(this.a(b),bulabulabula);了
   追进去这个a();瞧瞧看,好家伙，继承了ClassLoader，想必就是传说中的类加载器，又是知识盲区，硬着头皮看吧。研究这个玩意是花费时间比较久的。
   

   18.png

   
   然后接下来再看a里都做了什么，翻来覆去的读。哪都不是解密class的啊！
   

   19.png

   
   花了很长时间研究，然后后来脑子开窍了，既然是类加载器，那肯定是用来加载class的，既然加载class，文件头又对不上，那么加载之前一定是解密了，这个a里没有， 那肯定就在其他地方，寻找可疑函数。
   最后定位到了findclass，英文直译：寻找类文件，嗯，满足猜想的一个方法。
   

   20.png

   
   往里看,又发现了可疑方法DecodeClassFile,英文直译：解密类文件！
   可算找到了，接下来事情就明朗了，跟搞core文件思路类似，还是大刀阔斧的修改，修改后如下，为啥要判断呢，因为要替换core里边的class。所以加上之后调试起来方便点。
   

   21.png

   
   将这个字节数组a，导出成文件的代码如下

导出成文件写的代码也比较水,凑合看，这就是上边图例收起来的代码
也是通过导出s，判断出来传进来的s就是类的包名+类名，然后就这样输出了所有文件

//尝试输出byteString d = s.replace(".","\\");File file3 = new File("testtest\\"+d+"class");if (!file3.getParentFile().exists()) {    file3.getParentFile().mkdirs();}else {    file3.renameTo(new File("testtest\\" + d + ".class1"));}file3.createNewFile();OutputStream out3 = new FileOutputStrea(file3);InputStream is3 = new ByteArrayInputStrea(a);byte[] buff3 = new byte[1024];int len3 = 0;while((len3=is3.read(buff3))!=-1){    out3.write(buff3, 0, len3);}is3.close();out3.close();