On 2011-07-30 18:16, alaios wrote:
> Might be that this type of format uses any special type of format that
> requires some encryption and decryption?
No, it requires hacking.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Even if I read your statmement about “not anything readable” to litteraly (IMHO the output of od is allways readable, but maybe you do not understand what is there because it is no language you understand or no language at all), I must point to the fact that this does not say very much. Take the next simple case:
henk@boven:~> ls -l ttt
-rw-r--r-- 1 henk wij 28 31 jul 12:13 ttt
henk@boven:~> od -t a ttt
0000000 a b c d d e f g h nl C ) C < C us
0000020 nl E us C 4 b soh 0 B 9 nl nl
0000034
henk@boven:~> strings ttt
abcddefgh
henk@boven:~> cat ttt
abcddefgh
éüß
şô⁰¹
henk@boven:~> file ttt
ttt: UTF-8 Unicode text
henk@boven:~
od does not reveal directly that it is a perfectly readable text.
And strings only reveals those strings that are within the ASCII range (a minimal subset of Unicode).
But cat shows it all.
And file reveals that it is UTF-8 encoded Unicode.
In your case file does NOT say that, but imagine UTF-8 encoded text embedded in some structured file (that may start with a lot of other data). That would not be detected by file and strings would not find anything when those texts are e.g. from the Tibetan range of Unicode.
And how do you think you could detect that something is a file out of an Oracle database structure without having any clue in that direction? This is just an example to show how vast the range of possibilities is.