Help to reverse enginner a linux process - Page 1
Forum section: electronics / general

author: DavidAlfa
author_rank: Super Contributor
timestamp: June 06, 2021, 10:23:34 pm
content: 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 fromhereMy 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:strace -f -y -yy -z -tt -s 65536 -o "/tmp/trace.log" ./phoenixI 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=sharingHowever, 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!

author: PKTKS
author_rank: Super Contributor
timestamp: June 07, 2021, 01:24:23 pm
content: Not sure if I understand you right...But ...straceis meant just for that.. system calls.It will dump whatever INT80H calls it can trace on the binary suppliedOn the other hand may be you really want a debug version - e.g.a full blowndebuggableversion where the lines and opcodesinformation are required at compile time..Otherwise a voooodoooo magic is needed to decompile the BIN hexobject in readable opcodes...As far as strace is concerned it is bounded to reliable snoop INT80H callsPaul

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 08, 2021, 10:43:30 pm
content: Quote from: DavidAlfa on June 06, 2021, 10:23:34 pmIn 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 guessingamazinglypredictive, 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 (theusbmonkernel module), and given fast enough storage media, is rock solid.Quote from: DavidAlfa on June 06, 2021, 10:23:34 pmAh, 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.

author: ejeffrey
author_rank: Super Contributor
timestamp: June 14, 2021, 04:25:24 pm
content: 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.

author: tv84
author_rank: Super Contributor
timestamp: June 26, 2021, 06:59:44 pm
content: Quote from: DavidAlfa on June 06, 2021, 10:23:34 pmIMO, 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"...