iOS任意版本号APP下载(含itunes 12.6.5.3 最后带AppStore版本) 软件介绍 下载iOS旧版应用,简化繁琐抓包流程。 一键生成去更新IPA(手机安装后,去除App Store的更新检测) 软件界面 支持系统 windows 10/windows 8/windows 7(由于使用了Fiddler库,所以需要.Net环境) 使用方法 一、直接搜索方式 搜索APP,双击选择。 双击选择要下载的版本。 在iTunes中下载即可。 二、复制APP链接方式 在iTunes下载按钮右侧下拉菜单中,选择【复制链接】。 双击选择要下载的版本。 在iTunes中下载即可。 常见问题 问:iTunes 账号无法登录成功 请先关闭本工具,再进行 iTunes 登录操作。 登录成功后,再打开本工具即可。 问:iTunes对电脑进行授权时,授权不了,反复授权 关闭本工具,再进行授权即可。 问:搜不到APP历史版本号?(以下方法100%可解决) 先不要拦截,在iTunes商店中下载此软件,等待下载完成。 在本工具中【安装管理】下找到对应IPA安装包,右键选择【查找版本ID】。 即可列出软件所有历史版本ID,版本号按新版到旧版排序。 PS:暂时没有通过版本ID,查版本号的接口,所以抓下来,看吧。 问:iTunes 一直显示正在下载... iTunes 先取消下载。 本工具【停止拦截】,再点击iTunes【继续下载】。 问:下载完APP,安装到手机,打开闪退。 先在手机中卸载该APP。 使用下载此App的账号,登录 App Store,在 App Store 中随便下载一个应用,不要卸载。 使用同步助手,重新安装。(如果仍闪退,尝试覆盖安装) 问:导入伪旧版App后,iTunes未检测到更新。 iTunes 更新列表页面下,按F5即可。 如上述方法未解决,删除当列表所有文件,保留文件,再点击右下角检测更新按钮。 问:“已停止供货”的APP 怎么抓取?(已失效) 取消拦截,下载该软件最新版。 本助手里切换到【安装管理】,右键APP,选择【伪装旧版APP】。 双击【*_伪装版.ipa】(或右键,在文件夹中打开),将APP拖动到iTunes资料库,替换,检查更新,该软件变为更新状态。 【开始拦截】,iTunes中更新该软件,即可正常下载该版本。 查杀链接 查杀链接 视频教程 ht 阅读全文
打造一个可国内访问的Blogger(Blogspot)方法 Blogger,一个干爽、免费的博客发布平台,作为主流的发布,提供免费的托管,免去了Typecho&Wordpress高昂的服务器费用,避免了Hexo&Jekyll静态博客无后台的缺陷,与CSDN、简书相比,可以绑定域名,界面干净,无广告【当然可以自己放自己的广告】。 实际上,当今写博客的软件数不胜数,主要分为一下三类: 服务器部署:典型代表:Wordpress\Typecho 无服务器托管:典型代表:Hexo\Jekyll\Gidea\Hugo\Hola等等 集成型网站:Blogger、简书、CSDN、cnblog、wodemo等等 上面所有软件,优缺点都有,具体看个人选择 当然,个人认为Typecho适合做个人博客,Hexo可以作为要求不高的人。集成性网站最主要的是只要安安心心写文章,不用管后端乱七八糟的代码。当然,最有问题的是大多数都不支持绑定域名,而且经常往网站上塞广告,自定义范围也不够。 接下来,我们扯扯集成博客中的一股清流:Blogger Blogger.com是由Pyra Labs公司创立,是目前全球用户数量最多的个人网志服务提供商。Pyra Labs和Blogger.com均被Google公司收购,成为其旗下的一项服务内容。 Blogger提供免费主机Blogspot.com存放博客,用户不必写任何代码或者安装服务器软件或脚本,通过所见即所得界面轻松地创建、发布、维护和修改自己的网志。 Blogger允许有经验的用户自行设计博客界面,其模板支持使用HTML和CSS进行编辑 实际上,由于Blogger托管于谷歌,写作域名 www.blogger.com 和托管域名 *.blogspot.com 均被MainLand所Ban。但是接下来来,我会讲讲如何打造一个能在国内大陆访问的Blogger 1. 注册Blogger 众所周知,请善用技术上网。 用谷歌账号登录 ( https://www.blogger.com ) ,没有?不是⑧不是吧不是扒,都0202年了,还不会去注册一个谷歌账号? 进入控制台,新建一个博客: 绑定域名,这一步随意,因为我们还要绑定一个自定义域 阅读全文
WireGuard+V2ray打造史上最安全隐匿且高速的内网穿透隧道 首先讲一下需求,其实需求简单无比, 那就是无论身处何时何地,只要有互联网,就可以访问内网资源 ,说得具体点,比如出差在外想访问家里NAS存储的文件,通过直接访问NAS的内网IP(比如192.168.2.10)就可以实现访问,就好像自己坐在家里一样 时代背景 传统的内网穿透方案只能实现某个端口的穿透,想换个端口又需要重新配置,而在本方案中,整个内网资源都是共享的,只需配置一次即可。缺点是需要一个 大带宽公网服务器 做转发(如果流量使用不大也可使用小带宽公网服务器),不做转发也需要一个公网服务器作为 信令服务器 交换各自IP做NAT打洞操作,但TCP打洞难度太大(需要 三次握手 ),一般是UDP打洞,但是UDP又会被 QoS ,而且打洞成功率还需要受NAT类型影响(Full Cone NAT打洞成功率高,且需要NAT两边都是该类型,简而言之该类型NAT会 记住内网主机出去的端口 ,如果NAT不记住,则端口全靠猜),所以话题绕回来了,想要稳定还是需要一个大带宽公网服务器做转发。 该方案简单来讲就是 WireGuard over WebSocket over HTTPS ,也是一种 UDP over TCP 的方案。那为什么这么简单的需求需要这么复杂的实现呢?因为需要大带宽公网服务器做转发,就牵扯出一些列问题,这里简单说一下时代背景: 国内商用带宽贵 :因为国家政策要求民用带宽量大价低,所以运营商普遍用高价商宽补贴家庭带宽。首先,宽带是运营商管的,就是那三家垄断,国内网络基础设施只有三大运营商有资质建设,阿里云、腾讯云、华为云等数据中心都必须要跟运营商买带宽,价格没法谈,偏贵。所以想想为什么百度云要限速了吧,你下载1G的小电影所支持给运营商的带宽费用和百度支付的根本不在一个数量级。其次IP资源受美国控制,国内独立IP价格更贵。而海外的商用带宽却很便宜,因此大带宽公网服务器一般选择海外服务器,既然出国了,那出国流量都会受到婶查的影响。所以这是第二点背景 网X络X婶X茶 :富强、民主、文明、和谐!@#¥#¥%...,这就需要我们满足 隐匿 的需求,隐匿其实是在安全层面之上的,不安全谈何隐匿。 运营商对UDP实施QoS :因为WireGuard使用的是UDP,作者也说过使用UDP的一大原因是因为TCP over TCP性能太糟糕 阅读全文
Tailscale 开源版中文部署指南(支持无限设备数、自定义多网段 、自建中继等高级特性) 目前国家工信部在大力推动三大运营商发展 IPv6,对家用宽带而言,可以使用的 IPv4 公网 IP 会越来越少。有部分地区即使拿到了公网 IPv4 地址,也是个大内网地址,根本不是真正的公网 IP,访问家庭内网的资源将会变得越来越困难。 部分小伙伴可能会选择使用 frp 等针对特定协议和端口的内网穿透方案,但这种方案还是不够酸爽,无法访问家庭内网任意设备的任意端口。更佳的选择还是通过 VPN 来组建大内网。至于该选择哪种 VPN,毫无疑问肯定是 WireGuard,WireGuard 就是 VPN 的未来。 我已经不止一次向大家推荐使用 WireGuard 了,我累了,不想再讲了,你爱 JB 用辣鸡 OpenVPN 之类的就用吧,你开心就好。 WireGuard 相比于传统 VPN 的核心优势是没有 VPN 网关,所有节点之间都可以点对点(P2P)连接,也就是我之前提到的 全互联模式(full mesh) ,效率更高,速度更快,成本更低。 WireGuard 目前最大的痛点就是上层应用的功能不够健全,因为 WireGuard 推崇的是 Unix 的哲学,WireGuard 本身只是一个内核级别的模块,只是一个数据平面,至于上层的更高级的功能(比如秘钥交换机制,UDP 打洞,ACL 等),需要通过用户空间的应用来实现。 所以为了基于 WireGuard 实现更完美的 VPN 工具,现在已经涌现出了很多项目在互相厮杀。笔者前段时间一直在推崇 Netmaker ,它通过可视化界面来配置 WireGuard 的全互联模式,它支持 UDP 打洞、多租户等各种高端功能,几乎适配所有平台,非常强大。然而现实世界是复杂的,无法保证所有的 NAT 都能打洞成功,且 Netmaker 目前还没有 fallback 机制,如果打洞失败,无法 fallback 改成走中继节点。Tailscale 在这一点上比 Netmaker 高明许多,它支持 fallback 机制,可以尽最大努力实现全互联模式,部分节点即使打洞不成功,也能通过中继节点在这个虚拟网络中畅通无阻。 没错,我移情别恋了,从 Netmaker 阵营转向了 Tailscale,是渣男没错了。 Tailscale 是什么 Tailscale 是一种基于 WireGuard 的虚拟组网工具,和 Netmaker 类似, 最大的区 阅读全文
盘点国外主流收款服务 中国的公司以及个人开发者通过互联网把生意做到国外时,不可避免会有支付相关的需求。这篇文章盘点一下国外的知名收款服务商。 因为个人对这方面稍有了解,推友问到相关话题,就顺手总结一下,不是每家服务都注册和体验过,疏漏错误在所难免,欢迎在评论中指正。 1. Paypal 与 信用卡收款服务商 欧美线上服务基本都提供信用卡支付,所以主流信用卡收款服务商都可以选择。 所以如果面向欧美市场,选择 Paypal 与信用卡收款即可。如果面向欧洲南美市场,多数的服务商也都支持当地的主流支付方式。如果面向东南亚及非洲市场,这些地区移动支付线上服务商暂时难以满足需求。 PayPal PayPal 是欧美市场除了信用卡之外最主流的支付方式了,因为起步早名声大,覆盖范围也广,纵然对商家极度不友好,费率较高,但仍然是很多企业个人优先选择的收款服务。 Payoneer 在介绍其他收款服务之前,需要先介绍 Payoneer。 Payoneer 是一个流行的收款服务,能够帮你创建虚拟的美元/欧元/澳元/日元等国际主流货币 实名虚拟银行账户 ,可以提现到本地银行。出于风控考虑,这些虚拟银行只接受公司账户的对公转账,且不同货币的虚拟银行仅支持来自相关国家的入账。 Amazon,Shoppe, Lazada 等平台的中国卖家基本都在使用 Payoneer 进行收款, Google Adsense, Youtuber 广告收入也多用 Payoneer 进行收款。所以对于个人用户,如果收入的外汇来自大公司或者平台,需要提现到中国银行消费,Payoneer 是个不错的选择。 接下来介绍的部分收款平台如果不支持直接提现到中国银行,可以使用 Payoneer 进行中转。 本站的 Google Adsense 广告收入也是通过 Payoneer 的美国虚拟银行进行收款,收入的美元直接转入 香港银行 ,因为不涉及货币转换,所有损耗只有 Payoneer 1%的手续费,银行不收取手续费。 可能提现到中国大陆的银行会涉及汇率损耗。 Stripe 欧美市场风头最劲的线上信用卡收款服务商。经常在国外购买软件服务的朋友应该能注意到,多数软件服务都是用的是 Stripe。 除了收款服务,Stripe 也提供账单服务,甚至还有帮助非美国国籍的人注册美国公司的 ATLAS 服务,仅需要几千人民 阅读全文
服务端高并发分布式架构演进之路 一、概述 本文以淘宝作为例子,介绍从一百个并发到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构设计的原则。 二、基本概念 在介绍架构之前,为了避免部分读者对架构设计中的一些概念不了解,下面对几个最基础的概念进行介绍: 分布式 系统中的多个模块在不同服务器上部署,即可称为分布式系统,如Tomcat和数据库分别部署在不同的服务器上,或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时,其他节点能够接替它继续提供服务,则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务,这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上,共同组成一个整体提供集中配置服务。在常见的集群中,客户端往往能够连接任意一个节点获得服务,并且当集群中一个节点掉线时,其他节点往往能够自动的接替它继续提供服务,这时候说明集群具有高可用性 负载均衡 请求发送到系统时,通过某些方式把请求均匀分发到多个节点上,使系统中每个节点能够均匀的处理请求负载,则可认为系统是负载均衡的 正向代理和反向代理 简单来说,正向代理是代理服务器代替系统内部来访问外部网络的过程,反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。 三、架构演进 1、单体架构 以淘宝作为例子。在网站最初时,应用数量与用户数都较少,可以把Tomcat和数据库部署在同一台服务器上。浏览器往www.taobao.com发起请求时,首先经过DNS服务器(域名系统)把域名转换为实际IP地址10.102.4.1,浏览器转而访问该IP对应的Tomcat(应用服务器)。 随着用户数的增长,Tomcat和数据库之间竞争资源,单机性能不足以支撑业务 2、第一次演进:Tomcat与数据库分离(在不同服务器上部署) Tomcat和数据库分别独占服务器资源,显著提高两者各自性能。 随着用户数的增长,并发读写数据库成为瓶颈 3、第二次演进:引入本地缓存和分布式缓存 在Tomcat同服务器上或同JVM中增 阅读全文
玩客云编译 ArmBian 系统刷机 本文将介绍如何从零到一编译 Armbian 系统,适配这台设备的代码来源,并对玩客云小设备进行刷机。为之后的折腾做一个前置准备。 写在前面 最近有几个有趣的小想法想实践一下,希望使用低功耗、低成本的硬件跑一些持续性的独立的服务。最初的想法是入手一个树莓派得了,开发板尺寸小巧,资源丰富。然而搜索价格的时候发现最新版的树莓派,如果搭配上一些常用配件,加一个定制外壳,算下来成本几乎能和我之前的 NUC 裸机价格一较高下。 那么,有没有性价比更高的方案呢? 为什么选择搭载 Amlogic S805 的玩客云 于是,目光就锁定到了同为 ARM 架构的廉价 SoC 上,前一阵群里有同学推荐过“玩客云”,搜索了一番,发现 虽然芯片其实是几年前的款,但是性能并不差,拥有一个千兆网口,并且机器自带一个金属外壳 。因为我 不需要使用 GPIO 接口 ,所以相比较树莓派而言,一套 50 元左右的小主机,性价比高非常多。 而且设备因为使用了廉价的 ARM 芯片,不光运行过程中的温度不算高,日常功耗也非常低。 玩客云采用的芯片方案是 Amlogic S805,和著名的 Hard Kernel 几年前推出过的开发板“ODROID-C1+”几乎完全一致。这个板子性能基本是树莓派3B的 两倍 ,前文中提到的玩客云的成本大概是目前二手树莓派3的1/5~1/6。 如果追求绝对的性能,在价格差不多的情况下,可以考虑入手搭载 S905 芯片的“电视盒子”,性能和最新的树莓派4相比也 不落下风 ,甚至在一些环节中性能高出不少。不过缺点嘛也是有的,目前这类机器受限于成本问题,很少有利于散热的金属外壳;因为性能更高,发热量也会更大。不过即便如此,综合成本也只是树莓派4的十几分之一。 系统选择及“源码溯源“ 相对于硬件而言,软件系统也非常重要。 拥抱 Linux 让我们的设备有了无穷的可能性,树莓派有 Raspberry Pi OS(Raspbian),玩客云则因为搭载了和 Hard Kernel 之前产品一致的 Soc ,所以可以使用 ArmBian。 在正式介绍如何为玩客云更换系统,以及编译一份干净的新版镜像之前,我要介绍一下这个系统的由来,因为这里有太多前人的无私贡献。 Armbian 官方代码 2014年末, Armbian 立项 ,或许是暴风雨来临之前的沉寂, 阅读全文
重新学习并解锁emby4.6.7,4.7.2版本 版本历史与建议 2022.6.4: 更新4.7.2版本. 更新docker镜像,更新双端文件,更新群晖一键脚本. 更新4.7.*版本群晖脚本的sb小bug.相比于4.7.1, emby官方 1.在媒体库选项中增加剧集介绍检测功能. 2.增加用户配置选项,可以跳片头. 3.修复从文件名中解析集数时的集数倒退问题. 4.修复家庭录像的文件名在文件名的最后一个点之后被截断的问题. 5.修复删除下载任务时重新下载的问题. 6.如果启用字幕选择,记住即使用户字幕模式被设置为默认为无. 从这个版本开始不再做所谓的美化包, 不再更新ubuntu脚本, 由于更新一次全端耗时太长,除非有重大更新,否则以后只能做到随缘更新了. 请各位手动关掉自动更新, 位置在 设置 - 自动更新 - 允许服务器自动重启以应用更新. 取消勾选然后点击保存. 2022.5.26: 更新4.7.1版本. 相比于4.7.0.60, 官方 1.修复了windows上不必要的ffmpeg依赖问题, 2.提升了内嵌中文字幕和音轨的体验, 3.修复了一堆错乱抽风的按钮(4.7.0.60版本所有人都会遇到), 4.歌词开始显示时间轴. 已经安装了4.7.0.60的同学可以考虑升级。 2022.5.20: 修复群辉一键脚本,更新ubuntu一键脚本的sb小bug,更新群晖命令。修复受到影响的docker镜像。 2022.5.19: 更新4.7.0.60正式版,更新群辉一键脚本,更新ubuntu一键脚本,更新docker,更新美化包。更新unraid模板。 2022.5.9: 更新群晖一键脚本到v1.2,解决运行脚本后套件无法启动的问题。更新4.7.38双平台测试版。 2022.4.8: 更新unraid模板, 默认加上了代理的字段, 需要自己设置好http和https代理地址。不需要的话请删掉这两个字段 前言 以前,emby开心用户靠neko.re老哥的第三方激活服务器和加速套件得以存活,今天,发现老哥的服务器已经全关了,意料之中,早晚的事,幸亏能用的时候就备份了老哥原来的返回格式。 1 2 3 4 5 6 7 8 //https://crackemby.mb6.top/admin/service/registration/validateDevice.php? {"cacheExpirationDays&qu 阅读全文
Redis rdb文件手动合并(单库,只有db0) 线上服务使用的阿里云的集群版本redis服务,数据量1千万,rdb文件4GB。 线下测试环境只有单节点redis,需要导入线上全量数据。 8个rdb文件,每个500MB。 RDB格式如下: 头5个字节是字符REDIS。 之后4个字节代表版本号,阿里的版本分别是 00 00 00 06 之后2个字节 FE 00,FE是标识 00是数据库,还好我们只有一个库。 最后的结尾9个字节 。 FF 加上8个字节的CRC64校验码(实在没空弄,后来偷了一个懒) 。 一、生成对应的文件 #文件1 大小566346503,截取尾部的9个字节 dd bs=1 if=src_1.rdb of=1.rdb count=566346494 #文件2 大小570214520,跳过头部的11个字节,再截取尾部的9个字节 #dd bs=1 if=src_2.rdb of=2.rdb skip=11 count=570214400 ... #文件8 大小569253061,跳过头部的11个字节,再截取尾部的8个字节,保留FF。 dd bs=1 if=src_8.rdb of=8.rdb skip=11 count=569253042 二、合并文件 cat 1.rdb > dump.rdb cat 2.rdb >> dump.rdb ... cat 8.rdb >> dump.rdb 备份文件合并完毕。 三、检查备份文件 redis-check-rdb dump.rdb 应该会提示没有crc校验。 四、修改配置文件 因为数据库备份文件里面不包含crc64的校验码,配置文件中关闭选项。 rdbchecksum no 数据恢复到此结束,此方法只适合用于临时恢复和导出数据,数据完整性不敢保证。 参考的文章 https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-RDB-Dump-File-Format 来源:https://www.jianshu.com/p/097c0b01ea69 阅读全文
当中台遇上 领域驱动设计DDD,我们该如何设计微服务? 借用当下最流行的段子做个开场白。 “设计原则千万条,高内聚低耦合第一条,架构设计不规范,开发运维两行泪!”。 在分布式架构下,单体应用被拆分为多个微服务,为了保证微服务的单一职责和合理拆分,“高内聚、松耦合”是最宝贵的设计原则。 通俗点讲,高内聚就是把相关的行为聚集在一起,把不相关的行为放在别处,如果你要修改某个服务的行为,最好只在一处修改。如果做到了服务之间的松耦合,那么修改一个服务就不需要修改另一服务,一个松耦合的服务应该尽可能少的知道与之协作的那些服务的信息。 从集中式架构向分布式架构的技术转型,正如从盖砖瓦房向盖高楼大厦转变一样,必然要有组织、文化、理念和设计方法的同步更新,其中最不可或缺的能力就是架构设计能力。 如何做到“高内聚、低耦合”?我们先来学习几种典型的微服务架构模型。 微服务架构模型 整洁架构(又名洋葱架构) 在整洁架构里,同心圆代表应用软件的不同部分,从里到外依次是领域模型、领域服务、应用服务、最外围是容易变化的内容,如界面和基础设施(如数据存储等)。整洁架构是以领域模型为中心,不是以数据为中心。 整洁架构 整洁架构最主要原则是依赖原则,它定义了各层的依赖关系,越往里,依赖越低,代码级别越高。外圆代码依赖只能指向内圆,内圆不知道外圆的任何事情。一般来说,外圆的声明(包括方法、类、变量)不能被内圆引用。同样的,外圆使用的数据格式也不能被内圆使用。 整洁架构各层主要职能如下: Entities:实现领域内核心业务逻辑,它封装了企业级的业务规则。一个 Entity 可以是一个带方法的对象,也可以是一个数据结构和方法集合。 Use Cases:实现与用户操作相关的服务组合与编排,它包含了应用特有的业务规则,封装和实现了系统的所有用例。 Interface Adapters:它把适用于 Use Cases 和 entities 的数据转换为适用于外部服务的格式,或把外部的数据格式转换为适用于 Use Casess 和 entities 的格式。 Frameworks and Drivers:这是实现所有前端业务细节的地方:UI,Tools,Frameworks 等。 六边形架构(又名端口适配器架构) 追溯微服务架构的渊源,一般会涉及到六边形架构。六边形架构的核心理念是:应用是通过端口与外部进行交互的,这也是微服务架构下 API 网关盛行的主要原因。 阅读全文