Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Hi all, The downloader looks excellent. If I send new programs/updates to customers, what is the likelyhood that they will be able to read my code. (I don't know too much about this). My understanding is that the .bxb file is in some sort of machine code? I have spent the past two years adding to and refining my code for my project, and I would hate to just hand it over to someone to use/copy without my permission. Having said this, I guess there is nothing stopping other people from obtaining additional BX24s and cloning chips from the new program I have just sent them!!! Hell, M$ can't stop people copying software. It would be real nice to be able to update a program on the otherside of the world without giving away the program. any ideas? Further to this, is it possible for someone to reverse engineer the code out of a programmed BX24? I have 2 weeks left before I finish my Engineering degree Wha Whooo! so I look forward to being more active in the group real soon when I will finally have time to build more projects. Thanks, David.

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> what is the likelyhood that they will be able to read my code. In most cases, not very. The only files that you need to send out are the PRF (Chip preferences file) and the BXB (The compiled binary object). >I have spent the past two years adding to and refining my code for my project, and >I would hate to just hand it over to someone to use/copy without my >permission. Having said this, I guess there is nothing stopping other people >from obtaining additional BX24s and cloning chips from the new program I >have just sent them!!! Hell, M$ can't stop people copying software. Protection can be done. Not that hard to do. First off dont distribute source unless the client licenses it and even then be sure the license is claused to protect you from them. No license. No source. No exceptions. There are all different ways of incorporating a copy-protection schemes to prevent theft of the BXB object and just downloading the object on ones own. However, I will state that it isn't going to stop a determine individual. Cloning the chip and the code inside would require a very good understanding of the chip, an eeprom burner and something just short of an EE degree. For the everyday user or consumer (if you intend to market a product) your pretty safe. Most dont own burners. There was a discussion here just the other day about version control....right after that I was thinking along the lines of not only of different methods of version control but also of copy protection and proof of object ownership. Funny you should bring all that up. A very common practice in the software world is imbedded copyright. Since its a well known method, I was prototyping some code for posting after the version discussion. A very simple way to implement, is to just create an array and put your copyright information in the array. If the BXB is stolen or used without your permission, the array is also copied that contained your copyright text. A court system can easily examining the object and determine who the true owner is. For a BX, a Block Data Class object would be best for that. The file just sits on your development box and downloads with the code. As for copyright protection of a chip itself, you need to devise a way that ensures that only the chips running your code authorized by you are valid. Poking a special key into eeprom comes to mind first off if using a BX24....if using a BX01, a software key based on the chip's serial number can also be incorporated. The BX01 has a serial number. The BX24 does not, only a hardware version number, which still could be implemented in a round about way, to ensure the BXB runs on a set hardware level. That and an eeprom poke could be used together. If you plan on, or if your project currently uses a Dallas 1-Wire device, you can implement an dual on/board /off board method by implementing the unique features of those devices. Every chip manufactured by Dallas contains a unique key code that can be accessed and used. Its one of the ways the FBI and others can trace things back to who bought it, in a case where a device is used, say in the making of a timing device of a bomb. That why they pick up all the little pieces. If you are really concerned about it, go with the on board/ off board method. Only devices you manufacture are then authorized. If someone steals the BXB, buys some chips and even some Dallas supporting chips...it still wont work for them since they cant change the Dallas codes and your software only functions on a range of codes. The range you purchased. But always remember...someone, somewhere may still hack at it and may succeed. If one really knows what one is doing they'll eventually break your scheme. But rest assured, most of the general public just want the "project" and dont have time or want to put in the effort to hack around. Whatever you do though, keep it simple or even transparent to the end-user. You'll only tee them off by requesting a protection key over and over and they'll look else where for whatever your project has to offer. Hope this helps! .db. -----Original Message----- From: David and Megan [mailto:] Sent: Thursday, October 25, 2001 7:23 PM To: Subject: [BasicX] RE: Software Download without BasicX downloader Hi all, The downloader looks excellent. If I send new programs/updates to customers, what is the likelyhood that they will be able to read my code. (I don't know too much about this). My understanding is that the .bxb file is in some sort of machine code? I have spent the past two years adding to and refining my code for my project, and I would hate to just hand it over to someone to use/copy without my permission. Having said this, I guess there is nothing stopping other people from obtaining additional BX24s and cloning chips from the new program I have just sent them!!! Hell, M$ can't stop people copying software. It would be real nice to be able to update a program on the otherside of the world without giving away the program. any ideas? Further to this, is it possible for someone to reverse engineer the code out of a programmed BX24? I have 2 weeks left before I finish my Engineering degree Wha Whooo! so I look forward to being more active in the group real soon when I will finally have time to build more projects. Thanks, David. Yahoo! Groups Sponsor Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed]

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

these are all good options. the 1-wire setup would be a good option for most hackers. along with the embeaded signature using the Block Data setup would give you the most security. another thing you can do. you send them a download program. that program reads an encripted file with extra data in it. that extra data is just an added anti-hack that your program knows. noops & jump to nothing realy anoise hackers. your program opens the encripted file and downloads only the data needed by the bx to the bx. they can still read the eeprom direct but you are not suppling them with the compiled bx code to start from. --- Dan Bielecki <> wrote: > > what is the likelyhood that they will be able to read my code. > > In most cases, not very. The only files that you need to send out are the > PRF (Chip preferences file) and the BXB (The compiled binary object). > > >I have spent the past two years adding to and refining my code for my > project, and > >I would hate to just hand it over to someone to use/copy without my > >permission. Having said this, I guess there is nothing stopping other > people > >from obtaining additional BX24s and cloning chips from the new program I > >have just sent them!!! Hell, M$ can't stop people copying software. > > Protection can be done. Not that hard to do. First off dont distribute > source unless the client licenses it and even then be sure the license is > claused to protect you from them. No license. No source. No exceptions. > > There are all different ways of incorporating a copy-protection schemes to > prevent theft of the BXB object and just downloading the object on ones own. > However, I will state that it isn't going to stop a determine individual. > Cloning the chip and the code inside would require a very good understanding > of the chip, an eeprom burner and something just short of an EE degree. For > the everyday user or consumer (if you intend to market a product) your > pretty safe. Most dont own burners. > > There was a discussion here just the other day about version > control....right after that I was thinking along the lines of not only of > different methods of version control but also of copy protection and proof > of object ownership. Funny you should bring all that up. > > A very common practice in the software world is imbedded copyright. Since > its a well known method, I was prototyping some code for posting after the > version discussion. A very simple way to implement, is to just create an > array and put your copyright information in the array. If the BXB is stolen > or used without your permission, the array is also copied that contained > your copyright text. A court system can easily examining the object and > determine who the true owner is. > > For a BX, a Block Data Class object would be best for that. The file just > sits on your development box and downloads with the code. > > As for copyright protection of a chip itself, you need to devise a way that > ensures that only the chips running your code authorized by you are valid. > Poking a special key into eeprom comes to mind first off if using a > BX24....if using a BX01, a software key based on the chip's serial number > can also be incorporated. The BX01 has a serial number. The BX24 does not, > only a hardware version number, which still could be implemented in a round > about way, to ensure the BXB runs on a set hardware level. That and an > eeprom poke could be used together. > > If you plan on, or if your project currently uses a Dallas 1-Wire device, > you can implement an dual on/board /off board method by implementing the > unique features of those devices. Every chip manufactured by Dallas > contains a unique key code that can be accessed and used. Its one of the > ways the FBI and others can trace things back to who bought it, in a case > where a device is used, say in the making of a timing device of a bomb. > That why they pick up all the little pieces. > > If you are really concerned about it, go with the on board/ off board > method. Only devices you manufacture are then authorized. If someone > steals the BXB, buys some chips and even some Dallas supporting chips...it > still wont work for them since they cant change the Dallas codes and your > software only functions on a range of codes. The range you purchased. > > But always remember...someone, somewhere may still hack at it and may > succeed. If one really knows what one is doing they'll eventually break > your scheme. But rest assured, most of the general public just want the > "project" and dont have time or want to put in the effort to hack around. > Whatever you do though, keep it simple or even transparent to the end-user. > You'll only tee them off by requesting a protection key over and over and > they'll look else where for whatever your project has to offer. > > Hope this helps! > > .db. > > -----Original Message----- > From: David and Megan [mailto:] > Sent: Thursday, October 25, 2001 7:23 PM > To: > Subject: [BasicX] RE: Software Download without BasicX downloader > Hi all, > > The downloader looks excellent. > > If I send new programs/updates to customers, what is the likelyhood that > they will be able to read my code. (I don't know too much about this). My > understanding is that the .bxb file is in some sort of machine code? I have > spent the past two years adding to and refining my code for my project, and > I would hate to just hand it over to someone to use/copy without my > permission. Having said this, I guess there is nothing stopping other people > from obtaining additional BX24s and cloning chips from the new program I > have just sent them!!! Hell, M$ can't stop people copying software. > > It would be real nice to be able to update a program on the otherside of the > world without giving away the program. > any ideas? > > Further to this, is it possible for someone to reverse engineer the code out > of a programmed BX24? > > I have 2 weeks left before I finish my Engineering degree Wha Whooo! so I > look forward to being more active in the group real soon when I will finally > have time to build more projects. > > Thanks, > > David. > Yahoo! Groups Sponsor > > ===== Tony Brenke North Tacoma, WA __________________________________________________

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Hey now.......I like the encrypted download file at the host level, great thought. And we now have that OEM downloader to do it all from a custom vbCode module. I have some EBCDIC encryption schemes I developed just last year for credit card number storage on an AS400 platform for internet card processing, transmission and storage. I'll dig them up from my CD archives and see how well they can be adapted to ASCII and a BX platform. They use single or double key algorithms of up to 30 bytes each. User selectable at encryption time. I can cut the keys shorter if need be, but most host PCs should be able to handle it. There's only three humans that I know of that under that AS400 algorithm, and the other two dont even know what a BX is. Strictly AS400 guys. Its new, its custom and will drive a hack just bonkers since it works on a decrypt technique of "get the key prompt right within N-number of times, or I encrypt even further". A hack is never gonna know what the N-th number assigned at encryption is, could be one time, two, ten...whatever. The end user with the decrypt key doesn't even have to know the N-th number. A vbModule would just make an external call to the encriptor or decriptor. The encryption keys can be imbedded in logic or sent separately from the objects, like in an email, and prompted for at install time. Call the Decriptor to decrypt the BXB-no-op-null-jumps file and then call the OEM downloader to send the extracted object down to the chip. Imbed copyright notices at the bxCode level to show/prove ownership and do a Dallas-codes type of thing to protect theft of the object from the actual chip. HEY DAVE!!! Yeah I think between us all....we can pretty well ensure your bxCode remain yours. Give us a bit of time to work out the nitty-gritty....go graduate or something in the mean time. .db. -----Original Message----- From: Tony Brenke [mailto:] Sent: Friday, October 26, 2001 1:40 AM To: Subject: RE: [BasicX] RE: Software Download without BasicX downloader these are all good options. the 1-wire setup would be a good option for most hackers. along with the embeaded signature using the Block Data setup would give you the most security. another thing you can do. you send them a download program. that program reads an encripted file with extra data in it. that extra data is just an added anti-hack that your program knows. noops & jump to nothing realy anoise hackers. your program opens the encripted file and downloads only the data needed by the bx to the bx. they can still read the eeprom direct but you are not suppling them with the compiled bx code to start from. --- Dan Bielecki <> wrote: > > what is the likelyhood that they will be able to read my code. > > In most cases, not very. The only files that you need to send out are the > PRF (Chip preferences file) and the BXB (The compiled binary object). > > >I have spent the past two years adding to and refining my code for my > project, and > >I would hate to just hand it over to someone to use/copy without my > >permission. Having said this, I guess there is nothing stopping other > people > >from obtaining additional BX24s and cloning chips from the new program I > >have just sent them!!! Hell, M$ can't stop people copying software. > > Protection can be done. Not that hard to do. First off dont distribute > source unless the client licenses it and even then be sure the license is > claused to protect you from them. No license. No source. No exceptions. > > There are all different ways of incorporating a copy-protection schemes to > prevent theft of the BXB object and just downloading the object on ones own. > However, I will state that it isn't going to stop a determine individual. > Cloning the chip and the code inside would require a very good understanding > of the chip, an eeprom burner and something just short of an EE degree. For > the everyday user or consumer (if you intend to market a product) your > pretty safe. Most dont own burners. > > There was a discussion here just the other day about version > control....right after that I was thinking along the lines of not only of > different methods of version control but also of copy protection and proof > of object ownership. Funny you should bring all that up. > > A very common practice in the software world is imbedded copyright. Since > its a well known method, I was prototyping some code for posting after the > version discussion. A very simple way to implement, is to just create an > array and put your copyright information in the array. If the BXB is stolen > or used without your permission, the array is also copied that contained > your copyright text. A court system can easily examining the object and > determine who the true owner is. > > For a BX, a Block Data Class object would be best for that. The file just > sits on your development box and downloads with the code. > > As for copyright protection of a chip itself, you need to devise a way that > ensures that only the chips running your code authorized by you are valid. > Poking a special key into eeprom comes to mind first off if using a > BX24....if using a BX01, a software key based on the chip's serial number > can also be incorporated. The BX01 has a serial number. The BX24 does not, > only a hardware version number, which still could be implemented in a round > about way, to ensure the BXB runs on a set hardware level. That and an > eeprom poke could be used together. > > If you plan on, or if your project currently uses a Dallas 1-Wire device, > you can implement an dual on/board /off board method by implementing the > unique features of those devices. Every chip manufactured by Dallas > contains a unique key code that can be accessed and used. Its one of the > ways the FBI and others can trace things back to who bought it, in a case > where a device is used, say in the making of a timing device of a bomb. > That why they pick up all the little pieces. > > If you are really concerned about it, go with the on board/ off board > method. Only devices you manufacture are then authorized. If someone > steals the BXB, buys some chips and even some Dallas supporting chips...it > still wont work for them since they cant change the Dallas codes and your > software only functions on a range of codes. The range you purchased. > > But always remember...someone, somewhere may still hack at it and may > succeed. If one really knows what one is doing they'll eventually break > your scheme. But rest assured, most of the general public just want the > "project" and dont have time or want to put in the effort to hack around. > Whatever you do though, keep it simple or even transparent to the end-user. > You'll only tee them off by requesting a protection key over and over and > they'll look else where for whatever your project has to offer. > > Hope this helps! > > .db. > > -----Original Message----- > From: David and Megan [mailto:] > Sent: Thursday, October 25, 2001 7:23 PM > To: > Subject: [BasicX] RE: Software Download without BasicX downloader > Hi all, > > The downloader looks excellent. > > If I send new programs/updates to customers, what is the likelyhood that > they will be able to read my code. (I don't know too much about this). My > understanding is that the .bxb file is in some sort of machine code? I have > spent the past two years adding to and refining my code for my project, and > I would hate to just hand it over to someone to use/copy without my > permission. Having said this, I guess there is nothing stopping other people > from obtaining additional BX24s and cloning chips from the new program I > have just sent them!!! Hell, M$ can't stop people copying software. > > It would be real nice to be able to update a program on the otherside of the > world without giving away the program. > any ideas? > > Further to this, is it possible for someone to reverse engineer the code out > of a programmed BX24? > > I have 2 weeks left before I finish my Engineering degree Wha Whooo! so I > look forward to being more active in the group real soon when I will finally > have time to build more projects. > > Thanks, > > David. > Yahoo! Groups Sponsor ===== Tony Brenke North Tacoma, WA __________________________________________________ Yahoo! Groups Sponsor Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed]

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

thinking more about this. the noops and jump to random would only work if it was not in the same order in the file. for instance. you send an update. a bit latter you send another. a compair on the two will provide a starting place to remove the extra data. But if they are placed in random locations in random orders this would be imposable. I love the idea of N-th number assigned at encryption, LOL. that would have me pulling my hair out. --- Dan Bielecki <> wrote: > Hey now.......I like the encrypted download file at the host level, great > thought. And we now have that OEM downloader to do it all from a custom > vbCode module. > > I have some EBCDIC encryption schemes I developed just last year for credit > card number storage on an AS400 platform for internet card processing, > transmission and storage. I'll dig them up from my CD archives and see how > well they can be adapted to ASCII and a BX platform. They use single or > double key algorithms of up to 30 bytes each. User selectable at encryption > time. I can cut the keys shorter if need be, but most host PCs should be > able to handle it. There's only three humans that I know of that under > that AS400 algorithm, and the other two dont even know what a BX is. > Strictly AS400 guys. Its new, its custom and will drive a hack just bonkers > since it works on a decrypt technique of "get the key prompt right within > N-number of times, or I encrypt even further". A hack is never gonna know > what the N-th number assigned at encryption is, could be one time, two, > ten...whatever. The end user with the decrypt key doesn't even have to know > the N-th number. > > A vbModule would just make an external call to the encriptor or decriptor. > The encryption keys can be imbedded in logic or sent separately from the > objects, like in an email, and prompted for at install time. > Call the Decriptor to decrypt the BXB-no-op-null-jumps file and then call > the OEM downloader to send the extracted object down to the chip. Imbed > copyright notices at the bxCode level to show/prove ownership and do a > Dallas-codes type of thing to protect theft of the object from the actual > chip. > > HEY DAVE!!! Yeah I think between us all....we can pretty well ensure your > bxCode remain yours. Give us a bit of time to work out the > nitty-gritty....go graduate or something in the mean time. > > .db. > > -----Original Message----- > From: Tony Brenke [mailto:] > Sent: Friday, October 26, 2001 1:40 AM > To: > Subject: RE: [BasicX] RE: Software Download without BasicX downloader > these are all good options. > the 1-wire setup would be a good option for most hackers. > along with the embeaded signature using the Block Data setup would give you > the most security. > > another thing you can do. > you send them a download program. > that program reads an encripted file with extra data in it. > that extra data is just an added anti-hack that your program knows. > > noops & jump to nothing realy anoise hackers. > > your program opens the encripted file and downloads only the data needed by > the bx to the bx. > > they can still read the eeprom direct but you are not suppling them with the > compiled bx code to > start from. > > > --- Dan Bielecki <> wrote: > > > what is the likelyhood that they will be able to read my code. > > > > In most cases, not very. The only files that you need to send out are the > > PRF (Chip preferences file) and the BXB (The compiled binary object). > > > > >I have spent the past two years adding to and refining my code for my > > project, and > > >I would hate to just hand it over to someone to use/copy without my > > >permission. Having said this, I guess there is nothing stopping other > > people > > >from obtaining additional BX24s and cloning chips from the new program I > > >have just sent them!!! Hell, M$ can't stop people copying software. > > > > Protection can be done. Not that hard to do. First off dont distribute > > source unless the client licenses it and even then be sure the license is > > claused to protect you from them. No license. No source. No exceptions. > > > > There are all different ways of incorporating a copy-protection schemes to > > prevent theft of the BXB object and just downloading the object on ones > own. > > However, I will state that it isn't going to stop a determine individual. > > Cloning the chip and the code inside would require a very good > understanding > > of the chip, an eeprom burner and something just short of an EE degree. > For > > the everyday user or consumer (if you intend to market a product) your > > pretty safe. Most dont own burners. > > > > There was a discussion here just the other day about version > > control....right after that I was thinking along the lines of not only of > > different methods of version control but also of copy protection and proof > > of object ownership. Funny you should bring all that up. > > > > A very common practice in the software world is imbedded copyright. > Since > > its a well known method, I was prototyping some code for posting after the > > version discussion. A very simple way to implement, is to just create > an > > array and put your copyright information in the array. If the BXB is > stolen > > or used without your permission, the array is also copied that contained > > your copyright text. A court system can easily examining the object and > > determine who the true owner is. > > > > For a BX, a Block Data Class object would be best for that. The file > just > > sits on your development box and downloads with the code. > > > > As for copyright protection of a chip itself, you need to devise a way > that > > ensures that only the chips running your code authorized by you are valid. > > Poking a special key into eeprom comes to mind first off if using a > > BX24....if using a BX01, a software key based on the chip's serial number > > can also be incorporated. The BX01 has a serial number. The BX24 does > not, > > only a hardware version number, which still could be implemented in a > round > > about way, to ensure the BXB runs on a set hardware level. That and an > > eeprom poke could be used together. > > > > If you plan on, or if your project currently uses a Dallas 1-Wire device, > > you can implement an dual on/board /off board method by implementing the > > unique features of those devices. Every chip manufactured by Dallas > > contains a unique key code that can be accessed and used. Its one of the > > ways the FBI and others can trace things back to who bought it, in a case > > where a device is used, say in the making of a timing device of a bomb. > > That why they pick up all the little pieces. > > > > If you are really concerned about it, go with the on board/ off board > > method. Only devices you manufacture are then authorized. If someone > > steals the BXB, buys some chips and even some Dallas supporting chips...it > > still wont work for them since they cant change the Dallas codes and your > > software only functions on a range of codes. The range you purchased. > > > > But always remember...someone, somewhere may still hack at it and may > > succeed. If one really knows what one is doing they'll eventually break > > your scheme. But rest assured, most of the general public just want the > > "project" and dont have time or want to put in the effort to hack around. > > Whatever you do though, keep it simple or even transparent to the > end-user. > > You'll only tee them off by requesting a protection key over and over and > > they'll look else where for whatever your project has to offer. > > > > Hope this helps! > > > > .db. > > > > > > > > -----Original Message----- > > From: David and Megan [mailto:] > > Sent: Thursday, October 25, 2001 7:23 PM > > To: > > Subject: [BasicX] RE: Software Download without BasicX downloader > > > > > > Hi all, > > > > The downloader looks excellent. > > > > If I send new programs/updates to customers, what is the likelyhood that > > they will be able to read my code. (I don't know too much about this). My > > understanding is that the .bxb file is in some sort of machine code? I > have > > spent the past two years adding to and refining my code for my project, > and > > I would hate to just hand it over to someone to use/copy without my > > permission. Having said this, I guess there is nothing stopping other > people > > from obtaining additional BX24s and cloning chips from the new program I > > have just sent them!!! Hell, M$ can't stop people copying software. > > > > It would be real nice to be able to update a program on the otherside of > the > > world without giving away the program. > > any ideas? > > > > Further to this, is it possible for someone to reverse engineer the code > out > > of a programmed BX24? > > > > I have 2 weeks left before I finish my Engineering degree Wha Whooo! so I > > look forward to being more active in the group real soon when I will > finally > > have time to build more projects. > > > > Thanks, > > > > David. > > > > > > Yahoo! Groups Sponsor > > > > > > > === message truncated === ===== Tony Brenke North Tacoma, WA __________________________________________________

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Hi Dan, > I have some EBCDIC encryption schemes I developed just last year > for credit > card number storage on an AS400 platform for internet card processing, > transmission and storage. I'll dig them up from my CD archives > and see how You can still capture the program as it goes down the serial port, in it's unencrypted form. It makes it more difficult, but there are (freeware!) tools that can do this. Also, the memory where the code is stored could be easily read - as you said, by a motivated and skilled individual (or organisation). It does worry me that someone could eventually copy my programs, but then again, there are ways around it - for example, you could use a Dallas iButton, as a 'dongle'. All the best, Mike

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Yes...I understand that. In theory I hacked the proposed update patch, exactly this way. Same would go for a full download. Tap the pins and capture the code. The data can be captured as it leaves the host and rides the download cable. Encrypting would be most useful at the host level so you could post BXBs on a website, for example. The BXB and PRF is protected from reverse engineering of the files alone, without doing it by chip code extraction or by simply buying chips and downloading someone's code into it and marketing the product as one's own.. Personally, I really like the full download as is and the fact that nothing can be uploaded out. If the update patch is implemented, I would never use it. Too much hassle. Not only do you have to have open two-way communications between the host and chip to examine what is currently loaded, you open all kinds of doors to user related problems and cumulative patches. Patch C needs Patch B installed. B level needs A installed. User only has A installed and obtained C level. Tries to load it, gets error messages saying cant be done and ends up calling your Help Desk. Its a stupid problem related to the user's ignorance and generates unnecessary Help Desk related work that costs you money in the end in telephone costs, salaries, and help desk possible issues. If they are not trained properly to diagnose user problem correctly, the original problem then multiplies by the Helpdesk factor. I would only go the full update route and the if the user has Level A and obtained level C, He skipped B and went right to C. The chip is updated to the new level. period. Level C not working?...Reload A. Try backing out a cum patch....Can be done, sure, but just too much grief and hassle. In the mean time, both the host and the BX programmers are asking for raises due to all the extra code and work involved. I hope the two-communications is never implemented, the code is safe from extraction. I like that. It closes so many problematic doors right off. All you have to worry about then is replication of the chip by eeprom burning it. The Dongle approach protects the chip from eeprom replication. I would do an onboard eeprom poke, that is only done by at distribution/sale time. Say, with a serial number scheme using a customer number and an algorithmic factor from the dongle. At program run time, extract both the Dongle code and the eeprom poke value and do a software evaluation of what they should be. That would triangulate the three entities, the software, the chip and the dongle. If the three dont match up...my worse-case personal response would be to start poking &hFF to as much of the code segments as possible, destroying any trace of logic in the chip and protecting intellectual property. The burner-hack then is left with a trashed chip with a dongle attached. A user in most cases would not be messing around with the dongle by swapping it out and end up trashing the chip that way. If a dongle is bad, a replacement is obtained third-party from you along with a download program that triangulates the new dongle-code to the chip. As for pin capturing of download code....You can always use 2-BXs. Cable-->BX1-->BX2. Encrypted BXB is sent to BX1. He runs decrypt logic on inbound Com1 data, decrypts it and sends it out Com 3. The chip to update is plugged into those ports using a custom designed update device. One could still capture from the two BX pins in theory but you compound the hack's troubles by introducing a second BX device inline. If there's just so much to deal with a hack will pass it on by and find something else easier to break. You could also just create a BX-Flash-type device using 2 BXs. They update bxCode and avoid the host connection altogether. One device can update many customer BXs. Plug the device into an update port designed on the project. The two BXs just talk to each other and one flashes the other with the updated logic. Still hackable at the pin level, but the flasher could transmit encrypted bytes and the Flashes decrypts and updates. He has decrypt logic built into the project code. The hack sees garbage at the pin connections. That method would only work if NetMedia releases the technical requirements involved in what happens after the ATN is triggered, something they may not want to do. The Flasher BX must be able to replicate the requirements of the cable connection. If NetMedia doesn't want to do that, then they could manufacture an OEM flash device that you plug your update code into. The signal goes out your update BX, thru the OEM device that manages pin stuff and into the flashes BX. Something like that would also generate some additional revenue for NM with a new BX related product. (their competitors, the P-Guys did it for their SX chip.) I dont dont think thats crosses any type of infringement lines (lawyers, get to work..) since its a well known practice to use flash devices. .db. -----Original Message----- From: Miguel Puchol [mailto:] Sent: Friday, October 26, 2001 2:33 PM To: Subject: RE: [BasicX] RE: Software Download without BasicX downloader Hi Dan, > I have some EBCDIC encryption schemes I developed just last year > for credit > card number storage on an AS400 platform for internet card processing, > transmission and storage. I'll dig them up from my CD archives > and see how You can still capture the program as it goes down the serial port, in it's unencrypted form. It makes it more difficult, but there are (freeware!) tools that can do this. Also, the memory where the code is stored could be easily read - as you said, by a motivated and skilled individual (or organisation). It does worry me that someone could eventually copy my programs, but then again, there are ways around it - for example, you could use a Dallas iButton, as a 'dongle'. All the best, Mike Yahoo! Groups Sponsor Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed]

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )