mem tracing is out of sync by 1 op position compared to x64dbg

[brandonros]

this is half nitpick half like "actual problem" in terms of lining up x64dbg vs scemu for comparison

here is x64dbg line

{
    "i": 1,
    "iHex": "1",
    "x64dbgLine": {
      "rawLine": {
        "Index": "00001",
        "Address": "00000001448A76A9",
        "Bytes": "E8 C2C96D00",
        "Disassembly": "call dts9_patcherv.144F84070",
        "Registers": "rsp: 14F4A0-> 14F498",
        "Memory": "000000000014F498: 7FFA617547B1-> 1448A76AE",
        "Comments": ""
      },
      "rip": "1448a76a9",
      "registerChanges": [
        {
          "registerName": "rsp",
          "previousValue": "14f4a0",
          "newValue": "14f498"
        }
      ],
      "memoryChanges": [
        {
          "address": "14f498",
          "previousValue": "7ffa617547b1",
          "newValue": "1448a76ae"
        }
      ]
    }

here is scemu line

    "scemuLine": {
      "rawLine": {
        "diffRegLine": "diff_reg: pos = 1 rip = 1448a76a9 rsp 14f4a0 -> 14f498;",
        "memTraceLines": [
          {
            "rawLine": "mem_trace: pos = 1 rip = 1448a76a4 op = write bits = 64 address = 0x14f4a8 value = 0x1db36b3a name = 'stack'",
            "position": "1",
            "rip": "1448a76a4",
            "operation": "write",
            "bits": "40",
            "address": "14f4a8",
            "value": "1db36b3a"
          }
        ]
      },
      "position": "1",
      "rip": "1448a76a9",
      "registerChanges": [
        {
          "registerName": "rsp",
          "previousValue": "14f4a0",
          "newValue": "14f498"
        }
      ],
      "memoryChanges": [
        {
          "address": "14f4a8",
          "previousValue": 0,
          "newValue": "1db36b3a"
        }
      ]
    },
    "instructionErrors": [
      {
        "index": 0,
        "message": "unmatchedMemoryChange mismatch (x64dbg but not scemu)",
        "x64dbg": "14f498"
      },
      {
        "index": 0,
        "message": "unmatchedMemoryChange mismatch (scemu but not x64dbg)",
        "scemu": "14f4a8"
      }
    ]
  },

it isn't until next instruction/position (whatever you want to call it) that we pick up 000000000014F498: 7FFA617547B1-> 1448A76AE memory change

"scemuLine": {
      "rawLine": {
        "diffRegLine": "diff_reg: pos = 2 rip = 144f84070 rsp 14f498 -> 14f490;",
        "memTraceLines": [
          {
            "rawLine": "mem_trace: pos = 2 rip = 1448a76a9 op = write bits = 64 address = 0x14f4a0 value = 0x1448a76ae name = 'stack'",
            "position": "2",
            "rip": "1448a76a9",
            "operation": "write",
            "bits": "40",
            "address": "14f4a0",
            "value": "1448a76ae"
          }
        ]
      },
      "position": "2",
      "rip": "144f84070",
      "registerChanges": [
        {
          "registerName": "rsp",
          "previousValue": "14f498",
          "newValue": "14f490"
        }
      ],
      "memoryChanges": [
        {
          "address": "14f4a0",
          "previousValue": 0,
          "newValue": "1448a76ae"
        }
      ]
    },

this isn't necessairly a bug but i'm curious what you recommend/how you would approach/if you can think of a fix

[sha0coder]

in first place the position 1 is not the call, x64dbg starts by 0 isn't it?
1 0x1448a76a4: push 1DB36B3Ah ;0x1db36b3a
2 0x1448a76a9: call 0000000144F84070h

in second place the push and pop i think is ok, push print before doing the push, pop print after doing the pop (other wise wouldn't have the poped value).

But regarding get_operand_value/set_operand_value the first is done before the operation and the other is done after the operation.

Is in that moments when we know the memory address and value.

Other option is having a track of the addr+value.

[sha0coder]

I should modify the stepping logic, to pre-print the instruction before being emulated.
Step and continue comands should be reimplemented, but that's another topic.