[General] CLR hosting without the dll?

[serock1]

Huh? The first two sentences in your post make zero sense.

Anyway... It's explained why it's dangerous (loader locks), and the solution is given to you (in the DLL best practices document). Wanna know the solution? Follow the rules and don't use APIs in DllMain which you are recommended not to!

Just export a function from your DLL and do your work there. It's not hard...

P.S. Read the first sentence of the article you linked:
"Let me get this out of the way up front: Creating a thread from DllMain is not recommended. "

That should be enough for you to NOT DO IT.

This forum is for hack, isnt it? Why pedantic attention to detail or rules?

I dont recommend some1 to use it, I just want to talk about why if we should not use it. Also, if some1 really know what he/she do, it is fine to use it.

If my words offended your programming/software developing sense. Excuse me please.

[_Mike]

however if you could get around fixing the 64 bit thing it would be nice because i've already run into the first problems with it

What kind of problems?
I do plan on supporting 64bit eventually but it's not a high priority at the moment. Mainly because it's not needed for the things I use it for.
You could try fixing it yourself. I haven't really looked at what's needed, so I'm just assuming here..
But the only major things would be the assembler code* and there are a few pointer-to-dword casts.
I'm not allowed to install winrar on this stupid work computer so I can't look at the code right now

*) 32->64bit register usage mainly, and possibly the memory read/writes. The general logic of the code flow should be the same as 32bit I think, dunno if the 64bit CLR requires anything extra.

This forum is for hack, isnt it? Why pedantic attention to detail or rules?

I dont recommend some1 to use it, I just want to talk about why if we should not use it. Also, if some1 really know what he/she do, it is fine to use it.

If my words offended your programming/software developing sense. Excuse me please.

Not following api guidelines might be okey if you don't care about compatibility.
Something that works today might not work with the next patch/service pack/windows version if you don't play by the rules.

[serock1]

What kind of problems?
I do plan on supporting 64bit eventually but it's not a high priority at the moment. Mainly because it's not needed for the things I use it for.
You could try fixing it yourself. I haven't really looked at what's needed, so I'm just assuming here..
But the only major things would be the assembler code* and there are a few pointer-to-dword casts.
I'm not allowed to install winrar on this stupid work computer so I can't look at the code right now

*) 32->64bit register usage mainly, and possibly the memory read/writes. The general logic of the code flow should be the same as 32bit I think, dunno if the 64bit CLR requires anything extra.



Not following api guidelines might be okey if you don't care about compatibility.
Something that works today might not work with the next patch/service pack/windows version if you don't play by the rules.

Last, I want to say,

1. Everyone knows 'should not' do not mean 'must not'. If you know what you do, just do it, ofc, at your own risk.
2. Compatibility is just a dream. We think about it, but why use it to shackle ourself? I dont think even Unix/Linux/Windows can guarantee their compatibility as software.
3. I dont want to represent something against mainstream theory. Also, I think about this kind of problem for my software developing job. But here, we are just developing something to hack WoW.exe (or bin in mac). Why think about so much? If we know WHY and HOW, then just need think about how to let the stuff work.

I must stop talking about off-topic. And I am sorry for it. :P

[Cypher]

This forum is for hack, isnt it? Why pedantic attention to detail or rules?

I dont recommend some1 to use it, I just want to talk about why if we should not use it. Also, if some1 really know what he/she do, it is fine to use it.

If my words offended your programming/software developing sense. Excuse me please.

Why do things the 'wrong way' when there is no good reason? Playing by the rules in this case affords you a more stable and forwards compatible code base. What does risking a deadlock in this case get you? Nothing.

Yes, you 'get away with it' under the right circumstances, but why do it? Just export a function and call it. As far as I can see it's all gain and no loss.

Last, I want to say,

1. Everyone knows 'should not' do not mean 'must not'. If you know what you do, just do it, ofc, at your own risk.
2. Compatibility is just a dream. We think about it, but why use it to shackle ourself? I dont think even Unix/Linux/Windows can guarantee their compatibility as software.
3. I dont want to represent something against mainstream theory. Also, I think about this kind of problem for my software developing job. But here, we are just developing something to hack WoW.exe (or bin in mac). Why think about so much? If we know WHY and HOW, then just need think about how to let the stuff work.

I must stop talking about off-topic. And I am sorry for it. :P

1. Except in this case there is no reason to not play by the rules... Why do something unnecessarily dangerous for zero gain other than avoiding exporting a function and calling it (a half dozen lines of code).

2. A dream? How is it that I can take a piece of (well written) software for Windows 98 and run it on my Windows 7 machine? Surely I must be dreaming!

Microsoft go to GREAT lengths to try to ensure both backwards and forwards compatibility for software running on their operating system.

Unix/Linux applies less in this case in my experience, but my experience is definitely lacking in this area, so I'm not going to pass judgement either way. Both approaches have their advantages and disadvantages.

3. Because that is what makes us good programmers. Yes, we're writing low-ish level software, but that doesn't mean we should throw good programming practices out the window. That kind of mindset is the reason most public cheats are buggy and unstable pieces of crap.

[serock1]

Why do things the 'wrong way' when there is no good reason? Playing by the rules in this case affords you a more stable and forwards compatible code base. What does risking a deadlock in this case get you? Nothing.

Yes, you 'get away with it' under the right circumstances, but why do it? Just export a function and call it. As far as I can see it's all gain and no loss.


1. Except in this case there is no reason to not play by the rules... Why do something unnecessarily dangerous for zero gain other than avoiding exporting a function and calling it (a half dozen lines of code).

2. A dream? How is it that I can take a piece of (well written) software for Windows 98 and run it on my Windows 7 machine? Surely I must be dreaming!

Microsoft go to GREAT lengths to try to ensure both backwards and forwards compatibility for software running on their operating system.

Unix/Linux applies less in this case in my experience, but my experience is definitely lacking in this area, so I'm not going to pass judgement either way. Both approaches have their advantages and disadvantages.

3. Because that is what makes us good programmers. Yes, we're writing low-ish level software, but that doesn't mean we should throw good programming practices out the window. That kind of mindset is the reason most public cheats are buggy and unstable pieces of crap.

Ok, I am back, for really last post about 'do sth in DllMain'. !@^^@!, Sorry for off-topic, again.

First, I dont negative your points. I just express there is at least one special condition like this, we may break the rules. Yes, there is reason. Also, not zero gain.

Dont you feel it is more graceful that the sub-system (your bot) is self-executed just with being loaded? This sub-system is 'complete'. With this kind of dll, the code in main topic will work fine. The injector can be more general and easy to implement. That is my reason. To be frank, I prefer the sub-system like this, especially for WoW dll bot, even if there are some shortcomings. Every coin has two sides always.

A well-known project (Scintilla: a free source code editing component, since 1999) shows 'do sth in DllMain' is not bad. Maybe you are its user (notepad++). Visit Scintilla and SciTE Related Sites for more info please.

It does several rules that 'should never do' in Best Practices for Creating DLLs:

# Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
# Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
.......

What do you think about this? I believe there are many dlls broken 'rules', maybe include the dll designed by Microsoft. Ofc, those dont mean we 'should' do that, I never said that. We still 'should not'. But the rule in software developing like this is very different from the order of nature. It is not Bible. If you know what you do exactly, just do it.

Any 'better way' must be under its condition. If I am writing a dll bot by c++, I must CreateThread in DllMain. But if I use c# to write a dll bot, I will choose _Mike's awesome method.

BTW: I think the author of Scintilla is a good programmer.

Thanks for discussing.

[Cypher]

Ok, I am back, for really last post about 'do sth in DllMain'. !@^^@!, Sorry for off-topic, again.

First, I dont negative your points. I just express there is at least one special condition like this, we may break the rules. Yes, there is reason. Also, not zero gain.

Dont you feel it is more graceful that the sub-system (your bot) is self-executed just with being loaded? This sub-system is 'complete'. With this kind of dll, the code in main topic will work fine. The injector can be more general and easy to implement. That is my reason. To be frank, I prefer the sub-system like this, especially for WoW dll bot, even if there are some shortcomings. Every coin has two sides always.

More graceful? No. I feel that software is 'more graceful' when it's not risking my system's stability.

Just because it works now doesn't mean it will work into the future. Follow the rules and it's just one less thing to stress over.

The point about the injector is kinda silly. It's a few extra lines, it's not a big deal.
1. Load module locally
2. Call GetProcAddress
3. Convert local VA to remote VA
4. Call CreateRemoteThread

It's only a handful of lines of code.

Maybe we should stop doing error checks in our software because it will make it 'easier to implement'. Easier to implement does not always mean better.

There may be 'two sides' most of the time, but in this instance it's pretty obvious which side 'defensive programmers' will want to be on. If you want to play russian roulette with your software's stability that's your perogative, but I would rather not.

A well-known project (Scintilla: a free source code editing component, since 1999) shows 'do sth in DllMain' is not bad. Maybe you are its user (notepad++). Visit Scintilla and SciTE Related Sites for more info please.

It does several rules that 'should never do' in Best Practices for Creating DLLs:

Well-known software does dumb shit all the time. Just because a popular piece of software does something dumb doesn't mean they're right and we should follow suite. No developer is infallible.

What do you think about this? I believe there are many dlls broken 'rules', maybe include the dll designed by Microsoft. Ofc, those dont mean we 'should' do that, I never said that. We still 'should not'. But the rule in software developing like this is very different from the order of nature. It is not Bible. If you know what you do exactly, just do it.

Like I said, there are conditions where you can 'get away with it', however you're still yet to present a decent example of where the cost outweighs the gains. The workaround is so trivial that it would be silly imo to break the rules just for the sake of breaking the rules.

There may be cases where it is appropriate to circumvent the rules, in fact, we as reversers do this all the time.

My point is NOT that we should NEVER break the rules. My point is that in this instance it's silly to break the rules, because there is no good reason to!

Any 'better way' must be under its condition. If I am writing a dll bot by c++, I must CreateThread in DllMain. But if I use c# to write a dll bot, I will choose _Mike's awesome method.

BTW: I think the author of Scintilla is a good programmer.

Thanks for discussing.

No, you don't' have to use CreateThread in DllMain, I've already told you how to work around that restriction. (i.e. Add a dozen lines to your injector to call a named export. It's really that simple.)

BTW: I'm not arguing otherwise, but everyone makes mistakes. Just because you're a good programmer doesn't mean you're infallible. Everybody screws up, including me, you, and the author of Scintilla.

[serock1]

COLOR="lime"

All right, I goes back on my word. I hope !@^^@! dont mind.

I think we have no divergence in regard to technology, our difference lie in design aesthetics. The reason I will choose CraeteThread in DllMain is not that I have to do it, just as you said, I have choice. To GetProcAddress the exported function and write asm code piece to call it is an easy thing. I choose this way, only because I like this kind of 'complete' sub-system, when you load it, it runs. No need to do anything else.This kind of system need be restricted by platform (Windows) only, no need to meet other host's rules (implement one function with specified name, ex: Initialize). For unmanaged dll, the injector in main topic is obviously more GENERAL than the injector you said (need call one function of dll). The former injector is a helper for dll, the latter one is a HOST (dll need obey the rules of the injector, even if there only one rule) for dll.

I think it is ugly to add new custom rule(s) to restrict the target dll, when we can support the same injecting ability without adding new rule(s). The dll is forced to hand over its control right. How ugly!

Anyway, It is just my predilection. Not about technology. I am confident of my soft's quality. Just as the author of Scintilla is confident of Scintilla. We know, we have no experimental results to tell me I will lose how many percent quality for my choice.

Last, I appreciate your guidance. I have learned so much.

[_Mike]

Also something that is quite relevant in the context of this thread is that you shouldn't run managed code during loader lock.
And you shouldn't have any static objects who's constructor or destructor require the loader lock.

[Cypher]

All right, I goes back on my word. I hope !@^^@! dont mind.

I think we have no divergence in regard to technology, our difference lie in design aesthetics. The reason I will choose CraeteThread in DllMain is not that I have to do it, just as you said, I have choice. To GetProcAddress the exported function and write asm code piece to call it is an easy thing. I choose this way, only because I like this kind of 'complete' sub-system, when you load it, it runs. No need to do anything else.This kind of system need be restricted by platform (Windows) only, no need to meet other host's rules (implement one function with specified name, ex: Initialize). For unmanaged dll, the injector in main topic is obviously more GENERAL than the injector you said (need call one function of dll). The former injector is a helper for dll, the latter one is a HOST (dll need obey the rules of the injector, even if there only one rule) for dll.

I think it is ugly to add new custom rule(s) to restrict the target dll, when we can support the same injecting ability without adding new rule(s). The dll is forced to hand over its control right. How ugly!

Anyway, It is just my predilection. Not about technology. I am confident of my soft's quality. Just as the author of Scintilla is confident of Scintilla. We know, we have no experimental results to tell me I will lose how many percent quality for my choice.

Last, I appreciate your guidance. I have learned so much.

You don't need to inject an ASM function to call your export if you just make your export match the calling convention that CreateRemoteThread requires.

Also, it's perfectly possible to write a 'generic' DLL injector that offers the OPTION of calling a remote function. Just make it a flag in your injector or w/e...

Lastly, you can assert whatever you want about your 'confidence', but that really means nothing. I can say I'm 'confident' that the earth is flat, but without any proof/investigation/etc it's a baseless assertion.

P.S. Hooray for civil discussions/arugments!

Also something that is quite relevant in the context of this thread is that you shouldn't run managed code during loader lock.
And you shouldn't have any static objects who's constructor or destructor require the loader lock.

Very true.

Another restriction is that you shouldn't run managed code in vectored exception handlers and the likes. I know that doesn't apply in this particular scenario, but it's interesting nonetheless (well, it is imo at least).

[_Mike]

Another restriction is that you shouldn't run managed code in vectored exception handlers and the likes. I know that doesn't apply in this particular scenario, but it's interesting nonetheless (well, it is imo at least).

I assume this is because the CLR can throw it's own exceptions? Wouldn't that also make parts of the STL dangerous to use in an exception handler?

[Cypher]

I assume this is because the CLR can throw it's own exceptions? Wouldn't that also make parts of the STL dangerous to use in an exception handler?

I can't recall the details, I just remember that last time a friend of mine tried to do it, WinDbg went absolutely ballistic with debug message spam saying "DONT RUN MANAGED CODE IN A VEH YOU MORON!" or something to that effect.

You make a valid point though, I'll look into that tomorrow if I (hopefully) remember.

EDIT:

VectoredHandler Callback Function (Windows)

The handler should not call functions that acquire synchronization objects or allocate memory, because this can cause problems. Typically, the handler will simply access the exception record and return.

No mention of C++ EH, but the STL both acquires synchronization objects and allocates memory (obviously it depends on which components you use as to which of these it does, but that's an implementation detail anyway, so even if you think it's not going to do it, it's not something you want to rely on).

Also, it's probably a safe bet anyway that throwing C++ exceptions (or any exceptions for that matter) in a VEH is bad mojo.

Good call.

[!@^^@!]

What kind of problems?
I do plan on supporting 64bit eventually but it's not a high priority at the moment. Mainly because it's not needed for the things I use it for.
You could try fixing it yourself. I haven't really looked at what's needed, so I'm just assuming here..
But the only major things would be the assembler code* and there are a few pointer-to-dword casts.
I'm not allowed to install winrar on this stupid work computer so I can't look at the code right now

*) 32->64bit register usage mainly, and possibly the memory read/writes. The general logic of the code flow should be the same as 32bit I think, dunno if the 64bit CLR requires anything extra.

Well the first issue is the lack of x86 injection into x64, second "issue" (which might just be me who's dumb) is the lack explenation of the return codes (I'll gladly write a c# wrapper with Exceptions and share it if there is an explenation of the codes somewhere)

Thridly, how the hell do i make the stupid visual studio compiler include boost\noncopyable.hpp ? It's in the right folder, it's been included in the project and it can even open the file when i right click the error and click "Open document" yet i still get the stupid "error C1083: Cannot open include file: 'boost\noncopyable.hpp': No such file or directory" compiler error

Edit: Yes i'm a complete retard when it comes to c++

[Cypher]

Well the first issue is the lack of x86 injection into x64, second "issue" (which might just be me who's dumb) is the lack explenation of the return codes (I'll gladly write a c# wrapper with Exceptions and share it if there is an explenation of the codes somewhere)

Thridly, how the hell do i make the stupid visual studio compiler include boost\noncopyable.hpp ? It's in the right folder, it's been included in the project and it can even open the file when i right click the error and click "Open document" yet i still get the stupid "error C1083: Cannot open include file: 'boost\noncopyable.hpp': No such file or directory" compiler error

Edit: Yes i'm a complete retard when it comes to c++

x86 processes can't inject code into x64 processes (It may be technically possible -- I've never tried, but I have a few ideas on how it could be done -- but it's not possible by any means you even want to try to attempt).

In response to your second issue, just read the source code. From memory it's all self-explanatory (last time I read the code was when that thread was posted though, so I'm quite hazy on the details).

As for the third issue... That's PEBKAC, so I'm gonna be lazy and let someone else cover that.

[_Mike]

x86 processes can't inject code into x64 processes (It may be technically possible -- I've never tried, but I have a few ideas on how it could be done -- but it's not possible by any means you even want to try to attempt).

A 32bit* process injecting a 64bit dll in to a 64bit process is possible. Injecting a 32bit dll in to a 64bit process should also be possible from my limited tests.
But it would be more of a cool proof of concept than anything else imo because you have to be very careful with what you do in your dll unless you want to bring the target process down in a flaming ball of crashing fire

*) Technically all processes are 64bit.. Some just also run 32bit code.

As for return values.. Like Cypher said it should be easy to find out most of them but I guess some could be confusing if you don't know assembly, and I'm bored atm so I typed them out for you. This is for managed dlls btw, native ones have different error codes. (Which now that I think back is kind of stupid)

Local code:
1 : process handle is null
2 : memory allocation failure
3 : loadlibrary("mscoree.dll") (local process)
4-14 : WriteProcessMemory
15 : CreateRemoteThread(loadlibrary)
16 : loadlibray("mscoree.dll") (remote process)
17 : WriteProcessMemory
18 : CreateRemoteThread(assembler code)
Remote code:
19 : CLRCreateInstance()
20 : MetaHost->GetRuntime()
21 : RuntimeInfo->IsStarted() // typo in the comment
22 : RuntimeInfo->GetInterface() // typo in the comment
23 : RuntimeHost->Start()
24 : RuntimeHost->ExecuteInDefaultAppDomain()

Success code is whatever you return from your managed func, so I recommend not using 1-24.
Sometimes you get random return codes but I haven't debugged why, and I think it only happens with native dlls.

[Cypher]

A 32bit* process injecting a 64bit dll in to a 64bit process is possible. Injecting a 32bit dll in to a 64bit process should also be possible from my limited tests.
But it would be more of a cool proof of concept than anything else imo because you have to be very careful with what you do in your dll unless you want to bring the target process down in a flaming ball of crashing fire

*) Technically all processes are 64bit.. Some just also run 32bit code.

As for return values.. Like Cypher said it should be easy to find out most of them but I guess some could be confusing if you don't know assembly, and I'm bored atm so I typed them out for you. This is for managed dlls btw, native ones have different error codes. (Which now that I think back is kind of stupid)

Local code:
1 : process handle is null
2 : memory allocation failure
3 : loadlibrary("mscoree.dll") (local process)
4-14 : WriteProcessMemory
15 : CreateRemoteThread(loadlibrary)
16 : loadlibray("mscoree.dll") (remote process)
17 : WriteProcessMemory
18 : CreateRemoteThread(assembler code)
Remote code:
19 : CLRCreateInstance()
20 : MetaHost->GetRuntime()
21 : RuntimeInfo->IsStarted() // typo in the comment
22 : RuntimeInfo->GetInterface() // typo in the comment
23 : RuntimeHost->Start()
24 : RuntimeHost->ExecuteInDefaultAppDomain()

Success code is whatever you return from your managed func, so I recommend not using 1-24.
Sometimes you get random return codes but I haven't debugged why, and I think it only happens with native dlls.

Yeah, like I mentioned, it should be technically possible, but the implementation would be pretty nasty as far as I know.

Did you ever get your cross-architecture injection code working without requiring patching of the system DLLs in memory?