![]() |
Quote:
- having the software create a memory space for you. You then dump your code you want to run into that memory pool. You suspend the app, redirect it's EIP to the start of your code, ensure your code 'calls back' to where the app originally was when it's done, delete the memory pool it created for you, and you leave no footprints behind of what happened/who was there :yep: - This is Window's biggest flaw: just because an app needs to use 'system' DLLs doesn't mean you can't intercept them. You can do it quite easily too. Windows first looks for any DLLs the file calls for in the local folder the app was started from. So if you make a DLL that has the same name as the DLL it's looking for it will load your DLL. You in turn have to ensure your DLL maps all the functions that the app needs. Then when the app calls out for a function in the DLL control is handed over to your DLL, you decide what you want to do with it, then call the original DLL passing the same parameters it passed you. The system and the app have no idea that you hijacked a DLL of it or that you may of intercepted some data that wasn't meant to be 'seen'. I don't care how secure you think any piece of software is, it's not if it's running on Windows. Even if you inline every function call the app is still susceptible to 'detouring'. If you try and be sneaky and create another thread that tried to monitor something like this (by using a watchdog timer or the likes) I can suspend that thread too. You can't win in Windows. If there's some data that someone wants and they have the knowledge they will get it. There are many other ways you can exploit software. Windows just makes it very easy to do :D You can call it DLL injection, code injection, whatever. As one does not physically modify a binary image there's no law being broken. There is also no evidence left behind saying how the code got into the app in memory. Besides the app did it for you and it did it without any complaints. What a bargain :yeah: There are those that use these methods for malicious intents (worms, trojans, etc.). I am just naturally curious and do it just to see if I can. I especially like dumping PE headers just to see if the app in question is using any of the crypto classes. If it is well it's game on. I just gotta know what they are trying to hide. It's like a game. A game where it's hard not to always win. |
Ja, I know.... :)
|
no need DLL inject, just rename your dll file to *.act
no need DLL inject, just rename your dll file to *.act
|
Sorry TDW this post is just to let you know that links in post #1 aren't working anymore...could you provide new ones?
Thanks in advance!:salute: |
Quote:
|
Quote:
|
Sorry for this necro-quote/post but i was wondering ...
Quote:
Quote:
This tool translate pure, but implicitly statically typed Python (2.4-2.6) programs into optimized C++ ( and dll if i'm correct ) Can we use this to improve the horrendous loading time and cpu usage of SHV ? Is such a feat possible, if so where do I begin ? |
All times are GMT -5. The time now is 08:46 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © 1995- 2025 Subsim®
"Subsim" is a registered trademark, all rights reserved.