Needed: madCodeHook Expert

[GaryGlaze2496]

Hello everyone,

A friend of mine (owner of a major Internet software company) has asked me to help him locate a skilled Windows API/Network programmer to do some advanced coding.

I immediately thought to come here, because being a developer myself, I have extreme respect for the people on this board (of course, including madshi himself).

If anyone here believes they can do either one of the following tasks, you're the guy/gal for this job:

a) use madCodeHook (or another method) to trap all outgoing Outlook Express email and modify it before going out

or

b) PREFERRED - use madCodeHook (or another method) to trap all outgoing TCP/IP traffic, and modify all emails (regardless of client) before going out.

The modifications would be as simple as adding or changing text in the message body, as defined a set of simple rules that will be given to you.

This software would need to work on all platforms, from Windows 95 to Windows XP SP2.

The preferred language would be Delphi 6 or 7 (although if you believe you can do this, but would prefer another language, that is fine).

Please rest assured that the use of this code will not be malicious in any way. Unfortunately I can not go into the details any further than this until an NDA has been signed.

They are looking to hire immediately.

Please PM me here on this board, or contact me at garyglaze2496@bluebottle.com if you think you can do this, or you know someone who can. The first qualified person to respond will be hired.

Madshi, you aren't excluded from this by any means

To whoever qualifies, if you do well, I am told there may be a long term programming position available for you (you would be able to work over the Internet).

Looking forward to getting to know some of you better!

Gary

Gary Glaze

[madshi]

Hi Gary,

that shouldn't be too difficult. Look here for a demo app which does already catch mail sending of any mail client:

http://www.blad3.ro/

Changing it to include manipulation of the mail shouldn't be a big problem.

Of course I have to add, that madCodeHook may only be used for legal purposes. So please clarify the situation with the laws in your country.

[GaryGlaze2496]

Hey Madshi,

Thanks for your response

The problem seems to be actually modifying the outgoing data, not capturing it.

Apparently, modifying the data and making it a different size than the original email can cause crashes.

If you have a solution for this, that would be great.

Gary

[madshi]

Can you give an example of what shall be changed exactly? Do you want to replace some words? Or add something? Or remove something?

[GaryGlaze2496]

Hi,

Desired result is to add something

Happy new year, and thanks for your help!

Gary

[madshi]

Adding something shouldn't be that difficult, I guess.

Try contacting the guy from: http://www.blad3.ro/ . If he doesn't want to do it, I might eventually do it - depending on how much you pay...

[dcsoft]

Hi,

Desired result is to add something

Ahh, you mean like how Google puts the ads at the bottom of gmail?

Perhaps a dumb idea, but are you just appending your data to the same buffer that is being sent out? If so, that buffer may not be big enough. Copy the original data into a new buffer, add your data at the end, then send the new buffer.

-- David

[GaryGlaze2496]

Hey guys,

Here is the code that was tried, that does not work

Essentially, it works if we try to replace 'abcd' with 'efgh', but if we try to increase the length, it seems to crash all over the place.

All that's needed I suppose is the code that will enable us to increase the length of the buffer without causing everything to go crazy...

Thanks!

Gary

P.S. As I said earlier, if you help solve this problem...you may very well have the opportunity to be hired for a programming position...if you want, of course.

Code: Select all

library WSHook;

uses Dialogs, Windows, SysUtils, Winsock, madCodeHook, madStrings;

var
	sendNextHook: function(s: Integer; Buf: Pointer; len, flags: Integer): Integer; stdcall;

function sendHookProc(s: Integer; Buf: Pointer; len, flags: Integer): Integer; stdcall;
var
	s1: string;
begin
	SetString(s1, PChar(Buf), len);
	ReplaceStr(s1, 'abcd', 'efghi');
	result := sendNextHook(s, pointer(s1), length(s1), flags);
end;

begin
    HookAPI('ws2_32.dll', 'send', @sendHookProc, @sendNextHook);
end.

[madshi]

Well, that code looks just fine to me. Are you sure that it doesn't work?

Maybe the sender is using asynchronous sending and the problem is that the string buffer gets freed too early? Can't really imagine that this would be the case, since usually only those WSA*** functions are asynchronous. Not sure, though, am no WinSock expert.

Btw, please do not use Dialogs in a hook dll. It will result in lots of VCL junk being linked into your hook dll! That's quite bad, because the dll size will grow. Also your hook dll will do lots of initialization and finalization work which is not good for a hook dll. A good hook dll should do only as much as absolutely necessary. Also try to get along without SysUtils, if possible. That saves another 20-30kb overhead.

[GaryGlaze2496]

Hey mashi,

Thanks for your quick reply!

Yes, I'm sure it doesn't work - We compiled it with Delphi7 and the latest madCodeHook, and sending email with "abcd" in it will cause the email to not be sent, and eventually screws up Outlook/Outlook Express, which need to be restarted.

Sending email without "abcd" works fine, as does changing the replace string to something that is the same length.

I know the code probably looks fine to you because we grabbed it from another thread, where you posted almost all of it.

Did you actually compile and test it on your machine?

If so, which version of Delphi did you use, and what outgoing TCP/IP did you test it on?

Thanks!

Gary

[GaryGlaze2496]

Ah, forgot to mention about Dialogs and SysUtils - we actually didn't have those initially, but threw Dialogs in for a few lazy ShowMessage calls, and SysUtils for something else

Anyway, you're right, we don't need those...but removing them doesn't fix the problem unfortunately...

[madshi]

I just had a thought: "send" returns the number of bytes sent. You need to correct that, if you change the length of the data.

Let's say Outlook sends 100 bytes and you manipulate it to 120. Your hook callback function nevertheless should only return 100 bytes, although you really sent 120 bytes. Maybe that fixes the problem?

No, I didn't test any of this.

When needing message boxes for testing please use MessageBox in hook dlls. That is thread safe and doesn't use VCL. I'm using it myself. It makes sure that there are no new problems because of VCL.

[dcsoft]

Hey guys,

Essentially, it works if we try to replace 'abcd' with 'efgh', but if we try to increase the length, it seems to crash all over the place.

How exactly does it crash? Have you got a call stack?

The send() documentation says this:

For message-oriented sockets, care must be taken not to exceed the maximum packet size of the underlying provider, which can be obtained by using getsockopt to retrieve the value of socket option SO_MAX_MSG_SIZE. If the data is too long to pass atomically through the underlying protocol, the error WSAEMSGSIZE is returned, and no data is transmitted.

It shouldn't crash, but you could go beyond the size allowed by the socket. In that case, you need to do multiple send() calls, I guess.

-- David

[dcsoft]

I just had a thought: "send" returns the number of bytes sent. You need to correct that, if you change the length of the data.

Let's say Outlook sends 100 bytes and you manipulate it to 120. Your hook callback function nevertheless should only return 100 bytes, although you really sent 120 bytes. Maybe that fixes the problem?

No, I didn't test any of this.

When needing message boxes for testing please use MessageBox in hook dlls. That is thread safe and doesn't use VCL. I'm using it myself. It makes sure that there are no new problems because of VCL.

Good idea about the return value.

ReplaceStr() probably allocates a new buffer if the string grows. Is the Delphi heap allocator thread-safe? With all that other VCL stuff going on, perhaps the heap is getting corrupted.

Gary, try allocating a big global buffer in DllMain and use that instead of the s1 local variable. Perhaps that will fix the crashes.

Fingers crossed,
David

[madshi]

Delphi's heap allocator is thread safe, if you set "IsMultiThread := true", which is done by madCodeHook's initialization. Using Delphi's allocator in hook callback functions has never been a problem yet. Some of my demo hook dlls use that, too.