c0d3-m4513r / inject-lib Goto Github PK

After I have made my library theoretically no_std compatible #20 , I need to figure out how to test it.

TBH. I don't know, if I'm happy with LGPLv2.1.
I need to consider some other alternatives.
This license is not set into stone at all for me.
If I am going to change the license, I'd rather go with something more open.

EDIT: If I do decide to go with another licence it will be "LGPLv2.1 or 'Something Else'". You should not have to worry about what license I change to (unless the current license is to restrictive for you).

When target process is under WOW, the path of kernel32.dll is "c:\windows\system32\kernel32.dll", which is fake path. The real path is "c:\windows\sysWOW64\kernel32.dll".
And if the domain process is under WOW too, the entry_point will point to the export function of "c:\windows\sysnative\kernel32.dll". The real path is "c:\windows\system32\kernel32.dll".
So there is a bug.

Currently asm! is still nightly/beta only.
When asm! for stable gets released, I should remove the nightly feature.

See tests on recent dev pr:
1b644e6
3f1df12

Seems to be a github actions thing though?
Maybe related to a headless env?

Add a feature to support no_std development

If the function fails with ERROR_BAD_LENGTH when called with TH32CS_SNAPMODULE or TH32CS_SNAPMODULE32, call the function again until it succeeds.

afaict LDRUnloadDll is more consistent at unloading a dll from a process (ProcessHacker uses that method).
Maybe the two methods make x86->x64 injection/ejection easier?

Sometimes tests fail, or the entire testing process crashes due to STATUS_HEAP_CORRUPTION.
I've also seen STATUS_ACCESS_VIOLATION.
why? did it happen before?

• investigate 32-bit(i686) no-std builds

I don't currently know, how to add tests.
I'd need to compile a dll, and inject it. All while inside a method? is that doable?

I will not release a 1.0 release until stability and crash freeness of this library and target process (assuming it doesn't crash because a dll was injected) can be garanteed.

Thank u for this project.
My English is bad, sorry.
There are two errors in InjectWin::eject:

1. windows::str_from_wide_str convert raw wide char pointer to rust-string without trim '\x00', which will make get_module_in_pid cannot find target module handle. I add .map(|s|{String::from(s.trim_end_matches(char::from(0)))}) to fix this.
2. The arg lpParameter of CreateRemoteThread will become the arg of lpStartAddress directly. When lpStartAddress is 'FreeLoadLibraryA', lpParameter should be the handle instead of a pointer.

I have not maintained this crate in a while, and I have honestly lost interest in this.
This crate was a fun way to learn about more low level stuff for me.
I have not had any interest of touching this crate in a while.

Probably can probably be attributed in part to some of the bad code-quality that is inside this crate.
Anyways, if you are interested in stepping up as a maintainer I can add you as a co-owner on crates.io and give you writer(or maintainer) access on github.