Searching \ for '[PIC] Remove IC markings' 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'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Remove IC markings'
2004\11\05@062924 by Mohit Mahajan

flavicon
face
As a first line of defence against code copying, I'd like to remove the
markings on ICs; logo, number, etc. Can anybody suggest a chemical that
can dissolve the printing and not damage the IC package?

I've seen people use nail-polish to cover the markings.

Thanks,
Mohit.

> {Original Message removed}

2004\11\05@064440 by Jan-Erik Soderholm

face picon face
Mohit Mahajan wrote :

> As a first line of defence against code copying, I'd like to
> remove the markings on ICs; logo, number, etc.

Anyone with a clue, could probably find out the type
of chip anyway.

> Can
> anybody suggest a chemical that can dissolve the
> printing and not damage the IC package?

I *think* that some (Microchip) uses laser based "printing"
today. Can't be just dissolved. It must be grinded off.

> I've seen people use nail-polish to cover the markings.

And I've seen my wife use nail-polish remover.
Never tried it myself (and *if* I'd had, I would not say so
here anyway... :-) ), but it seems to work just OK... :-) :-)

Regards,
Jan-Erik.
PS.
Why was the whole post from Bob Ammerman included ?

____________________________________________

2004\11\05@070002 by Lee Jones

flavicon
face
>> As a first line of defence against code copying, I'd like to
>> remove the markings on ICs; logo, number, etc.

> Anyone with a clue, could probably find out the type
> of chip anyway.

>> Can anybody suggest a chemical that can dissolve the
>> printing and not damage the IC package?

> I *think* that some (Microchip) uses laser based "printing"
> today. Can't be just dissolved. It must be grinded off.

I think that sanding or grinding would frequently be necessary to
remove most modern markings.

>> I've seen people use nail-polish to cover the markings.

You can easily scrape off nail polish without damaging the
underlying surface.

> And I've seen my wife use nail-polish remover.  Never tried it
> myself (and *if* I'd had, I would not say so here anyway... :-) )

I'll admit I've used it -- what alternative do you use to un-bond
your fingertips after you used too much super glue (cyanoacrylate
adhesive) and it cured while you held that random assembly together ...
Or do you want to be permanently one with your work? :-)

                                               Lee Jones

____________________________________________

2004\11\05@071741 by Mohit Mahajan

flavicon
face
> Anyone with a clue, could probably find out the type
> of chip anyway.
Like I wrote "As a first line of defence". Will take him some time to,
nevertheless.

> Why was the whole post from Bob Ammerman included ?
Sorry. Just replied to a post from PICList to get the id and [PIC] tag
there. Forgot to remove the post, although I DID change the subject. :-)
My mistake.

Mohit.

> {Original Message removed}

2004\11\05@075459 by olin_piclist

face picon face
Mohit Mahajan wrote:
> As a first line of defence against code copying, I'd like to remove the
> markings on ICs; logo, number, etc. Can anybody suggest a chemical that
> can dissolve the printing and not damage the IC package?

Sand paper?

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

2004\11\05@102842 by Herbert Graf

flavicon
face
On Fri, 2004-11-05 at 07:11, Mohit Mahajan wrote:
> > Anyone with a clue, could probably find out the type
> > of chip anyway.
> Like I wrote "As a first line of defence". Will take him some time to,
> nevertheless.

Sorry, no. Unless you're using a REALLY obscure chip a trained eye would
have a good idea of what part it is within about 5 seconds. I personally
wouldn't even bother, in fact, a chip with it's markings removed would
probably cause someone to try HARDER to copy your chip, since anything
hidden automatically "activates" certain people.

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

____________________________________________

2004\11\05@104049 by Support - KF4HAZ

flavicon
face
Sand paper is what we use here on boards that have many ICs,
we remove the part# from op-amps even,
then stamp new numbers on to further confound our competition.
Everytime we develop a new product our competitors order one or two,
we sell to them, so far they have not been able to go into competition with us.
Possible reasons could be In-house part#s, and code protection on the microcontrollers.
As a service tech I hate in-house part#s because it makes diagnostics and repair difficult,
but as the guy who spent a month or more R&D on a new product I would rather they just let us handle the repairs.
Besides we give a good warranty, if it proves to be something quick and simple I repair it,
something major we simply send them a new unit.

KF4HAZ - Lonnie

----- From: "Olin Lathrop" <olin_piclist@
{Quote hidden}

____________________________________________

2004\11\05@112553 by Bob Axtell

face picon face
We use a rotating drafting erasing tool with a rough eraser rod. It
"erases" the
top layer of plastic. Sandpaper works well, too, of course. MEK will
dissolve
the plastic, but might not stop in time- and may soften the interface
between the pins
and the case.

But any engineer familiar with PICs will eventually determine what it
is, even if it can't
read the array.

I'm intrigued by protecting against code copying by clipping the MCLR\
or PGD pin.
Anybody done that sucessfully? It seems after the bootloader has been
debugged that
changes can be made without reprogrammed.

--Bob

Olin Lathrop wrote:

{Quote hidden}

>_____________________________________________

2004\11\05@115140 by Josh Koffman

face picon face
But there is still a connection to the chip. I've seen a tutorial on
how to scrape out a little of the casing and solder on a new pin.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Fri, 05 Nov 2004 09:25:49 -0700, Bob Axtell <spam_OUTengineerTakeThisOuTspamcotse.net> wrote:
> I'm intrigued by protecting against code copying by clipping the MCLR\
> or PGD pin.
> Anybody done that sucessfully? It seems after the bootloader has been
> debugged that
> changes can be made without reprogrammed.
____________________________________________

2004\11\05@115819 by Wouter van Ooijen

face picon face
> I'm intrigued by protecting against code copying by clipping
> the MCLR\ or PGD pin.

That would neatly provide the info which pin is important for
reverse-engineering, defeating removing the marking. And what would keep
me (as reverse-engineer) from sticking a hot needle into the housing
(maybe using a little MEK), thus making contant with the remains of the
pin?

> Anybody done that sucessfully? It seems after the bootloader has been
> debugged that changes can be made without reprogrammed.

I have yet to see a bootloading scheme that isn't a reverse-engineers
friend.

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\05@121657 by Mauricio Jancic

flavicon
face
Hi,
       Talking about this. I'm intrigued on how to read the program memory
of one of the new PICs. I have here some that I can sacrifice in pro of the
knowledge. I would like to know and first hand prove that there is a risk to
overpass code protection.

       I've successfully removed the chip case (plastic) simply with a hot
air gun. So, I have the very chip there. With some microscope and VERY good
hand-pulse, you can resolder the pins and perhaps erase separately the chip
protection sector(?)

       I've not yet done the least but I guess it would be possible, are
there any know protection braking methods?

       Regards

Mauricio Jancic
Janso Desarrollos
Microchip Consultant Program Member
(54) 11-4542-3519
.....infoKILLspamspam@spam@janso.com.ar
http://www.janso.com.ar


>>{Original Message removed}

2004\11\05@122459 by Dwayne Reid

flavicon
face
At 04:22 AM 11/5/2004, Mohit Mahajan wrote:
>As a first line of defence against code copying, I'd like to remove the
>markings on ICs; logo, number, etc. Can anybody suggest a chemical that
>can dissolve the printing and not damage the IC package?

Belt sander works well.  While this does not deter anyone for long if you
are using conventional parts in a conventional manner, it can be effective
if the parts you use are obscure and not well known.  Make sure that there
aren't any marking on the underside of the chip as well.

An interesting variant is to design the board with the chip upside down,
then bend the leads backwards.  Don't laugh too hard - I once
reverse-engineered a board that used this trick.  Its also way more
effective if you do this with only the obscure chips on the board.

dwayne

--
Dwayne Reid   <dwaynerspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 20 years of Engineering Innovation (1984 - 2004)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

____________________________________________

2004\11\05@123900 by Support - KF4HAZ

flavicon
face
How about one that must see a 128 bit number within the first 50ms following a reset
if no data run program
if correct # seen load new code
if an incorrect # sent, flip a bit in eeprom causing it to refuse to function until a different password restores the bit.
Note that the 128 bit # that restores operation is a different one than the one that causes a download of new code so any sequential automated attempt will continually fail.
Also, the line that must see the 128 bit # is being used as an input from something else, a jumper for example.
NDA footnote: The above is not exactly the method we employ, but close enough to let someone else design their own.
KF4HAZ - Lonnie

----- From: "Wouter van Ooijen" <wouter@
<snip>
> I have yet to see a bootloading scheme that isn't a reverse-engineers
> friend.
>
> 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\05@124751 by Support - KF4HAZ

flavicon
face
HEY! that was not a copy protection attempt,
I just goofed up on the PCB layout and did not catch it till we had 100,000 boards etched drilled and populated,
had to flip the chip to save my tail...

Just kidding - KF4HAZ - Lonnie

----- From: "Dwayne Reid" <dwayner@
<snip>
{Quote hidden}

____________________________________________

2004\11\05@125440 by Robert Rolf

picon face
Dwayne Reid wrote:

> At 04:22 AM 11/5/2004, Mohit Mahajan wrote:
>
>> As a first line of defence against code copying, I'd like to remove the
>> markings on ICs; logo, number, etc. Can anybody suggest a chemical that
>> can dissolve the printing and not damage the IC package?
>
>
> Belt sander works well.  While this does not deter anyone for long if
> you are using conventional parts in a conventional manner, it can be
> effective if the parts you use are obscure and not well known.  Make
> sure that there aren't any marking on the underside of the chip as well.
>
> An interesting variant is to design the board with the chip upside down,
> then bend the leads backwards.  Don't laugh too hard - I once
> reverse-engineered a board that used this trick.  Its also way more
> effective if you do this with only the obscure chips on the board.

That should have fooled you for all of 10 seconds since the
mold markings are very different for the bottom of a chip.
And they would have had a lot of fun doing that with SMT stuff.

Since most chips need Vcc and Gnd a flipped chip is
trivially easy to spot.

If you really need code security, look at the seriously secure
uP chips by Atmel.

As for bootloader vulnerability, that is only a weakness
if the cracker can eavesdrop on an upload.
If the data is encrypted, and CRC'd it is a LOT of work
to figure out what packets to send to load their dumper code.
And they stand a good chance of mangling the code in
trying to figure out the bootloader protocol.

With an exposed chip one can zap the code protect bit,
although today's chips tend to have it well protected by an
aluminum overcoat to shield if from laser zap. If the
internal address/ data bus is probable, the program can
be read out on the fly.

The satellite card hackers have had many years of experience
proving that any chip is hackable if the rewards are
worth the investment.

Robert


____________________________________________

2004\11\05@130216 by Roy E. Burrage

flavicon
face
But it has been done on purpose.  Keithley used this scheme on one of
their older portable meters...took an ICL7106 A/D converter and flipped
it over.  Their part cost 35 bucks where the standard cost about 7 at
the time.

REB

Falcon Wireless Tech Support - KF4HAZ wrote:

{Quote hidden}

____________________________________________

2004\11\05@130349 by Roy E. Burrage

flavicon
face
But it has been done on purpose.  Keithley used this scheme on one of
their older portable meters...took an ICL7106 A/D converter and flipped
it over.  Their part cost 35 bucks where the standard cost about 7 at
the time.

REB

Falcon Wireless Tech Support - KF4HAZ wrote:

{Quote hidden}

____________________________________________

2004\11\05@130834 by Bob Axtell

face picon face
How about blowing out the PGD or PGC pin somehow? Anybody done that yet? I
thought I remember a thread about this a year ago.

I have an internal firmware bootloader that  operates as part of the
normal commands of the
firmware. It uses the top half of PIC PGM memory as temp storage, then
when a special command
is given, programs the data in the upper half into the lower half. It
can't visualize how it could be
cracked unless the HOST application that has the firmware loader itself  
was cracked.

--Bob

Wouter van Ooijen wrote:

{Quote hidden}

>_____________________________________________

2004\11\05@132912 by Ken Pergola

flavicon
face

Why remove the markings?

Wouldn't it be more fun to remove the original marking, and then put totally
fake markings on it that misrepresent what the device is? :)

For example, mark a PIC with AVR markings? :)

Yes, I am *totally* jesting here -- no offense to anyone, ok?


Best regards,

Ken Pergola



____________________________________________

2004\11\05@141332 by Wouter van Ooijen

face picon face
> How about one that must see a 128 bit number within the first

Sorry, I should have been more specific: I have never seen a bootloading
scheme that can safely (= without relealing the (new) code) work in the
client's context. Whether that is still relevant to the discussion is to
be determined :)

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\05@143227 by Support - KF4HAZ

flavicon
face
See my earlier postings, we actually do stamp bogus numbers.
They have meaning to us,
and we will sell a pre-programmed PIC18G256 for example
IF their technician can convince me that is what is blown.
$85 might seem a bit expensive for one,
but the alternative is we will repair "out-of warranty" units for that same amount,
their choice, and they are not likely to find any PIC18G256 chips for less programmed or not.

KF4HAZ - Lonnie

----- From: "Ken Pergola" <no_spam@
{Quote hidden}

____________________________________________

2004\11\05@143418 by Win Wiencke

flavicon
face
> As a first line of defence against code copying, I'd like to remove the
> markings on ICs; logo, number, etc. Can anybody suggest a chemical that
> can dissolve the printing and not damage the IC package?

I've not had luck dissolving IC labels.  An electric eraser, however, worked
pretty well.

You might try a Dremel tool with a sanding disk too.

Aza D. Oberman

____________________________________________

2004\11\05@143906 by Support - KF4HAZ

flavicon
face
If the bootloader is capable of addressing bytes to change
a field update can be applied without sending the entire object code.
And of course somewhere in the process part of the 128bit # gets changed
so the password will be different for each subsequent update.

KF4HAZ - Lonnie

----- From: "Wouter van Ooijen" <wouter@

{Quote hidden}

____________________________________________

2004\11\05@144351 by Bob Ammerman

picon face
----- Original Message -----
From: "Wouter van Ooijen" <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl>
To: "'Microcontroller discussion list - Public.'" <piclistspamspam_OUTmit.edu>
Sent: Friday, November 05, 2004 2:13 PM
Subject: RE: [PIC] Remove IC markings


>> How about one that must see a 128 bit number within the first
>
> Sorry, I should have been more specific: I have never seen a bootloading
> scheme that can safely (= without relealing the (new) code) work in the
> client's context. Whether that is still relevant to the discussion is to
> be determined :)
>
> Wouter van Ooijen

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.

For a single boot load, this is 'perfect' security. It is called a 'one time
pad' and is one of the most secure ways to send data (assuming the pad
itself is physically secure).

This is still very good for multiple boot loads, although not perfect
because parts of the program that do not change from one load to another
will be constant in the various loads. You can do a little better here by
prefixing the load with an offset to be used into the random bit string
(which is considered circular in nature).

If you can't afford a full length random bit string you can do quite well
with a shorter one.

I use a scheme in one PC application where I have two truly random bit
streams with relatively prime lengths. Each byte of data is exclusive or'd
with one byte from each bit stream like this:

   decoded[offset] = stream1[offset % stream1_len] ^ stream2[offset %
stream2_len] ^ encoded[offset]


By the way, I got my truly random bits of a web site that generates them in
hardware of some sort.

Bob Ammerman
RAm Systems


____________________________________________

2004\11\05@155008 by Peter L. Peres

picon face


On Fri, 5 Nov 2004, Jan-Erik Soderholm wrote:

> Mohit Mahajan wrote :
>
>> As a first line of defence against code copying, I'd like to
>> remove the markings on ICs; logo, number, etc.
>
> Anyone with a clue, could probably find out the type
> of chip anyway.

But most locusts are clueless usually (thanks for small miracles, noe
how about a larger one ?).

A Dremel or similar tool with a rubber disk and fine abrasive paper on it
will remove most writing and symbols faster than solvent. Especially since
the latest chips use laser etched writing which is imprevious to solvents.
Using a Dremel on a SOIC chip may have undesirable results (like exposing
the top of the bonding wires. Use with caution and never on something you
cannot replace. Use at your own risk.

Peter
____________________________________________

2004\11\05@160642 by Wouter van Ooijen

face picon face
> If the bootloader is capable of addressing bytes to change
> a field update can be applied without sending the entire object code.

In most cases a new release will contain some new code, shifting a large
part of the code around. Hence this idea is not very helpfull.

> 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.

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\05@160643 by Wouter van Ooijen

face picon face
> 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. 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.

It is true that the one-time pad is totally secure, but a PIC that
applies a fixed XOR pad to the incomming message is like a crypto system
using a fixed XOR pad, while under a choosen-cryptotext attack. This is
indeed known to be very easily crackably. (The PIC is a little bit more
secure because its decoding of the message is not immedeately readble,
but enough of it can be deduced from the behaviour of the PIC).

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\05@164248 by Bob Ammerman

picon face
{Quote hidden}

Ah, but this is easily avoided: you simply include a (nice long) hash with
the program in the encoded stream and refuse to run the program unless the
hash is correct after decoding.

Also you can make these types of attacks far more time consuming by
deliberately using a relatively slow bit rate, for example.

Bob Ammerman
RAm Systems

____________________________________________

2004\11\05@172444 by M. Adam Davis

flavicon
face
Wouter van Ooijen wrote:

>In most cases a new release will contain some new code, shifting a large
>part of the code around. Hence this idea is not very helpfull.
>  
>
If you design your code carefully in the beginning as extremely modular,
and place each function with a certian amount of padding afterwards (or
use a function table) then it's very easy to supply tiny updates.

If you use the function table, then you can write new functions in empty
spots and then change the function table only when the crc is shown to
be correct.  Further, partial updates can be recovered from if
interrupted since the old code is never overwritten, and the tables
aren't changed until the new code is completely and correctly loaded.  
One might consider also running a checksum at bootup to determine if the
new code is valid to prevent further possible attacks - revert to an
older valid code if the new code doesn't pass.  If no code passes,
display an error message and wait for reprogramming.

It does involve more work in developing a complex toolchain, but once
the initial work is done the rest is normal pic development.

-Adam
____________________________________________

2004\11\05@172648 by M. Adam Davis

flavicon
face
And when your company and all documentation is gone and lost, people
trying to maintain this equipment will swear at you daily.  :-)

-Adam

Falcon Wireless Tech Support - KF4HAZ wrote:

{Quote hidden}

>_____________________________________________

2004\11\05@181019 by Support - KF4HAZ

flavicon
face
But it is still working for us with Sandia Labs & Los Alamos Labs,
They tried to crack it, ordered a new chip, I told them I would send the new one as soon as they sent back the one they said had exploded, they said "never mind" then offered to buy the source code.
My response (as this was for homeland security) was pay off my mortgage and throw in something for the boss and it is yours.
They must not have cracked the security yet as they continue to place orders from us.
The bogus part# mentioned in my earlier post most of you could have figured out at least 2/3rds of  18 means 18pin device G means Government product, the rest I cannot disclose.
as for shifting around major blocks of code, this is not as difficult as it seems, think it through, the bootloader is addressable, if you know what is where you could re-write 99% of the code without exposing what the new code was and without the other 1% the object code would still be useless even if you could separate addresses from codebytes.

KF4HAZ - Lonnie

----- From: "Wouter van Ooijen" <wouter@

{Quote hidden}

____________________________________________

2004\11\05@205610 by SM Ling

picon face
Even worst when the protected failed device is just a sub-component of a
very expensive installed system.  Cost: projects, testings, integrations,
installations, verifications,  social, etc.  Personally, I am biasing
towards tools that are open-source if I have become used to it I do not want
to dance to the tune of OEM "obselence" plan.

Ling SM

{Quote hidden}

same amount,
> >their choice, and they are not likely to find any PIC18G256 chips for
less programmed or not.

____________________________________________

2004\11\06@025431 by Wouter van Ooijen

face picon face
> If you design your code carefully in the beginning as
> extremely modular,
> and place each function with a certian amount of padding
> afterwards (or
> use a function table) then it's very easy to supply tiny updates.

When the changes are tiny. What is the required change is big?

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\07@075145 by hilip Stortz

picon face
while nail polish will work, i'd suggest a colored epoxy.  nail polish
is easy to remove, anything that will dissolve the epoxy will likely
take the ic package with it.  many of the markings are lasered into the
ic package so they won't be removable with a solvent, about all you can
do is put some kind of adhesive/paint over them.  it might still be
possible to remove the epoxy if heated but i'd think the case would
soften at about the same point and that it would be hard to separate the
layers to get something readable, and it's not something most people
would do.  alternatively you could carefully sand them off (depending on
how thick the chip is, some packages are already very thin and there's
not much between the die and the outside, if you expose any of the die
or make the coating too thin moisture etc. will get in and eventually
destroy the chip).  of course with a suitable laser you could scan
across the whole surface but that would be rather extreme and expensive.

Mohit Mahajan wrote:
>
> As a first line of defence against code copying, I'd like to remove the
> markings on ICs; logo, number, etc. Can anybody suggest a chemical that
> can dissolve the printing and not damage the IC package?
>
> I've seen people use nail-polish to cover the markings.
-------

--
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@075148 by hilip Stortz

picon face
very true.  and frankly, most of what people consider "proprietary" is
easier to redesign from scratch than to reverse engineer in the first
place.  unless there are hundreds of hours of work involved or something
that really is extremely clever (and many things that seem very clever
have been done before but you've just re-invented them, it happens all
the time).  however i doubt you can identify a de-marked chip rapidly,
most of them from the same manufacturer look identical as far as i can
tell.  on the other hand there are simple electrical test that can help
identify things pretty rapidly if you have some idea.  it's really the
code you want to protect, and de-marking the chip isn't going to provide
much additional security to whatever the chip maker has done to secure
your' code (which again may not be that hard to duplicate functionally).
i don't want to insult any one, but honestly most of the things i've
seen people go to great lengths to protect with these tricks are not as
clever or hard to reinvent as they seem to think they are, at least not
for any one who's designed a lot of stuff before and knows that
particular field of application at all or bothers to spend a little time
learning about it.  it's nice to make someone go to the work of
reinventing it rather than stealing it, but you have to decide how much
work you are willing and need to do (from an economic stand point) to
protect it.  potting the whole thing in epoxy is probably more worth
while if you are really worried about it.  i confess i'll be epoxy
coating the chips on one of my projects, but only to prevent very, very
casual duplication of something that's cheap any way.

Herbert Graf wrote:
------
> Sorry, no. Unless you're using a REALLY obscure chip a trained eye would
> have a good idea of what part it is within about 5 seconds. I personally
> wouldn't even bother, in fact, a chip with it's markings removed would
> probably cause someone to try HARDER to copy your chip, since anything
> hidden automatically "activates" certain people.
-----

--
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@075151 by hilip Stortz

picon face
while that would make it inconvenient, it wouldn't make it that much
harder.  all one would have to do is conductive epoxy a wire on the
exposed metal end, and if you epoxied over the stub they could sill just
carefully grind down to expose the end of the stub again with a dremel
etc.  

people have gone so far before as to remove the top of the package and
use a laser to clear the memory protect bit (with a little practice on a
chip of the same type, which is pretty easy to verify visually once the
die is exposed you can find the right area of the chip by trial and
error, it's expensive and time consuming but it has been done.  there
are even development tools now that let you measure the charge/voltage
on parts of the chip without contact and do molecular beam epitaxy right
on the spot.  

if someone really wants to spend the money and has the tools, or hires a
company that does there's not much you can protect ultimately).  i've
seen reports of the laser method.  it takes skill and determination but
it is possible, and there are other variations as well.  

seriously, current technology can detect substances at the part per
trillion level, you really think you can keep someone from reading your'
code if they put the time, energy, and $$ into it?  

like any security all you can do is make it more expensive than it's
worth to steal the data, and there are very real limits to how secure it
can be even if it's worth a lot.  the only thing that's hard to copy are
the really subtle and clever tricks that are overlooked even when
exposed, if the potential cloner is clever enough.  that's the good
news, most people aren't clever or determined enough and will rarely pay
one of the reverse engineering companies to do it since they charge an
arm and a leg for their expertise (and facilities).

it's all spy vs. spy, just like cryptography, given the motivation most
things can be brute forced, eventually.  and just like cryptography a
small mistake in the implementation can ruin an otherwise well secured
system, and this happens all the time in commercial products.

better to just come up with a really good design, and protect it well
enough that you'll have the improved version for sale before most people
can reverse engineer the last version.  you just want to slow down their
time to market for a clone enough that it isn't worth while to clone it
and waste their resources when they should be just reinventing it, and
hiring more/better engineers if necessary.  not that there aren't great
games you can play with the less clever competitors to really make them
waste time, like the mis-marking of chips, that will confuse the amateur
no end.

Bob Axtell wrote:
------->
> I'm intrigued by protecting against code copying by clipping the MCLR\
> or PGD pin.
> Anybody done that sucessfully? It seems after the bootloader has been
> debugged that
> changes can be made without reprogrammed.
-------

--
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@075154 by hilip Stortz

picon face
you just need a good microscope and positioner to do that, off the shelf
stuff that you can probably even find surplus, or build yourself.  there
are also other games to try that often work, if you can write any new
code you write a short monitor program and fill the rest of what you
think is empty space with jump instructions to your code dumping
routine, then all you have to do is disturb the program counter enough
that it winds up pointing to one of your jump instructions and boom,
it's running your' code dumping routine!  the pc can often be disturbed
by voltage transients on the power supply, heat, etc.  this is similar
to how people hack systems by overflowing stacks and heaps.  other
things to try are slightly too high a voltage for the power supply,
slightly too low, and of course various power glitches.  read the
disclaimer about the chips security, they already know there are
definitely ways to defeat it if someone knows what they are doing, or
bothers to do some web searching etc.  it's all about being a little
creative and not thinking about the "normal" in spec things to do.

Mauricio Jancic wrote:
{Quote hidden}

-------

--
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@075156 by hilip Stortz

picon face
in which case you need time and a good dso with enough channels.  once
you are playing you find what keeps it from working, and then you worry
about observing that part when it does work.  it's not trivial, but it's possible.

Falcon Wireless Tech Support - KF4HAZ wrote:
>
> How about one that must see a 128 bit number within the first 50ms following a reset
> if no data run program
> if correct # seen load new code
> if an incorrect # sent, flip a bit in eeprom causing it to refuse to function until a different password restores the bit.
-------

--
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@075159 by hilip Stortz

picon face
it's difficult to trust the reliability of the rest of the chip if you
do that.  it's nearly impossible to damage one part without some damage
to the rest of the chip i'd think, even if you blow the bond wire like a
fuse the current has to be going through another pin(s) as well, and a
high voltage would definitely be hard to contain.

Bob Axtell wrote:
>
> How about blowing out the PGD or PGC pin somehow? Anybody done that yet? I
> thought I remember a thread about this a year ago.
-----

--
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@075201 by hilip Stortz

picon face
and the data sheets and application notes for such products suggest many
methods of cracking lesser chips.  the extreme measures taken on some
"secure" microcontrollers are really impressive, but remember that part
of any good security system is psychology, if you make the data sheet
long enough and go into enough detail about what doesn't work someone
who's not experienced will tend to get mind freeze and have trouble
coming up with other creative abuses of the chip in question.

Robert Rolf wrote:
-----
> If you really need code security, look at the seriously secure
> uP chips by Atmel.
------

--
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@075204 by hilip Stortz

picon face
exactly, anything that someone has physical access to can be cracked,
particularly if they can try it on several units.  and it's rarely worth
while to put it in a box with a self destruct!  it makes debugging and
repair a real nightmare, not that some military/inteligence chips don't
have that "feature", but it cost a lot in all kinds of ways (for
instance the first time the software crashes it may self destruct, which
makes debugging very hard when the user has to remember exactly how they
broke it before you can fix that bug that just melted the chip...).  

i remember in the 80's a scheme for rom chips where they new which
addresses could come before which other addresses, i.e. you couldn't
just increment through all of the addresses to read the rom, of course
all you had to do was monitor the rom and run through all of the
routines, or most of them to defeat that silliness (and it took about
1/2 second for me to know that the first time i read about it!).  i've
never heard of them being used or of them at all since.  another silly
thing someone that added security that mostly added trouble.

Wouter van Ooijen wrote:
>
> > How about one that must see a 128 bit number within the first
>
> Sorry, I should have been more specific: I have never seen a bootloading
> scheme that can safely (= without relealing the (new) code) work in the
> client's context. Whether that is still relevant to the discussion is to
> be determined :)
-----

--
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@075207 by hilip Stortz

picon face
then it takes a lot longer, and it's time to use another attack at the
same time.  again, there is gear that can detect the surface charges on
an operating chip with enough resolution to see any signal on the
surface or not blocked by metalization, and lets you do molecular beam
epitaxy as well to modify chips, it's meant for development use on
asics, but the reverse engineering possibilities are huge.  potentially,
you could strip off layers of the chip and read the rom directly!  it's
just not worth while most of the time, for most people.  and of course
with non-disclosure/non-cracking agreements it's not popular in legal
circles and a lawsuit and injunction can get expensive very quickly for
the defendant without too much cost on the part of the "victim"...

Falcon Wireless Tech Support - KF4HAZ wrote:
>
> If the bootloader is capable of addressing bytes to change
> a field update can be applied without sending the entire object code.
> And of course somewhere in the process part of the 128bit # gets changed
> so the password will be different for each subsequent update.
-----
> http://mailman.mit.edu/mailman/listinfo/piclist

--
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@114503 by Herbert Graf

flavicon
face
On Sun, 2004-11-07 at 06:10, Philip Stortz wrote:
> very true.  and frankly, most of what people consider "proprietary" is
> easier to redesign from scratch than to reverse engineer in the first
> place.  unless there are hundreds of hours of work involved or something
> that really is extremely clever (and many things that seem very clever
> have been done before but you've just re-invented them, it happens all
> the time).  however i doubt you can identify a de-marked chip rapidly,
> most of them from the same manufacturer look identical as far as i can
> tell.  

Which right there is a giveaway. Most manu's parts tend to look the
same, so picking out the manu is generally easy for common parts. Then a
quick check of Vdd, Vss and where the crystal attaches, along with the
number of pins would lead a trained eye to within a small handful of
part numbers. That's what I meant. While I'm certainly no expert there
are people out there that are.

> protect it.  potting the whole thing in epoxy is probably more worth
> while if you are really worried about it.  i confess i'll be epoxy
> coating the chips on one of my projects, but only to prevent very, very
> casual duplication of something that's cheap any way.

Agreed, the potting in epoxy method is probably the best way to go.
While certainly nowhere near secure, the amount of effort needed to get
at the parts is probably what most people are aiming for from a security
point of view.

Remember, there is no such thing as absolutely secure. Talk to the
satellite TV people about that... :( TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

____________________________________________

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

picon face

On Fri, 5 Nov 2004, Wouter van Ooijen wrote:

>> If the bootloader is capable of addressing bytes to change
>> a field update can be applied without sending the entire object code.
>
> In most cases a new release will contain some new code, shifting a large
> part of the code around. Hence this idea is not very helpfull.
>
>> 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.

Not really. It can be chosen as a part of a challenge/response dialog
between programmer and target at runtime. What should be done (I have not
used this so far) is to limit the number of attempts available. Say 100
firmware upgrades, then it's goodnight. That lowers the chances of
stumbling on the right answer.

Peter
____________________________________________

2004\11\08@002514 by Chen Xiao Fan

face
flavicon
face
It seems that lots of the people here are proud of their code and
try to prevent others from reverse engineering the program.

Seriously, is it worth the effort? How many people really reverse
engineering the MCU code, especially those below 8k word which most
of the PICs have?

So maybe just simply code protect your MCU, remove the IC markings,
potting the device (or a drop of Loctite) will deter most of the
competitors from peeking through your code. Or you can put some
extra stuff to just fool them if you can afford the cost.

Xiaofan
____________________________________________

2004\11\08@005559 by Bob Axtell

face picon face
That's a good observation.

Reverse engineering a competitor's product to steal it is rarely done by
a competent
engineer. Most engineers on this list won't do it, because it is
basically unethical. I have
only reverse-engineered products twice... (1) when asked to determine
the cause of a failure
by the copyright-owner's insurance company (with owner's blessing, but
poor documentation
forced the job); and (2) when the copyright-owner company went out of
business and was
unable to be located, and the client provided proof that he'd made an
exhaustive search, and
the irreplaceable PCB was causing his company to lose money. I have
refused to reverse-engineer
at least 15 times over the years. Usually I can convert that effort into
a REAL design job.

The problem is that your client will put pressure on you to do this
anyway; it happens every
time. What I do is to scratch the IC markings off,  blow the security
bit, and hope for the
best.  _I_ know that a determined effort can uncover the data, but I
also know that it would
be cheaper to hire a competent engineer to design it from scratch.

--Bob


Chen Xiao Fan wrote:

{Quote hidden}

>_____________________________________________

2004\11\08@010404 by Jinx

face picon face

> It seems that lots of the people here are proud of their code and
> try to prevent others from reverse engineering the program.
>
> Seriously, is it worth the effort? How many people really reverse
> engineering the MCU code, especially those below 8k word which
> most of the PICs have?

Obviously you can't stop somebody copying the functions that
a circuit performs, but you can at least not give them code on a
plate. I've a couple of projects going on that are worth a lot of
money in the market-place and I'd be seriously pissed off if they
were broken into. Both of them have meant considerable time
and effort developing. One would be reasonably straight-forward
to functionally copy (possibly the more valuable of the two but
it's a niche market). The other is based around an OS that has
been tweaked over time - not one I would like to start from
scratch and I'd like to ensure that if anyone wants to do something
similar they'll have to write their own


____________________________________________

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

face picon face
>As a first line of defence against code copying, I'd like
>to remove the markings on ICs; logo, number, etc. Can
>anybody suggest a chemical that can dissolve the printing
>and not damage the IC package?

The other part that people forget to do is remove the part number that
sometimes exists on the bottom of the chip. I have an HP plotter that no-one
wanted as it had died, and HP wanted an arm and a leg to repair it. There
was another identical plotter around and someone swapped chips between the
two until they identified the faulty chip. The plotter eventually fell into
my "rubbish bin" as no-one wanted it, and I removed the chip, looked on the
bottom, and found 6805 stamped there. Sure enough, changing the chip for a
6805 micro out of some other equipment in the workshop ensured a working
plotter again.

>An interesting variant is to design the board with the chip
>upside down, then bend the leads backwards.  Don't laugh
>too hard - I once reverse-engineered a board that used this
>trick.  Its also way more effective if you do this with only
>the obscure chips on the board.

It is also a trick fraught with other potential problems. A colleague had
dealings with doing this as a PCB had been designed back to front because
someone forgot the pinout was viewed from the top of the chip, and not the
bottom. They fitted chips by reverse bending the leads, but they would fail
regularly. eventually he came up with some arrangement that meant the chips
did not need the leads reverse bent (IIRC it was not possible to just mount
the chip on the other side of the PCB) and the failures stopped. He surmised
that the action of reverse bending the leads damaged the seal between the
leads and the body, allowing ingress of moisture (it was a sub tropical
environment) leading to eventual failure of the chip.

____________________________________________

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

face picon face
>>In most cases a new release will contain some new code,
>>shifting a large part of the code around. Hence this
>>idea is not very helpfull.
>
>
>If you design your code carefully in the beginning as
>extremely modular, and place each function with a certian
>amount of padding afterwards (or use a function table)
>then it's very easy to supply tiny updates.

The way the Microchip linker seems to spray code around the address space at
times, I'm not sure you need much padding.

____________________________________________

2004\11\08@060804 by Joe McCauley

picon face
If I remember correctly the old Kiethley 169 DMM used this trick for
conversion. The chip looked like a custom part & was expensive. Looking at
the schematic one day it struck me that it looked very like some other
circuits I had looked at in the recent past. Sure enough the main converter
turned out to be a very common (and cheap) DMM part turned upside down. I'm
sure the engineers at Keithley did not employ someone to bend the pins on
each DMM they shipped :) These parts were probably ordered that way from the
manufacturer and likely were to a higher spec than the regular parts. I
suspect that the main reason they were flipped was to try to ensure that
cheaper and possibly less accurate parts were not used in their products.

In our case the DMMs were used in undergraduate teaching in very undemanding
situations, so I was happy enough to use the cheaper devices in them,
particularly as some students seemed to be making a career of blowing them.

The moral of the story: Don't rely on this trick to fool anyone but the most
inexperienced of engineers. (those are the people you probably don't have to
worry about anyhow) It is probably not a great idea to stress the component
leads in this way as well.

One of the best lines of defense is to encapsulate using a delicate circiut
construction. That way the reverse engineer will most likely wreck the
circuit taking it apart. At least if they finally succeed, they will have to
have bought a few.... A useful variation of this (though labour intensive)
is to leave out a few PCB traces and make the connections using the type of
wire used for wire wrapping. (remember that anyone?) These connections
should form loops which end up embedded in the encapsulant. Taking apart the
package usually destroys these connections. If you use the same colour of
wire for all connections it will add to the confusion.

Of course anyone with access to an x-ray machine will be able to figure this
out too, but if someone wants to rip you off that badly, then you're in
trouble no matter what you do......


Joe



{Original Message removed}

2004\11\08@113853 by hilip Stortz

picon face
an even more clever variant just occurred to me.  use conductive epoxy
to make some of the connections!  these will be dissolved along with the
encapsulating epoxy.  the conductive epoxy could form some of the
traces, be used to attach some of the chips (meaning they'd be loose
when the epoxy dissolved/softened) and to connect the previously
suggested wire wrap (or small magnet wire) connections.  using some
conductive epoxy with epoxy potting would make it very, very hard to
brute force reverse engineer.  though as noted, most applications are
fairly simple to design from scratch to a good engineer, it's only worth
so much effort to block the casual and clumsy cloner.

as far as reverse engineering, there are several variations.  outright
copying of a product is (rightfully i believe) wrong to many engineers.  

however, some reverse engineering is often required to add functionality
or interface to other products, this is completely ok.  i had to add
controls and some computer monitorable outputs to a stabilized laser,
fortunately the schematic was available as was the theory of operation
(it was clever, but i could do it from scratch from memory, nothing
"fancy").  the main job was figuring out how to modify the stock circuit
board.  some traces were cut, some holes were drilled to connect extra
wires, no big deal.  a year later i wound up completely redesigning the
electronics and the case for the original manufacturer, largely because
they new of our prior additions and enhancements to their unit.  of
course the redesigned unit had the computer monitoring and control
additions built in.  the original seller wound up with a much better
design (the original was very poorly executed, a variable inductor to
tune out a noise signal from the hv power supply didn't have enough
range, we replaced it with one which did.  there were also things like
using a green wire for the hot lead to a power transformer, mounted
sideways so that the bare hot leads were 1/4" from the bottom of the
case, creating a nice shock hazard and other just careless things).

this is the difference between hacking (in general) and cracking
(hacking specifically aimed at circumventing access and control
restrictions placed by the owner to protect property) as well.  i've no
problem with hacking, cracking however is violating someone's trust and
ethics at the least and possibly the law.  what bothers me is the move
to make hacking in general illegal in many areas where frankly i believe
people should be allowed to enhance performance when they aren't
stealing anything.  for instance, our satellite receiver has terrible,
terrible software, i'd love to be able to change just the menus, but the
satellite provider would not like me to even open the case due to their
paranoia and absurd desire for "absolute" security, which they can't
have which makes them paranoid about things that pose no real threat to
their profits and might even increase them.  the same goes for the dvd
clowns in holey wood.  i've learned a great deal by "tinkering" with
commercial systems and equipment like video games etc., it is a very
good way to learn a lot of very practical things quickly and harms no
one, yet many think that as soon as you remove the screws from some
boxes you are doing something wrong, balloony.

Joe McCauley wrote:
-----
ads in this way as well.
>
> One of the best lines of defense is to encapsulate using a delicate circiut
> construction. That way the reverse engineer will most likely wreck the
> circuit taking it apart. At least if they finally succeed, they will have to
> have bought a few.... A useful variation of this (though labour intensive)
> is to leave out a few PCB traces and make the connections using the type of
> wire used for wire wrapping. (remember that anyone?) These connections
> should form loops which end up embedded in the encapsulant. Taking apart the
> package usually destroys these connections. If you use the same colour of
> wire for all connections it will add to the confusion.
-------
____________________________________________

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

picon face

On Mon, 8 Nov 2004, Alan B. Pearce wrote:

> It is also a trick fraught with other potential problems. A colleague had
> dealings with doing this as a PCB had been designed back to front because
> someone forgot the pinout was viewed from the top of the chip, and not the
> bottom. They fitted chips by reverse bending the leads, but they would fail
> regularly. eventually he came up with some arrangement that meant the chips
> did not need the leads reverse bent (IIRC it was not possible to just mount
> the chip on the other side of the PCB) and the failures stopped. He surmised
> that the action of reverse bending the leads damaged the seal between the
> leads and the body, allowing ingress of moisture (it was a sub tropical
> environment) leading to eventual failure of the chip.

You'd be surprised how many circuits work fine while immersed in a mug of
tap water. Including exposed ICs (as in, metal can sawed off). This is
actually a test that someone I used to know administered to his designs.
If the circuit did not work u/w he improved it until it did. This included
conformal laquer in some areas and changing circuit values and more.
Obviously nothing very sensitive. Bending the leads the wrong way likely
caused stress on the internal lead frame and that sheared the bonding wire
off some pin(s) either immediately or while thermal cycling or vibrating
in use (the lead end of the bonding wire is in the epoxy with or without a
separator). Humidity is a very unlikely cause for failures of this kind
imho.

Peter
____________________________________________

2004\11\10@030957 by hilip Stortz

picon face
it could have been from those sources (very likely) but it could also
have been due to long term moisture ingress.  while chips are passivated
and might work for some time under water, that doesn't mean that they
will work that way long term.  i worked at a company where we had some
linear photo diodes without the caps on them (because they were going
into a vacuum chamber, and we wanted to eliminate the potential virtual
leak).  this worked fine, until we had some stored for about a year,
they still seemed to work all right, but crystals of dopant or something
else clearly formed in a few places along it's length.  this did not
show up for some time, and while they worked at the time i'm sure that
storage for several more years or in a damper climate would have
noticeably damaged them.  the solution of course was to store them in a
dessicator (just a sealed box with some desiccant and an indicator card,
and labeling telling the inventory people to get me when they needed to
inventory the contents).  
it is very common for a system to put up with a particular type of abuse
short term but be intolerant to it longer term.  what works in coffee
for several minutes or hours will not necessarily tolerate coffee for
years.  moisture inside a chip package can very easily allow the dopants
to move about and possible corrode metallic layers, but it may take some
time and just as in the case of mild static damage may at first show up
as just a slight change in performance which may go unnoticed in many
designs until further degradation occurs due to the original abuse. even short term testing at "high" levels isn't always a good predictor
of what will happen long term at lower levels.  this is a common flaw in
many test methods that should be kept in mind.  arithmetic equality does
not necessarily imply functional equality.

"Peter L. Peres" wrote:
------
environment) leading to eventual failure of the chip.
{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>

___________________________________________

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