iOS 多开检测,反多开检测,反反多开检测


#4

同样。现在是个人都知道该hook dladdr。 但是99%的人都不知道要hook dladdr下实际调用的那个函数。所以如果你直接使用下层的那个函数而不是dladdr的话安全性又会高一些。

不过嘛这种对抗没啥意思,Userland也就那点东西


#5

这个叫Binary Plist,可以理解为序列化后的XML Plist. 傻逼微信黑产们把这玩意儿叫62数据。因为bplist开头对应的16进制是0x62XXXXXXXX

+[NSDictionary dictionaryWithContentsOfFile:]


#6

果然还是防不胜防啊


#7

感谢。学习了,文章对我这种小白太有价值了。
读取文件的方式太多,mmap,等等。。。


#8

感谢。学习了,文章对我这种小白太有价值了。
读取文件的方式太多,mmap,等等。。。


#9

如果把加密的str 用ida什么的改了肿么办


#10

用syscall来读取embedded.mobileprovision,检测开发者证书有没有被替换?

检查mach-o文件的有没有被修改…

好像记得以前讨论过,可以静态patch… 用张总黑科技,也不能防静态patch吧


#11

私有版可以。参见hikari那贴最下面的demo http://bbs.iosre.com/t/llvm-hikari/10720/141?u=zhang 就是PatchMe那个。反调试反Patch+混淆

类似。具体的我在群里提过一嘴


#12

玩的溜,膜…


#13

请问syscall如何读取embedded 来校验app签名是否被替换?


#14

他的意思就是普通的文件读取。不过为了逃避hook改写成了syscall而已


#16
  1. 因为类簇的关系,文中替换NSDictionary的objectForKey方法应该是不起作用的。若是MUHook做了兼容,那就没有这个问题。
  2. 若这么替换的话,那NSMutableDictionary和CFDictionaryRef是否也考虑替换下。
  3. 有没有更好的替代方法,比如判断是谁打开Info.plist,如果可行可以避开替换方法太多的问题。

#17

666, 小白学习了


#18

666,小白学习了


#19

没有这种需求 仅做了下尝试 第二天就提示非官方客户端了


#20

我当时听说62的时候也懵逼了一下,后来一想,bin开头不是0x62吗,无语……


#21

经测试iOS10/iOS11中所有对NSDictionary的访问都会调用-[__NSCFDictionary objectForKey:]
测试内容包括:

  1. [dict objectForKey:]
  2. [dict valueForKey:]
  3. dict[@“key”]
  4. NSBundle.mainBundle.bundleIdentifier
  5. [[NSBundle mainBundle] objectForInfoDictionaryKey:@“CFBundleIdentifier”];
  6. [NSBundle mainBundle].infoDictionary[@“CFBundleIdentifier”];
  7. [dict objectForKeyedSubscript:]

但是有个坑,hook的方法要这样写:
-(id)objectForKey:(void *)aKey

否则iOS11上容易crash,其原因是aKey有可能是0x1!根据0x1这个地址读取内容肯定会crash。


#22

我比较赞成用这个办法


#23

话说楼主的微信多开方法,能够持续运行超过2周嘛?
目前很少见到第三方的微信分身,能够存活超过2周的,一般一周左右微信就会自动弹出警告了,不知道微信是怎么检测的。。。


#24

微信有一千种方法检测你的插件,仅仅只是干掉多开检测是远远不够的。最主要的还是看人品。。。

你还是转发杨超越吧。