IOS on cubegao

通过 SSH 连接 iOS 设备的几种方法

Sun, 20 Oct 2019 19:20:00 +0800

必备工具

一台已经越狱的iPhone
一台PC

方案一

打开Cydia,搜索OpenSSH，安装。

保证PC和iPhone在同一局域网下，然后连接SSH。默认的账户是root，密码是alpine。地址是设备的局域网地址。

方案二

打开Cydia，卸载掉OpenSSH（如果安装了），然后添加源：http://cydia.ichitaso.com/test。（如果iPhone重启了，打开Cydia闪退，记得先Re-Jailbreak）
在Cydia中搜索dropbear，安装。

然后重复方案一的2.,直接SSH连接即可。

遇到的问题

如果wifi连接iPhone设备一直失败怎么办？

我们可以借助usbmuxd这个工具通过USB连接。

usbmuxd 是苹果的一个服务，这个服务主要用于在USB协议上实现多路TCP连接，将USB通信抽象为TCP通信。苹果的iTunes、Xcode，都直接或间接地用到了这个服务。它提供了一个USB - TCP的转换服务。

安装usbmuxd。

建立映射关系。

这样当前连接设备的22端口(SSH端口)映射到电脑的1234端口，因此想和设备通信，直接和本地端口1234通信就可以了。

安装 frida 遇到的一些问题

Wed, 09 Oct 2019 19:20:00 +0800

开始安装frida

首先需要安装python，Mac已经自带python2.7，frida作者是推荐安装python3.x。python2.x同样也能安装成功。

如果报错：

安装命令修改成

聊聊 iOS 中的内存管理

Thu, 23 Aug 2018 21:03:00 +0800

对于开发者来说，内存管理几乎是一个永恒的话题。

内存管理对于编写出高效率的iOS APP是非常重要的，这是因为iOS是多任务系统，在同一时刻可能有多个应用程序共享内存，有时为了使某个任务更好地执行，iOS系统可能会对其它任务分配的内存进行移动，甚至删除。

现在被广泛使用的内存管理机制主要有GC和RC两种。 GC：垃圾回收机制，定期查找不再使用的对象，释放对象占用的内存。 RC：引用计数机制，采用引用计数来管理对象的内存，当需要持有一个对象时，使它的引用计数+1，当不需要再持有一个对象的时候，使它的引用计数-1；当一个对象的引用计数为0时，该对象就会被销毁。

Objective-c支持三种内存管理机制:GC,MRC,ARC。以前MacOS开发中是支持GC的，后面引入ARC后就弃用了GC机制。iOS开发中使用的是RC机制，从MRC到现在的ARC。

###引用计数可以看我之前的一篇关于引用计数。

###MRC时代基本内存管理规则：MRC下是要严格遵守引用计数内存管理规则。内存管理模型是基于对象的所有权。任何对象都可以拥有一个或者多个所有者，但是一个对象最少要拥有一个所有者，它才会继续存在。如果对象没有所有者的，它将会被销毁。

####四条内存管理策略： 1.自己生成的对象，自己持有 alloc/new/copy/mutableCopy等方法创建的对象，我们自己直接持有，它的RC初始值为1，我们可以直接使用，不需要使用的时候调用release释放。

2.非自己生成的对象，自己也能持有。不通过上面方法创建的对象，它的RC初始值也为1，但是我们不能直接使用，要先调用retain，否则可能会crash。原因是因为这些方法内部是给对象调用了autorelease方法，所以这些对象是被添加到了自动释放池中了。

两种情况，程序没有手动指定@autoreleasepool，当runloop迭代结束时，会自动给释放池中的对象调用release方法。如果我们使用前不进行retain，刚好runloop迭代结束，对象的RC从1变成0,然后就被销毁了.我们去访问一个已经被销毁的对象,程序就会crash。程序手动指定了@autoreleasepool，当时出了其作用域，对象会调用release方法，然后销毁，这个时候使用对象也会crash。

3.不再需要自己持有的对象时，释放。不再需要持有或者使用对象的时候，就调用release或者autorelease方法进行释放。rc变成0时，就会调用dealloc方法销毁。 release立马rc-1，autorelease加入自动释放池，在合适的时候rc-1，实际上就是延迟释放。

4.非自己持有的对象，无需释放。自己不是持有者，调用release的话，会crash。

####实用的内存管理原则使用访问器方法可以省略大量的retain和release 推荐使用访问器方法设置属性，一个是可以避免忘记写retain和release，第二个是触发kvo 不要在初始化和dealloc中使用访问器方法，原因是在初始化中使用访问器方法，self=[super init]，首先会调用父类的访问器方法，然后如果子类重写了访问器方法，会去调用子类的访问器方法，而这个时候，子类实际上是没有初始化的，所以会出错。dealloc实际上是个反向的。就是子类先释放，再去调用父类。就是调用父类的dealloc时，会调用父类的访问器方法，如果子类重写了该访问器方法，就会去调用子类的访问器方法，但是子类已经释放掉了，也会出错。还有一个原因就是会触发KVO，在准备释放前，触发了kvo，即将释放的对象被持有了。就是出现莫名其妙的错误。推荐使用@autoreleasepool，虽然mrc下，可以使用NSautoreleasepool，但是速度慢很多。 1.写的程序是非UI框架，比如命令行工具 2.循环创建大量的临时变量。 3.多线程中。比如创建辅助线程。

###ARC时代 ARC时代，内存管理基本都交给编译器来处理了，对于开发者来说是十分友好了。 ARC的编译器有两部分，前端编译器和优化器。前端编译器会对每一个对象插入相应的release语句。类拥有的对象会在dealloc中释放。方法内创建的对象，前端编译器会在方法末尾自动插入release语句销毁它。优化器负责移除多余的retain和release操作语句。

但是还是有些地方需要注意的。

新增的几个关键字： __strong 强引用,用来保证对象不会被释放。 __weak 弱引用释放时会置为nil __unsafe_unretained 弱引用可能不安全，因为释放时不置为nil。悬垂对象。 __autoreleasing 对象被注册到autorelease pool中方法在返回时自动释放。

####block使用中出现循环引用

使用weakSelf结合strongSelf的情况下，能够避免循环引用，也不会造成提前释放导致block内部代码无效。在MRC下，应该使用__block。

在 Centos7.2 上安装编译 Swift

Fri, 30 Mar 2018 16:10:00 +0800

由于想用Swift写服务玩玩，准备在Centos7.2上部署一个Swift环境，能跑一下Perfect。

由于Docker的种种好处，当然是选择它来部署Swift环境。

安装Docker

更新yum包到最新。`如果是生产机器务必慎重更新内核，避免出现不必要的问题。`

1[root@fadaixiaohai ~]# yum update

执行 Docker 安装脚本。

1[root@fadaixiaohai ~]# curl -fsSL https://get.docker.com/ | sh

启动 Docker 进程。

1[root@fadaixiaohai ~]# service docker start

验证 docker 是否安装成功并在容器中执行一个测试的镜像。

1[root@fadaixiaohai ~]# docker run hello-world
2Hello from Docker!

大概两三分钟就安装好了，国内的服务器可能要用镜像加速会好点。

安装Swift

拉取Swift的镜像到本地。

1[root@fadaixiaohai ~]# docker pull swift

镜像拉取成功后就可以使用docker images列出当前我们拉取到本地的所有镜像：

1[root@fadaixiaohai ~]# docker images
2REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
3swift               latest              934835f58041        3 weeks ago         1.3GB
4hello-world         latest              f2a91732366c        4 months ago        1.85kB

我们都知道，操作系统分为内核和用户空间。对于 Linux 而言，内核启动后，会挂载 root 文件系统为其提供用户空间支持。而 Docker 镜像（Image），就相当于是一个 root 文件系统。