Integrity protection implementation thoughts

[NewDwarf]

Do you ever think about adding integrity protection to make this product more or less complete?
It is pretty easy to implement any algorithm on C, precompile it is a bitcode file (*.bc) and then just link it as it is done for the custom implementation in AntiDebugging.cpp.
Example implementation:

1. Take predefined range of the specific length.
2. Do any simple arithmetic operation, say, addition, on that prediefined range (like mod 2^32) using secret random value as a key.
3. Compare the obtained result with the pre-calculated value.

Each integrity protection instance should have

1. Secret random value used as a key, valid pre-calculated integrity value for the specific range.
2. Pointer to the code which should be protected and its length.

Protection itself should be applied in two steps:

1. Linking of the precompiled bitcode file which implements integrity protection on compile time. In this step, the metadata file must be created which would inform what ranges should be protected and location of the tables to store valid integrity values.
2. Reading of the metadata file created on the first step, parsing it, calculating the valid checksum values for the predefined ranges and filling the integrity protection instance tables. For this step, separated tool is required.

[Naville]

We did in the original implementation of Hikari and then removed, guess why

[NewDwarf]

We did in the original implementation of Hikari and then removed, guess why

Probably, some guys try to commercialize the ideas. But I don't see the problem here. There is a balance here in:

1. Some guys tries to improve the algorithms and use it in its own apps becoming independent of the protector vendors. LLVM gives us a great opportunity to use rich LLVM API.
2. Some guys earns money on other people ideas. But at the same time, the lose potential customers because of previous statement.

[Naville]

Not really, the idea itself is inherently flawed, this is purely a technical issue

[NewDwarf]

Not really, the idea itself is inherently flawed, this is purely a technical issue

Do you mean if the algorithm is known, the protection is useless?

[NewDwarf]

We did in the original implementation of Hikari and then removed, guess why

Is this available somewhere? Or this implementation was not published on github?

[Naville]

Do you mean if the algorithm is known, the protection is useless?

Not only that, but a few other issues, some inherently from LLVM's IR system design. Should be easy to reason about once you start implementing it.

Is this available somewhere? Or this implementation was not published on github?

I dont remember, probably not

[NewDwarf]

Do you mean if the algorithm is known, the protection is useless?

Not only that, but a few other issues, some inherently from LLVM's IR system design. Should be easy to reason about once you start implementing it.

The main problem I see, at least, now is getting the ranges in the native code which should be protected as we cannot get the lenght of the function being protected. We can easily find the function location in the native code but getting its length is more difficult task.
Also, it is not clear how to get the specific basic block or the whole object module.

[Naville]

Exactly, in order to do that you need to dig very deep into the compilation pipeline, heavily modify multiple components in LLVM , as well as handling stuff like inlining or whatsoever.

[Naville]

QuarksLab had a slide about implementing such feature (although they talked about it in a such an obscure way that we can only guess that it's integrity related)

[NewDwarf]

@Naville How do you think whether LLVM's MachineFunctionPass can mitigate the problem with getting the required ranges of the native code?

[Naville]

Trade secret that I can't share too much

[61bcdefg]

It seems impossible to achieve high availability only through IR Pass, because it cannot be guaranteed that the TargetMachine generated by us is the same as the TargetMachine generated by the frontend, and the location of the IR Pass in the pipeline is also an issue

[61bcdefg]

No plans to implement this feature