展开

关键词

腾讯安全ApkPecker上线DEX-VMP自动化脱壳服务

头图.png 近日,腾讯安全科恩实验室ApkPecker上线了自动化脱壳服务,帮助安全人员更好地进行安全审计。经过大规模测试结果显示, ApkPecker的脱壳成功率超过了85%。 而市面上现有的自动脱壳工具不能解决DEX虚拟化的加固方案,并且厂商自定义的解释器会定期更换Opcode映射表,导致很多自动脱壳服务无法完整有效的还原DEX代码。 同时,针对厂商的DEX虚拟化保护(DEX-VMP), ApkPecker也进行了针对性脱壳和恢复。 ApkPekcer的脱壳方案解决了opcode handler识别的难点,自动化还原被DEX-VMP保护的代码,提高了脱壳的完整度和自动化程度。 此次上线的自动化APK脱壳服务,也是其整体能力的又一次升级。

79110

实用FRIDA进阶:脱壳自动化、高频问题

前面我们聊到了Frida在内存漫游、hook anywhere、抓包等场景中地用法,今天我们聊Frida在脱壳自动化的用法以及经常被问到的高频问题。 Frida系列文章地址:https://github.com/r0ysue/AndroidSecurityStudy 1 Frida用于脱壳 安全工程师在拿到应用评测的任务之后,第一件事情是抓到他的收包发包 ,第二件事情应该就是拿到它的apk,打开看看里面是什么内容,如果不幸它加了壳,可能打开就是这样的场景,见下图,什么内容都看不到,这时候就要首先对它进行脱壳。 ,手机上处理不了的在电脑上处理、反之亦然; “自动化”:手机电脑互相协同,实现横跨桌面、移动平台协同自动化利器。 也就是说,我们的目标是哪怕输入admin的账户名和密码,也可以绕过本地校验,进行服务器验证登陆的操作。

1.9K00
  • 广告
    关闭

    90+款云产品免费体验

    提供包括云服务器,云数据库在内的90+款云计算产品。打造一站式的云产品试用服务,助力开发者和企业零门槛上云。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    自动化服务治理

    如对于,数据库的自动化分析 —— 已经有 Tequila 进行了大量的自动化。 ? 微服务粒度适应度函数 对于微服务架构来说,最令人头疼的一个问题就是微服务粒度。 往往是一个团队维护了超过其自身数量的微服务,即 6 个开发人员可能维护了 8 个微服务。 大家常犯的一个错误是:通过技术维度而非业务维度划分微服务。关于这部分的自动化,我暂时找不到头绪。 微服务服务间调用从函数调用变成了远程调用,这也意味着,我们并不能从 A 服务直接访问 B 服务的数据库,而是通过访问 B 服务的接口,借助它去访问数据库。 扫描 MyBatis 等这一类的工具,生成表和服务关系维护 实现『数据库表-映射服务』的快照测试。 简单来说,我们的工具在这一部分所要做的事情是:每次代码提交时,进行自动化地扫描,生成一个快照。 简单来说,就是将《系统重构与迁移指南》一书中记载的部分,通过自动化的方式进行识别。 数据结构适应度函数 ? 关于数据结构/数据模型,已经有一些工具可以做类似的事情。

    34230

    Ansible自动化部署服务

    bash_profile; sh 902.验收商业app.sh nohup - name: ust the new website shell: /opt/sy/test.sh 编写服务启动检查脚本

    35520

    某移动应用安全加固与脱壳技术研究与实例分析

    01 概述 — 由于近期很多朋友问关于Android加壳与脱壳技术,这两天我就对目前主流的脱壳工具和加壳方法做了研究,就对目前的脱壳方法做个汇总和方法记录。 接下来运行脱壳程序进行脱壳,这里比较简单了,直接运行脱壳程序,参数就是进程名,如下: ./drizzleDumper com.thsseek.welove ? 点击操作就完成了脱壳操作了: ? 03 总结 通过对3款Android应用的脱壳工具的测试,效果最好的就是drizzleDumper 了,但未测试收费的加壳服务不知道能不能脱壳,后面有机会再测试,脱壳过程主要是研究各个工具的使用,均是利用工具自动化方式来实现 ,后面有机会尝试手动脱壳测试。

    1.3K80

    自动化测试」微服务自动化测试简介

    除上述内容外,测试人员还应确保所有接口都是通用的,以便其他系统/服务可以毫无障碍地使用。 由于需要自动化所有内容,因此请使用Micro Services测试自动化工具。 这些工具有助于验证每个独立服务单元的功能,并通过组合多个这些微服务来执行集成测试。 微服务自动化测试级别 单元测试 - 这是测试单个微服务测试单元的内部工作。 对于单元测试,使用基于NUnit或JUnit的单元测试框架,以较少的QA参与自动化测试。 对于合同测试,QA测试自动化工程师参与。此测试在每个服务单元中执行,通过隔离它并命中服务的单个URI。 例如,内存和CPU使用等问题在本地传递,而不同的服务通常继续工作。 如何对微服务进行自动化测试? 有五种策略用于成功测试微服务自动化服务测试的最佳实践 隔离测试 微服务很难测试,因为有许多独立服务以许多(通常是未预料到的)方式与其他独立服务进行通信。开始测试自动化工作的一个好地方是直接测试特定微服务的功能。

    1.1K20

    支撑性服务 & 自动化能力

    Backing services 云原生系统依赖于许多不同的辅助资源,例如数据存储、消息队列、监视和身份服务,这些服务统称为支撑性服务。 下图显示了云原生系统使用的常见支撑性服务 ? 要素4指出:“支撑性服务“应通过可寻址的URL公开,这样做解耦了将资源与应用” 要素3指出:“将配置信息从微服务中移出并外挂” Stateless和支撑性服务,这样松散的设计使你可以将一项支撑性服务换成另一项支撑性服务 支撑性服务将在第5章“云原生数据模式”和第4章“云原生通信模式”中详细讨论。 自动化 如你所见,云原生依赖(微服务、容器和现代设计理念)来实现速度和敏捷性。 但是,你如何配置运行这些系统的云环境? 被广泛认可的作法是基础设施即代码(IaC) 借助IaC,你可以将平台配置和应用程序部署自动化,将诸如测试和版本控制之类的软件工程实践应用于你的DevOps实践。 你的基础架构和部署是自动化,一致且可重复的。 Automating infrastructure 在底层,IaC是幂等的,这意味着你可以一遍又一遍地运行相同的脚本,而不会产生副作用。

    21710

    Android | 自动化测试辅助服务

    题图:Photo by Ma Fei at Hong Kong 今天聊聊Android的自动化测试,但这里先不讨论具体的技术方案,这些放到后面章节讨论,本文主要来跟大家分享一下自动化测试过程中一定会遇到的一些问题以及针对这些问题提供的一系列辅助服务 UI自动化测试 不管是通过什么方案实现的UI自动化,录制回放也好、写自动化脚本也好,都会遇到同样的问题:在不同手机上安装被测应用时弹出的系统提示框,这部分肯定是没办法通过脚本实现的,而且存在兼容性问题: 不同手机的安装流程一般是不一样的,那么怎么才能让安装这部分流程自动化呢? 我们的主角登场了:AccessibilityService 具体实现参考:https://github.com/logan62334/Jarvis 安装好辅助应用后,点击图标会打开系统的辅助功能页面,这里会看到系统服务中已经注册好了一个叫智能安装服务的条目 ,打开该服务即可。

    14620

    Kubernetes微服务自动化发布系统

    实施微服务架构后,原先单一的系统结构统变成了数量众多的微服务应用,开发、测试、运维部署等都会面临不少挑战。 在本篇文章中我将以Spring Cloud微服务技术体系为背景,通过GitLab自带的CI/CD机制并基于Kubernetes容器化技术来实现一套具备相对完整CI/CD流程的自动化发布系统。 GitLab-CI自动化发布系统的关键实现 前面我们描述了基于GitLab-CI机制实现自动化发布系统的基本组成,要具体实现这套系统你需要安装部署GitLab服务器并配置GItLab Runner功能, 由于GitLab服务器是CI/CD流程执行的主要承载点,如果你的服务是基于Maven构建的Java服务,那么还需要在GitLab服务器中安装Maven客户端,并配置Maven私服的地址,以提高构建速度。 基于GitLab-CI机制的自动化发布系统由于其构建方式比较简单,不需要太多的开发工作,因此目前不少创业公司中都采用了此类方案来实现微服务自动化构建和交付。

    86511

    Ansible自动化编译安装Nginx服务

    部署了那么多线上服务器,80%以上几乎都是脚本搞定,自动化的今天我可能有点土逼了。。 说搞就搞~~ Ansible 这款软件简直是太灵巧了。如下分享是经过实操的,也就是真正应用在了线上。 使用 Ansible 无需安装服务端和客户端,只要 SSH 即可。这意味着,任何一台装有 Ansible 的机器都可以成为强大的管理端。我觉得,这种去中心化的思路显得更为灵活。 nginx_install]# cd files/ [root@zhdy01 files]# ls nginx-1.12.0.tar.gz template这一行对应的是template这个目录和主服务端定义的变量 ~ /\.ht { # deny all; #} } include vhosts/*.conf; }##需要注意的就是模板变量(客户端自动采集)、和在服务端定义的变量

    1.3K50

    「docker实战篇」python的docker爬虫技术-移动自动化控制工具安卓SDK安装和配置(14)

    为什么要一起学习移动的自动化,在app这里,有50%的app的通过抓包软件就可以分析出来抓包的参数,抓取到信息。 比如上次说的app,通过fiddler就可以进行分析就可以抓取里面的数据了,还有30%的需要适当的反编译分析出加密算法之后,才能抓取到信息,剩余的20%犹豫进行了加固,如要脱壳进行反编译,分析出加密算法之后才能进行抓取信息 其实对于反编译和脱壳我也不熟悉,但是为了可以进行正常抓取剩余的50%,可以通过移动自动化工具的方式来进行滑动,点击,分页等操作,在配合使用mitmdump来调用python语言解析。 ? 因为咱们需要SDK的一个环境来进行自动化的控制。 下载SDK http://tools.android-studio.org/ ? 目前演示环境是windows我就选择windows的 ?

    34420

    搭建jenkins实现自动化部署微服务_自动化部署平台搭建

    注意双引号内是个助记符根据需要修改 cd /root/.ssh # 进入ssh目录 git ls-remote -h ssh://git@118.188.3.87:1022/html/tamH5.git HEAD # 连一下git服务器 chown jenkins * # 将key文件的所有者改为jenkins d)此时pwd再ll应该看到如下内容   2、打开 id_rsa.pub 将其中内容复制到记事本中,然后再copy到git服务器上

    6730

    如何构建Web服务自动化测试系统?

    构建自动化测试系统中,需要根据项目大小和对错误的容忍程度,酌情补充不同类型和级别的用例。  3.经典测试金字塔 ?    4.manual test:   数量:10%   测试内容:针对本次修改点对应的功能进行重点测试   实现:手工测试   触发:每个迭代的新增功能和bug及探索性测 试,有必要的话,需要对应增加上述自动化用例

    37430

    服务自动化部署平台之Saltstack总结

    Salt是基于python写的经典C/S框架的自动化部署平台。由Master和Minion构成,通过ZeroMQ进行通信。 4505(publish_port)为salt的消息发布系统,4506(ret_port) 为salt客户端与服务端通信的端口。 key的名字)                用来和master进行认证 #/etc/init.d/salt-minion restart                             重启服务 (安装的软件包,服务的运行状态以及需要同步的文件配置)     注意:salt默认的根目录在/srv/salt中,如果没有需要进行建立。 salt-cp用来复制文件到制定的系统上去 salt-key用来和minion之间进行身份验证 salt-master为服务端的主守护进程用于控制minion salt-run为前端命令执行 module

    83060

    SaaS设计:自动化服务启停设计示例

    在远程连接的时候特别容易操作错误,比如通过远程桌面或者是ssh连接,本来想要重启A服务器上的服务,不小心把B服务器上的服务重启了。 所以,我们可以借助自动化运维平台,来开发一个用于批量、自动执行服务启停的SaaS。 本文就对服务启停SaaS的设计进行一些讨论。下面我们就分类进行讨论要完成一个服务启停动作要包含的要素。 常见的操作有【启动服务】、【停止服务】和【重启服务】,另外还有如果按常规方法停止服务后,服务不响应请求时,需要一个【强制杀进程】的操作。 【启动服务】后,我们需要检查服务是否启动成功;【停止服务】后,我们需要检查服务是否停止成功等。 因为一般在启停整个集群下的服务时,为了不让应用出现中断服务的情况,需要先启停其中一部分服务,启停成功且正常提供服务后,再启停剩余部分。如图示: ? 启停适用性设计 你设计的服务启停能启停哪些服务

    35640

    服务架构系统中的自动化测试

    一个成功的微服务架构的业务系统,必须进行大量的自动化测试。简单来说,在微服务架构中,测试的层次变得更多,而且对环境的搭建要求更高。 在本文中,我们将讨论您可以为微服务编写的五种类型的自动化测试。 API测试 当我们创建一个微服务时,我们最终为消费者提供API来访问和消费资源。例如REST和SOAP API。您可以通过为API编写自动化测试来测试它。 用户验收测试 这是自动化测试的最后一个级别,您将测试最终用户使用场景的各个方面。这里的重点是创建实时使用场景,例如访问用于测试逻辑的生产模式数据库。在发布和启动应用程序之前,这一步是必要的。

    32130

    腾讯云Kafka海量服务自动化运营实践

    腾讯云CKafka是基于Apache Kafka 的分布式、高可扩展以及高吞吐的云端Kafka服务。 这种情况下,我们会根据迁移后的服务节点数量生成多种迁移方案,每种方案下迁移的代价是不同的。当从少数机器迁移往多数机器时,每个机器所需要的服务能力会更小。 当前我们迁移主要为了解决以下几种问题:服务异常,这种情况必须迁移实例下的Partition,否则后续服务可能会受到影响;实例扩缩容,这种情况下必须迁移实例部分Partition,否则无法满足用户升级的需求 Replica迁移方式 自动化控制中心架构 为了满足日常运维指标以及告警的实际需求,以及自动化调度功能实现,整个自动化控制中心架构的实现如下: ? 图9. 小结 针对CKafka的Broker节点底层改造以及利用自动化控制中心对迁移的合理管控,有效解决CKafka运营过程中遇到的实例分配、升降配、迁移以及集群负载均衡调度等一系列问题,为海量节点运营提供了自动化运营手段

    8.1K50

    原 荐 RESTFul 服务测试自动化的艺术

    老码农在上一篇博客 给出了如何从头开始创建一个 自带自动化测试工具的 RESTful 服务项目的例子. 今天我们在这个简单例子上做延伸, 把这个例子改写为一个简单的 TODO Task 应用. 更重要的问题是人工在这种重复性劳作上远远不如机器可靠, 如果没有自动化测试的保障, 即便是大牛也不敢随便对代码动刀子搞搞重构之类的高级手术. 那自动化测试怎么搞, 这是一个问题. 多年寻寻觅觅找不到满意的方案, 这思路一开, act-e2e 插件便横空出世. 5.1 act-e2e 简介 act-e2e 是老码农为 Act 应用开发提供的自动化测试插件, 其设计目的主要有一下几点 在本文中我们不会详细罗列整个 Scenarios 文件的语法结构, 而是通过对 Todo 服务进行自动化测试来介绍 Scenarios 文件的用法. 5.3 为 Todo 服务实现自动测试 打开 src 该定义来自 Todo 服务的下面的服务端口: @PostAction @Transactional public int create(Todo todo) { dao.save(todo);

    27130

    帮助企业实现客户服务自动化的方式

    自动化客户服务会带来许多好处,其中最明显的一点就是降低成本。 但是除了降低成本之外,它还有什么其他的好处呢?让我们仔细聊聊为什么越来越多的企业正在自动化他们的客户服务。 什么是自动化的客户服务? 随着信息技术的发展,目前,,自动化客户服务包括以下内容: 自助服务门户和知识库 AI聊天机器人 电子邮件和短信模板 解决问题的交互式工具 自动化客户服务的优势是什么? (4)鼓励客户服务团队合作 自动化客户服务工具可以帮助增强团队合作。配备自动化功能的工作台可以改善解决客户投诉的工作流程,从而避免重复步骤,工单批准后,可以标记为无变更。 如何实现客户服务自动化,实现客户服务自动化需要从多个方面考虑。以下是一些自动化客户服务的方法: 创建客户服务知识库 实现客户服务自动化的第一步是创建知识库。 总之,如果你不提供自动化客户服务,可能会限制你向潜在客户提供高水平服务的能力。

    12530

    相关产品

    • 自动化助手

      自动化助手

      自动化助手(TAT)是云服务器的原生运维部署工具。通过自动化助手,您无需登录服务器,也无需打开入站端口、SSH,便可以直接管理实例,批量执行 Shell 命令,轻松完成运行自动化运维脚本、轮询进程、安装或卸载软件、更新应用以及安装补丁等常见管理任务。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券