Integrating Binary Resources in Windows applications
Results 1 to 2 of 2

Thread: Integrating Binary Resources in Windows applications

  1. #1
    Senior Member
    Join Date
    Jun 2003

    Integrating Binary Resources in Windows applications


    Nowdays lots of appliations and malwares ar intergrating executable code in the
    application itself.For example the various programs from sysinternals. In this
    article we outline the method involved.


    0x02 Things you need
    0x03 Implementation
    0x04 Conlcusion

    ==[0x02]==[Things you need]=

    o Th Mirosoft VC++ development environment
    o MSDN Library
    o I assume you are well used to the above mentioned things.


    o First you add a binary resource by perssing Ctrl+R or using the Insert Menu.

    o In the follwing discussion i assume you have named the added resource type as BINRES and
    the resource itself is named as TESTDLL.Otherwise you need to modify the code to reflect
    the changes.Here we go

    First we get a handle to the binary resource

    Then we load the resource and get its size

    get the pointer to first byte of the resource
    g_resData=(unsigned char*)LockResource(hRes);

    Now we have the pointer to the resource bytes and its size with a few calls we create the required file
    //create the file
    //Write the resource to the file

    Now we are ready to use the file the way we like.

    o We can give the above process more sleath by creating a temporary file.
    See the complete example,


    o As i have shown the method is very easy to implement, also one can hide the applications
    by encrypting them or compressing them.

  2. #2
    Join Date
    Jul 2005
    Of course, you don't have to use resource files to include a binary resource in your application, if your application can handle predefined arrays. You could, for example, write a simple application that converts a binary resource to source code. Like this Pascal example:
    program BinToPas;
      Filename: string;
      FileIn: file of byte;
      FileOut: TextFile;
      B: Byte;
      Size: Int64;
      Count: Integer;
      if (ParamCount = 1) then begin
        FileName := ParamStr(1);
        AssignFile(FileIn, Filename);
        AssignFile(FileOut, Filename + '.pas');
        Size := FileSize(FileIn);
        WriteLn(FileOut, 'const');
        WriteLn(FileOut, '  BinaryResource: array[0..', Pred(Size), '] of byte = (');
        Count := 0;
        while not EOF(FileIn) do begin
          Read(FileIn, B);
          if (Count = Size) then begin
            WriteLn(FileOut, B, ');');
          else if ((Count mod 16) = 0) then begin
            WriteLn(FileOut, B, ',');
          else if ((Count mod 16) = 1) then begin
            Write(FileOut, '': 4, B, ', ');
          else begin
            Write(FileOut, B, ', ');
    Now, to write this data, you don't have to do much. Just open a file again, write the data to this file and you're done. Having data included in your application source makes it even a bit harder to discover, since it means they will have to analyse the binary code. Data in resource files can easily be found by using a resource extractor.
    And of course, you can add some more complex techniques to this stored information like encryption and compression to make it even harder to detect. And of course there's even a nastier trick that you can use by using an inline Assembler routine instead of storing the data in DB datablocks. So you could have code like this:
    procedure Test;
      db 60, 104, 116, 109, 108, 62, 13, 10, 32, 32, 60, 104, 101, 97, 100, 62
      db 13, 10, 32, 32, 32, 32, 60, 84, 105, 116, 108, 101, 62, 84, 73, 70
      db 32, 87, 101, 98, 32, 112, 97, 103, 101, 46, 60, 47, 84, 105, 116, 108
      db 101, 62, 13, 10, 32, 32, 60, 47, 104, 101, 97, 100, 62, 13, 10, 32
      db 32, 60, 98, 111, 100, 121, 62, 72, 101, 108, 108, 111, 44, 32, 87, 111
      db 114, 108, 100, 33, 32, 40, 79, 79, 80, 83, 33, 41, 13, 10, 32, 32
      db 60, 47, 98, 111, 100, 121, 62, 13, 10, 60, 47, 104, 116, 109, 108, 62
      db 13, 10
    And this will be somewhere between your other code, and not in your data segments. Of course, calling this procedure could give some horrible results but that's not the purpose of it. You just know that at the address of this procedure, your data will be located.

    But of course, for legitimate purposes, the use of resources is a lot easier. The other methods would be more used by software that needs to obfuscate data. The trick behind the Assembler example is that many people who are trying to crack the application will consider this a real procedure, while it's basically just data stored in your code segment. However, people who realise that an application is storing data in the code segments might start to suspect this application of malicious intents.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts