安卓逆向——如何修改APP包名实现应用分身

安卓逆向——如何修改APP包名实现应用分身,第1张

齐天大圣孙悟空是家喻户晓的神话传说名人,大家都知道他有一个很强大的技能——拿出一根猴毛“biu”一吹实现分身。

那么我们程序猿也和咱们的齐天大圣是同类(开个玩笑),程序猿怎么实现分身呢?我们拔一根头发吹肯定是不好使的……那就是通过修改APP的包名来实现应用分身。也就是说在同一个设备上可以打开两个或多个相同的APP。

一.如何修改APK的包名

那么如何修改apk的包名呢?我们以“土豆视频为例”来进行一个分析。首先,找到“工程管理器”,打开工程管理器进入界面,点开土豆视频的下行文件数据

里面有“manifest”这样一个标签,找到这个标签里面的一个“package”属性,这个值就是我们要找到应用程序的包名

第二步,把“package”属性改为“hou”或者“123”等等都可。

这个值我们可以通过删减几个字母或者是任意添加几个字母或数字来进行修改,切记注意只能使用添加或删减数字和字母,不可以用汉字!

建议通过“添加数字或字母实现”,删除容易把握不准,当然删除以后一定要记得保存。 然后点击“回编译”按钮,进行回编译过程

二.如何修改内容提供者

启动模拟器,进行应用安装,然后把我们“回编译”好的拖到模拟器里面

发现安装失败,提示“存在同名的内容提供者”。 错误的原因由于我们只修改了包名,没有修改内容提供者。 那么如何修改“内容提供者”?

搜索结束后显示我们 需要修改的是“provider”里面有个“android;anthorities”的值

修改的方法同修改“package”值的属性是一样的,可以添加或删减字母或者是数字(绝对不能是汉字)

将搜索到的结果进行逐一全部修改,修改完成后千万不能忘记保存

完成之后找到其所在的目录进行安装,方法同样,直接拖进模拟器里面即可

※这里补充一点:有的apk由于没有内容提供者,就只需要一步到位——修改包名就可以直接实现应用分身了。

三.程序无法运行安装及对应解决方案

那么在什么情况下会导致程序无法运行以及安装,它们对应的解决方案是什么呢?

Q 1 ·   只修改apk的包名会引发内容提供者冲突

解决方案:

修改配置文件中所有内容提供者的标签“provider”里面“android:authorities”属性的值

Q 2· 应用程序分身的签名信息不同导致无法运行

解决方案:

使用相同的签名工具对所有分身进行统一的签名

Q 3· 有些apk在内部使用的包名只修改包名会导致程序崩溃

解决方案:

全局搜索应用程序的包名查看搜索结果,如果是字符串就进行一个替换,将原有的字符串修改为修改后的包名否则不进行替换

这就是如何修改apk的包名实现应用程序分身的具体方法了,在实际 *** 作中可能会遇到更多的小细节问题,我们要具体问题具体分析。总之多动手多思考多实 *** ,安卓逆向没有什么太难的。当然分享的相关经验,如果有哪处不妥也欢迎在评论区回复讨论或者私聊交流哈。

首先,逆向分析是一门技术,也是一门艺术。

其次,安卓逆向同样可细分为应用层APK逆向、安卓设备框架、内核驱动等逆向、基于安卓的硬件产品逆向等。此处假定楼主说的是第一种逆向。

应用层的逆向分析根据需求的不同,又可细分成APK流程逆向与功能逆向。

流程逆向通常是指简单的对APK运行流程进行分析,此类分析通常可以使用将APK置于沙盒环境中运行捕捉并查看运行结果。这种逆向需求通常不是很多,典型的工种有杀软厂商的病毒分析工程师。

功能逆向相比流程逆向则困难得多。但需求比较普遍。实际逆向分析过程中对功能实现的理解,在很大程度上取决于逆向人员相关的软件开发知识。比如,分析Android程序的JAVA代码就需要掌握基本的Android软件开发的知识。分析so库的代码就需要了解C/C++相关的so库开发的知识。除了基本开发相关的能力外,逆向分析人员还需要具备以下知识:

ARM/X86/MIPS汇编语言-分析so库时可能需要阅读大量的反汇编代码。

常见逆向分析工具的使用-JDGUI/IDA PRO/APKTOOL/JEB/DEX2JAR

常用的安卓程序调试与反调试手段-调试器检测与反检测/脱壳/反混淆

常用的加密与解密算法-好的逆向分析人员需要有快速识别常见加密解密算法的能力

最后,就是多动手,多动手练习是掌握逆向分析技术最好的方法。

前言:网上关于微信逆向的文章很多,而关于抖音的就相对较少,主要原因是在逆向Hopper分析的时候,里面大多是函数调用地址,不知道具体的方法直线,笔者研究了几天之后,有些小心得与各位分享.

逆向需求:实现评论功能,模拟不同的用户评论.

开发环境:脱过壳的抖音IPA(Aweme.app), Xcode(安装MonkeyDev), Hopper(解析执行文件), 导出抖音所有头文件

1>运行MonkeyDev,查看抖音的层级结构,先找到评论的控制器 AWECommentListViewController

搜索头文件,看看里面有什么有用的属性,replyComment:这个可能是回复评论时候生成的模型,model:,listManager:可能是用来处理评论逻辑的,- (_Bool)userTappedSendWithContent:(id)arg1 inputView:(id)arg2:点击发送评论,这个应该是关键方法,随便发一条评论,在该方法下一个断点,进行验证

确实来到了这个方法,而且这个方法是由  AWECommentListInputView  这个View来调起的,猜想这个View应该是文本输入框的View,而且评论控制器实现了这个View的代理方法- (_Bool)commentInputViewShouldReturn:(id)arg1,代理方法里面调用了评论控制器的- (_Bool)userTappedSendWithContent:(id)arg1 inputView:(id)arg2方法, 所以理论上我们可以手动调用这个方法,能实现发送评论,

2>在评论控制器添加一个按钮,按钮的点击事件设为- (_Bool)userTappedSendWithContent:(id)arg1 inputView:(id)arg2 这个方法,看是否能够评论成功,

验证评论可以发送成功,

3>继续跟进方法调用,查看是哪个类来发送的评论请求,我们需要了解必须上送什么参数,以及请求路径. 打开Hopper 寻找突破口,搜索AWECommentListViewController userTappedSendWithContent,找到三个可疑的方法,点进去跟进

实现这三个方法,分别打入断点,运行Xcode,当发送一条评论时,会进到-sendCommentContent 这个方法,进到这个方法里面,看到一条有用信息

点进这个方法,发现一个熟悉的味道 AWECommentListManager,方法是属于它的,还记不记得在文章开始的那个listManager,就是它,惊不惊喜,还原成控制器的调用就是 [self.listManager commentWithContent: replyId: replySubCommentID: replySubCommentAuthorID: extraInfo: referString: completion:], 顺藤摸瓜,继续往下走,最终跟进到+(void)commentAwemeItemWithID:(void *)arg2 content:(void *)arg3 replyCommentID:(void *)arg4 replySubCommentID:(void *)arg5 extraInfo:(void *)arg6 sticker:(void *)arg7 referString:(void *)arg8 completion:(void *)arg9 这个方法之后,就无法再跟进了于是转换思路,看看listManager里面会不会调用其他方法,我的做法是将里面的所有方法都打上断点,来到了_cmd 对应的这个方法,看到了传入的那个字典,aweme_id 是评论的id,就是你当前刷的这条抖音,text是我评论的内容,"https://aweme.snssdk.com/aweme/v1/comment/publish/"是发送端口路径.

在调试过程中,我发现评论完的请求发送完成之后,又会发一个交易,通过

看到了一个关键词heartbeat,当我定在这个断点,会发现评论会失败,这应该是抖音的某种机制,这个心跳包如果不对,那么你的评论就会失效.

4>思路:(1).发送评论肯定得知道用户的信息,比如userid,昵称,头像路径,这样才能区分是谁发的评论,找到这个"https://webcast.amemv.com/webcast/room/live_room_id/?version_code=9.2.0&pass-region=0&pass-route=0&js_sdk_version=1.43.0.1&webcast_sdk_version=1330&app_name=aweme&vid=019C3DD5-08D3-49B6-AF5B-939154B6B148&app_version=9.2.0&language=zh-Hans-US&device_id=40613784883&channel=pp&mcc_mnc=46011&aid=1128&effect_sdk_version=5.8.0&screen_width=414&openudid=02a6db71a7ae780f226b95032b116da6852f13e8&webcast_language=zh&os_api=18&ac=WIFI&os_version=12.4.6&webcast_locale=zh-Hans_CN&device_platform=iphone&build_number=92013&iid=110910203440&device_type=iPhone%206%20Plus&idfa=25D32F6D-CBC3-42E9-9A7C-2D72277497D4",   它是一个POST请求 请求参数 就是aweme_id=6812025407865425166&channel_id=0&text=%E4%BD%A0%E8%AF%B4%E7%9A%84%E5%AF%B9,这三个,接下来就得看请求头里面有没有我们需要的信息,只有iid=110910203440这个参数比较可疑,

5>查看一下评论的模型信息,点进个人主页,查看userId的格式是怎么样的---待续...


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/bake/11525351.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-16
下一篇2023-05-16

发表评论

登录后才能评论

评论列表(0条)

    保存