lubricy / pyemu Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/pyemu
Automatically exported from code.google.com/p/pyemu
What steps will reproduce the problem?
++++++++++++++++++++++++++++++++++++++
1. Try to emulate a binary containing a lodsd assembly instruction (I packed a
"Hello, World!" program with UPX and the packed image contained a lodsd
instruction (BTW, I guess the last detail is not pertinent). See attached
binary hello_upx_packed.exe.
2. See step 1.
3. See Step 2.
What is the expected output? What do you see instead?
+++++++++++++++++++++++++++++++++++++++++++++++++++++
I expect emulation to do just fine. Instead, I get the error (missing feature
?):
[!] Unsupported instruction lodsd
What version of the product are you using? On what operating system?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm using the latest version (I've found no version info about pyemu, on the
net, or in the source), running on Windows 7 Starter Edition.
Please provide any additional information below.
++++++++++++++++++++++++++++++++++++++++++++++++
See attached binary hello_upx_packed.exe.
Original issue reported on code.google.com by [email protected]
on 6 Feb 2012 at 10:08
Attachments:
[*] Executing [0x409faf][33] xor eax,eax
[*] Trying to get memory @ 409fb1
[*] Trying to get memory @ 409fb1
[*] Executing [0x409fb1][a3] mov [0x4aa9f4],eax
[!] Please add this segment
Original issue reported on code.google.com by [email protected]
on 13 Feb 2010 at 9:10
What steps will reproduce the problem?
just, watch this. eax is incorrect.
eax=00000001 ebx=00000003 ecx=00000200 edx=00000004 esi=00000300 edi=00000006
eip=004001ef esp=0095e800 ebp=00000100 iopl=00
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 eflags=[]
004001ef lea eax,[esi+ecx-0x1]
[*] Executing [0x4001ef][8d] lea eax,[esi+ecx-0x1]
eax=000005ff ebx=00000003 ecx=00000200 edx=00000004 esi=00000300 edi=00000006
eip=004001f3 esp=0095e800 ebp=00000100 iopl=00
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 eflags=[]
What is the expected output? What do you see instead?
: eax should be 0x4ff instead of 0x5ff. because 8bit displacement of LEA
instruction is treated like unsigned 8bit. 0xFF is not subtracting 1 instead
its adding 255.
this makes the incorrect behavior of some of the lea instrustions.
What version of the product are you using? On what operating system?
: latest from here. https://github.com/codypierce/pyemu
Please provide any additional information below.
additionally, PyMemory.py is missing from https://github.com/codypierce/pyemu
Original issue reported on code.google.com by [email protected]
on 29 May 2015 at 5:30
What steps will reproduce the problem?
1. Execute file that has XOR instruction with opcode 0x32
2. PyCPU.XOR(...) returns False
Attached is a patch that implements the instruction. Needs tests, though.
Original issue reported on code.google.com by [email protected]
on 9 May 2011 at 8:21
Attachments:
I got an error when running pydbgpyemu.py in the examples.
The error output is as below:
E:\pydbgpyemu.py calc.exe 0x001001AF3
[*] Trying to attach to existing calc.exe
[*] Attaching to calc.exe (1352)
[*] First bp hit setting emu address @ 001001af3
Traceback (most recent call last):
File "E:\pydbgpyemu.py", line 129, in <module>
dbg.debug_event_loop()
File "C:\Python25\Lib\site-packages\pydbg\pydbg_core.py", line 335, in
debug_event_loop
self.debug_event_iteration()
File "C:\Python25\Lib\site-packages\pydbg\pydbg_core.py", line 283, in
debug_event_iteration
continue_status = self.exception_handler_breakpoint()
File "C:\Python25\Lib\site-packages\pydbg\pydbg.py", line 1074, in
exception_handler_breakpoint
continue_status = self.breakpoints[self.exception_address].handler(self)
File "E:\pydbgpyemu.py", line 54, in handler_emu_breakpoint
print "%x %x" % (dbg.context.SegFs, dbg.tebs[dbg.dbg.dwThreadId])
AttributeError: 'pydbg' object has no attribute 'tebs'
Original issue reported on code.google.com by [email protected]
on 31 Jan 2010 at 3:18
What steps will reproduce the problem?
1. jno instruction in the asm code
2.
3.
What is the expected output? What do you see instead?
should be able to take a jump
What version of the product are you using? On what operating system?
windows xp
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 12 Apr 2014 at 2:50
What steps will reproduce the problem?
1. just see the def sar(self, instruction) func in the pycpu.py
2. search "result = result / 2"
3. just result = 0xFFFFFFF5
What is the expected output? What do you see instead?
if i use c language 0xFFFFFFF5 >> 1 is FFFFFFFA
but use python2.5/2.7 the result is 7FFFFFFA
What version of the product are you using? On what operating system?
python2.5 win7
Please provide any additional information below.
i think the FFFFFFFA result is my want? why python got 7FFFFFFA?
Original issue reported on code.google.com by [email protected]
on 23 Nov 2012 at 2:12
the http://code.google.com/p/pefile/ changed it Section class, in a way that
the "data" properties doesn't exist anymore.
Original issue reported on code.google.com by [email protected]
on 12 Jul 2012 at 8:38
I might be misinterpreting, but it appears as if this regular expression is
malformed.
Additionally, you are re.compile-ing each expression every time it's evaluated
-- and it evaluates (and thus *compiles*) all of them until one is matched
(!!!!).
It would be a good idea to move the compiled statements (results of re.compile)
to a property/member, so that it is only compiled once.
Eg;
exprExX = re.compile(..., re.IGNORECASE)
...
if exprExX.match(register): # eax/ebx/ecx/edx
# ...
Original issue reported on code.google.com by [email protected]
on 15 Sep 2011 at 3:33
Attachments:
What steps will reproduce the problem?
1. run the example idapyemu_return_value.py example
2. run any code that calls emu.set_mnemonic_handlers() s.t. handler function
does not take 6 arguments.
3.
What is the expected output? What do you see instead?
I expect to see return value (i.e. EAX). But it exits with the following output:
---------------------------------------------------------------------------
[*] Loading text section bytes into memory
[*] Text section loaded into memory
[*] Loading data section bytes into memory
[*] Data section loaded into memory
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Program Files\IDA\python\init.py", line 65, in runscript
execfile(script, g)
File "C:/pyemu/examples/idapyemu_return_value.py", line 71, in <module>
if not emu.execute():
File "C:\PyEmu\PyEmu.py", line 163, in execute
if not self.cpu.execute():
File "C:\PyEmu\PyCPU.py", line 1385, in execute
if not self.supported_instructions[pyinstruction.mnemonic](pyinstruction):
File "C:\PyEmu\PyCPU.py", line 149, in <lambda>
"ret": lambda instruction: self.RET(instruction),
File "C:\PyEmu\PyCPU.py", line 9605, in RET
self.emu.mnemonic_handlers[mnemonic](self.emu, mnemonic, self.get_register32("EIP"), op1value, op2value, op3value)
TypeError: my_ret_handler() takes exactly 2 arguments (6 given)
=====================================================
What version of the product are you using? On what operating system?
pyemu 0.0.2 on windows xp prof.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 3 Sep 2010 at 9:36
What steps will reproduce the problem?
1. Execute the following Assembly line:
mov ebx, DWORD PTR SS:[EBP-14]
The negative Number -4 will be stored as 0xffffffec in op.displacement and just
added to address which will result in an address higher then 2**32.
I am using the current svn source tree.
FIX (works for me):
545a546,547
> if value == False:
> print "failed to read from %x, len: %d"%(address,size)
1503a1506
> address = address & 0xffffffff
1506a1510,1512
> print "Address: 0x%x"%address
> print "op.basereg: 0x%x"%op.basereg
> print "op.displacement: 0x%x"%op.displacement
1564c1570
<
---
> address = address & 0xffffffff
1704c1710
<
---
> address = address & 0xffffffff
1706a1713,1715
> print "Address: 0x%x"%address
> print "op.basereg: 0x%x"%op.basereg
> print "op.displacement: 0x%x"%op.displacement
1764c1773
<
---
> address = address & 0xffffffff
Be advised that the error is possibly also located in other instructions using
offsets.
Original issue reported on code.google.com by [email protected]
on 8 Jan 2011 at 9:44
class PyCPU:
...
def AND(self, instruction):
...
# <<< added by forc1
#22 /r AND r8,r/m8 r8 r/m8
elif instruction.opcode == 0x22:
osize = 1
op1value = self.get_register(op1.reg, osize)
if op2.type == pydasm.OPERAND_TYPE_REGISTER:
op2value = self.get_register(op2.reg, osize)
# Do logic
result = op1value & op2value
self.set_flags("LOGIC", op1value, op2value, result, osize)
self.set_register(op1.reg, result, osize)
elif op2.type == pydasm.OPERAND_TYPE_MEMORY:
op2value = self.get_memory_address(instruction, 2, asize)
op2valuederef = self.get_memory(op2value, osize)
# Do logic
result = op1value & op2valuederef
self.set_flags("LOGIC", op1value, op2valuederef, result, osize)
self.set_register(op1.reg, result, osize)
opcode = instruction.opcode
if opcode in self.emu.opcode_handlers:
if op1valuederef != None and op2valuederef == None:
self.emu.opcode_handlers[opcode](self.emu, opcode, self.get_register32("EIP"), op1valuederef, op2value, op3value)
elif op2valuederef != None and op1valuederef == None:
self.emu.opcode_handlers[opcode](self.emu, opcode, self.get_register32("EIP"), op1value, op2valuederef, op3value)
else:
self.emu.opcode_handlers[opcode](self.emu, opcode, self.get_register32("EIP"), op1value, op2value, op3value)
# >>>
...
def SBB(self, instruction):
...
# <<< added by forc1
#1a /r SBB r8,r/m8 Subtract with borrow r/m8 from r8
elif instruction.opcode == 0x1a:
osize = 1
op1value = self.get_register(op1.reg, osize)
if op2.type == pydasm.OPERAND_TYPE_REGISTER:
op2value = self.get_register(op2.reg, osize)
# Do logic
result = op1value - (op2value + self.CF)
oldcf = self.CF
self.set_flags("SBB", op1value, op2value + self.CF, result, osize)
if oldcf == 0:
self.CF = oldcf
self.set_register(op1.reg, result, osize)
elif op2.type == pydasm.OPERAND_TYPE_MEMORY:
op2value = self.get_memory_address(instruction, 2, asize)
# Do logic
op2valuederef = self.get_memory(op2value, osize)
result = op1value - (op2valuederef + self.CF)
oldcf = self.CF
self.set_flags("SBB", op1value, op2valuederef + self.CF, result, osize)
if oldcf == 0:
self.CF = oldcf
result = self.sanitize_value(result, osize)
self.set_register(op1.reg, result, osize)
opcode = instruction.opcode
if opcode in self.emu.opcode_handlers:
if op1valuederef != None and op2valuederef == None:
self.emu.opcode_handlers[opcode](self.emu, opcode, self.get_register32("EIP"), op1valuederef, op2value, op3value)
elif op2valuederef != None and op1valuederef == None:
self.emu.opcode_handlers[opcode](self.emu, opcode, self.get_register32("EIP"), op1value, op2valuederef, op3value)
else:
self.emu.opcode_handlers[opcode](self.emu, opcode, self.get_register32("EIP"), op1value, op2value, op3value)
# >>>
...
#1B /r SBB r16,r/m16 Subtract with borrow r/m16 from r16
#1B /r SBB r32,r/m32 Subtract with borrow r/m32 from r32
elif instruction.opcode == 0x1b:
...
elif op2.type == pydasm.OPERAND_TYPE_MEMORY:
op2value = self.get_memory_address(instruction, 2, asize)
# <<< fixed by forc1
# Do logic
#op1valuederef = self.get_memory(op1value, osize)
op2valuederef = self.get_memory(op2value, osize)
#result = op1valuederef - (op2value + self.CF)
result = op1value - (op2valuederef + self.CF)
oldcf = self.CF
#self.set_flags("SBB", op1valuederef, op2value + self.CF, result, osize)
self.set_flags("SBB", op1value, op2valuederef + self.CF, result, osize)
if oldcf == 0:
self.CF = oldcf
result = self.sanitize_value(result, osize)
#self.set_memory(op1value, result, osize)
self.set_register(op1.reg, result, osize)
# >>>
...
Original issue reported on code.google.com by [email protected]
on 27 Oct 2010 at 7:15
[*] Executing [0x73c57b][9c] pushf
[!] Unsupported instruction pushf
Original issue reported on code.google.com by [email protected]
on 13 Feb 2010 at 8:54
What steps will reproduce the problem?
1. Try executing a function that does not use EBP and has an rep stosd. All the
rep stosd is doing is zeroing memory. I've tried uping the debug level to three
but no error or reason for halting execution is given.
What is the expected output? What do you see instead?
The emulator should execute past the REP STOSD. For some reason the emulator
stops execution as a result of this instruction.
I'm running a very basic IDAPyEmu program that simply tries to execute the
function.
What version of the product are you using? On what operating system?
revision 19, windows xp sp3, ida 5.6
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 24 Oct 2011 at 1:40
is this code usable - or this code is only for non linux ?
programming in python isn't complicated - but so trivial bug ? (one from)
Tia,
m32
diff /devel/python/pyemu/PyEmu.py ./PyEmu.py
809c809
< self.os.initialize(self.stack_base, self.stack_base -
self.stack_size, self.heap_base, self.heap_base + self.heap_size)
---
> self.os.initialize(self, self.stack_base, self.stack_base -
self.stack_size, self.heap_base, self.heap_base + self.heap_size)
879c879
< self.os.initialize(self.stack_base, self.stack_base -
self.stack_size, self.heap_base, self.heap_base + self.heap_size)
---
> self.os.initialize(self, self.stack_base, self.stack_base -
self.stack_size, self.heap_base, self.heap_base + self.heap_size)
Original issue reported on code.google.com by [email protected]
on 23 Jul 2009 at 2:20
PyCPU lacks support for the 0x2 ADD instruction, resulting in execute() to
fail for asm commands like:
add al, byte-ptr[edi+edx]
Adding the following lines to def ADD(self, instruction) in PyCPU.py fixed
the issue for me:
#02 r8 ADD r/m8 Add r/m8 to r8
elif instruction.opcode == 0x02:
osize = 1
op1value = self.get_register(op1.reg, osize)
if op2.type == pydasm.OPERAND_TYPE_REGISTER:
op2value = self.get_register(op2.reg, osize)
# Do logic
result = op1value + op2value
self.set_flags("ADD", op1value, op2value, result, osize)
result = self.sanitize_value(result, osize)
self.set_register(op1.reg, result, osize)
elif op2.type == pydasm.OPERAND_TYPE_MEMORY:
op2value = self.get_memory_address(instruction, 1, asize)
# Do logic
op2valuederef = self.get_memory(op2value, osize)
result = op1value + op2valuederef
self.set_flags("ADD", op1value, op2valuederef, result,
osize)
result = self.sanitize_value(result, osize)
self.set_register(op1.reg, result, osize)
Original issue reported on code.google.com by [email protected]
on 24 May 2010 at 5:32
Attached diff addresses this:
1. 3 new instructions JP, JNP, JPO.
2. ROR instruction was not working "correctly".
Now it behaves not exactly as the documentation says.
If you look at what the doc says.
(* ROR instruction operation *)
IF tempCOUNT > 0) (* Prevent updates to CF *)
WHILE (tempCOUNT ≠ 0)
DO
tempCF ← LSB(SRC);
DEST ← (DEST / 2) + (tempCF ∗ 2^SIZE);
tempCOUNT ← tempCOUNT – 1;
OD;
ELIHW;
CF ← MSB(DEST);
IF COUNT = 1
THEN OF ← MSB(DEST) XOR MSB − 1(DEST);
ELSE OF is undefined;
FI;
FI;
This
DEST ← (DEST / 2) + (tempCF ∗ 2^SIZE);
does not really make sense to me as (tempCF * 2^SIZE) is always zero.
So I change it so it does tempCF * 2^(SIZE-1). That way the PyEmu
produces the same result as the real CPU.
3. PyLinux was not initialized properly.
4. Few little thing live wrong variable name etc. in TEST, MOVZX, MOVSX.
(Actually, it looks like libdasm in the repository does not disassemble
MOVZX properly, the fix was submitted to http://code.google.com/p/libdasm/)
Here is the issues I bumped into but did not address them in any way.
1. PyEmu.dump_register may result into infinite recursion as
PyEmu.raise_exception uses
PyEmu.dump_register. And PyEmu.dump_register may cause a call to raise
exception.
2. While trying to manipulate the memory at high address (greater then
0x80000000) i got
OverflowError: long int too large to convert to int
in PyMemory.py. Apparently, pages list index is to big for xrange or
something. I guess it can be fixed by using only 20 bits integers for those
indexes, first 12 bits are all zero anyhow.
I saw it only on 32-bit system, on 64-bit system did not see anything like
that.
Original issue reported on code.google.com by [email protected]
on 15 Jun 2009 at 2:14
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.