I'm learning reversing and for that i use Ghidra. There is program i'm trying to modify so i can recompile it and make it work. I have a code that ghidra decompile like this: data=function(4) Going inside the function i think to make it work i need to pass a zero. in the assembly i can read:

CALL function
MOV qword ptr [data],RAX

What i understand from that (and i'm propably wrong) is that the MOV EDI,0x4 is the 4 given in the function so i tried to rewrite it in Ghidra with 0x0 and it replace the:

bf 04 00 00 00 with bf 00 00 00 00

I thought it would be enough and i exported as an ELF but when i start the program i get a segmentation fault so i guess i'm doing something wrong with the memory.

    (gdb) x/10xi $rip
=> 0x555555401888:      mov    (%rax),%rax
   0x55555540188b:      test   %rax,%rax
   0x55555540188e:      jne    0x55555540189a
   0x555555401890:      mov    $0x0,%eax
   0x555555401895:      jmp    0x55555540199d
   0x55555540189a:      movq   $0x0,-0x50(%rbp)
   0x5555554018a2:      mov    -0x60(%rbp),%rax
   0x5555554018a6:      mov    %rax,%rdi
   0x5555554018a9:      call   0x5555554008f0 <strlen@plt>
   0x5555554018ae:      mov    %rax,-0x48(%rbp)

I would like some help to understand what i'm doing wrong.


  • Can you diff the two ELF files - before and after editing and post a diff here too? Also can you attach the ELF with gdb and post the crashing instruction?
    – sudhackar
    May 17 at 15:13
  • (gdb) run Results : Program received signal SIGSEGV, Segmentation fault. 0x0000555555401888 in ?? () May 18 at 6:35
  • command : diff <(objdump -d elffile) <(objdump -d elffileWithZero ) Result : 2c2 < elffile: format de fichier elf64-x86-64 --- > elffileWithZero: format de fichier elf64-x86-64 222c222 < b50: bf 04 00 00 00 mov $0x4,%edi --- > b50: bf 00 00 00 00 mov $0x0,%edi – May 18 at 6:50
  • Also can you disassemble the bytes where the application crash? Or just attach the original ELF file?
    – sudhackar
    May 18 at 6:54
  • Bytes view in ghidra c3 55 48 89 e5 bf 00 00 00 00 e8 19 0b 00 00 48 89 05 b7 24 20 00 48 8d 3d 82 ff ff ff May 18 at 6:59

1 Answer 1


You need to understand the consequences of patching an instruction. What gets changed by the instruction - both data and control flow. Based on the comments I think you are trying to patch this part

.text:0000000000000B4C                 push    rbp
.text:0000000000000B4D                 mov     rbp, rsp
.text:0000000000000B50                 mov     edi, 4
.text:0000000000000B55                 call    sub_1673


.text:0000000000000B4C                 push    rbp
.text:0000000000000B4D                 mov     rbp, rsp
.text:0000000000000B50                 mov     edi, 0
.text:0000000000000B55                 call    sub_1673

Based on this you can see what will change when sub_1673 gets executed.

.text:000000000000167C                 mov     [rbp+nmemb], rdi
.text:0000000000001680                 cmp     [rbp+nmemb], 0
.text:0000000000001685                 jnz     short loc_1691
.text:0000000000001687                 mov     eax, 0
.text:000000000000168C                 jmp     loc_1736
.text:0000000000001736                 add     rsp, 28h
.text:000000000000173A                 pop     rbx
.text:000000000000173B                 pop     rbp
.text:000000000000173C                 retn

Based on the calling convention 0 will be copied to rdi. It is then compared to 0 and then a jump is taken if its non zero. If its zero the function returns with a return value of zero. Something like

int sub_1673(size_t a1) {
    if(!a1) return 0;

If the value was non-zero some memory is allocated and the pointer is saved to some global variable. In your case - after the patch the variable stays 0 and the application crashes while read NULL(0) address.

  • thanks it clarified what is happening and what do to May 18 at 9:09

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.