Reading WndProc Messages

[John Wright]

First some background:

I have been asked to develop a program that access our data warehouse. It
requires a login and password to use so we created a custom control that is
placed on the form, the user types in their username/password, we validate
then return either true or false. The program hosting the control has no
access to the keydown and keyup events from the control. This user control
is used throughout the plant and by many developers. Now we need to use it
for the access the warehouse. We must log everyone that attempted to log
into the system and everyone who logs into the system. I cannot capture
this by the control we use, so I created a class that extends the control
and listens for messages. It inherits from the
System.Windows.Forms.NativeWindow object.

I have overridden the WndProc process and raise an event passing out the
System.Windows.Forms.Message. I need to interrupt the message that is thrown
and then log the username that was entered. I can get an ASCII value using
the WParam but it only gives me upper case and freaks out when the shift key
is pressed (usernames can be something like J0hnD03). Does anyone know how
to read this message and see what key was pressed?

Thanks.

John



One the form side, I have the following routine:

Private Const WM_KEYDOWN As System.Int32 = &H100

Private Const WM_KEYUP As System.Int32 = &H101

Private Const WM_SYSKEYDOWN As Integer = &H104

Private Const WM_SYSKEYUP As Integer = &H105

Dim WithEvents abc As Hooked


'Code I need help with
Private Sub abc_CallBackProc(ByVal m As System.Windows.Forms.Message)
Handles abc.CallBackProc

Select Case m.Msg

Case WM_KEYDOWN

TextBox2.Text &= ChrW(m.WParam)

End Select

End Sub

 

[Guest]

This user control
is used throughout the plant and by many developers. Now we need to
use it for the access the warehouse. We must log everyone that
attempted to log into the system and everyone who logs into the
system. I cannot capture this by the control we use, so I created a
class that extends the control and listens for messages.

Why aren't you capturing this stuff on the back end?

 

[ShaneO]

First some background:
.... we created a custom control that is
placed on the form, the user types in their username/password, we validate
then return either true or false. The program hosting the control has no
access to the keydown and keyup events from the control.

Hmmm.... This sounds very fishy to me. If you "created" the custom
control, then why not just "modify" the custom control to provide what
you're looking for?

If you're trying to create some kind of password capture app then I
don't think you'll find too many people here wanting to help you!

Maybe I've read this wrong, and I apologise if this is the case, but
that's how it reads to me.

ShaneO

There are 10 kinds of people - Those who understand Binary and those who
don't.

 

[schneider]

I think Windows logs all this for you now...

 

[Family Tree Mike]

First some background:

I have been asked to develop a program that access our data warehouse. It
requires a login and password to use so we created a custom control that is
placed on the form, the user types in their username/password, we validate
then return either true or false. The program hosting the control has no
access to the keydown and keyup events from the control. This user control
is used throughout the plant and by many developers. Now we need to use it
for the access the warehouse. We must log everyone that attempted to log
into the system and everyone who logs into the system. I cannot capture
this by the control we use, so I created a class that extends the control
and listens for messages. It inherits from the
System.Windows.Forms.NativeWindow object.

Capturing who tries to log in should be on the end where the control
connects. Handle it there and not in your client. After all, where are you
going to log it? Logging to the client does not make sense for tracking
hackers.

 

[John Wright]

I guess I was not clear in what I needed to do. The control I was given was
claimed to be hack proof and to keep the credentials of the user safe and
unexcessible to a developer. I wanted to prove my point it was not secure
at all. I created a class to extend the control and was able to intercept
the WndProc messages and I wanted to send them out to a file on the network
for logging to prove a point. However, I found a better way to do this. I
just turned the KeyPreview on and was able to capture the keys strokes sent
to the control. Voila, I was able to capture who logged on. Now I can see
who has tried to access the dataware house and when. This is an auditing
procedure we must follow in our industry due to the data being stored.
Since I was forced to use this control, I "hacked" it to see who was trying
to access the system. I did not log it where the control connects because
a) I don't have access to the server that validates the users and b)Only our
site needs this data.

So problem solved. KeyPreview saved it for me.

 

[Guest]

Voila, I was
able to capture who logged on. Now I can see who has tried to access
the dataware house and when. This is an auditing procedure we must
follow in our industry due to the data being stored. Since I was
forced to use this control, I "hacked" it to see who was trying to
access the system. I did not log it where the control connects
because a) I don't have access to the server that validates the users
and b)Only our site needs this data.

OK, you proved your point that the control is insecure... but that's
trivial since any keylogger could do what you did.

If you believe your type of auditing is secure, you're kidding yourself.
You should really get access to the login reports and generate your audit
logs from those.

Hacking the control to do what you've done is a poor mans solution ... and
hopefully you'll never need to rely on the data ;-)