correct me if I'm wrong, but I believe this is about marshalling.
Is there a way to access a class/obj directly from another .exe ?
Printable View
correct me if I'm wrong, but I believe this is about marshalling.
Is there a way to access a class/obj directly from another .exe ?
That's one of the things we have ActiveX EXEs for.
To identify an object in COM you could use a moniker. Regarding to VB6 you should enable unsafe marshaling as well (HKCU\Software\Microsoft\Visual Basic\6.0\AllowUnsafeObjectPassing)
All of the above applies to Std-EXE projects or private classes.
You can try PutObject function from this thread. This way one can use built-in GetObject to access a registered object from Std-EXE running as a seprate process.
cheers,
</wqw>
Keep helping to do things that can be used in malware without asking...
Yes, of course, but some things are much more indicative of malware use, IMO the OP shoudl be asked before receiving a suggestion in those cases.
Because the helper is in part responsible of the malware otherwise.
A car manufacturer can make a car that can be used to put a bomb. Yes... but if someone is buying TNT and a detonator, that's much more probable that it will be used in a bomb that if you are simply selling a car.
I didn't think that I had to explaing this.
I'm not saying that you should not help people, but in such cases (cases that are quite obvious that the OP might be making malware) before helping at least ask what he is doing and why he needs that. Common sense.
I know the OP from previous threads and there is nothing suspicous in this one too.
Mods here that can remove anything they found dangerous too.
cheers,
</wqw>
Frankly, I'm not terribly concerned about some1uke03...except for what his username means, of course.
Eduardo's comments did get me thinking though: Anybody could ask for anything. If they have been around long enough to establish a track record, that's usually a good sign, though there have been a few exceptions over the years. A new user asking such a question would be a bit of a red flag. We tend to challenge them, and they tend to leave, but aren't we really just filtering out those too dumb to cover their tracks? Not saying we shouldn't, just saying that there are layers to pretty nearly anything.
Yeah, you can never be sure who has been taken over by the Body Snatchers and who hasn't yet.
Now I'm curious about doing this too because I'd like to dig into some of the ListView and shell objects in Explorer to try to figure out some of the undocumented stuff I can't quite get to work in VB.
You know what some of the very first advanced questions I ever had about VB were... using calls like OpenProcess and ReadProcessMemory. Scary malware? No, I was a teenager making chatroom games and other utilities for AOL.
We shouldn't presume the worst of people and try to make certain techniques an exercise in gatekeeping. If there's something specific that indicates a user is working on malware, yeah obviously that should be shut down. But presuming it just because someone wants to use some particular calls that have any number of legitimate uses? Nah. You could maybe make a case for some gray areas where you'd want a little extra assurance you're not helping with malware, but that would be questions like evading AV software or asking about exploiting security vulnerabilities, not stuff like this.
I do not agree. In gray areas we should presume that it could be malware and ask what the subject is doing before helping.
And time in the forum guarantees nothing.
But I think I was already clear before.
Also, it is not the only thread.
There is a saying "do good without looking at who". Well, I completely disagree with that.
Do good looking at who.
In an actual gray area sure. But this isn't asking about how to execute arbitrary code using a buffer overflow, or silently escalate privileges above the current user... what a 'gray area' is should be reserved to situations where it's highly unlikely to have any use that's not malicious, and something like this doesn't even come close. And I looked back over this users posts, unless you're talking about something older than the 2 years I checked, everything else is even more innocuous and not even a tiny bit suspicious.
So if you access class objects of another exe you are not able to execute code or change things in the other process? That's new.
I'm not saying this user does malware because I don't know (and possibly not), what I say is that things like this need to be asked with an explanation.
I have other recent threads in mind in fact (of another user), but I don't want to make this issue bigger.
It isn't just about the OP, even when you believe the old chestnut "I just want to know how to crack passwords for my own education." Wink wink. There is also the matter of becoming a searchable repository of malware "recipes" to be used by all comers to create complete malware meals.
But more importantly there might be a less fragile and more sustainable "front door" solution if we knew the actual problem.
For example the product under attack here may only be offered for free in the form of a user program (EXE), but as a library there is a fee. And of course no programmer deserves compensation for his efforts and he's a filthy capitalist anyway if he wants money from me. Because, like, I'm a special snowflake. Mom always tells me so.
The question is 'Are the legitimate uses of this exceptionally unlikely, or is this commonly used for legitimate purposes.'
There's many reasons why you'd access the class objects of another exe, there's nothing inherently wrong with changing things in another process. Most of them aren't malicious. The uses that exist aren't something you'd only expect security researchers to use. Therefore, it's inappropriate to assume malware.
What I'm saying is the bar for accusing someone of being a malware author and saying they have to explain themselves if they want help needs to be a lot higher than what you're suggesting, which seems to be 'anything that involves doing anything to another process'.
And it's particularly unreasonable to question someone about being a malware author because someone else asked something actually suspicious.
dilettante's example of writing a password cracker is an example of something that's legitimately suspicious, because the vast majority of uses for it are malicious, and the legitimate use of a personal forgotten password uncommon and better addressed by existing tools.
I predict a lot of fun theorizing about how I could use the next questions you guys ask in malware :p :afrog:
Wow. This topic has stirred away quickly?
Guys relax. It's just a straightforward question. Don't assume the worst. It's not my 1st post!
I have an app that loads lots of files in Memory and rather doing it all in one app, i want to see if i can split it to two and share common classes to reduce memory, as I'm hitting the 2GB limit.
I don't see anything suspicious about accessing an object in a process. You can use it to IPC and it's very flexible/useful.
Reading/Writing/Hooking a process can be useful to monitor a process for memory leaks, debugging, etc.
Take a look at this.
You can just use a shared object between processes. Create an OBJREF moniker and pass it as a command line parameter. Use GetObject in the new process instance. There was the example where you can share an object betwee process and call the methods directly between processes.
Malware-writers long time ago don't use all those cheap "stuff" you guys wrote in this topic ^)