dex

我们最近一直在思考DeFi领域如何发展，以及如何跟随更广泛的科技行业趋势。 如果你读过Ben Thompson的Stratechery博客，他的聚合理论(aggregation theory)定义了平台公司和 "聚合器 “(aggregators)之间的区别。 有一些平台公司，比如Shopify或Substack，它们提供一些API或技术，让第三方与终端用户连接。Substack连接作家和读者，然后从收入中抽取10%的分成。Shopify连接商家和买家，然后向商家收取月订阅费来提供其技术，同时提供可选的增值服务(支付、信贷额度等)。 但最终是由作者或商家自己去获取用户和进行分销。 聚合器是像Google或Facebook这样的公司，在第三方和用户之间搭建中介关系。这样说有点过分简单，但Facebook和谷歌拥有大量的用户信息，并利用这些信息让公司在他们那里花大量的广告钱。在很多情况下，媒体公司或旅游公司并不拥有客户关系，他们必须通过向谷歌和Facebook支付费用来进行发布。 如果你计划去东京旅行，你可能会在谷歌开始搜索，而不是直接在Expedia上搜索。因此，Expedia在2019年花费了60.3亿美元的 "销售和营销 "费用，主要花在了谷歌广告上。 在CeFi加密货币领域，币安可能是最类似于Facebook或Google的 “聚合器”。币安拥有超过15,000

在2020年快要过半的时候，DeFi概念相关的币种直接引爆了行情。DEX (去中心化交易所)——作为DeFi项目最容易捕获价值的细分赛道之一，自然也是备受瞩目。 细数一下,DEX的项目还真不少：Bancor、Cruve、Balancer、LRC…但是！如果你要问谁是DEX里最靓的仔，那必然是 引领AMM潮流、“Shit Coin大赌场”、 DEX中崛起的独角兽、——Uniswap。 2020超新星Uniswap 今天的文章将从“引领AMM潮流”、“Shit Coin大赌场”、“DEX中崛起的独角兽”，这三个角度来展开介绍Uniswap，聊聊Uniswap崛起的全过程，还原一个牛市FOMO情绪下的区块链大“赌场”的真面貌。 引领AMM潮流 Uniswap的诞生充满了偶然与趣味性，据说Uniswap 的创始人Hayden Adams 的灵感来自于V神在reddit上发的一个帖子。灵感有了，Hayden Adams老兄便开始着手学习Solidity编程。是的，他一开始只是抱着学习Solidity编程试试看的想法，然而这个用来练手的项目很快就得到了认可，获得了一笔来自以太坊的资助奖金，这下启动资金的问题也解决了。 2018年11月，Uniswap正式上线，其定位是一个基于以太坊的去中心化交易所（DEX）。DEX虽然在用户资产安全性方面有所提升，但是受限于其资金规模

太难了 太难了 先放出来俩re题花了大量时间没搞出来 如下是俩道简单的安卓题 Reverse-java 解压题目得到一个java.apk，要求输入正确的flag。 主要函数： 坑：替换了密钥内容 解密代码： misc –vulcrack 360加固，先脱壳，用fdex2即可： 拿到dex后修补一下文件头： 反编译看源码： 抠出来用就可以了： 来源： oschina 链接： https://my.oschina.net/u/4323755/blog/4288783

一、前 言 Android Apk加固的发展已经有一段时间了，相对来说本篇博客要记录的Android加壳的实现思路是4年的东西了，已经被老鸟玩烂了，Android加固的安全厂商也不会采用这么粗犷的方式来进行Android Apk的加固处理。早期Android加固聚焦的两个点主要是在DexClassLoader和Android类加载这两条代码执行流程上去下功夫，后期Android加固会在Android动态库so的加固处理和Android应用程序的自定义smali字节码虚拟机上下功夫来实现与逆向分析的对抗。本篇博客记录主要学习参考的博文是 Android APK加壳技术方案【1】 、 Android APK加壳技术方案【2】 、 APK加壳【1】初步方案实现详解 这3篇。Android加固的关注点主要集中在两个方面：dex文件的隐藏和dex文件的加载运行，针对Android应用dex文件的加固也有两种方案即，dex文件的整体加固方案、dex文件的部分加固方案。本篇博客提到的Android Apk的加固属于dex整理加固的方案。 源程序 ：需要被加壳保护的Android应用程序的代码，可以是Android应用的apk也可以是Android应用的dex文件和so库文件。 加密工具

受影响手机包括魅族，中国移动等国产手机。 5月12日开始有人在百度知道提问cmtwg，5月13日mx吧也有人在发贴。 我接到有问题的手机时间更早，大约就是五一之后。 出现问题的几个牌子的国产手机，似乎存在漏洞，对方可以利用4G网络，自动安插它们的软件到你的设备上。 com.wagd.qhsz的dump com.wg.cmtwg的dump 自动安装时间点的日志 1 25 ** 26 ** I ActivityManager: Start proc 20763 :com.android.defcontainer/u0a20 for service com.android.defcontainer/ .DefaultContainerService 2 20763 20780 D DefContainer: Copying /storage/emulated/ 0 /.tm/882a3f6d5466518c3fb5290ada5f2a89 to base .apk 3 25 ** 26 ** I PackageManager.DexOptimizer: Running dexopt (dex2oat) on: /data/app/vmdl533505310.tmp/ base .apk pkg=com.wg.cmtwg isa=arm64 vmSafeMode= false

本文博客地址: https://blog.csdn.net/QQ1084283172/article/details/80954759 在进行Android程序的逆向分析的时候，经常需要Android程序的静态分析和动态调试的结合，尤其是对一些加固后的Android类方法被调用的确认，需要Hook java类方法打印java类方法的调用堆栈。有幸在网上看到了这篇文章《XPosed暴力列举Package下所有的方法调用》，按照作者的思路和代码进行了验证和尝试，发现效果并不明显而且不好用，对多dex的Android应用支持不好，因此在此基础上调整了一下思路，简单的写了份xposed Hook代码，如下： package com.xposed.enumeratorClassHook; import java.lang.reflect.Field; import java.lang.reflect.Method; import java.lang.reflect.Modifier; import de.robv.android.xposed.IXposedHookLoadPackage; import de.robv.android.xposed.XC_MethodHook; import de.robv.android.xposed.XC_MethodHook

本文博客地址： https://blog.csdn.net/QQ1084283172/article/details/80982869 Android系统在启动时安装应用程序的过程，这些应用程序安装好之后，还需要有一个Home应用程序来负责把它们在桌面上展示出来，在Android系统中，这个默认的Home应用程序就是Launcher了。Android系统的Home应用程序Launcher是由ActivityManagerService启动的，而ActivityManagerService和PackageManagerService一样，都是在开机时由SystemServer组件启动的，SystemServer组件首先是启动PackageManagerServic，由它来负责安装系统的应用程序，系统中的应用程序安装好了以后，SystemServer组件接下来就要通过ActivityManagerService来启动Home应用程序Launcher了，Launcher在启动的时候便会通过PackageManagerServic把系统中已经安装好的应用程序以快捷图标的形式展示在桌面上，这样用户就可以使用这些应用程序了。 上面这段内容，摘自老罗博客《 Android系统默认Home应用程序（Launcher）的启动过程源代码分析 》

本文博客地址： https://blog.csdn.net/QQ1084283172/article/details/80956614 作者dstmath在看雪论坛公布一个Android的art模式下基于frida框架的脱壳脚本，详情见文章《 基于frida的脱壳工具 》的介绍，作者dstmath公布的frida脚本代码见github地址: https://github.com/dstmath/frida-unpack ,脱壳原理比较简单，和我前面的博客《 ART模式下基于Xposed Hook开发脱壳工具 》中提到的作者的脱壳的思路是一致，这个脱壳思路也比较常见，在看雪论坛有多位楼主提到了这个基于Android的art模式下的OpenMemory拦截进行内存dump的脱壳思路，其实很多Xposed框架的Hook思路都可以移植到基于Frida框架的Hook上，顺便提一句，作者dstmath的简书博客写的不错。 具体参考的其他的文章： 《 乐固libshella 2.10.1分析笔记 》作者的帖子写的很不错。 《 Android第二代加固（support 4.4-8.1） 》 《 修改源码dump某加固保的dex 》 《 legu 2.10.7.1 脱壳简明过程 》 下面简要的说下，作者dstmath提供的frida脱壳脚本需要注意的几个点： 由于随着Android系统版本的升级

某安全公司移动病毒分析报告的面试题目，该病毒样本的代码量比较大，最大的分析障碍是该病毒样本的类名称和类方法名称以及类成员变量的名称被混淆为无法辨认的特殊字符，每个被分析的类中所有的字符串都被加密处理了并且每个类的加密算法还不是一样的，人肉还原出被加密的字符串是很不现实的，该样本大约有100多个类，需要处理的加密字符串的解密高达几千个之多，有兴趣和能拿到样本的同学可以挑战一下自己，暂不提供样本。经过对该木马病毒进行深入和全面的分析，发现该木马病毒还是很厉害的，远控的功能比较多，盗取用户手机上的用户信息，通信app的数据信息也比较多，有些远程的功能对于用户的手机来说是致命的伤害。 本文博客地址: https://blog.csdn.net/QQ1084283172/article/details/81380553 Android木马病毒com.schemedroid的混淆对抗手段： 1.将代码中的类名称、类方法名称、类属性名称混淆为人工难以辨认的特殊字符串。 2.代码中的字符串全部被加密处理，每个类中解密字符串的函数都不一样，需要解密的字符串的量大。 字符串解密函数的代码示例： Android木马病毒com.schemedroid的分析报告 样本基本信息： apk包名：com.schemedroid 文件Md5: CFBCEE2B12DD93A6109AC06C10C34C86 1

本文博客地址： http://blog.csdn.net/qq1084283172/article/details/78092365 Dalvik模式下的Android加固技术已经很成熟了，Dalvik虚拟机模式下的Android加固技术也在不断的发展和加强，鉴于Art虚拟机比Dalvik虚拟机的设计更复杂，Art虚拟机模式下兼容性更严格，一些Dalvik虚拟机模式下的Android加固技术并不能马上移植到Art模式下以及鉴于Art虚拟机模式下的设计复杂和兼容性考虑，暂时相对来说，Art模式下的Android加固并没有Dalvik虚拟机模式下的粒度细和强。 本文给出的 Art模式下基于Xposed Hook开发脱壳工具的思路和流程不是我原创，主要是源自于看雪论坛的文章《 一个基于xposed和inline hook的一代壳脱壳工具 》，思路和流程有原作者smartdon提供，文中提到的Art模式下的dexdump脱壳工具源码github下载地址： https://github.com/smartdone/dexdump 。原作者提供的脱壳操作步骤稍微复杂了一些，在此基础上我对原作者的代码进行了修改，使脱壳更加方便，原作者的代码是Android Studio的工程，顺手将其转化为了Eclipse下的工程。作者smartdon的Art模式下脱壳思路如下图所示：