I'm testing on Intel x86_64, Ubuntu 64bit, Python3, Pwntools v4.3.1
$ python
Python 3.7.4 (default, Aug 13 2019, 20:35:49)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pwn import *
>>> addr = 0xbffffb78
>>> print(p32(addr))
b'x\xfb\xff\xbf'
In my opinion, the correct packing result for 0xbffffb78 should be\x78\xfb\xff\xbf.
But why did b'x\xfb\xff\xbf' happen?
where is \x78 ?
And what is the correct way of packing, not using p32()?
This is just how Python renders bytes objects. If a byte can be rendered as an ASCII character, it is displayed as one.
>>> b"\x78"
b'x'
To see the bytes rendered as hex you can use the hex method of the bytes object:
>>> b'x\xfb\xff\xbf'.hex()
'78fbffbf'
Related
I need to get bytearray as string on python3.
on python 2.7 , str(bytearray) results the contents of bytearray in string format.
Python 2.7.18 (default, Feb 8 2022, 09:11:29)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> c = bytearray(b'\x80\x04\x95h\x00\x00')
>>> str(c)
'\x80\x04\x95h\x00\x00'
>>>
on python 3.6, even the "bytearray" keyword is added into the resulting string.
Python 3.6.8 (default, Aug 12 2021, 07:06:15)
[GCC 8.4.1 20200928 (Red Hat 8.4.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> c = bytearray(b'\x80\x04\x95h\x00\x00')
>>> str(c)
"bytearray(b'\\x80\\x04\\x95h\\x00\\x00')"
>>>
why is it happening so on 3.6 ?
how to get the exact same behavior on 3.6 as that of 2.7 ?
Note: I cannot do c.decode(), as those are compressed/pickled data which will result in invalid start byte errors.
Any suggestions please.
The __str__ method for the bytearray class is different in Python 3, to obtain a similar result you could try below snippet.
>>> str(bytes(c))
"b'\\x80\\x04\\x95h\\x00\\x00'"
I'm trying to use .. in a Windows long filename within Python and it is producing unexpected results.
Here is the output from the Python REPL:
Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.exists(u'\\\\?\\C:\\BitBucket\\crab6\\product\\installer\\windows\\..\\usage.txt')
False
>>> os.path.exists(u'\\\\?\\C:\\BitBucket\\crab6\\product\\installer\\usage.txt')
True
(I realize the path above isn't over 260 characters and therefore the long path syntax is unnecessary, but for the purposes of this post I've made it more manageable. The outcome is the same with very long paths.)
Has anyone else encountered this, and is it a purposeful limitation of long filenames?
I'm running python 3.6 + gunicorn + django 2.0.5 in docker container with some cyrillic project and that's what I see when I try to log cyrillic strings in console with Django.
'ascii' codec can't encode character '\u0410' in position 0: ordinal not in range(128)
Also this what happens in shell
Python 3.6.5 (default, May 3 2018, 10:08:28)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> :�ириллица
The same time, when i'm running python 3.5 outside docker container, everything is ok:
Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> Кириллица
Any ideas how to make python 3.6 inside docker work ok with cyrillic strings?
Use # -*- coding: utf-8 -*- in the first line of your python code.
And in your Dockerfile add:
ENV PYTHONIOENCODING=utf-8
How to prevent echo from input ??
Have tried "getpass()" but no luck.
On Windows IDLE, it doesn't work
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import getpass
>>> p = getpass.getpass(prompt="Input: ")
Warning: Password input may be echoed.
Input: abc <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< It still echos..
On the terminal of the Windows, it works
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import getpass
>>> p = getpass.getpass(prompt="Input: ")
Input:
>>>
Is there a easy way to prevent echo from input ?
I'm assuming your first example there is in IDLE.
From getpass.win_getpass():
if sys.stdin is not sys.__stdin__:
return fallback_getpass(prompt, stream)
IDLE replaces sys.stdin with a different object. getpass detects that somebody has wrapped stdin and fails for security reasons.
See: http://bugs.python.org/issue9290
I'm trying to compute hmac using sha-512.
The Perl code:
use Digest::SHA qw(hmac_sha512_hex);
$key = "\x0b"x20;
$data = "Hi There";
$hash = hmac_sha512_hex($data, $key);
print "$hash\n";
and gives the correct hash of
87aa7cdea5ef619d4ff0b4241a1d6cb02379f4e2ce4ec2787ad0b30545e17cde
daa833b7d6b8a702038b274eaea3f4e4be9d914eeb61f1702e696c203a126854
Python version:
import hashlib, hmac
print hmac.new("\x0b"*20, "Hi There", hashlib.sha512).hexdigest()
which gives the incorrect hash of
9656975ee5de55e75f2976ecce9a04501060b9dc22a6eda2eaef638966280182
477fe09f080b2bf564649cad42af8607a2bd8d02979df3a980f15e2326a0a22a
any ideas why the Python version is giving me the wrong hash?
Edit:
version is
Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
yes indeed -- it seems the Leopard version of python2.5 is the one that is broken.
below run on a Penryn-based MBP...
$ **uname -a**
Darwin lizard-wifi 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
dpc#lizard-wifi:~$ **which python**
/usr/bin/python
Running this version installed in Leopard OS
dpc#lizard-wifi:~$ python
Python 2.5.1 (r251:54863, Jan 13 2009, 10:26:13)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, hmac
>>> print hmac.new("\x0b"*20, "Hi There", hashlib.sha512).hexdigest()
9656975ee5de55e75f2976ecce9a04501060b9dc22a6eda2eaef638966280182477fe09f080b2bf564649cad42af8607a2bd8d02979df3a980f15e2326a0a22a
>>>
And then the MacPorts version of python2.5
$ /opt/local/bin/python2.5
Python 2.5.4 (r254:67916, Feb 3 2009, 21:40:31)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, hmac
>>> print hmac.new("\x0b"*20, "Hi There", hashlib.sha512).hexdigest()
87aa7cdea5ef619d4ff0b4241a1d6cb02379f4e2ce4ec2787ad0b30545e17cdedaa833b7d6b8a702038b274eaea3f4e4be9d914eeb61f1702e696c203a126854
>>>
I am unable to replicate your results here. In IDLE using Python 2.5:
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information.
...
IDLE 1.2.2
>>> import hashlib, hmac
>>> print hmac.new("\x0b"*20, "Hi There", hashlib.sha512).hexdigest()
87aa7cdea5ef619d4ff0b4241a1d6cb02379f4e2ce4ec2787ad0b30545e17cdedaa833b7d6b8a702038b274eaea3f4e4be9d914eeb61f1702e696c203a126854
Which version of Python? Strings are Unicode in Python 3. Is this a Unicode issue?
Under python 2.5.2 I get the correct hash
I guess the old version was the problem