JAVA RMI GDC每小时触发Full GC 前言 最近倒腾Java，发现JVM并行收集器在还有大量堆内存的时候就开始触发老年代的回收，通过GC日志发现每小时都会执行GC和Full GC回收，回收是通过System.gc()调用。 那每小时都调用一次Full GC，我添加启动参数-Xms11g -Xmx11g分配11G堆内存只是为了好看吗？每次Full GC耗时在600ms，并行收集器老年代内存使用还不足5%，真是发神经了！ 过程就不做记录了，无聊又蛋疼。以下是在使用了RMI或者其他NIO对象的情况。 RMI DGC每小时触发一次Full GC 原因：DGC代码中调用System.gc()导致并行收集器触发Full GC。 解决办法： 修改DGC调用System.gc()执行时间，默认一小时，单位ms。启动参数添加： -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 禁止程序中的System.gc()，添加启动参数： -XX:+DisableExplicitGC 使用支持并发的收集器（CMS、G1、ZGC或Shenandoah），并且添加启动参数： -XX:+ExplicitGCInvokesConcurrent 方法1，治标不治本，延长时间触发Full GC会导致STW时间更长，可以配合并行收集器使用-XX:+ExplicitGCInvokesConcurrent来控制频率。 方法3，启用-XX:+ExplicitGCInvokesConcurrent参数可以尝试在垃圾收集时使用并发收集来减少STW时间，从而提高应用程序的响应性。 不建议使用-XX:+DisableExplicitGC来限制System.gc()。 因为从Java 7开始，Java提供了基于NIO的RMI实现，称为NIO-based RMI。这种实现利用了NIO的非阻塞I/O模型，能够更高效地处理大量的并发连接，减少了线程资源的消耗，并提高了性能和可伸缩性。通过使用NIO，NIO-based RMI能够更好地适应高并发和大规模的网络通信场景。 DirectByteBuffer是一种在堆外内存中分配的ByteBuffer，它与NIO密切相关，因为它可以直接映射到操作系统的内存中，从而避免了在Java堆和本地内存之间进行复制。在NIO编程中，使用DirectByteBuffer可以提高I/O操作的性能和效率，特别是在处理大量数据时。在基于NIO的RMI实现中，使用NioServerSocketChannel和NioEventLoopGroup通常涉及到DirectByteBuffer的使用。 虽然 DirectByteBuffer 对象本身是由 JVM 管理的，它们存储在 Java 堆内存中，但是 DirectByteBuffer 对象所持有的实际数据存储在堆外内存中。 JVM 通过 DirectByteBuffer 对象来管理对堆外内存的访问和操作。当 DirectByteBuffer 对象被垃圾回收时，它所持有的堆外内存也会随之被释放。 因此，触发 Full GC 通常是为了回收已经失去引用的 DirectByteBuffer 对象，进而释放掉它们所占用的堆外内存。 Full GC 在回收过程中会扫描整个堆内存，包括其中的对象和引用。当发现 DirectByteBuffer 对象已经没有引用指向时，JVM 就会将其标记为可回收， 待下次 Full GC 执行时进行回收。这样，间接地通过 Full GC 回收了 DirectByteBuffer 对象，也就释放了相应的堆外内存。 如果禁用了System.gc()，那么不会及时的清理 DirectByteBuffer 或者其他 NIO 对象导致堆外内存也不会释放。虽然最后也可能因为JVM堆内内存不足触发Full GC 来释放，但没必要冒险。参阅 监控程序调用System.gc()堆栈 可以使用 async-profiler 跟踪System.gc调用者： 预先开始分析： profiler.sh start -e java.lang.System.gc <pid> 发生一种或多种System.gc情况后，停止分析并打印堆栈跟踪： --- Execution profile --- Total samples : 6 Frame buffer usage : 0.0007% --- 4 calls (66.67%), 4 samples [ 0] java.lang.System.gc [ 1] java.nio.Bits.reserveMemory [ 2] java.nio.DirectByteBuffer.<init> [ 3] java.nio.ByteBuffer.allocateDirect [ 4] Allocate.main --- 2 calls (33.33%), 2 samples [ 0] java.lang.System.gc [ 1] sun.misc.GC$Daemon.run 在上面的示例中，System.gc从两个地方调用了 6 次。这两种情况都是 JDK 内部强制进行垃圾回收的典型情况。第一个来自java.nio.Bits.reserveMemory.当没有足够的可用内存来分配新的直接 ByteBuffer 时（由于-XX:MaxDirectMemorySize限制）， JDK 会强制进行 Full GC 回收无法访问的直接 ByteBuffer。 第二个来自 GC Daemon 线程。这由 Java RMI 运行时定期调用。例如，如果您使用 JMX 远程，则每小时自动启用一次定期 GC。 这可以 通过-Dsun.rmi.dgc.client.gcInterval系统属性进行调整。 结语 起初我很不明白为什么DGC代码里面会有System.gc()，我一直以为堆外内存不归JVM管理，那调用System.gc()又有什么用呢？又是问ChatGPT又是各种搜索，才发现虽然JVM不管理堆外内存，但是管理使用堆外内存的对象，System.gc()是为了及时释放掉不再使用的堆外内存持有对象，堆内释放了，操作系统就会释放堆外内存了！

探索ChatGPT、NewBing和Google Bard：我与大型语言模型的初体验 前言 最近ChatGPT很火爆，不过我还是近几天才知道，平时也没怎么看新闻，有点孤陋寡闻了！既然都发布了那我也来试试看人工智能到底有多智能！这不，一口气体验三款AI，chatGP、Bing AI，还有Google Bard。 一个ChatGPT出来，后面就会有千千万万个ChatGPT如脱缰野马般涌现，那么那些跟趋势蹭流量的ChatGPT到底是人工智能还是"人工智障"？ 注册ChatGPT 刚接触到ChatGPT那就不得不提注册了。虽然注册也没什么难点，但是还是有限制，例如你的IP、手机号码等。当然伟大的国人总是能想到各种方法来解决问题。 IP问题科学上网就行了，我还是推荐多使用欧美地区节点，香港都不行，和大陆一视同仁了，唉~~~！ 注册也没什么难点，主要是短信验证，对号码有要求，国内、香港的反正是不行的，只能用其他国家。电话验证接码我使用的是sms-activate 【链接包含我的Ref,介意的话不要点击】，当然有很多选择，这个倒是无所谓。openai好像也只是用来验证你是真人，也没看见那里能设置或修改电话，目前来说应该是没有什么其他用途。 sms-activate必须要充值后才能使用，充值支持支付宝、银联卡等。 点击右上角充值： 选择支付宝即可，当然也可以用银联卡，什么方便用什么： 充值完了就可以选号码开始注册了，在右边搜索openai： 选择印度尼西亚（你可以试试其他的，但是不保证能收到验证码，没收到码一般也不会扣费），一般在openai验证手机号时等个3-5分钟，如果还没有接收到验证码，就可以X掉再换一个号码了，没收到验证码是会把扣费返还的： 他们甚至都为其出了官方教程：sms-activate注册openAI。 注册openai后就可以正常使用了，chatGPT-web版是免费的。听说是有次数限制的，这两天使用还是没有触碰到上限。 体验ChatGPT chatGPT-web版在对话中经常出现错误的情况，之前我以为是访问人数太多导致，这两天换了一个相对稳定的翻墙节点后稳定许多，否则会一直出错，需要刷新网页才能恢复，非常难受。 ChatGPT自然语言处理非常出色，精通多国语言，非常流利。最让人惊讶的是上下文关联，每次对话都会结合本轮对话上下文做出回答。 打个比方，你先问它"乔布斯是谁"，再问它"他对苹果公司有什么贡献"，这里的【他】是指我上一次问题里面的"乔布斯"。别小看了上下文关联以为很简单，其实对于提取上下文里面与本次对话有关联的关键词是非常困难的。这就类似于人类的记忆功能，你和刚会说话的小朋友对话时，他就可能经常出现"丢失上下文关联"，不理解你说的是指什么。 它甚至都能写论文、诗词、程序，在编程开发中，遇到BUG、异常它都能给出可能涉及的问题。这可比在搜索引擎里面一个个翻找答案的效率可快多了。何况中文垃圾站真是一片一片的，大大降低效率。提供给它的任何日志，让它总结分析，它都说得头头是道，有理有据。这确实在某些情况下对我有很大的帮助。 目前网上也出现了很多Chrome浏览器的ChatGPT扩展，总体来说体验还是不够好。 一些基于web获取chatGPT-web版的Cookie和Token，在chatGPT-web版中对话都经常断线要刷新网页才能继续，放到扩展中也一样断线，体验非常不好。 还有一种基于OpenAI-API，这种体验非常好，但是OpenAI-API收费。目前注册ChatGPT账号有5美金的体验金，而OpenAI-API的收费是按照字数来收取的，称之为Token，以下是价格： 关于token消耗，以下引用ChatGPT3.5回答： 在 OpenAI API 中，每个模型的 Token 数量限制是不同的，因此“1,000 tokens 约等于 750 个单词”这个说法的具体计算方式也可能因模型而异。一般来说，这种说法是根据一个平均单词长度为五个字符的假设得出的。在这种情况下，一个包含 1,000 个 Token 的输入文本大约包含 200 个单词。而根据英语写作的经验，每个单词的平均长度约为 4-6 个字符，因此约 200 个单词的文本约有 750 到 1,200 个字符，这就是通常将 1,000 个 Token 与 750 个单词联系起来的原因。但需要注意的是，这只是一个大致的估计，并不适用于所有情况。 这个token是双向计费，你提问的字数和AI回答的字数都是会消耗掉token的（包括标点符号等一系列其他符号）。虽然GPT3.5 1000Token只需要0.002美金，但是1000Token消耗非常快，特别是中文字符。如果使用上下文关联，需要用到会话ID，那本次对话所关联的会话也会再算一次token，你想想这个消耗有多大。个人使用都能感觉到肉疼，但是公开使用那就更不用说了。你看现在网上大把的免翻墙免费用ChatGPT的那些，如果真是ChatGPT API搭建，然后免费给你用，你觉得现在还有这种"好心人"吗？如果不是ChatGPT，那它是个什么东西相信大家都应该想得到！ 目前我在使用的Chrome浏览器扩展只有一款，chatGPTBox，相对于其他的体验比较好，而且开源。目前划词功能、配合搜索引擎比较实用，其他的我觉得也还好，使用情况不多。有兴趣可以点进去看看。 ChatGPT还有Plus版，可以抢先体验新功能，目前plus版可以使用GPT4： 我目前还没有去体验Plus版，chatGPT-web版使用的比较少，但是我准备使用openAI API，所以弄了张美国虚拟信用卡用来绑定。目前国内推荐的虚拟信用卡大多都是depay和nobepay。免费版在高峰期会提示We're experiencing exceptionally high demand. Please hang tight as we work on scaling our systems.，需要刷新网页更频繁，plus应该会好许多，但是我没用过也不能确定。 起初我想使用depay，无奈连个像样的官网都没有，注册也有BUG，我发送验证码始终没有反应。而且充值有点麻烦。有手续费、月费、不想实名需要10美金卡费。 nobepay注册需要邀请码，这个邀请码自己上网找找，我也是网上找的 （989B08，用不了的话自己上网找找吧），没有还注册不了。 需要实名认证，注册时微信ID那一栏一定要已经实名认证的微信，到时候充值和实名认证都是要用该微信。 注册时最低充值500RMB，支付宝充值有1%手续费，开卡有手续费和最低充值金额（每张卡可能不一样）。充值的RMB，开卡是扣费也要选择RMB账户，汇率偏高，我开卡时汇率时6.8，他那边显示7.0！556766卡段开卡要充值最低30美金，需要扣除手续费、开卡费、汇率转换差不多2.X美金。556766卡段能绑定openai，开卡时地址找找美国免税州地址，网上搜搜美国地址生成器，生成一个即可，信用卡姓名可自定义。 openai使用的是Stripe收款，开卡时需要注意，你的ip最好是信用卡开卡国的，否则大概率被拒绝。如果你使用nobepay 556766卡段，选美国节点去绑定，一般是没有什么问题的。 目前支持卡段（已验证）： OpenAI/ChatGPT Plus 支持的卡段： 591393 （ DePay ） 556766 （ NobePay ） OpenAI/ChatGPT Plus 不支持的信用卡： 国内招行 VISA/MASTERCARD 、全币卡 全球付香港虚拟卡 万里汇香港虚拟卡 绑定成功后一般是从信用卡 PENDING 5美金，然后每月有账单，用多少扣多少！先用后付。 体验NEW BING Bing在众多搜索引擎中一直不怎么起眼，毕竟Google才是大头。虽然Google搜索引擎早已涉及自然语言AI领域，但是却是微软的Bing AI先出来。 微软在早期忽略搜索引擎，自家的IE也是爱用不用的态度，直到Google的出现，无论是搜索引擎还是浏览器，那个曾经有巨大优势的微软反应过来才发现已经被人家甩得太远。而微软近几年的操作一直在布局，从收购Github，组建Azure云服务, 投资OpenAI实验室，直到今天ChatGPT，微软在AI领域已经走在了前面。 Bing AI相对于ChatGPT最大的优势就是拥有互联网能力，目前的Bing AI使用GPT4模型，并且结合自家搜索引擎能更快更好的找到答案。Google虽然借助自然语言处理来完善搜索引擎，但是返回的大量搜索结果中去找答案还是非常耗时的，而Bing AI却已经缩短了从搜索结果中到找到答案之间的时间，这让Google搜索引擎感受到了压力。 在和Bing AI对话时发现，对于已知问题它会直接给你答案，未知问题，它会通过搜索引擎去结果中总结答案。可惜也需要科学上网才能使用。总体体验相对于chatGPT-web版反应稍慢，有可能时因为使用GPT4模型的关系。 Bing AI必须使用自家的Edge浏览器，不过可以通过修改请求User Agent来模拟Edge。Chrome浏览器可以使用ModHeader扩展来修改： Edge浏览器user-agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 Edg/110.0.1587.57 你甚至可以添加X-Forwarded-For头部然后指定国外IP来免除科学上网，但毕竟不是长久之计。 Bing AI虽然可以联网进行搜索，但是表现起来比ChatGPT要呆，很多时候一直给出重复答案，就算你强调关键字也是如此，甚至它会结束当前对话，脾气还不小。像是给它一份报告，让它分析，他就完全不如ChatGPT那样会给出总结和分析。看来Bing AI可能被屏蔽某些功能。 体验Google Bard 其实，我还是很看好Google的Bard AI，用了这么多年Google搜索引擎，Google搜索引擎的关键词纠错能力还是很亮眼的。我相信很多人在打字输入比较快的的时候，容易出现很多谐音词，当它输入到Google的搜索引擎的时候，你会发现基本上已经被Google纠错，并且在搜索引擎结果上面返回已经纠正的关键词，你是不是要找 xxxxx，红色高亮。ChatGPT和Bing也是有纠错能力的，只是我更想试试Bard。 2023-04-05 我已经获得了Bard AI的体验资格，很遗憾，它目前支持英文... Bard它说它支持关键词纠错，并且善于互联网搜索（我英语一塌糊度，这都是我用Google翻译的...） 你甚至可以将文章链接丢给它，它去帮你分析总结。我先是发生文章地址让它帮我做SEO优化，然后让它分析总结这篇文章。但是我发现它的回答有些问题，我把我这篇文章丢给它分析，它把New Bing说成是Google Ai的新搜索引擎... 当然它的中文还在训练中，这都可以理解。 Bard回复体验不像ChatGPT和Bing两个AI，它是一次返回全部答案，而其他两个是一个个字输出。Bard什么都敢说，什么都敢答，只要你敢问！ 有时候回答能明显比之前回答慢，我估计它是自己在互联网搜索，并且分析搜索结果。Bard虽然自己说会用到各种搜索引擎，但是我认为它多数时候都是使用Google，毕竟是自家的，不可能放着自家世界上最大的搜索引擎不用，去用其他搜索引擎。配合Google搜索引擎简直如虎添翼，这也让我更看好Bard未来的发展。 我立即去问Bard来验证，果不其然它回答确实优先使用Google，但是他这回答总感觉有点王婆卖瓜的感觉... 随即我又问它出现的原因是不是因为ChatGPT，连Google两位创始人都回来了，虽然我也认为它的潜力很大，希望它自己的回答也不是在讲大话！ 就目前来看，它没有像chatGPT-web版一样频繁断线需要刷新网页，体验感稍微好点，但是它的中文还在训练中，不知道还要多久。没有发现禁止某些地区使用，只是体验需要申请。 结语 目前我已经简单体验了ChatGPT、Bing AI和Google的AI Bard。目前人类在人工智能领域已经走出了一大步，相信在人工智能的帮助下，进步会越来越快。openai API价格比较贵，就个人而言勉强能接受，但是如果用它来做公共服务前期投入还是比较大的。ChatGPT和Bing AI可能是两个完全不同的产品，Bing AI明显更偏向解决关于搜索类型问题，虽然基于GPT4，但表现出来连GPT3.5都不如（阿三的锅？）。而Google AI Bard虽然还没发布，但是消息模型功能上感觉比其他两款要强大，看看Bard的后续进展吧！ 我这两天只玩了下消息模型，还有很多图片、语音等模型还没机会，就拿图片模型来说，提取图片中的文字功能就可能绕过目前大部分简单图片验证码。 AI是新鲜事物，能力有限，目前最多也是辅助使用，远没有达到代替的程度。它无论是写代码，还是写论文，都基于大数据。 但这仅仅是目前...

折腾京东APP签名-获取wskey相关签名参数 前言 前几天随手撸了个自动上传京东open token（open token其实就是用户cookie）的脚本（有兴趣可以看看：京东cookie自动更新维护），虽然可以自动上传了，但是每天都得去打开京东APP才行，而且两次打开时间不能超过24小时，不然open token就过期了。这方法怎么看都不是很省事！ 最近一直在找替代方法，发现Zy143L大佬脚本中提到wskey可以申请open token，wskey有效期应该比较长，我使用好几天之前抓包到的wskey依然可以获取到open token。wskey在APP抓包中经常看到，使用wskey的请求里面都有签名，感觉签名方法应该是一样的。通过genToken的接口获取open token，那个签名方法虽然短时间可以重复使用（请求只需要变动wskey就好，签名没有加入wskey做计算），但是还不清楚有效期，如果一直靠抓包获取签名的话那比上面直接抓包open token还恶心！ 分析 wskey很重要，京东APP很多敏感接口都是使用wskey，不要泄露！！！ 既然可以通过wskey获取open token，wskey有效期有比较长，那么它是一个很好代替每天上传open token的方法。 我的思路： 不定期通过手机app抓包wskey上传到服务器，服务器接收到后写入wskeys.list。 每天定时通过wskey换取open token（open token 24小时有效期，应该每天获取两次比较保险），并且写入cookies.list。 目前还不清楚wskey有效期，所以在第二步中wskey过期及时发送通知以便重新上传wskey。 经过一下午折腾，确实可行。但是看Zy143L大佬源码发现genToken接口中的签名是请求coding.net返回的（应该是大佬自建部署的吧！）！这个动作引起了我的好奇心，没有公布签名算法，究竟是何等高级的玩意儿？请求没有任何数据，就一个get请求即可返回所有签名参数，难道签名参与计算的值都是固定的吗？ 这类资料比较少，不过还是有乐于分享的大佬。找到几篇文章： JD app sign 加密参数破解 - unidbg 逆向工具之unidbg（在pc端模拟执行so文件中的函数） Unidbg使用指南(一) Unidbg模拟执行大厂so实操教程(一) 先把框架搭起来 Unidbg模拟执行大厂so实操教程(二) 借鸡生蛋之SandHook的使用(一) 借鸡生蛋之某电商App签名so的使用(二) 借鸡生蛋之某电商App签名so的使用(三) 对于我来说难度比较大，涉及知识面广，不过如果有信心那就没问题。 我总结了一下经过步骤： 首先得搭建一个android开发环境。 下载京东安卓APP，apk文件可以当作压缩文件打开，从lib里面提取出libjdbitmapkit.so。 用ida修改libjdbitmapkit.so文件，需要修改一些地方屏蔽错误。 使用unidbg载入libjdbitmapkit.so，调用签名方法签名。 打包编译，部署到服务器。 步骤虽然简单，但是操作过程对于一个从来没有接触过andriod、汇编的人来说每一步都掉坑！！！ 过大坑纪要 Exception in thread "main" java.lang.IllegalStateException: Illegal JNI version: 0xffffffff，这个问题坑了我好久，起初我以为自己环境有问题，因为根本找不到什么资料。其实就是so文件问题，如果你没有使用unidbg-0.9.1版本的话会出现这个错误，引发错误的根本原因就是先按借鸡生蛋之某电商App签名so的使用(三)对so文件打补丁，如果按上文推荐的文章顺序阅读那么就会被卡住，建议全部读一遍后再动手。 打补丁使用的ida软件，对于汇编是一脸懵逼的，借鸡生蛋之某电商App签名so的使用(三)一文中把修改位置写得很明白了，但是ida真心不会用，其中包括安装ida插件: keystone中下载msi安装文件，Version 0.9.1有提供32位和64位装一个就行。安装过程一定要勾选安装pthon2.7，我就取消了，最后插件无法使用，还是自己手动去安装的，如果你也是手动安装记得安装six模块：pip install six。 把keypatch代码复制，到ida plugins目录建一个新文件Keypatch.py，把代码复制进去。 ida中Options-General-Disassembly-Number of opcode bytes设置成16，以十六进制显示字节码： 使用keypatch插件修改sourceDir部分，JNI_OnLoad部分使用ida功能Edit-Patch program-Change byte就好了。000037CC 04 25 C0 F2 01 05 MOVS R5, #0x10004这段我是用keypatch一直报错，浪费一两个小时，使用Patch program替换中间字节就行了： 修改摘要： 00002D08 40 F0 40 81 BNE.W loc_2F8C -> 00002D08 40 E1 B loc_2F8C 00002F8C 6F F0 02 00 MOV R0, #0xFFFFFFFD -> 00002F8C 4F F0 01 00 MOV.W R0, \#1 000037C8 FF F7 96 F9 BL check_status -> 000037C8 FF F7 96 F9 BL check_status 000037C8 FF F7 96 F9 BL check_status 000037CC 80 46 MOV R8, R0 000037CE 00 28 CMP R0, \#0 000037D0 67 D1 BNE loc_38A2 -> 000037C8 FF F7 96 F9 BL check_status 000037CC 04 25 C0 F2 01 05 MOVS R5, #0x10004 000037D2 2A E0 B loc_382A; 打包一定要看Unidbg使用指南(一)，所有操作都是在test文件夹完成的，不然会缺少包，装又装不上！打包也要载入test文件夹！ 搭建服务 如果你能坚持到这步就已经成功了，只要能获取到签名参数想怎么玩就怎么玩！我还是用http服务比较顺手，网上找了个java socket代码一顿改！！！ 在JD app sign 加密参数破解 - unidbg文中代码基础上修改，加入socket模拟http： ... public static void service(final Socket socket, final JingDong jd) { InputStream inSocket; try { //获取HTTP请求头 inSocket = socket.getInputStream(); int size = inSocket.available(); byte[] buffer = new byte[size]; inSocket.read(buffer); String request = new String(buffer); System.out.println("ClientBrowser:\n" + request + "\n" + "------------------------------------------------------------------"); String httpCode = "200 OK"; String result = ""; if (request.length() > 0) { try { JSONObject data = JSON.parseObject(request.substring(request.lastIndexOf("\r\n")).trim()); if (data != null) { String uuid = data.getString("uuid"); String functionId = data.getString("functionId"); try { String body = new URLCodec().decode(data.getString("body")); String version = data.getString("version"); if (!uuid.isEmpty() && !functionId.isEmpty() && !body.isEmpty() && !version.isEmpty()) { result = convert(jd.runJni(uuid, functionId, body, version)); System.out.println(result); System.out.println(convert(result)); } } catch (DecoderException e) { e.printStackTrace(); } } } catch (JSONException e) { e.printStackTrace(); result = "{\"code\": \"400\", \"message\": \"Invalid param\"}"; httpCode = "400 Bad Request"; } } //将响应头发送给客户端 String responseFirstLine = "HTTP/1.1 " + httpCode + "\r\n"; String responseHead = "Content-Type:application/json\r\n"; OutputStream outSocket = socket.getOutputStream(); System.out.println("ServerResponse:\n" + responseFirstLine + "\n" + responseHead + "\n" + result + "\n" + "--------------------------------------------------------------------"); System.out.println("current thread：" + Thread.currentThread().getName()); System.out.println("threads count：" + Thread.activeCount()); outSocket.write(responseFirstLine.getBytes()); outSocket.write(responseHead.getBytes()); outSocket.write("\r\n".getBytes()); outSocket.write(result.getBytes()); outSocket.close(); socket.close(); } catch (IOException e) { e.printStackTrace(); } } public static void main(String[] args) throws IOException { //獲取參數，服務監聽地址和端口 //java -Daddress=0.0.0.0 -Dport=9999 -jar unidbg-android.jar address = System.getProperty("address", "127.0.0.1"); port = Integer.parseInt(System.getProperty("port", "8668")); threadCount = Integer.parseInt(System.getProperty("thread", "10")); //綫程池 ExecutorService executorService = Executors.newFixedThreadPool(threadCount); final ServerSocket serverSocket; final JingDong jd = new JingDong(); try { //建立服务器Socket,监听客户端请求 serverSocket = new ServerSocket(port, 50, InetAddress.getByName(address)); System.out.println("Server is running on " + serverSocket.getLocalSocketAddress()); //死循环不间断监听客户端请求 while (true) { final Socket socket = serverSocket.accept(); System.out.println("biuld a new tcp link with client,the cient address:" + socket.getInetAddress() + ":" + socket.getPort()); //并发处理HTTP客户端请求 executorService.execute(new Runnable() { @Override public void run() { service(socket, jd); } }); } } catch (Exception e) { e.printStackTrace(); } finally { jd.destroy(); executorService.shutdown(); } } ... 网上七拼八凑折腾出来这么个玩意，使用： java -Daddress=127.0.0.1 -Dport=8668 -DthreadCount=5 -jar xxx.jar address：绑定地址，port：绑定端口，threadCount：线城数量。 请求参数: //没有限制请求方法，GET POST随意，以下是请求body {"uuid":"随机字符串，随机生成就行了","functionId":"接口（genToken）","body":"URI编码的json，不要带任何多余东西","version":"安卓版本"} //返回结果 { "uuid": "9d53afe389f6ae5f", "st": "1630922926986", "sign": "0a9b72a4fc6ffd5d799642dd295623f8", "sv": "111" } 然后外面再套一层nginx反代，或者和自己jd_script同服务器，内网请求。你要是绑定0.0.0.0暴漏出去也行！ 结语 为了个签名折腾了好久，整个签名使用了functionId，body，uuid，client，clientVersion五个参数，client基本可以固定android了。使用ida汇编长了不少知识。 至此应该是不用在操心京东登陆方面的问题了，只要使用京东APP全部都自动更新了！

京东cookie自动更新维护 前言 薅羊毛门槛越来越高了，京东cookie目前有效期只有一天，有些甚至更短。之前扫码登陆目前看来已经获取不到cookie了,现在获取cookie相对麻烦不少。 前段时间很忙，最近闲下来折腾下。看到github上有些脚本，可以抓包获取京东APP请求中cookie，突然有个大胆的想法。如果我让脚本把获取的cookie发送到自己的服务器，服务器自动更新维护cookies.list文件，那么每天打开下APP即可。像IOS有快捷指令APP，让它自动化，每天按时打开京东APP更新cookie,让后服务器自动维护岂不美哉！缺点就是每个用户都得有个可以执行脚本的APP。 废话不多说，干就完了 由于我用的是软路由，openwrt上跑docker（没错，还是LXK0301大佬的那套，自不过修修补补勉强用着，不过目前蛮多用什么面板的！），所以要复杂一点，服务器上部署可以少很多步骤。在openwrt上需要开启frp客户端，然后要映射docker容器端口到本地。还需要一台服务器搭建frp，主要是服务端会搭建在openwrt上，方便外网访问API。在openwrt上部署服务端，接收请求更新本地cookie文件就好了。 服务端 服务端不需要太复杂，用node.js弄个简单的就好了，根据cookie中的pt_pin来替换整行cookie（没有新增哦，只能提换已存在的）： const http = require('http') const fs = require('fs'); const path = require('path') const file = path.resolve(__dirname, '../logs/cookies.list') //路径不同需要改改，你当期间脚本文件相对路径 function writeCookie(pt_key, pt_pin) { const re = new RegExp('.*'+ pt_pin +'.*', 'g') const cookie = `${pt_key};${pt_pin};` // console.log(re) fs.readFile(file,'utf8',function(err,data){ // console.log('替換前' + data) let result = data.replace(re, cookie); // console.log('替換後' + result) fs.writeFile(file, result, 'utf8', function (err) { if (err){ console.log(err) } }); }) } const server = http.createServer(function(request, response) { const contentType = request.headers['content-type'] // response.setHeader('Content-type', 'application/json') // && contentType === 'application/json' if (request.method === 'POST' && request.url === '/cookie/update') { let body = []; request.on('data', (chunk) => { body.push(chunk); }).on('end', () => { // console.log(Buffer.concat(body).toString()) try { body = JSON.parse(Buffer.concat(body).toString()); if (body.pt_key && body.pt_pin) { writeCookie(body.pt_key, body.pt_pin) // console.log(body.pt_key) response.end('OK'); } else { response.statusCode = 400; response.end('Invalid param'); } } catch (e) { response.statusCode = 400; response.end('Invalid param'); } }); } else { response.statusCode = 404; response.end(); } }) const port = 8888 const host = '0.0.0.0' server.listen(port, host) console.log(`Listening at http://${host}:${port}`) 运行 node 脚本名即可启动服务，对于服务器上部署，我还是推荐使用 pm2 来管理 （至于有什么有点，点进去官网了解下吧！）： # 安装 $ npm install pm2@latest -g # or $ yarn global add pm2 # 运行 pm2 start 脚本名 客户端 脚本在此 jd_appopen.js， 只需要稍作修改即可： /* 杀掉后台后打开京东app获取app_open 在脚本日志查看值 [MITM] hostname = api.m.jd.com ===========Surge================= [Script] jd_appopen = type=http-request,pattern=^https:\/\/api\.m\.jd\.com\/openUpgrade, max-size=0, script-path=jd_appopen.js ===================Quantumult X===================== [rewrite_local] # jd_appopen ^https:\/\/api\.m\.jd\.com\/openUpgrade url script-request-header jd_appopen.js =====================Loon===================== [Script] http-request ^https:\/\/api\.m\.jd\.com\/openUpgrade script-path=jd_appopen.js, timeout=3600, tag=jd_appopen */ const $ = new Env("app_open") if ($request.headers) { let cookie = ($request.headers.Cookie || $request.headers['Cookie'] || $request.headers['cookie'] || '') let pt_key = cookie.match(/(pt_key=[^;]*)/)[1] let pt_pin = cookie.match(/(pt_pin=[^;]*)/)[1] if (pt_key && pt_pin) { console.log('================') console.log(`${pt_key};${pt_pin};`) console.log('================') const options = { "url": `换成你的域名/cookie/update`, 'body': JSON.stringify({ "pt_key": pt_key, "pt_pin": pt_pin }) } $.post(options, (err, resp, data) => { try { if (err) { $.msg("app_open获取成功！", `更新cookie失败: ${JSON.stringify(err)}`) console.log(`pp_open获取成功,更新cookie失败: ${JSON.stringify(err)}`) } else { console.log(`更新cookie: ${data}`) } } catch (e) { $.logErr(e, resp) } }) } } $.done($request.headers) ... 然后使用你手机APP（Surge、Quantumult X、Loon、shadowrocket）添加即可，shadowrocket我试过也可以，成本相对其他app应该便宜点！ IOS快捷指令 在快捷指令APP中添加个自动化，运行前询问看自己情况开启，这里的shadowrocket可以换成其他执行脚本APP，如果你跑脚本的APP常驻打开那么就可以删掉shadowrocket部分，启动此自动化需要打开： 快捷指令有个缺点，不是所有自动化都可以锁屏运行，像这个也是，但是会发送通知，点击通知就可以，或者自己不使用，每天自己手动也是一样的！ 结语 没有写很详细，这些也就是大概思路，还有很多值得优化的地方。京东这次动作能刷下不少代挂了，操作成本太高了。对于三五个好友玩玩还行。如果喜欢折腾的应该能按照思路完善吧，写得太详细有时候真不是件好事！

Nginx SNI 分流（端口复用）使用Xray+VLESS+XTLS 前言 Xray已经出来一段时间了，之前一直使用VLESS+tls+ws方式科学上网，其实都够用，没什么问题。但是了解了下XTLS黑科技，再看看Xray性能测试，这货简直爆炸，性能是TLS的数倍。 其实之前折腾过一次，但是Xray要监听443端口（不监听也行，但是不完美啊），影响做站。虽然有解决方法，但是不够完整，我一不小心就跳坑里面去了。Xray已经带了SNI回落功能（教程看这里：通过 SNI 回落功能实现伪装与按域名分流），Nginx也带SNI功能，我还是觉得用Nginx的比较好，免得折腾Xray影响网站运行。 这里我不会写如何安装Xray，因为教程实在是太多了，嫌麻烦还有一键脚本：Xray_onekey（V2ray脚本别用这个作者的哈,特别是服务器有站点的！！！Xray脚本这个大佬的还不错）。 坑 因为服务器上有几个站点，装完Xray后实现SNI分流，过程非常顺利，但是chrome上有问题，几个二级域名访问的内容全部和第一个访问的域名一样。 例如：我先访问 a.example.com 然后在访问 b.example.com，b.example.com 响应内容和 a.example.com 一模一样，然后再访问 c.example.com 还是和 a.example.com 一样。开chrome隐身模式直接访问 c.example.com 正常，然后访问 a.example.com 或 b.example.com 内容又全是 c.example.com 的（不一定会每次都这样，要看浏览器是否使用现有连接或服务器是否断开了之前的连接）。 这个问题折腾我很长时间，最后发现和HTTP/2有关，我所有站点不使用HTTP/2就会正常，只要有一个站点使用了HTTP/2，你先访问HTTP/2站点，那么后面的其他子域名都会变成它的内容。这个情况没有仔细测试证明，无法确定。 最开始我使用Xray的SNI也是这样，我还以为是Xray SNI的问题，之后换成Nginx使用SNI还是这样。chrome中有这个问题，用手机safari浏览器完全正常。 经过网上一番搜刮，终于找到了问题根源：通配符域名证书。 首先你得了解什么是SNI，个人理解：SNI就是通过证书区分服务。多个二级域名使用通配符域名证书的话，相同的证书无法区分具体想访问的服务，因为它们的证书都一样。 用下人家的图（原作者文章：Multiplex TLS Traffic with SNI Routing）： *由于原始服务器10.0.3.2使用的TLS证书具有通配符名称 .example.com，因此Web浏览器可以建立服务器名称为 b.example.com 的 TLS连接，并对HTTP/2请求使用相同的连接到 a.example.com。这可能会在网站和应用程序中导致未定义的行为。** 因为HTTP/2会保持TCP连接，导致你访问了 a.example.com 后，在访问 b.example.com 的时候使用的同一个连接，SNI跟失效了一样，直接使用该连接访问之前的服务。我在Xray的调试日志中发现访问错误的域名没有获取到，是空的！ 两个域名使用同一个连接（红框内是连接ID），可以很清楚的看到两个域名使用同一个连接，返回的内容也是一模一样： 解决办法两种： 不使用HTTP/2。不确定是否HTTP2的问题，但是你可以试一试 不使用通配符域名证书，站点域名证书一个个申请。 配置Nginx SNI 使用Nginx首先得安装（如果服务器自带就不用折腾了），不会安装Nginx可以看我之前的文章：Ubuntu 安装nginx（如果使用Xray_onekey脚本，那他已经帮你全部弄好了，你都不用折腾）。 nginx.conf配置追加： stream { map $ssl_preread_server_name $orzlee { a.example.com a; b.example.com b; c.example.com c; } upstream a { server 127.0.0.1:60088; ### A站点监听端口，xray xtls伪装站点 } upstream xtls { server 127.0.0.1:4443; ### 你的Xray端口 } upstream b { server 127.0.0.1:60001; ### B站点监听端口，业务站点 } upstream c { server 127.0.0.1:60002; ### C站点监听端口，业务站点 } server { listen 443 reuseport; listen [::]:443 reuseport; proxy_pass $orzlee; ssl_preread on; proxy_protocol on; } server { ### Xray XTLS listen 127.0.0.1:60088 proxy_protocol; proxy_pass xtls; } } a.example.com.conf配置（伪装站点）: server { listen 80; listen [::]:80; server_name a.example.com; return 301 https://$http_host$request_uri; } server { ### 伪造站点由Xray处理SSL listen 127.0.0.1:60003 proxy_protocol; ### xray http/1.1 listen 127.0.0.1:60004 http2 proxy_protocol; ### xray http/2 set_real_ip_from 127.0.0.1; real_ip_header proxy_protocol; port_in_redirect off; ###重定向去掉端口号 server_name a.example.com; index index.html index.htm index.php default.php default.htm default.html; root /var/www/a.example.com; ... } b.example.com.conf配置（其他业务站点配置照葫芦画瓢）: server { listen 80; server_name b.example.com; rewrite ^(.*) https://b.example.com$1 permanent; } server { listen 127.0.0.1:60001 proxy_protocol ssl http2; set_real_ip_from 127.0.0.1; ### 获取真实客户IP，不然全是127.0.0.1 real_ip_header proxy_protocol; port_in_redirect off; ###重定向去掉端口号。不然类似 try_files nginx帮你重定向时，你浏览器上都带了60003这样的端口 ssl_certificate b.example.com.cer; ### 证书换成你的 ssl_certificate_key b.example.com.key; ### 证书换成你的 server_name b.example.com; root /var/www/b.example.com; index index.php index.html index.htm; ... } 配置Xray 服务端配置： { "log": { "access": "/var/log/xray/access.log", "error": "/var/log/xray/error.log", "loglevel": "warning" }, "inbounds": [ { "listen": "127.0.0.1", "port": 4443, "protocol": "vless", "settings": { "clients": [ { "id": "你的UUID", "flow": "xtls-rprx-direct" } ], "decryption": "none", "fallbacks": [ { "dest": 60003, "xver": 1 }, { "dest": 60004, "alpn": "h2", "xver": 1 } ] }, "streamSettings": { "network": "tcp", "security": "xtls", "xtlsSettings": { "alpn": [ "h2", "http/1.1" ], "minVersion": "1.3", "certificates": [ { "certificateFile": "b.example.com.cer 记得换证书", "keyFile": "b.example.com.key 记得换证书" } ] } }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] } } ], "outbounds": [ { "protocol": "freedom" } ] } 客户端看作者说明吧，值得一看：Outbounds 可用协议列表-VLESS，flow仔细看看。 结语 本来折腾Xray的，结果Nginx折腾大半天。虽然掉坑里了，总算是爬出来了，受益匪浅！ 通配符证书用起来省事，碰到坑了一下还不好找问题。就今天这个坑上网找都不知道怎么描述，基本上找不到相关问题，比较冷门。之前参考其他博主Nginx SNI配置发现有其他同学也有这样的问题，但是无从查起，不了了之！ 遇到这个坑不长记性都难。

openwrt-安装oh-my-zsh 前言 openwrt的shell连上次会话历史记录都没有，很是蛋疼。不如换成oh-my-zsh,还有很多插件可以玩。 VPS上安装可以看之前的文章：oh-my-zsh强大的zsh配置管理 安装 操作前记得备份你得openwrt配置，现在很多用的都是改版openwrt，不确定会发生什么奇奇怪怪的问题，但是大部分是没有问题的，备份一下保险。 登陆到openwrt ssh,首先安装依赖： opkg update && opkg install wget unzip zsh ca-certificates 安装oh-my-zsh: sh -c "$(wget -O- https://raw.githubusercontent.com/felix-fly/openwrt-ohmyzsh/master/install.sh)" 这时候已经安装完成了，还差设置默认shell为zsh: which zsh && sed -i -- 's:/bin/ash:'`which zsh`':g' /etc/passwd 到此结束，退出当前会话然后重新登陆ssh看看是不是已经默认为zsh了。 有了历史记录再配合命令补全、命令高亮插件简直不能太爽！！！ 自动补全插件或其他插件安装方法还是请看：oh-my-zsh强大的zsh配置管理 自动补全插件： 命令高亮插件： 如果你要卸载oh-my-zsh的话： sh -c "$(wget -O- https://raw.githubusercontent.com/felix-fly/openwrt-ohmyzsh/master/uninstall.sh)" 结语 装完oh-my-zsh感觉没有束缚了，这样的终端爽的飞起。之前所有的服务器都装了oh-my-zsh，习惯了，没有oh-my-zsh总感觉太单调了，敲起来不顺手。

LXK0301京东签到脚本-京喜工厂解决无法签到异常 前言 LXK0301大佬的京喜工厂自动签到脚本不知怎么一直提示：亲,活动太火爆了,请稍后再试吧!,基本无法使用，任务也不自动做了。 上网查了一下，全是说黑号，真蛋疼。因为脚本无法做任务什么的，但是手动完全没有问题，根本不是黑号，网上一股脑说黑号。 我就不信邪，app能做任务脚本就不行，肯定是脚本有问题。 2021-03-25 第二次更新，已经不需要自己抓包获取签名参数了，脚本会在每次执行时自动获取签名参数。已经联系作者，等作者更新吧！(推荐使用作者脚本，修复了参团问题) 2021-03-25更新，今天更新了下脚本，应该可以获取自己的签名参数使用了，有时间的朋友可以测试一下！仓库地址：jd_scripts-orzlee 2021-03-23更新，自己获取签名的方法可能无效，作者已经跟新脚本，目前使用我提供的签名参数可以正常做任务和领取电力，后续可能还需要研究。更新作者脚本即可！ 原因 最根本的原因就是脚本发送请求链接签名有问题，这个好像只针对了部分用户，有的用户没问题，有的就会一直提示：亲,活动太火爆了,请稍后再试吧!。 起初发现问题是在手机上用QuantumultX抓包京喜APP，点击地上的零件，再抓包脚本，然后找出usermaterial/PickUpComponent请求来对比。开始我还以为是cookie问题，我替换cookie重试请求还是太火爆错误，再重发一下抓包京喜APP的请求，依然成功。再替换替换脚本请求的url参数为抓包app的，莫名奇妙的成功了。这个锅必须脚本背了！ 脚本中decrypt函数是负责请求链接签名的，但是目前脚本有问题，很多签名key都是没有值的，因为根本没有获取值，只有少部分定义了默认值。来看一下代码(目前是1535行)： function decrypt(time, stk, type) { if (stk) { const random = 'pmUmA8IyRcDp'; //这些常量其实每个用户都可能不一样 const token = `tk01wd4571d58a8nT0tkdXczeW94f5x4qjWs44kcPCTXeWKa2xXY+ZxHaOtbRxmyw6vrIF4RDFwwTUfwy1pIqNE0oyWW`; //这些常量其实每个用户都可能不一样 const fingerprint = 8410347712257161; //这些常量其实每个用户都可能不一样 //这个时间转换和现在的不一样，现在是new Date(time).Format("yyyyMMddhhmmssSSS");，转换结果不一样，加密出来也不一样 const timestamp = new Date(time).Format("yyyyMMddhhmmssS"); const appId = 10001; //这个是活动id 是固定的 const str = `${token}${fingerprint}${timestamp}${appId}${random}`; const hash1 = $.CryptoJS.HmacSHA512(str, token).toString($.CryptoJS.enc.Hex); //这里加密算法有可能不一样 let st = ''; stk.split(',').map((item, index) => { //下面的签名参数只有些默认值，很多都是空的，但是链接上又带了有效值，服务器验签估计不合法(但是有的用户却没有问题，搞不懂) st += `${item}:${item === '_time' ? time : item === 'zone' ? 'dream_factory' : item === 'type' ? type || '1' : ''}${index === stk.split(',').length -1 ? '' : '&'}`; }) const hash2 = $.CryptoJS.HmacSHA256(st, hash1).toString($.CryptoJS.enc.Hex); console.log(`st:${st}\n`) // console.log(`hash2:${JSON.stringify(["".concat(timestamp.toString()), "".concat(fingerprint.toString()), "".concat(appId.toString()), "".concat(token), "".concat(hash2)])}\n`) console.log(`h5st:${["".concat(timestamp.toString()), "".concat(fingerprint.toString()), "".concat(appId.toString()), "".concat(token), "".concat(hash2)].join(";")}\n`) return ["".concat(timestamp.toString()), "".concat(fingerprint.toString()), "".concat(appId.toString()), "".concat(token), "".concat(hash2)].join(";") } else { return '20210121201915905;8410347712257161;10001;tk01wa5bd1b5fa8nK2drQ3o3azhyhItRUb1DBNK57SQnGlXj9kmaV/iQlhKdXuz1RME5H/+NboJj8FAS9N+FcoAbf6cB;3c567a551a8e1c905a8d676d69e873c0bc7adbd8277957f90e95ab231e1800f2' } } 研究过程我就不再多说了，京东那边全是混淆的JS，真的很头疼，我弄了一下午才摸清楚他的逻辑。 整个流程大概是这样（官方的js混淆了，乱七八糟的就不贴代码了）： 第一次进入活动页面会发送POST请求：https://cactus.jd.com/request_algo?g_ty=ajax，将返回结果储存在本地（这个默认应该没有有效期，但是京喜工厂里面的JS会设置有效期，过期会重新获取）。已经更新脚本自动获取签名参数了。 请求参数： { appId: "10001" expandParams: "" //fingerprint //pc浏览器我试过，就算拿到所有数据跑脚本依然不行，还是太火爆错误。所以保险还是去京喜APP抓包吧！ fp: "5525701123405161" platform: "web" timestamp: 1614687205087 version: "1.0" } 接口会返回： { data: { result: { //加密函数 algo: "function test(token,fingerprint,timestamp,appId,algo){const random='jQ1SS0VI2Vuw';const str=`${token}${fingerprint}${timestamp}${appId}${random}`;return algo.SHA512(str)}" //加密token tk: "tk01w91541b51a8nWURUM3hiZk9HHRKep5j4FeOg/jHOQoGSDcsasdSOZ+83iz4uf/YBXHcK6xMIUqqv5/iJv6F0aooT5Nd3" } version: "1.0" message: "" status: 200 } } 这个接口会返回所有签名需要的参数，也就是脚本中decrypt中的参数，其实照着值样子都知道怎么替换了。 当前时间格式转换new Date(time).Format("yyyyMMddhhmmssSSS")这个时间是和链接参数中的'_time匹配'。 字符串拼接${token}${fingerprint}${timestamp}${appId}${random}。 第一次签名，将第三步的字符串用SHA或者MD5加密，这个主要参考第一步中的机密函数: function test(token,fingerprint,timestamp,appId,algo){ const random='jQ1SS0VI2Vuw'; const str=`${token}${fingerprint}${timestamp}${appId}${random}`; return algo.SHA512(str) } 这个函数提供了加密方法和随机字符串，官方直接用它做闭包函数第一次签名。 第一次签名完成后，开始第二次了，这个参数每个接口可能不同，它会按照请求url中的_stk参数来提供签名参数，例如&_stk=_time,pin,placeId,zone,那么就需要将参数拼接成time:xxxx&pin:xxxx&placeId:xxxx&zone:xxx这样子。stk参数的值也会包含在url中,例如： https://m.jingxi.com/dreamfactory/usermaterial/PickUpComponent?zone=dream_factory&placeId=1&pin=91DCBu8VvYt6rEdezHZ_VQ%3D%3D&_time=1614622722731&_stk=_time%2Cpin%2CplaceId%2Czone&_ste=1&h5st=20210302021842732%3B6099600123439161%3B10001%3Btk01wa66691cafa8nSmV1UDN2SWtZAiPI1uR1EAuPwYDaw36v9gQGhJz5Ac4h2cjfkeCQexVweqwa6%2BsjvERwkVU6wxTK%3Ba795we798qwe789789qe8262584d49f9449a1ce0194bb26c72049eef428f5e23e1043a641d&_=1614622722744&sceneval=2&g_login_type=1&callback=jsonpCBKR&g_ty=ls 第二次签名加密的算法是固定的，SHA256。 最后拼接： ["".concat(timestamp.toString()), "".concat(fingerprint.toString()), "".concat(appId.toString()), "".concat(token), "".concat(hash2)].join(";") 抓包 2021-03-04 更新可以免去抓包和修改脚本操作了： 一旦有一个设备的url签名参数更新，其他设备都会失效，如果多设备跑同一个账号要保持一直，否则还是会失败的！！！ 我更新了脚本，不需要手动抓包了，QuantumultX可以添加url_sign_params.conf重写引用，其他平台可能需要自己写一下。然后删除京喜APP，重新下载后进入京喜工厂（最好重下APP，不然有可能还是太火爆异常，如果没有提示退出京喜工厂再进一次，多试试！）: 折腾好了就只使用京喜APP进入京喜工厂（url签名参数会被京喜工厂里面的JS设置过期时间，过期会重新获取），以免从京东APP进入京喜工厂跳转到京喜APP重新获取覆盖，京东APP里面的京喜工厂获取的url签名参数也不能执行成功！只能使用京喜APP的url签名参数！ 日志可以查看url签名参数： 以下为未更新之前的方法： 找到了问题就好解决了，抓包京喜APP一个请求就行了，抓包之前建议先删除APP，因为签名参数会存在本地，基本上弄不到了。删掉APP再进入京喜工厂之前，准备好抓包工具，IOS可以用QuantumultX、Surge等,PC抓包太多了，一搜一大把。 准备好抓包工具之后，进入京喜工厂，等待完全进入工厂，最好再捡下零件。没有报错就可以关掉抓包工具了。 搜索algo,找到签名参数请求： 请求JSON和响应JSON都要看，不然你不知道fingerprint参数，是一串数字，在请求JSON里： 复制返回请求中的参数： 修改脚本 脚本我修改了很多处，但是很简单： 新增一个获取url参数的函数： /** * 新增url参数获取函数 * @param url_string * @param param * @returns {string|string} */ function getUrlQueryParams(url_string, param) { let url = new URL(url_string); let data = url.searchParams.get(param); return data ? data : ''; } 时间函数与官方不一致，会导致签名结果错误（这函数是官方混淆JS里面扒出来的）： /* 修改时间戳转换函数，京喜工厂原版修改 */ Date.prototype.Format = function (fmt) { var e, n = this, d = fmt, l = { "M+": n.getMonth() + 1, "d+": n.getDate(), "D+": n.getDate(), "h+": n.getHours(), "H+": n.getHours(), "m+": n.getMinutes(), "s+": n.getSeconds(), "w+": n.getDay(), "q+": Math.floor((n.getMonth() + 3) / 3), "S+": n.getMilliseconds() }; /(y+)/i.test(d) && (d = d.replace(RegExp.$1, "".concat(n.getFullYear()).substr(4 - RegExp.$1.length))); for (var k in l) { if (new RegExp("(".concat(k, ")")).test(d)) { var t, a = "S+" === k ? "000" : "00"; d = d.replace(RegExp.$1, 1 == RegExp.$1.length ? l[k] : ("".concat(a) + l[k]).substr("".concat(l[k]).length)) } } return d; } decrypt函数也要修改，我加了一个url参数，在拼接签名参数需要的值可以在url中拿（实在不想动太多代码，怎么方便怎么来吧）： /* 签名函数 签名信息获取地址：https://cactus.jd.com/request_algo?g_ty=ajax 方法： POST 参数：{ appId: "10001" expandParams: "" fp: "5525701123405161" //fingerprint platform: "web" timestamp: 1614687205087 version: "1.0" } 返回结果：{data: { result: { algo: "function test(token,fingerprint,timestamp,appId,algo){const random='jQ1SS0VI2Vuw';const str=`${token}${fingerprint}${timestamp}${appId}${random}`;return algo.SHA512(str)}" //加密函数 tk: "tk01w91541b51a8nWURUM3hiZk9HHRKep5j4FeOg/jHOQoGSDcsasdSOZ+83iz4uf/YBXHcK6xMIUqqv5/iJv6F0aooT5Nd3" //token } version: "1.0" message: "" status: 200 } } 将返回参数替换： const random : data.result.algo字符串中的const random='xxxxxx' const token : data.result.tk const fingerprint : 通过抓包APP获取 const hash1加密方法（例子：algo.SHA512、algo.MD5，主要看签名信息获取地址返回结果data.result.algo） */ function decrypt(time, stk, type, url) { stk = stk || (url ? getUrlQueryParams(url, '_stk') : '') if (stk) { const random = '1gy8nc5oDM+y'; const token = `tk01w9a771c1aa8nd1k2NUo4UmNaahBe0/qh61gMNV9222JdJwlR0wyO9gko9dFTogSpvPIpqxstZJ9tl8JM9ONKNJWk`; const fingerprint = 5525701217505161; const timestamp = new Date(time).Format("yyyyMMddhhmmssSSS"); const appId = 10001; const str = `${token}${fingerprint}${timestamp}${appId}${random}`; const hash1 = $.CryptoJS.HmacSHA512(str, token).toString($.CryptoJS.enc.Hex); let st = ''; stk.split(',').map((item, index) => { // st += `${item}:${item === '_time' ? time : item === 'zone' ? 'dream_factory' : item === 'type' ? type || '1' : ''}${index === stk.split(',').length -1 ? '' : '&'}`; st += `${item}:${getUrlQueryParams(url, item)}${index === stk.split(',').length -1 ? '' : '&'}`; }) const hash2 = $.CryptoJS.HmacSHA256(st, hash1).toString($.CryptoJS.enc.Hex); console.log(`st:${st}\n`) // console.log(`hash2:${JSON.stringify(["".concat(timestamp.toString()), "".concat(fingerprint.toString()), "".concat(appId.toString()), "".concat(token), "".concat(hash2)])}\n`) console.log(`h5st:${["".concat(timestamp.toString()), "".concat(fingerprint.toString()), "".concat(appId.toString()), "".concat(token), "".concat(hash2)].join(";")}\n`) return ["".concat(timestamp.toString()), "".concat(fingerprint.toString()), "".concat(appId.toString()), "".concat(token), "".concat(hash2)].join(";") } else { return '20210121201915905;8410347712257161;10001;tk01wa5bd1b5fa8nK2drQ3o3azhyhItRUb1DBNK57SQnGlXj9kmaV/iQlhKdXuz1RME5H/+NboJj8FAS9N+FcoAbf6cB;3c567a551a8e1c905a8d676d69e873c0bc7adbd8277957f90e95ab231e1800f2' } } 最后一步了，搜索${decrypt(关键字，大概有8处要修改，主要是团长这部分多，主要还是没有解耦： 参团部分（每一个api不一样，只要剥离出&h5st=${decrypt(xxxxx就行了，单独拼接）： //可获取开团后的团ID，如果团ID为空并且surplusOpenTuanNum>0，则可继续开团 //如果团ID不为空，则查询QueryTuan() function QueryActiveConfig() { return new Promise((resolve) => { //option中的url拉出来替换如下 let url = `https://m.jingxi.com/dreamfactory/tuan/QueryActiveConfig?activeId=${escape(tuanActiveId)}&_time=${Date.now()}&_=${Date.now()}&sceneval=2&g_login_type=1&_ste=1` url += `&h5st=${decrypt(Date.now(), '', '', url)}` const options = { 'url': url, //改成变量 "headers": { ... taskurl和newtasksysUrl函数部分: function taskurl(functionId, body = '', stk) { let url = `${JD_API_HOST}/dreamfactory/${functionId}?zone=dream_factory&${body}&sceneval=2&g_login_type=1&_time=${Date.now()}&_=${Date.now()}&_ste=1` url += `&h5st=${decrypt(Date.now(), stk, '', url)}` if (stk) { url += `&_stk=${stk}`; } ... function newtasksysUrl(functionId, taskId, stk) { let url = `${JD_API_HOST}/newtasksys/newtasksys_front/${functionId}?source=dreamfactory&bizCode=dream_factory&sceneval=2&g_login_type=1&_time=${Date.now()}&_=${Date.now()}&_ste=1`; if (taskId) { url += `&taskId=${taskId}`; } if (stk) { url += `&_stk=${stk}`; } //传入url进行签名,加入位置不要错了，不然有些签名参数获取不到值 url += `&h5st=${decrypt(Date.now(), stk, '', url)}` ... 大功告成，发到手机上或者node跑一下试试： 结果非常完美。 docker处理 手机端好办，docker麻烦一点，放到远程或者本地都行，具体看说明jd_scripts docker。docker提供了一个环境变量CUSTOM_SHELL_FILE（你也可以用CUSTOM_LIST_FILE挂载本地定时任务列表,只是更新要手动，要自动还是需要脚本的）可以跑远程shell脚本，jd_scripts docker说明中还有示例，照葫芦画瓢即可。我在github上弄一份自用，你可以参考或者fork一份自己用,地址：jd_scripts-orzlee。只需替换decrypt函数部分常量就好了，shell脚本最好看看我写的注释。然后在环境变量中加入shell脚本地址CUSTOM_SHELL_FILE=https://raw.githubusercontent.com/xxx/xxx.sh即可。 如果用我仓库的远程脚本，务必docker配置环境变量RANDOM_DELAY_MAX=600, 600的值可以自己设置非零正整数，意思是所有脚本每天随机延迟0-600秒执行。 结语 经过不懈努力，终于还是折腾好了，这半个月都是手动点击脚本，人家升级都比我快，没办法手动哪里有脚本那么按时呢！混淆JS浪费不少时间，眼睛都能看瞎。

LXK0301京东签到脚本-自动提交互助码 前言 今天24号，刚好是LXK0301助力码清除日期，晚上给忘记了，到中午才发现今天互助码重置。 瞬间感觉错误一个亿，之前就想过要折腾个自动提交互助码的脚本，就是太懒了。今天亡羊补牢，折腾折腾。有兴趣可以用阅读我之前的文章QuantumultX-京东签到撸京东豆、openwrt-docker部署lxk0301京东自动签到脚本。 安装Telegram-Cli 此安装环境是VPS，openwrt上安装用docker，当然VPS也可以使用docker! 科学上网必备，没有一个良好的网络环境为前提都是白折腾！！！ docker安装（推荐，省去一大堆麻烦事）： 镜像地址：ugeek/telegram-cli 安装镜像： docker create --name telegram-cli -e TZ=Asia/Shanghai -v 挂载本地目录:/root/.telegram-cli ugeek/telegram-cli:amd64 启动docker: docker start telegram-cli 执行telegram-cli命令行交互（先执行一次登陆，输入telegram注册的手机号码，号码记得加区号。） docker exec -it telegram-cli telegram-cli -N -W 以下为编译安装步骤（docker或者编译二选一即可）： 克隆telegram-cli: cd /root/work/telegram ### 或者你自己想要存放的目录 git clone --recursive https://github.com/vysheng/tg.git && cd tg 编译安装 ### ubuntu sudo apt-get update sudo apt-get -y install libreadline-dev libconfig-dev libssl-dev lua5.2 liblua5.2-dev libevent-dev libjansson-dev libpython-dev make ./configure make 如果编译安装出现如下错误： 解决方法： apt-get install -y libgcrypt20-dev libssl-dev ./configure --disable-openssl --prefix=/usr CFLAGS="$CFLAGS -w" make 申请Telegram APP Key并且登陆telegram-cli 首先到telegram-apps里申请一个telegram App key（登陆时电话号码记得加国际区号）。 复制Public keys: 创建一个文件保存Public keys: nano /root/work/telegram/bot_key.pub ###鼠标右键粘贴 ctrl+o ##保存 按完记得敲车键 ctrl+x ##退出 登陆telegram-cil /root/work/telegram/tg/bin/telegram-cli -k /root/work/telegram/bot_key.pub ###输入账号绑定的手机号码，记得加区号 ###输入telegram App收到的验证码 IOS锁屏就会提示offline,打开手机telegram app就会提示online。 测试一下命令： telegram-cil频道名称如果有空格用下划线代替。 发送命令格式/root/work/telegram/tg/bin/telegram-cli -W -e "msg 频道名称 命令" ### 发送一条统计当前互助码池命令 /root/work/telegram/tg/bin/telegram-cli -W -e "msg Turing_Lab_Bot /count_activity_codes" 回显信息比较乱，自己看手机或PC telegram APP Turing_Lab_Bot机器人 消息就好了。 编写脚本 把互助码准备好，编写脚本： ### 创建一个文件，保存脚本 nano /root/work/telegram/submit_activity_codes.sh 2021-05-08 优化加载会话列表，resolve_username 只加载需要发送命令的两个BOT，避免会话太多出现奇奇怪怪的问题。 2021-03-08 优化了定时任务脚本，速度更快，不会中断了，之前的脚本有问题，会经常中断(原因是因为脚本中执行发送消息命令太快-W参数加载消息会话列表没有完成就已经发出命令，导致命令出错！)。 复制以下内容，互助码自己替换，其他活动互助码自己添加（多个互助码用&拼接）： #!/bin/bash telegramPath=TG Path #记得替换你telegram-cli目录/xxx/tg/bin ( echo "resolve_username TuringLabbot" echo "resolve_username LvanLamCommitCodebot" sleep 5 ### @Turing_Lab_Bot ###京喜财富岛 echo "msg Turing_Lab_Bot /submit_activity_codes jxcfd 互助码" ###京东闪购盲盒 echo "msg Turing_Lab_Bot /submit_activity_codes sgmh 互助码" ###京东环球挑战赛 echo "msg Turing_Lab_Bot /submit_activity_codes jdglobal 互助码" ###惊喜工厂 echo "msg Turing_Lab_Bot /submit_activity_codes jxfactory 互助码" ###东东工厂 echo "msg Turing_Lab_Bot /submit_activity_codes ddfactory 互助码" ###东东萌宠 echo "msg Turing_Lab_Bot /submit_activity_codes pet 互助码" ##种豆得豆 echo "msg Turing_Lab_Bot /submit_activity_codes bean 互助码" ###东东农场 echo "msg Turing_Lab_Bot /submit_activity_codes farm 互助码" ### @Commit_Code_Bot ###JD签到领现金 提交助力码 echo "msg Commit_Code_Bot /jdcash 互助码" ###JD签到领现金 提交助力码 echo "msg Commit_Code_Bot /jdcrazyjoy 互助码" echo "safe_quit" ) | ${telegramPath}telegram-cli -D -D参数关闭了输出，调试的时候可以删除该参数(虽然没什么用，因为你命令发出去还没有等回显就已经结束命令了)。 docker 用户将最后一行脚本替换成) | docker exec -i telegram-cli telegram-cli -N,删除telegramPath=TG Path #记得替换你telegram-cli目录/xxx/tg/bin即可 保存脚本 ctrl+o ##保存 按完记得敲回车键 ctrl+x ##退出 赋予脚本可执行权限 chmod +x /root/work/telegram/submit_activity_codes.sh 测试的时候记得注释大部分命令，留一到两个就行了，频繁提交小心被Bot Ban号。 bash /root/work/telegram/submit_activity_codes.sh 看看手机接收到的通知，一般接收到通知无非就是提交成功或助力池已满。 添加crontab定时任务 助力池每次清空日期为每月1，8，16，24号，延迟10分钟后执行： crontab -e 10 0 1,8,16,24 * * bash /root/work/telegram/submit_activity_codes.sh 结语 其他Bot签到什么的可以举一反三。 这下一劳永逸，省的忘记错过一个亿。最近京东活动也比较多，没有助力活动任务很难完成，助力才是京东活动的灵魂。