News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

unpacking res

Started by Celtic, October 13, 2008, 09:54:30 AM

Previous topic - Next topic

Celtic

Hi i have problems to unpack a dll from a ressource.

I will put a dll into my project and i will unpack this into the appfolder of my programm.
How i can make it?

The dll is in the RCDATA res!

Sorry for my bad english!!!


BogdanOntanu

Please explain me the reason for this action?

I have also noticed in you posts that you intend to hide your process from task list or process enumeration. This kind of actions are suspicious and will be picked up by AV software. You give too little details.

So explain me what is your project and why do you want to take this road?

Ambition is a lame excuse for the ones not brave enough to be lazy.
http://www.oby.ro

Celtic

It has nothing to do with what you said.
   
I just want to learn MASM

I have problems wenn i will play xm files oder other sound files and in the bass.dll i have this functions!
or can i make a lib from the bass.dll?

I am sorry if you misunderstood searched.


ragdog

You can use a libary or the function loadlibary and GetProcAddress

For libary see in my bassradio player 0.1
http://www.masm32.com/board/index.php?topic=9298.0

For extract the bass.dll from res use this

In you resouce file add this

#define     IDR_BASSDLL 400 

IDR_BASSDLL RCDATA  "Res/bass.dll"



.data
szLibName       TCHAR   "bass.dll",0
szFileName      TCHAR   "\bass.dll",0
pPathBuffer     LPTSTR  (MAX_PATH+11) dup (?)
pFileSize       LPDWORD (34308)

.data?
hModule         HMODULE             ?
wfd             WIN32_FIND_DATA    <?>
pBytesWritten   LPDWORD

.code
invoke ExtRes,hInstance,CTXT ("Bass.dll"),ResourceId

ExtRes  proc   hInst:DWORD, pFileName:LPCTSTR,pResource:LPCTSTR

        invoke  GetSystemDirectory,ADDR pPathBuffer,MAX_PATH
        invoke  lstrcat,ADDR pPathBuffer,pFileName
        invoke  FindFirstFile,eax,ADDR wfd
        cmp     eax,INVALID_HANDLE_VALUE
        jz      @F
        invoke  FindClose,eax
        mov     eax,wfd.nFileSizeLow
        cmp     eax,pFileSize
        jz      @ret
@@:     invoke  FindResource,hInst,pResource,RT_RCDATA
        push    eax
        invoke  SizeofResource,hInst,eax
        mov     edi,eax
        pop     eax
        invoke  LoadResource,hInst,eax
        mov     esi,eax
        invoke  LockResource,eax
        invoke  CreateFile,ADDR pPathBuffer,GENERIC_WRITE,
                                            FILE_SHARE_READ,
                                            NULL,
                                            CREATE_ALWAYS,
                                            FILE_ATTRIBUTE_NORMAL,
                                            NULL
        cmp     eax,INVALID_HANDLE_VALUE
        jz      @error
        mov     ebx,eax
        lea     ecx,pBytesWritten
        invoke  WriteFile,ebx,esi,edi,ecx,NULL
        invoke  CloseHandle,ebx
        or      eax,eax
        jnz     @ret
@error: invoke  MessageBox,NULL,CADD("INVALID_HANDLE_VALUE"),
                                0,MB_ICONERROR
        mov     eax,FALSE
@ret:   ret

ExtRes  endp


greets

BogdanOntanu

The BASS system from here: http://www.un4seen.com/ contains an example of usage in MASM32 with source code.

Hence you should try and use what the people that created BASS do provide for free. You are no supposed to reverse, "unpack", or hide the DLL that you are using for free.

As for me "understanding wrong"  your post like this:
Quote
Hmmm. I have change the Code to:

.386
.model flat,stdcall
option casemap:none

include kernel32.inc
include windows.inc
include user32.inc
includelib user32.lib
includelib kernel32.lib
include masm32.inc
includelib masm32.lib

.data?
   
   hSnapshot   dd      ?
   uProcess   PROCESSENTRY32   <>

.data


prog db "notepad.exe"
handle dd ?
pid dd ?
.code
start:

   mov   [uProcess.dwSize], sizeof uProcess
   invoke   CreateToolhelp32Snapshot, TH32CS_SNAPPROCESS, 0
   mov   [hSnapshot], eax
   invoke   Process32First, eax, ADDR uProcess
   .while eax
   
   
    .if !eax
   invoke OpenProcess,PROCESS_ALL_ACCESS,0,uProcess.th32ProcessID <= i have this change
   mov handle,eax
    invoke ShowWindow,handle,SW_HIDE <= and this
    invoke CloseHandle, [hSnapshot]
    .endif
   invoke   Process32Next, [hSnapshot], ADDR uProcess
   .endw
   invoke   CloseHandle, [hSnapshot]


    invoke ExitProcess,NULL

end start

   
but nothing happens ????


Is this not your post in another thread regarding hiding a process or a window?

Be careful here because you are walking on thin ice ... you are warned. If your intention are correct then it is ok but otherwise I will remove your posts.

Hence if you have problems with BASS and bass.dll and playing XM files with it... then why not say so directly?... And why do you ask about how to unpack a DLL from a RCDATA resource?

You want to learn ASM and the first things you want to learn are about how to hide something from the user and how to unpack a DLL from a resource?  Hmmm .. allow me to call this "strange" :D







Ambition is a lame excuse for the ones not brave enough to be lazy.
http://www.oby.ro

Vortex

Hi Celtic,

Beside using resources, you have the option to embed the DLL into your main executable. Hutch's fda tool coming with the Masm32 package converts any binary file to linkable MS COFF object module. Your final executable linked together with this object file encapsulates the binary file.

A quick example :

include     TestDll.inc
include     Console.inc

.data

DllName     db 'Console.dll',0
func        db 'StdOut',0
message     db 'DLL extracted from the executable',0

.data?

hFile       dd ?
bWritten    dd ?
hInst       dd ?

.code

start:

    invoke  CreateFile,ADDR DllName,GENERIC_WRITE,0,0,\
            CREATE_ALWAYS,FILE_ATTRIBUTE_ARCHIVE,0
    mov     hFile,eax
    invoke  WriteFile,eax,ADDR pDLL,ln_pDLL,ADDR bWritten,0
    invoke  CloseHandle,hFile           ; Write the DLL to disc

    invoke  LoadLibrary,ADDR DllName    ; Load the DLL
    mov     hInst,eax
    invoke  GetProcAddress,eax,ADDR func
    invoke  pr1 PTR eax,ADDR message    ; eax points the address
    invoke  FreeLibrary,hInst           ; of the StdOut function
    invoke  ExitProcess,0
   
END start




\masm32\tools\fda\fda dll\Console.dll Console.obj pDLL
\masm32\bin\ml /c /coff TestDll.asm
\masm32\bin\polink /SUBSYSTEM:CONSOLE TestDll.obj Console.obj


The file data assembler fda.exe converts the DLL to an object file. This module is linked with the main project module to produce TestDll.exe. Running this executable, it writes the embedded DLL to disc, loads it with LoadLibrary and calls the exported function StdOut to print a string to the console.


[attachment deleted by admin]

Mark Jones

I actually admire his desire to make "one executable which does it all." However, I do not think this is the way it should be done. Extracting a .DLL from anything at run-time could cause many anti-virus softwares to lock down this application. This may not be a problem on one particular machine (and anti-virus setting) but it would not be a good idea to make this type of application public -- the end result could be very unpredictable.

The best thing to do would be to include the BASS.DLL separately. Yes it sucks, but that is the price you must pay for using somebody else's lib. You could make an NSIS installer which included the BASS.DLL, and test for it before install. (That way, if the user allready has a BASS.DLL, then another one does not need to be installed.) Of course then, you risk your application failing if the user uninstalls the other application which installed the BASS.DLL.

P.S. Vortex, Avira comes up with an "TR/Dropper.Gen" virus match on your attached file. I know it is a false positive, but this just goes to show how touchy A/V products are to this kind of activity, and why they should not be implemented.
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

Vortex

Hi Mark,

Extracting a DLL should not be a problem as many installers are designed to unpack embedded executables. The problem is that some AV softwares are very sensitive while handling the type of executables in my case. To find a good solution for this false positive problem,  it would be interesting to create an example based on the article autored by Peter Kankowski :

copy /b sfx.exe+archive.zip sfx_ready.exe

To solve the problem, I converted my executable to a SFX. The compressed data block ( the child DLL ) having the size of 490 bytes does not trigger the AV softwares listed in jotti Thanks to Jeremy Collake for his compression software.



[attachment deleted by admin]

Vortex

Here is a new version based on the method described by Peter Kankowski.

I created a simple command-line tool named WriteLen.exe to add 4 bytes defining the file size increased by 4 to the end of any binary file.

According to the statement :

copy /b sfx.exe+archive.zip sfx_ready.exe

the extractor is built like the following :

copy /b TestDll.exe+dll\Console.dll TestDll.exe

The extractor module reads it's own last four bytes from the disc to get the size of the embedded file Console.dll  The file pointer is set to point the offset of the dll and the extractor. writes Console.dll to disc.


[attachment deleted by admin]

Vortex

Simplified procedure to merge the main module with the DLL. Another tool named MergeFile.exe does the merging job and it writes the size of the file to be embedded to the end of the combined files.
Usage : MergeFile filename1.ext filename2.ext
[attachment deleted by admin]