Need help identifying an architecture

[brainwash]

I've got this usb peripheral sitting on my table. Pretty cheap, links to a bluetooth board (via serial, I assume) to talk a very basic protocol.
I've taken a look inside the firmware update program, it has two embedded .hex images. The only difference between them is 11 bytes (some configurable parameters).

The hex files converted into binary hex weigh in at 15,856 bytes. They also have some readable strings in them, in the middle of the file - possibly hardcoded bluetooth serial communication.

I'm trying to establish which architecture is the microcontroller - it's a small black blob that probably costs <1$ in quantity. It's at most an ARM4 but more likely 8051 derivative.


Long story:
What's the end goal?
I'm trying to patch a bug on an EOL piece of hardware (<50$). Have already contacted the manufacturer two months ago, they initially wanted to provide a patch but later came around and said they don't have resources. I offered my support for free with willingness to sign an NDA. No response yet, so I've started working on this myself. Obviously I cannot disclose too much for now but either way I will give back to the community.
Of course, if I achieve the goal before they get back to me then screw the NDA.

The hex file was obtained from the official firmware updater on their site.

The patch requires a few (2?) extra chars sent via the serial (to BT) link.

[codeboy2k]

I'd agree at first glance it looks like 8051 code in your hex file.

First off, the hex file from the software update is Intel Hex format, that's a giveaway (but inconclusive, since it's a common format that's also used by non-Intel architectures).

Second, here's the first two lines of the file:

Code: [Select]

:0A000000020E1FBCFFFFFFFFFFFF11
:100E1F007591FF7596017800D8FE7800D8FE78009E

The first line loads 020E1F into address 0000, which is the reset vector. Those 3 bytes decode to the 8051 LJMP to address 0E1F, which also just happens to be the load address of the rest of the code starting at line 2, :100E1F ....

[codeboy2k]

For continuing with your reverse engineering,  what I would do next is turn the hex file into a binary image and load that into an 8051 simulator that you can step through.  You'll have initial difficulty with the peripheral I/O and any memory mapped I/O, (i.e. the BT device) but you can work around that as you try to figure it out.  You can also write those peripherals as library extensions to the 8051 simulator you are using, once you know you know what they are (i.e. what I/O ports are used, or memory mapped I/O, etc)

There are plenty of opensource 8051 simulators that have peripheral support, and of course there is Proteus VSM, a very good commercial product.

EDIT: if it's just 2 extra bytes, maybe you don't need to go through all this

[amyk]

Pretty sure this is an 8051.

[brainwash]

Thanks, that was fast!

[brainwash]

I'm resurrecting this very old thread just to provide with some explanations.

I bought a pair of "compatible" (i.e. knockoff) PS3 controllers that were marketed by Gioteck but could not get them to pair with my PC. They seemed like a pretty large gaming peripherals vendor so I assumed they got the knowhow to create a PS3 controller that's compatible in all regards.
So I took apart the software that does the firmware update and was able to extract two firmware images out of it - they just had a different sensitivity setting on the analog sticks. I managed to figure out what was wrong with the firmware but could not find a way to 'adjust' it. I offered my help to them (if needed) to solve the PC compatibility issue but never heard from them again.
Anyway, a few months later I look at the firmware again and see the string 'Gasia'. For those unfamiliar with the name, it's probably the biggest chinese brand name for these cheap knockoff controllers, so it would seem that I just paid for the brand but still got the clones. The compatibility issue has since then been 'resolved' by various 'sixaxis' receiver implementations and it even works with a Raspberry PI.
Unfortunately the pairing of these controllers is finicky, they lose connection sometimes, battery runs down pretty quick, they randomly lag or lose inputs. Not to mention that the analog movements are not as precise as with the original controller.

As a side note, I had a very similar experience with some Wiimote controller clones. They did not implement the standard BT protocol but just the bare minimum to be able to work with the Wii. The also had an idle current draw much larger than the original ones.


The takeoff is that at least with controllers you get what you pay for, perhaps even less. It's not worth the 'saving' from 40-50$ to 15-20$ if the knockoff runs through batteries 10 times faster and does not work correctly. Just buy original controllers and save the hassle for something else.