monline

AtomicParsley is a lightweight command line program for reading, parsing and setting metadata into MPEG-4 files supporting these styles of metadata:

• iTunes-style metadata into .mp4, .m4a, .m4p, .m4v, .m4b files
• 3gp-style assets (3GPP TS 26.444 version 6.4.0 Release 6 specification conforming) in 3GPP, 3GPP2, MobileMP4 & derivatives
• ISO copyright notices at movie & track level for MPEG-4 & derivative files
• uuid private user extension text & file embedding for MPEG-4 & derivative files

I use it to display the tree structure of MPEG-4 container atoms.

Let's assume your video recorder (phone, camera, etc.) died while recording an MP4 (or MOV or 3GP ... they are mostly the same container format). If you try to read/analyze it with ffmpeg, it'll tell you that "moov atom not found". The problem is that recorders put the most important part of the video (this so called moov atom) at the end of the video file. It contains the index of the video and the metadata (like codec, etc.). So everything that a video player needs to know to be able to play it back. The reason for this is simple: while you're recording the video, you don't have the full index yet. You only have it, when the recording is finished. And you don't know in advance how long the video is going to be so you cannot simply reserve some space for the index at the start of the recording.

Obvious benefits:

• Possibility to easily get system information in a simple string representation.
• Possibility to use dumped CPU, RAM, Battery, storage stats for a pretty charts, which will allow you to check how your application affects the overall device!

If you run dumpsys you would see a ton of system information. But you can use only separate parts of this big dump.
To see all of the "subcommands" of dumpsys do:

dumpsys | grep DUMP

First of all, you'll need a rooted device. I guess that's not much of a surprise after all. Then you'll need the iptables executable.

From the official documentation it might not be fully clear: for each webapp the server default context.xml is parsed first (which is at /etc/tomcat7/context.xml for Debian and Ubuntu servers) and if a webapp specific context definition exists (either at /META-INF/context.xml in the webapp's bundle/directory or at $CATALINA_BASE/conf/[enginename]/[hostname]/ in a *.xml file), then the latter is "merged" with the global default. I.e. if the global default specifies a flag that the webapp's context definition does not, then the flag will be set as specified by the global default context config.

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:

• Tomcat 5.5
• Tomcat 6.0

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.

After two years of silence JD-GUI development is back on track! 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! 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 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 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 ...