@blless 联网确实是一种思路

@Arnie97 这思路不错，实际操作的话，用 readelf 之类的工具定位一下各个区的位置，然后计算的时候跳过去？

@ipoh @VYSE @blahgeek
谢谢几位，其实我本来想 so 库通过校验 hash 是否一致来判定自己是否被篡改，不过这个思路好像逗逼了，因为要提前编译好 so，然后会得到一个 hash 值，代码运行时找到 so 路径然后判断 hash 值是否一致，但是一旦把这个 hash 值编译进 so 库，库被改变，其 hash 也会变。。。。

其实是之前参考 stackoverflow 上的一个帖子: https://stackoverflow.com/questions/15318795/android-shared-library-integrity-protection

from Freedom_Ben:
'The best way to protect from modification is to take a SHA-2 of the .so after you compile it, and rehash each time at runtime, matching it against the known value.'

不过他没详细说怎么个操作

@cs8425 学到了新知，十分感谢！

@cs8425。。。如果能直接对内存数据 hash 会更安全，那么 so 文件会原封不动映射到内存中吗（ so 文件的 hash 和其被加载到内存中的 hash 一致）？

可以用这个 getApplicationInfo().nativeLibraryDir，感谢 @enenaaa

@enenaaa 感谢，那就是直接去 /data/data/packagename/..下面找吗？有函数可以动态获取路径吗？

@zhouquanbest 关于动态函数生成 key+签名验证，可以详细说说做法吗？之前看过 Jake 大神的文章，square 基本不做混淆啥的，基本上靠端到端之间的可靠性

可惜的是欧洲人没进来，把毛熊放进来了

@Karblue 安全行业确实赚钱，刚查了下几个大厂加固都是 8w/year，360 倒是免费，不过有点担心他们会不会搞事情。目前看来可能比较好实现的就是 OLLVM 混淆+ndk 代码验证签名防二次打包，话说验证签名有多靠谱呢？有什么手段可以攻破?

@zyu0090 好像 3 小时一波草

割草可以改系统时间

@s82kd92l 说到 service 想起另一个问题，系统内存紧张的时候会杀掉 service，此时是整个进程一起杀还是单独杀 service 呢，如果是单独杀，如果 service 里面之前启用了一个 thread，那么被杀掉时这个 thread 发生什么了？

谢谢两位
@honeycomb
@s82kd92l

多问一句，假设做一个简单的单进程音乐播放 app，那么把播放逻辑做在 service 中，然后常驻一个通知，这样应该就不怕 activity 在后台被回收了，另外开启 activity 的时候去 bind 播放 service 以便获得各类播放状态显示出来（当然也可以考虑走广播机制），这个思路没什么问题吧？

@lancerly 如果用 service 在通知栏里驻留一个通知，然后 activity 进后台，此时 activity 就一直常驻内存了吧

想多了，毕竟 Dang 指挥枪

东北老铁劝你如果家里没特殊情况，攒个房租钱去一线找 1-2 个月，先熬个两三年再说。东北大环境越来越堪忧，根据你的描述也可以看出来工作小环境上的问题：信息流通慢，管理落后，薪资水平低。

@HongJay 公司推全栈的目的是节省成本让开发两边都做，还是说主要提高移动端对后端理解

深圳和新加坡是什么关系？深圳有机会调新加坡吗？