Need help developing a secure Login\Licensing system.

[Jeremy__]

This is definitely a challenge. I've been trying to create an difficult to crack login-system because it seems incredibly difficult to do. I mean, many login systems out their can be detoured by a single jump, and I wanted to challenge myself to create something which can try and avoid the easy detour of user login. Heres what I planned to do, please point of flaws and suggest some ideas.

Login: Client which the user enters login details into. If the login details checkout with the server, the server will generate a hash based on the current time (to the day), the username, and the password, return it, and store it in the user's registry. This hash is hereby called the Usr/Pass hash. (With a sault ofc)

Product Loader: A small DLL which loads the actual product into memory(The product is yet another dll). The product is quite small and potential amount of users are fairy small. The product loader will tell the server it is attempting to login while sending the user\pass hash; if the user\pass hash checks out, the server will perform the following steps to a local copy of the product:

1) Determine if the remote Product Loader has performed more than one query a day. If it has, then the product server will refuse further connections - primarily to protect the server's cpu time from being abused.

2) Determine 10 random functions to hijack - that is, 10 which will be streamed over to the product loader upon these function's execution. These functions may be run through a polymorphic engine each time they get streamed over. Further, there will be a constant of 5 others to be hijacked (So that users cannot share their hijacked functions among each-other to reconstruct the executable.) If the server ever becomes idle, it will generate more of these hijacked functions by running them through a polymorphic engine and storing them in a table.

3) Run the entire product via a polymorphism engine

4) Lightly pack using random arguments. - More just fill it with a bunch of anti-debug.

5) Sign processed product as to protect the users of the product from recieving invalid products by other servers.

6) Upload to loader.

The loader will then try to decrypt the recieved product(to assure that it is signed), then decrypt it again using the Usr\Pass Hash. Finally, it will load the library into memory and place int3 breakpoints at the address of all the hijacked routines (Actually, it will use both int3 and hardware breakpoints as to prevent users from using hw bps). Upon execution of these bps, the exception handler will tell the server a bp has occured at the given address. If the server recognizes these addresses to be those which is hijacked, it will gladly stream them over, otherwise it will terminate the connection and flag the user.

Communication level obstruction.

I was thinking of opening a given number of TCP\IP streams with the server for each transaction. All data to be transacted between the loader and the server will be signed and encrypting with the Usr\Pass hash. The data will then be divided into the seperate streams, sent over, and then recompiled and decrypted on the remote end. I was thinking of possibly even sending this data over with a stub of code preceding it that would be responsible for decrypting the data once received.

Anyway, obviously this entire thing is incredibly CPU intensive on both the server and the client, but what flaws would you see(Aside from heavy network traffic and CPU usage)?

Edited August 9, 2011 by Jeremy__

[Zer0Flag]

What about:

On Login the App sends a Username to a Webserver. If the Useranme exists this returns the HASH saved for the Username else random pseudo hash( choose good PWs like "SKJAssa9898)=(=)"2291kJ" or even longer so Brute is no risk).

The App compares the input MD(PASS.SALT.USERNAME) and if its the same it decrypts the Memory of the MainProgramm with the Input PW, If not nothing happens.

The only vuln I see there is that someone could brute the password. But with a good and long PW e.G. >50chars its impossible to do that in a short time.

Thinking mistake?

~0

[deepzero]

i think he tries to prevent his customers from unpacking the file, despite having a valid name/pw combo.

Which turns this into the quest of creating a "safe" licensing system, not a login system, imo.

I believe that the potential problems (paying for server, time for setting up the licensing system/maintaining it, angry customers) rule out the benefits.

Additionally, stuff like this can still be broken. You might scare away the bugs with this, but at the same time you`ll attract the wasps. See DemonTools Pro.

[Jeremy__]

What about:

On Login the App sends a Username to a Webserver. If the Useranme exists this returns the HASH saved for the Username else random pseudo hash( choose good PWs like "SKJAssa9898)=(=)"2291kJ" or even longer so Brute is no risk).

The App compares the input MD(PASS.SALT.USERNAME) and if its the same it decrypts the Memory of the MainProgramm with the Input PW, If not nothing happens.

The only vuln I see there is that someone could brute the password. But with a good and long PW e.G. >50chars its impossible to do that in a short time.

Thinking mistake?

~0

Hmm, thats a very valid method. But someone could just dump the product if they got even one password. I.e users could share the product with one another. One password = infinite copies of the product.

i think he tries to prevent his customers from unpacking the file, despite having a valid name/pw combo.

Which turns this into the quest of creating a "safe" licensing system, not a login system, imo.

I believe that the potential problems (paying for server, time for setting up the licensing system/maintaining it, angry customers) rule out the benefits.

Additionally, stuff like this can still be broken. You might scare away the bugs with this, but at the same time you`ll attract the wasps. See DemonTools Pro.

I totally agree, investing tons into licensing security is usually a waste of money. This is more of concept though. I am just trying to develop a more reliable login system as a challenge. Not necessarily to apply it to a commercial product with a large and inpatient user-base.

I'm aware its still breakable, as everything is, but hopefully it would hold-off the more experienced crackers from redistributing their work freely. Really, Its just supposed to discourage mass distribution of it cracked.

Edited August 9, 2011 by Jeremy__

[Zer0Flag]

Oh yes I forgot that you may need to insert a HWID into the Hash generation like MD(salt.username.pass.hwid). But well if the buyer leaks PW and HWID its tha same since someone could patch the HWID generation in the product.

~0

[Jeremy__]

Oh yes I forgot that you may need to insert a HWID into the Hash generation like MD(salt.username.pass.hwid). But well if the buyer leaks PW and HWID its tha same since someone could patch the HWID generation in the product.

~0

Yeah, I definitely don't want to make it more complex then it needs to be. HWIDs are fairly easy to fake; and it would require a lot of maintenance to get reliable HWIDs. Getting a valid HWID would be like me vs the user, who can write the lowest-level hook?

Also, I want to keep the hash-generation routine server-side so I can use things like system time and change the hash per-user baisis if it proves to better secure the system.

[atom0s]

The biggest issue with a system like this is the requirement of having an internet connection to just use a product. But it depends on what the product does to make it a more valid reason for it to be a problem. If the app itself doesn't need the internet for anything other then the security features, some may be a bit put off when they can't use it if their internet is down, or they are traveling etc.

Be weary about moving things into separate files as well. If you have the communication layer in its own DLL it will become easier for people to proxy the communication between the app and the server. Even faking the entire DLL would become possible with a simple replacement. Not to say it is hard with everything in the same app, but it is a lot easier to hook onto it when its in a separate DLL.

One other main issue is maintaining the server which will handle everything. If you get attacked (DDoS'd) your customers are out of luck and have no use of your product. Hardware failures could lead to downtime, which in turn leads to unhappy people and such. Be sure that before you plan on writing all this out; is it really going to outweigh the risk of being cracked easily vs. the headache it could become after its in place?

[Zer0Flag]

My Idea was more designed as a secure login system wich it would be and not as a licensing system.

For a licensing system I think that online checks are not the feature (all points why not have been said). And with a System designed only with Username/Password you will always have the problem of leaked "accounts".

So the way goes through a combo with HWID and alot of AntiReversing things like CodeVM , StolenCode , AntiDump , 2.nd Process wich checks the 1.te for CodeChanges or decrypts only parts of Code ( like Armadillo) etc.

~0

[Jeremy__]

The biggest issue with a system like this is the requirement of having an internet connection to just use a product. But it depends on what the product does to make it a more valid reason for it to be a problem. If the app itself doesn't need the internet for anything other then the security features, some may be a bit put off when they can't use it if their internet is down, or they are traveling etc.

Be weary about moving things into separate files as well. If you have the communication layer in its own DLL it will become easier for people to proxy the communication between the app and the server. Even faking the entire DLL would become possible with a simple replacement. Not to say it is hard with everything in the same app, but it is a lot easier to hook onto it when its in a separate DLL.

One other main issue is maintaining the server which will handle everything. If you get attacked (DDoS'd) your customers are out of luck and have no use of your product. Hardware failures could lead to downtime, which in turn leads to unhappy people and such. Be sure that before you plan on writing all this out; is it really going to outweigh the risk of being cracked easily vs. the headache it could become after its in place?

Very good suggestions. Your point about the communication layer is one I haven't thought of; but you're right if that gets emulated locally than the entire protection system has failed. Further, had I put the communication layer in another file, it would be easier to isolate it; or even predict the modules primary function by picking at the imports\exports and looking at the names. Maybe if I inlined some of the communication routines it would help. I.e, this would prevent people from detouring the one function that handles all receiving. If I inlined such a function, analyzing it would become more difficult especially if I introduced junk-code and polymorphism on each implemented inline.

It would really suck if someone managed to abuse the server because it really is a major link in the security\product chain. I would have to closely monitor the server and bandwidth usage. Hmm, not quite sure how I would deal with a DDoS attack though. The problem is, I would probably use up a lot of CPU time and banwidth offered by the host if such an event were to occur, and considering the protection does use a lot of cpu time and banwidth alone, it could cause some serious problems in service.

My Idea was more designed as a secure login system wich it would be and not as a licensing system.

For a licensing system I think that online checks are not the feature (all points why not have been said). And with a System designed only with Username/Password you will always have the problem of leaked "accounts".

So the way goes through a combo with HWID and alot of AntiReversing things like CodeVM , StolenCode , AntiDump , 2.nd Process wich checks the 1.te for CodeChanges or decrypts only parts of Code ( like Armadillo) etc.

~0

You're right, I should have said licensing and not login; as technically I am incorrect to describe my system as a login system.

It is also very dependent on the product whether an online server is a particle solution or not. We'll assume from now on that the product is very dependent on the internet.

Leaked accounts are easier to deal with. I.e, I could constrain the user to a specific IP address (Users usually have dynamic IP addresses, but I could toy with this idea a bit). There are other things too, like consider that the server is streaming a lot of the code to the user; it wouldn't stream data to two instances of the same account at a time. The possibility of two users having conflicting uses of the software would greatly discourage them from sharing and make mass distribution of account credentials unpractical. I could also flag the user if two login attempts are made from different machines. Just force them to change their password or something.

Edited August 9, 2011 by Jeremy__

[kao]

Guys already mentioned most of the potential problems. Here are few more comments that haven't been mentioned yet:

1) AV products will "hate" this sort of behaviour. Modern malware does the same thing - fetches packed file with unique MD5 from network, then loads and runs it.

2) according to your description ("The loader (...) will load the library into memory and place int3 breakpoints at the address of all the hijacked routines") - server sends both morphed executable AND list of hijacked function addresses. Reverser will happily use that information to fetch all the hijacked functions from server, then rebuild the complete executable on his machine.

[0xFF]

What about modifying the .dll and injecting it to some random process ? wouldn't it bypass all of this ?

Edit: Sorry buddy, no one here will help you secure your software, this isn't the right forum...

we'll always have ideas to bypass stupid protections (like this one)...

Edited August 9, 2011 by rotem156

[Jeremy__]

Guys already mentioned most of the potential problems. Here are few more comments that haven't been mentioned yet:

1) AV products will "hate" this sort of behaviour. Modern malware does the same thing - fetches packed file with unique MD5 from network, then loads and runs it.

2) according to your description ("The loader (...) will load the library into memory and place int3 breakpoints at the address of all the hijacked routines") - server sends both morphed executable AND list of hijacked function addresses. Reverser will happily use that information to fetch all the hijacked functions from server, then rebuild the complete executable on his machine.

I agree, this is far from A.V. friendly. Hopefully, though, the fact that the code is signed will help secure the user's system. There are a lot of products out there that do conflict with the users A.V, not to excuse itself from conflicting though..

You're right about finding the breakpoints, but its a lot easier said than done. The problem is, there really aren't many other ways to do it. Either way though, I figure doing this is no less effective than loading it up with a bunch of anti-debug routines which can be detoured with a single plugin. So, one might argue its pointless, but others might argue its a potential line of defence. However, the address of INT3 breakpoints won't need to be sent over to the loader because they're right there in the decrypted code.

What about modifying the .dll and injecting it to some random process ? wouldn't it bypass all of this ?

Edit: Sorry buddy, no one here will help you secure your software, this isn't the right forum...

we'll always have ideas to bypass stupid protections (like this one)...

I guess I'll use your post as an example of what I don't want to waste my time reading.

I've stated several times, this is a project of curiosity with no real application; I'm not asking you to help "secure [my] software." This is a forum of experienced crackers, they already have proven that they are capable and willing to point out flaws in my project. Further, this is a learning oppritunity for me. I have been looking for some ways to use encryption libraries for a while now.

You just called my project "stupid" when I have put a mere day into planning it out; I haven't even prototyped a single component of it. The comparison, relative to noithing, with no justification might I add; it really angers me when I read your post. I really don't want to waste my time reading this ignorant crap let a lone having to respond to it...

Edited August 9, 2011 by Jeremy__

[atom0s]

I guess I'll use your post as an example of what I don't want to waste my time reading.

I've stated several times, this is a project of curiosity with no real application; I'm not asking you to help "secure [my] software." This is a forum of experienced crackers, they already have proven that they are capable and willing to point out flaws in my project. Further, this is a learning oppritunity for me. I have been looking for some ways to use encryption libraries for a while now.

You just called my project "stupid" when I have put a mere day into planning it out; I haven't even prototyped a single component of it. The comparison, relative to noithing, with no justification might I add; it really angers me when I read your post. I really don't want to waste my time reading this ignorant crap let a lone having to respond to it...

Just ignore him Jeremy__ the rest of the internet has already.

Your point about the communication layer is one I haven't thought of; but you're right if that gets emulated locally than the entire protection system has failed.

Yeah, one example of this bypass was with GameGuard a while back. You could emulate the server locally and fake the package sent back and load an old version of the anti-cheat making the remote server entirely useless.

It would really suck if someone managed to abuse the server because it really is a major link in the security\product chain. I would have to closely monitor the server and bandwidth usage. Hmm, not quite sure how I would deal with a DDoS attack though. The problem is, I would probably use up a lot of CPU time and banwidth offered by the host if such an event were to occur, and considering the protection does use a lot of cpu time and banwidth alone, it could cause some serious problems in service.

CPU usage shouldn't be a problem from what you've explained so far. The server shouldn't have much issue at all processing the logins and handling the data. Bandwidth will only become a concern depending on how much data you plan on sending to the client and how its packaged. Compress everything you can to help with that.

DDoS protection is based on your provider and if they offer it. It's not something that will probably come cheap either to handle any major scale of an attack. Depending on how you expose your server as well, small attacks could lead to disastrous results. Be sure to check all incoming data for valid requests, valid data, and such. Immediately drop any connection that is invalid, don't hesitate to check for anything extra. Possibly even add some extra params to your connection strings (or however you plan to connect the server and client) to help ensure the client is a trusted source. (Such as sending an application key that is hard-coded. Not that this is any means secure, it just adds an extra level for you to use to help with fake connections.)

[Jeremy__]

Yeah, one example of this bypass was with GameGuard a while back. You could emulate the server locally and fake the package sent back and load an old version of the anti-cheat making the remote server entirely useless.

I remember this as well. I'll definitely make sure to mix up my communication layer. I'm thinking of forcing all calls to the commumication layer to be inlined now, as it would tightly bind it with the product-loader. The polymorphic engine could make it more difficult to recognized the different instances of the inlined call as well.

CPU usage shouldn't be a problem from what you've explained so far. The server shouldn't have much issue at all processing the logins and handling the data. Bandwidth will only become a concern depending on how much data you plan on sending to the client and how its packaged. Compress everything you can to help with that.

DDoS protection is based on your provider and if they offer it. It's not something that will probably come cheap either to handle any major scale of an attack. Depending on how you expose your server as well, small attacks could lead to disastrous results. Be sure to check all incoming data for valid requests, valid data, and such. Immediately drop any connection that is invalid, don't hesitate to check for anything extra. Possibly even add some extra params to your connection strings (or however you plan to connect the server and client) to help ensure the client is a trusted source. (Such as sending an application key that is hard-coded. Not that this is any means secure, it just adds an extra level for you to use to help with fake connections.)

I agree, while a strict level of control over communications could annoy some users, I'd rather annoy a tenth then all of them because of a DDoS attack. Thanks for pointing out how critical the communication layer is; I would have totally missed it otherwise. What I could do is make the connection string consist of maybe a few arguments that take a while to calculate. This would thus make it more difficult for a single machine to perform a heavy ddos attack; as the connection string would take a while to construct. The only problem I see with this though is that it would take the server the same amount of time to calculate and ensure the connection string is valid, hmm...

* Edit *

Hey, what if I sent over a piece of executable code to be product-loader every, say, 15 seconds that checks the prolog of the hijacked functions - i.e to make sure they don't consist of anything other than a breakpoint. The function can maybe also perform a hash on the exception handler and make sure that it is the top-level exception handler. Then, in-order to assure this routine was actually executed, I could force the sent over code to render a return value. If it matches what the server expects the return to be, target can resume using the server, otherwise the service is cut-off. I could genereate a random hard-coded return value and then mix it up with some junk-code so that each time it were executed remotely a different return value would be expected. I wouldn't make it so obvious as to have like mov eax, return_value; but maybe mix it up with some arithmetic operations so it more difficult to generically process the code.

Another idea, while it might be a bit risky: What if I put two breakpoints between two large sections of code with a predictable amount of time between them. When each of these bps are hit, it will go via the exception handler, which will send the address of the bp to the server. The server will then look that address up in a table (To determine why it placed a software bp there). Say these bps were placed to measure the delta time between the two breakpoint's execution. If the delta is two large, then it was probably traced though, in which case the server might cut a connection to the client.

Hmm, this is going to be a fun project. I think I'm going to start prototyping some of it soon; stupid summer school. Finals on Thursday and I'm done for the summer.

Edited August 10, 2011 by Jeremy__

[atom0s]

I agree, while a strict level of control over communications could annoy some users, I'd rather annoy a tenth then all of them because of a DDoS attack. Thanks for pointing out how critical the communication layer is; I would have totally missed it otherwise. What I could do is make the connection string consist of maybe a few arguments that take a while to calculate. This would thus make it more difficult for a single machine to perform a heavy ddos attack; as the connection string would take a while to construct. The only problem I see with this though is that it would take the server the same amount of time to calculate and ensure the connection string is valid, hmm...

Well depending on how you connect/communicate between the client the first part of the login handshake could be a call like:

attemptLogin( username, password, appHash )

The first checks would be ensuring the correct number of arguments and that the appHash is valid. If not the connection is rejected immediately. Like you said, basically anything is going to add CPU time but the sooner you kill the connection in the attempt the better. So if you can weed out bad connections faster by any means, you are best off to use at least one method to do so.

As for the DDoS issue, you can code your server to use a load-balancer to help with the bad connections. If a number of bad connections keeps coming in from the same IP you can effectively block that IP for a set period of time. Granted your server should be behind extra protection so the load-balancing shouldn't take place on the same system but on a dedicated load-balance server or firewall.

* Edit *

Hey, what if I sent over a piece of executable code to be product-loader every, say, 15 seconds that checks the prolog of the hijacked functions - i.e to make sure they don't consist of anything other than a breakpoint. The function can maybe also perform a hash on the exception handler and make sure that it is the top-level exception handler. Then, in-order to assure this routine was actually executed, I could force the sent over code to render a return value. If it matches what the server expects the return to be, target can resume using the server, otherwise the service is cut-off. I could genereate a random hard-coded return value and then mix it up with some junk-code so that each time it were executed remotely a different return value would be expected. I wouldn't make it so obvious as to have like mov eax, return_value; but maybe mix it up with some arithmetic operations so it more difficult to generically process the code.

This sounds a lot like a keep-alive check. The only downside you'll possibly face to it aside from some slight performance decreasing is the ability to emulate the check. If its like a section CRC that some protection software does, you can force the check to compare against the bad memory which will make it assume it is fine. Doing byte specific checks can be patched fairly easy and bypassed with little effort.

Another idea, while it might be a bit risky: What if I put two breakpoints between two large sections of code with a predictable amount of time between them. When each of these bps are hit, it will go via the exception handler, which will send the address of the bp to the server. The server will then look that address up in a table (To determine why it placed a software bp there). Say these bps were placed to measure the delta time between the two breakpoint's execution. If the delta is two large, then it was probably traced though, in which case the server might cut a connection to the client.

Hmm, this is going to be a fun project. I think I'm going to start prototyping some of it soon; stupid summer school. Finals on Thursday and I'm done for the summer.

This would land up being too risky based on CPU performance on the clients end. They could be doing a number of other things that could be hogging the CPU and trigger your timer to be invalid. The other issue is some apps may place system wide timing hooks that could skew your results and make the idea flawed.

Granted every protection idea is going to have flaws and drawbacks. But if you efficiently use enough of them the protection can become fairly solid in the sense that it becomes harder and harder to crack and bypass. If anything try to keep as much server sided information private (obviously). If possible rotate encryption keys on data every so often so if things start getting attacked or looked at you can flip the key on the fly.

A good start to some basics would be look at the current protection systems on the market today and look at their cracks/patches. Look into their flaws and why the flaws exist. Try to come up with ways to fix those flaws or effectively get the same desired result with different code.

[_Ghost_]

brother i am not feeling my self that i am capable to reply in this discussion. as already mentioned by masters you need to make your server 24 up... for that you need to use cloud servers they are so costly..... second thing is about cracking that licensing system is no so hard with experience....Cause all traffic on your computer can be easily captured by packet sniffer like commview etc.... packets can be modified easily.. even your protection of exe is too strong (because packet sniffing will not consider your exe is packed or not)... and if your server got hacked all license system will be down in a mint. you need to spend 24/24 hours on internet to make sure of 24/7 up-time guaranteed. the technique which is most commonly used to patch this type of security is to emulate the server to local or change the server linking to another server with same activation process or just needed activation process.. in online licensing i often saw that there is only two to three parts of your whole key is enough to patch the software

e.g 123-333-444-555 this is the key which is activated in your database for a client assume am the client. i provide the software exe to a cracker and my hwid key to him.. he will find the point where the whole key of his system is generated and ready to send to the server he can then replace activated key with his own one.. and soft should be open baammmmmmmmmmm.........

sorry for my bad English and sorry if i said something wrong

[mudlord]

I've stated several times, this is a project of curiosity with no real application; I'm not asking you to help "secure [my] software." This is a forum of experienced crackers, they already have proven that they are capable and willing to point out flaws in my project. Further, this is a learning oppritunity for me. I have been looking for some ways to use encryption libraries for a while now.

In terms of testing out your code in realtime, tried something like XAMPP? It can host a full web server locally, with MySQL+PHP and all. Perfect for testing a database driven server-based authentication system. Saves getting a server for the express purpose of testing.

[Jeremy__]

brother i am not feeling my self that i am capable to reply in this discussion. as already mentioned by masters you need to make your server 24 up... for that you need to use cloud servers they are so costly..... second thing is about cracking that licensing system is no so hard with experience....Cause all traffic on your computer can be easily captured by packet sniffer like commview etc.... packets can be modified easily.. even your protection of exe is too strong (because packet sniffing will not consider your exe is packed or not)... and if your server got hacked all license system will be down in a mint. you need to spend 24/24 hours on internet to make sure of 24/7 up-time guaranteed. the technique which is most commonly used to patch this type of security is to emulate the server to local or change the server linking to another server with same activation process or just needed activation process.. in online licensing i often saw that there is only two to three parts of your whole key is enough to patch the software

e.g 123-333-444-555 this is the key which is activated in your database for a client assume am the client. i provide the software exe to a cracker and my hwid key to him.. he will find the point where the whole key of his system is generated and ready to send to the server he can then replace activated key with his own one.. and soft should be open baammmmmmmmmmm.........

sorry for my bad English and sorry if i said something wrong

Thanks. You have made a good point about the communication layer, as atom0s has suggested, the communication layer has to be tightly bound to the loader and transactions between server and client must be well obstructed. - Once the protocol is reversed one could begin emulating a server which could lead to defeating the entire system. I've suggested some ways of obstructing the communication layer (Its near the end of the first post in the thread.) Tell me what you think of it. Thanks for your input!

I going to try to rotate between encryption keys as atom0s has suggested as well and further try to make the packets difficult to generically and programatically process. Hopefully, rotating encryption will make it difficult to sniff and analyze the protocol. I've also planned on opening upwards of 5 or six streams to the server which are to run parallel to one another. A single command of data would then be divided among the streams in a cryptic manner as to add another layer of complexity to the process.

There are other things I plan to do with this (Maybe I mentioned them earlier) but I'm losing track. When I get time to prototype this design I'm going to read through this thread and design a diagram to organize the process more efficiently.

In terms of testing out your code in realtime, tried something like XAMPP? It can host a full web server locally, with MySQL+PHP and all. Perfect for testing a database driven server-based authentication system. Saves getting a server for the express purpose of testing.

I've used XAMPP before, and you're right it would allow me to prototype it locally and much quicker. Thanks for the suggestion I'll have to keep that in mind

Edited August 10, 2011 by Jeremy__

[_Ghost_]

Communication level obstruction.

I was thinking of opening a given number of TCP\IP streams with the server for each transaction. All data to be transacted between the loader and the server will be signed and encrypting with the Usr\Pass hash. The data will then be divided into the seperate streams, sent over, and then recompiled and decrypted on the remote end. I was thinking of possibly even sending this data over with a stub of code preceding it that would be responsible for decrypting the data once received.

Dear brother did you mean encode the data when sending and decode it when it received on remote server ?? encrypted data like pass/usrname etc, bro once some one can got the generating point of encrypted data he or she will use this encrypted data to communicate to your activation server... suppose my key is 1234 it will not be generated at once. the proggy will generate 1 then 2 and then 3 in last it will say 12,123,1234 it mostly looks like MOV ECX,DWORD PTR SS:[EBP-18] the stack will be at one step back where the encryption will start.. at this point if cracker/reverser use any activated key in it. encryption will be started with new code ... ( sorry for my bad knowledge )

but you can do one thing (possibilities are still there)when it start reading username or pass or hwid encrypt it when it starts generate i mean 1 by 1 encryption... i hope you will understand what i mean

(dont think that i am against your idea your idea is superb we are pointing out all these things so that you can think how you can ourcome to all these problem)

[Saduff]

Maybe do it the way Ubisoft did with their latest DRM?

In case you're not familiar with it, here's a description:

At certain points in the game, the game sends

a request code to the server, which looks like this:

001000000100000000000c68d000000000000c68e2

And the server replies with:

001200000200000000000c68e800000000000c68ea0003

In case the reply is incorrect or there's no reply at all (i.e no connection),

the game will not continue, i.e won't trigger a certain event.

I'm not sure what the return value is used for, but it could be

used for example as a decryption key for some part of code.

There are 1910 such pairs in total, thus collecting them would take quite some time

and it requires the collector to play through the whole game.

And the collector must have a valid key to connect to the server at all.

You could encrypt all your procedures for example and then apply this scheme.

This should slow down reversers when there are lots of such value pairs.

[Jeremy__]

Dear brother did you mean encode the data when sending and decode it when it received on remote server ?? encrypted data like pass/usrname etc, bro once some one can got the generating point of encrypted data he or she will use this encrypted data to communicate to your activation server... suppose my key is 1234 it will not be generated at once. the proggy will generate 1 then 2 and then 3 in last it will say 12,123,1234 it mostly looks like MOV ECX,DWORD PTR SS:[EBP-18] the stack will be at one step back where the encryption will start.. at this point if cracker/reverser use any activated key in it. encryption will be started with new code ... ( sorry for my bad knowledge )

but you can do one thing (possibilities are still there)when it start reading username or pass or hwid encrypt it when it starts generate i mean 1 by 1 encryption... i hope you will understand what i mean

(dont think that i am against your idea your idea is superb we are pointing out all these things so that you can think how you can ourcome to all these problem)

Yeah, you hit it dead on. Well, basically, I am going to encrypt it, then sign it, and then distribute it across several different connection streams running parallel to one another in a crpytic manner. By this I mean, if I had the message "Hello World" to send to the server, It might look like the following (Though the actual implemntation would be more complicated.) Plus there would be signing and encryption as well.

Stream 1

"hlod"

Stream 2

"eor"

Stream 3

"lwl"

Notice that the message is even distributed accross the 3 streams. In the real implementation I wouldn't make it this simple, I might divide a single byte of data into one or two different bytes of data, maybe have a pattern based off of a key or something that would be rotated at specific internvals. The amount of streams open would also probably be tied in with a pattern based upon the key.

You're right though, this information could be reveresed out of the target but the primary goal of this system is to both limit the amount of knowledge one could harvest via packet sniffer and to stop someone from recognizing a pattern in sent\recieved packets. I.e, acknowledging that packet A always has a response of packet B and that packet C always has a responce of packet D etc etc to make it more difficult to emulate the server.

You also mention that once someone figures out where messages are encrypted, signed, and sent one could more easily communicate with the server. You're right, and I have decided to try and make most calls to the communication layer inlined. This will make it more difficult to detour and programatically processes incoming and out-gonig traffic. Throwing in some junk-code and running it through a polymorphism engine, I hope that it makes it more difficult to identify the data being processed by the communication routines.

Sorry if I misunderstood anything you were saying. Thanks for your input

Maybe do it the way Ubisoft did with their latest DRM?

In case you're not familiar with it, here's a description:

At certain points in the game, the game sends

a request code to the server, which looks like this:

001000000100000000000c68d000000000000c68e2

And the server replies with:

001200000200000000000c68e800000000000c68ea0003

In case the reply is incorrect or there's no reply at all (i.e no connection),

the game will not continue, i.e won't trigger a certain event.

I'm not sure what the return value is used for, but it could be

used for example as a decryption key for some part of code.

There are 1910 such pairs in total, thus collecting them would take quite some time

and it requires the collector to play through the whole game.

And the collector must have a valid key to connect to the server at all.

You could encrypt all your procedures for example and then apply this scheme.

This should slow down reversers when there are lots of such value pairs.

Good idea, if I have a lot of keys to decrypt different parts of my application, all of which would need to be queried from the server, it would definitely prolong the reversing process. The only problem I see though is that this is implemented more effectively in really large targets, but I'm designing this protection for a rather small target. I am still going to try to incorperate the method but it may need to be hacked up a bit to get it working effectivley. Thanks.

Edited August 10, 2011 by Jeremy__

[_Ghost_]

ok brother best of luck for your project :-bd i am waiting for your beta release.