5

I'm reverse engineering an old TP-Link TD-W9970v3 router for fun and wanted to examine one of the executables called webWarn. Ghidra was unable to recognise the format, which surprised me. I then tried to use the file command on it, and it too did not recognise it, simply reporting it as data. I then opened up the file in a hex editor and was surprised to see that the first bytes in the executable are a string containing a relative path to the location of the busybox executable on the system.

Comparing the hex of this executable with a normal ELF executable from the system shows that their headers seem to be the same size. It caught my attention that the presence of the string "/lib/ld-uClibc.so.0" in both files starts at the same offset.

Comparison

There are many strings in the binary that seem to refer to C libraries and functions, so it does look like a regular compiled executable.

I uploaded it to Decompiler Explorer (see result) and only BinaryNinja was able to recognise the file apparently, although trying to upload it to BinaryNinja's own cloud service didn't work

What binary format is this?

Improve this question
4
  • 1
    You may be able to get further with Ghidra if you force opening it as a raw binary and selecting the correct architecture.
    – multithr3at3d
    Oct 30, 2022 at 23:45
  • Thanks, I gave that a go and tried to open it as raw binary using the same architecture that Ghidra detected for another ELF binary, but the result doesn't appear to be very meaningful, with e.g. warnings about invalid instructions.
    – Amr Bekhit
    Oct 31, 2022 at 4:30
  • 1
    Are you sure this isn't a symbolic link to busybox that somehow got overlayed on top of the contents of its target (busybox)? Try comparing it (other than the first 17 bytes) with the busybox executable. Maybe whatever you're using to view the filesystem of the router has problems opening symlinks?
    – secondperson
    Oct 31, 2022 at 5:35
  • @secondperson You're right - it looks like something went wrong with binwalk's extraction. I checked the file on the running device with hexdump and it's just a normal ELF executable. Good catch! I used binwalk to extract the JFFS2 image and it has handled other symlniks just fine. Perhaps it's errors in the extracted image data, or a bug in binwalk.
    – Amr Bekhit
    Oct 31, 2022 at 7:43

1 Answer 1

Reset to default
0

It looks like something went wrong with binwalk's extraction. I checked the file on the running device with hexdump and it's just a normal ELF executable. I used binwalk to extract the JFFS2 image and it has handled other symlniks just fine. Perhaps it's errors in the extracted image data, or a bug in binwalk.

Thanks to @secondperson.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.