|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
vda
Joined: 11 Jan 2010 Posts: 11
|
Posted: Mon Jan 18, 2010 12:59 pm Post subject: Why is extracting ROM not possible? |
|
|
I have searched the forum and seen a lot of post saying it is not possible to extract the entire contents of a ROM - from a remote control, certainly - but none of them said why. Can anybody give some explanation, please? |
|
Back to top |
|
|
unclemiltie Expert
Joined: 21 Jan 2004 Posts: 1795 Location: Pittsburgh, PA |
Posted: Tue Jan 19, 2010 12:23 am Post subject: |
|
|
The processors that are used in the remotes contain the ROM (for the ROM-based remotes) and FLASH (for the flash based remotes) They are all on a single piece of silicon so "taking the ROM out" is not really possible.
Not only that, they are generally mounted chip-on-board with a dab of plastic melted on top so taking the whole chip off the board is damned near impossible. _________________ this JP1 stuff is a sickness! |
|
Back to top |
|
|
vda
Joined: 11 Jan 2010 Posts: 11
|
Posted: Tue Jan 19, 2010 2:15 am Post subject: |
|
|
It sounds reasonable from user's point of view, but from manufacturer's point, it doesn't.
It would mean that for every single remote control model, the manufacturer would have to create a new chip design (because the "how" transistors are connected together on a piece of silicon represents the "code" or "software" that the processor will execute) and adapt the production line to produce them, it would make the chip very-very expensive.
The fact is you could get a RC for a few quid. Breaking down the cost, we could guess the price to produce a micro-controller chip is just a few pence, so that chip must be of a very common design to be effectively mass produced.
So I still guess that the manufacturer make a "blank" chip then "upload" it with the contents (code and data) provided by the client. And since the remote control is usually not designed to keep such secret data like a credit card's chip would do, I don't think there would be a mechanism that blocks reading out data (and code) from the chip.
I've found a document on the net that seems to support what I thought: http://www.freescale.com/files/microcontrollers/doc/app_note/AN2497.pdf
(Note the BDM Connector mentioned in the document)
Certainly what I think is just a guess and I could be totally wrong. That's why we are here to discuss the question. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21234 Location: Chicago, IL |
Posted: Tue Jan 19, 2010 8:35 am Post subject: |
|
|
Hi vda, I'm curious as to what your goals are. I know you've already asked to see the source code for IR.exe, not as a developer but just out of curiosity, and now you want to extract the ROM from your remote. It sounds like you have more than just re-programming your remote in mind, so care to share? _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
unclemiltie Expert
Joined: 21 Jan 2004 Posts: 1795 Location: Pittsburgh, PA |
Posted: Tue Jan 19, 2010 11:33 am Post subject: |
|
|
vda wrote: | It sounds reasonable from user's point of view, but from manufacturer's point, it doesn't.
It would mean that for every single remote control model, the manufacturer would have to create a new chip design (because the "how" transistors are connected together on a piece of silicon represents the "code" or "software" that the processor will execute) and adapt the production line to produce them, it would make the chip very-very expensive.
The fact is you could get a RC for a few quid. Breaking down the cost, we could guess the price to produce a micro-controller chip is just a few pence, so that chip must be of a very common design to be effectively mass produced.
So I still guess that the manufacturer make a "blank" chip then "upload" it with the contents (code and data) provided by the client. And since the remote control is usually not designed to keep such secret data like a credit card's chip would do, I don't think there would be a mechanism that blocks reading out data (and code) from the chip.
I've found a document on the net that seems to support what I thought: http://www.freescale.com/files/microcontrollers/doc/app_note/AN2497.pdf
(Note the BDM Connector mentioned in the document)
Certainly what I think is just a guess and I could be totally wrong. That's why we are here to discuss the question. |
Boils down to a discussion about development costs versus reproductive costs. If you can save $.50 per unit and make 10M of them, you can certainly invest $1M to build a custom chip. If you only sell 100K of them, then not so good.
Go take a look at the Samsung S3C80 processor and you will understnad. This is a masked-ROM chip with the processor, programs and all of the built-in code on a single piece of silicon. the semiconductor manufacturing guys are quite good at building new masks for a masked ROM part at reasonable NRE fees and if you're making millions of them this is without a doubt the way to go. On the ROM-based remotes the user setup data is stored in a serial EEPROM which is connected to both the JP1 connector and the processor.
The Samsung S3F80 is essentially the same thing but with a built-in flash system instead of ROM. This is programmed with the code, etc at the factory with some kind of access directly to the chip. No one has really figured this out yet. (I know these remotes, not the other processor based remotes)
Anyway, like I said, both processors are then mounted chip-on-board so the programming mechanism (for flash remotes) and access to the internal storage is locked away under that little blob of plastic. So even if there is some kind of JTAG or other port to look inside, there is no guarantee that it is routed anywhere on the PCB so that someone could take a look at it.
And by the way, UEI does see their library of codes as one of their core pieces of IP and has protected it pretty well by doing things like asking web sites to take down UEI provided upgrades, code lists, etc. Also People have found that there are protections in the remotes that won't allow you to learn more than a few key sequences, supposedly to protect the code library. So it's not a far stretch to believe that they would have other protections in the hardware. _________________ this JP1 stuff is a sickness! |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Tue Jan 19, 2010 12:02 pm Post subject: |
|
|
The cost of a new mask set is around $50K for an 8 bit micro. The breakeven point is obviously dependent on the number of micros made, but in this context, a hundered thousand is enough.
Speaking from experience, there is another reason to prefer masked ROM micros. When each unit is individually programmed, there is a much higher chance of defective parts. One defective part in a an electronic unit (even if it only costs a penny) triggers the return of the whole unit. Nasty leverage.... |
|
Back to top |
|
|
vda
Joined: 11 Jan 2010 Posts: 11
|
Posted: Tue Jan 19, 2010 12:38 pm Post subject: |
|
|
To unclemiltie:
Quote: | The Samsung S3F80 is essentially the same thing but with a built-in flash system instead of ROM. This is programmed with the code, etc at the factory with some kind of access directly to the chip. No one has really figured this out yet. |
Thank you, that is the answer I was looking for. "No one has really figured this out yet" is not equal to "not possible".
To Rob:
Quote: | I'm curious as to what your goals are. I know you've already asked to see the source code for IR.exe, not as a developer but just out of curiosity, and now you want to extract the ROM from your remote. It sounds like you have more than just re-programming your remote in mind, so care to share? |
My pleasure! The reason I asked to see the code of IR.exe is to learn more about JP1 stuff. There are tons of howto's and FAQ's on this forum and on the net, but unfortunately the majority of them are not up-to-date and confusing. As a programmer I always find the source code the best "documentation" or "specification" to read - supposed that the software works, certainly.
And for the same reason, there is no better way to understand how a remote control works, at least for me, than by looking at its code. That's why I would like to extract the ROM.
By the way, I think some ROM's have already been extracted by some people. I could hardly think that people discovered how to inject assembly codes to data area of a RC just by coincidence.
And for people who think extracting ROM is equal to stealing IP, well, to get our hands on the code database, there is no need to extract ROM, the only tool we would need is an infrared receiver and enough time, is that right?
My ultimate goal is to learn microcontroller programming. And I find tweaking a JP1 remote fits my goal, and more, it is fun.
vda |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21234 Location: Chicago, IL |
Posted: Tue Jan 19, 2010 12:59 pm Post subject: |
|
|
vda wrote: | By the way, I think some ROM's have already been extracted by some people. I could hardly think that people discovered how to inject assembly codes to data area of a RC just by coincidence. |
The "data area" is separate from the main MCU, it's an EEPROM in the older remotes and it's a special area of the flash, set aside just for this purpose, in the newer remotes. The remotes were specifically programmed by UEI to allow data to be read from and written to these areas.
vda wrote: | And for people who think extracting ROM is equal to stealing IP, well, to get our hands on the code database, there is no need to extract ROM, the only tool we would need is an infrared receiver and enough time, is that right? |
There is code in the remotes to protect against that. The remote can tell the difference between normal usage and someone (or something) continually changing the setup code and then pressing all the buttons. When it detects this activity, it scrambles the keypad, something which a real user would notice but someone stealing the codes would not. So, once you've triggered the scramble, all the buttons that you learn from that point forward will be worthless. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
unclemiltie Expert
Joined: 21 Jan 2004 Posts: 1795 Location: Pittsburgh, PA |
Posted: Tue Jan 19, 2010 1:33 pm Post subject: |
|
|
vda wrote: |
By the way, I think some ROM's have already been extracted by some people. I could hardly think that people discovered how to inject assembly codes to data area of a RC just by coincidence.
vda |
Actually, the history of people figuring this out is quite interesting. But the first step was the ability to read the serial EEProm, and then the "startling" discovery that you could read and then back up and restore the EEPROM.
With the ability to read, and then using the keypad to set things up (codes, VPT, macros, etc) a bunch of people started figuring just what was in it, then figuring how to build upgrades, tools like IR, then, then, then...
For an interesting history lesson, read this:
http://www.remotecentral.com/cgi-bin/mboard/rc-remote/thread.cgi?1556
it's actually quite fascinating how each little nugget of info brought yet another discovery by someone else. _________________ this JP1 stuff is a sickness! |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Tue Jan 19, 2010 3:26 pm Post subject: |
|
|
The Robman wrote: | vda wrote: | By the way, I think some ROM's have already been extracted by some people. I could hardly think that people discovered how to inject assembly codes to data area of a RC just by coincidence. | The "data area" is separate from the main MCU, it's an EEPROM in the older remotes and it's a special area of the flash, set aside just for this purpose, in the newer remotes. The remotes were specifically programmed by UEI to allow data to be read from and written to these areas. | On top of that, there are protection flags set at the factory that prevent using the debugging port to read the protected areas. The Freescale documentation you mentioned also details the protection mechanisms. Basically, once the protection is activated, the only debugging command allowed to function is to erase the entire flash memory. _________________ Mike England |
|
Back to top |
|
|
vda
Joined: 11 Jan 2010 Posts: 11
|
Posted: Tue Jan 19, 2010 4:20 pm Post subject: |
|
|
Quote: | The "data area" is separate from the main MCU, it's an EEPROM in the older remotes and it's a special area of the flash, set aside just for this purpose, in the newer remotes. The remotes were specifically programmed by UEI to allow data to be read from and written to these areas. |
When I said ROM, I really meant the code part inside the microcontroler/flash chip, not the EEPROM or the writable part of flash chip. One must be very lucky to be able to figure out what assembly code to write to tell the remote control to update its internal data (for example: protocol update, extender) without seeing what the internal data is and/or where the code of some routines starts...
Quote: | There is code in the remotes to protect against that. The remote can tell the difference between normal usage and someone (or something) continually changing the setup code and then pressing all the buttons. When it detects this activity, it scrambles the keypad, something which a real user would notice but someone stealing the codes would not. So, once you've triggered the scramble, all the buttons that you learn from that point forward will be worthless. |
Well, then I would like to hear from John Fine about this if he is around: "John has been a One For All remote enthusiast for many years. He painstakingly went through all the codes in his Cinema 6 using an oscilloscope documenting what the signals looked like." -- from http://www.hifi-remote.com/jp1/history.shtml
Maybe John was lucky enough to not trigger the scrambler? |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21234 Location: Chicago, IL |
Posted: Tue Jan 19, 2010 4:26 pm Post subject: |
|
|
vda wrote: | When I said ROM, I really meant the code part inside the microcontroler/flash chip, not the EEPROM or the writable part of flash chip. One must be very lucky to be able to figure out what assembly code to write to tell the remote control to update its internal data (for example: protocol update, extender) without seeing what the internal data is and/or where the code of some routines starts... |
We don't need to jump to ROM address because there are vector addresses in the chips to make them all appear the same. For example, if we want to jump to the IR engine, we can jump to address $0146 regardless of where the IR engine really is in the main ROM because there will always be a vector jump at $0146 that will take us to where we need to be. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Tue Jan 19, 2010 4:41 pm Post subject: |
|
|
vda wrote: | Well, then I would like to hear from John Fine about this if he is around: "John has been a One For All remote enthusiast for many years. He painstakingly went through all the codes in his Cinema 6 using an oscilloscope documenting what the signals looked like." |
Perhaps I can answer this instead of John. John's interest in doing this was to understand the IR protocols, i.e the encoding methods used in the patterns of pulses and gaps that convey the data from the remote to the appliance, and to learn how to distinguish one from another. JVC sends its data in a very different way to Sony, for instance. For this purpose it doesn't actually matter if the wrong data is being sent if it is being sent with the correct protocol. The scrambler scrambles the data but the scrambled data is still encoded with the correct protocol.
________________
Graham |
|
Back to top |
|
|
mdavej Expert
Joined: 08 Oct 2003 Posts: 4501
|
Posted: Tue Jan 19, 2010 5:28 pm Post subject: |
|
|
vda wrote: | Well, then I would like to hear from John Fine about this if he is around: "John has been a One For All remote enthusiast for many years. He painstakingly went through all the codes in his Cinema 6 using an oscilloscope documenting what the signals looked like." -- from http://www.hifi-remote.com/jp1/history.shtml
Maybe John was lucky enough to not trigger the scrambler? | I expect since he looked at each in a scope, he was going slow enough not to trigger the scrambler. |
|
Back to top |
|
|
vda
Joined: 11 Jan 2010 Posts: 11
|
Posted: Tue Jan 19, 2010 5:53 pm Post subject: |
|
|
What you guys are saying is very interesting and convincing, but let me approach from a different angle:
The scrambler and all the efforts to protect the code library is possibly addressed to companies/rivals and not to hobbyists. If company A wants to stole the code library from company B's product, what is not simpler than to purchase, say 200 remotes of the same kind at, say 5 quids each. Then with each of them, they could discover the IR codes of, say 5 devices before the scrambler could be triggered. A price of 1000 quids for a code library of 1000 devices is very cheap in order to make a clone model, isn't it?
So do you really think protecting ROM makes sense and extracting ROM is not possible? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|