Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Java and C++ are somewhat syntactically similarly languages that have diverged over time. Java was loosely inspired by C++, but initially didn't adopt C++'s template structures, nor did it require C++'s header/content file separation, and of course, it used the JVM and compiled to bytecode rather than machine code.
I was recently in Shanghai. Great city! Enjoyed the trip, the city, and the people. When I travel, I usually use cash, not credit. There's plenty of ATMs around, and Shanghai was no exception. One of the things that really struck me while I was there was the overwhelming presence of mobile computing. I mean, when I was on the subway in Shanghai, all I could see were the tops of people's heads. Everybody was on a cell phone.
Now I've been around. I've been on the London underground, Paris and Vienna metros, New York's subway, and Washington DC's transportation system. Sure, we all use our phones, but we usually look up every once in a while, and we don't stay on them that long. But in Shanghai, it was completely different. Mobile computing is completely integrated with modern Chinese life — in Shanghai at least. And I expect Beijing is no different.
One of the nice things about Swift 5 is the final stabilization of the ABI. This is actually a big deal. The application binary interface defines exactly how data is stored in programs, shared from libraries, things like that. It includes name decoration, class and object definitions, and so on. Now that we have a stable ABI, building tools that analyzed and manipulate these binary representations will become much, well, not easier, but not as much a waste of time. Until now, you were just about guaranteed to have any tools you created broken by new Swift versions. With a stable ABI? This shouldn't happen.
We just covered how classes are defined in Swift 5, and we discovered that they reflect the basic design in Objective-C. There are some key differences though, and one of those is member method definitions.
In a previous article, we looked at the disassembly of class creation and program semantics for a simple program that prints a string. It did expose how classes are defined and how objects are reference counted however, as simple as that example was. Now we're going to look at an equivalent Swift program
This swift program is equivalent to the Objective-C program, right down to the method names:
Fuzzing is an important capability in cybersecurity vulnerability analysis. You can use it to test applications, libraries, network services, you name it. There's a variety of tools available out there for this kind of thing, spanning both the open-source and commercial markets. That said, they still generally take a bit of work to apply to a specific problem.
Interestingly, though it's an approach equally applicable to more traditional software quality assurance, fuzzers have been more actively adopted by the cybersecurity research and development community than software testers. I'm not entirely sure why this is, but I suspect that it's because fuzzing is a much more efficient approach to vulnerability discovery when working with black-box software components than alternatives like source code analysis (especially as you'll only have access to disassembly or decompiled code rather than original code in black-box work).
Most of the time, working in cybersecurity, when we're reverse engineering an application we're working either with C or C++. Both of these languages use function semantics for method or function calls. Objective C is different — instead of using function semantics, where you use a 'call' instruction to pass program execution and state to a specific section of memory, Objective C uses message passing semantics. Let's explore exactly what that is, and how it differs from function semantics. We'll start by outlining exactly what function semantics are and how they work. To do that, we'll need to outline use of the call instruction and name mangling in C++.
C code is pretty straightforward to analyze. A function call in C will look something like this:
Today, we mess up encryption application in two primary ways. We either try to create our own (always a bad idea) or misconfigure protocols to use weak algorithms (also a bad idea, but it's surprisingly easy to do).
With respect to the first way we screw up encryption, we need to be a bit more detailed with respect to what we mean. When I say "create our own", I don't mean "try to create our own encryption algorithm". I mean, nobody's going to do this. Not that nobody can, after all the initials in RSA stand for real folks, but that it's likely that you don't know anybody who can do this. And that you don't know anybody who knows anybody who can do this. And for the most part we all realize this, so we don't try. Go us!
Cybersecurity research has, it seems, two main thrusts. Both of them seem similar at first glance, but one is more lucrative (though not as impactful) while the other has much more impact (but doesn't seem to pull in the cash). Let's give an overview of various cybersecurity careers first, and then segue into what cyber R&D is today.
From a career perspective, you can first split jobs into either offensive or defensive specialties. Now, granted, this is a somewhat artificial delineation. After all, if you work in any corporate cybersecurity department, you've got someone either on staff or on call that can analyze suspected malware or do some post-incident forensics. But generally, offensive folks do things like pen testing and vulnerability analysis while defensive folks implement and monitor cybersecurity controls and policies in organizations. We can include forensics work and malware analysis as defensive fields. They're not a perfect fit, but as they're not focused specifically on attacking systems, let's lump them in with defensive fields.
For the first time, it seems the United States has executed an open, offensive cyber campaign against a foreign target. Multiple sources have reported over the past few days, and are reporting today, that the US Cyber Command attacked the Internet Research Agency during the mid-term elections to prevent Russian manipulation of social media.
Overall, this aligns with the Trump administration's hawkish position on offensive cyber capabilities. In August of 2018, president Trump signed an order reversing Presidential Rule 20. Presidential Rule 20, enacted by the Obama administration, assembled a large, complex network of approvals needed for cyber operation approval, essentially making offensive cyber operations bureaucratically impossible. The Trump administration, guided by John Bolton, removed many of these restrictions and vastly simplified the process, leading us to where we are today.
PyTorch uses some different software models than you might be used to, especially if you migrate to using it from something like Keras or TensorFlow. This first is, of course, the Tensor concept (something shared with TensorFlow, but not so obvious in Keras). The second is the nn.Module hierarchy you need to use when building a particular network. The final one is implied dimensionality and the channel concept. Of these, I'd really like to focus on the latter its own article, so let's get the first two out of the way first.
Tensors in PyTorch are really just values, and they mirror many of the methods available on NumPy arrays — like ones(), zeros(), etc. They have specific naming conventions on instances too. For example, Tensor::add_() will add to the calling addend and adding in place, while Tensor::add() will return a new Tensor with the new cumulative value. They support list-like indexing semantics, slicing, and comprehensions as well. They convert easily too and from NumPy arrays as well via the torch.from_numpy() and Tensor::numpy() methods. They also have a sense of location and are affiliated with a specific device, and this is where things can get tricky.
Reuters wrote an interesting group of articles on Karma (a rootkit for iOS) and Project Raven (a group of ex-NSA contractors and employees who worked for the UAE). There are a couple of interesting features in this story, not the least of which is that this is the first time we've seen tradecraft migrate from tier-one cyber groups to other countries in this way. And from the looks of things, none of this was, at least initially, illegal. I expect we'll see some repercussions though, at least in the US, and likely in other countries with advanced cyber capabilities as they try to more strongly manage these capabilities.
There was one detail though, a small one, that I personally found very interesting that I thought I'd point out. In "Inside the Villa" section, Reuters goes over the process Raven used for targeting and exploitation. Step two of that process was:
So I work at the intersection of cybersecurity and machine learning. I use a variety of neural network architectures and machine learning techniques to try to create new ways to detect new malware. I've worked on other projects using machine learning and AI too.
And we have nothing to worry about.
In the first part of this series, I raised a few questions about weaponized software and how complex regulating it has become. Malware with clear criminal intent from criminal actors seems easy to regulate — you just make it or the crimes they facilitate illegal, and this has been the approach taken by law enforcement over the last few decades. But what about government approved malware from external consultants? I mean, it steals information, audio, video, and the like, just as more criminal strains. But because a central government approves it, it's not a crime to have been developed or used. Even when targeting people in different countries.
But the two smell awfully similar.
CNN and the Washington Post have both reported over the past week that Israeli company the NSO Group and their Pegasus monitoring system may have been the driving force for the detainment and murder of American resident, reporter, and Saudi dissident Jamal Khashoggi. Citizen Lab has likewise reported that Omar Abdulaziz, a Canadian resident and Saudi activist, was likewise targeted by this specific spyware.
The NSO Group, for their part, denies involvement in either of these cases. Whether that's true or not, I really can't say. I do think it's pretty clear that their products were certainly used to surveil Omar Abdulaziz, at the very least. They also claim that they sell only to governments that are approved by the Israeli government. That, I fully believe is the case.
Modern browsers use a wide range of techniques to attempt to protect the underlying operating system from browser application level compromise. This, not surprisingly, is very difficult to do today.
The browser you're using to read this is essentially a virtualized computer that runs at the user level of your computer. It has networking capabilities built in via WebSockets and asynchronous processing via Web Workers. It has persistent storage. All of this is built into the browser itself, which is used to load arbitrary and provider-defined content from around the world. Seriously — open a mainstream news site like Al Jazeera or CNN with developer tooling enabled and take a look at the network traffic. Visiting that one site results in your browser firing off hundred(s) of requests to a wide range of sites. And many of those sites you've probably never heard of.