AspieRogue wrote:
You're also gonna need em if you're going to write a file at some arbitrary location in memory that may involve overwriting something else.... If you wanted to overwrite part of one file and then part of another the OS isn't going to let you do that. Self-replicating programs are quite a bit more complex than you think, brah.
Not true. High-level languages can do this through API calls like WriteProcessMemory. Lots of malicious C++ programs still have to use WriteProcessMemory because pointers only allow you to write to memory in your process's own virtual address space. You can't use C file pointers to write past the end of one file and into another. File pointers are just a pointer to a FILE struct which contains a file handle for system calls along with other stuff used by the runtime library. They are not a pointer to a specific location on your disk. Under the hood, your C runtime library just makes system calls to write and read files, and the system calls obviously won't trash the file system. On linux, you can get raw disk access by opening the disk device (i.e. /dev/sda) with any language's file IO capabilities. On Windows you need a CreateFile API call, which you can do from any language.
AspieRogue wrote:
Now obviously you don't need pointers to RAM addresses to read and write files. But when it comes to self-replicating viral programs, the need for pointers(and not file pointers) has to do with they allow you to treat code as data. You could write a virus as a two part program with a "head" and a "tail". The cycle goes as the head writes the tail and the tail writes the head. C++ has a generic pointer that is not type specific. The head and the tail have pointers that reference each other.
But now I'd like to hear from MyFutreSelfnMe about how a virus can be written without pointers.
Effectively all languages have reference types, handles, or something along those lines. When you say pointers, I guess you are talking non-type safe pointers, which you can do arithmetic on and cast to different pointer types. It's worth noting that C# actually has these types of pointers, but you can only use them in an explicitly-declared unsafe environment and only run the compiled assembly under full-trust. However, there is almost no good reason for user-land code to use an unsafe pointer instead of a type-safe reference. You do not need unsafe pointers to treat code as data, and you don't necessarily need to treat code as data to write a self-replicating program.
AspieRogue wrote:
C# is fully objected oriented and was inspired by Java. I have to say, Java sucks because it's inflexible, pedantic, slow, and is particularly bad at user interfacing.
I have to disagree, at least if you're using C++ as your benchmark language. Java and C++ have a lot of the same GUI libraries, so I don't see what your complaint is there. As for the speed issue, I find that the ease of development of Java/C# programs more than outweighs the slight speed hit for all but some extremely specialized applications such as ray tracing. For business applications, Java/C# performance tends to be very comparable to C++, even with the overhead of the VM. This benefit to JIT compilation is that the VM can make optimizations that a regular compiler can't. For example, it can check if the processor supports SEE at compile-time, where a regular C++ compiler has to compile to the lowest common denominator. Also, a C#/Java compiler can make optimizations that a C++ compiler cannot due to C#/Java's strict type-safety.
AspieRogue wrote:
In addition to pointers, C++ retains the procedural aspects of C which makes writing user interfaces a lot easier and more efficient. If you have program that reads and processes user input it's SO much easier to do that with C++ and even python(using the interpreter)than with Java or C#. The void* pointer in C++ is very convenient as it offers the programmer a generic data type.
C# and Java retain the procedural aspects of C, too. They're called static methods. I don't see how OOP makes writing user interfaces harder, either. If anything, I would say the opposite is true. Compare MFC to win32 API calls or QT to GTK+. C#/Java have the object reference which is also a generic reference type. The difference is that in Java/C# you can't cast an object to anything but its underlying type and you can't directly set the memory address of the reference, which is pretty much only necessary if you have to deal with memory-mapped IO (embedded or system level programming) or have strict control over allocation patterns (stack vs heap). You're right that C++ tends to be convenient for certain classes of viruses, and you certainly couldn't write shellcode in Java/C# though you could use them to inject that shellcode. Still, most programmers are not writing these types of programs and greatly benefit from the higher level of abstraction provided by C#/.NET. Development time is expensive, and higher level languages with good libraries save tons of time writing and debugging code. At my company, we will generally just add a new server to the cluster before using my time for profiling and optimization.
AspieRogue wrote:
I've heard that many hardc0re programmers and compuSci buffs have a very long opinion of Java. I've heard from some inside sources that Java was specifically create to catch bugs that no-so-good programmers would miss. Java is mainly used for internet programming as well as cellphone apps. I'm allowed to have my opinions, aren't I?
You say that like catching bugs is a bad thing. Bugs happen, even to good programmers. Why do you think we have memory protection? Operating system designers and processor manufacturers go through great lengths to stop bugs in non-type-safe programs from interfering with other processes. Basically, each process has its own address space (so even if two processes have a pointer to the same memory address, it maps to two different pages of physical memory). Keeping track of these mappings is computationally expensive, which is why windows and linux are designed in such a way as to minimize context switching (having monolithic kernels, reserving a portion of each process's address for the kernel, etc). Are you against memory protection, too?
03 Jun 2012, 1:09 pm
