Jump to content


TuMaGoNx

Recommended Posts

2 hours ago, TuMaGoNx said:

Hi dibya (got your greeting mail)
I'm not really motivated and disappointed with disadvantage of XomPie from requiring patch, neither have enthusiasm for OneCore as it need system modification (and thus security implication).

will you continue ? I love your idea . It is posready update friendly .

ExtendedXP is no more my own project . FranceBB , who is really my good friend is going to make ExtendedXP more better .

Both of us will maintain the project .

Link to comment
Share on other sites


4 hours ago, TuMaGoNx said:

I'm not really motivated and disappointed with disadvantage of XomPie from requiring patch, neither have enthusiasm for OneCore as it need system modification (and thus security implication).

I played around a bit with some loader code that I wrote which tries to patch the imports on loading in memory, but got stuck with it as loader modification needs to take place in the context of the target appliation as soon as it is loaded into memory, as IAT lookup etc. is running in its context, not in the context of the executing application...

Anyway, would it be benifical if you could load an application with xompie by executing it via a seperate application that loads the target into memory and patches the imports accordingly so that it uses your wrapper DLLs for functions that are unavailable in original DLLs?
I can share what I got so far, if you are interested, even though it's not working yet.

Link to comment
Share on other sites

9 hours ago, Dibya said:

can you make a wrapper ? Please

Not sure what you mean by it.. This is a kernel function exported from ntoskrnl for drivers, so it is ring 0 code. To run it, one could implement an export driver containing the code (https://msdn.microsoft.com/en-us/library/windows/hardware/ff542891(v=vs.85).aspx), but still, how do you get your driver that depends on this function being exported from ntoskrnl.exe to load the function from the "wrapper" driver that implements it? Would you patch the IAT of the requiring driver to point to the export driver?

Link to comment
Share on other sites

59 minutes ago, leecher said:

Not sure what you mean by it.. This is a kernel function exported from ntoskrnl for drivers, so it is ring 0 code. To run it, one could implement an export driver containing the code (https://msdn.microsoft.com/en-us/library/windows/hardware/ff542891(v=vs.85).aspx), but still, how do you get your driver that depends on this function being exported from ntoskrnl.exe to load the function from the "wrapper" driver that implements it? Would you patch the IAT of the requiring driver to point to the export driver?

Okay . It is easier for me to put the function inside ntoskrnl

Link to comment
Share on other sites

@leecher
I have played with deviare (of the similar principle) before and think of that kind pe loader either via autonamed loader at same directory of target or via target's image debugger registry hook. assuming that it works, it seems impose quirks at some cases such:
how it handle chained calls/piping for other PE (commonly in commandline apps)?
how to deal with service app?
if the target is the one renamed there also minor consequences

but I'm not digging that deep because of those flaws ahead, sure I'd like to see your works!

Link to comment
Share on other sites

20 hours ago, leecher said:

Not sure what you mean by it.. This is a kernel function exported from ntoskrnl for drivers, so it is ring 0 code. To run it, one could implement an export driver containing the code (https://msdn.microsoft.com/en-us/library/windows/hardware/ff542891(v=vs.85).aspx), but still, how do you get your driver that depends on this function being exported from ntoskrnl.exe to load the function from the "wrapper" driver that implements it? Would you patch the IAT of the requiring driver to point to the export driver?

I will patch import no problem . I am really getting into dark for none . My head is crashing when trying to put the function. Please leecher make the wrapper for me .

I am trying to back port WindowsServer2003-KB919117-x86-ENU & WindowsServer2003-KB929161-x86-ENU. This two can make XP fully compatible with GPT and Bigger Disk drives also it will improve cluster driver aka disk manager .

@TuMaGoNx

It will be great to have xompie for drivers , patch and play .

Link to comment
Share on other sites

Leecher it is working flawlessly . I have replaced patched system files from my 7 32bit partition then booted to XP . It worked System is running also detected 4TB WD GPT Partition with out paragon . Releasing Today only . Running few tests let see how it goes .

THanks for Help .

Link to comment
Share on other sites

  • 3 months later...

I might polish XomPie, (installer, makefiles...) but no further feature plus removing half-baked functions.
Other note: UI related library is hardest one (shell32.dll) it unlikely reliable to bridge from older OS unless the shell (explorer.exe) itself get upgraded...
Regarding Wine: the more you take from there the more it become incompatible with original XP system files --> the more you will replace everything with wine... silly
the less you take from wine.. ummm the more works to be done doh.. sometime approach like func_new(a,b) -> func_old(a) is enough but often unreliable

Link to comment
Share on other sites

  • 2 weeks later...

add getuserpreferreduilanguages dummy, needed by autodesk meshmixer 3 which planned (or already) to be merged to 123d design (which also need this but untested). fix typo in perfile patcher
BTW, XP marketshare is plummeted by FUD lol
 

EDIT:

reup installer :missing xpvcrt.dll

clarify which freeware

xompie-0.5a.exe

Edited by TuMaGoNx
Link to comment
Share on other sites

  • 2 weeks later...

Looks like FreeRDP developer already did what I try to do:
https://github.com/FreeRDP/FreeRDP/tree/master/winpr/libwinpr

cool, might integrate it into xompie

Edited by TuMaGoNx
Link to comment
Share on other sites

  • 3 weeks later...

@Dibya Sorry haven't check nvme yet but here is new xompie

version 0.6a
xpatcher:
- selective patch
- always patch with bigmem LAA
- show immediate dependencies
added updater
added wine direct3d and direct2d based on wine 2.11

wined3d has not tested by myself, I decide to add it as svyatpro said it become more usable now. I've sent a build to him and he said it works (I assume tested against one-core dll) this one however for use with XomPie with exception gdi32.dll is from one-core. I hope this also works!

This version become so big (768KB) that I move it to github now

https://github.com/tumagonx/XomPie/releases/download/v0.6-alpha/xompie-0.6a.exe

Link to comment
Share on other sites

6 hours ago, TuMaGoNx said:

@Dibya Sorry haven't check nvme yet but here is new xompie

version 0.6a
xpatcher:
- selective patch
- always patch with bigmem LAA
- show immediate dependencies
added updater
added wine direct3d and direct2d based on wine 2.11

wined3d has not tested by myself, I decide to add it as svyatpro said it become more usable now. I've sent a build to him and he said it works (I assume tested against one-core dll) this one however for use with XomPie with exception gdi32.dll is from one-core. I hope this also works!

This version become so big (768KB) that I move it to github now

https://github.com/tumagonx/XomPie/releases/download/v0.6-alpha/xompie-0.6a.exe

already patched palemoon 27.2 unstable was working but now crashed before showing UI.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...