Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DLL Talk / question: DLLs in TEMP dir

Author
Message
DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 28th Sep 2004 09:26
How can we be sure people will not open the TEMP dir and steal our DLLs while the program is running? One more reason why temporary files suck.

Cleber de Mattos Casali, game programmer.
DarkPhear is a full freeware RPG developed by me. You can download it and some game demos for free at my page: http://darkphear.cjb.net
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 28th Sep 2004 17:07
You cant...

No real way around it really until everything from the DLL is embedded within the executable.


Come to the UK Convention on the 23rd & 24th of October
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 28th Sep 2004 17:46
Create a special activation code for you dll to use. The command would set a 'activated' variable within the dll memory space. Then shove a check for that in each of your commands. If you need a more detailed explanation, feel free to ask more.
Dave J
Retired Moderator
16
Years of Service
User Offline
Joined: 11th Feb 2003
Location: Secret Military Pub, Down Under
Posted: 28th Sep 2004 17:55
Unless it's a commercial DLL you shouldn't really worry about it anyway.


"Computers are useless they can only give you answers."
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 28th Sep 2004 18:17
In DarkPhear's case he wanted to keep his dll private. Which is understandable, some people like to keep certain pieces of code private for whatever reason. I have a ezine to finish up in the next few days, but somewhere inbetween that and my free time I'll work up an example for people to see how to implement security on their dll's.
Freddix
AGK Developer
16
Years of Service
User Offline
Joined: 19th Sep 2002
Location: France
Posted: 28th Sep 2004 20:18
Take us informed Torrey I'll be interested too

DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 28th Sep 2004 23:47
DLL functions will actually be embedded within the executablein the future? This would be great. Temporary files slow things down, are really unprofessional and unnecesary in modern systems, wich have a lot of RAM. I think the DLLs could be extracted directly to memory, this method would me much better.
The DLL activation command thing is what I had in mind. The bad part is adding one more IF condition to each function of my extremely optimized code, but I guess it will not make a big difference. For my joystick DLL, I can check for the activation only in the JOYSTART command, because the other commands will not work without it.

Cleber de Mattos Casali, game programmer.
DarkPhear is a full freeware RPG developed by me. You can download it and some game demos for free at my page: http://darkphear.cjb.net
IanG
14
Years of Service
User Offline
Joined: 25th Sep 2004
Location: Cyberspace
Posted: 29th Sep 2004 00:47
i hate the way that the window just sits in the taskbar for an age when it is extracting all your project files

Used to be Phoenix Insane : PC Spec-AMD Athlon 2.0Ghz,GeForce FX5200 128mb,512MB of ram, Win XP Pro SP2 . Last reformat: 17/09/2004
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 29th Sep 2004 08:58
DLL extraction directly to memory is impossible. It is a Windows PE file format, and the loader for the OS needs to properly load and initialize memory for it's sections, stack, etc.
DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 29th Sep 2004 09:04
Sorry to hear that. I've read somewhere Lee is working on DLL protection. I hope it includes our DLLs...

Cleber de Mattos Casali, game programmer.
DarkPhear is a full freeware RPG developed by me. You can download it and some game demos for free at my page: http://darkphear.cjb.net
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 29th Sep 2004 10:45
Quote: "DLL extraction directly to memory is impossible."

Nah, it's not impossible. Tricky but not impossible. (For Delphi DLLs a bit too tricky.)

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 29th Sep 2004 11:15
It is entirely impossible. And if you'd think that MapAndLoad would work in this case, that's wrong! If you misunderstood DarkPhear mentioned having a dll packed in to a file and it loaded in to memory without it being dropped to the hard drive first. Windows API's require that the PE image be on disk to load. The internal loader of the OS that automatically does the loading when we double click on the file may be able to handle such a load without extracting, but then again, MS wouldn't tell us their secretive kernel mode functions.
Rob K
Retired Moderator
16
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 29th Sep 2004 20:52
Quote: "DLL extraction directly to memory is impossible. It is a Windows PE file format, and the loader for the OS needs to properly load and initialize memory for it's sections, stack, etc."


You can modify the PE file in memory after it has loaded. So perhaps you could create a tiny dummy DLL, load that, and then replace that with information from the real DLL afterwards?


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 29th Sep 2004 21:07 Edited at: 29th Sep 2004 21:19
Quote: "It is entirely impossible. "

Erm... it is possible.
What do you think: when I write, "it's tricky but not impossible", would that sentence indicate I got it working? The answer: Yes. Well with the exception of Delphi DLLs (that's what the other sentence indicates). However, VC++, C++ Builder, FASM and FreePascal DLLs do work. So please...

Quote: "And if you'd think that MapAndLoad would work in this case, that's wrong!"

No, really?


Quote: "If you misunderstood DarkPhear mentioned having a dll packed in to a file and it loaded in to memory without it being dropped to the hard drive first."

I know.

Quote: "Windows API's require that the PE image be on disk to load."

The Windows PE loader requires that, not the API. Solution: Don't use the Windows PE loader.

Quote: " The internal loader of the OS that automatically does the loading when we double click on the file may be able to handle such a load without extracting, but then again, MS wouldn't tell us their secretive kernel mode functions."

They don't need to.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 29th Sep 2004 21:15 Edited at: 29th Sep 2004 21:23
Quote: "You can modify the PE file in memory after it has loaded. So perhaps you could create a tiny dummy DLL, load that, and then replace that with information from the real DLL afterwards?"

That method is called injection. But that doesn't really help because you still have to map the DLL to the new gained memory area. It's only "useful" when you want a compiled program to behave in a different manner, for instance intercepting system DLL calls (keyword: virus, although it can be used for more beneficial things too).

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
IanM
Retired Moderator
16
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 29th Sep 2004 21:57
In the end, it's all just data. You just have to understand the format and the transforms required to fixup the memory addresses ... not that I do

@Empty, care to share information or links on how to load a DLL from memory with me? I already have the DLL injection stuff sorted, and I'd like to go deeper ... I'm ready for the blue pill

*** Coming soon - Network Plug-in - Check my site for info ***
For free Plug-ins, source and the Interface library for Visual C++ 6, .NET and now for Dev-C++ http://www.matrix1.demon.co.uk
Dave J
Retired Moderator
16
Years of Service
User Offline
Joined: 11th Feb 2003
Location: Secret Military Pub, Down Under
Posted: 29th Sep 2004 22:53
You mean the red pill?


"Computers are useless they can only give you answers."
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 29th Sep 2004 23:42 Edited at: 29th Sep 2004 23:52
I went to a highest power on this one. Here's the answer from the powers that be:

Quote: "I wouldn't use the word "impossible." It can be done be some way, but would be pretty difficult. If you look at it from an documented point of view, it may be impossible."


@IanM

I don't think we'll get an answer any time soon on how to do this one. And speaking of that blue pill, I'm not so sure you want that kind of knowledge. Secret Service paid me a little visit about 5 months ago. The DoD handed them the case to seek information from me. I would have guessed it was the visit they paid to my site months before. My AWStats picked that visit up, and I reversed it after I noticed the ".mil" turned out to be the DoD - scientific applications unit.

@empty

Wow you mentioned FASM!! First guy I've noticed to do it. All of my DLL's for DarkBASIC Pro are compiled using FASM, it's one of the best compilers out there. I've been a developer for over 10 years, once used TASM, but finally switched over 1-2 years ago to FASM.
DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 30th Sep 2004 00:03 Edited at: 30th Sep 2004 00:17
Quote: "You can modify the PE file in memory after it has loaded. So perhaps you could create a tiny dummy DLL, load that, and then replace that with information from the real DLL afterwards?"


This idea sounds pretty good. And possible. If anyone can find out how to do that, please explain it to Lee.

Let's see another aspect of the problem. Think about it, when we publish a game or application we're also publishing the core of DBPRO inside it, the DLLs. TGC's commands and plugin commands are all there. By the way, is it legal to distribute DBPRO's DLLs? Because that's exactly what we're doing. If the DLLs are free to distribute, people can just grab the DLLs and copy to their plugins folder. Or even create an alternative compiler that uses the DLLs. People would just download DBPRO's latest upgrade, extract the DLLs and simply put it in the alternate compiler's folder. I'm sure TGC wouldn't want that.

Cleber de Mattos Casali, game programmer.
DarkPhear is a full freeware RPG developed by me. You can download it and some game demos for free at my page: http://darkphear.cjb.net
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 30th Sep 2004 03:09 Edited at: 30th Sep 2004 03:11
@Torrey
No matter what your powers that be tell you, from what point of view you look at it, and whether you like or not, it is possible. It doesn't even require hacking or reverse engineering and is not illegal. End of story.


@IanM
Well I'm certainly not explaining the method in public, because even thought it's legal, one can do a lot of harmfull things with it.
Also it took me quite a while to sort that out because (fortunately actually) there are no resources online anywhere that discuss such sorts of things or at least I'm not aware of them. So I'm not going to tell anyone how it works in detail at this point of time. We might actually use this method in/for one of the future versions of playbasic unless we find a better solution. So some basic hints: You need to simulate the Windows PE loader; the most important thing is to map the sections correctly. All you need to know to do this is the PE file format. There are some indepth discussion about the PE file format on the MS site. Also neophyte posted a detailed description on the off topic board. Investigating COFF and OBJ files might help too, as well as some linkers, like for instance Alink which is open source. The more complicated part is to process the export and reloc tables. If you have some specific questions you're welcome to send me a PM on the underware design forums.



Here is an example application where a DLL is called from a resource. It's one of the first version I got working, and the resource section in the DLLs won't work properly. In order to test it with other DLLs use a resource editor of your choice, and replace the resource named "a01" with your DLL. The DLL should contain a function called "TestFunction".

Well while we're at it, I'd be very grateful if someone with a 64bit CPU and XP SP2 could test this too. I'd like to know if it passes the DEP.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 30th Sep 2004 03:28
I'll try that later on - unless someone else gets there first...


Come to the UK Convention on the 23rd & 24th of October
IanG
14
Years of Service
User Offline
Joined: 25th Sep 2004
Location: Cyberspace
Posted: 30th Sep 2004 04:29
ran okay on xp pro sp2 32bit, three dialog boxes appeared, dll loaded, test function executed and dll unloaded

Used to be Phoenix Insane : PC Spec-AMD Athlon 2.0Ghz,GeForce FX5200 128mb,512MB of ram, Win XP Pro SP2 . Last reformat: 17/09/2004
DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 30th Sep 2004 05:41
ran okay on brazilian Win98SE

Cleber de Mattos Casali, game programmer.
DarkPhear is a full freeware RPG developed by me. You can download it and some game demos for free at my page: http://darkphear.cjb.net
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 30th Sep 2004 05:53
empty, what is your handle? And you probably know what I'm talking about.
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 30th Sep 2004 08:14
@IanG Surreal Studio and DarkPhear
Thanks for testing it, guys.



@Torrey
Quote: " empty, what is your handle? And you probably know what I'm talking about."

Actually no, not really.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 30th Sep 2004 11:25 Edited at: 30th Sep 2004 11:29
I just finished debugging this entire example you gave. It was really obvious that you tried to simulate the PE loader as best you could. For each section of the PE file you allocated 1024 bytes of space and moved the bytes over, and then protected the page. Loaded the user32 dll that you need, filled in the memory values and then made a call to the dll entry point. I will you give you it was a darn good attempt at loading a dll from memory, but it doesn't look like a possible solution for any of the guys coding dbp dll's. Once that gets developed a little more, that'd be a nice little routine to add in to a program. Combine that with a file packer, and you'd be set.

I liked it a lot, good skill. Looks like optimized C under the microscope. What compiler was used? I know it wasn't msvc++.
DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 30th Sep 2004 11:55 Edited at: 30th Sep 2004 11:56


I wish it was this easy...

Cleber de Mattos Casali, game programmer.
DarkPhear is a full freeware RPG developed by me. You can download it and some game demos for free at my page: http://darkphear.cjb.net
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 30th Sep 2004 20:49
Quote: "I just finished debugging this entire example you gave. It was really obvious that you tried to simulate the PE loader as best you could. For each section of the PE file you allocated 1024 bytes of space and moved the bytes over, and then protected the page. Loaded the user32 dll that you need, filled in the memory values and then made a call to the dll entry point. I will you give you it was a darn good attempt at loading a dll from memory, but it doesn't look like a possible solution for any of the guys coding dbp dll's. Once that gets developed a little more, that'd be a nice little routine to add in to a program. Combine that with a file packer, and you'd be set."

It'll allocate more memory if needed and load more DLLs if the import table requires it.


Quote: "What compiler was used?"

Delphi.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 1st Oct 2004 07:50
Sooooo TCA, have you found the time to test it on your high end machine?
Obviously there are not many people with 64bit CPUs here.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
IanM
Retired Moderator
16
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 1st Oct 2004 08:13
Well, I've found 2 pieces of very informative code that do the loading of DLLs from memory.

The problem is that one is an incomplete implementation, and the other is for an emulated system so I have to match it back to windows. Oh well ... lots of study ...

*** Coming soon - Network Plug-in - Check my site for info ***
For free Plug-ins, source and the Interface library for Visual C++ 6, .NET and now for Dev-C++ http://www.matrix1.demon.co.uk
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 1st Oct 2004 18:19
Quote: "Sooooo TCA, have you found the time to test it on your high end machine?"

No, not yet. I will over the weekend.


Come to the UK Convention on the 23rd & 24th of October
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 1st Oct 2004 20:38
Cool, thanks.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 1st Oct 2004 22:10
I dont see anything stopping me this time...


Come to the UK Convention on the 23rd & 24th of October
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 2nd Oct 2004 20:44
Its okay with 64-bit processors and DEP.


Come to the UK Convention on the 23rd & 24th of October
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 2nd Oct 2004 20:47
Great. Thanks, TCA.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 2nd Oct 2004 20:56
It could cause the message to come if they used the SP2 Release Candidate (as DEP was changed between that and the full version), but if they are using the beta version still, then its the users problem...


Come to the UK Convention on the 23rd & 24th of October
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 2nd Oct 2004 21:08
Ah I didn't know they changed the DEP (except to solve the .NET issues they had).
Seems that it's very likely that the next 32bit CPUs will support DEP, too.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 2nd Oct 2004 21:12
According to the DEP tab, non-64 bit processors have DEP emulated in software...


Come to the UK Convention on the 23rd & 24th of October
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 2nd Oct 2004 21:26 Edited at: 2nd Oct 2004 21:26
Yeah software enforced DEP. Although according to MS it's different to the hardware enforced DEP.

Quote: "Hardware-enforced DEP

Hardware-enforced DEP marks all memory locations in a process as non-executable unless the location explicitly contains executable code. There is a class of attacks that attempt to insert and execute code from non-executable memory locations. DEP helps prevent these attacks by intercepting them and raising an exception.

Hardware-enforced DEP relies on processor hardware to mark memory with an attribute that indicates that code should not be executed from that memory. DEP functions on a per-virtual memory page basis, usually changing a bit in the page table entry (PTE) to mark the memory page.

The actual hardware implementation of DEP and marking of the virtual memory page varies by processor architecture. However, processors that support hardware-enforced DEP are capable of raising an exception when code is executed from a page marked with the appropriate attribute set.

Both Advanced Micro Devices™ (AMD) and Intel® Corporation have defined and shipped Windows-compatible architectures that are compatible with DEP.

Beginning with Windows XP Service Pack 2, the 32-bit version of Windows utilizes the no-execute page-protection (NX) processor feature as defined by AMD or the Execute Disable bit feature as defined by Intel. In order to use these processor features, the processor must be running in Physical Address Extension (PAE) mode. The 64-bit versions of Windows XP uses the NX processor feature on 64-bit extensions and certain values of the access rights page table entry (PTE) field on IPF processors.

It is hoped that all future 32-bit and 64-bit processors will provide support for hardware-enforced data execution prevention. Microsoft continues to work with processor vendors to encourage the adoption and development of DEP technologies.

Software-enforced DEP

An additional set of data execution prevention security checks have been added to Windows XP SP2. These checks, known as software-enforced DEP, are designed to mitigate exploits of exception handling mechanisms in Windows. Software-enforced DEP runs on any processor which is capable of running Windows XP SP2. By default, software-enforced DEP only protects limited system binaries, regardless of the hardware-enforced DEP capabilities of the processor."


Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 3rd Oct 2004 21:55
Lee may be interested in the idea, especially if the system wont be changed...


Come to the UK Convention on the 23rd & 24th of October
Rob K
Retired Moderator
16
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 4th Oct 2004 00:40
@Empty

How does the performance of loading DLLs from resources compare with unloading the files to the hard drive and loading them from there. I assume it will be faster, but by how much?


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
empty
16
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 4th Oct 2004 04:12 Edited at: 4th Oct 2004 04:12
To be honest, I haven't compared it yet. Of course it is faster than any other method that requires hdd access even if the Windows PE loader were faster than mine (and it probably is).

I started improving my method by pre-analysing the DLL and saving it in a "custom" format. So instead of a DLL, you'll have custom data attached to the executable that can be mapped around 20% faster compared to the old technique. Although this isn't complete yet.

Play Nice! Play Basic! Out now.

nFinity Emulator. Coming soon.
the_winch
16
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 4th Oct 2004 10:02 Edited at: 6th Oct 2004 07:10
For the original question.
The string table isn't needed once the exe is compiled. You could use this to swap the plugin dll for an indentical one with a blank string table.
Then it would be unuseable by someone else unless they wrote their own string table. You could also use cryptic function names in the dll to make it a bit harder.

Shrink dbpro exes with upx
can i scream?
DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 6th Oct 2004 10:01
Swaping DLLs for DLLs without the stringtable is a good idea.
I was thinking... Quickly create a RAMDRIVE, extract the DLLs to it, load the DLLs and destroy the RAMDRIVE. Wich brings a new question, how hard is it to create a RAMDRIVE? Is there any DLL or API call that does that?
Also, I found this:
http://www.osronline.com/lists_archive/ntfsd/thread1699.html

Cleber de Mattos Casali, game programmer.
DarkPhear is a full freeware RPG developed by me. You can download it and some game demos for free at my page: http://darkphear.cjb.net
the_winch
16
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 6th Oct 2004 11:21 Edited at: 6th Oct 2004 11:24
Using a ram disk is really no better than the current system. The only difference is at the moment the dlls in the temp dir are not deleted after loading.
It wouldn't gain you that much anyway since the dbpro exe format is very simple so it then becomes easier to just extract the files from the exe.
It will proberly allways be simple to extract the files from the exe as the format needs to be simple so they can be extracted as quickly as possible to keep loading times down. Also TGC have their own system to protect their dlls so have little incentive to improve the situation as it's only an issue for a tiny ammount of their customers, practically everything else has higher priority.

I think you would be better off looking into a solution that assumes anyone will be able to get the dll from the exe. Perhaps hiding some data in the exe somewhere that the plugin looks for. Combined with removing the string table you should be able to make it hard enough that almost all users can't get a working copy of the dll. You have a big advantage if you are the only person that will be using the dll since you can also use dbpro code to help work out if the dll is being used by a third party.

Shrink dbpro exes with upx
can i scream?
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 6th Oct 2004 13:43
Quote: "I think you would be better off looking into a solution that assumes anyone will be able to get the dll from the exe. Perhaps hiding some data in the exe somewhere that the plugin looks for. Combined with removing the string table you should be able to make it hard enough that almost all users can't get a working copy of the dll. You have a big advantage if you are the only person that will be using the dll since you can also use dbpro code to help work out if the dll is being used by a third party."


It's my belief that this kind of effort in pre-deployment is a little extreme. If you were part of a game programming project, doing such things of hiding data inside the exe and removing the string table would slow down the beta process. There should be an easier solution developed.

In this development community there are quite a few intelligent guys that are really good programmers. I think that if some ideas were tossed back and forth, and a group effort was made, a very good protection scheme could be made.

In the last two weeks I've already thought up more then 5 ways to protect the plugin dll's. Each have their own flaws and strengths. More then likely I will code out an example and post here. I'm still working on a few projects in real life, but should be able to get to this topic soon.
DarkPhear
15
Years of Service
User Offline
Joined: 15th Oct 2003
Location: Brazil
Posted: 8th Oct 2004 06:41 Edited at: 8th Oct 2004 11:31
There's something about DLL protection in upgrade 5.7 ... I will check it out.

[EDIT]
Hmm... Couldn't find any differences...

Cleber de Mattos Casali, game programmer.
Author of DarkPhear (full freeware RPG), Retro River Raid and others. Download free games and demos at my page: http://darkphear.cjb.net
IanG
14
Years of Service
User Offline
Joined: 25th Sep 2004
Location: Cyberspace
Posted: 9th Oct 2004 05:02
Quote: "Hmm... Couldn't find any differences..."


that either means:
1) they have added it so you can't see it
2) they haven't added it
3) you can't see it but it can be seen by some people

Used to be Phoenix Insane : PC Spec-AMD Athlon 2.0Ghz,GeForce FX5200 128mb,512MB of ram, Win XP Pro SP2 . Last reformat: 17/09/2004

Login to post a reply

Server time is: 2019-07-21 02:12:08
Your offset time is: 2019-07-21 02:12:08