SilvioCesare
Bug in single stepping over a popf setting the trap flag
Posted June 4th, 2008 by SilvioCesareTitle of the post nearly sums it up. In win32, single stepping over a popf that sets the trap flag. The trap flag when examined using GetThreadContext reports the trap flag as being clear.
I tried for the first time installing OllyDbg today also, but Olly has no problem in detecting the trap flag as set. [...]
Single stepping through NtContinue, faking pushf, and trapping int1
Posted June 3rd, 2008 by SilvioCesareIn my bid to emulate win32 seh (in my emulator), I needed (to test my emulator) to single step through exception handling. My first approach was to just single step through the program by setting the trap flag in the eflags register. I had some problems with this.
One of the problems is single stepping through [...]
Fast string operations, Was x86 CPU bug in rep movsb
Posted May 23rd, 2008 by SilvioCesareUPDATE: This isn’t a bug after all. Aspect provided documtation of what is actually occuring.
It’s a feature since pentium pro computers to do ‘fast string’ or block operations. A block operation (eg, movb) of 64 bytes is performeed if ecx >= 64, if edi is aligned to 8 an byte boundary, and if esi and edi are not [...]
cpu bug, repne changes status flag in scasb
Posted May 21st, 2008 by SilvioCesareAnother CPU bug uncovered while testing my emulator. I came across a repne scasb while emulating the win32 version of upx. The logic of scasb (scan string), to paraphrase the intel manuals is
SRC = dereference(edi)
temp = al - SRC
SetStatusFlags(temp)
update_edi
In the code I ran across, %al was set to 0, the byte at (%edi) was 70 [...]
gdb leaves file descriptors open in debugee
Posted May 13th, 2008 by SilvioCesareI have my emulator running reasonably successfully on upx now. It’s actually an auto unpacker, and identifies when the program is unpacked by monitoring execution on previously written memory. In the process of emulating file io I came across a particular bug in gdb.
The file descriptor returned from an open call inside the debuggee, was [...]
CPU Bug x86 shl behaviour sets overflow flag
Posted May 9th, 2008 by SilvioCesareI’ve been writing an x86 emulator, and to debug it, I ran it on a p4 computer in parallel to a debugger on a target program (a upx packed binary). Well.. I got to shl $8, %eax where eax = 0×00ffffff.
The intel documentation says that the overflow flag is only changed for 1 bit shifts. Suprisingly, [...]
Merging basic blocks to deobfuscate non continugous control flow
Posted May 1st, 2008 by SilvioCesareIn some binaries, basic blocks may be connected only by jumps. These basic blocks may also be non contiguous in the file, ie scattered throught the binary.
In cases like this, if your looking at the disassembly, you need to constantly jump throught the image to have the logical order of the control flow. When the [...]
retn $0xhh consistency across function tails
Posted April 13th, 2008 by SilvioCesareSome procedures, following a calling convention simply return (ret), without modifying the stack pointer (they expect the caller to perform stack correction). In another call convention, procedures (callees) modify the stack using retn $0xhh.
Yesterday I made some changes to my disassembler, so that it would look at the stack correction in procedures. But there is a possibility of inconsistency when [...]
ClamAV.
Posted February 19th, 2008 by SilvioCesareI lied when I said I would write in a day the details of the ClamAV bug published by idefense last week.
ClamAV was acquired by Sourcefire, which is the software company that is responsible for the Snort IDS.
ClamAV code needs a fair amount of refactoring to be maintainable. The current sources are quite disturbing. I’m [...]
ClamAV.
Posted February 19th, 2008 by SilvioCesareI lied when I said I would write in a day the details of the ClamAV bug published by idefense last week.
ClamAV was acquired by Sourcefire, which is the software company that is responsible for the Snort IDS.
ClamAV code needs a fair amount of refactoring to be maintainable. The current sources are quite disturbing. I’m [...]
Recent comments
5 days 9 hours ago
5 days 20 hours ago
6 days 11 hours ago
6 days 18 hours ago
1 week 12 hours ago
1 week 12 hours ago
1 week 3 days ago
2 weeks 3 days ago
2 weeks 3 days ago
2 weeks 3 days ago