2

I have an android app (com.daye.dayeapp) to control my robot lawn mower. The App contains new firmware in the assets folder, in the form of a 122KB .bin file. How do I determine the architecture of that ? binwalk is no help.

My decompile/hacking experience is old. Z80 and 68k series CPU. Old pre-intel MacOS. Removed lots of copy protection back in the old days.

Looking at the output of strings, it contains lots of unencrypted data. Some places there are clearly '\0' terminated strings.

BinWalk has some entropy indicating some sections. But it is likely false positives. At least the last one.

Is there any other way than to pop it open and try to identify the architecture from the chips ?

It does have sensors, LCD display, buttons, bluetooth module. So it does have some I/O ports. I might try to read out raw firmware if I can find some JTAG header.

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
0             0x0             Falling entropy edge (0.711720)
120832        0x1D800         Falling entropy edge (0.843220)
123904        0x1E400         Falling entropy edge (0.842013)

0x0001E3B0  20 20 16 4C 06 4D 6F 77 65 72 31 23 0D 16 00 1B |...L.Mower1#....|
0x0001E3C0  12 33 01 A1 21 69 66 A0 0D 32 30 31 37 30 38 32 |.3..!if..2017082|
0x0001E3D0  33 32 33 34 35 74 A0 04 31 30 31 01 42 32 07 42 |32345t..101.B2.B|
0x0001E3E0  33 07 42 34 07 42 35 07 32 36 2A 0C 1D 6C 23 2A |3.B4.B5.26*..l#*|
0x0001E3F0  38 3F 54 5B 69 4D 6F 6E 54 75 65 57 65 64 54 68 |8?T[iMonTueWedTh|
0x0001E400  75 46 72 69 53 61 74 53 75 6E 6C 14 92 11 E3 0D |uFriSatSunl.....|
0x0001E410  2F 41 03 02 3D 2A 01 0D 11 6C 16 0D B4 21 24 1C |/A..=*...l...!$.|
0x0001E420  05 0F 54 24 54 21 24 1E 2E C6 23 1E 2E F6 17 1C |..T$T!$...#.....|

\0 terminated strings (with CRLF line endings !?):

0x0000A270  A0 24 00 20 A4 24 00 20 A8 24 00 20 43 4F 4C 4C |.$...$...$..COLL|
0x0000A280  49 53 49 4F 4E 20 72 65 74 75 72 6E 20 0D 0A 0D |ISION.return....|
0x0000A290  0A 20 00 00 54 49 4C 54 20 72 65 74 75 72 6E 20 |....TILT.return.|
0x0000A2A0  0D 0A 0D 0A 20 00 00 00 AC 00 00 20 AD 00 00 20 |................|
0x0000A2B0  AC 24 00 20 4F 55 54 20 42 4F 55 4E 44 41 52 59 |.$..OUT.BOUNDARY|
0x0000A2C0  20 72 65 74 75 72 6E 20 0D 0A 0D 0A 20 00 00 00 |.return.........|

And beginning of file. Looks strange ? Some jump table ?

0x00000000  B0 73 00 20 55 11 01 08 39 11 01 08 3B 11 01 08 |.s..U...9...;...|
0x00000010  3F 11 01 08 43 11 01 08 47 11 01 08 00 00 00 00 |?...C...G.......|
0x00000020  00 00 00 00 00 00 00 00 00 00 00 00 4B 11 01 08 |............K...|
0x00000030  4D 11 01 08 00 00 00 00 4F 11 01 08 51 11 01 08 |M.......O...Q...|
0x00000040  6F 11 01 08 6F 11 01 08 6F 11 01 08 E9 53 01 08 |o...o...o....S..|
0x00000050  6F 11 01 08 6F 11 01 08 1F 4F 01 08 6F 11 01 08 |o...o....O..o...|
0x00000060  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x00000070  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x00000080  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x00000090  6F 11 01 08 6F 11 01 08 6F 11 01 08 91 43 01 08 |o...o...o....C..|
0x000000A0  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x000000B0  FD 0B 02 08 01 4B 01 08 6F 11 01 08 6F 11 01 08 |.....K..o...o...|
0x000000C0  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x000000D0  6F 11 01 08 3F 68 02 08 6F 11 01 08 6F 11 01 08 |o...?h..o...o...|
0x000000E0  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x000000F0  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x00000100  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x00000110  A7 59 01 08 6D 5B 01 08 73 08 02 08 6F 11 01 08 |.Y..m[..s...o...|
0x00000120  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x00000130  00 F0 02 F8 00 F0 66 F8 0A A0 90 E8 00 0C 82 44 |......f........D|
0x00000140  83 44 AA F1 01 07 DA 45 01 D1 00 F0 5B F8 AF F2 |.D.....E....[...|
0x00000150  09 0E BA E8 0F 00 13 F0 01 0F 18 BF FB 1A 43 F0 |..............C.|
0x00000160  01 03 18 47 4C D6 01 00 6C D6 01 00 10 F8 01 3B |...GL...l......;|
0x00000170  0A 44 13 F0 03 04 08 BF 10 F8 01 4B 1D 11 08 BF |.D.........K....|
0x00000180  10 F8 01 5B 64 1E 05 D0 10 F8 01 6B 64 1E 01 F8 |...[d......kd...|
0x00000190  01 6B F9 D1 00 2D 15 D0 10 F8 01 4B 03 F0 0C 03 |.k...-.....K....|
0x000001A0  0C 2B A1 EB 04 04 0A BF 10 F8 01 3B A4 EB 83 14 |.+.........;....|
1
  • Can you find the processor for the system? You may get more information from the internet about the architecture of the binary, just by looking up the processor serial number online. – dingo_kinznerhook Mar 28 '19 at 16:23
4

And beginning of file. Looks strange ? Some jump table ?

0x00000000  B0 73 00 20 55 11 01 08 39 11 01 08 3B 11 01 08 |.s..U...9...;...|

That's an ARM vector table. The first word is the initial stack pointer value near the top of RAM, the rest are vectors.

  • B0 73 00 20 this is 0x200073B0 likely indicating a part with 32K RAM starting at 0x20000000 As that is more RAM than a lot of the cheaper parts have, it helps narrow your search

  • 55 11 01 08 this is 0x08011155 and the Reset Vector or initial entry point of the code from which you can tell two things:

    • the part has more than 64K of flash
    • the 1's bit set in the address means it is running in Thumb mode, which is all many current MCU's like Cortex-M0, M3, M4 etc offer.

Looking further we find

0x000000B0  FD 0B 02 08

So there's more than 128K of flash

0x00000120  6F 11 01 08 6F 11 01 08 6F 11 01 08 6F 11 01 08 |o...o...o...o...|
0x00000130  00 F0 02 F8 00 F0 66 F8 0A A0 90 E8 00 0C 82 44 |......f........D|

Your last vector is at 0x12c, so the size of the vector table may constrain possibilities

A good guess would be an STM32 of some sort, but there are many other silicon vendors which license the ARM Cortex cores and while 0x800000 rules out some makes, there are still many possibilities with which it is consistent.

Another thing you can note is the peculiar pattern of 0's in the vectors. In many vector table sources, these would correspond to reserved vectors, and you could try to match that pattern. To take a handy example from startup_stm32l073xx.s

__Vectors       DCD     __initial_sp              ; Top of Stack
                DCD     Reset_Handler             ; Reset Handler
                DCD     NMI_Handler               ; NMI Handler
                DCD     HardFault_Handler         ; Hard Fault Handler
                DCD     0                         ; Reserved
                DCD     0                         ; Reserved
                DCD     0                         ; Reserved
                DCD     0                         ; Reserved

etc

Your next step would probably be to disassemble, for example if you install a gcc-based arm cross development toolchain you could do something like:

arm-none-eabi-objdump -d -marm -Mforce-thumb --adjust-vma=0x8000000 -b binary YOURFILE.BIN

However, it is not entirely certain that the image you have itself starts at 0x8000000. It's possible instead that it starts at a higher address following a bootloader responsible for copying it into flash. Or it could be an image linked for the second bank of a dual bank part, that like the STM32L1xx does not offer bank address swapping (vs the STM32L0xx where the dual bank models do). You may need to do some experimenting with base addresses (as passed to the --adjust-vma) until you find sensible code at the targets of vectors. Particularly the reset one, where you'd expect to fairly early find things like a loop to copy initialized data to RAM.

Then you could look for aligned 32-bit constants that are addresses mapping to typical peripheral (GPIO, I2C or SPI, etc) registers and try to further narrow down from there. Often these constants will be found at the tail of the functions that initialize them to initialize the corresponding peripherals.

If you find encoding of FPU instructions, it would have to be at least a Cortex-M4, but just because the processor has an FPU doesn't mean code would necessarily be built to use it.

Is there any other way than to pop it open and try to identify the architecture from the chips ?

That is often fairly effective, but another that works is to see if there's an FCC sticker the on product, look that up, and see what you can learn from the internal photos portion of the listing report.

0
  1. Detecting CPU Endianness. At the file offset 0x000098C0 you can find next:

    000098B0: 74 00 00 20-4D 4F 54 5F-43 54 52 4C-28 2D 31 33 t MOT_CTRL(-13
    000098C0: 35 30 2C 31-33 35 30 29-0A 00 00 00-BA FA FF FF 50,1350)◙ ║·  

BA FA FF FF is -1350 for little endian 32-bit, so assuming we have LE CPU

  1. Detecting CPU using cpu_rec utility.

./cpu_rec.py AutoMower.bin
AutoMower.bin full(0x1e708) ARMhf chunk(0x6400;25) ARMhf

so assuming we have Little Endian ARM with hardware floating-point support.

  1. Detecting Entry Point.
    At the file offset 0x000098C0 you can find next:

    00006DB0: 54 68 61 6E-6B 20 79 6F-75 3B 00 00-3E 3C 00 20 Thank you; ><

3E 3C 00 20 is 0x20003C3E for little endian 32-bit and 0x3C3E is in range 0-0x1E707, so assuming start address of firmware is 0x20000000

2
  • Your interpretation of the start address is incorrect. The address you claim is in RAM, but this is a firmware which executes from ROM. – Chris Stratton Mar 29 '19 at 14:26
  • I agree, my approach is not quite correct. – Igor Matyuh Mar 29 '19 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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