[Deathader]

I thought about using a Try block with a GCHandle, but it doesn't work out so well...

.Net is garbage collected, objects live on the heap, the garbage collector compacts the heap intermittently, which can involve moving objects to other memory locations. When you pin an object you are making it so that the object cannot be moved - it will remain at the same address. This allows you to then get the address of the object in memory, because you know the object isn't going to be moved and so the address will be valid. Only when you have finished using this address should you unpin the object.

In short,
You should: pin, use, unpin
What you are doing: pin, copy address, unpin, use address.

- When you get to use the copy of the address, the object may have moved off somewhere else - the pointer isn't guaranteed to be pointing where you want it to point to.

It means the function ToPtr isn't robust. You should scrap it and just do it with verbose code. I thought about using:

Code

Dim gch As GCHandle
Try
   gch = GCHandle.Alloc(whatever, GCHandleType.Pinned)
   SomeAPICall(gch.AddressOfPinnedObject())
Finally
   If GCHandle.IsAllocated() Then GCH.Free()
End Try

But if you think about it the only place it can fail is if whatever is Nothing, or if whatever isn't blittable, or if SomeAPICall throws an exception. You can test for Nothing easily, so that doesn't require a Try block. API calls will only throw .Net exceptions if the signature is incorrect. You would want to iron out problems like that before deploying. So I didn't bother and just stuck GCH.Free in without the Try...Finally.

Hmm, thank you for the example. I'll change it thisafternoon.

And thank you everyone for the great feedback.

[pr0t0typ3]

Nice thread ... It is way better then my method but both work xD

[ThatGuyThis]

Looks awesome Deathader!

2short

[Sikandar]

cooool
post death
will try this out
:)

[julian]

i don't exacly know when that garbage collector that julien is talking about cleans up

Yeah, you never know - it runs when memory is getting tight. It's not likely to run immediately after you've unpinned a GCHandle, but it could, so the AddressOfPinnedObject is no longer certain to be the address of the object after it is unpinned.

I was just reading a paper about the heuristics that anti-malware scanners use when running through PE Files. It's a good read.
“PIMP MY PE”: PARSING MALICIOUS AND MALFORMED EXECUTABLES

For those that don't know a heuristic is a quick test that you can do to help identify or find something. The anti-malware scanner parses the PE structure of an EXE file and records some facts about its structure. It then decides how much of a threat the EXE file is by running tests that consider these facts. Things that increase the likelihood of being detected include: an overlay (data tacked onto the end of the file), incorrect PE file structure - especially the bit that says where the end of the file is, repetitive section names, particular orderings of sections, lots of entropy (random data), ...

DeathAdder's code shoves the encrypted file into a section using an API. This means that there won't be an overlay, the PE file structure should be correct (unless MS screwed up the API!), hopefully it will also use standard section orderings. You could name the section something amazing using the API, but the paper shows it's probably best not to.

[GoldStar]

i don't exacly know when that garbage collector that julien is talking about cleans up

Yeah, you never know - it runs when memory is getting tight. It's not likely to run immediately after you've unpinned a GCHandle, but it could, so the AddressOfPinnedObject is no longer certain to be the address of the object after it is unpinned.

I was just reading a paper about the heuristics that anti-malware scanners use when running through PE Files. It's a good read.
“PIMP MY PE”: PARSING MALICIOUS AND MALFORMED EXECUTABLES

For those that don't know a heuristic is a quick test that you can do to help identify or find something. The anti-malware scanner parses the PE structure of an EXE file and records some facts about its structure. It then decides how much of a threat the EXE file is by running tests that consider these facts. Things that increase the likelihood of being detected include: an overlay (data tacked onto the end of the file), incorrect PE file structure - especially the bit that says where the end of the file is, repetitive section names, particular orderings of sections, lots of entropy (random data), ...

DeathAdder's code shoves the encrypted file into a section using an API. This means that there won't be an overlay, the PE file structure should be correct (unless MS screwed up the API!), hopefully it will also use standard section orderings. You could name the section something amazing using the API, but the paper shows it's probably best not to.

intressting,intressting,intressting^^
thx for the document^^ would help making apps more legit :p

[ubbelol]

Nice release Deathader, cute way of getting past Avira. :3

[JIMP]

wow this is great.Good tut.

[6e756c6c]

It's about time someone came up with a simple replacement for EOF. Good job. Oh also.. I HAD NO IDEA ABOUT PINNING!!! God, that would be so much faster then allocating data I wish I had known about it sooner.

[Bitwin]

I dunno why people thinks that Deathader is the first here showing an example of resources, Julian was the first. 😝

[Kōtei]

Because Deathader is more well known.

[GoldStar]

I dunno why people thinks that Deathader is the first here showing an example of resources, Julian was the first. 😝

yeah i think he is, but no body checked it cuz he posted in a SCANTIME crypter. people are dumm -_-

hadfhsukdfgsudkgfcsicvuargbsdu

and what tha fuck is that? are you retarded?

[Cunt]

Cheers Deather ur so sexy o.O i want to lick you o.O and yeh cheers again gonna go try it out :)

[Deathader]

hadfhsukdfgsudkgfcsicvuargbsdu

I'm sorry, I'm not fluent in retardeese

[d3c0mpil3r]

Thanks !!!
I will test it soon.