(Edited 5/8/2022 with some changes to make sure it works on Buster / other linux distributions with sec-linux. The new stuff is in purple.) It took me a while but I finally found someone that had solved this. I am linking the solution. However, typing in a password and following it up with the one-time-password (OTP) is *extremely* user unfriendly. Anything that is hard to do to make better security actually makes worse security. Instead my approach protects the private keys with a password, and you then only use the OTP as the user’s password each login. So, here is the process. Assuming you have pivpn already installed and working with an OpenVPN configuration. Install google authenticator on the pi: sudo apt-get install libpam-google-authenticator Edit[…]

There are quite a few tools readily known to the Android reversing community. The primary one is most likely smali/baksmali. It’s an open source tool which will decompile/compile an android dex format which is used by dalvik the native Android VM, into a format known as smali, which is very similar to an assembly language. A lot of people even like dex2jar, which further enhances the experience and takes a broken down apk, and pulls out the compiled dex classes. With dex2jar you can further that and attempt to get some readable jar files. If you wanted to make it even simpler you continue with that jar and use something like JD-GUI to read those jars back into native java code and be off running. For the lazy, there’s also the apktool which does most of the above for you in a simple one-stop-shop.

These are all great tools, but what else is out there? That’s what I’ll be covering in the next few articles. Today I’d like to point your attention to JEB (http://java-decompiler.com). I discovered this back in February when it made its first public release. At the time, I was knee deep in doing Android Application Security Assessments as part of our IPA process. I was still primarily using the tools mentioned above, so it was nice not only to find something different (it doesn’t use the open source smali as the decompiler), and it’s a nice all-in-one solution for exploring the code, as well as analyzing it.

The following events are based on actual facts and actual events. Names have been changed to protect the oblivious. I would like to start off by stating that I take no pity on the individual this story is about. I refer to them as oblivious because to do what they did simply can’t be categorized in any other way. Let’s back up a week. I’ve been in need of another Android device to do some tinkering with, have a backup for my daily driver, and to have something that my son can play with and not fear total destruction (again of the daily driver). After checking with friends and co-workers if they had any spares – they didn’t – I[…]

Around this time of year, many people receive new devices and gadgets as gifts, and some of those gadgets turn out to be smart phones. But smart phone security is very tricky to pin down, as there are multiple vendors and platforms to take into consideration, not to mention the speed at which smart phone technology is evolving. So when I came across this Top 10 iPhone Security Tips whitepaper (pdf), I knew that it was probably a good thing that it attempts to target a specific platform. However, after reading through it, I think that many of the things McAfee points out can also apply to a Droid or BlackBerry. And so, by stripping away the platform-specific details, we arrive[…]

In light of all the discussions about maintaining a secure posture on trusted certificates we often times forget about the little guys. In this case I’m talking about our mobile devices. We tend to forget that these devices are just as vulnerable as our desktop/laptops. Unfortunately it’s not always easy to manage the certificates on these devices. But if you own an Android device and would like to take a little more control over what your device is trusting read on to find out how you can do it.

I recall back in the 80s, when “computer virus” was a new term, “antivirus software” hadn’t been invented yet, nobody had coined the term “malware”, and Apple was still running incomprehensible TV ads. It’s ironic: Apple computers were the predominant home computers when computer virii and malware were invented. And yet, the first malware kit for the MAC OS (or, more accurately, OS X), Weyland-Yutani BOT, was only released earlier this month. For obvious reasons, I’m not about to download it and play around, but preliminary reports indicate that this kit may have caused a significant increase in OS X malware. And supposedly, kits for iPad and Linux are just around the corner. To be honest, I find the iPad[…]