Schatz Forensic

The following video shows an experimental interactive memory debugger and visualiser called ICU64, running against the  Frodo C64 emulator. 

The video below shows an interactive exploration of the memory space of the emulated C64 while it runs the game “Cataball”, pointing out correspondences between the raw memory and the on-screen action.

Hex editor authors and forensic tool manufacturers should take note of the zoomable memory map.

[via Root Labs Rdist]

In late June I wrote about the forged email that had been at the heart of a political scandal. Mr Godwin Grech at the time claimed he had received an email from the office of the Prime Minister of Australia pushing for preferential treatment of a friend of the PM. The Australian Federal Police raided Mr. Grech’s home and found the email in question, deleted, on his home computer. They pronounced it a fake.

Today, The Australian is reporting that Mr. Grech last night admitted to having faked the email.  Mr. Grech claims that he recollected receiving an original email similar to the one in question. Unable to find the original, he concocted the fake one in order to substantiate verbal claims he had made about the matter.

An excellent visual summary of computer hardware connectors. The original is sonic840’s Computer Hardware Poster.

[via Hack a Day]

It has been a few months since I last looked at Kowari. My motivations currently are in using a persistent OWL implementation, or at least a persistent RDF store. Kowari’s graph traversal ITQL operations are particularly of interest and look promising, and Paul Gearon, one of the core developers, seems to be working hard on the OWL implementation.

Last time I looked at Kowari, which was a few months ago, it was a tedious process getting it to run inside of Eclipse. I have become accustomed to simply pointing the Eclipse source path at the /src directory in any particular source distribution, and importing all of the jars in the /lib directory, and it all simply working. Not in this case.

The Kowari source code is organised over upwards of 30 separate source folders. When I simply imported all of these folders into eclipse there were serious shadowing problems. For some reason, (which I suspect are an artifact of having a couple of copeting implementations in the source tree, which were configured buy the ant build) there were a number of classes with the same name and package in multiple folders.

Happily, things have improved for the better. Digging into the scr/jar and src/war folder heirarchies reveals folders called “java” which can be imported as eclipse source paths without issue. The only real gotcha here is that a number of source files are generated, and not packaged with the source distro. Running the ant build in situ fixes that. At this point one can add obj/jar/config/java and obj/jar/itql/java to the build path.

At this point the eclipse should be able to build all of the most base parts, as long as you import all of the libraries in lib. A number of errors will be visible due to missing 3rd party libraries.

Running Kowari was a little more tricky. Here is how to do it.

Created a reate a run configuration with main class org.kowari.server.EmbeddedKowariServer. For the command line, I appended the following (adjust the path to suit):

-c file:///D:/mysrc/kowari-1.1/conf/kowari-config.xml

The following are needed VM arguments (again, adjust the path to suit):

-Djava.security.policy=file:///D:/mysrc/kowari-1.1/conf/kowari-rmi.policy
-Dorg.kowari.xml.ResourceDocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
-Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory
-Djava.naming.provider.url=rmi://localhost
-Dlog4j.configuration=file:///D:/mysrc/kowari-1.1/log4j-conf.xml

The final trick is to copy the conf directory into whatever your eclipse build directory is (my default is kowari-1.1/classes). This is typically the /bin directory.

My next try was to get the org.kowari.itql.ItqlSession unit test to run. Most of it currently runs without issue, although I am getting failures on testSelect7, and all of hte testLoadAPI, testBaskup, testLoadBackup, and testRestore unit tests. I havent looked into the reasons for this in any detail. In order to get this to run, you will need the VM argument

-Dcvs.root=D:/mysrc/kowari-1.1

The ITQL interpreter, org.kowari.itql.ItqlSession seems to run without any commmand line or VM arguments, although I havent yet tested actually using it. I will update this when I have.

Getting the MP3 demo application required me to run the ant build target

>ant demo-mp3-config-generate

And then adding the obj/jar/demo-mp3/java to the source folders. The MP3 applicatoin is run from the class org.kowari.demo.mp3.swing.Mp3Application with the argument the relative path to the config file: conf\mp3-config.xml. This should be in your classes/conf dir.

The mp3-config.xml file needs to be edited as below

type =”http://tucana.org/tucana#Model”>

Finally I had to copy the icons in the images directory of demo-mp3 into the /classes directory.