Map and projects (the most frequently updated page of this blog)


Aurais-je été meilleur ou pire que ces gens, si j'avais été...

packers' categories and features
Following my graph of the packers' landscape, I made a graph showing the different categories of packers, and what kind of features they have.
Then, to go deeper in details, I made a more detailed list of the various features for each of these kinds.

a graph of the different packers' categories and their features
a detailed list of packers' features

les sortes de packeurs et leurs caractéristiques
Après mon graphe sur le monde des packeurs, j'ai fait un graphe qui montre les différentes catégories de packeurs et le genre de caractéristiques qu'ils ont:
les types de packeurs et leurs caractéristiques (anglais)
ensuite, pour aller plus dans les détails, j'ai fait une liste qui détaille chaque catégories.
list détaillée du fonctionnement interne d'un packeur (anglais)

Je ne prévois pas pour l'instant de faire des versions françaises à mes codes sources ou graphes, faites-moi savoir si ça vous gène.


  1. I'm not agree with your nanomite definition.

    For me a nanomite is to replace instructions (like jcc/jmp for armadillo) by int3 or 1 handled by a driver (Pace ILok) or an attached debugger (armadillo).

    What you describe seems to be protected sections (part of code is encrypted and decrypted at the first execution or at any execution and re-encrypted after).
    Or instruction emulation (like in SafeCast), instruction is replaced by a function which emulate it.

    (Sorry for my bad english ;) )

  2. I'm not sure what the problem is.

    jcc/jmp are among the flow opcodes, and the important point of nanomite is that all flow paths should be taken to get a completely restored original file. whether it's by int1, int3 or something else (for example, make all E8 calls redirect to a 'decryptme' function would work too).

    Not sure if my one-liner doesn't show that, but it's difficult to limit yourself to a single line. let me know if it's better after my explanation.

    I don't know about safecast. do you have a more detailed example ?

  3. The word "nanomite" comes from Armadillo (now knows as SoftwarePassport) it describes the feature I've talk about in my previous comment, an instruction (for armadillo, a jcc/jmp) is replaced by an int3 catched by an attached debugger.

    The attached debugger doesn't decrypt or patch anything, it emulates the original instruction behaviour by changing eip according to the current Eflags states and the orignal instruction.

    There is no decryption an you can execute the int3 all the times you want it'll never be patched to the original instruction.

    This is why I think nanomite is not appropriate for your definition.

    An other Armadillo feature (CopyMem-II) does exactly what you are talking about (decrypting and encrypting on the fly). And many other packers like Obsidium.

    For SafeCast, just download a SafeCast protected application ;)

  4. I must have thought about a similar feature, where after the first use, the opcode was restored, so that the application doesn't become too slow (Safedisc, maybe ?). I'll put both protection under 'anti-flow'.

    CopyMem-II is what I called 'code splicing' (incorrect name), then.

    I won't have time for SafeCast anytime soon, so it will have to wait :(

    thanks for these comments.

  5. You're right, SafeCast and SafeDic restore the original opcode after some executions for speed optimisation reason (and it make it very easy to fix :p).

    Code splicing is not encryption of code (if I'm right, I just break protections, I'm not realy interrested in their names ;) ) it just add junk to little portions of code and redirect its in allocated memory, you can read an explanation of armadillo's implementation on my blog ;)