TypeError in svcrack / svhelper getNonce

[sandrogauci]

Command line parameters:
['/usr/bin/svcrack', '-u', '1003', '192.168.123.15', '-vv', '-R']
version: 0.3.0
msg: 
python version: 
3.9.1 (default, Dec  8 2020, 07:51:42) 
[GCC 10.2.0]
osname: posix
uname: posix.uname_result(sysname='Linux', nodename='kali', release='5.9.0-kali5-amd64', version='#1 SMP Debian 5.9.15-1kali1 (2020-12-18)', machine='x86_64')

Trace:
Traceback (most recent call last):
  File "/usr/share/sipvicious/sipvicious/svcrack.py", line 524, in main
    sipvicious.start()
  File "/usr/share/sipvicious/sipvicious/svcrack.py", line 282, in start
    self.getResponse()
  File "/usr/share/sipvicious/sipvicious/svcrack.py", line 189, in getResponse
    nonce = getNonce(authheader)
  File "/usr/share/sipvicious/sipvicious/libs/svhelper.py", line 196, in getNonce
    _tmp = re.findall(nonceRE, pkt)
  File "/usr/lib/python3.9/re.py", line 241, in findall
    return _compile(pattern, flags).findall(string)
TypeError: expected string or bytes-like object

[sandrogauci]

might be a dupe of #44

[0xInfection]

I tried doing some tests on my end to see if this issue is reproducible, but couldn't. However I have 2 ideas that might solve this issue.

Looking at the error, it can be said that at least NoneType isn't being passed to the function. So it might be some other corrupt data is being passed along to that function (which is possible because we are using ignore when using decode('utf-8', 'ignore')). So my suggestions are:

• Use the binary bytes received from the server for regex matching and everything. Do not decode to ASCII.
• Use strict function parameter accepting datatypes, so that in this way we can better track the value being passed to the function.

Let me know what you think of this. If it sounds good, happy to make a PR.

[sandrogauci]

the user who submitted this issue fixed it by doing the following:

fixed that error by simply adding "if authheader is not None:" to the svcrack.py script on string #189. It was assuming that 401/407 response automatically means presence of authentication header, but life shows that it isn't :)

I didn't yet have time to replicate the issue and get it fixed but I'm trying to find out if this is something that we're not actually catching - so don't do anything yet @0xInfection :)