Searching \ for '[PIC] Remove IC markings. Encryption' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Remove IC markings. Encryption'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Remove IC markings. Encryption'
2004\11\05@164008 by Robert Rolf

picon face
Wouter van Ooijen wrote:

>>Assuming you have room in the PIC, you could store a truly
>>(not pseudo)
>>random bit string as long as the user program. As bytes are
>>received by the
>>boot loader that are exclusive or'd with this bit string before being
>>programmed into memory.
>
> This system is easy to crack, the method is documented on the web
> somewhere (just to make clear that it is not my idea). The basic idea is
> that you feed the chip programs untill you get a recogniseable external
> effect.

But you WON'T if the program you feed requires a valid CRC in
order to load.

 Like: start with the firmware as you received it from your
> supplier. Change the first instruction to all possible bit patterns
> (only 2^14 to try, much less if the bits are not shuffled). Note which
> ones cause the chip to draw much less current. Probably only one: halt.
>>From that you can probably guess the first xor value, and hence the
> first instruction of the firmware. With some care and inspiration you
> can extend this to retrieve the full xor pattern.

Except that with an embedded, non obvious location of CRC
to validate the upload the PIC NEVER executes the
changed program. You now have 2^14^progsize patterns to try.
Peeling the lid off and probing would be faster.

>>And of course somewhere in the process part of the 128bit #
>>gets changed
>>so the password will be different for each subsequent update.
>
> That's a PITA for your customer administration - maybe OK for 1 or 2
> customers, but hardly maneagable for 1k or 1M.

Hardly a problem for any database system.
Key is made up of unique customer serial number + revision number.
IF the customer hasn't applied the prior patch, the current
patch won't load.
Digital satellite and cable operators, cell phone providers,
etc. don't seem to have a problem tracking millions of customers
and their digital encryption keys and MSL codes.

Robert



____________________________________________

2004\11\05@181718 by Bob Ammerman

picon face

----- Original Message -----
From: "Robert Rolf" <spam_OUTRobert.RolfTakeThisOuTspamualberta.ca>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
Sent: Friday, November 05, 2004 4:40 PM
Subject: Re: [PIC] Remove IC markings. Encryption


{Quote hidden}

Actually, if you have any idea that their is a CRC involved you only need to
try 2^14 * 2^(number of bits in CRC) values in the first couple of words.
Therefore, if the CRC is nice and large (like a 160bit MD5 hash for
example), you have now made the problem very difficult indeed.

Bob Ammerman
RAm Systems


____________________________________________

2004\11\06@025432 by Wouter van Ooijen

face picon face
> Except that with an embedded, non obvious location of CRC
> to validate the upload the PIC NEVER executes the
> changed program. You now have 2^14^progsize patterns to try.
> Peeling the lid off and probing would be faster.

In cryptography you are not allowed to assume something 'non-obvious'.
There is an exncryption method, and there is the key. The method is
known, the key is unknown. There are very good reasons for this, read
any good book on cryptology if you don't believe me.

Your CRC has just added another layer, with the CRC polynom as key. The
approach to crack that layer by itself would be to change one bit of the
application code, let's say bit 0, and try all CRC values untill you
find the one that matches. Repeat until you understand how the CRC is
derived. You can easily check whether the PIC writes or not by
obsetrving the current drawn.

> Hardly a problem for any database system.
> Key is made up of unique customer serial number + revision number.
> IF the customer hasn't applied the prior patch, the current
> patch won't load.
> Digital satellite and cable operators, cell phone providers,
> etc. don't seem to have a problem tracking millions of customers
> and their digital encryption keys and MSL codes.

No problem as long as you are the one who applies the update. When it is
up to the customer to do so it is a different story.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\11\06@070333 by Bob Ammerman

picon face

----- Original Message -----
From: "Wouter van Ooijen" <wouterspamKILLspamvoti.nl>
To: "'Microcontroller discussion list - Public.'" <.....piclistKILLspamspam.....mit.edu>
Sent: Saturday, November 06, 2004 2:54 AM
Subject: RE: [PIC] Remove IC markings. Encryption


>> Except that with an embedded, non obvious location of CRC
>> to validate the upload the PIC NEVER executes the
>> changed program. You now have 2^14^progsize patterns to try.
>> Peeling the lid off and probing would be faster.
>
> In cryptography you are not allowed to assume something 'non-obvious'.
> There is an exncryption method, and there is the key. The method is
> known, the key is unknown. There are very good reasons for this, read
> any good book on cryptology if you don't believe me.

Absolutely correct.

> Your CRC has just added another layer, with the CRC polynom as key. The
> approach to crack that layer by itself would be to change one bit of the
> application code, let's say bit 0, and try all CRC values untill you
> find the one that matches.

This can be made very difficult by using a large pseudo-CRC, like an MD5
hash. For example: 160 bits.

2^160 tries to get the first word right.

Rather impractical, especially since you aren't going to be able to do those
tries very quickly, they'll have to be done on the actual PIC, which can
slow things down just as much as it wants to. Say you design for a 5 minute
update time. Then you'll need 5 min * 2^160 to exhaustively try to find the
correct hash. That comes to roughly 1.43 * 10^43 years, a _very_ long time
indeed.

Of course, even if the PIC doesn't slow it down at all, you'll still have to
wait a little while :-)

Bob Ammerman
RAm Systems

____________________________________________

2004\11\06@074925 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> Your CRC has just added another layer, with the CRC polynom as key.
> The approach to crack that layer by itself would be to change one bit
> of the application code, let's say bit 0, and try all CRC values
> untill you find the one that matches.

Yes, given infinite time.  Only 32 bits of CRC would require on average over
2 billion attempts.  And that is just to find one pattern that matches one
CRC.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\06@090933 by Wouter van Ooijen

face picon face
> This can be made very difficult by using a large pseudo-CRC,
> like an MD5 hash. For example: 160 bits.

The idea is: the image is encrypted by XORing with a pseudo-random LFSR
sequence (based on a secret start value, a real one-time pad is
infeasible), the image is accepted only when the last part of it matches
an MD5 of (the rest of the image + a secret key). Accepting can be
implemented by writing the image while it is received, but writing an
activation vector only when the MD5 matches.

This of course works only on PICs that can be configured to allow the
program to write its own code space, but deny this to an external
programmer.

Let me think about this for a while. The point about crypto is that the
encrypter thinks, poses his method, and then the attackers get all the
time they want to create their method of attack. And the fact that one
lonely attacker can not pose a feasible attack means little :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\11\06@091455 by Wouter van Ooijen

face picon face
> Yes, given infinite time.  Only 32 bits of CRC would require
> on average over
> 2 billion attempts.  And that is just to find one pattern
> that matches one
> CRC.

There are only a limited number of sensible 32-bit CRCs, so using a
32-bit CRC does not give you a 2^32 factor of security. But see my reply
for a better method.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\11\06@120405 by Bob Ammerman

picon face
Wouter,

Why are you eliminating the idea of a real "one-time pad"? That is an
integral part of the security.

Bob Ammerman
RAm Systems

{Original Message removed}

2004\11\06@132835 by Wouter van Ooijen

face picon face
> Why are you eliminating the idea of a real "one-time pad"? That is an
> integral part of the security.

You mean a secret key as long as the application program? Because that
would double the size of the application program memory. IMHO that price
is too high. And it's not a one-time pad anyway, unless you want to
update only once.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\11\06@150003 by William Chops Westfield

face picon face
On Nov 6, 2004, at 6:14 AM, Wouter van Ooijen wrote:

> There are only a limited number of sensible 32-bit CRCs

Surely, based on the similarities to PRNGs, there are 2^32-1 ?  It
wouldn't
make much sense to a CRC that didn't span all possible values?

BillW

____________________________________________

2004\11\06@153429 by Robert Rolf

picon face
William Chops Westfield wrote:

> On Nov 6, 2004, at 6:14 AM, Wouter van Ooijen wrote:
>
>> There are only a limited number of sensible 32-bit CRCs
>
>
> Surely, based on the similarities to PRNGs, there are 2^32-1 ?  It wouldn't
> make much sense to a CRC that didn't span all possible values?

And you are also assuming that the CRC bytes are identifiable
as such. If you don't know which bits/bytes are the CRC you have
far more than 32 bits to diddle.

When I said "non obvious CRC" I meant 'having the CRC randomly
spread throughout the image'. The loader would know where to
look for the CRC based on the current secret key, but an
attacker could not since the one assumption we made is that
that attacker does NOT YET have the binary code, otherwise
why would they care to break the encryption scheme?

A wide PRNG with a reasonable size of secret PRN starting keys
(say 255, one for each update, and randomly sequenced by serial number)
would give you an unresolvably large search space.
And unlike text decryption, you have no way of knowing
for certain when you have cracked the binary, since one
could also embed nonsense blocks that could XOR into
real instructions.

And by basing the start key on a random association with
the unit serial number,
you prevent your customer from giving his update away
to a friend. Even if two identical version updates were compared,
to try and find the XOR sequence, the
random placement of CRC (or data for that matter) would
make a brute force attack impractical.

Yes, you have to create a unique update for each and every
unit, but thats the price you pay for securing your IP.

And there are methods, like those used by the satellite
and cable operators, where the encrypted data stream is common
to all recipients with individual access keys securely transmitted
to the end user, that only work on their unit.

Robert


____________________________________________

2004\11\06@161140 by Bill & Pookie

picon face
After five or six consecutive failed loads, the Pic could erase the entire
program.  There by destroying the code.

Wrote a data logger program that would answer the phone, give you a message
that it was a private site.  Then iw would give you two chances to enter the
password, with no promps of any kind.  If the second attempt was incorrect,
the program would start ignoring data from the modem, but stay on hook.
When the calling party hung up, the program would hang up the modem and wait
for next call.

The only feedback the caller got was that a computer had answered the phone,
unless the password was correct the first or second time.

Bill

____________________________________________

2004\11\06@161621 by Wouter van Ooijen

face picon face
> > There are only a limited number of sensible 32-bit CRCs
>
> Surely, based on the similarities to PRNGs, there are 2^32-1 ?

no

> It wouldn't
> make much sense to a CRC that didn't span all possible values?

You are confusing 'a CRC polynom' with 'a CRC value calculated by
applying a polynom to a datastream'. There are of course 2^N of the
latter, but much less *sensible* of the first (CRC polynoms for a given
N).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\11\06@172928 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> You are confusing 'a CRC polynom' with 'a CRC value calculated by
> applying a polynom to a datastream'. There are of course 2^N of the
> latter, but much less *sensible* of the first (CRC polynoms for a
> given N).

But there is nothing magic about the CRC algorithm.  What you are really
talking about in general are hashing functions, of which CRC is only a small
subset.  The hashing scheme can use a large key independent of the size of
the resulting hash value.  The CRC hashing key is the "polynomial" of which
only a subset of the possible values make sense as you said, and CRC
polynomials are the same size as the hash code.  However, this does not need
to be true in general.  A simple example is a much wider CRC of which only
the low bits are ultimately used, but there are many others of course.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\06@190735 by Attila Muhi

flavicon
face
And I once removed the markings on a op-amp by applying overvoltage to it. The markings flew away...  Of course the performance of the op was significantly reduced ...   Hmmm, power supply rejection , hmm  ....
But, to be serious, if the case is plastic, paint dilution would probably dissolve the plastic enough to remove the markings.


Attila - SM4RAN ______________________________________________________

Gratis visitkort - klicka här !
Allt inom e-handel! http://www.torget.se


-----Ursprungligt meddelande-----
Från: Bill & Pookie <EraseMEreddxspam_OUTspamTakeThisOuTcomcast.net>
Till: Microcontroller discussion list - Public. <piclistspamspam_OUTMIT.EDU>
Datum: den 6 november 2004 22:29
Ämne: Re: [PIC] Remove IC markings. Encryption


{Quote hidden}

>____________________________________________

2004\11\06@205931 by Bob Ammerman

picon face
The CRC _value_ will span 2^32 values.

Useful CRC _polynomials_ are much rarer than that. It is the polynomial you
would have to determine.

Bob Ammerman
RAm Systems

{Original Message removed}

2004\11\07@082434 by hilip Stortz

picon face


Bill & Pookie wrote:
>
> After five or six consecutive failed loads, the Pic could erase the entire
> program.  There by destroying the code.

which means that the software has a self destruct routine built in.
this will cause major reliability problems in any real application and
is a bad idea.  all that has to happen is for the system to crash and
happen to run the code in that part of memory.  this is very, very
likely to happen often in a real device/application.  it's a very
expensive method in terms of reliability.

> Wrote a data logger program that would answer the phone, give you a message
> that it was a private site.  Then iw would give you two chances to enter the
> password, with no promps of any kind.  If the second attempt was incorrect,
> the program would start ignoring data from the modem, but stay on hook.
> When the calling party hung up, the program would hang up the modem and wait
> for next call.
>
> The only feedback the caller got was that a computer had answered the phone,
> unless the password was correct the first or second time.

no, they also got the feedback that they had failed to use the correct
password as the system was non-responsive, any moderately sophisticated
war dialer should notice this and try again.

--
Philip Stortz, mad scientist at large -- "It is sobering to reflect that
one of the best ways to get yourself a reputation as a dangerous citizen
these days is to go about repeating the very phrases which our founding
fathers used in the struggle for independence." -- Charles A. Beard
____________________________________________

2004\11\07@082650 by hilip Stortz

picon face
worse than that, you allow them to stay connected as long as they want
looking for a back door or program defect to exploit, like a stack
overflow in the communications subroutine.  this is a very bad idea,
they should be disconnected immediately and the system should ignore the
modem and not answer after too many bad attempts.  the fact that the
system doesn't respond does tell them they used a bad password, not
responding but staying connected is a very, very bad idea.

Bill & Pookie wrote:
------
> Wrote a data logger program that would answer the phone, give you a message
> that it was a private site.  Then iw would give you two chances to enter the
> password, with no promps of any kind.  If the second attempt was incorrect,
> the program would start ignoring data from the modem, but stay on hook.
> When the calling party hung up, the program would hang up the modem and wait
> for next call.
>
> The only feedback the caller got was that a computer had answered the phone,
> unless the password was correct the first or second time.
------

--
Philip Stortz, mad scientist at large -- "It is sobering to reflect that
one of the best ways to get yourself a reputation as a dangerous citizen
these days is to go about repeating the very phrases which our founding
fathers used in the struggle for independence." -- Charles A. Beard
____________________________________________

2004\11\07@143120 by Peter L. Peres

picon face

On Sat, 6 Nov 2004, Bob Ammerman wrote:

> Why are you eliminating the idea of a real "one-time pad"? That is an
> integral part of the security.

Afaik in order to work as advertised the pad must be the size of the data
+ 1 bit. Where do you store it ?

Peter
____________________________________________

2004\11\07@190023 by Bob Ammerman

picon face
> Afaik in order to work as advertised the pad must be the size of the data
> + 1 bit. Where do you store it ?
>
> Peter

In a PIC with twice the code space as the application requires. Nobody said
security is free. :-)

Bob Ammerman
RAm Systems

____________________________________________

2004\11\08@052636 by Alan B. Pearce

face picon face
>> Why are you eliminating the idea of a real "one-time pad"?
>> That is an integral part of the security.
>
>You mean a secret key as long as the application program?
>Because that would double the size of the application program
>memory. IMHO that price is too high. And it's not a one-time
>pad anyway, unless you want to update only once.

Another possibility may be some CRC or hash of the code already in the chip,
which means any update would have to be applied in correct order, requiring
any previous updates as well. There may already be code in the chip to
obtain this hash on start-up, as part of the reset checking.

Another possibility that I have not seen proposed is some means of error
correcting code being used, with deliberate errors in the downloaded code
being corrected once it is inside the chip. This could mean that code could
be mangled to look like a processor from manufacturer A, when it really is a
processor from manufacturer B. It would take some thinking about how to do
it, and would involve a fair amount of error correcting CRC on each
download, but may still be do-able.

____________________________________________

2004\11\08@061416 by Wouter van Ooijen

face picon face
> Another possibility that I have not seen proposed is some
> means of error
> correcting code being used, with deliberate errors in the
> downloaded code
> being corrected once it is inside the chip. This could mean
> that code could
> be mangled to look like a processor from manufacturer A, when
> it really is a
> processor from manufacturer B.

This method evaporates when you apply the cryptographic 'first law': the
key is secret, the encryption method is public.

If you don't grok this at the abstract level think this way: the method
must be safe even when one (or even all) of the designers leaves the
company and starts working for the opposition.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\11\08@112334 by Support - KF4HAZ

flavicon
face
I am sure the boss would agree with you,
but he didn't design the bootloader, nor the products.
I am the only one here who knows the algorithm (job security)
He did not cover this in the NDA and I aint gonna tell him.

KF4HAZ - Lonnie

----- From: "Wouter van Ooijen" <wouter@
{Quote hidden}

____________________________________________

2004\11\08@115145 by hilip Stortz

picon face
that frankly strikes me as unethical, in the extreme.  you've been hired
and paid to do specific work and designs.  the entity employing has the
right to full documentation of the product you produce for them.  if you
are working as an independent contractor it may be somewhat reasonable,
if those who contract you understand that they are not going to receive
full documentation, otherwise you are frankly ripping them off and it is
highly unethical.  if you produce work for someone, that work is theirs
unless you've negotiated some other agreement or are acting as a
contractor rather than a traditional employee, and i believe the courts
would generally agree with me.  
i certainly believe that most would agree with on the ethics of this
situation.  by keeping part of the work paid for secret and demanding
job security for it you are in fact stealing by leveraging what you've
already been paid for but have failed to deliver against future
employment, i find this despicable in the extreme.  
where i have worked i've always provided full documentation, and even
after leaving i've consulted (for pay of course) to help the company
understand how things worked when there wasn't documentation on some
small points or the documentation had been lost/stolen (in this case it
was a spin off company, and a dishonest employee had stolen many of the
computer files relating to his work and the work of others, along with
the ceo's machining tools...).

i do not work for free, and if you contract me i will charge fees for
everything and may chose to only license certain tricks to you, however
if you hire me as an employee, you own my work (along with the liability
for it) and i will fully disclose unless a prior arrangement has been
made.  this is the implied contract, to do otherwise is dishonest and
frankly criminal.  if you believe you are being under compensated for
your' work you do not have the right to steal some of your' own work,
you should renegotiate or find other employment, not unilaterally decide
not to disclose all of the product you have generated as an employee. and i expect no less from those employing me, there is an implied
contract as well as any specific contract when one is employed and if
you can't honor that you need to honestly renegotiate rather than
pulling dishonest tricks to extort the employer.

Falcon Wireless Tech Support - KF4HAZ wrote:
{Quote hidden}

----------

-- “it is possible to fool all the people all the time—when government and press
cooperate.”-George Seldes, 1938 <http://www.wanttoknow.info/buzzsaw10pg>
<www.tompaine.com/articles/kerry_won_.php>
<http://207.44.245.159/article7217.htm>
<http://www.cooperativeresearch.org/project.jsp?project=911_project>

___________________________________________

2004\11\08@122921 by Support - KF4HAZ

flavicon
face
Actually it is just a matter of he never asked.
If I were to leave on good terms I would release the algorithm to him,
but having been cheated in the past I tend to protect myself.
Lets say you were hired to develop something with the understanding that
1. You would receive hourly wages for R&D, and
2. If the product took off, you would get a commission on all future sales.
This is in our agreement.
Now suppose your boss gets greedy and decides he does not want to pay
you your share of the commissions from sales, so you are out the door.
Then one day he needs an update but your replacement cant find your algorithm,
so you are called back in, negotiate an even better sounding deal, what guarantee do you have that the same will not happen after he has the algorithm?

KF4HAZ - Lonnie

----- From: "Philip Stortz"
{Quote hidden}

> ______________________________________________

2004\11\08@124405 by Support - KF4HAZ

flavicon
face
Also forgot to mention, our agreement states that I hold the copyright on All source code and PCB artwork.


{Quote hidden}

2004\11\08@195253 by hilip Stortz

picon face
that's somewhat reasonable, and i might do the same to that extent.  i
have been ripped off by employers before.  the fact that you are to
receive commission means you have maintained some ownership interest in
the design, so there's no problem with keeping some of it secret unless
asked or unless you left under good terms.  if you were hired for
straight salary that would be a different situation.  
at the same time i think it's appalling that in the u.s. companies can
claim full ownership of any patent an employee comes up with.  in all
other countries only individuals can own patent rights when they invent
something, the company may be entitled (because of an employment
contract) to free use etc., but they don't get to own it completely. and this is abused, i decided not to be a "meter reader" for our power
company because their employment contract says that they'd own any
patent i ever came up with for the rest of my life, even if i wasn't
working for them and it had nothing to do with their business!  that's
an awfully high price to pay for a low paying non-technical job!

it sounds like you are fortunate enough to have a reasonable employer,
as opposed the the more common greedy bastard variety that doesn't think
employees deserve what little they're already getting (and there are
plenty of those, even in high tech fields with no respect for engineers etc.).

Falcon Wireless Tech Support - KF4HAZ wrote:
{Quote hidden}

-----------

-- “it is possible to fool all the people all the time—when government and press
cooperate.”-George Seldes, 1938 <http://www.wanttoknow.info/buzzsaw10pg>
<www.tompaine.com/articles/kerry_won_.php>
<http://207.44.245.159/article7217.htm>
<http://www.cooperativeresearch.org/project.jsp?project=911_project>

___________________________________________

2004\11\08@200313 by hilip Stortz

picon face
good deal!  if you own it, you own it, i have no problem with that. it's more the situation that has happened for instance with some water
departments before (and it was done here in casper) where the good old
boys decided to use left hand shut off valves here and there with some
little address formula to remember which was which to insure job
security, since someone new wouldn't know which shut off valves were
"right handed" and which were "left handed", and as i said i know this
was at least attempted right here in casper wyoming!  now that's a dirty
and stupid trick.  needless to say when one of the left handed valves is
encountered it's replaced immediately, at considerable cost to the city
and the residents.  and other schemes have been used by some tradesmen
in the past.  
unions are a good thing, but they have become just as corrupt as the old
bosses, just as any one familiar with human nature would have expected. still better than it was, but still a long way from good.

of course part of the problem is the hiring power big companies have,
they often think they can set any rules they want, and often get away
with it.  they want to hire high-tech people and treat them like temps
and then wonder why there is no employee loyalty, well it's a two way
street, if you want loyal employees who respect you then the employer
needs to respect the employees.  some how management people don't seem
to understand this principle at most companies, they are really clue
less as to why they are hated and despised by their technical employees
whom they treat like dirt.  thick headed morons, and educated morons
rarely realize when they've been stupid and even more rarely do they
admit it or change their ways.

i'm glad you have a good working environment where your' skills are
actually valued appropriately.  in my experience working for good people
is more important than just the salary and benefits, i'll take a lot
less money to work for a good boss and want a lot more to put up with
idiotic management and you can guess who i'll stay with longer.

Falcon Wireless Tech Support - KF4HAZ wrote:
>
> Also forgot to mention, our agreement states that I hold the copyright on All source code and PCB artwork.
>
> > Actually it is just a matter of he never asked.
------

-- “it is possible to fool all the people all the time—when government and press
cooperate.î-George Seldes, 1938 <http://www.wanttoknow.info/buzzsaw10pg>
<www.tompaine.com/articles/kerry_won_.php>
<http://207.44.245.159/article7217.htm>
<http://www.cooperativeresearch.org/project.jsp?project=911_project>

___________________________________________

2004\11\09@073656 by olin_piclist

face picon face
Philip Stortz wrote:
> at the same time i think it's appalling that in the u.s. companies can
> claim full ownership of any patent an employee comes up with.

First, they can't.  Patents are issued to individuals only.  However the
patent rights are property that can be assigned to other entities, including
corporations.

Second, I don't see how it's my business if two parties voluntarily enter
into an agreement where each does something for the other.  If A pays B and
in return B agrees that all intellectual property developed by B belongs to
A, why should you care?  It seems silly to disallow this when both A and B
feel it's to their advantage.  It is exactly these kinds of deals that drive
innovation and make the world work.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\09@074251 by olin_piclist

face picon face
Philip Stortz wrote:
> unions are a good thing, <blah, blah, blah>

I think this has now deviated way beyond PICs, EE, or anything remotely
technical.  Can we cut this policital rant here now?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\09@162544 by Peter L. Peres

picon face

On Mon, 8 Nov 2004, Falcon Wireless Tech Support - KF4HAZ wrote:

> Also forgot to mention, our agreement states that I hold the copyright
> on All source code and PCB artwork.

There are no irreplaceable people. People can be divided into two groups:
one which is harder to replace, and the other which is easier to replace.

good luck,

Peter
____________________________________________

2004\11\10@025659 by hilip Stortz

picon face
you'll see that i've moved it to [ot] and changed the subject
appropriately.  at the same time, i would say the issue of fair
compensation for work performed should be of interest to all technical
people.  the more off topic portions were simply examples of fair and
unfair expectations on the part of employers and employees, given to
clarify the issue.  technology does not exist in a vacuum, societal
issues do bear a great deal of relevance on the practice of technical
skills and appropriate compensation is a frequent area of disagreement
between technical people and their employers.  however i will concede
that i should have been more concise, and i usually do try to be as
concise as possible while still communicating effectively.  (and please,
no personally attacks on my writing style etc., frankly i do a lot
better than most technical people i've known, and certainly much better
than most technical writers i've read, though not the really good ones).

Olin Lathrop wrote:
>
> Philip Stortz wrote:
> > unions are a good thing, <blah, blah, blah>
>
> I think this has now deviated way beyond PICs, EE, or anything remotely
> technical.  Can we cut this policital rant here now?
------
-- “it is possible to fool all the people all the time—when government and press
cooperate.”-George Seldes, 1938 <http://www.wanttoknow.info/buzzsaw10pg>
<www.tompaine.com/articles/kerry_won_.php>
<http://207.44.245.159/article7217.htm>
<http://www.cooperativeresearch.org/project.jsp?project=911_project>

___________________________________________

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...