Sec, blogmal!
11 2010

Categories:

Everything

Februar '17

SoSoSoSoSoSoSo
303112345
6789101112
13141516171819
20212223242526
272812345

Archive:

Tue, 30 Nov 2010

Offline ?

Ja, der JMStV ist durch. Und? Leute, ihr seid extrem kindisch wenn ihr jetzt alle "Offline"-Blogpostings macht, und damit droht euer Blog dichtzumachen.

so zum Beispiel:

Wer sich wirklich informieren will, statt nur nachzuplappern, dem sei dieser Link empfohlen. Und selbst wenn ihr zu dem Schluss kommt, das es tatsächlich jetzt unhaltbar schlimm geworden ist, ist sich leise in der Ecke zu verkriechen definitiv keine Lösung.

Davon ab, ihr seid eh alle Selbstdarsteller. Ich glaube euch nicht, das ihr plötzlich nichts mehr schreiben wollt, oder genauer: es lange aushaltet, nichts mehr zu schreiben :-)

– Sec


posted at: 17:08 | Category: /misc | permanent link to this entry | 0 comments (trackback)

Thu, 18 Nov 2010

OLE Compound Format Extractor

Today, a colleague asked me to help him extract a logo as a file from an openoffice document. This is a task which seems easy enough, given that .odt documents are essentially zip files.

Extracting the .odt revealed (among other files) two interesting files: Object 1 and ObjectReplacements/Object 1. Using file to determine the file-types was quite unhelpful - on two different machines I got:

Object 1: Microsoft Office Document
Object 1: CDF V2 Document, corrupt: Cannot read summary info

And the other file stays enigmatic:

ObjectReplacements/Object 1: data

The ObjectReplacements file starts out with

0000000: 5643 4c4d 5446 0100 3100 0000 0000 0000  VCLMTF..1.......

which some googling reveals to be a StarView Meta file. - This is an openoffice internal format, supposed to have the extension .svm and can be opened by OO Draw.

But I wanted to get at the original file. Both suggestions from file(1) are wrong, but the Microsoft Office Document actually points in the right direction…

Checking in META-INF/manifest.xml gives us the supposed mime-type of application/vnd.sun.star.oleobject and further googling shows us that this is an so called OLE Compound File.

Now while I could easily find a Windows program to parse this file, I found no such thing for Unix. – Which lead me to a quick hack using perl and OLE::Storage_Lite to crate cfx the compound file extractor.

ice:~/ole>./cfx Object\ 1
- Root Entry
x \x{01}Ole
x \x{03}PIC
x \x{03}META
x \x{01}CompObj
x \x{03}ObjInfo
x \x{01}Ole10Native
x \x{01}Ole10ItemName

The …Native file is the one we want. For reasons that I still don't understand you still have to delete the first four bytes from that file which in our case then reveals:

ice:~/ole>file $'\001'Ole10Native  
Ole% 0Native: data
ice:~/ole>dd if=$'\001'Ole10Native skip=4 bs=1 of=Fixed
7648+0 records in
7648+0 records out
7648 bytes transferred in 0.025733 secs (297203 bytes/sec)
ice:~/ole>file Fixed
Fixed: PC bitmap, Windows 3.x format, % 97 x 75 x 4

the relevant .bmp file. Yay!

– Sec

P.S.: If you have a stromg stomach, check the file format specification.

P.P.S.: In the meatime I found out that 7-Zip can also extract OLE Compund Files. Would've been a bit easier :-/


posted at: 18:48 | Category: /tidbits | permanent link to this entry | 2 comments (trackback)

Fri, 12 Nov 2010

Android restore the hard way

Ich bin ja nun schon seit einiger Zeit zufriedener Besitzer eines Android-Handys (ein G1). Durch einen bizarren Bug, und einen kleinen Fehler meinerseits habe ich meine Kontakt- und Kalender-Datenbanken verloren. [Ich synce meine Kontakte prinzipiell nicht mit Google].

Alle relevanten Datenbanken liegen bei Android alle unter /data/data.
(Nur wer sich root-Rechte auf seinem Telefon gesichert hat kann ab hier fröhlich mitspielen).

Die Kontakte sind unter com.android.providers.contacts/databases/contacts.db, die Termine unter com.android.providers.calendar/databases/calendar.dbAchtung: immer auf den richtigen Owner achten, ist ja ein Unixoides System. (Bei mir sind das momentan app_1 für die Kontakte und app_29 für den Kalender) – Bei Unklarheiten einfach nachschauen wem das .../databases Directory gehört.)

Mein letzte Backup dieser Files war ein nandroid-Backup - Die nandroid-Backups liegen alle auf der SD-Card unter /sdcard/nandroid/<handy-id>
Dort pickt man sich das gewünschte Subdirectory (meistens wohl das neueste) heraus, und darin das data.img. Das ist jetzt ein YAFFS2-Image das man z.b. mit unyaffs (Windows-Binary hier) auspacken kann.

Die passenden Files kann man nun aufs Handy verfrachten. Dabei empfiehlt es sich vorher nachzuschauen wer der richtige Owner ist, da adb push diesen leider überschreibt.

adb shell ls -l /data/data/com.android.providers.contacts/databases/contacts.db
adb push contacts.db /data/data/com.android.providers.contacts/databases/contacts.db
adb shell chown app_1:app_1 /data/data/com.android.providers.contacts/databases/contacts.db

adb shell ls -l /data/data/com.android.providers.calendar/databases/calendar.db
adb push calendar.db /data/data/com.android.providers.calendar/databases/calendar.db
adb shell chown app_29:app_29 /data/data/com.android.providers.calendar/databases/calendar.db

Damit die Applikationen die Änderung hinter ihrem Rücken auch mitbekommen empfiehlt sich entweder ein reboot, oder ein (brutaler) restart der passenden Dienste:

adb shell killall android.process.acore
adb shell killall com.android.calendar

Und schon sind die Daten wieder da. Yay!

– Sec


posted at: 11:37 | Category: /tidbits | permanent link to this entry | 8 comments (trackback)
<< older

powered by blosxom
in 0.00 s