Which language should I choose?

[Blamblooga]

I've got a little bit of experience with Python and AutoIt (lol), and I'm looking to expand into a more capable language, but reduce the amount of frustrating syntax to a minimum. My current goals with programming:


Inject into a TCP stream to read and manipulate packets.
Basic memory reading/editing.
2D DirectX 8 manipulation



Should I stick with Python?

What about C#?

Oh, Delphi, do I want you?

 

[DaveSimmons]

Inject into a TCP stream to read and manipulate packets.
Basic memory reading/editing.
2D DirectX 8 manipulation

Hmm, that sounds like code for a keylogger, screen scraper, packet sniffer or other bit of naughty coding but I'm probably being cynical.

Native (unmanaged) C/C++ might be the best for low-level work since you don't need to go through a bunch of wrappers to get to the Win32.

 

[Sequences]

C/C++. I don't know about injecting into TCP streams (and editing packets) though, aren't those guarded by sequence numbers and check sums?

 

[brianmanahan]

Hmm, that sounds like code for a keylogger, screen scraper, packet sniffer or other bit of naughty coding but I'm probably being cynical.

Native (unmanaged) C/C++ might be the best for low-level work since you don't need to go through a bunch of wrappers to get to the Win32.

or it could be for something like fiddler, which is awesome. and that was implemented with c#, not c++

 

[Markbnj]

Hmm, that sounds like code for a keylogger, screen scraper, packet sniffer or other bit of naughty coding but I'm probably being cynical.

Native (unmanaged) C/C++ might be the best for low-level work since you don't need to go through a bunch of wrappers to get to the Win32.

That's the first thing I thought, heh. Sounds like a game bot or radar tool.

 

[clamum]

I've never done any messing with TCP streams but from your description, I'd go with C# if it supports the TCP stream thing.

 

[brandonb]

Don't bother.

You can't do what you want to do.

DirectX requires C++ and Windows. And the Windows TCPIP stack is protected so you can't sniff other processes packets. The only way around this is to create a fake driver/NIC on your computer (like Wireshark does) which can monitor outside of the TCPIP stack (from the other end of the connection).

App -> Winsock -> Windows (tcpip) -> Driver -> Hardware.

Anything between the App and Windows (tcpip) protects packets. You'd have to create a driver/fake emulated hardware to packet sniff. If you have no knowledge of this, you are still years away from writing one to accomplish your goal.

But what you want is C (You can't use C++ in drivers typically).

 

[Cogman]

But what you want is C (You can't use C++ in drivers typically).

C++ is used in drivers all the time. In fact, C++ is the recommended language to using in windows. See Here. In fact, microsoft has all be dropped support for C in their tools. There is a reason why they don't have a C99 compiler.

Linux drivers (mostly due to linus) are primarily written in C, especially if they are distributed with the kernel. This isn't because C++ can't do the job, this is because Linus hates C++ (see his famous hate talk about C++ and C++ developers).

However, I agree with everything else you just said.

 

[Fayd]

Don't bother.

You can't do what you want to do.

DirectX requires C++ and Windows. And the Windows TCPIP stack is protected so you can't sniff other processes packets. The only way around this is to create a fake driver/NIC on your computer (like Wireshark does) which can monitor outside of the TCPIP stack (from the other end of the connection).

App -> Winsock -> Windows (tcpip) -> Driver -> Hardware.

Anything between the App and Windows (tcpip) protects packets. You'd have to create a driver/fake emulated hardware to packet sniff. If you have no knowledge of this, you are still years away from writing one to accomplish your goal.

But what you want is C (You can't use C++ in drivers typically).

the way l2net did it was editing the hosts file to point a process at a particular IP address, and then use a loopback adapter to send all data going to that IP address back to the computer...then modify the packet stream, and send it to its original destination.

 

[brandonb]

C++ is used in drivers all the time. In fact, C++ is the recommended language to using in windows. See Here. In fact, microsoft has all be dropped support for C in their tools. There is a reason why they don't have a C99 compiler.

Hmmm. Last time I looked at it, I used the resource:

http://www.osronline.com/article.cfm?article=20#Q1

(that website, and this is their writeup)

What Language Can I Write Drivers In?

You write drivers for Windows in either C or C++. Support for using C++ is tenuous (click here to download an interesting paper on this topic written by one of the Microsoft kernel devs), but it can be done. Don't even think about trying to use another language. All the functions and data types are only defined in C/C++ header files. There are no assembly language definitions provided, so you can't use assembly language, either.

Further, it seems that the Microsoft Visual C++ compiler is a lot more rigorous in terms of catching ordinary errors than the MSVC compiler. So, even though it's probably best for most people to write drivers in "plain C", it's also probably a good idea to name your files *.cpp, to gain the added rigor that the C++ compiler provides.

That was when I was interested in writing a file system driver.

That website you linked Cogman looks much easier than when I looked at it last, and there are actually templates in Visual Studio now. That's awesome.

 

[Cogman]

Hmmm. Last time I looked at it, I used the resource:

http://www.osronline.com/article.cfm?article=20#Q1

(that website, and this is their writeup)



That was when I was interested in writing a file system driver.

That website you linked Cogman looks much easier than when I looked at it last, and there are actually templates in Visual Studio now. That's awesome.

Really good points in your link. It is true that you can't (well, shouldn't) use all of C++'s features in a Kernel level driver. That is still true today. Generally, you are supposed to write a small low level driver in kernel mode then do all of your complex logic in a user mode. Things like a filesystem driver would be pretty much entirely written as a user mode driver.

This was solidified with Windows Vista (which postdates your article). Microsoft's support for C++ and drivers has only gotten better as time has went on.

 

[BrightCandle]

C and some of C++ basically. Everything you are looking to do is at the OS level making C basically the primary choice for this. You could also use something like D but C is the big language in this area and nothing new has replaced it for this purpose.

 

[Bulldog13]

http://web.archive.org/web/20110613....com/archives/how-i-built-a-working-poker-bot

http://web.archive.org/web/20110613...ives/how-i-built-a-working-online-poker-bot-2

http://web.archive.org/web/20110613...ives/how-i-built-a-working-online-poker-bot-3

http://web.archive.org/web/20110614...ives/how-i-built-a-working-online-poker-bot-4

http://web.archive.org/web/20110613...ives/how-i-built-a-working-online-poker-bot-5

http://web.archive.org/web/20110624...ives/how-i-built-a-working-online-poker-bot-6

http://web.archive.org/web/20110614...ives/how-i-built-a-working-online-poker-bot-7

http://easyhook.codeplex.com/

The stuff you describe is a long journey from what you might be doing in Python, but good luck.