Archive for March 2016

Bypassing Antivirus With Ten Lines of Code or (Yet Again) Why Antivirus is Largely Useless

So you are probably looking at that and thinking ‘really?’ – I know how you feel. This is how I felt after I intended this to be step 1 of my tutorial and I ran it through virustotal and it returned 0/56 detection. I’d like to stress that this is an incredible simple and most basic technique, yet its success is still rather astonishing.

Alright, so antivirus is dead. We all know that. That being said, we can’t argue that over 95% of organizations are still depending on antivirus to protect endpoints. 


Is this fool proof technique? I would be inclined to say no. The bar will be raised, but a new type of cat and mouse game will begin.

Source: Bypassing Antivirus With Ten Lines of Code or (Yet Again) Why Antivirus is Largely Useless

Helium – Picture in Picture for OSX


Helium is a floating browser window that allows you to watch media while you work. Your content will never fall behind your other windows even as you switch tasks.

Imagine keeping your Google Hangouts or Slacker window above the rest while you collaborate, or watching tutorials and reading documentation while programming


Why we cannot make things less secure


A hospital in California is infected with ransomware, and forced to pay $17,000 to decrypt their own patient information. Ransomware ships with a legitimate Mac app and is remotely installed on people’s computers using the software’s auto-update mechanism. Remote administration tools are installed on people’s computers without their knowledge, and used to spy on them. Cars can be remotely controlled by hackers. Android malware steals people’s banking information. Since more and more information is stored online, identity theft is becoming easier, particularly because governmental and private databases containing personal information are regularly breached.

I could keep adding to this list, and literally never stop, because people are exploiting security problems in computer systems faster than I can type.

For the past 20 years, we’ve lived in a world where the Internet is ubiquitous, and more and more devices connect to it. At the same time, we’re still using computer systems, and an approach to security, that was largely designed for a threat model that did not include the Internet.

At the same time, computers, from the tiny smartphones in our pockets to huge data centers in far-away countries, contain more and more of our personal data.

It is to Apple’s great credit that, more than any other company, they have invested tremendous resources into making iOS an operating system that’s designed for a world in which the Internet exists.

All of this makes it particularly disheartening to see our own governments trying to undermine the work that goes into making us more secure. Not just with the lastest attacks on Apple, but also with previous actions (like the DMCA) that made security research harder, or even illegal, that targeted security researchers directly, and that made it much more difficult—sometimes impossible—for software companies to secure their products properly.

All of this doesn’t just have a direct negative impact on our security; it also has a chilling effect on future security research and development. Why should I invest any money into fixing security problems with my software, if it will just lead to trouble with the government?

We’re all vulnerable, since we’re still mostly using software designed for a pre-Internet era. There’s very little we can personally do to make ourselves more secure.

Instead of trying to fix this problem, our own governments are fighting to make us even less secure.

Clearly, this is not helping.

The magic / boilerplate trade-off

Phil Webb had an insightful tweet the other day.

Programming environments oscillate between boilerplate and magic. APIs tend to start out with all the wires exposed. Programming is tedious, but nothing is hidden. Development is hard, but debugging is easy. See, for example, the hello-world program for Win32.

Programmers get tired of this, and create levels of abstraction. Boilerplate is reduced and development gets easier. And if the abstraction is done well, debugging doesn’t get harder, or not much harder. But this abstraction doesn’t go far enough. Programmers feel like things should be easier still. That’s when magic comes in. Magic differs from abstraction in that it not only hides details, it’s actively misleading. Something appears to work one way, the desired way, but something quite different is going on. Development gets easier, but debugging gets much harder. If the magic gets to be too much, developers look to start over with something more transparent, and the cycle begins again.

The magic / boilerplate trade-off