HelpMaking A Loader

Posts 1–15 of 18 · Page 1 of 2

Making A Loader

Hey does anyone know how to make a loader using c#?

Well,

you'll need some sort of authentification, so probably a PHP script with some database. In C# you'll use HTTPWebRequest to login, maybe obtain the dll, ...

Next, if you want to inject it via C# aswell, you'll have to look into WinAPI (LoadLibrary, WriteProcessMemory, CreateRemoteThread, ...) this should get you started.

Have a nice day,
UniveX

Originally Posted by univex

Thanks for your help

you didn't specify which loader are you trying to make, but above your last post that guy guessed what were you talking about.

you don't need to make trash like an online login system for a loader, just save your dll in the resources of your loader program, export the dll from resources when you detect your process as opened and then save the dll where do you want, eg. in a temporary folder.

mainly what you need to use to inject your dll is: OpenProcess, CreateRemoteThreadEx, GetProcAddress, VirtualAllocEx and WriteProcessMemory.

... p/invoke them like this:

Code:

[DllImport("kernel32", CharSet=CharSet.Ansi, ExactSpelling=true, SetLastError=true)]
static extern IntPtr GetProcAddress(IntPtr hModule, string procName);

Sending requests to your website without any protection is unsafe as people can sniff the packets with any free tool and then crack it easily with it.

@Azuki I would consider that doing some php forms to interact with your database would be by itself an high protection. It would be one of the best ways to implement an online login system in an application. If you directly let your application communicate with the database, I would take less than 60 seconds to get your essentials database username and password.
Doing an interface between database and php, and then an interface between PHP and C# is enough. If someone gets the link of your php forms by using a sniffer, he can't do so much -> there are some of countermeasures ... checking the useragent, limiting requests.

Originally Posted by javalover

@Azuki I would consider that doing some php forms to interact with your database would be by itself an high protection. It would be one of the best ways to implement an online login system in an application. If you directly let your application communicate with the database, I would take less than 60 seconds to get your essentials database username and password.
Doing an interface between database and php, and then an interface between PHP and C# is enough. If someone gets the link of your php forms by using a sniffer, he can't do so much -> there are some of countermeasures ... checking the useragent, limiting requests.

User agent string can easely be spoofed and you only need one sql statement. Those are weak counter messures.
reg expr. + a full fledged ssl login system sounds a bit saver to me

I also higly reccomend looking into phpids (intrusion detection System)

Originally Posted by Azuki

Sending requests to your website without any protection is unsafe as people can sniff the packets with any free tool and then crack it easily with it.

That's when you add protection to your tool.
Anti debugging
And other Anti features.

And no matter how much effort you put in, It will always have a chance of getting cracked, It's all about the experience of the team/person who's cracking it.

Originally Posted by _NightWare

User agent string can easely be spoofed and you only need one sql statement. Those are weak counter messures.

I have doubts about you know what spoofing is. You can spoof it, but how do you get the UserAgent? Which SQL statement are you talking about? Please, can you have the effort to elaborate?

reg expr. + a full fledged ssl login system sounds a bit saver to me

I also higly reccomend looking into phpids (intrusion detection System)

A bit of etymology. Einstein says:

Everything sould be made as simple as possible, but not simpler

What does this mean, for you?

This is the opposite of a saver protection. I don't see why to make this, it would be just a wastage to do glaring things like this when there are simpler methods. And, just to say, SSL is also vulnerable to the heartbleed bug -> it is probably becoming obsolete, TLS is considered as the new version of SSL with more improvements. Heartbleed bug let you see important datas from a SSL secured server. TLS 1.0, 1.1 and 1.2 are not vulnerable to heartbleed bug.

A simple UserAgent with a checker is probably breakable by reversing the program or using a sniffer, this is what you didn't say.

Yes, you can do something simpler without this. You will only need to get some simpler and efficient ideas to protect your interface: an hash checker as parameter which validates other parameters you pass, a generated UserAgent which contains some datas which you will decrypt in php and then validate them, and other.

Summarizing, if you can cleverly and properly handle an UserAgent which brings padded data as obfuscation, you can still be safer.

Originally Posted by javalover

I have doubts about you know what spoofing is. You can spoof it, but how do you get the UserAgent? Which SQL statement are you talking about? Please, can you have the effort to elaborate?

Why would you have doubts over if I know what something means?
And why would you use an SQL statement to get a UserAgent string? Now I'm beginning to get doubts.
You use php to get your ua. You use SQL to query a database.

Originally Posted by javalover

And, just to say, SSL is also vulnerable to the heartbleed bug

Heartbleed? 2014 much? Irrelevent now. Plus it results from improper input validation.

Originally Posted by javalover

A simple UserAgent with a checker is probably breakable by reversing the program or using a sniffer, this is what you didn't say.

I said spoofing, I did not say how. Is that relevant? I proved my point by saying it's possible.

Ofcourse you can obfuscate your UA. or put time related data in it. But why would you not put that in the "password" <- wich I assume would not be static.

Originally Posted by javalover

Everything sould be made as simple as possible, but not simpler

So why re-invent the wheel?

That's my view on it atleast. Heartbleed is very irrelevent, and re-inventing the wheel is not a smart thing to do for an database connection.
I said it before, and I'll say it again.

look into phpids (intrusion detection System) and you'll see it's all there. well, exept ofcourse the connection to the server itself, forwich you would use SSL with the strongest cert you can get. Also you do cert checking on the server side.

Why would you have doubts over if I know what something means?

Because it's obvious I can use a custom UserAgent. Maybe you were trying to say how to get the UserAgent that will be set on the website?

And why would you use an SQL statement to get a UserAgent string? Now I'm beginning to get doubts.

I'm not sure how you are interpreting what I wrote. Don't invent strange things, I was quoting this:

Originally Posted by _NightWare

you only need one sql statement.

which sql statement were you referring to? Do you know what were you talking about?

You use php to get your ua. You use SQL to query a database.

Wow, seriously? How did you _mind_ I didn't know how to check the UserAgent of an user which is browsing my website? Why are you strutting about this?

I proved my point by saying it's possible.

Saying you can spoof an UserAgent is like saying it's _possible_ to use a custom UserAgent, it is superfluous and pointless. Saying you can get the right UserAgent which validates your request to the webserver has more sense.

Heartbleed? 2014 much? Irrelevent now.

Many websites still use an old version of OpenSSL, so it's still relevant.

Plus it results from improper input validation.

Who did ask it?

But why would you not put that in the "password" <- wich I assume would not be static.

Because the implementation will be muddler and conventionally wrong. You can customize your UserAgent, why shouldn't you do it?

So why re-invent the wheel?

What am I re-inventing?

Heartbleed is very irrelevent

Till this year, it is relevant. Maybe in 10 years it won't, but it is still relevant. You probably don't have any conception of this.

look into phpids (intrusion detection System) and you'll see it's all there. well, exept ofcourse the connection to the server itself, forwich you would use SSL with the strongest cert you can get. Also you do cert checking on the server side.

1. PHPIDS is not maintained since 4 years.
2. PHPIDS is vulnerable to XSS, LFI, IP spoofing, and mostly to CRLF injection attack, look at point 1.

At least, if you want to use something like PHPIDS, look at the forked versions.

Summarizing, you are suggesting glaring and bad methods to do the work, and this citation:

Everything sould be made as simple as possible, but not simpler

would lose its meaning.

Don't tell me to hide a pen you put it into a strongbox.

- - - Updated - - -

Limiting requests for a bunch of time is better and clearer as I've already said. Mostly I would consider doing an UserAgent checker if you want to make it more secure.

p.s: Obviously you should consider this:

SSL is also vulnerable to the heartbleed bug

as a jargon. I mean that who uses that old OpenSSL as implementation is vulnerable.

Originally Posted by javalover

Because it's obvious I can use a custom UserAgent. Maybe you were trying to say how to get the UserAgent that will be set on the website?

I'm not sure how you are interpreting what I wrote. Don't invent strange things, I was quoting this:

which sql statement were you referring to? Do you know what were you talking about?

Wow, seriously? How did you _mind_ I didn't know how to check the UserAgent of an user which is browsing my website? Why are you strutting about this?

Saying you can spoof an UserAgent is like saying it's _possible_ to use a custom UserAgent, it is superfluous and pointless. Saying you can get the right UserAgent which validates your request to the webserver has more sense.

Many websites still use an old version of OpenSSL, so it's still relevant.

Who did ask it?

Because the implementation will be muddler and conventionally wrong. You can customize your UserAgent, why shouldn't you do it?

What am I re-inventing?

Till this year, it is relevant. Maybe in 10 years it won't, but it is still relevant. You probably don't have any conception of this.

1. PHPIDS is not maintained since 4 years.
2. PHPIDS is vulnerable to XSS, LFI, IP spoofing, and mostly to CRLF injection attack, look at point 1.

At least, if you want to use something like PHPIDS, look at the forked versions.

Summarizing, you are suggesting glaring and bad methods to do the work, and this citation:

would lose its meaning.

Don't tell me to hide a pen you put it into a strongbox.

- - - Updated - - -

Limiting requests for a bunch of time is better and clearer as I've already said. Mostly I would consider doing an UserAgent checker if you want to make it more secure.

p.s: Obviously you should consider this:

as a jargon. I mean that who uses that old OpenSSL as implementation is vulnerable.

Seems like you're the kind of person who is not open to suggestions

maybe you didn't read what phpids stands for, but unless your internet protocol has a 3 way hand shake(wich ssl has) everything is vulnerable to ip spoofing xD
And everything is vulnerable to xss unless you validate inputs.

Originally Posted by javalover

Don't tell me to hide a pen you put it into a strongbox

Sadly that is exactly what you should be doing on the internet.

Be sure to send me a pm once you made a database online using just what you described

oh and I'm sorry I didn't know everything I said is wrong unless I spelled it out for you
ps. I'm done wasting time on someone who doesn't know how half the stuff he says works

Originally Posted by _NightWare

Seems like you're the kind of person who is not open to suggestions

I don't see the reason why I shouldn't criticize your suggestions.

Originally Posted by _NightWare

maybe you didn't read what phpids stands for

Maybe you didn't read it is an obsolete project, no longer mantained and has many vulnerabilities. Repo: https://github.com/PHPIDS/PHPIDSⓘ.

Originally Posted by _NightWare

but unless your internet protocol has a 3 way hand shake(wich ssl has) everything is vulnerable to ip spoofing

This is wrong. The 3 way handshake is used just for TCP connection initiation. The actual SSL tunnel negotiation costs a 4 way handshake. And a 3 way handshake wouldn't prevent IP spoofing, it would make the connection just harder to spoof. A good firewall with some other rules like ingress filtering to be set is enough to do all you can to prevent IP spoofing.

Originally Posted by _NightWare

Sadly that is exactly what you should be doing on the internet.

Not when you don't need to.

Originally Posted by _NightWare

Be sure to send me a pm once you made a database online using just what you described

Why?

A loader is just an injector that's using a library from your resources, or one that you'll download from a server.

Here's a good and simple injection library posted on MPGH that you can use.

http://www.mpgh.net/forum/showthread.php?t=531732