pseudo

Hi guys, I'm stuck with pseudo. I've done few steps ahead but now I'm stuck, watching it just looping on 0x7F. Need to discuss with someone who solved it, it's the last chall I need to finish REing challenges and it's starting to drive me crazy :)

Comments

  • done, nevermind.

  • I have un packed it with the tool which was use by them to pack it.
    And I got a flag like part from it HTB{base64_encoded message}
    But its like fooling, as it was not the flag,
    Please help!!

  • i can't run the file on my kalilinux what can i do i can't even add architecture for it

  • For anyone having issues running this and who don't have access to ARM hardware (like a Raspberry Pi), I found something useful:

    https://blahcat.github.io/2017/06/25/qemu-images-to-play-with/

    The arm64_stretch package ran just fine for me under Kali, right out of the box with no tweaks necessary. Pretty cool. You can transfer files to it over SSH.

    Having said that, has anyone made any progress with this? I'm not familiar with ARM, so I'm having a difficult time.

    opt1kz

  • edited November 2018

    I'm at the point where I know that the executable is a VM executing some "byte code" on a 2-register machine and I've figured out what 8 out of the 12 "instructions" do, but I'm having trouble with the last four. The use of floating point aarch64 instructions is confusing to me.

    Would someone be willing to give me some pointers on how to proceed?

    EDIT: The byte code sort of looks like a modified version of a certain esoteric language.

  • Solved after recognizing similarities to a certain esoteric programming language and writing a custom interpreter that skips a certain something.

    This is probably my favorite challenge out of all the reversing ones.


    Also, in addition to the aarch64 system image @opt1kz mentioned, you can also use qemu's built-in GDB server (qemu-aarch64-static -g <port> ./pseudo), which doesn't require a sysroot because pseudo is a statically linked executable.

  • I was able to run the code both with an actual device and with qemu, but how can you debug this? gdb doesn't have symbols so I can't setup breakpoints, while radare2 says "Sorry. No debugger backend available." when launching in debug mode.
    Anyway with radare2 I'm able to see the assembly code (which for me seems pretty crazy).
    Did you solve it without debugging?
    This is my last retro, it seems very interesting but I am probably missing something XD

    mrlbender

  • radare2 says "Sorry. No debugger backend available." when launching in debug mode.

    I'm not super familiar with radare2. Does it let you connect to a gdbserver? I used qemu-aarch64-static -g 12345 ./pseudo to start a gdbserver and set up IDA to connect to a remote GDB server at <linux VM's IP>:12345.

    Did you solve it without debugging?

    Yep. I only used the debugger to find approximately where the interesting stuff was and then worked off the disassembly.

  • Yes radare allows you to connect to a gdb server, but I have never tried it yet. I was using gdb directly, it connects but got some errors (code is running but can't setup breaks).
    Anyway thank you for your answer!!
    I will try to look better at the code :)

    mrlbender

  • Finally did it, thanks for the help!
    Eventually using qemu and radare2 + a script in python I wrote :)

    mrlbender

  • I've gotten to the point where the program is executing the loop based on bytes and see where and how the input is being stored. I'm stuck at this point and could use a push in the right direction.

  • Hi How many zip files appear before it reaches the end?

  • Hawkeye16 - you are on good track - now try to find other loops in the arm code where user input is used.

  • btw few people wrote me for hints on PM, and I'm glad to help out, but I honestly expected a "respect" at least. I'm not being salty for a game but it's just I'm a bit disappointed since it's not that fair to ask for an hint and do not give something back. Please consider this before writing me :)

  • Hi all, I need some help with the challenge. I can share in PM my approach and what I have tried so far. Thanks!

  • based on questions I've received, the generic hint I can give is to track down the input first (both user and password), watch what's happening with it and then move on the logic of the program: ask yourself "do I really need to reverse this bunch of no-sense assembly?" (by "no-sense" I'm refering to a certain part of the program). go for abstraction sometimes and try to assume that a piece of code is doing some sort of operations (you need to verify it by reversing or by observing te behaviour), don't be stuck just with bytes and instructions.
    For the rest of the code, it's "standard" assembly: no matter if you are experience only on x86/64, you can read this architecture too :)
    and, most important, take your time: for some is faster then for others to dig into asm! don't get frustrated and just keep read and try to understand what's going on: the time you're spending on this will improve your approach on reversing too, because at some point you'll focus on answering the correct questions you're making yourself :)
    If I was able to resolved it, trust me, you can really solve it youself ! :D

  • I made some progress, I think. I can distinguish library code from binary code. I know how the binary was compiled. I have identified the function that asks for some input. I have somehow reconstructed the first steps of the program.
    Now I am stuck in what seems to be a very long loop. Letting the loop evolve until the end probably leads to an infinite loop. I don't understand how to force divertion to a more interesting location (that I might have found). Could someone shed some light on this aspect?

  • edited July 31

    .

  • edited July 31

    .

  • edited August 10

    I've reached the point in which I too see the similarities with another esoteric language with the bytes for all but 3 of the bytes. However, I'm mainly zooming on this one byte as I know this is the one where some checking occurs... I know what operations are performed on my input and know what happens when this check fails. However, I'm having some difficulty getting past this part as I am not sure about the length. Anyone can help me out a little?

    On a sidenote (this might be my lack of experience with remote debugging with gdb), who else had issues finding what they typed in the memory of the program?

    will135

  • Alright got it! Very tough challenge. Tip for the last step... don't be like me and assume anything about lengths.

    will135

  • Just managed to solve it with radare2 and qemu (eventhough i felt like radare was very reluctant to work with this binary, it fought me wherever it could), by far the best challenge i have seen so far. As a beginner, I appreciate having to deal with reading assembly instructions other than X86 and IKEA, and the thing had a twist to it which was (in my opinion) pretty original. All in all very fun and educational (also, looking at the difficulty ratings makes me chuckle now because i feel like i'm part of an inside joke for both obvious and non-obvious reasons).

    I am intrigued however, several people here mention they solved it with a python script. I tried so too, but i ran into the same problem as with the binary itself, so in the end i solved it without (except for the usual calculations/conversions). If someone is willing to share his scripting-approach via PM (the rough idea should be sufficient), i would be grateful, because the comments here make me feel like i missed something.

    Gordin
    Press F to give respect

Sign In to comment.