Jump to content

leecher

Member
  • Posts

    14
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Austria

Posts posted by leecher

  1. MSNP24 protocol is dead, unfortunately. So my MSN-Plugin for Miranda NG is also dead. From reversing the newer Skype 8 client, I know that only the web-based APIs are working. In fact, the new Skype-client is some Javascript Electron-blob wrapped in a windows-client now.

    Therefore I changed from MSN-plugin to SkypeWeb-plugin in Miranda and merged contacts via MetaContact. So I can keep using instant messaging via Skype (never needed voice call capability anyway).

  2. 50 minutes ago, Dibya said:

    I have no build environment . I use Hexeditor , modexp , Cffexplorer , pemaker , ida pro , my own relocation editor

    I would love to have a build environment.

    I think i have to wait until 2019 . That time i will have extremely compatibility . may be better than 7 and 8

    thanks

    There certainly is a problem with this approach. For example, I have a German version of Windows XP and I don't want the messages from kernel32.dll to become English. So the XomPie-Approach is better with a replacement DLL that forwards all function calls to the original DLL and just contains the newly added functions. This way, you don't break i.e. language compatibility.It is easy to accomplish.

    For patching internal functions in the target DLL it may be better to write a patcher so that language DLL can be kept and just gets a patched copy. If you need internal structures from the target System DLL that you are patching, you can use Symbol server to resolve them, I did this in NTVDMx64 loader for instance.

  3. 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?

  4. 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.

  5. On 1.1.2017 at 6:20 AM, Dibya said:

    any one know Hex CC is which op code like NOP is 90

    0xCC = INT 3

    So this initiates a Debug Break when in Debugger. That's why this opcode is usually used as a filler, because then you end up in debugger when program execution for whatever reason gets there, which shoudldn't be the case.

  6. On 26.11.2016 at 10:14 AM, Dibya said:

    anyone know in which name following nt dll function exist in kernel32 dll

    TpAllocCleanupGroup -> CreateThreadpoolCleanupGroup
    TpAllocIoCompletion ->  CreateThreadpoolIo
    TpAllocPool -> CreateThreadpool
    TpAllocTimer -> CreateThreadpoolTimer
    TpAllocWait -> CreateThreadpoolWait
    TpAllocWork -> CreateThreadpoolWork
    TpCallbackMayRunLong -> CallbackMayRunLong
    TpCaptureCaller -> Used internally in SetThreadAffinityMask with paramter 2
    TpQueryPoolStackInformation -> QueryThreadpoolStackInformation
    TpSetPoolMinThreads -> SetThreadpoolThreadMinimum
    TpSetPoolStackInformation -> SetThreadpoolStackInformation
    TpSimpleTryPost -> TrySubmitThreadpoolCallback

    ...

  7. 26 minutes ago, TuMaGoNx said:

    @leecher: thank you, if the redirection possible then the problem left is subsystem version check workaround?
    maybe how wine run executable can be used? when i used wine msi to workaround installer, i think wine may have pe loader (like mono/netCore) too (though not convenient to use)

    Hmn, you would need to patch BasepIsImageVersionOk() call in KERNEL32 for that... If you completely replace KERNEL32.DLL with your version (should work if you exclude kernel32.dll from SFP (http://www.rohitab.com/discuss/topic/27845-disable-windows-file-protection/) ),you could also replace this check, but that doesn't look like a clean solution. In my NTVDM x64 project, I used an additional DLL that gets loaded into every process and patches the NT loader according to my needs to re-enable startup of NTVDM on 64bit Windows, this would also be an option (see my sourcecode at https://github.com/leecher1337/ntvdmx64/blob/master/ntvdmpatch/src/ldntvdm/ldntvdm/ldntvdm.c), but maybe AppCompat wrapper DLL can do these patches too on load or something like that?

  8. 19 hours ago, TuMaGoNx said:

    Would you enlighten me how thing might works with AppCompat ? maybe a diagram

    Hi,

    I'm don't really know a lot about AppCompat Shim Engine myself yet, but in LdrpMapDll, there is some code referencing an AppCompat redirect, which in turn allows the application to setup a DLL redirection path for a library on load:

    typedef
    NTSTATUS (NTAPI *PLDR_APP_COMPAT_DLL_REDIRECTION_CALLBACK_FUNCTION)(
        IN ULONG Flags,
        IN PCWSTR DllName,
        IN PCWSTR DllPath OPTIONAL,
        IN OUT PULONG DllCharacteristics OPTIONAL,
        IN PVOID CallbackData,
        OUT PWSTR *EffectiveDllPath
        );
    
    NTSYSAPI
    NTSTATUS
    NTAPI
    LdrSetAppCompatDllRedirectionCallback(
        IN ULONG Flags,
        IN PLDR_APP_COMPAT_DLL_REDIRECTION_CALLBACK_FUNCTION CallbackFunction,
        IN PVOID CallbackData
        );

    I think documentation is quite clear, check DllName in callback, if it is one of our system DLLs that need redirection and if so, fill EffectiveDllPath pointer accordingly with pointer to memory allocated with RtlAllocateHeap, caller will free. As I didn't find any direct reference to this function, my assumption is that it is designed to be used by some Shim-DLLs in the Notify-Routine in order to setup redirection.

    I just thought I should point into that direction, maybe it is useful, as this method circumvents KnownDLLs check.

  9. On 12.10.2016 at 0:08 AM, TuMaGoNx said:

    BTW I think I'd abandon patchless idea.. hooksubsystem itself is hackish and might be restrictive, I can't use redirection manifest either as having another "kernel32.dll" often trigger DEP. Not to mention I get chicken-egg situation as my dll (the xp kernel32 part) is just forwarder not even wrapper, the redirection manifest would meant any dependencies (dll) would call the fake kernel instead of just the executable.

    What about AppCompat shims? I haven't reverse engineered the Windows XP Shim Engine yet, but some people attempted to do this and in my opinion it may be the "cleanest" way, as the compatibility settings for running applications in compatibility mode are also applied with the Shim Engine. So maybe we could do some research on it?

    This document sums up available documentation: https://www.blackhat.com/docs/eu-15/materials/eu-15-Pierce-Defending-Against-Malicious-Application-Compatibility-Shims-wp.pdf

    Just an idea...

×
×
  • Create New...