[Deathader]

You can use this to get past Avira!

Please credit me if used. I've been slaving over a hot pc for the last few hours trying to get this to work (there is almost no documentation or examples on this)

Write resources to exe:

Code

Imports System.Runtime.InteropServices
Module ResourceWriter
    Private Function ToPtr(ByVal data As Object) As IntPtr
        Dim h As GCHandle = GCHandle.Alloc(data, GCHandleType.Pinned)
        Dim ptr As IntPtr
        Try
            ptr = h.AddrOfPinnedObject()
        Finally
            h.Free()
        End Try
        Return ptr

    End Function

    <DllImport("kernel32.dll", SetLastError:=True)> _
    Private Function UpdateResource(ByVal hUpdate As IntPtr, ByVal lpType As String, ByVal lpName As String, ByVal wLanguage As UShort, ByVal lpData As IntPtr, ByVal cbData As UInteger) As Boolean
    End Function
    <DllImport("kernel32.dll", SetLastError:=True)> _
    Private Function BeginUpdateResource(ByVal pFileName As String, <MarshalAs(UnmanagedType.Bool)> ByVal bDeleteExistingResources As Boolean) As IntPtr
    End Function
    <DllImport("kernel32.dll", SetLastError:=True)> _
    Private Function EndUpdateResource(ByVal hUpdate As IntPtr, ByVal fDiscard As Boolean) As Boolean
    End Function

    Public Function WriteResource(ByVal filename As String, ByVal bytes As Byte()) As Boolean

        Try
            Dim handle As IntPtr = BeginUpdateResource(filename, False)
            Dim file1 As Byte() = bytes
            Dim fileptr As IntPtr = ToPtr(file1)
            Dim res As Boolean = UpdateResource(handle, "RT_RCDATA", "0", 0, fileptr, Convert.ToUInt32(file1.Length))
            EndUpdateResource(handle, False)
        Catch ex As Exception
            Return False
        End Try
        Return True

    End Function
End Module

Read resources:

Code

Imports System.Runtime.InteropServices
Module ResourceReader
    
    <DllImport("kernel32.dll", SetLastError:=True)> _
    Private  Function FindResource(ByVal hModule As IntPtr, ByVal lpName As String, ByVal lpType As String) As IntPtr
    End Function

Private Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal moduleName As String) As IntPtr
    Private Declare Function SizeofResource Lib "kernel32" (ByVal hModule As IntPtr, ByVal hResInfo As IntPtr) As Integer
    Private Declare Function LoadResource Lib "kernel32" (ByVal hModule As IntPtr, ByVal hResInfo As IntPtr) As IntPtr

    Public Function ReadResource(ByVal filename As String) As Byte()
        Dim hModule As IntPtr = GetModuleHandle(filename)
        Dim loc As IntPtr = FindResource(hModule, "0", "RT_RCDATA")
        Dim x As IntPtr = LoadResource(hModule, loc)
        Dim size = SizeofResource(hModule, loc)
        Dim bPtr As Byte() = New Byte(size - 1) {}
        Marshal.Copy(x, bPtr, 0, CInt(size))
        Return bPtr
    End Function
End Module

How can this bypass avira? Simple. Instead of writing data to the EOF, you are writing it to the exe's resources (can be viewed in ResHacker and similar programs)

How do I use it? Put the writer in the builder and the reader in the stub. Get the builder to WRITE the settings to the server after it's written, then get the stub to read the resources, and parse out whatever. You can use this to read the output (if you are using strings)

Code

System.Text.Encoding.Default.GetString("BYTES!")

and to convert to byte array:

Code

System.Text.Encoding.Default.GetBytes("STRING!")

Please credit me if used. Thanks.

[Kōtei]

WTF Why has NO ONE commented yet??? THANK YOU DEATH!!! <3

[Stylis]

Yes, we have two method to write data !

1. EOF
2. RES :)

[adware]

Thanks Deathader.
Will add you in credits for sure :)

[Inveno]

Thanks for the share.
Will test this out later, i have a stub that's been detecting on avira, so will see if this fixes that issue.
Thank you for the share mate.

[Soul Collector]

Thanks a lot mate... Gonna try it out

[julian]

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.

[GoldStar]

humm very good. the try catch was wierd though.i usally free the GChandle last thing in my code, but i don't exacly know when that garbage collector that julien is talking about cleans up xD. but great exemple mate.
but i noticed something when i first started using the updateresource, is that sometimes some "PADDINGXXPADDING" is added to the EOF after updating. i found no documentation about the subject, but iStealer seems to updateresource the stub then deletes that padding thing by getting eof and writing nullbytes. try updating some win32 app and hex edit, and you'll see it. i just want to know what it is before handling it lool

[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.

[ThatGuyThis]

Looks awesome Deathader!

2short

[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

[JIMP]

wow this is great.Good tut.

[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?