(May 20, 2010 02:05 AM)julian Wrote:  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.

(May 20, 2010 06:25 AM)julian Wrote:  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.

(May 20, 2010 09:58 AM)C00k13 Wrote:  I dunno why people thinks that Deathader is the first here showing an example of resources, Julian was the first. 😝

(May 20, 2010 10:00 AM)morten emil Wrote:  hadfhsukdfgsudkgfcsicvuargbsdu

(May 20, 2010 10:00 AM)morten emil Wrote:  hadfhsukdfgsudkgfcsicvuargbsdu