I have graduated from hover testing to actually flying controlled around a field. Strange but I always thought the challenge with this project would be building the aircraft and software. It turns out flying is not as easy as it looks but I feel like I’m starting to get the hang of it. Meanwhile, it gives me some time to think about what I can do with a small aerial platform from a security angle. Anyway, this has been a really fun project.
I checked in some minor improvements for DeepViolet. DeepViolet is now packaged in a couple of different ways so you can quickly try it yourself. One executable runs the DeepViolet from the UI for fast spot checks. The other runs DeepViolet headless from the command line and useful in the *NIX script environment.
A new jar archive has been added, dvUI.jar. To get up and running quickly make sure you have Java 1.8 installed, download dvUI.jar to your desktop, double-click and the DeepViolet’s interface will display. Alternatively you can start DeepViolet UI from the command line like this…
Don’t care much for user interfaces, like to script everything you do, no problem. DeepViolet can be run headless from the command line. To run do something like this…
java -jar dvCMD.jar -serverurl https://test.com/
Photo: DeepViolet command line example
Where the the value of the serverurl parameter is the server you want to test.
If anyone knows of any open source projects to process ASN.1 data types send me a note. I rolled my own code to process the common object types I encountered mostly from reverse engineering and scarce documentation I could find.
Not too long ago I finished up a Raspberry PI project, Tracking Aircraft on Raspberry PI. I have been thinking about a next project. Most of us know about drones the military uses. If your a tech junkie like me you have probably watched a video or two of RC hobbyist flying multi-rotor camera platforms. If your starting you might not be aware of the level of sophistication and public interest in this area. Multi-rotor copters are not a fad they are taking the world by storm. My interest was peaked when I saw an (First Person View) FPV multi-rotor racing video.
Multi-rotor racing is a crazy fast hobby where pilots wear VR type goggles or attach small profile monitors on their transmitters. The pilot’s view while flying is out the front of the aircraft. Flying is similar to playing a first person shooter video game. No point in explaining it, see for yourself (video).
Watching drone racing videos got my blood pumping so I started reading some articles on multi-rotor craft. One of the articles I read recommended buying a low cost aircraft and get some flight time before you invest in anything expensive. Yes, I know when your driving you don’t ask for directions. You probably don’t read manuals for anything. This is different and it’s extremely good advice! Flying these craft is not as easy as you might believe and crashing a low cost aircraft is far better than crashing an expensive aircraft. Following is my favorite rookie Youtube crash video. I don’t know whether to laugh or cry.
Keep in mind the DJI Inspire 1 aircraft featured in the Youtube video retails around $3000 USD. The entire aircraft is not destroyed but I’m sure it’s an expensive lesson. You have to walk before you can run is the saying. With this out of the way, I will describe a few of my experiences so far. To start my flight training, I purchased an Air Hogs X4 (photo top of page) for around $80 USD. The unit is very light weight. It’s made from styrofoam like a drink cooler. It fly’s reasonably well. I broke some chunks of foam from some hard crashes. The foam was easily repaired with a hot glue gun. Getting some flights under my belt on the X4 was helpful. After some time on the Air Hog X4, I came upon the Hubsan X4. Don’t let the common X4 in the aircraft name fool you; both the Huban and Air Hog are entirely different aircraft.
Photo: Hubsan X4 H107C
The Hubsan X4 is a really cool Ready To Fly (RTF) quadcopter. Mine cost me about $80 USD at a hobby shop. I purchased H107C. There are 3 models you can choose, 1) the standard quad model H107L, 2) quad with a camera model H107C, 3) and FPV equipped quad H107D FPV X4. All 3 aircraft build upon the same basic X4 design and all fit in the palm of your hand. Both the H107 and H107D include an extra board for recording and transmitting video, respectively. I have not clocked the air time but it’s about 3-5 mins depending upon the model, conditions, and how you fly. A word on Hubsan, incredible for the price. There are some limitations for these tiny aircraft like wind. They are fairly stable under no or very light wind conditions but it’s tough to maneuver under moderate winds.
Photo: Neighborhood at 100ft (30.4m)
Again, no formal measurements but I estimate my Hubsan X4 top speed is around 25-30mihr max or 40-48kmhr. You can fly them indoors or outdoors. I cannot say enough good things about flying the Hubsan X4 and it’s the starter craft I recommend. If you crash and you will, an advantage of the light weight is they are very rugged and hard to break. Hubsan includes extra parts with the aircraft but also sells any extra you need. Extra propellers and extra batteries are handy for less down time between flights.
A few words on safety for those in the USA. For those interested FAA has some guidelines and a helpful info graphic on flying hobby aircraft. Please review any rules that may be applicable for your area before starting your own projects. Especially, any FPV projects. Broadcasting video on any of frequencies assigned to current market FPV gear likely requires an Amateur Radio License. An Amature license is more of a formality but you should be aware. Also a safety consideration is weight, my urban shot made with the Hubsan X4 that has a takeoff weight of 31g. Be kind to your neighbors, don’t fly any significant aircraft in or over urban or other populated areas. Use some common sense. And no flights over or near the White House. What the hell was this guy thinking? More on building your own later. Happy flying.
In a previous post I introduced the new OWASP Security Logging Project. The project is fresh out of the oven. At the time there was mostly broiler text on the wiki and few breadcrumbs for visitors to understand the project or it’s benefits. Since then we published some project background, for full background on the OWASP Security Logging Project see the projects, “Roadmap & Getting Involved” page.
A number of powerful logging technologies are available. The challenge with popular logging frameworks is that they focus mostly on diagnostics while security and audit are mostly an afterthought. Most developers that require security and audit logging extend popular logging frameworks for their own purposes and often with inconsistent results. Following are a few larger obstacles we considered when adopting popular logging frameworks for security and audit logging.
Logging platforms use-case agnostic Popular logging platform designers are interested in developing platforms that are most useful to the widest possible audience. As such it’s not clear to developers who use these frameworks how they should be used for security or auditing. For instance, if your logging an access failure should the message level be a WARNING or INFORMATION type message? The point is that a system written from a software diagnostics perspective is not necessarily intuitive for use in security and auditing. Often log quality varies from deployment to deployment since it left up to each application designer to implement these use-cases on their own. Sometimes these logs are little benefit for security or auditing and even worse sometimes the logs provide sensitive information attackers find helpful. Logging is non-functional requirement By non-functional requirement I mean, logging is seldom a feature the Software Development VP mandates is included on the projects schedule. Logging is something developers need when “fit hits the sham”. Comprehensive logs are tools application designers need to do a better job but not generally the focus of a project effort. Lack of domain expertise Security and auditing logs have a wider audience than diagnostic type logs. Consider for a moment that software diagnostic logs are useful to application designers whereas security and audit logs are likely more useful for the business units. Even if software developers are fortunate enough to recevie some time on the schedule to build the application logging system, development may not have the required skills to build such a system. Last but not least, loose a diagnostic message and it’s irritating. Loose your audit log or log the wrong information and someone receives a permanent unpaid vacation, company fines, or worse jail.
Why are we doing this? We see some room for improvement in security and auditing logging for our applications. The OWASP Security Logging Project is planning a combination of software and documentation building upon popular frameworks to guide the development community to improve the quality of software logs. If your interested to participate or learn more about the project take a look at the project wiki.