Fix issues related with debugging #1323

bet4it · 2019-07-14T10:59:10Z

We don't need to use os.environ when env is not set, and when remote debugging this will lead to a confusion.
We shouldn't file the local executable when remote debugging, gdb will download it automatically by exec-file related commands.
Unify the way to validate argv. (Should we put them in one place to avoid code duplication?)
Fix encoding related issues.

After this pulll request, some tests like

Lines 387 to 402 in 544ae93

    
                       # Connect to the SSH server 
        
                       shell = ssh('passcode', 'pwnable.kr', 2222, password='guest') 
        
                       # Start a process on the server 
        
                       io = gdb.debug(['bash'], 
        
                                       ssh=shell, 
        
                                       gdbscript=''' 
        
                       break main 
        
                       continue 
        
                       ''') 
        
                       # Send a command to Bash 
        
                       io.sendline("echo hello") 
        
                       # Interact with the process 
        
                       io.interactive()

pwntools/pwnlib/gdb.py

Lines 596 to 608 in 544ae93

    
                       shell = ssh('bandit0', 'bandit.labs.overthewire.org', password='bandit0', port=2220) 
        
                       # Start a process on the server 
        
                       cat = shell.process(['cat']) 
        
                       # Attach a debugger to it 
        
                       gdb.attach(cat, ''' 
        
                       break exit 
        
                       continue 
        
                       ''') 
        
                       # Cause `cat` to exit 
        
                       cat.close()

pwntools/pwnlib/gdb.py

Lines 858 to 864 in 544ae93

    
               >>> with context.local(log_level=9999): # doctest: +SKIP 
        
               ...     shell = ssh(host='bandit.labs.overthewire.org',user='bandit0',password='bandit0', port=2220) 
        
               ...     bash_libs = gdb.find_module_addresses('/bin/bash', shell) 
        
               >>> os.path.basename(bash_libs[0].path) # doctest: +SKIP 
        
               'libc.so.6' 
        
               >>> hex(bash_libs[0].symbols['system']) # doctest: +SKIP 
        
               '0x7ffff7634660'

can work (on my vps).

I think this pull request also solves #1314.

Arusekk

Well, this seems to be a nice change.

There are two minor drawbacks I addressed, but generally it is fine. Also it would be perfect if you added doctests for the new changes.

pwnlib/tubes/process.py

pwnlib/tubes/ssh.py

Co-Authored-By: Arusekk <arek_koz@o2.pl>

pwnlib/gdb.py

bet4it · 2019-07-16T09:21:25Z

@Arusekk It seems that there are no doctests in gdb.py, it may not suitable to add doctests there?

Arusekk · 2019-07-16T12:08:39Z

There is never anything wrong with adding tests to an untested piece of code 😉

The reason was so far that it was hard to automatically test debugging without having a display on the testing machine. (gdb.debug() results in starting another terminal by default)

bet4it · 2019-07-16T12:15:26Z

How can we test remote debugging? The vps provided in the comment ( pwnable.kr ) can't be used, I think they may add some restrictions.
And I really don't know how to build doctest environment locally.

Arusekk · 2019-07-16T13:13:52Z

Fortunately, the CI setup creates a virtual host example.pwnme and allows to log in without password as user travis. Testing gdb seems way harder than ssh, though.

bet4it · 2019-07-18T16:03:48Z

I'm trying to add doctests to gdb.py by setting context.terminal with custom script so we can interact with gdb. You can see what I have done in the latest commit.

I have some questions about it:

We may need to create a new script file for each doctest. Is this proper?
Is this proper to use pwntools in the script file?
Where should we put those scripts into?
Which name do you think the script files should have?
Should I use relative path when referring the script file? It seems that pwd is different when travis running in python2 and python3
Any other suggestions?

Arusekk · 2019-07-24T12:26:44Z

Yes, this looks perfectly fine, although a separate script for each file seems not very great.
I think the scripts could be placed under the docs/ directory, and named something indicating that they are fake terminals for gdb.

As for the path, you can use a path stored on the module (e.g. gdb.TEST_TERM_PATH), and resolve it relatively to pwnlib.__file__ or whatever.

Also, it could be useful to generate the fake terminal files on-the-fly, maybe using some utility function and tempfiles (the best option in my opinion).

You mentioned before something of deduplicating the code for validating argv and env. This is also a great idea, and the validation takes place (AFAICT) in gdb, in tubes.process, and in tubes.ssh.

@zachriggle what do you think of that?

numin0us · 2019-08-16T22:03:29Z

Hey @bet4it, I pulled your debug branch and noticed that this issue still crops up when gdb.attach() is invoked to attach to a local process.

root@kali:~/ctf/MBE/lab6A# ptpython
>>> from pwn import *
>>> context.log_level = 'DEBUG'
...
>>> p = process('./lab6A')
...
SION_BUS_ADDRESS': b'unix:path=/run/user/0/bus', b'SSH_TTY': b'/dev/pts/1', b'_': b'/usr/local/bin/ptpython', b'OLDPWD': b'/root/ctf/MBE'} : pid 12061
>>> gdb.attach(12061)
[DEBUG] Wrote gdb script to '/tmp/pwnk66rvllg.gdb'
    file "/root/ctf/MBE/lab6A/lab6A"

in GDB

pwndbg> disass main
Dump of assembler code for function main:
   0x00000c0f <+0>:     Cannot access memory at address 0xc0f

After hacking together a solution to remove the offending file line, debugging seemed to work fine.

bet4it · 2019-09-21T10:45:44Z

I have added doctests for most functions in gdb.py.

Now I only need one fake terminal file for all the situations.
But I need to set it in doctests of every function.
Can I set it globally before doctests started?

To solve the bug mentioned by @skywardgaze, I remove all the 'file' statement in gdb script. I think we should always load the symbols of executable in the argument of gdb command.

Arusekk

Sorry for not responding, I have been quite busy lately. I have some questions about the code you added.

Arusekk · 2019-12-06T11:50:14Z

.travis.yml

@@ -45,6 +48,7 @@ before_script:
  - PWNLIB_NOTERM=1 python -c 'from pwn import *; print(pwnlib.term.term_mode)'
  - PWNLIB_NOTERM=1 python -c 'from pwn import *; print(pwnlib.term.term_mode)'
  - PWNLIB_NOTERM=1 python -c 'from pwn import *; print(pwnlib.term.term_mode)'
+  - sudo sh -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope"


This shouldn't be necessary, as we do some prctl() in pwntools to mitigate this already

That's necessary. prctl() only affects direct child process.
You can try this by yourself:

pwntools/pwnlib/gdb.py

Lines 587 to 597 in 0491972

# Start a forking server

server = process(['socat', 'tcp-listen:1234,fork,reuseaddr', 'exec:/bin/sh'])

# Connect to the server

io = remote('localhost', 1234)

# Connect the debugger to the server-spawned process

gdb.attach(io, '''

break exit

continue

''')

The attach should fail if ptrace_scope is not set to 0.

I see, the process is created by socat, not us. This is bad, because pwntools users won't be able to do this either without disabling Yama.

I think most users won't use pwntools in this way, so it's okey to leave this problem here😃

pwnlib/gdb.py

Conflicts: pwnlib/gdb.py

Arusekk · 2019-12-09T16:15:03Z

pwnlib/util/cyclic.py

@@ -209,6 +209,7 @@ def cyclic_find(subseq, alphabet = None, n = None):

    if isinstance(subseq, six.integer_types):
        subseq = packing.pack(subseq, bytes=n)
+    subseq = context._encode(subseq)


This breaks python 3 build. What is your usecase?

I hope cyclic_find can also accept a str likes cyclic_find('baaacaaa') besides of cyclic_find(b'baaacaaa') in Python 3.

This must be done somehow differently. _encode enforces bytes, while we need the type that is used in the alphabet. The internal library usage does not use str with binary alphabets, nor does it use bytes with text alphabets.

I think we can unify subseq and alphabet to bytes. Add a commit to fix the build.

Fix issues related with debugging

f49ec1a

Arusekk requested changes Jul 15, 2019

View reviewed changes

pwnlib/tubes/process.py Outdated Show resolved Hide resolved

pwnlib/tubes/ssh.py Show resolved Hide resolved

Update pwnlib/tubes/process.py

91b82e0

Co-Authored-By: Arusekk <arek_koz@o2.pl>

zachriggle requested changes Jul 15, 2019

View reviewed changes

pwnlib/gdb.py Show resolved Hide resolved

bet4it mentioned this pull request Jul 16, 2019

gdb.attach loses symbols' address in PIE binary #1314

Closed

bet4it force-pushed the debug branch from a323a50 to 5375e34 Compare July 16, 2019 14:33

Enable doctest for find_module_addresses

9306305

bet4it force-pushed the debug branch from 5375e34 to 9306305 Compare July 16, 2019 15:11

Experiment about adding doctests to gdb.py

9881199

bet4it mentioned this pull request Aug 16, 2019

gdb.debug() appends an extra line to the passed gdbscript, resulting in symbol resolution errors #1333

Closed

bet4it added 2 commits September 2, 2019 21:37

Add doctests for most functions in gdb.py

857a7c2

Remove 'file' statement in gdb script

2613469

Arusekk reviewed Dec 6, 2019

View reviewed changes

Merge branch 'dev3' into debug

e2f28d8

Conflicts: pwnlib/gdb.py

Arusekk reviewed Dec 9, 2019

View reviewed changes

bet4it added 2 commits December 28, 2019 08:14

Merge branch 'dev' into debug

13735e3

Encode cyclic alphabet

323ee88

bet4it changed the base branch from dev3 to dev December 28, 2019 01:44

Fix travis build

a1502b8

Arusekk merged commit f727b66 into Gallopsled:dev Dec 29, 2019

bet4it deleted the debug branch December 29, 2019 12:41

CptGibbon mentioned this pull request Jul 2, 2020

qemu debugging support doesn't load target file #1625

Closed

goreil mentioned this pull request Sep 12, 2023

Bugfix gdb.debug: exe parameter now respected #2233

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix issues related with debugging #1323

Fix issues related with debugging #1323

bet4it commented Jul 14, 2019 •

edited

Loading

Arusekk left a comment

bet4it commented Jul 16, 2019

Arusekk commented Jul 16, 2019

bet4it commented Jul 16, 2019

Arusekk commented Jul 16, 2019

bet4it commented Jul 18, 2019

Arusekk commented Jul 24, 2019

numin0us commented Aug 16, 2019

bet4it commented Sep 21, 2019

Arusekk left a comment

Arusekk Dec 6, 2019

bet4it Dec 9, 2019

Arusekk Dec 9, 2019

bet4it Dec 10, 2019

Arusekk Dec 9, 2019

bet4it Dec 10, 2019

Arusekk Dec 27, 2019

bet4it Dec 28, 2019

	# Connect to the SSH server
	shell = ssh('passcode', 'pwnable.kr', 2222, password='guest')

	# Start a process on the server
	io = gdb.debug(['bash'],
	ssh=shell,
	gdbscript='''
	break main
	continue
	''')

	# Send a command to Bash
	io.sendline("echo hello")

	# Interact with the process
	io.interactive()

	shell = ssh('bandit0', 'bandit.labs.overthewire.org', password='bandit0', port=2220)

	# Start a process on the server
	cat = shell.process(['cat'])

	# Attach a debugger to it
	gdb.attach(cat, '''
	break exit
	continue
	''')

	# Cause `cat` to exit
	cat.close()

	>>> with context.local(log_level=9999): # doctest: +SKIP
	... shell = ssh(host='bandit.labs.overthewire.org',user='bandit0',password='bandit0', port=2220)
	... bash_libs = gdb.find_module_addresses('/bin/bash', shell)
	>>> os.path.basename(bash_libs[0].path) # doctest: +SKIP
	'libc.so.6'
	>>> hex(bash_libs[0].symbols['system']) # doctest: +SKIP
	'0x7ffff7634660'

	# Start a forking server
	server = process(['socat', 'tcp-listen:1234,fork,reuseaddr', 'exec:/bin/sh'])

	# Connect to the server
	io = remote('localhost', 1234)

	# Connect the debugger to the server-spawned process
	gdb.attach(io, '''
	break exit
	continue
	''')

Fix issues related with debugging #1323

Fix issues related with debugging #1323

Conversation

bet4it commented Jul 14, 2019 • edited Loading

Arusekk left a comment

Choose a reason for hiding this comment

bet4it commented Jul 16, 2019

Arusekk commented Jul 16, 2019

bet4it commented Jul 16, 2019

Arusekk commented Jul 16, 2019

bet4it commented Jul 18, 2019

Arusekk commented Jul 24, 2019

numin0us commented Aug 16, 2019

bet4it commented Sep 21, 2019

Arusekk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bet4it commented Jul 14, 2019 •

edited

Loading