Greg's Scratchpad Thread on Roomba Comm Hacking

Inside the Roomba and Scooba and more, Cool mods, Repair and Upgrades - including the all new iRobot Create Kit. Let's void that warranty baby!
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

CMD07 : Part two

Post by gssincla »

Ok, figured out the "odd" function.. The purpose of that function is to determine if the data read from the image was at the last position in the 64k segment. If so the paragraph pointer is incremented. The memory offset is increment by the width of the data read (in this case 2 bytes). Here is the C code for the function:

Code: Select all

// returns TRUE if the iFlashImageMemOffset is wrapped or if iFlashImageParagraph
// is wrapped. Else returns 0;
//
// the function will adjust the paragraph pointer if the data read reached
// the end of the memory segment (hit the 64k boundary at 0xFFFF)

unsigned int OSMO_DetectFlashImageParagraphWrap(unsigned int dataSize, unsigned int paragraphIncrement)
{
		OSMO_IsMSBofASet();		// this is useless code		
	
		unsigned int original_iFlashImageMemOffset;
		unsigned int original_iFlashImageParagraph;
		
		if ((unsigned long)(iFlashImageMemOffset + dataSize) > 0xFFFF)
			iFlashImageParagraph = iFlashImageParagraph + paragraphIncrement + 1;
		else 
			iFlashImageParagraph = iFlashImageParagraph + paragraphIncrement;
		
		
		iFlashImageMemOffset = iFlashImageMemOffset + dataSize;
		
		
		if (iFlashImageParagraph < original_iFlashImageParagraph) return 1;
		if (iFlashImageParagraph != original_iFlashImageParagraph ) return 0;
		if (iFlashImageMemOffset < original_iFlashImageMemOffset) return 1;
		
		return 0;

}
So with that mystery solved, we have a pretty clear idea of what is happening in the Cmd07 subroutine...

Code: Select all

#define MSB(x)	(unsigned char)((x >> 8) & 0x00FF)

void OSMO_SendCmd07(unsigned int seqNum)
{

/* translations:

dataLength = varA
seqNum = var0
indexer = var2

*/
	unsigned int dataLength, var8, var6, var4, indexer;
	
	// determine the packet length based on subCmd type
	dataLength = OSMO_DetermineCmd07PktLength(seqNum)

	iPacketLength = dataLength + 2;		// add space for additional fields
	
	arrayPacketDataBuffer[0] = iPacketLength;
	
	arrayPacketDataBuffer[1] = OSMO_Cmd07DetermineSubcommand(seqNum);
	
	iFlashImageMemOffset = OSMO_CalcFlashImageMemOffset(seqNum);
	iFlashImageParagraph = OSMO_CalcFlashImageParagraph(seqNum);
	
	indexer = 0;
	
		
	while (indexer < (dataLength/2) - 1)
	{
		value =	OSMO_GetFirmwareWordFromFlash(iFlashImageMemOffset, 
																					iFlashImageParagraph, 
																					iCmd07FlashAddrAdjustIndex);
	
			
		// store value into packetBuffer... offset of +2 is used to skip over
		// the subCmd and sequence number
		pktbuffer[LSB((indexer * 2) + 2)] = MSB(value)		
		pktbuffer[LSB((indexer * 2) + 3)] = LSB(value)
		
		
		OSMO_DetectFlashImageParagraphWrap(2, 0);
		
		indexer ++;		
	}
	
	OSMO_SendCmdPacketToRoomba(0x07);
	
}
This basically means that all the Cmd07 subroutine does is

Code: Select all

1) figure out how much data will be put into the data field of the packet
2) populate the data field with the sequence number
3) populate the data field with the subcommand number
4) populate the data field with the image data
   a) determine location of image data for the particular byte
   b) read the word from the flash space
   c) populate the data field with the word (MSB first)
   d) increment the memory offset for the next value
   e) determine if paragraph pointer needs to be incremented
   f) loop until the packet length has been fulfilled

What this also means is that we might have an encypted package. Which sux!!! :evil: I don't see any ASCII strings here and I know I should. Sigh.

I'm still tearing this program apart so I'm hoping to find more secrets that I can use to decode the package. I doubt it, but the flash reader subroutine might have some insight that I missed.

I do have some ideas. If i can figure out how to blindly inject code into the roomba, i can clear the security bit which will allow me to download the flash. This does break one of my primary objectives which was to do all of this without soldering, but eh.. if i can do it once and download the source, i'll never need to do it again. Bad for me, good for you.




any thoughts? anyone still reading this? :wink:
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

TP on Roomba

Post by gssincla »

I mentioned earlier on about a set of commands that would put the roomba into a state were it would sent out huge quantities of seemingly random data.
So far I've found the following sub commands of command 0x01
[any byte labeled as <x> means that any value can be inserted]

Code: Select all

0x0 <x> <x> - sends a stream of data (requires reset to end.. simply hitting power just pauses the stream) 
When I was testing the TP on the OSMO I noticed that the data coming across seems very similar to the data produced from this command. My current guess is that this is the roomba version of the test points (TP).

just some random info to add :)
twsnagel
Posts: 2
Joined: September 4th, 2006, 1:16 am

Post by twsnagel »

Wow - I'm reading it. Awesome job - keep going. It's way more advanced than I'm capable of, I'm reading and mostly understanding, but can't offer any help. It's like a textbook, not a collaboration for me. But thanks, and I read every day hoping for new insights.
User avatar
THX-1138
Robot Master
Posts: 2805
Joined: June 23rd, 2005, 8:16 pm
Location: United States of America

Post by THX-1138 »

:D Definitely! gssincla took over the light torch that rj5555 had here! Thanks for keeping up your research. Hope you continue after you come back from your Honeymoon! :wink:
User avatar
vic7767
Robot Master
Posts: 15556
Joined: January 14th, 2006, 7:31 pm
Location: Haughton Louisiana - USA

Post by vic7767 »

Greg is just gone for the long weekend he'll be back soon, not getting married until Nov.
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Post by gssincla »

Don't marry me off yet THX! ;-)

Like Vic said, I've been away on holiday this weekend over in DC. But I have been working on this project even while I was away. But before I get into that, let me say a sincere thank you to twsnagel, vic7767 and thx-1138 for their kind words and encouragement!

As a way of saying thank you for that, here's a new program to play with... This program will convert the raw hex files produced when capturing the communication between an OSMO and a roomba and put them into a modified S-record format.

Now why is this important, you are asking? Well, its the first part of a two part solution I'm working on. The second part is a software based firmware updating package. Instead of using a OSMO to upgrade your roomba, you can use a roo device, serial cable and this program to upgrade or downgrade your roomba.

What I will provide is the source code to the converter program (see attached file) and the binary of the Roomba Firmware Update program (but not the source) when its complete. I WILL NOT provide the source code to the update software nor will I provide ANY image file to use with the update program. I know, I know, this sounds very harsh and I'm sure I'm coming across as a bit of a d!ck about this, but I can't release these things for the following reasons:

1) I can't release the source because I don't want someone selling this to newbies and screwing them out of their hard earned money

2) I can't release the image files because these are copyrighted images of iRobot and I'm much too pretty to go to jail! ;-)

Anyway, I'm off to go recover from my trip. I'll try to get the updater program working this week. Wish me luck. And again, thank you all for the kind words and support!

greg.

EDIT: REMOVED APPLICATION ATTACHMENT. SEE POST BELOW FOR LATEST VERSION
Last edited by gssincla on September 6th, 2006, 2:20 am, edited 1 time in total.
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Because Microsoft hates you...</B>

Post by gssincla »

For those who have downloaded the program i just posted, you are probably noticing an error saying something to the effect of
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
well, this error is the result of Microsoft punishing those who do not program in .NET. Personally I hate .NET because it provides WAY too much bloat to code so I like to program in VC whenever possible... and since VC isn't Microsoft's favorite platform anymore they do not provide the necessary DLLs.


soooooooo... go to this link http://www.microsoft.com/downloads/deta ... layLang=en (Microsoft Visual C++ 2005 Redistributable Package) and download the package. Install this package and you will be able to run the program.

Sorry about the confusion.

Thanks to Vic for helping me resolve this!

greg.
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Corrected Application

Post by gssincla »

I found a few critical bugs in the S-Record program. Here is the updated version. Assuming I've fixed all the errors (HA!) this should be the final version of the S-Record application until I release the initial flash program.


If you downloaded the previous version, you'll need to delete it and use this version otherwise your output will not be compatible.

greg.

PS. It's been officially one month since I started this thread and sadly I've not cracked the Roomba code yet. Hopefully by next month :)
Attachments
OSMOHexToSRecord.rar
Converts raw data captures into S-record files
(62.95 KiB) Downloaded 527 times
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Sampler...

Post by gssincla »

I'm still working on the updater program... i'm having some trouble with the serial package i was using. i think i might just scrap it and write my own comm package.

but to give you an idea of what is to come, here is a sample of the updater. This version will simulate the process by going through all the necessary steps and putting a file in your C:\ drive called "roombafirmwareupdater.log" that contains what the output will be once the serial interface is setup.

BE WARNED THAT THERE IS THE POSSIBILITY THAT THIS PROTOTYPE COULD UNFLASH YOUR ROOMBA! DO NOT HOOKUP YOUR SERIAL CABLE OR WHATEVER INTERFACE YOU USE TO YOUR ROOMBA WHILE RUNNING THIS PROGRAM! This program will attempt to actually stage 3 your roomba... sometimes it works, sometimes it doesnt. but unless you have an OSMO handy, i wouldnt take the risk.

I should point out a few things

1) this program has no warranty. it is entirely likely that your roomba will die a horrible death if you hook it up while running this program in its current state

2) this program is not associated with any iRobot work. this is solely my own (ok, i think i've put this disclaimer in here enough that i shouldn't get sued by them... i've been sued by directv for hacking before... so i'm a little gunshy, can you tell? :wink: )

3) this program is an alpha release. this means its not even beta tester ready.

4) you will need the same package from microsoft installed that you needed for the S-record app. see the previous post for the link


anyway, give this a spin and let me know how you like it. the operation is pretty simple... get an S-record from the previous program i released. load it into this program by clicking "select image"... open a comm port by selecting the comm port and hitting "open port" (you will need to select an actual comm port on your system) and finally hit "flash"... since there is no real communication the whole process takes about 2 seconds to complete.

please give me your feedback!

greg.
Attachments
RoombaFirmwareUpdater.rar
Alpha release of the Roomba Firmware Updater application.
(23.61 KiB) Downloaded 570 times
User avatar
THX-1138
Robot Master
Posts: 2805
Joined: June 23rd, 2005, 8:16 pm
Location: United States of America

Post by THX-1138 »

Hello Greg!

Great work so far! One question, why did you not receive a 'cease and desist' from DirectTV first before a law suit? That is common practice within the law community. :? I think any company would go that route first before enforcing their rights if fringed upon. If iRobot sees something not to their liking they would submit a 'kind reminder or notice' then a 'cease and desist' if continued and finally a 'law suit' if person(s) defy their warnings (a.k.a. shots accross the port bow). :wink:
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Post by gssincla »

THX-1138 wrote:why did you not receive a 'cease and desist' from DirectTV first before a law suit?
well, it was back in college and i foolishly ordered something that they thought was used for hacking their satellite feed... so instead of asking me about it, they just assumed i was hacking. directv is known for being a legal d!ck of a company... they sue first, ask questions later. :evil:

so far i've not heard word one from iRobot... so hopefully they are unconcerned with our activities. :)

i'm hoping to have the comm issue resolved in the next day or so. i want everyone to have a chance to play with the updater as soon as possible.


greg.
Last edited by gssincla on September 28th, 2006, 4:11 pm, edited 1 time in total.
User avatar
vic7767
Robot Master
Posts: 15556
Joined: January 14th, 2006, 7:31 pm
Location: Haughton Louisiana - USA

Post by vic7767 »

Does anyone know if there is a difference in the OSMO image based on the CPU memory size? i.e. 128Kb vs 256Kb. I wonder if the memory locations addressed remain the same whether you have a Black or Blue? Just a thought..........
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Post by gssincla »

vic7767 wrote:Does anyone know if there is a difference in the OSMO image based on the CPU memory size? i.e. 128Kb vs 256Kb. I wonder if the memory locations addressed remain the same whether you have a Black or Blue? Just a thought..........
not sure Vic... i know that the OSMO has a string to select between the two different processors but they seem to be hardcoded to one or the other... there doesn't seem to be any control logic that that says "if the version is X, then the roomba is using processor Y" instead it seems to be more along the lines of "the roomba is processor Y" regardless of version.

if you can get me a transmission capture, i'll be more than happy to compare that with what i have.

my hunch is that they'd have different addresses otherwise we'd be able to get away with using a blue OSMO for everything (since it is the smaller footprint of the two). but again, that's just a guess without facts to back it up.

greg.
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

General Packet Encoding theories

Post by gssincla »

I'm still working on the updater program... I have it to the point that it will spit out the firmware image, but not to the point where the roomba is happy about it. Also, I've emailed iRobot to make sure they aren't unhappy with me releasing this. Unless I get a negative reply by Wednesday, it's being released when its done.

But that aside, I was talking outloud this weekend with Vic and something occurred to me. From the data captures it was seen that every so often that the OSMO would have to retransmit a packet because the roomba gave a negative acknowledgment. At first we all assumed this was because there was no flow control... I'm not going to dispute that as I believe that is still the case. However, I want to add some more observations....

If you look at the captures you'll see that the roomba sends an acknowledgement TWO packets back from the current packet. So the OSMO will respond by resending the last two packets. Take a look at this capture from an upgrade from version 8 to version 8...
>07 07 0a 00 00 3e 7d fc 62 59 58 36 f9 dc d3
<10 08 01 00 0f f9
>07 07 0a 01 01 47 d7 0b 3b 90 e8 1c 6f d6 61
<10 08 01 01 0a 6e
>07 07 22 02 02 a5 82 72 b0 a0 49 92 b3 b4 b5 19 88 8c 81 35 03 db 8d a2 4c ea 2c e2 59 ef fa 2a d6 46 1f b4 b9 0d 38
<10 08 01 02 0e d7
>07 07 22 03 02 5d 28 b5 b8 b6 a4 a3 67 f3 fc 2c 3b ed 9d 06 79 34 da 26 fa b9 19 9c 8a 46 8f c4 e0 32 3e b6 55 08 80
<10 08 01 03 0b 40
>07 07 22 04 02 d3 94 e0 ea ae b4 f5 12 d5 52 75 26 31 c2 62 a7 2c 2a ce 14 b8 e3 b6 c2 e4 d5 7b 86 43 22 cb 2e cf 22
>07 07 22 05 02 1f 12 1e 5f 3a e4 c1 a0 60 54 a8 86 38 0f a7 63 3d db 63 8e 31 46 09 fe 86 29 59 31 29 ee 26 08 a5 ba
<10 09 01 04 c0 55
>07 07 22 04 02 d3 94 e0 ea ae b4 f5 12 d5 52 75 26 31 c2 62 a7 2c 2a ce 14 b8 e3 b6 c2 e4 d5 7b 86 43 22 cb 2e cf 22
<10 08 01 04 0d a5
>07 07 22 05 02 1f 12 1e 5f 3a e4 c1 a0 60 54 a8 86 38 0f a7 63 3d db 63 8e 31 46 09 fe 86 29 59 31 29 ee 26 08 a5 ba
<10 08 01 05 08 32
>07 07 22 06 02 f3 fe 73 b4 c4 29 56 5b d0 68 80 ba d7 99 99 71 dc 72 c3 4b c6 c6 71 3d ca 83 34 d6 a0 44 98 33 84 b9
>07 07 22 07 02 aa 5a 45 b2 77 b6 a9 c0 e5 b7 75 60 7c 93 18 56 33 29 7c f7 7e 9e 9b 7e 4a 89 0f d9 19 11 89 51 c4 18
<10 09 01 06 c1 7b
>07 07 22 06 02 f3 fe 73 b4 c4 29 56 5b d0 68 80 ba d7 99 99 71 dc 72 c3 4b c6 c6 71 3d ca 83 34 d6 a0 44 98 33 84 b9
<10 08 01 06 0c 8b
>07 07 22 07 02 aa 5a 45 b2 77 b6 a9 c0 e5 b7 75 60 7c 93 18 56 33 29 7c f7 7e 9e 9b 7e 4a 89 0f d9 19 11 89 51 c4 18
<10 08 01 07 09 1c
>07 07 22 08 02 39 44 c5 65 41 87 d8 db d6 b7 b0 b4 a2 5f 3c 5d 1a ae da 5e 7d df aa b5 20 6b fe 04 f2 c2 ec 41 4f 0d
>07 07 22 09 02 a9 7a 6f 83 c8 63 01 c3 f6 1a 7e 71 47 c7 43 f1 ed b4 c9 b4 a7 91 7c d0 8b 82 4a f1 35 e6 fb 09 08 d3
<10 09 01 08 c6 b1
>07 07 22 08 02 39 44 c5 65 41 87 d8 db d6 b7 b0 b4 a2 5f 3c 5d 1a ae da 5e 7d df aa b5 20 6b fe 04 f2 c2 ec 41 4f 0d
<10 08 01 08 0b 41
>07 07 22 09 02 a9 7a 6f 83 c8 63 01 c3 f6 1a 7e 71 47 c7 43 f1 ed b4 c9 b4 a7 91 7c d0 8b 82 4a f1 35 e6 fb 09 08 d3
<10 08 01 09 0e d6
As you can see after about the 4th flash packet the roomba doesn't send back a response for the 5th and 6th flash packets. After the 6th packet the roomba sends a negative acknowledgement for the 5th packet. The 09 responses seem to always come with even numbered sequence numbers. So this leads me to believe that the packets are paired together.

But why? Why would you have pairs of packets in a data stream that is sequential in nature? My current guess is that one packet is the actual data and the other packet is the decryption key.

Take a look at the the last two packets from the scheduler update:
01 02 B6 10 F0 CF A6 8A AB 8E 4A 8F 03 82 34 75 84 A4 24 55 EA C9 CE 66 13 86 C1 A8 53 2E A3 F3 76 BA
02 02 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
This packet has always struck me odd because of the population of 16 0xFF bytes. Nowhere else in any of the other 4 data captures have I seen such a population of similiar values. From this I had the idea of "what if the decryption is done by ADDing/XORing/SUBing one packet from its mate?" ... so i wrote a small program manipulate the packets in this fashion. I didn't find any ASCII strings in the resulting outputs. I guess we can't be that lucky, eh?

Since its not as simple as combining the two packet components together, my guess is that there is a function that takes one value as a seed/key and manipulates the other packet's value based on a predetermined function. For instance, maybe its a lookup table substitution. At this point I really don't know. If this is the case, an interesting question is how is the key generated? I separated each of the pairs into separate files to see if there was a repeating pattern and i couldn't find one.

As another point of interest is the fact that the OSMO transmits more data than the E128 roombas can hold. Without going into great detail about how the processor is designed, there is 128KB of space available on the processor in total. Since the PC (program counter... the motorola name for the instruction pointer) is 16bits wide, you can only access a maximum of 64KB. To overcome this, the processor "windows" 16K of the flash at a time. There is only one block of memory that is visible at ALL TIMES. This 16KB block of memory is special because no matter where the window into the flash is pointed it is always visible at the address space of 0xC000-0xFFFF. This 16KB block is more than likely where your bootloader software lives. So long story short, if you have 128KB total and 16KB is dedicated to the bootloader which we can reasonably assume is not updated by the OSMO, this means you have a total flash space of 112KB. The problem is that once you strip all of the packet header bytes, checksum bytes, sequence number bytes and subcommand bytes, the image being transferred is 120KB... 8K too much! This being the case, is it not reasonable to assume that some part of the flash image is being dropped or used only temporarily... as a key would be?


anyway, this is just some food for thought. Anyone have any ideas? I welcome the feedback.


greg.
Howard
Posts: 35
Joined: June 15th, 2006, 2:18 am

Post by Howard »

So this leads me to believe that the packets are paired together.
More likely the roomba dosen't request retransmition of a packet untill it recieves the folowing packet & realizes that it has missed one.
This 16KB block is more than likely where your bootloader software lives.
When dealing with bankswitching to store the program the bank that can always be seen is critical it is whare the main program loop & common subroutines will be stored. It will be part of the download.
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Post by gssincla »

Howard wrote:More likely the roomba dosen't request retransmition of a packet untill it recieves the folowing packet & realizes that it has missed one.
i thought about that too. but looking at the comm subsystem of the OSMO which i can imagine is very similiar if not identical to the roomba there is more than enough space in the buffer to accommodate two unread packets (the buffer size is about 256 bytes for RX and about 512 bytes for TX on the OSMO). But for the sake of argument, lets say there is only enough space to hold one packet... this brings up another question of why do the first 4 packets go through without problem but from that point on you have to retransmit every two packet sets? Mind you the first two packets are half the size of the rest of the packets, but that still leaves two packets that make it through without issue. Whats more, if you look at it, the system handles pairs of packets without problem. So after the retransmit request, the system sends down a packet, it gets processed, and then it sends down another packet and gets processed without error. Its only after you have delievered a pair of packets that you run into issue.... as if the system is updating or processing the packets and runs out of time before the new set arrive. Thats another reason i was thinking the two were related somehow.

Now to add a counter point to my own argument, this is the possibility this is a result of the flashing window. Flashing is slow in comparison to normal RAM read/write. I'd imagine its faster than comm traffic, but still. if you have only a 64byte window to program with, then that could be the reason you are seeing pairs and has nothing to do with a key/data pair. But a 64byte flashing window seems very small.
When dealing with bankswitching to store the program the bank that can always be seen is critical it is whare the main program loop & common subroutines will be stored. It will be part of the download.
This is true. But I was assuming that since the bootloader itself isn't updated and by the bootloader i mean the kernel of the roomba (updater subroutine, bootup sequences, comm subsystem, system interface subsystem, etc), the only part of the roomba to really be updated is the application software... which is what i'd say the OSMO is uploading. Assuming that only half of the constant window is used by the bootloader/kernel, this would allow for a full package to be transmitted. That would give us the full 120K of needed space. But that just seems too cozy a fit to me.... but we are dealing with an embedded system, not a hard drive ;-)

But at this point, this is all speculation on my part. Until I can figure out how to access the internal workings of a roomba, i can only guess.

greg.
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

irobot speaks

Post by gssincla »

:roll:

well, possibly bad news campers....

i have spoken with irobot about releasing the updater program. in theory they are fine with it provide a couple of conditions are met. i'm currently clarifying the conditions.

but theres more...

it looks like we are (..ok, i am) getting dangerously close to the point where iRobot will stop being cool with me sharing information. The guy I've been talking with at iRobot is really cool about things, but its the lawyers who are laying down the law... which is the way it is with any company. so to quote the lawyers:
The Roomba firmware and the OSMO software are protected by the terms and conditions of the iRobot EULA and copyright law, including but not limited to the Digital Millennium Copyright Act (DMCA). You cannot legally copy or make derivative works of the Roomba firmware or the OSMO software, or distribute copies or derivative works of the same. The DMCA forbids circumvention of the access control mechanisms that we use to protect the Roomba firmware, including but not limited to the encryption that we use to protect the Roomba firmware. Circumvention of these access control mechanisms could subject you to significant civil and criminal liability.
again, i'm currently asking for clarification from iRobot, but it looks like we are fine just so long as we don't explain how the encryption is handled or how it can be broken. this, of course, kind of kills the spirit of this thread. while i might not like that, i totally understand their point of view. if we crack their encryption, publish the details of that cracking.. whats to stop their competitor from downloading their firmware, reverse engineering it and making a roomba clone? we do not want to put roomba in a situation where it will lose money because that will end up hurting us in the end. if irobot starts losing money to unfair competition they will start jacking up the prices on their hardware which will cost us. its all a matter of law and business.


soooooooooooo... until i get clarification from irobot on a few finer points the following is happening:

1) the updater will not be released

2) i will continue to work on this project, but not post my results

I'm hoping that irobot will allow us to continue this work. but until i get their go ahead, i have to protect my interest as well as the well being of my family...getting sued reaaaaaaaally hinders the well being of my family :)

I will keep you posted as i learn more.

greg.
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

Not dead...

Post by gssincla »

Just wanted to provide an update to those who were curious.

I'm still waiting for iRobot to get back to me about what our limits are for this type of forum. I am still doing research on the roomba (though slower now that i've got a big project at work).

as soon as i hear back from the legal department of irobot i will update you all.

greg.
User avatar
vic7767
Robot Master
Posts: 15556
Joined: January 14th, 2006, 7:31 pm
Location: Haughton Louisiana - USA

Post by vic7767 »

dang it :(
User avatar
gssincla
Robot Addict
Posts: 111
Joined: July 19th, 2006, 3:26 pm
Location: Chicago

The Rules....

Post by gssincla »

Hello Everyone....

Time for an update. If you look through this thread you'll see that I removed two posts on Aug 21 and replied their content with
EDIT: This content was removed by gssincla. Please see the post on 28 Sept 2006 for details.
I'm doing this as an act of good faith/good will to iRobot.

I've been talking with iRobot about my work here and they have expressed some concerns about the crypto work I've been doing. This is completely understandable. The fact is that iRobot's money is tied up in keeping their encryption secret... well, anyone who uses encryption has their money tied up in keeping that secrets, that's why its encrypted! :) As a result, I felt it would be best to remove these and any other posts I've done on reverse engineering their encryption method.

so, where does this leave us? Well, as a result of talking with iRobot, I have some general guidelines from them that I'd like to share:

1) No one should publically share or detail the encryption scheme used by iRobot for its firmware packages or any other encryption used by iRobot

2) The updater program I'm working on (yes, i've not forgotten about it :) ) can be released provided that it is released without an active firmware image.


These are pretty simple rules to follow I think especially since iRobot has been kind enough to give us access to the roomba's control via SCI, I don't see any problems at all with following them. But this does mean no more crypto work. As you know, I was never planning on releasing the firmware image with the updater so we are good there too.

I appreciate everyone's understanding in this matter.

greg.
Post Reply