On Wed, 10 Jan 2007 10:31:50 -0600, Chris Mellon <[EMAIL PROTECTED]> wrote:
> On 10 Jan 2007 08:12:41 -0800, sturlamolden <[EMAIL PROTECTED]> wrote:
>>
>> Chris Mellon wrote:
>>
>> > This works fine if the binary data is "pure" asm, but the impresssion
>> > the OP gave is that it's a compiled binar
On 9 Jan 2007 07:04:11 -0800, sturlamolden <[EMAIL PROTECTED]> wrote:
>
> Jorgen Grahn wrote:
>
>> For what it's worth[1], under Unix it /is/ impossible. The only way to bring
>> in
>> new code (short of dynamic libraries) is to call exec(2) or its variations,
>> and all need a file system object
On 10 Jan 2007 08:12:41 -0800, sturlamolden <[EMAIL PROTECTED]> wrote:
>
> Chris Mellon wrote:
>
> > This works fine if the binary data is "pure" asm, but the impresssion
> > the OP gave is that it's a compiled binary, which you can't just "jump
> > into" this way.
>
> You may have to offset the fu
Chris Mellon wrote:
> This works fine if the binary data is "pure" asm, but the impresssion
> the OP gave is that it's a compiled binary, which you can't just "jump
> into" this way.
You may have to offset the function pointer so the entry point becomes
correct.
--
http://mail.python.org/mailm
On 9 Jan 2007 07:04:11 -0800, sturlamolden <[EMAIL PROTECTED]> wrote:
>
> Jorgen Grahn wrote:
>
> > For what it's worth[1], under Unix it /is/ impossible. The only way to
> > bring in
> > new code (short of dynamic libraries) is to call exec(2) or its variations,
> > and all need a file system obj
Jorgen Grahn wrote:
> For what it's worth[1], under Unix it /is/ impossible. The only way to bring
> in
> new code (short of dynamic libraries) is to call exec(2) or its variations,
> and all need a file system object to load the code from.
The x86 processor cannot tell the difference between c
Jorgen Grahn wrote:
> On 8 Jan 2007 12:29:36 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> For what it's worth[1], under Unix it /is/ impossible. The only way to bring
> in
> new code (short of dynamic libraries) is to call exec(2) or its variations,
> and all need a file system object t
On 8 Jan 2007 12:29:36 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
>> Is it possible to execute a binary string stored within a python script
>> as executable code ?
>>
>> The script is run under Windows, and the binary code (a full executable
>> file) is stored
"Chris Mellon" <[EMAIL PROTECTED]> wrote:
> Repost. Is there any chance at all that ML could set the
> reply-to to the list instead of the sender?
+1
- I regularly hit "reply all", delete the OP, and then I get :
"Message has a suspicious header"
- Hendrik
--
http://mail.python.org/mai
On 1/8/07, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> At Monday 8/1/2007 18:01, [EMAIL PROTECTED] wrote:
>
> >Chris Mellon wrote:
> > > Writing to a temp file will be at least 3 times as easy and twice as
> > > reliable as any other method you come up with.
> >
> >I'm not disputing that, but I
At Monday 8/1/2007 18:01, [EMAIL PROTECTED] wrote:
Chris Mellon wrote:
> Writing to a temp file will be at least 3 times as easy and twice as
> reliable as any other method you come up with.
I'm not disputing that, but I want to keep a piece of code (a parser
for Oracle binary dumps, that I did
[EMAIL PROTECTED] wrote:
> The code I try to execute is Windows specific and it is binary,
> not python. Furthermore, it is stored in a variable within the
> parent python script, not stored on harddisk as a file.
Sure, I just wanted to show that your special application is not
specific for troja
Bjoern Schliessmann wrote:
> But you could technically achieve this with standard python too
> (just write python source and spawn a python process executing it).
The code I try to execute is Windows specific and it is binary, not
python. Furthermore, it is stored in a variable within the parent
Larry Bates wrote:
> What you are asking is a virus/trojan "like" program.
Why? For being a trojan horse it must fake something. For being a
virus it must replicate itself. Writing an executable doesn't imply
the will to replicate itself.
But you could technically achieve this with standard pyt
Chris Mellon wrote:
> Writing to a temp file will be at least 3 times as easy and twice as
> reliable as any other method you come up with.
I'm not disputing that, but I want to keep a piece of code (a parser
for Oracle binary dumps, that I didn't wrote) out of foreign hands, as
much as possible.
On 8 Jan 2007 12:45:45 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Larry Bates wrote:
>
> > What you are asking is a virus/trojan "like" program. There's no reason
> > you shouldn't be able to write the code to TEMP directory and execute it.
> >
> > -Larry
>
>
> No, it is not about a tro
Larry Bates wrote:
> What you are asking is a virus/trojan "like" program. There's no reason
> you shouldn't be able to write the code to TEMP directory and execute it.
>
> -Larry
No, it is not about a trojan, but I guess it's pointless to try to
convince you otherwise.
It's not about being ab
[EMAIL PROTECTED] wrote:
> Is it possible to execute a binary string stored within a python script
> as executable code ?
>
> The script is run under Windows, and the binary code (a full executable
> file) is stored in a variable in the script.
>
> I know I can use os.system() or os.popen() to run
[EMAIL PROTECTED] wrote:
> Is it possible to execute a binary string stored within a python script
> as executable code ?
>
> The script is run under Windows, and the binary code (a full executable
> file) is stored in a variable in the script.
>
> I know I can use os.system() or os.popen() to ru
Is it possible to execute a binary string stored within a python script
as executable code ?
The script is run under Windows, and the binary code (a full executable
file) is stored in a variable in the script.
I know I can use os.system() or os.popen() to run an external file, but
these functions
20 matches
Mail list logo
