• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Which language should I choose?

B

Blamblooga

Junior Member
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?
 
Blamblooga said:
Inject into a TCP stream to read and manipulate packets.
Basic memory reading/editing.
2D DirectX 8 manipulation
Click to expand...

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.
 
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?
 
DaveSimmons said:
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.
Click to expand...

or it could be for something like fiddler, which is awesome. and that was implemented with c#, not c++
 
DaveSimmons said:
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.
Click to expand...

That's the first thing I thought, heh. Sounds like a game bot or radar tool.
 
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.
 
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).
 
brandonb said:
But what you want is C (You can't use C++ in drivers typically).
Click to expand...

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.
 
Last edited:
brandonb said:
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).
Click to expand...

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.
 
Cogman said:
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.
Click to expand...

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.
Click to expand...

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.
 
Last edited:
brandonb said:
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.
Click to expand...

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.
 
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.
 
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top