📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.








Flag: Tornado! Hurricane!

 Forums >>  Brainstorms - General  >>  Advice Needed on Native Code Merging

Topic created on: August 8, 2007 13:47 CDT by DMettio .

I have a COM/OLE Type library shared  by VB and delphi application to preform licensing and copy protection functions. the problem is, once the dll is known to attacker given the interface it would be a matter of a little effort to crack the system. but my question.

Is it possible to merge com dlls with exe to make tracing harder? if not what about a none COM dll? would it make any diffrence? any help would be appreciated

  phantal     August 8, 2007 15:58.24 CDT
  If I'm not misunderstanding you, you want to know if you can compile your exe such that it doesn't depend on the DLL any longer for COM operations, and if that's what you're asking, I would say no.

  You could find a way to perform the same tasks as the COM operations perform so you don't rely on COM to do it, but it'd be more work.  Also, that won't slow anyone down.

  What you're trying to fight is crackers, but you should be defending against the common thief.  There's that old saying "Locks keep honest people honest", and it's very true.  I'd say, implement a simple scheme to protect your software from theft by the majority.  People who can crack are usually in search of the next big thing to crack, not some guy's weak DRM scheme.  I'd rather have a program that may not be cracked because no one sees it as a challenge than something that becomes a target by crackers because it seems challenging.

-Brian

  DMettio   August 8, 2007 17:01.05 CDT
You are right, basically I need some form of static linkage. As far as I'm concerned I want to make the code harder to break, unfortunately the code is already broken. I'm working on the new version but how can I hide the implementation when I need to carry around a COM type library that exports an OpenLock function !!! to rename the OpenLock to some dummy name won't help since there are 32 applications that call this function and relly on a return value to validate the licensing.

I hoped I can complicate thing much further by merging the code inside dll (COM or a normal one) with the main exe. this way at least it would be harder to locate the code. I can't see why there is no tool to merge executable files. is it more than adding code segments to the main file and redirecting Import tables? Am I missing something? I think I should be!

  igorsk     August 8, 2007 17:07.36 CDT
http://www.openrce.org/blog/view/784/

  DMettio   August 8, 2007 17:39.45 CDT
Thanks igorsk, sounds like a great place to start.

Edit: Tracking the link, I've found two commercial softwares that can bundle any kind of dll inside executable. I'm going to update rewolf's source to support COM dlls and will publish it as soon as it's done. thanks again.

  fileoffset     August 15, 2007 01:51.18 CDT
Haha, OpenLock eh :)

Brilliant export, and a crackers dream. If you have no choice but to use the existing COM component (and from what you say, its already fairly integrated into your product suite, so you do) then the first step would be to obfsucate your COM component and rebuild it.

You will also need to refactor all your code references aswell.

Obfuscation is a good first step and its one of the cheapest forms of "quick" protection.

You could also expand each of the exports to create fake arguments to calls, e.g:

int OpenLock(void) becomes

int OpenLock(int, int, int, int, char [20], pvoid *)

You don't have to use them though if you at least pretend to it can help hide your functions real purpose.

Once all your COM names are obfuscated, you have to do two things:

1. Go through all your programs and attempt to hide or obfuscate the way the COM is used/called. layers of indirection, inheritance and high level OOP is sometimes useful for this.

2. Start work on mangling the inside of the COM dll to make it much harder to:

- identify functions
- trace execution
- use debuggers and static tools to disassemble

I know there are better ways to handle software protection but as far as effort goes, in your current situation this will probably be the most effective.

Note: Registration is required to post to the forums.

There are 31,328 total registered users.


Recently Created Topics
[help] Unpacking VMP...
Mar/12
Reverse Engineering ...
Jul/06
let 'IDAPython' impo...
Sep/24
set 'IDAPython' as t...
Sep/24
GuessType return une...
Sep/20
About retrieving the...
Sep/07
How to find specific...
Aug/15
How to get data depe...
Jul/07
Identify RVA data in...
May/06
Question about memor...
Dec/12


Recent Forum Posts
Finding the procedur...
rolEYder
Question about debbu...
rolEYder
Identify RVA data in...
sohlow
let 'IDAPython' impo...
sohlow
How to find specific...
hackgreti
Problem with ollydbg
sh3dow
How can I write olly...
sh3dow
New LoadMAP plugin v...
mefisto...
Intel pin in loaded ...
djnemo
OOP_RE tool available?
Bl4ckm4n


Recent Blog Entries
halsten
Mar/14
Breaking IonCUBE VM

oleavr
Oct/24
Anatomy of a code tracer

hasherezade
Sep/24
IAT Patcher - new tool for ...

oleavr
Aug/27
CryptoShark: code tracer ba...

oleavr
Jun/25
Build a debugger in 5 minutes

More ...


Recent Blog Comments
nieo on:
Mar/22
IAT Patcher - new tool for ...

djnemo on:
Nov/17
Kernel debugger vs user mod...

acel on:
Nov/14
Kernel debugger vs user mod...

pedram on:
Dec/21
frida.github.io: scriptable...

capadleman on:
Jun/19
Using NtCreateThreadEx for ...

More ...


Imagery
SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit