突然找到数年前写的这段代码,当是因为对密码学几乎不怎么了解踩了一些坑,现在开源出来方便大家直接利用. ECDSA的全名是Elliptic Curve DSA,也就是椭圆曲线DSA,由于椭圆曲线的复杂性是的其具备良好的安全性,也就是说无法从公钥计算出私钥. 签名过程分为以下两步:第一步:对于一段指定的字符串,首先对其做消息摘要.在示例代码中采用256bit的摘要,也就是以下部分: EVP_MD_CTX md_ctx; EVP_MD_CTX_init(&md_ctx); EVP_DigestInit

Android5.1.1 - APK签名校验分析和修改源码绕过签名校验 作者:寻禹@阿里聚安全 APK签名校验分析 找到PackageParser类,该类在文件“frameworks/base/core/java/android/content/pm/PackageParser.java”中.PackageParser类的collectCertificates方法会对APK进行签名校验,在该方法会遍历APK中的所有文件,并对每个文件进行校验.下面是该方法的部分源码: APK是一个ZIP格式的文件

某些apk为了防止重打包,使用了签名校验.所以在破解的时候我们需要破解签名校验.在定位签名校验位置时常用的关键词有sign,signature,checkSign,signCheck,getPackageManager,getPackageInfo,verify,same等. java层签名校验代码示例: //原签名信息 private static final String SIGNATURE = "478yYkKAQF+KST8y4ATKvHkYibo="; private sta

APK签名校验绕过 Android JNI 获取应用签名 android apk 防止反编译技术第一篇-加壳技术 android apk 防止反编译技术第五篇-完整性校验 利用IDA Pro反汇编程序 http://drops.wooyun.org/mobile/10010 http://drops.wooyun.org/mobile/4296 http://blog.csdn.net/masonblog/article/details/28095709 http://my.oschina.ne

转载:http://www.cnblogs.com/shipengzhi/articles/2716004.html 一.需解决的问题 部分API有签名参数(signature),Passport首先对签名进行校验,校验通过才会执行实现方法. 第一种实现方式(Origin):在需要签名校验的接口里写校验的代码,例如: boolean isValid = accountService.validSignature(appid, signature, client_signature); if (!

本文同步至http://javaexception.com/archives/30 问题: 之前的一个开源项目碰到了一个问题,Fix CertPathValidatorException: Trust anchor for certification path not found. 问题在于自建后台的站点用的是免费的ssl证书,okhttp默认会进行https签名校验,所以需要去掉这种校验. 解决办法: OkHttpClient.Builder builder = new OkHttpClien

ECDSA的全名是Elliptic Curve DSA,即椭圆曲线DSA.它是Digital Signature Algorithm (DSA)应用了椭圆曲线加密算法的变种.椭圆曲线算法的原理很复杂,但是具有很好的公开密钥算法特性,通过公钥无法逆向获得私钥.   第一部分 : DSA的签名和验证过程   要了解ECDSA,首先要了解DSA签名的过程和验证过程.为了理解的方便,这里省去诸多DSA算法的细节,仅就重要的几个点进行讨论.   1. 签名过程     假设要签名的消息是一个字符串:“He

概述 信息安全基本概念: ECC算法(Elliptic curve cryptography,椭圆曲线密码学) 一.ECC加密解密[暂时无意义] 椭圆加密算法(ECC)是一种公钥加密体制,最初由Koblitz和Miller两人于1985年提出,其数学基础是利用椭圆曲线上的有理点构成Abel加法群上椭圆离散对数的计算困难性. 是目前已知的公钥体制中,对每比特所提供加密强度最高的一种体制.在软件注册保护方面起到很大的作用,一般的序列号通常由该算法产生. ECC算法在jdk1.5后加入支持,目前仅仅只

一.需解决的问题 部分API有签名参数(signature),Passport首先对签名进行校验,校验通过才会执行实现方法. 第一种实现方式(Origin):在需要签名校验的接口里写校验的代码,例如: boolean isValid = accountService.validSignature(appid, signature, client_signature); if (!isValid) return ErrorUtil.buildError(ErrorUtil.ERR_CODE_COM

一.前言 之前已经写了一个爆破签名校验的工具kstools,很多同学也在使用,但是也反馈了不少问题,之前一篇文章也介绍了,关于爆破之后第三方登录问题修复,这篇我们在综合说明一下一些后遗症问题,关于kstools工具说明以及工具的原理,可以看这篇文章说明:Android中自动爆破签名工具kstools说明. 二.样本分析 下面开始进入正题吧,关于有些同学反馈,使用该kstools爆破某app之后,出现无限制重启问题,关于这个问题,我没见过,很好奇就是尝试了这个样本案例: 看到了,的确是这样的,无限

一.领券页面错误 二.给到前端的数据 三.根据给前端的额数据做签名校验 四.给前端的签名和校验的签名一致(这一步能判断签名没有问题,基本可以判断是前端调用微信接口时拼接的数据有问题) 五.以下是微信的领取卡券的接口(前端cardExt扩展字段有问题就会报签名错误)

转: http://drops.wooyun.org/mobile/4296 APK签名校验绕过 3xpl0it · 2014/12/11 10:41 0x01 Android签名机制 将APK重命名为zip文件,然后可以看到有个META-INF的文件夹,里面有三个文件,分别名为MANIFEST.MF.CERT.SF和CERT.RSA,这些就是使用signapk.jar生成的签名文件. 1. MANIFEST.MF文件: 程序遍历update.apk包中的所有文件(entry),对非文件夹非签名

接口参数签名校验,是WebApi接口服务最重要的安全防护手段之一. 结合项目中实际使用情况,介绍下前后端参数签名校验实现方案. 签名校验规则 http请求,有两种传参形式: 1.通过url传参,最常见的就是get请求(实际上post,put,delete都可以使用这种传参方式),如: http://api.XXX.com/getproduct?id=value1 2.通过request body传参,最常见的就是post请求,如下图所示 我们针对于以上两种传参方式,采用不同的签名校验规则(注:签

参数一定按照我得顺序写,这样可以不用排序,签名在图二. H5支付最坑的一点就是文档坑爹!!!文档中有一个场景信息字段写的是必填,实际上是不需要的!!因为这个字段找了一下午bug,用签名校验工具是成功的,但调用下单接口就是返回签名错误

前言 很多HTTP接口在传参时,需要先对接口的参数进行数据签名加密 如pinter项目的中的签名接口 http://localhost:8080/pinter/com/userInfo 参数为: {"phoneNum":"123434","optCode":"testfan","timestamp":"1211212","sign":"fdsfdsaafsa

需求描述: 项目里的几个Webapi接口需要进行鉴权,同接口可被小程序或网页调用,小程序里没有用户登录的概念,网页里有用户登录的概念,对于调用方来源是小程序的情况下进行放权,其他情况下需要有身份验证.也就是说给所有小程序请求进行放行,给网页请求进行jwt身份验证.由于我的小程序没有用户登录的功能,所以要针对小程序和网页设计出两套完全不同的鉴权方式. 鉴权流程设计: 查阅相关资料,最终决定的鉴权方式: 小程序采用sign签名检验 网页采用目前比较流行的JWT的token校验 通过AOP的思想使用.

我们在提供API服务的时候,为了防止数据传输过程被篡改,通常的做法是对传输的内容进行摘要签名,把签名串同参数一起请求API,API服务接收到请求后以同样的方式生成签名串,然后进行对比,如果签名串不一致,说明数据在传递过程中被篡改了,这时API服务拒绝本次请求即可,这样我们就实现了签名校验. 常见的摘要算法方式很多,如MD5.SHA.HMAC等,本文采用的是MD5+Base64的方式生成签名串,具体如下: 1.MD5加密方法 点击查看代码 ///<summary> /// 字符串MD5加密 //

该工具类中用到了BASE64,需要借助第三方类库:javabase64-1.3.1.jar注意:RSA加密明文最大长度117字节,解密要求密文最大长度为128字节,所以在加密和解密的过程中需要分块进行.RSA加密对明文的长度是有限制的,如果加密数据过大会抛出如下异常: Exception in thread "main" javax.crypto.IllegalBlockSizeException: Data must not be longer than 117 bytes at c

朋友发来一个apk,需要分析其中的一些算法,分析过程涉及到了重新打包apk,打包后的apk运行失败,估计是apk内部有检验是否被篡改的代码.检验apk是否被篡改,简单的方法是直接校验签名,如果apk签名和预先设置的签名不同,则可以判定apk被篡改了. 获取签名函数: getPackageInfo 尝试在代码里查找此函数,找到好几处,每个地方都查看了一下,最后定位到如下代码: public static String getSignNumber(Context paramContext) { tr

在开发app中,我们经常要为app提供接口.但是为了保证数据的安全,我们通常会对接口的参数进行加密. 1.不验证的接口api api接口请求,"http://www.xx.com/getUser/?a=1&b=2" 这样的接口中非常粗暴.恶意者可以通过修改参数去拉取数据.对数据不安全.增加api接口额外的调用. 2.带签名的接口调用 给参数的appid和appsercert.然后后端存储appsercert.前台通过将appid和参数一起加密.生成sign.后端用appserc