# Is this code equation solvable?

Assuming the following lines of code:

`````` MOV DWORD PTR FS:,EAX
CALL someRoutine
MOV EAX,DWORD PTR DS:[EAX+4]
CMP DWORD PTR DS:[EAX+1204],0
JE placeInCode
XOR EAX,EAX
``````

My goal is to change [someRoutine] in such a way that the JE is always taken - I specifically don't want to tamper with the code outside [someRoutine]. So just think of [someRoutine] as a set of instructions that you can freely change and adapt.

I can't seem to understand how to solve this equation. If there was no MOV instruction after the call, I guess I could just go to the address [EAX+1204] and fill it with 0. But like this, there seem to be too many unknown dependencies.

Have `someRoutine` perform the following actions (in C below for example purposes) --

``````DWORD* p = (DWORD*)malloc(8);
p = 0;
p = (SIZE_T)p - 1204;
return p;
``````

Obviously this is a memory-leak since the allocated memory never gets `free()`'d, so you wouldn't want to use this approach if `someRoutine` gets called often. However it's not feasible to offer a better recommendation without us knowing the memory layout of the actual program.

Edit: Updated based on @tathanhdinh's suggestion.

• Maybe I am wrong, since the degrees of freedom of this equation is 2 (they are value of EAX and the memory); we may need just a 8 bytes malloc, for example: `dword* p = malloc(4 * 2); p = 0; p = (dword)p - 1204; return p;` Nov 9 '15 at 17:37
• @tathanhdinh: Nice thinking! I've updated my answer above. Thanks! Nov 9 '15 at 17:44
• Thanks a lots @JasonGeffner. I think we can just change `malloc` by a stack allocation, then we may not have memory leak, for example: `dword a; dword b = 0; a = (dword)&b - 1204; return &b;` Nov 9 '15 at 20:58
• @tathanhdinh: That assumes that the returned data is evaluated immediately after `someRoutine` is called. If @vic wants to make this work for each call of `someRoutine` throughout the program, I don't know that it's safe to assume that the stack values will never get overwritten between the `someRoutine` call and the check. Nov 9 '15 at 21:07
• Ahhh, you are absolutely right @JasonGeffner. I did not take into account the situation that you described. Nov 9 '15 at 21:15