Greg's Scratchpad Thread on Roomba Comm Hacking

[vic7767]

It would be best to not attempt hacking the MCU on the Create. The reason being, you would not be able to recover the OS that was resident. There is no OSMO device available for the Create.

You can try an Internet search for :
Motorola, Inc., 2003
MC9S12E-Family
Device User Guide
V01.04
Original Release Date: 4 APR 2003
Revised: 04 NOV 2003
Motorola, Inc.
Freescale Semiconductor, I
Freescale Semiconductor, Inc.

You can do a little light reading of that .pdf document and it will point you to other Motorola documents that now have the Freescale logo on them. Then you will have an understanding of what the MCU is capable of. Then hit ebay and look for a non working Roomba. Usually you won't need most of the Roomba vacuum functions. You just want the SCI access, you can take out the cleaning brush deck, side brush, dust bin and vacuum motor, now you have a mini Create. Play with that MCU, at least then if you turn it into a brick you may be able to recover it via an OSMO. Of course the original boot-loader will be needed. Good luck

[biolizard89]

Thanks for the info. This looks like I may be getting in way over my head, but I'm still interested. One question I have is, what hardware do I need to mess with the MCU? Is a BDM programmer necessary? Based on a quick Google search, a BDM programmer looks like it'll cost me hundreds of dollars, which is way more than I can afford to spend on an experiment.

The updater program which was worked on in this thread sounds like it would be a huge help to me, which makes me wonder if there's some way to modify it so that pirates can't use it easily.

I'm not an expert on encryption or protection schemes, so this may sound stupid (I apologize in advance), but maybe the updater could try to recognize whether a firmware image is ripped from an actual iRobot image versus being homebrew, and only allow homebrew firmware images to be sent to the Roomba? Maybe this could be done by detecting snippets of code that are unique to iRobot code? Or maybe by requiring homebrew firmware to include some specific custom signature at a certain address which can't be added to an official image? E.g. require homebrew firmware to use a specified machine-language routine that outputs a certain string over the serial port, which is long enough that inserting that code into an iRobot image at the required address would overwrite some code necessary for the official iRobot firmware to boot, and then have the updater check for that code? I don't know how well any of this would work, but I think being able to upload homebrew firmware to a Roomba/Create through the serial port would be extremely useful.

The other thing that I personally think should be kept in mind is, if a few evil pirates download an iRobot image and use it with the updater, what damage is done? Not much; a few people were able to repair their Roombas without bothering iRobot about it (my understanding is that iRobot will provide an OSMO for free if the Roomba is defective and needs it). Any actual competitor to iRobot which used pirated software to develop their product would be vulnerable to a lawsuit, and thus I doubt that any large companies would try it. In general, software pirates are individuals who just want to use something for personal use without paying for it: illegal, but not a large threat to iRobot given the nature of the software we're discussing. Large companies are usually very careful not to pirate anything, even minor stuff, because then any profits they make from the resulting product would be subject to a certain-to-happen lawsuit. Thus, I don't really think much damage would occur if pirates were to use the updater program. Please correct me if I'm wrong!

Please let me know if I will need a BDM programmer. Thanks again for the info!

[THX-1138]

Hello Biolizard89 Glad to see you here!

What makes sense to you on the use of copyrighted material will not for the people who came up with it and their lawyers. iRobot was kind enough to let us tinker with certain aspects but not all. If you are interested in learning the how to-s, contact iRobot and ask about any educational assistance with your project, you may surprised what you may end up with.

[vic7767]

There is a nice little device made by P&E Micro that provides the BDM function, connects to the leads on the OSMO and when the OSMO is powered (9 volt battery) the BDM is connected to a PC via USB cable. P&E software downloads the OSMO image as well as the communications program and bootloader program.

The MCU on the Roomba also has the BDM connections. The one I got from P&E Micro cost $99 bucks. Ya can't go wrong with that.

[biolizard89]

There is a nice little device made by P&E Micro that provides the BDM function, connects to the leads on the OSMO and when the OSMO is powered (9 volt battery) the BDM is connected to a PC via USB cable. P&E software downloads the OSMO image as well as the communications program and bootloader program.

The MCU on the Roomba also has the BDM connections. The one I got from P&E Micro cost $99 bucks. Ya can't go wrong with that.

Thanks. I looked around the P&E Micro web site; I think you're referring to the USB-ML-12; is that correct? Does it come with the necessary software, or am I going to have to purchase that separately? Also, to access this connection on the MCU, is it as simple as removing the case and finding an existing plug on the motherboard, or would I have to physically modify or solder something?

One other question: it looks like the BDM interface is capable of downloading the contents of the MCU memory to the PC; will this work on the Create or Roomba, or did iRobot use the security features to disable that? (If it works, which I doubt, that would be useful in the event that I get tired of this project and decide I want the official firmware back on the Create/Roomba.)

Thanks again.

[vic7767]

Go to freescale and download the CodeWarrior package to work with the system. Don't buy the software from P&E.
Go to the codewarrior directory and run the program called hiwave.exe.

[biolizard89]

I apologize for bringing this up again (I am often slow to get things, please be patient with my ignorance), but I do not entirely understand why iRobot is concerned about the ability to update the firmware through the serial port. It seems to me that it's the same in terms of IPR as updating through BDM, it just saves a lot of hassle (and the risk of damaging something beyond repair if you're hardware-illiterate like me). Could someone explain in n00b-friendly language why a serial firmware updater would enable people to get access to the official firmware? I assume that an updater would allow PC to Roomba firmware transfers, but not in reverse. Is this correct? Is there any (possibly closed-source) setup which could be devised which allows homebrew code to be uploaded through serial but which doesn't work with official firmware dumps? In a previous post, I suggested checking for official firmware code snippets in the file, and refusing to upload if the official firmware is detected. I would be happy to buy an OSMO for the purpose of restoring the official firmware to my Roomba if necessary. I just am really, really averse to removing the case, and I (probably due to ignorance) do not see why it would be a problem to do it through serial.

Please have mercy on my n00bness, don't be mad, I'm just trying to learn here.

[vic7767]

Biolizard89, sorry I missed your post. Didn't scan the Sticky at the top. I believe that IRobot does not care if you want to blow away their OS running on the MCU. Basically that is the only way you can then put your own code in via a BDM. Of course once their OS is gone then the SCI port has lost its definition and the serial I/O is gone so you can't communicate that way. You also can't go back to their OS via the OSMO because the bootstrapper is also gone.

Greg wrote an updater program that captured the OSMO data and converted it to an .S record. Once the .S record was created the OSMO is no longer needed and the Roomba could be flashed via the PC and his program. It is feasible to write a serial updater but I don't know what data you would have in an .S record file that could be sent to the Roomba and it understand what to do with it since you don't know the encryption scheme IRobot is using.

[biolizard89]

Biolizard89, sorry I missed your post. Didn't scan the Sticky at the top. I believe that IRobot does not care if you want to blow away their OS running on the MCU. Basically that is the only way you can then put your own code in via a BDM. Of course once their OS is gone then the SCI port has lost its definition and the serial I/O is gone so you can't communicate that way. You also can't go back to their OS via the OSMO because the bootstrapper is also gone.

Greg wrote an updater program that captured the OSMO data and converted it to an .S record. Once the .S record was created the OSMO is no longer needed and the Roomba could be flashed via the PC and his program. It is feasible to write a serial updater but I don't know what data you would have in an .S record file that could be sent to the Roomba and it understand what to do with it since you don't know the encryption scheme IRobot is using.

Thanks for the reply.

Maybe I'm not totally clear on how this works, so I'll tell you what I'm looking for. My understanding is that the OSMO updates the firmware through the serial port. I would like a PC program that can do the same thing, but with a homebrew firmware that I write using CodeWarrior, GNU, or whatever. I don't need the ability to decrypt the iRobot firmware, upload it to the Roomba, or anything like that (seeing as that would tick off iRobot, and wouldn't do me any good), but if it is necessary, I would need to be able to encrypt a homebrew firmware into a format which could be sent through serial and have the bootloader know what to do with it. My understanding was that Greg reverse-engineered the encryption enough that this was possible; is that wrong?

My reason for wanting to use serial to load a firmware instead of BDM is because this is for a school project, using my school's Roomba or Create. I have a Roomba at home which I might be able to sacrifice for testing, but my school has been very clear to me, that while I am allowed to hack it any way I want software-wise, I am not allowed to remove the case or otherwise physically disassemble the Roomba (which I understand would be necessary for accessing the BDM port).

Does this explain what I want to do?

[vic7767]

I understand what you want to do but don't understand how you would write code to download into a proprietary OS. If you don't know the internal Roomba program and all of its sub routines and the address they reside in when you write into a memory range you wouldn't know what your code would change. And of course if you wrote into a critical program area you might not be able to recover the Roomba using an OSMO.

You might want to consider using the MindControl made by www.elementdirect.com

[biolizard89]

I understand what you want to do but don't understand how you would write code to download into a proprietary OS. If you don't know the internal Roomba program and all of its sub routines and the address they reside in when you write into a memory range you wouldn't know what your code would change. And of course if you wrote into a critical program area you might not be able to recover the Roomba using an OSMO.

You might want to consider using the MindControl made by www.elementdirect.com

Hmm, obviously I'm not understanding something here, being a n00b to all this. My only major experience with embedded platforms is the Charmed Labs Xport (which, of course, is quite a bit more advanced than the Freescale MCU in the Roomba in more than one way). Here's how the Xport stuff I'm using works. There are two programs in nonvolatile memory: the bootloader and the firmware. The bootloader is at the start of Flash, and the firmware is appended after it (with some padding so that the firmware is always a certain distance in). The bootloader runs at boot, and checks if a firmware update is being requested through serial. If not, it simply runs the firmware (by declaring a pointer to a void function, setting it to the location of the firmware in Flash, and calling that pointed function). If a firmware update is requested, it simply listens on the serial port for a binary file, and writes the input to Flash in the location where the firmware resides. The result is that the bootloader and firmware don't need to know anything about each other, except for the location where the firmware starts in Flash.

My impression (correct me if I'm wrong) is that the Roomba works somewhat similarly, but with protocol and/or storage encryption. So if I write a C program for the Roomba MCU and run it through the linker such that its start address is the same as that of the official firmware, and I send it to the bootloader (encrypting first if necessary), it should overwrite the official firmware but leave the bootloader intact, so that I can restore the official firmware with an OSMO if necessary. I shouldn't need to understand anything about the official firmware; just how the bootloader expects the firmware to be linked and/or encrypted.

If this is all correct, then I don't understand what the problem would be in writing a homebrew firmware and uploading it through serial, other than reverse-engineering the encryption (which I believe Greg has already done; correct me if I'm wrong).

If I'm wrong in all of this, as is likely, can someone explain where my assumptions are wrong here?

Thanks.

EDIT: Also, the MindControl looks very nice, but the nature of my school project requires that my finished product not require any hardware other than the Roomba/Create. The MindControl definitely does look cool, though.

[vic7767]

First off, I do remember Greg writing a program that would send .S record data to the Roomba. The .S record file was created (somehow) by reading a dump of the OSMO data.

Greg never reverse engineered the encryption protocol and after a few comments and communication with IRobot that activity stopped.

One of the major problems with trying to load code into the Roomba is when the OSMO communicates with the Roomba and is able to finally obtain stage 3 message exchange, Greg couldn't locate the bootloader address range. We don't know where it resides. It doesn't behave like it should. Hummmm.

You might go back through the first pages in this thread and see if there are still some I/O programs that you can download that can help you see the message exchange between the OSMO (I hope you have one there) and the Roomba. There may be some way to do what you want but it is beyond my experience level.

There may be some info about creating .S files at Sourceforge

here: http://sourceforge.net/

[biolizard89]

Wow, been quite a while since I last posted in this thread. I had other projects going on, so my interest in the Roomba/Create MCU got put on hold. But now, here's my next question. Where is the BDM port on the Roomba/Create board? I looked at an image online, and didn't see an obvious BDM port. I did see something marked JU1, but I'm unsure of whether it's the BDM connection. Is that the BDM port, or is there something else? And how would I connect a P&E Micro BDM programmer to it? Would soldering or physical modifications to the board be necessary?

Thanks!

[Gordon]

biolizard89:

First, I should point out that I know nothing about the Create's mobo. However, I have studied the Roomba-Disco and Scooba mobos, and see they both have the six-contact JU1 interface which I detailed in a page-4 post of this thread. If the Create is fitted with the same MCU, it seems quite likely that the same JU1 interface will be present on its mobo.

Just look for it. As shown in the photo, JU1 pads are very large and arrayed in a 2x3 pattern located very close to the MCU (its pin-28 corner is shown in the Disco-image).

You ask:

And how would I connect a P&E Micro BDM programmer to it? Would soldering or physical modifications to the board be necessary?

My guess is iRobot's mfg people probably use a six-position Pogo jig to pressure connect to the JU1 pads. You might like to solder-connect to them.

[mfortuna]

Most likely the MCU comes pre-programmed. The pad array was probably used for developement only.

I have had no need to take my create apart since it doesn't have a brush deck.

[vic7767]

The P&E BDM will not dump the contents of the Create or Roomba MCU. It can be used to dump the Roomba and Scooba OSMOs.

To access the MCU via the BDM will require the MCU to be unlocked. The only way to unlock the MCU is to erase the memory, load your own program and then the BDM can be used.

[Gordon]

Most likely the MCU comes pre-programmed.

Yes, it probably does.

The pad array was probably used for developement only.

No. Probably not, since iRobot is watching every mfg penny! To expand on that, "development" = {concept/spec ==> breadboarding ==> engineering_model ==> prototype_model ==>release_to_mfg}.

And while it is feasible that JU1 (with its large size plated-through holes) and associated SMD components (five resistors, three ceramic-caps, and one e-cap) got implemented on the first mfg run of Disco-PWBs, there has been at least three (4XXX-) PCB-foil revisions since that time, with each change giving iRbt an opportunity to either delete the JU1 structure, or discontinue mounting its related components, but the Company chose not to eliminate that JU1 functionality, ergo, the mfg-group is using it during some mfg-step.

IOW, iRbt had several obvious chances to save '20'-cents per PWB-asm, but decided against those savings.

[mfortuna]

That pin arrangement is normally for a header. It appears the header has been depopulated since it probably isn't needed for normal production. As is, the empty plated through holes are not usable as test points for any normal automatic test fixture. There may be testpoints elsewhere that can be picked up and that could be why they left in the discretes.

[biolizard89]

The P&E BDM will not dump the contents of the Create or Roomba MCU. It can be used to dump the Roomba and Scooba OSMOs.

To access the MCU via the BDM will require the MCU to be unlocked. The only way to unlock the MCU is to erase the memory, load your own program and then the BDM can be used.

I'm under the impression that the P&E BDM programmer is capable of performing said unlocking/erasing operation. Is that correct? If not, what would I need to do that?

mfortuna: Are you saying the JU1 connector is unlikely to function completely, or are you saying something else? (Sorry, I'm bad at understanding technical stuff that I'm not familiar with.)

[vic7767]

I'm under the impression that the P&E BDM programmer is capable of performing said unlocking/erasing operation. Is that correct? If not, what would I need to do that?

If you read the .pdf file on the MCU it explains how the locking can be done to protect the memory contents. It also explains that the only way to access the memory contents after that locking is accomplished is to erase the memory. How the locking, erasing, and unlocking is actually done is something that has not been accomplished in this thread.

Also, why do you want to dump the contents of the MCU ? The firmware is encrypted and has not been decoded by anyone in this forum.

The OSMO has the same MCU and is not locked, possibly you could use it to test with.