Adding Custom Login

[Dave Prost]

Hi

I have a compiled app that I want to add a login program too. I've written the login program and compiled it. My first thought was adding a code cave but when I look at the login assembly it's pretty big so I'm not sure if there will be enough space for a code cave.

Is there a better way?

Can I merge the two programs together and then maybe make a jump at the start of the first program to go to the login app? Then depending on the return value continue loading app 1 or exit.

I'm just guessing here as i'm really not sure of the best way to proceed so any hints or tips would be greatly appreciated.

Thanks

D

[dn5]

Dear Dave Pros,

Can I merge the two programs together and then maybe make a jump at the start of the first program to go to the login app? Then depending on the return value continue loading app 1 or exit.

Is not secure in any case. It could be bypassed in single patching (even there are many ways to do so). Instead, do a algorithm with a heck lot of calls which do nothing but loops (Crackers hate that). Make sure to pack application too.

Other then that, nothing is secure and everything can be cracked. Good algorithm is best you can do.

[xsp!d3r]

or you can use a protected dll!!

[dn5]

Dear xsp!d3r,

On which way do you think that would save him from his application being cracked?

[xsp!d3r]

hein anything can be cracked, that's true but at least it will make it a little bit harder to be cracked

[Jeremy__]

Some ideas to make it difficult would be to:

- Implement a streaming executable design - though this is contraversal; likely you won't get this posted on any site. Unless, I suppose, its non-executable resources you're streaming. Further you may not have the bandwidth for this.

- Write the login client and the actual product seperately but make the product(not the login client) heavily dependant on the login client. I.e, you could have it act as a middle man for various APIs. I would use named pipes for this.

- You could consider writing a kernel driver and factoring it into the process - I.e maybe wrap some kernel APIs and write your own front-end to them; I and I assume several other REs would be discouraged if they found out they had to step into kernel mode. Actually, if you do go into kernel-mode, you mid-as-well detour some APIs in the SSDT to make it extra annoying - though the AV may consider this to be malicious activity (And IMHO it is.) I got away with it though in my last rootkit.

Only problem with this is that someone can virtualize the entire login client if you make it easy enough to decrypt and interpret the protocol you've decided to use across the named pipe. And doing that would be fairly easy - once you have the protocol figured out ofcourse. So the key is to obstruct the communication occuring between the product and the login client.

If I understood the networking in Puzzle Pirates correctly, I believe they opened like six different connections to the server; this really confused me in terms of understanding their networking protocol. -- I never figured it out

Other than that, you should obstruct and possibly virtualize the code in the login client and the product.

Edited July 25, 2011 by Jeremy__