At line #3 of a function, I have a QWORD at address 7FE875F3FE0 which resolves to a value of 85857490416 for which the function returns true. If not, the value is set to 0.

I would like to know how can I modify this QWORD to the said sequence of digits so that the function returns true. I have tried assembling this LoC, but it kills the function due to the non-match of the byte padding.

Code Cave is an option? If so, can somebody help me? Else a MOV statement?

Just started recently with RE and IDA Pro.

Code Segment

push    rbx
sub     rsp, 20h
mov     rax, cs:qword_7FE875F3FE0
mov     rbx, rcx
test    rax, rax
jnz     short loc_7FE8728D09D

mov     [rcx], rax
xor     eax, eax
add     rsp, 20h
pop     rbx

.data representation of the QWORD

.data:000007FE875F3FE0 qword_7FE875F3FE0 dq ? 
.data:000007FE875F3FE8 db    ? ;
.data:000007FE875F3FE9 db    ? ;
.data:000007FE875F3FEA db    ? ;
.data:000007FE875F3FEB db    ? ;
  • If your goal is to just have the function return true, why not just patch the function directly to always return true so that it never even looks at the value at qword_7FE875F3FE0? – Jason Geffner Jul 16 '15 at 15:35
  • The reason is because subsequent functions after this block looks for this particular value inside the [rcx] register. Performing what you suggest would then always result a value 0 to [rcx]. Future function calls depend on the validity of this register. – Pramod Mohandas Jul 16 '15 at 15:50
  • How do you arrive at 85857490416 from your code example? The code you posted will return 0, which is false, not true, if the value at qword_7FE875F3FE0 is anything but zero. – Guntram Blohm supports Monica Jul 16 '15 at 18:18
  • Because if I hover over qword_7FE875F3FE0 on LIne #3, I see this value which changes to 15483925093871637495 in the second segment move into [rcx]. – Pramod Mohandas Jul 16 '15 at 18:36

The easiest solution would likely be to patch the first block of the function to be the following:

push    rbx
sub     rsp, 20h
mov     rax, 85857490416
mov     rbx, rcx

Though mov rax, 85857490416 will consume extra bytes, you can remove test rax, rax and jnz short loc_7FE8728D09D to compensate.

And if it still doesn't fit, then yes, a code-cave would likely be the next option.

| improve this answer | |
  • What happens to the second half of the function that comes under the purview of loc_7FE8728D09D? Could you also point me to the code-cave alternative/sources as I would like to learn the same with this question. – Pramod Mohandas Jul 16 '15 at 16:56
  • As long as you only patch the first block, it should be fine. – Jason Geffner Jul 16 '15 at 16:57
  • So the code doesn't fit in. The program crashes on sub rsp, 20h I believe that a code-cave approach is necessary. Would it be possible for you to append a code-cave alternative to this query? Just the code part and not the basic how-to. – Pramod Mohandas Jul 16 '15 at 17:14
  • If the program crashes on sub rsp, 20h then something is very very wrong... – Jason Geffner Jul 16 '15 at 17:55
  • @Jason Geffner: Why consumes mov rax, 85857490416 more bytes than the (to be replaced) mov rax, cs:qword_7FE875F3FE0 ? Doesn't it consume one byte less to give space for a NOP? The bytecode should give evidence. – josh Jul 17 '15 at 0:57

Your Answer

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.