1

I've been working with this application to remove it's trial limitations. But every byte I change, it throws an acces violation.

Piece of the code:

Original:

003354C6 - 0F85 D3000000         - jne 0033559F
00EA54CC - FF 87 54050000        - inc [edi+00000554]
00EA54D2 - 83 BF 54050000 0A     - cmp dword ptr [edi+00000554],0A { 10 }
003354D9 - 0F82 C0000000         - jb 0033559F
003354DF - 6A 00                 - push 00 { 0 }

Patched

003354D2 - 83 BF 54050000 0F     - cmp dword ptr [edi+00000554],0F { 15 }

Nothing else is changed. Now the program does run, but after ~4 seconds it crashes.

When running through x64dbg it catches the exception, but I don't know what to do with it. x64dbg

And run just normally it gives this Windows crash report

Any help, tips would be appreciated!

New contributor
Daan Rozebloem is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
2

Without more information it's hard to tell for sure. However, I'd make 2 observations -

  • It appears that your patch is trying to increase the upper bound of a loop from 10 to 16.

  • The function in which the access violation occurs appears to be a C++ class member function where the faulting instruction is trying to read a member variable. (esi here is loaded from ecx where ecx is the this pointer.

The combination makes me suspect that the increase in loop limit results in an out-of-bounds array access. e.g. something like this -

std::array<some_class*,10> widgets;         // or std::vector or C-array etc

.. elsewhere ..

for( size_t i = 0; i < 10; ++i ) {          // the patch changes 10 to 15
    widgets[i]->faulting_function( ... );
}

To confirm this hypothesis and resolve it you are going to have work backwards from the faulting function to see where ecx comes from and then increase the size of the container. If however, this is static and in the data section of the exefile then it might not be trivial to do so.

  • Thanks for your response. I've looked further at it, and tries to patch some other areas. Still throws acces violation. So it's an anti-tamper measure. I'm new to x32dbg and I need to run a trace from entrypoint till execution with the original file and patched file. Do you know how? – Daan Rozebloem yesterday
0

This is more of a comment-answer, but as I am below 50 reputation, I can only post answers.

It's something to do with the cmp instruction you are byte-patching.

An access violation is occuring with the EIP register, which tells the computer what instruction to execute next, and controls the flow of the program. The cmp you are patching is breaking, likely because the what it's returning isn't met for the jb instruction to occur, hence the EIP is throwing an access violation.

How is the cmp working exactly? Have you reversed that?

Your Answer

Daan Rozebloem is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.