flat assembler
Message board for the users of flat assembler.

Index > Heap > security, password, truecrypt, bruteforce

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
redsock
I would like to ask you a simple question but I all I want is a decent answer which I tried in other forums, even specialized ones and all I could get was this very famous phrase: "What you refer to is security by obscurity... and bla-bla-bla".

Please without mentioning that phrase, I would like an answer for the following case:


    1.An individual wrote an algorithm to make meaningful data unreadable, looking like random garbage (a.k.a. encryption). Let us consider this individual can be a skilled cryptographer or not... No one knows.

    2.While highly unlikely, let us consider such algorithm can be as "strong" as the current (02/04/2015) Advanced Encryption Standard or even better (calm down, those are just possibilities you may consider). Or it can be a real crap, a thing any one would easily solve (examples are XORed with "pass phrase" or inverted bits). While at the same being as easy as that is unlikely.

    3.Now let us say this individual have a file that was processed with said algorithm.

    4.You have only this file at your disposal and you must decipher its real content to save your life, time is not a problem as you can live forever without food or water and you have all technology available in the current world at your disposal.

    5.You have nothing more about the file or the algorithm or program that generated it, the only thing you know but is unsure is that it probably contains text data.

    The question is: How hard or easy would be to recover the real contents from this file? What techniques could be used to solve this? How would you try? Or no, no one will even try too much headache/work for a marginal or no benefit at all!?


I know it sounds stupid, but that is a question no one ever answered in a way I consider acceptable. And I insist on this whenever a find a cryptography expert like you.

I apologize for any inconveniences I may have caused.

Thank you for your patience!
Post 02 Apr 2015, 22:43
View user's profile Send private message Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 357
Location: Australia
redsock
HaHaAnonymous wrote:
The question is: How hard or easy would be to recover the real contents from this file? What techniques could be used to solve this? How would you try? Or no, no one will even try too much headache/work for a marginal or no benefit at all!?
Smile It is a public holiday here in Australia so I have the day off and am sitting here enjoying a slow morning with my coffee Smile Will do my best to answer Smile

Armed with only garbled/encrypted output, the first and most important thing to determine is whether or not it is uniformly distributed. A simple XOR for example doesn't produce pseudorandom output, and so the distribution would not be uniform. The simplest and fastest (IMO) way to determine this is to see whether or not you can compress the data with whatever your preferred compression utility is.

If it DOES compress, and you have a reasonable suspicion it is text/ASCII/readable contents inside, then figuring out what letter frequencies are most common in the given language (spanish versus german, etc) isn't really that difficult, and you can pretty easily undo anything that is "simple".

If it does NOT compress, well, then your options are very limited if there is no signature/file information/anything. Your time would be well spent investigating to obtain more information about the methods the file was constructed in the first place, etc. than attempting "blind" brute forcing with arbitrary algorithms, unknown keys, iterations, etc. An exercise in futility really.

As an interesting example, if you take your favourite MP3 track for example, and use it as your XOR key, HA! Good luck to the person that attempts to undo that with no information whatsoever.

Modern crypto IMO is all about knowing (and even advertising openly) how things are constructed and still not being able to get anything useful out of it.

That being said however, even with my simple "use your favourite song" XOR, that would be very difficult to undo without knowing how/why it was constructed in the first place.

It definitely does amount to "obscurity", heheh, but can still be very effective. For uniformly distributed material though, you'd definitely be better off digging for more information about the source/construction methods before bothering with "blind decryption".

$0.02 thusly Smile
Post 02 Apr 2015, 23:08
View user's profile Send private message Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 357
Location: Australia
redsock
For fun, I wrote a filexor HeavyThing example so you can look at the output of my silly example of using your favourite song as an XOR key Smile To compile, stick this code into its own directory in my examples directory:
Code:
        ;
        ;       filexor.asm: File based XOR example for HaHaAnonymous on the board
        ;
include '../../ht_defaults.inc'
include '../../ht.inc'

public _start
_start:
        call    ht$init

        cmp     dword [argc], 1
        jbe     .usage

        ; xor key file is our only argument, grab from back of args
        mov     rdi, [argv]
        call    list$pop_back
        mov     rdi, rax
        xor     esi, esi
        call    privmapped$new
        test    rax, rax
        jz      .badinputfile
        mov     r12, rax
        ; process our input in key file sized blocks
        mov     rdi, [rax+privmapped_size_ofs]
        call    heap$alloc
        mov     rbx, rax
        ; read from stdin until eof
calign
.loop:
        mov     eax, syscall_read
        xor     edi, edi
        mov     rsi, rbx
        mov     rdx, [r12+privmapped_size_ofs]
        syscall
        cmp     rax, 0
        jle     .done
        mov     r13, rax
        ; xor it with our file xor key
        mov     rdi, rbx
        mov     rsi, [r12+privmapped_base_ofs]
        mov     rdx, rax
        call    memxor
        ; output the result to stdout
        mov     eax, syscall_write
        mov     edi, 1
        mov     rsi, rbx
        mov     rdx, r13
        syscall
        jmp     .loop
.done:
        mov     eax, syscall_exit
        xor     edi, edi
        syscall

calign
.usage:
        mov     rdi, .argrequired
        call    string$to_stdoutln
        mov     eax, syscall_exit
        mov     edi, 1
        syscall
cleartext .argrequired, 'xor key filename required'
calign
.badinputfile:
        mov     rdi, .badinput
        call    string$to_stdoutln
        mov     eax, syscall_exit
        mov     edi, 1
        syscall
cleartext .badinput, 'unable to open input file'

        ; include the global data segment:
include '../../ht_data.inc'
    
And to use/play/check it out:
echo "This is my plaintext" | ./filexor /path/to/song.mp3 | hexdump -C

and to "decrypt" (self explanatory really, but for those who don't know):
echo "This is my plaintext" | ./filexor /path/to/song.mp3 | ./filexor /path/to/song.mp3

Obviously if your "xor key file" contains a lot of zero bytes, then that is patently absurd to use, but if it is something half-decent like an MP3, works quite well wouldn't you say?

Smile Smile
Post 02 Apr 2015, 23:36
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
Thank you for the answer and example, redsock. Interesting!

Enjoy the holiday!
Post 02 Apr 2015, 23:59
View user's profile Send private message Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 357
Location: Australia
redsock
No worries!

Because our topic here is about brute forcing, I modified the filexor example I did to work similarly, but with AES128 instead of a simple XOR.

This output is brute force resistant, of course I didn't bother with any of the complexities of block alignment (it adds padding bytes to the input as necessary to fill a 16 byte block boundary), so if the input is not aligned 16, the output will not match the input (thanks to it adding * bytes to the end).

As an example for you though, you can quickly see that if all you have is encrypted output with no other information, things quickly become intractable Smile

Can you tell it is a day off? hahahah

Anyway, aesfilekey.asm follows, similar to filexor, stick this in its own directory in the HeavyThing examples dir.
Code:
        ;
        ;       aesfilekey.asm: AES128 w/ key == some filename for HaHaAnonymous on the board
        ;       this example will pad to 16 bytes, and during decrypt, the padding is not
        ;       removed, but serves the purpose well for example's sake, padding byte is *
include '../../ht_defaults.inc'
include '../../ht.inc'

public _start
_start:
        call    ht$init

        cmp     dword [argc], 1
        jbe     .usage
        mov     r14, aes$init_encrypt
        mov     r15, aes$encrypt
        mov     rax, aes$init_decrypt
        mov     rcx, aes$decrypt
        ; if argc == 2, then we are encrypting, else decrypting
        cmp     dword [argc], 2
        cmovne  r14, rax
        cmovne  r15, rcx
        
        ; take our key file argument, and compute a SHA256 hash of it for our AES keys
        mov     rdi, [argv]
        call    list$pop_back
        mov     rdi, rax
        xor     esi, esi
        call    privmapped$new
        test    rax, rax
        jz      .badinputfile
        mov     r12, rax
        call    sha256$new
        mov     rbx, rax
        mov     rdi, rax
        mov     rsi, [r12+privmapped_base_ofs]
        mov     rdx, [r12+privmapped_size_ofs]
        call    sha256$update
        sub     rsp, 1024       ; we'll use this space later
        mov     rdi, rbx
        mov     rsi, rsp
        mov     edx, 1          ; let it destroy the sha256 context
        call    sha256$final
        ; we are done with our key file:
        mov     rdi, r12
        call    privmapped$destroy
        ; allocate space for our AES context:
        mov     edi, aes_size
        call    heap$alloc
        mov     rbx, rax
        ; now we have 32 byte SHA256, AES128 only needs 16 byte key:
        mov     rdi, rax
        mov     rsi, rsp
        mov     edx, 16
        call    r14

        ; read from stdin until eof
calign
.loop:
        ; AES requires complete blocks, so pad our space before we read
        ; this is slow of course, but we are only doing an example Smile
        mov     rdi, rsp
        mov     esi, 0x2a               ; our asterisk padding
        mov     edx, 1024
        call    memset
        mov     eax, syscall_read
        xor     edi, edi
        mov     rsi, rsp
        mov     edx, 1024
        syscall
        cmp     rax, 0
        jle     .done
        mov     r13d, eax
        ; 1024 / 16 == 64, code bloat here is fine by me for our example
        repeat 64
                blockoffset = (% - 1) * 16
                mov     rdi, rbx
                lea     rsi, [rsp+blockoffset]
                call    r15
        end repeat
        ; output the result to stdout, making sure we round up to the nearest 16 bytes
        mov     eax, syscall_write
        mov     edi, 1
        mov     rsi, rsp
        mov     edx, r13d
        add     edx, 0xf
        and     edx, not 0xf
        syscall
        jmp     .loop
.done:
        mov     eax, syscall_exit
        xor     edi, edi
        syscall

calign
.usage:
        mov     rdi, .argrequired
        call    string$to_stdoutln
        mov     eax, syscall_exit
        mov     edi, 1
        syscall
cleartext .argrequired, 'AES key filename required'
calign
.badinputfile:
        mov     rdi, .badinput
        call    string$to_stdoutln
        mov     eax, syscall_exit
        mov     edi, 1
        syscall
cleartext .badinput, 'unable to open input file'

        ; include the global data segment:
include '../../ht_data.inc'
    


To encrypt with it:
echo "This is my plaintext" | ./aesfilekey /path/to/song.mp3 > encrypted.output

To decrypt with it:
cat encrypted.output | ./aesfilekey -d /path/to/song.mp3 > decrypted.output
cat decrypted.output

You'll note the extra asterisks added to the input, but as an example, it is quite effective.

This example just takes whatever file argument you pass it and makes a SHA256 hash of its contents and uses the first 16 bytes of that as the AES128 keys.

Brute force? I think not, but then it is a matter of ATIME file access settings, how much command line history you leave laying around, etc as to whether or not something like this would ever be useful. Better than the XOR example by a country mile in any case, hahah

Cheers
Post 03 Apr 2015, 00:54
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.