由一个扯淡需求引出的关于Charles Proxy的破解

UPDATE[2013.01.04]: Keygen for Charles Proxy: Login to read more

其实是想研究iTunes的协议然后写个限免自动下载工具的,之前的技术调研没看到网上有现成的实现,所以只能靠自己研究。

Wireshark抓到Client Hello的包能看到两个域,se.itunes.apple.com和p46-buy.itunes.apple.com,p46这个之前试了下,p后边的数字可以从2到50,不过只是半折法试的不保证准确。

知道域名之后,下一步就应该是搭一个https proxy然后将客户端的请求重定向到proxy上。我选择了本地的nginx+修改hosts,然后这逻辑很2的死循环了。后来换用虚拟机改hosts访问宿主机nginx,结果access log里是400的错误。curl直接访问 se.itunes.apple.comde https,得到的响应是503。试图看nginx代码,加个完整请求的日志,然后周六晚上看着看着就睡着了 = =

更早的,为了分析某iphone app的请求,php写了个代理工具,增加了几个数据处理的handler,直接nginx把所有请求fastcgi传到这个php上来,curl转发请求。这次连请求都进不去,自然也用不上了。

昨晚跟@透明de面具 讨论了实现方案,才知道有个叫 Charles Proxy 的东西,找到了Windows版,下载页面上提示需要64位JRE,于是断定核心使用java写的,准备下载下来反编译然后keygen it。

下载,安装,查看安装目录,找到jar包,用 JD-GUI 打开看,代码还原度较高,随便开的几个class文件都没乱码。释放所有源码,grep了几个关键字,找到了Licence的文件,拿过来,反编译,扔到vps上gcj编译,结果各种报错。找 @吉普 请教后找了Eclipse来Quick fix,不过很多错误全都是cast的,long/int和int/long,不分析一下数据根本没法搞。折腾了几个暴力fix,重新编译出来的几个key不可用,估计是算法在fix的时候被毁了。后来试图直接null几个public的方法,重新编译打包运行,程序起不来。

Login to read more
# EOF

由一个扯淡需求引出的关于Charles Proxy的破解 by @sskaje: https://sskaje.me/2012/02/crack-charles-proxy/

Incoming search terms: