Help to reverse enginner a linux process

[DavidAlfa]

I know the title might sound bit like "How to make a nuclear reactor?"
I'm asking for some advices, hints, readings... Something to use as a start point.
I'm trying to reverse engineer an oscilloscope binary (phoenix, from Hantek). Coming from here
My linux knowledge is acceptable for everyday tasks, and some basics with strings, hexdump, binwalk and such, but not much more.
So far I've been able to do the basics. Break into the shell, analyze the system, run strings in the binaries...
Then I wanted to spy what the binary was doing. Calls to system libraries, etc.
I cross-compiled ltrace but sadly the suppport for arm was dropped long time ago.
Then I cross-compiled strace. Luckly that one worked.
The cmd I used was:

Code: [Select]

strace -f -y -yy -z -tt -s 65536 -o "/tmp/trace.log" ./phoenix
I could get some interesting things. There are lots of calls to system libraries, (open, read, close, write, ioctl...)
Uploaded a log here:
https://drive.google.com/file/d/1VTvxoUMlnpno_Ax5hFIcQDQiDj4zq0JI/view?usp=sharing

However, it's a 18MB file for 10 seconds of running! I found some info here and there but I find it overwhelming.
What to search for? Any common strings, access, paths...?

Thanks!

[PKTKS]

Not sure if I understand you right...

But ...  strace  is meant just for that.. system calls.

It will dump whatever INT80H calls it can trace on the binary supplied

On the other hand may be you really want a debug version - e.g.
a full blown debuggable  version where the lines and opcodes
information are required at compile time..

Otherwise a voooodoooo  magic is needed to decompile the BIN hex
object in readable opcodes...

As far as  strace is concerned it is bounded to reliable snoop INT80H calls

Paul

[Nominal Animal]

I'm trying to reverse engineer an oscilloscope binary (phoenix, from Hantek).

In my experience, that approach won't yield much useful information.  Not only is it a lot of work – you've already seen how much information is gathered during each second – but the results aren't "clean-room"; you'll always have the spectre of copyright issues looming over the end product.

Personally, capturing the information sent and received between the device and the computer, is much more useful.
(Even though I'm just a hobbyist, I have done this for a couple of devices quite successfully, including a vinyl cutter.  I've mentioned here before that I then used a Pro Micro clone, a cheap ATmega32u4 programmed in the Arduino environment as an Arduino Leonardo, to stand-in as an USB device replaying captured communications for "driver" development.)

The "trick" is to generate well controlled, detailed tasks, repeat them, and vary them, to see how settings and data affect the communication.  For each captured communications stream, you do need to attach a detailed description of the task, including things like scope settings.  (I prefer a directory tree structure, with a directory per dataset, descriptions in text files for easy grepping and data comparison, and so on.  I often write awk scriptlets to compare different comms sequences, looking for similarities and differences.  I end up building a mental image of the protocol, and stepping "into the shoes" of the design engineer, to anticipate/guess the choices they made – understanding their context makes such guessing amazingly predictive, and even though there will be some "dark spots" in the data stream you don't know what they exactly describe, you can work with the end result.)

In Linux, you can use Wireshark.  In fact, the USB capture is implemented in the kernel itself (the usbmon kernel module), and given fast enough storage media, is rock solid.

Coming from here

Ah, so you actually have a console on the embedded Linux system inside the scope; this changes things a bit – but not overmuch.

I'll reply in that other thread.

[ejeffrey]

Agree on USB capture (or other IO snooping).  strace can be useful to see how a process is manipulating the system, especially what files it accesses, what IO it performs, and how it interacts with other processes, but for reverse engineering something like this it will produce far too much noise.  It's much better to focus on the specific IO channel -- whether it is USB, TCP/IP, or serial.

[tv84]

I'm asking for some advices, hints, readings... Something to use as a start point.
I'm trying to reverse engineer an oscilloscope binary (phoenix, from Hantek). Coming from here
My linux knowledge is acceptable for everyday tasks, and some basics with strings, hexdump, binwalk and such, but not much more.
So far I've been able to do the basics. Break into the shell, analyze the system, run strings in the binaries...
Then I wanted to spy what the binary was doing. Calls to system libraries, etc.

IMO, the best way is to start with some static analysis of the code with a with a good disassembler (IDA or Ghidra) and then pass to dynamic analysis via JTAG interface (since you seem to totally own the device).

With OpenOCD, IDA, etc you can use the JTAG interface to literally run the binary instruction-by-instruction, see the full state of the machine at any point, etc.

Starting with binaries compiled with full symbol-info helps a lot in understanding the mechanics. Then move on to more obscure bins...

Spoiler: it's not an easy learning curve BUT "when there's a will, there's a way"...