安全编译器
⑴ iOS代码加密的几种方式
众所周知的是大部分iOS代码一般不会做加密加固,因为iOS
APP一般是通过AppStore发布的,而且苹果的系统难以攻破,所以在iOS里做代码加固一般是一件出力不讨好的事情。万事皆有例外,不管iOS、adr还是js,加密的目的是为了代码的安全性,虽然现在开源畅行,但是不管个人开发者还是大厂皆有保护代码安全的需求,所以iOS代码加固有了生存的土壤。下面简单介绍下iOS代码加密的几种方式。
iOS代码加密的几种方式
1.字符串加密
字符串会暴露APP的很多关键信息,攻击者可以根据从界面获取的字符串,快速找到相关逻辑的处理函数,从而进行分析破解。加密字符串可以增加攻击者阅读代码的难度以及根据字符串静态搜索的难度。
一般的处理方式是对需要加密的字符串加密,并保存加密后的数据,再在使用字符串的地方插入解密算法。简单的加密算法可以把NSString转为byte或者NSData的方式,还可以把字符串放到后端来返回,尽量少的暴露页面信息。下面举个简单例子,把NSString转为16进制的字符串:
2.符号混淆
符号混淆的中心思想是将类名、方法名、变量名替换为无意义符号,提高应用安全性;防止敏感符号被class-mp工具提取,防止IDA Pro等工具反编译后分析业务代码。目前市面上的IOS应用基本上是没有使用类名方法名混淆的。
别名
在编写代码的时候直接用别名可能是最简单的一种方式,也是比较管用的一种方式。因为你的app被破解后,假如很容易就能从你的类名中寻找到蛛丝马迹,那离hook只是一步之遥,之前微信抢红包的插件应该就是用hook的方式执行的。
b.C重写
编写别名的方式不是很易读,而且也不利于后续维护,这时你可能需要升级一下你的保护方式,用C来重写你的代码吧。这样把函数名隐藏在结构体中,用函数指针成员的形式存储,编译后,只留下了地址,去掉了名字和参数表,让他们无从下手( from 念茜)。如下例子:
c.脚本处理
稍微高级一点的是脚本扫描处理替换代码,因为要用到linux命令来编写脚本,可能会有一点门槛,不过学了之后你就可以出去吹嘘你全栈工程师的名头啦。。。
linux脚本比较常用的几个命令如下:
脚本混淆替换是用上述几个命令扫描出来需要替换的字符串,比如方法名,类名,变量名,并做替换,如果你能熟练应用上述几个命令,恭喜你,已经了解了脚本的一点皮毛了。
如以下脚本搜索遍历了代码目录下的需要混淆的关键字:
替换的方式可以直接扫描文件并对文件中的所有内容替换,也可以采用define的方式定义别名。例如:
d.开源项目ios-class-guard
该项目是基于class-mp的扩展,和脚本处理类似,是用class-mp扫描出编译后的类名、方法名、属性名等并做替换,只是不支持隐式C方法的替换,有兴趣的同学可以使用下。
3.代码逻辑混淆
代码逻辑混淆有以下几个方面的含义:
对方法体进行混淆,保证源码被逆向后该部分的代码有很大的迷惑性,因为有一些垃圾代码的存在;
对应用程序逻辑结构进行打乱混排,保证源码可读性降到最低,这很容易把破解者带到沟里去;
它拥有和原始的代码一样的功能,这是最最关键的。
一般使用obfuscator-llvm来做代码逻辑混淆,或许会对该开源工具做个简单介绍。
4.加固SDK
adr中一般比较常见的加固等操作,iOS也有一些第三方提供这样的服务,但是没有真正使用过,不知道效果如何。
当然还有一些第三方服务的加固产品,基本上都是采用了以上一种或几种混淆方式做的封装,如果想要直接可以拿来使用的服务,可以采用下,常用的一些服务如下:
几维安全
iOS加密可能市场很小,但是存在必有道理,在越狱/开源/极客的眼中,你的APP并没有你想象的那么安全,如果希望你的代码更加安全,就应给iOS代码加密。
⑵ 对于C++语言来说,什么叫做类型检查
静态类型检查:编译器检查,int i = "k" 编译器直接报错
还有dynamic_cast<>()也是由编译器进行类型检查
⑶ 编译器如何危及应用程序的安全
对于编译器如何将人类可读的代码翻译成机器运行的机器码,大多数程序员通常只有大概的概念。在编译过程中,编译器会对代码进行优化,使其能高效的运行。有的时候,编译器在优化上面走的太远了,它甚至移除了本不应该移除的代码,导致应用程序更加脆弱。
MIT人工智能和计算机科学实验室的四位研究人员调查了(PDF) 不稳定优化(optimization-unstable)代码的问题——编译器移除的包含未定义行为的代码。所谓的未定义行为包括了除以0,空指针间接 引用和缓冲溢出等。在某些情况下,编译器完整移除未定义行为代码可能会导致程序出现安全弱点。
研究人员开发了一个静态检查器STACK去识别不稳定的 C/C++代码,他们在足球平台出租测试的系统中发现上百个新bug:Linux内核发现32个bug,Mozilla发现3个,Postgres 9个和Python 5个。STACK扫描了Debian Wheezy软件包仓库8575个含有C/C++代码的软件包,发现其中3471个至少包含一个不稳定的代码。研究人员认为这是一个非常普遍的问题。
⑷ 用VS编译C 出现一个警告 什么意思啊
警告 2 warning C4013: “getch”未定义;假设外部返回 int d:\文件类\c语言\c 语言项目\c\c\2.c 12 C源代码是# include <stdio.h
void main(){int a[10];int i;for(i=0;i<10;i++){scanf("%d",&a[i]);}a[5]=a[5]+5;
printf("%d",a[5]);getch();}回答:很多涉及字符串的函数是不检查越界的, 不安全。 所以后来有一套新的安全函数替代这个, 第一个warning就是建议你用 scanf_s代替scanf 第二个 warning是说你用的 getch()没定义, 所以编译器假定它是 int getch(void)。 用的函数最好先 include好头文件
warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS
已经是安全主导的年代了,这些老旧的东西微软提供了一些新函式来取代,很简单他在后面加了_s ,例如gets == gets_s ,strcpy == strcpy_s原因解释这种微软的警告,主要因为那些C库的函数,很多函数内部是不进行参数检测的(包括越界类的),微软担心使用这些会造成内存异常,所以就改写了同样功能的函数,改写了的函数进行了参数的检测,使用这些新的函数会更安全和便捷。关于这些改写的函数你不用专门去记忆,因为编译器对于每个函数在给出警告时,都会告诉你相应的安全函数,查看警告信息就可以获知,在使用时也再查看一下MSDN详细了解。库函数改写例子:
mkdir改写为 _mkdir
fopen”改写为 fopen_s
stricmp改写为 stricmp_s
strcpy改写为strcpy_s解决方案:1 根据下面的warning提示:参见“fopen”的声明
消息:“This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.”
所以可以将函数按warning提示的第二句,改为使用fopen_s函数即可:
例如:FILE *pFile=fopen("1.txt", "w");改为:FILE* pFile;
fopen_s(&pFile, "1.txt", "w");
2 还是根据warning提示的地三句话:use _CRT_SECURE_NO_DEPRECATE
项目|属性|配置属性|C/C++|命令行|附加选项,加入【/D "_CRT_SECURE_NO_DEPRECATE" 】(注:加入中括号中完整的内容)
3 降低警告级别:项目|属性|配置属性|C/C++|常规,自己根据情况降低警告级别(此法不推荐)
注意:高度重视警告:使用编译器的最高警告级别。应该要求构建是干净利落的(没有警告)。理解所有警告。通过 修改代码而不是降低警告级别来排除警告。
编译器是你的朋友。如果它对某个构造发出警告,这经常是说明你的代码中存在潜在的问题。成功的构建应该是无声无息的(没有警告的)。【《