mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-21 20:23:18 +00:00
GITBOOK-4328: No subject
This commit is contained in:
parent
8acbebc710
commit
7b5eb950c2
2 changed files with 25 additions and 2 deletions
|
@ -1034,7 +1034,9 @@ For more information about how this **communication work** on how it **could be
|
|||
|
||||
## MIG - Mach Interface Generator
|
||||
|
||||
MIG was created to **simplify the process of Mach IPC** code creation. It basically **generates the needed code** for server and client to communicate with a given definition. Even if the generated code is ugly, a developer will just need to import it and his code will be much simpler than before.
|
||||
MIG was created to **simplify the process of Mach IPC** code creation. This is because a lot of work to program RPC involves the same actions (packing arguments, sending the msg, unpacking the data in the server...).
|
||||
|
||||
MIC basically **generates the needed code** for server and client to communicate with a given definition (in IDL -Interface Definition language-). Even if the generated code is ugly, a developer will just need to import it and his code will be much simpler than before.
|
||||
|
||||
For more info check:
|
||||
|
||||
|
|
|
@ -14,8 +14,27 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
## Basic Information
|
||||
|
||||
MIG was created to **simplify the process of Mach IPC** code creation. It basically **generates the needed code** for server and client to communicate with a given definition. Even if the generated code is ugly, a developer will just need to import it and his code will be much simpler than before.
|
||||
|
||||
The definition is specified in Interface Definition Language (IDL) using the `.defs` extension.
|
||||
|
||||
These definitions have 5 sections:
|
||||
|
||||
* **Subsystem declaration**: The keyword subsystem is used to indicate the **name** and the **id**. It's also possible to mark it as **`KernelServer`** if the server should run in the kernel.
|
||||
* **Inclusions and imports**: MIG uses the C-prepocessor, so it's able to use imports. Moreover, it's possible to use `uimport` and `simport` for user or server generated code.
|
||||
* **Type declarations**: It's possible to define data types although usually it will import `mach_types.defs` and `std_types.defs`. For custom ones some syntax can be used:
|
||||
* \[i`n/out]tran`: Function that needs to be trasnlated from an incoming or to an outgoing message
|
||||
* `c[user/server]type`: Mapping to another C type.
|
||||
* `destructor`: Call this function when the type is released.
|
||||
* **Operations**: These are the definitions of the RPC methods. There are 5 different types:
|
||||
* `routine`: Expects reply
|
||||
* `simpleroutine`: Doesn't expect reply
|
||||
* `procedure`: Expects reply
|
||||
* `simpleprocedure`: Doesn't expect reply
|
||||
* `function`: Expects reply
|
||||
|
||||
### Example
|
||||
|
||||
Create a definition file, in this case with a very simple function:
|
||||
|
@ -37,7 +56,9 @@ simpleroutine Subtract(
|
|||
```
|
||||
{% endcode %}
|
||||
|
||||
Now use mig to generate the server and client code that will be able to comunicate within each other to call the Subtract function:
|
||||
Note that the first **argument is the port to bind** and MIG will **automatically handle the reply port** (unless calling `mig_get_reply_port()` in the client code). Moreover, the **ID of the operations** will be **sequential** starting by the indicated subsystem ID (so if an operation is deprecated it's deleted and `skip` is used to still use its ID).
|
||||
|
||||
Now use MIG to generate the server and client code that will be able to communicate within each other to call the Subtract function:
|
||||
|
||||
```bash
|
||||
mig -header myipcUser.h -sheader myipcServer.h myipc.defs
|
||||
|
|
Loading…
Reference in a new issue