#1
|
|||
|
|||
Problem with Single-Step INT1 on Virtual PC XP Mode
Has anyone come across this message of single step INT1 just start occurring on a VM host machine? This behavior reminds me of how Olly1 acted under Wow64 with out the patch but this is XP Mode 32bit.
Olly2: Break on single-step trap or INT1 set by application - Shift+Run/Step to pass exception to the program. The exception can not be passed, options are enabled. Setting permanent system BP will now reach the entry point but the entry point will error as corrupt BP. App crashes whether Packed or Unpacked Olly1: Reaches entry point but can not pass along the exceptions. App crashes when packed but loads fine unpacked. Win 7 Pro 64 bit with the default VPC XP Mode vhd. The app shouldn't matter but I've been using my own PEC unpackme as a target. It crashes Olly 1&2 packed or unpacked like all other apps. Apps run fine without the debugger attached. So I restored a fresh image of XP Mode that is clean with no software installed. Downloaded a fresh copy of Olly and the same results. So I assume this is being caused by the host running the VM. I didn't change anything that I am aware of and running out of ideas. Any ideas on what would affect the virtual machine like this? Before I trash this Win 7 install thought maybe I'm just over looking something simple... Thanks |
#3
|
|||
|
|||
LOL Yeah I did try that also. x32_dbg will pass along the first exception but something else is still going on as the exe will crash. I could debug the same file or any other file before no problem under the VM.
The main difference between x32 loading up the process and Olly is that after the initial system BP, x32 will break at entry with INT3 like it should. Olly won't continue to the entry point from the system BP, instead it will loop with the INT1 message. When I change Olly to break on program entry, it will break at the entry point saying its using INT1 and then a message about the BP being corrupt modified blah blah blah. But this only works if I enable the permanent BP on system calls option. I don't use Olly2 very often but I don't remember having to enable that before. I did not change to use any other types of BP in the Olly options. No matter, the exe will still crash when any debugger is attached. It was all working fine the last time I booted up the VM. ??? I'm looking at the host system for anything else out of the ordinary. Getting to the point where it would be faster to pop in a new drive and install fresh. Cheers - jack |
#4
|
|||
|
|||
can you upload the application?
|
#5
|
|||
|
|||
Yeah sure, it's my own pec_unpackme. This happens on other protected files tho...
|
#6
|
|||
|
|||
I a not actually quite sure if i got you correctly or not.
when i run the program in vmware or vbox, it went fine. without plugins, it just keeps throwing memory violations which i am assuming due to detection of the debugger . unpacked file runs without a hitch. When i installed fresh virtualpc , it resulted similar as before(all went fine). Now , i manually set the trap flag by writing a small codecave and disabling "pass exception to application" . It reaches the exception and olly notifies me . Code:
pushfd pop eax or eax, 0x00000100 push eax popfd So my assumption about the failure to handle single steps is that somehow you messed up hardware virtualization support or something similar to it . Earlier versions of virtualpc for windows 7 didnt support software virtualization till they released a patch to enable it. if that is the case , you need to enable hardware virtualization to solve the issue probably. second case may be improper plugin settings. Let us know the result of this issue. Cpu used was i7 4770k . Last edited by Conquest; 12-18-2014 at 01:27. |
#7
|
|||
|
|||
Well... I'm picking up a new drive today. This gives me a reason to get something a little faster and bigger. I've had an SSD sitting here but was waiting till I cleared off the current drive to be used with the smaller SSD. If the problem is gone, I can keep the old drive around and examine it better offline. If anyone has run into this problem before, I'd still appreciate the reply.
BTW I was really tired and increasingly roasted when I replied... I should have included some further explanation and context. That is a simple unpackme/patchme for use of the watermark function of PEC in Delphi. If anyone is learning PEC it's written to be very simple, give it a try. By protected files, I meant files that throw similar anti-debug exceptions like PEC does. Before this started happening, I was looking at a target that uses more advanced plugins of PEC with some twist. When I noticed the same results were happening with my unpackme, I kept using the unpackme as the test app. I hashed the unpackme before posting it on another forum awhile back and the hash is valid. I'm 99.9% sure it's not the unpackme causing the problem but that .1% can be a PITA... LOL Cheers - jack Just seen the other reply. Sorry about that. Yeah I am thinking it's has to do with the drivers. I've looked for rogue drivers and nasties but nothing showing itself. The BIOS is unlocked but I have the VT set to stock. Also using an i7. Seen there was a bug with this cougar chipset but that feature is disabled in the BIOS. One item I didn't look at yet is I patched the terminal service to allow multi connections not too long ago. It shouldn't be related but I'll look at it. Thanks for looking into it. If I find what it is, I'll post the solution. Last edited by RedBlkJck; 12-18-2014 at 02:34. Reason: add on |
#8
|
|||
|
|||
Just some more details.
The stock BIOS supports VT out of the box. Alienware restricted a setting between BIOS updates that affected the video card detection. So I unlocked the BIOS to get access to those features again. That was a long time ago and the system has been stable. This is an Alienware M17xR3 with Intel Core i7-2670QM and Intel HM67 (Cougar Point) [B3] chipset. Hardware all seems to be running fine. Occasionally there is an event id about the power settings on the CPUx but from what I read this ok. All the other event id that are hardware related are from me causing it. I restored my terminal service patch and the result is the same. Perhaps a windows update has messed up something. I'll look into the specifics of what was updated two weeks ago. Not giving up but I'm moving on to a fresh install tonight. I can boot back up into that drive from the ext sata port. If it still happens on the new drive then I'll chalk it up to the hardware is starting to fail. Wouldn't be the first time some failing capacitor giving me days of misery... - jack |
The Following User Gave Reputation+1 to RedBlkJck For This Useful Post: | ||
#9
|
|||
|
|||
Well... I have something working but went another way about it.
I did some hardware testing and stripped the notebook apart for some much needed cleaning. It amazes me how dog/cat fur can reach places it should never be... Anyway the hardware testing and visual inspection all look good. Unfortunately after installing the new drives and clean Win 7 install I still got the same result as before. :\ So decided to try another VM. Removed Virtual PC and installed the free VMWare 7 Player. Using the same XP_Mode image from VPC and the problems are now gone. Olly aaand X32_dbg - both run smooth again. So I dunno what the problem is with VPC. Guessing a conflict with the Intel chipset driver or a MS update. VMWare player seems to be running XP Mode much faster. Guess I'll stick with it instead. Thx - jack |
#10
|
||||
|
||||
Try this plugin : http://waleedassar.blogspot.com/2012/03/ollydbg-v110-and-wow64.html
|
#11
|
|||
|
|||
Thanks for the reply Kurapica but the VPC image is 32bit XP and this was happening with other debuggers also. The problem seems very similar the trap flag issue of Olly v1 tho. Very odd and no problems running a debugger on the host.
It could be related to MS update kb2830477 but I have not tested. I just read about this update before the holidays and several people have reported problems with it and VPC. Currently I have put in a new hard drive for the host, installed clean OS and running VMWare without any problems. No plans to install VPC ever again. VMWare is running XP so much faster. I still have the drive with the old install. Next time I need to boot up into that system, I'll check if that KB was causing the problem. If success I'll post back. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
How to pass the large data in kernel mode to user mode? | benina | General Discussion | 3 | 03-06-2010 04:50 |
reversing step by step | MrHyde | General Discussion | 1 | 11-04-2003 21:41 |