iOS Waxpatch Hot Update principle

Here's how to quote someone else's article:

• Why do I need waxpatch

  In many cases, applications already in AppStore need urgent bug fixes, and some technical tools are needed to enable applications to dynamically download patches for bug fixes.

• What is Waxpatch

  So far, the fastest in the scripting language is Lua. The Lua language was developed in 1993 by Roberto Ierusalimschy, Waldemar celes and Luiz Henrique de Figueiredo of the Catholic University of Rio de Janeiro, Brazil. Its original design was to provide a scripting language that was easy to embed into the application. The Lua language is fully implemented with ANSI C, and its design is elegant and beautifully coded. The Lua interpreter is a total of 200k in size and runs at a speed of about 1/5 of the C language, and the syntax is simple, even if not a professional programmer is easy to master. In the 2003, with the launch of Blizzard's big online game "World of Warcraft", Lua became known (the "World of Warcraft" plug-in system was developed using LUA), and Lua became increasingly popular in the game community. Most game planners in the country now use the Lua language for numerical or level design.

  The LUA editor in World of Warcraft

Because Lua is simple to program and fast to run, Wax was born on iOS, a project that supported the use of the Lua language to write iOS apps. The Wax project allows users to use the Lua language to mobilize the functionality of the Apple IOS SDK for application development.

The Wax patch project is derived from the Wax project, and Wax patch not only allows users to invoke the IOS SDK and API within the application using Lua, but also uses the OBJECTIVE-C runtime Class_replacemethod Call to replace the class method written by objective-c inside the application to achieve functional fine tuning or bug fixes.

Wax/waxpatch Main Features:

All Objective-c call interfaces are built on the OBJECTIVE-C runtime, so it's very convenient to call Objective-c's API, unlike calling C + +, which must first write the calling interface for LUA (some techniques can help LUA Calls to a dynamic library written in C + + without having to write the calling interface in advance, but cannot invoke an API written by the application on IOS.

The data type conversions between OBJECTIVE-C and Lua are encapsulated, so developers don't have to care about the data type conversions of LUA and objective-c for easy development.
Waxpatch Working principle
The features and implementation mechanisms of the Objectvie-c language make it easy to invoke any other scripting language. The main reason is that the Objective-c runtime provides a reflection and introspection mechanism for OC types such as classes/objects.
The relevant APIs are as follows:

Typedefstruct Objc_class *class;
Structobjc_object "" "Class Isa objc_isa_availability;" 】";
Typedefstruct Objc_object *id;
Typedefstruct Objc_selector *sel;
TypeDefId (*IMP) (ID, SEL, ...);
Selsel_getuid (const char *STR);
Constchar *object_getclassname (id obj);
Classobjc_getclass (const char *name);
Methodclass_getinstancemethod (Class cls, SEL name);
Methodclass_getclassmethod (Class cls, SEL name);
Impclass_getmethodimplementation (Class cls, SEL name);
Impclass_replacemethod (Class cls, SEL name, IMP imp, const char *types);

With the above API, you can dynamically invoke methods of Objective-c classes and objects through strings.

Wax/waxpatch call Objective-c is not simply to Objective-c runtime API to 1 to 1 encapsulation, but instead of all the Objective-c object \ class \ function \ etc. abstract into a waxinstance, operate on the waxinstance. Instead, Waxpatch overrides the __newindex property of the waxinstance's meta-table, calls the Class_replacemethod method to rewrite the parent class's function implementation, and uses the forwardinvocation mechanism to forward the calling method for the parent class to the Lua rewrites the class method inside.
Dynamic Patch Flow
We use Waxpatch in some projects to implement the thermal update mechanism, and the main process is as follows.

1. Patch Pack release process

2 Client Request Patch Process

3 Client Use patch process

The entire process follows these guidelines:

Simple and effective, avoiding complex logic. The entire patch package is a full-volume package instead of an incremental package for all patches.

Security is guaranteed. The release version of the patch pack is encrypted to avoid malicious tampering.

Correctness In the process of patching, if an error occurs, immediately exit the patch process, to avoid the original application of the process of fatal damage.

4 Full-volume patch package format
├──20150701_01
│├──loadpatchviewcontroller.lua
│└──init.lua
├──20150703_01
│├──ltmovieplayerviewcontroller.lua
│├──ltplaycontrolcenterview.lua
│└──init.lua
├──luapatchmanager.lua
└──letv_hotpatch_mapping.lua

①letvpatchmanager.lua: Patch management and execution files that determine whether patches should be used on the client by the client version number and the letv_hotpatch_mapping.ua file.
②letv_hotpatch_mapping.lua: Patch index file, record patch for that client version.
③20150701_01: Patch packet subcontracting, in order to facilitate the management of the package, the individual patch files are grouped.
④20150701_01/init.lua: Patch group execution file.
⑤20150701_01/xxxx.lua: A functional patch.
The entire programme consists mainly of the following components:

Patch Manager: Integrated within the client, written using OBJECTIVE-C, responsible for downloading the patch package from the server and extracting it into the client's sandbox.

Patch pack: See above.

Patch Packager: Responsible for encrypting all plaintext patches and packaging them in a ZIP format for the client to download.
Improved Waxpatch
Block invocation and implementation
Waxpatch for Objective-c block support is not complete, although some Waxpatch derivative version added some block support, but does not satisfy us, especially block's parameter support. About it. We have added Waxpatch support for block, which supports the variable parameters of block.

Security Solutions
Since Waxpatch can do the API modifications to all objective-c (both the system and the client). So in theory, an illegal LUA patch can modify the client's processes and functions to the detriment of the end user's information.

In order to ensure the security of client functions and processes, all Lua patch source code is encrypted by secret key in the released patch package. On the client side, we modify the LUA interpreter, use the public key to decrypt and verify the code, and avoid the illegal LUA patch file being executed.
Other solutions and conclusions
Another scenario that is the same as the Waxpatch scenario is jspatch. Jspatch uses the system's built-in JavaScript interpreter to dynamically JavaScript code to achieve the same purpose as waxpatch. The principle is basically the same as Waxpatch.

After investigation, Jspatch compared with waxpatch, there are some inherent shortcomings can not be solved:

① on the iOS6.0 system, Apple does not have an open javascriptcore engine, it needs its own built-in JS engine to increase the client's volume.

② because Jspatch uses the system's JavaScriptCore engine, we are unable to verify the legitimacy and validity of the Javascript patch, which poses a great security risk to the client.

The above reasons determine the use of waxpatch rather than the Jspatch scheme.

The path to software development should be to improve the quality of the code and the rigorous testing to control client quality. While Waxpatch can quickly fix flaws in online applications, this approach can always be used as a last line of defense rather than relying too much on it.

Attach Open Source Project

Https://raw.github.com/mmin18/Create-a-More-Flexible-App/master/Wax
Https://github.com/mmin18/WaxPatch

iOS Waxpatch Hot Update principle