Twitter Updates

    follow me on Twitter

    List for 4.5% and get 1% cash back on your purchase

    Friday, June 2, 2023

    NcN 2015 CTF - theAnswer Writeup


    1. Overview

    Is an elf32 static and stripped binary, but the good news is that it was compiled with gcc and it will not have shitty runtimes and libs to fingerprint, just the libc ... and libprhrhead
    This binary is writed by Ricardo J Rodrigez

    When it's executed, it seems that is computing the flag:


    But this process never ends .... let's see what strace say:


    There is a thread deadlock, maybe the start point can be looking in IDA the xrefs of 0x403a85
    Maybe we can think about an encrypted flag that is not decrypting because of the lock.

    This can be solved in two ways:

    • static: understanding the cryptosystem and programming our own decryptor
    • dynamic: fixing the the binary and running it (hard: antidebug, futex, rands ...)


    At first sight I thought that dynamic approach were quicker, but it turned more complex than the static approach.


    2. Static approach

    Crawling the xrefs to the futex, it is possible to locate the main:



    With libc/libpthread function fingerprinting or a bit of manual work, we have the symbols, here is the main, where 255 threads are created and joined, when the threads end, the xor key is calculated and it calls the print_flag:



    The code of the thread is passed to the libc_pthread_create, IDA recognize this area as data but can be selected as code and function.

    This is the thread code decompiled, where we can observe two infinite loops for ptrace detection and preload (although is static) this antidebug/antihook are easy to detect at this point.


    we have to observe the important thing, is the key random?? well, with the same seed the random sequence will be the same, then the key is "hidden" in the predictability of the random.

    If the threads are not executed on the creation order, the key will be wrong because is xored with the th_id which is the identify of current thread.

    The print_key function, do the xor between the key and the flag_cyphertext byte by byte.


    And here we have the seed and the first bytes of the cypher-text:



    With radare we can convert this to a c variable quickly:


    And here is the flag cyphertext:


    And with some radare magics, we have the c initialized array:


    radare, is full featured :)

    With a bit of rand() calibration here is the solution ...



    The code:
    https://github.com/NocONName/CTF_NcN2k15/blob/master/theAnswer/solution.c





    3. The Dynamic Approach

    First we have to patch the anti-debugs, on beginning of the thread there is two evident anti-debugs (well anti preload hook and anti ptrace debugging) the infinite loop also makes the anti-debug more evident:



    There are also a third anti-debug, a bit more silent, if detects a debugger trough the first available descriptor, and here comes the fucking part, don't crash the execution, the execution continues but the seed is modified a bit, then the decryption key will not be ok.





    Ok, the seed is incremented by one, this could be a normal program feature, but this is only triggered if the fileno(open("/","r")) > 3 this is a well known anti-debug, that also can be seen from a traced execution.

    Ok, just one byte patch,  seed+=1  to  seed+=0,   (add eax, 1   to add eax, 0)

    before:


    after:



    To patch the two infinite loops, just nop the two bytes of each jmp $-0



    Ok, but repairing this binary is harder than building a decryptor, we need to fix more things:

    •  The sleep(randInt(1,3)) of the beginning of the thread to execute the threads in the correct order
    •  Modify the pthread_cond_wait to avoid the futex()
    • We also need to calibrate de rand() to get the key (just patch the sleep and add other rand() before the pthread_create loop
    Adding the extra rand() can be done with a patch because from gdb is not possible to make a call rand() in this binary.

    With this modifications, the binary will print the key by itself. 

    Related word

    No comments:

    Post a Comment

    Home for sale- $2,000 rebate!

    Ready Real Estate slide show

    Become a fan of my page

    Sheree Dutton, Reatlor, DFW, Texas on Facebook
    Powered By Blogger

    Pandora Faves

    Back on the market, price reduced, 1% cash back rebate offered

    Sheree Dutton | Ready Real Estate | 817-975-0461
    222 Birchwood, Azle, TX
    Back on the market, price reduced and 15 cash back rebate offered!
    3BR/2BA Single Family House
    offered at $102,500
    Year Built 2006
    Sq Footage 1,142
    Bedrooms 3
    Bathrooms 2 full, 0 partial
    Floors 1
    Parking 3 Covered spaces
    Lot Size .225 acres
    HOA/Maint $0 per month

    DESCRIPTION


    Wow, talk about pride of ownership! This house has too many upgrades to count, and is so well cared for. You must see it to believe it! A lot of value in this perfect starter home.

    OPEN HOUSE SUNDAY MAY 3RD 2+5 pm

    see additional photos below
    PROPERTY FEATURES

    - Central A/C - Central heat - Fireplace
    - High/Vaulted ceiling - Walk-in closet - Tile floor
    - Living room - Breakfast nook - Dishwasher
    - Refrigerator - Stove/Oven - Microwave
    - Laundry area - inside - Balcony, Deck, or Patio - Yard

    OTHER SPECIAL FEATURES

    - 1 car garage, covered carport for 2 cars
    - covered wood deck in backyard
    - gutters
    - storage shed
    - newly stained wood fence
    - electric fireplace added, with tile hearth
    - upgraded ceiling fans and light fixtures
    - island in kitchen

    ADDITIONAL PHOTOS


    Fantastic curb appeal

    covered wood deck in back

    living room

    kitchen with island

    breakfast nook

    master bedroom
    Contact info:
    Sheree Dutton
    Ready Real Estate
    817-975-0461
    For sale by agent/broker

    powered by postlets Equal Opportunity Housing
    Posted: Sep 11, 2009, 7:31am PDT

    Blog Archive