after reading the topic "patching system dll" on this forum and
other web pages about patching, i had the idea that patching IE
would be possible.

in firefox, tabs load in the background

in IE new windows load instantly and are set as your active
window. i usually load several pages to load in the background
and its annoying to keep switching back to the original window.

i thought about patching IE so that a new window DOESN'T set the
active window. i set breakpoints in OllyDbg for the window functions like
SetForegroundWindow, SetWindowPos, CreateWindowEx, ShowWindow

anyway, i dont recommend anyone try this.

in SHDOCVW.DLL which is the web page rendering control (IE and explorer.exe use this, so be careful) there are calls to SetForegroundWindow
etc



i replaced those 2 instructions with 7 NOPs to keep the alignment,
patched the DLL and rebooted.

now IE or explorer.exe wont load, and an access violation occurs.
using OllyDbg to debug it, its setting memory which it doesnt have.

but i cant understand why it does this, as i only blocked a call to
SetForegroundWindow. i have restored the original system DLL's again
and everything is back to normal.

does anyone have any ideas ? or experience in patching IE ?

I have no experience with patching IE. But one thing you might like to check is if 0x777d3674 is a destination from a jump. Keep the existing PUSH EAX at 0777d3673 and put POP EAX and 5 NOP's at 0x777d3674.

How does that help - wouldn't it mess up the stack. I think that the pop eax is already somewhere.

I think a better way would be to jump over the call and let the call remain there (0777D3674h). Otherwise calls or jumps to that address would pop an unknown variable from the stack and mess something up.

Of course its hard to tell what to do with only two lines visible, but disabling SetForeground doesn't help. The problem lies somewhere deeper.

i think it would be better to look at it with our own eyes, but not to try to guess what's happening there...
wisepenguin, could you provide us with the following information:
- OS Ver and IE ver
- disassembly listing of some problem places that confused you
- your workflow (not to spend hours trying to do what's done by you already)

then we could try to figure out what's happening there.
I can guess two possible variants:
a) incorrect checksum
b) addresses that you nopped may be called from other places (but this would be seen in debugger)

thankyou all for your replies.

i will try again later today, a few different methods.

first will be to add a random character to the end of the proper
file. if it crashes then i know its the checksum thats wrong. but i dont
know how to fix that.

if thats works, then i will change push eax to push ebx, which (hopefully)
should _most_ of the time effectively disable the SetForegroundWindow
call as the chances of a valid window handle being the value of ebx
are slim.

i will provide more in depth information later as i got to rush off now,
but quickly

OS: Win XP SP2
IE ver: default built into XP SP2 ( IE.6.0.2900.2180)
SHDOCVW.DLL (6.0.2900.2180)

the 2 assembly listings in the original post are from SHDOCVW.DLL

I just thought that really wonderful solution would be not to make IE load pages in background, but to add tabs to IE and load pages in tabs as all good browsers do. If MS guys cannot do this, then we can!

The PUSH EAX is the input parameter for the API call, when the API returns is restores the stack. So, if we stop the API call then we have to manually restore the stack with POP EAX.

zhak: IE 7 has tabs.