JavaScript access to Tomcat's cookies (eg. JSESSIONID) via useHttpOnly

In Tomcat 5.* and 6.* this was not an issue, because by default Tomcat configuration did not add the HttpOnly flag to the session cookie, thus JavaScript in webapp generated pages could access it.
Reference on this:

How to regenerate the /etc/udev/rules.d/70-persistent-net.rules file on Debian/Ubuntu

For quite a few years now most linux distributions ship udev with a network interface name caching mechanism. This simply means that whenever udev assigns a name for a network interface, it's cached (based on the interface's MAC address) in /etc/udev/rules.d/70-persistent-net.rules. However if you're cloning a system, the copy still contains this cache file. And since it lists your common interface names (from the original/source system) like eth0 or eth1 as occupied by specific MAC addresses, the cloned system will get new interface names (eg. eth2, eth3, rename3, etc.). Obviously this will break everything that references the old names and most of the time this will result in no network in the cloned system.

New version (0.3.5) of JD-GUI is out!

After two years of silence JD-GUI development is back on track! Smile For quite a long time v0.3.3 was the last published version. Recently two new versions appeared on the project's website:
  • v0.3.4 was published on 28th Aug 2012 (more than two years after the release of v0.3.3)
  • v0.3.5 was published just a few days ago on 18th Oct 2012
So there's still hope for existing bugs to get fixed. Eg. once I ran into quite a major fault in the decompilation of one of my classes: a condition evaluation was decompiled into the opposite instruction as it was in the compiled class! Shock Ie. an if (is_this_true) { ... } became an if (!is_this_true) { ... }. And obviously after a recompile the function in the generated class did quite the opposite compared to the original class.

dex2jar - tools to work with Android .dex and java .class files

"dex2jar contains 4 components:
  • dex-reader is designed to read the Dalvik Executable (.dex/.odex) format. It has a light weight API similar to ASM.
  • dex-translator is designed to do the conversion. It reads the dex instruction into dex-ir format and after some optimization it converts it to ASM format.
  • dex-ir used by dex-translator is designed to represent the dex instruction
  • dex-tools contains tools to work with .class files. (eg. modify an apk, deobfuscate a jar)

Dare - a tool for converting Dalvik/Android bytecode into traditional Java *.class files

"Dare is a project which aims at enabling Android application analysis. The Dare tool retargets Android applications in .dex or .apk format to traditional .class files. These .class files can then be processed by existing Java tools, including decompilers. Thus, Android applications can be analyzed using a vast range of techniques developed for traditional Java applications."

Nice. It seems I won't have to learn the Dalvik instruction set after all ... Smile

APKInspector - a GUI tool for APK analysis

"APKinspector is a powerful GUI tool for analysts to analyze the Android applications. The goal of this project is to aide analysts and reverse engineers to visualize compiled Android packages and their corresponding DEX code. The primary focus of this project is to provide a visualization layer that’s typically missing in existing Android reverse engineering tools, as well as to create a unified platform that combines several existing Android reverse engineering tools into a single unified view and context. For example this would include taking the control flow graph output from Androguard and unifying it with the code output from apktool, or dex2jar."

There's a 9 min video demonstrating the featureset of APKInspector.

Stowaway - static analysis tool for identifying permission use in Android apps

"Parts of the Android API are protected with permissions. In order to access protected API calls, developers must request the appropriate permissions in their applications' manifests. If a developer asks for more permissions than an application needs, then the application is overprivileged. Preventing overprivilege is important. Extra permissions may (1) unnecessarily deter users from installing applications, (2) unnecessarily accustom users to accepting lots of permissions, and (3) needlessly increase the potential damage of application vulnerabilities. Stowaway -a static analysis tool- detects overprivilege in compiled Android applications. Stowaway determines the set of API calls that an application uses and then maps those API calls to permissions. Automated testing tools were used on the Android API to build the permission map."

The tool itself seems to be not yet publicly available, but the website lets you upload an APK for analysis and review the results.

Androguard - reverse engineering of Android applications

"Androguard is mainly a tool written in python to play with:
  • Dex (Dalvik virtual machine) (.dex), and ODex (disassemble, decompilation)
  • APK (Android application) (.apk)
  • Android's binary xml (.xml)
Androguard is available for Linux/OSX/Windows (python powered)."

Ubuntu CDs are no more, apparently DVD is the way to go

"There is no longer a traditional CD-sized image, DVD or alternate image, but rather a single 800MB Ubuntu image that can be used from USB or DVD. Users who previously installed using LVM or full-disk encryption via the alternate CD will find that these installation targets are supported by the consolidated image in 12.10."

Well, that's almost true. Apart from the small difference that the new universal desktop image is only 790 MB. I don't really see any reason why the image could not fit on a 700 MB CD anymore. For those lousy 90 MB we've to use a DVD now. Did you already burn it? Is it not ridiculous how little of the 4.7 GB the image uses? Is it not a huge waste of space and resources? Ahhh. Sad

How to unpack (decode+disassemble) a number of APK packages

I recently wrote about how to deodex an odex file. Part of the instructions were a series of commands to unpack (decode+disassemble) an APK into some sort of a "source package". I've attached a short shell script (for linux/unix systems) that will use apktool, aapt and baksmali to extract and disassemble the contents of all APKs in the current working directory. It can be useful eg. to disassemble all system apps copied over to your PC from the /system/app directory on your phone. And having the sources you can start looking around and track down bugs, etc. Of course you could just download the original (Java) sources from, but that would take quite a long time and several gigabytes on your drive.

Syndicate content Syndicate content