(无网通信)MDNS实现设备间的发现与通信

简介

这里无网通信指的是没有互联网的通信方式，之前在区块链公司是做这块，现在怕自己以后忘了写一遍，之前搞工业机器人实在太忙，整个博客停了，也不搞移动了，现在离职了，创业也败了，该恢复一下之前的技术调整心态继续找工作了。

所谓无网通信其实是不同设备互相发现然后连接进行通信，而互相发现的方式可以归纳成三种

  • 两个设备连接在同一个WIFI
  • 两个设备通过WLAN创建点对点连接
  • 两个设备通过蓝牙BLE创建点对点连接

而前两种是最稳定的方式，可以使用Wifi Direct实现，而蓝牙BLE的方式就比较鸡肋了距离有限制大小也有限制，能Wifi直连肯定不用蓝牙。然而蓝牙的发现连接标准其实各个设备基本都遵循的是一套，但Wifi Direct则是实现方式多种多样像UPnP、Bonjour、DLNA、SLP抑或是其他技术都能实现。iOS用的自家Bonjour，而Android4.0后开始支持直接就叫Wifi Direct，不同设备直连基本都会遇到问题。这里以Android和iOS为例实现的基本逻辑其实都由MDNS与DNS-SD演化而来。

确定了Wifi Direct以后又会发现一个问题就是这解决的是设备与设备的通信，也就是一对一，而理想的无网通信是多对多，信息流之间希望有多跳的能力也就是Mesh，这个最终我们也没完美解决，虽然Android和iOS里有一定的解决方案(创建群组实现多对多)但也有不同系统无法互通的问题和群组上限问题，但当时我们选择了更简单的方式就是由路由器去Mesh其他路由器，而设备加入到路由器的网络里直接用MDNS去发现然后链接通信，专业设备做专业事，Mesh组网和设备通信分摊到两个地方。

MDNS(Multicast DNS)与DNS-SD(DNS Service Discovery)

简介里介绍完基本就确定了技术点就是Wifi Direct，而这项技术则是由MDNS(Multicast DNS)与DNS-SD(DNS Service Discovery)演化而来。

首先MDNS和DNS-SD是DNS协议的两个扩展。MDNS扩展了域名服务系统，在链路本地多播上运行。DNS-SD添加了通过DNS发现网络服务的支持。MDNS原理就是在基于udp加入网络后向所有主机组播一个消息。

基本流程就是基于某个自定义域名发布服务，发现设备，连接设备

Bonjour API

more >>

查看全文 >>

OLLVM代码混淆移植与使用(续)

现状

随着时间时间推移，类似库都基本不维护了，毕竟LLVM新版本改动多还好说，再多只要看看关键位置就大差不差知道怎么改怎么兼容，最难的就是编译，每次编译调试不知不觉没干啥就能耗人一天，另外就是以前的人现在都不知道还在不在业内，回归正题，其实修改的地方并不多，下面我就整理了一下关键位置，主要就是类型和调用顺序变了一下，了解以后去修改类似的项目也是手到擒来。

关键修改

9.0以后的修改

这里类型写法更加标准一步一步转
image.png
这里是9以后不在调用这个方法了，导致fla不生效，也可以在Flattening.cpp里面修改添加
image.png

more >>

查看全文 >>

OLLVM代码混淆移植与使用

简介

OLLVM(Obfuscator-LLVM)是瑞士西北应用科技大学安全实验室于2010年6月份发起的一个项目,该项目旨在提供一套开源的针对LLVM的代码混淆工具,以增加对逆向工程的难度。github上地址是https://github.com/obfuscator-llvm/obfuscator ，只不过仅更新到llvm的4.0，2017年开始就没在更新。

移植

OLLVM如果自己想拿最新版的LLVM和Clang进行移植功能其实也并不是很难，整理一下其实改动很小，接下来将会讲一下移植的方法。

个人整理

先放一下个人移植好的版本地址https://github.com/heroims/obfuscator.git ，个人fork原版后又加入了llvm5.0，6.0，7.0以及swift-llvm5.0的版本，应该能满足大部分需求了，如果有新版本下面的讲解，各位也可以自己动手去下载自己需要的llvm和clang进行移植。git上的提交每次都很独立如下图，方便各位cherry-pick。
more >>

查看全文 >>

AES-128-CBC Base64加密——OC,Java,Golang联调

AES-128-CBC

这里首先说说AES加密原理
AES加密算法采用分组密码体制，每个分组数据的长度为128位16个字节，密钥长度可以是128位16个字节、192位或256位，一共有四种加密模式（ECB、CBC、CFB、OFB），我们通常采用需要初始向量IV的CBC模式，初始向量的长度规定是128位16个字节。另外就是Padding，这里面有大坑。。。。先说一下Padding的三种模式PKCS5、PKCS7和NOPADDING。PKCS5是指分组数据缺少几个字节，就在数据的末尾填充几个字节的几，比如缺少5个字节，就在末尾填充5个字节的5。PKCS7是指分组数据缺少几个字节，就在数据的末尾填充几个字节的0，比如缺少7个字节，就在末尾填充7个字节的0。NoPadding是指不需要填充，也就是说数据的发送方肯定会保证最后一段数据也正好是16个字节。而PKCS5如果正好是16个字节且最后是16的时候则会再填充16个16用来区分，PKC7则是为0时填充16个0。而在iOS的OC方法里压根没提供PKCS5，只有PKCS7更坑的是真正对接时发现iOS上的PKCS7和其他端PKCS5是一样的。。。。所以才有了现在的想法分享一下踩过的坑，具体啥原因恐怕只有苹果自家知道，系统方法是真的坑！Java可以直接用系统方法填好设置结束战斗。。。Go的话padding这块自己写实现其他的系统都能设置。最后说一下密钥长度这里只有iOS是要自己设置好位数再对应位数写密钥，其他平台直接对应位数写密钥即可，所以最好各平台自己在封装下判断密钥长度出事向量长度，不然各端对应起来还是要犯傻。
more >>

查看全文 >>

Cocoa(iOS,OSX)安保系统设计实现

3994053-6cb0e72bd8827012.png

前言

这里主要以iOS和OSX讲讲crash闪退怎么防御。
其中最新的OSX应用本身就有一定闪退防御，但有点类似@try @catch在最外层包了一下普通的越界调用空方法都会中断在操作位置不向下执行，如果没有进一步复杂逻辑不会闪退，只是影响后续的操作。

而iOS则没这么好说话了，二话不说直接闪退给你看没有上面的那种机制。

所以才有了设计一个安保系统的意义，来保证最大程度的健壮性，理想的状态就是不crash且能继续正常运行后面的逻辑。

参考了众多网上的资料有了下面的小成果分享出来，这其实只是安保系统最后的一个环节的防御

https://github.com/heroims/SafeObjectProxy

安保系统设计

这里我所认为的安保系统应该从代码和规范两个层面看，毕竟想抓到所有的crash情况是一定不可能的，现实中即使处处try catch都没法保证抓到所有crash！

代码

  • swizzing切面
  • 方法防御选型
  • 防御成功上报
more >>

查看全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

大环境不好工作是越来越难找了<br><br>有能推荐的希望推荐下<br>谢谢大家