Skip to content
This repository has been archived by the owner on Dec 6, 2023. It is now read-only.

Still some encoding issues #28

Closed
maaaaz opened this issue Nov 1, 2015 · 4 comments
Closed

Still some encoding issues #28

maaaaz opened this issue Nov 1, 2015 · 4 comments

Comments

@maaaaz
Copy link

maaaaz commented Nov 1, 2015

Hello @byt3bl33d3r,

I would like to report (again) some encoding issues.
Steps to reproduce:

  1. Create a file named àâæçéèêëïîôœ—– »« ”’€ÿüûù.txt on a share. Note that this contains french accents.
  2. List that share
  3. See the bug
$ python crackmapexec.py -d adyolo -u user1 -p "yoloswag1!" 192.168.11.136 -s share --list encoding2
[*] 192.168.11.136:445 is running Windows 6.3 Build 9600 (name:DC01) (domain:adyolo)
[+] 192.168.11.136:445 Login successful adyolo\user1:yoloswag1!
[+] 192.168.11.136:445 Contents of encoding2\*:
drw-rw-rw-       0 2015-11-01 22:50 .
drw-rw-rw-       0 2015-11-01 22:50 ..
-rw-rw-rw-      25 2015-11-01 22:32 credz.txt
Traceback (most recent call last):
  File "/root/venvcrackmapexec/local/lib/python2.7/site-packages/gevent/greenlet.py", line 327, in run
    result = self._run(*self.args, **self.kwargs)
  File "crackmapexec.py", line 2903, in connect
    f.get_longname()))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-13: ordinal not in range(128)
<Greenlet at 0xb679bbbcL: connect('192.168.11.136')> failed with UnicodeEncodeError

I managed to fix this by editing the line #2093
from:

f.get_longname()

to:

f.get_longname().encode('utf-8')

It gives that output:

python crackmapexec_bug.py -d adyolo -u user1 -p "yoloswag1!" 192.168.11.136 -s share --list encoding2
[*] 192.168.11.136:445 is running Windows 6.3 Build 9600 (name:DC01) (domain:adyolo)
[+] 192.168.11.136:445 Login successful adyolo\user1:yoloswag1!
[+] 192.168.11.136:445 Contents of encoding2\*:
drw-rw-rw-       0 2015-11-01 22:50 .
drw-rw-rw-       0 2015-11-01 22:50 ..
-rw-rw-rw-      25 2015-11-01 22:32 credz.txt
-rw-rw-rw-      33 2015-11-01 13:14 àâæçéèêëïîôœ—– »« ”’€ÿüûù.txt

I saw you modified the print_* functions but I don't understand why utf-8 decoding fails at this point.

Finally, note that these encoding issues might exists for other features, every feature calling the longname() function.

Cheers.

@byt3bl33d3r
Copy link
Owner

@maaaaz Awesome, This is a duplicate of #24 but wasn't able to reproduce since he/she didn't provide any info. Will fix today

@byt3bl33d3r
Copy link
Owner

@maaaaz Deleted the second comment and opened a new issue ticket here #34 since it was a seperate issue

byt3bl33d3r pushed a commit that referenced this issue Nov 1, 2015
All strings are now unicode by default (ala Python3)
@byt3bl33d3r
Copy link
Owner

@maaaaz Should be fixed if not comment below. Thanks

@maaaaz
Copy link
Author

maaaaz commented Nov 2, 2015

Okay and I agree with you: double exception is really ugly :D
I also agree: unicode issues are a pain...
For the Windows version I used the following stuff:

  • that for ignoring codepage issues on cmd term:
# Windows specific to output UTF-8
import codecs
codecs.register(lambda name: codecs.lookup('utf-8'))
  • that to ignore potential decoding errors:
result.get_longname().encode('utf-8', 'ignore')

Anyway, I'll try your fix and let you know about it!

noraj pushed a commit to noraj/CrackMapExec that referenced this issue Jul 7, 2023
noraj pushed a commit to noraj/CrackMapExec that referenced this issue Jul 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants