Hackers weigh in on programming languages of choice Never mind what enterprise programmers are trained to do, a self-defined set of hackers has its own programming language zeitgeist, one that apparently changes with the wind, at least according to the relatively small set surveyed. Members of Europe's Chaos Computer Club, which calls itself "Europe's largest association of …
So, a language is successful if hackers use it?
Hacking is an activity with different requirements from other programming activity, so one would expect the language preferences to differ. Hacking, I expect (not something I've ever been interested in doing) involves quite a bit of file manipulation and command execution, so more "typical" programming languages wouldn't be terribly useful. Perhaps in the past Perl rated higher?
Many proof of concept scripts seem to be written in Python (perhaps because it is quick and dirty?). However I imagine many hackers (and crackers) are extremely proficient in C, C++. Mainly because they must be in order to identify buffer overflows and things like that.
Many probably are familiar with assembly (incl a number of different architectures) too, at least via disassemblers, tools like Radare2.
The reason why Perl and Python are used is because if you get a foothold in a system enough to drop a text file off and submit it to any sophisticated interpreted language, Perl and Python (amongst other capable languages) allow more access to network and OS facilities than a normal shell.
It is quite possible (and I have done it) to write things like packet and message forwarders in a language like Perl, opening a port on the outside interface of a system, and shuffling packets to the internal networks. And this is just the tip of the iceberg.
This is not possible using something like ksh88 (although it may be possible in ksh93, with it's dynamic library linking).
The thing about interpreted languages is that you don't need to know the underlying architecture of a system, or rely on a compilation system on your first foothold, in order to perform sophisticated attacks. The high-function interpreted language give you all the facilities you need.
Where hackers use C++ and other compiled languages is for external attack tools like port scanners and brute force tools. But, in order to use such languages to run things once you are in a system, you have to either know in advance the internal architecture of a system so you can compile commands in advance, or use a resident compilation tool on that system, something that should never be allowed on a system on a boundary.
I'm sure there have been multi-layer attacks that have gained a foothold, inserted precompiled tools such as a minimal compiler, then sent programs through to compile in situ, but it's easier just to use something like Perl if it's on a system.
If it were possible, I would completely ban high function interpreted language runtimes on boundary systems in an environment, but nowadays, so many admin tools rely on these runtimes that it's just not possible.
@Peter_Gathercole
Quote: "....use a resident compilation tool on that system, something that should never be allowed on a system on a boundary...."
Quote: "....ban high function interpreted language runtimes on boundary systems..."
Sensible, reasonable advice.
.....but self-evidently advice NOT taken by the development folk at SolarWinds!!
.....and one wonders how many other developers of enterprise software don't even understand the advice!!
.....and then there's Ken Thompson's observations (in 1984!): https://wiki.c2.com/?TheKenThompsonHack
If it were possible, I would completely ban high function interpreted language runtimes on boundary systems in an environment, but nowadays, so many admin tools rely on these runtimes that it's just not possible.
Seeing as you fairly easily install them as a single binary on a compromised system that's not necessarily going to help.
That reminds me of the tale of the browser based botnet which turned into the world's largest Scheme deployment. The miscreant wanted a highly functional interpreter in the target machines so simply deployed a minimal interpreter as a binary. Of course it helped that the target was exclusively Windows PCs hence a known runtime environment, but despite this the advantages of having the ability to push and live patch updates without need to compile made it worthwhile.
I disagree with the survey in a number of respects.
The UNIX Shell and Bash are programming languages, albeit rather specialized ones that rely on, and manipulate other external tools. But it is possible, and I have, written programs just using the shell itself, without calling other tools (you do this when trying to work out what is wrong with a system unable to launch other programs). It's rather a hair-shirt experience, but it is possible.
But I doubt that a shell us used for much more than marshaling other tools when people are hacking systems. It may be the first level of automation available to a hacker, but it's extremely unlikely that a shell script itself will be the active tool performing any hack (at least not unless there are stupid mistakes made by the administrators).
But I would wonder who in their right mind would define Vim as an Integrated Development Environment (IDE)? It's a sophisticated editor, but as far as I know, it's not even as integrated as electric-c-mode and the multi-buffer compilation system using make in Emacs. At least in Emacs, you have assists that allow you to capture the errors from a compilation, and then parse them to take you to the relevant line in the source, and even use the Grand Unified Debugger mode for using something like dbx.
A quick scan did not find anything like this available for Vim.
I have used Vim since it was vi.
It is very definitely not an IDE.
I was surprised that it was even mentioned as such.
Netbeans, Idea & Android Studio, Eclipse, Visual Studio, XCode. I use them all in varying degrees but just use Vim and TextWrangler as shell editors.
Have a beer for commenting before I got to it!
You don't use it as an IDE, but it can be turned into an IDE piecemeal via plugins if desired. For example, I recently discovered that there are plugins for VIM that support Visual Studio's language server protocol, giving you features like instant syntax checking, documentation, and completion. Not easy to set up, and not necessarily always worth it, but I've found the Haskell one quite useful.
I've been using Vim since it was ed on edition 6 and 7 Bell Labs. UNIX, (well conceptually at least, ed was substantially re-written to become ex, onto which the visual code was grafted to make vi).
I still wonder what Bill Joy's vi re-write was going to be like if he hadn't lost the code.
Even stock vim comes with the builtin :make command, which will drive make-based toolchains on most platforms with IDE-like behavior, building the target and scraping warning and error messages, which can then be navigated in the source using the :c* commands.
And stock vim comes with a lot of filetype and syntax macros and plugins, for things like syntax highlighting. And fancier plugins such as netrw and tohtml. And Towers of Hanoi.
Personally, I describe my IDE as "bash plus vim plus every other CLI program on the machine". But vim has IDE-like features, at least.
If you go back to DOS, where IDEs seem to have gained a foothold (due to the platform lacking any multi-tasking so it did need to be "all-in-one") and compare Vim with Borland Turbo C and it's cult classic IDE; I don't see too much in it in all fairness.
Then compare this with Watcom Vi (of the day) and there is a clear difference.
In many ways that is why I prefer (n)vi and tmux for my work because Vim does feel a bit too heavy.
Using a standard terminal on a UNIX system at a contemporary time to the IDEs you mention, while the OS was multitasking, the users session was not really. Before the concept of an IDE, the cycle was edit-save-compile-check-edit(again), as separate steps issued in sequence and repeated until completion.
Of course you could remain in your editor, and issue the compile without returning to the shell, but the first thing that I saw that really looked like an IDE on a terminal was Emacs, with it's multi-windowing, multi-buffer interface that allowed you to have the source in one window, and the compiler output in another, and step through the errors one by one in step between the windows. As long as the terminal had cell addressable cursor movement, Emacs was almost certain to be able to handle it. But the overheads were quite high.
Have a beer - but only the one, or you'll be up all night.
Pro tip: if your doctor puts you on a diuretic, ensure you take it in the morning rather than mistakenly taking it just before going to bed. The latter will ensure you understand that "up all night" has a very different meaning from when you were a young man.
My Uncle gave me a DAI personal computer in 81. So I've been programming for 41 years on my own machines. Professionally for 33years. I started being taught intermittently to program by my uncle over the four years prior to that on his mainframe (he had his own software company). He would sit with me and we would write small programs to turn lights on and off or create moving shapes on the single line led matrix.
Only 47 years, but my first computer is literally in a museum, CDC 6600, now in the Science Museum in London, unsure if on show now.
MNF Fortran Scope OS. Sent punch cards (IBM port-a-punch) by post, print out came back the following week, First program Taylor Maclaurin series.
One guy, got it right first time, not me, a syntax error.
Are they sure? A real Hacker would have entered many times, and had some fun with the responses given too.
But using Javascript / HTML / CSS apparently makers you a "hacker" these days, or at least it does in the eyes of 30% of those who consider themselves to be one. As another old fart who's been coding for about 40 years, I'm detecting a few wannabes amongst these responses, unless of course the results have actually been hacked. But I doubt this - I would be expecting to hear that 75% are using INTERCAL or Brainfuck if they had the true hacker mojo.
Shell first, then Python, then C, then HTML, then C++?
It's quite clear from that that hacking has some rather specific requirements that are, shall we say, less likely to be encountered in the workplace.
Plus, anybody who has ever met a hacker (as in the type that walks through security like it isn't there, rather than the tinkerer type) knows that they don't refer to themselves as hackers. They don't refer to themselves at all. Experienced hackers don't need to prove anything, and certainly not share it with others.
How did I meet such a person? Noticing the use of an acoustic modem with a laptop and a public phone (note - about twenty odd years ago). Talking to her (yes, a her), she was also well aware of all the security cameras in shops and knew this one place was a blind spot. Beyond that, she said nothing. Never saw her again either.
Kudos for stating "To be fair, the survey only had 43 respondents, so it's too small to allow for representative conclusions"
So often sample sizes much smaller than that are used to generalise about something. For example the' helping experiment' was performed on exactly 15 people in New York. This does not stop Daniel Kahneman claiming that it means in an emergency 27% of people would 'rush to help' someone, as stated in his best selling book "Thinking, fast and slow" (Chapter 16), even though previously in chapter 10 he specifically warns against taking results from experiments with too small samples.
See: BYSTANDER INTERVENTION IN EMERGENCIES: DIFFUSION OF RESPONSIBILITY
JOHN M. BARLEY, BIBB LATANE,
Journal of Personality and Social Psychology, 1968, Vol. 8, No. 4, 377-383
Nowhere in this study are the respondents asked what they used their choice of language specifically to do. "For hacking" it too broad a category to be meaningful. It's obvious that Bash, C and VB would be used for quite different purposes so identification of the correlation between languages and specific purposes would have been very informative, whereas without this information the study is very uninformative..
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
