lifting-bits/microx

Safely execute an arbitrary x86 instruction

microx's Issues

Publish to PyPI

We should publish microx to PyPI. Building it as a redistributable wheel shouldn't be too difficult, as long as we link XED statically.

Document the microx Python API

pdoc works well for us on other projects, we should use it here.

Use development dependencies correctly

These should be recorded as a dev extra in setup.py, instead of being hardcoded in random places.

Add type hints to the microx Python API

...and check them with mypy.

REP string instructions are broken

REP MOVSB was not working correctly for me. It seems the source and destination registers are not in the modified register set and do not get updated by WriteRegisters.

Something like this fixes the bug for me:

@@ -802,6 +802,7 @@ static void UpdateFlagsSub(Flags &flags, uintptr_t lhs, uintptr_t rhs,
     WriteGPR(dest_reg,                                                       \
              static_cast<uint64_t>(static_cast<int64_t>(ReadGPR(dest_reg)) + \
                                    stringop_inc));                           \
+    gModifiedRegs.set(dest_reg);                                             \
   } while (false)

 #define SCAS                                                                 \
@@ -813,6 +814,7 @@ static void UpdateFlagsSub(Flags &flags, uintptr_t lhs, uintptr_t rhs,
     WriteGPR(dest_reg,                                                       \
              static_cast<uint64_t>(static_cast<int64_t>(ReadGPR(dest_reg)) + \
                                    stringop_inc));                           \
+    gModifiedRegs.set(dest_reg);                                             \
   } while (false)

 #define LODS                                                                 \
@@ -821,6 +823,7 @@ static void UpdateFlagsSub(Flags &flags, uintptr_t lhs, uintptr_t rhs,
     WriteGPR(dest_reg,                                                       \
              static_cast<uint64_t>(static_cast<int64_t>(ReadGPR(dest_reg)) + \
                                    stringop_inc));                           \
+    gModifiedRegs.set(dest_reg);                                             \
   } while (false)

 #define MOVS                                                                 \
@@ -832,6 +835,8 @@ static void UpdateFlagsSub(Flags &flags, uintptr_t lhs, uintptr_t rhs,
     WriteGPR(dest_reg,                                                       \
              static_cast<uint64_t>(static_cast<int64_t>(ReadGPR(dest_reg)) + \
                                    stringop_inc));                           \
+    gModifiedRegs.set(src_reg);                                              \
+    gModifiedRegs.set(dest_reg);                                             \
   } while (false)

 #define CMPS                                                                 \
@@ -845,6 +850,8 @@ static void UpdateFlagsSub(Flags &flags, uintptr_t lhs, uintptr_t rhs,
     WriteGPR(dest_reg,                                                       \
              static_cast<uint64_t>(static_cast<int64_t>(ReadGPR(dest_reg)) + \
                                    stringop_inc));                           \
+    gModifiedRegs.set(src_reg);                                              \
+    gModifiedRegs.set(dest_reg);                                             \
   } while (false)

 #define REPNE(...)                \

CI builds

We should build both microx and its Python bindings in the CI.

Saving/restoring XMM / YMM register state in inline assembly

I don't recall if we're actually saving/restoring enough. I think we're only saving xmm0 through xmm7. I'd need to think more about whether more is needed. I don't believe that we rewrite things like raw uses of xmm8 (in avx2) to be in that range, for instance.

Python example with 64-bit RIP

Setting the memory map address bit size to 64 is not sufficient to run X64 code. It will constantly loop over one instruction because when microx updates the program counter it updates EIP instead of RIP.

Bug in pop rsp

pop rsp currently returns result increased by 8 opposed to expected value. One possible explanation is that following happens:

new = *rsp
store(dst, new)
*rsp = *rsp + 8

instead of

new = *rsp
*rsp = *rsp + 8
store(dst, new)

BT family incorrect mem displacement

For example BTS does not work with greater immediates.

Switch to trusted publishing

All of our PyPI-packaged projects should use trusted publishing, rather than a manually configured API token.

Example trusted publishing workflow:

https://github.com/trailofbits/blight/blob/master/.github/workflows/release.yml

Resources:

• https://docs.pypi.org/trusted-publishers/
• https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/

Is this related to the "Micro Execution" paper?

Thanks for the really cool project!
I am wondering if this is a related implementation of "Micro Execution" (https://patricegodefroid.github.io/public_psfiles/icse2014.pdf), which is not open-sourced?

Thanks.

Missing support for RDTSC / RDTSCP

While these are categorized as "system" instructions, they are also popular within userspace applications. While it is unlikely that microx can provide a "correct" implementation, it can at least provide a way for the user to provide an implementation.

Something like:

@@ -1347,6 +1421,18 @@ static bool Emulate(const Executor *executor, uintptr_t &next_pc,
       WriteGPR(reg0, mem0);
       return true;

+    case XED_IFORM_RDTSC:
+    case XED_IFORM_RDTSCP: {
+        Data tsc;
+        if (!executor->ReadTsc(tsc)) {
+          status = ExecutorStatus::kErrorReadTsc;
+          return false;
+        }
+        WriteGPR(reg0, *reinterpret_cast<uint32_t *>(&tsc.bytes[0]));
+        WriteGPR(reg1, *reinterpret_cast<uint32_t *>(&tsc.bytes[4]));
+      }
+      return true;
+
     default:
       return false;
   }
@@ -1382,6 +1468,14 @@ static bool UsesUnsupportedAttributes(void) {

 static bool UsesUnsupportedFeatures(const Executor *executor) {
   switch (xed_decoded_inst_get_category(gXedd)) {
+    case XED_CATEGORY_SYSTEM:
+      switch (xed_decoded_inst_get_iform_enum(gXedd)) {
+        case XED_IFORM_RDTSC:
+        case XED_IFORM_RDTSCP:
+          return false;
+        default:
+          return true;
+      }
     case XED_CATEGORY_3DNOW:
     case XED_CATEGORY_MPX:
     case XED_CATEGORY_AES:

DF not handled properly

DF is not having a correct value after executing some instruction. Best seen with popf and can crash program in other cases (by possibly not restoring properly?)