Searching \ for '[PIC:] Disassemblers' 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: 'Disassemblers'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Disassemblers'
2004\01\28@045733 by Alan B. Pearce

face picon face
>> Does anyone remember the tool that would take a PIC hex file and
>> produce ASM from it?
>
>    MPLAB will disassemble the code for you, but won't replace
>    numbers with symbols; I don't know of a PIC disassembler that
>    will do that.  However, the tedious process of MANUALLY labeling
>    addresses and constants seems -- in my experience -- to be a
>    critical element in the success of any reverse-engineering
>    effort.

I have a disassembler written in VB3 which will do that. It was originally
written by someone else for a 16F84, and I expanded it to cover the 16F87x
series. It identifies the destination register and bits by name, and gives
all possible definitions for a given address, depending what bank it may be
in. It is then up to the operator to select the correct one by inspection,
as the disassembler does not keep track of the actual bank settings.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\01\28@045733 by Alan B. Pearce

face picon face
>> Does anyone remember the tool that would take a PIC hex file and
>> produce ASM from it?
>
>    MPLAB will disassemble the code for you, but won't replace
>    numbers with symbols; I don't know of a PIC disassembler that
>    will do that.  However, the tedious process of MANUALLY labeling
>    addresses and constants seems -- in my experience -- to be a
>    critical element in the success of any reverse-engineering
>    effort.

I have a disassembler written in VB3 which will do that. It was originally
written by someone else for a 16F84, and I expanded it to cover the 16F87x
series. It identifies the destination register and bits by name, and gives
all possible definitions for a given address, depending what bank it may be
in. It is then up to the operator to select the correct one by inspection,
as the disassembler does not keep track of the actual bank settings.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@172523 by Liam O'Hagan

flavicon
face
Well that message lost its subject line somewhere along the way...

The reason I ask, is that we (as a 3rd party) test certain devices which
handle large quantities of money, and someone has recently discovered a way
to remove more money from these devices that he or she is entitled to...

This has generated quite a bit of interest and investigation, and along the
way we noted that the binary image on the Z86 micro installed in these
devices was different to that which was meant to be there, possibly
facilitating this unauthorised cash removal. As such we needed to find out
what the binary did that the official binary didn't. Hence the need for a
disassembler...

I have a working one now, and I'm trying to deduce what the code is doing.

Sorry to be so roundabout in my description, by necessity there are a lot of
security concerns with an issue like this.

> {Original Message removed}

2004\01\28@184527 by Olin Lathrop

face picon face
Liam O'Hagan wrote:
> The reason I ask, is that we (as a 3rd party) test certain devices
> which handle large quantities of money, and someone has recently
> discovered a way to remove more money from these devices that he or
> she is entitled to...

Don't be so modest.  That was a pretty clever back door you put in.  So how
do we cash in before you fix it?  It's OK, just us PIClisters here, you can
tell us.


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

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts29-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spam_OUT20040130080757.CRTU19788.tomts29-srv.bellnexxia.netTakeThisOuTspammitvma.mit.edu>>          for <.....piclist_errorsKILLspamspam@spam@SYMPATICO.CA>;
         Fri, 30 Jan 2004 03:07:57 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8261 ; Fri, 30 Jan 2004 03:07:53 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9757; Fri, 30 Jan 2004 03:07:54 -0500
Date:         Fri, 30 Jan 2004 03:07:54 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <LISTSERVspamKILLspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           .....listsjoshKILLspamspam.....3MTMP.COM,
             "For EraseMEBlackholeeclipsespam_OUTspamTakeThisOuTEarthlink.Net" <piclist_errorsspamspam_OUTSYMPATICO.CA>
Message-ID:   <LISTSERV%@spam@2004013003075353KILLspamspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'KILLspamowner-piclistKILLspamspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9755; Fri, 30 Jan 2004 03:07:54 -0500
Received: from mta118.mail.ukl.yahoo.com [217.12.11.55] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 03:07:53 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta118.mail.ukl.yahoo.com
From: RemoveMEMAILER-DAEMONTakeThisOuTspamyahoo.co.uk
To: spamBeGoneowner-piclistspamBeGonespammitvma.mit.edu
X-Loop: TakeThisOuTMAILER-DAEMONEraseMEspamspam_OUTyahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<RemoveMEviniciusbhspamTakeThisOuTyahoo.co.uk>:
Sorry, your message to viniciusbhEraseMEspam.....yahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <EraseMEowner-piclistspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta118.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 08:07:55 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <RemoveME23.00CC3AC7EraseMEspamEraseMEcherry.ease.lsoft.com>; Thu, 29 Jan 2004 18:59:22 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 5540 for RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU; Thu, 29 Jan 2004
         18:59:15 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 8949; Thu, 29 Jan 2004 18:59:03 -0500
Received: from mta02-srv.alltel.net [166.102.165.144] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Thu, 29 Jan 2004 18:59:02 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta02-srv.alltel.net
Received: from L1.cedar.net ([162.40.230.163]) by mta02-srv.alltel.net with
         ESMTP id <RemoveME20040129235905.SDKV319.mta02-srv.alltel.netTakeThisOuTspamspamL1.cedar.net>>          for <EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU>; Thu, 29 Jan 2004 17:59:05 -0600
X-Sender: RemoveMEdvanhornKILLspamspammail.cedar.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <5.2.0.9.2.20040129185422.01580470STOPspamspamspam_OUTmail.cedar.net>> Date:         Thu, 29 Jan 2004 18:56:07 -0500
Reply-To:     pic microcontroller discussion list <
spamBeGonePICLISTSTOPspamspamEraseMEMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU>
From:         Dave VanHorn <EraseMEdvanhornspamEraseMECEDAR.NET>
Subject: Re: [PIC:] Disassemblers
To:           @spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU
In-Reply-To:  <spamBeGone2193429B07D9914D97216EBBAA6AB8BD1A053AspamKILLspamwhitlam.corp.gli.co m.au>
Precedence: list

At 10:17 AM 1/30/2004 +1100, Liam O'Hagan wrote:
>Hit send a bit soon whoops!
>
>What I meant to say is that the disassembly appears a bit buggered, some of
>the mnemoncs are meant to have 2 operands and they only have one for
>instance.

In Z-80 code and other families with multi-length instructions, one can put
things in specifically to hose disassemblers.
At verifone, we had a number of those tricks, and an ascii string in the
rom that said, "Nosy little Fucxer aren't you", more or less.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.
*** MESSAGE TRUNCATED ***


..
.

2004\01\28@185532 by Liam O'Hagan

flavicon
face
Funnily enough, the person that is removing this money originally worked for
the company that prodices these devices...

Now I have to go through and find whatever is hidden in the code, without
the source, and without knowing specific details of how the person is
getting this money :( fun times ahead!

> {Original Message removed}

2004\01\28@191647 by John Plocher

picon face
Liam O'Hagan wrote:

> Now I have to go through and find whatever is hidden in the code, without
> the source, and without knowing specific details of how the person is
> getting this money :( fun times ahead!

Assuming you have both the "original" and the "buggered"
bits, you should be able to semi-mechanically identify
the differences, or at least the "mostly common" sections.

On the assumption that the buggered chip "works" in the field
for the rest of the users, most of the original routines must
still be there in some form, simply because the original work
it was designed to do still needs to be done.

Doing this at a course level (ignoring goto/call addresses,
absolute values of register locations... - if this were a
high level language I'd call it "the parse tree") should
let you identify chunks of common code, which you can
set aside for the moment while you focus on the stuff that
is unique to the original ("missing features") or unique
to the buggered version ("backdoor hack").

Once you have a handle on the hack, it should be easy
(for Wouter at least :-) to figure out the rest ....

I have not done it recently (the search, that is!), but
googling for how to identify cheaters on comp sci class
projects should find you plenty of ideas, tools and
anecdotes.

  -John

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@192101 by

picon face
Liam O'Hagan wrote :

> Sorry to be so roundabout in my description, by necessity
> there are a lot of security concerns with an issue like this.


Hm, even *mentioning* it seems to be on the "security edge"... :-)

Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts17-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <.....20040130073729.HOBC17233.tomts17-srv.bellnexxia.netspam_OUTspammitvma.mit.edu>>          for <TakeThisOuTpiclist_errors.....spamTakeThisOuTSYMPATICO.CA>;
         Fri, 30 Jan 2004 02:37:29 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8247 ; Fri, 30 Jan 2004 02:37:25 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9193; Fri, 30 Jan 2004 02:37:26 -0500
Date:         Fri, 30 Jan 2004 02:37:26 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <TakeThisOuTLISTSERVKILLspamspamspamMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           .....listsjoshspamRemoveME3MTMP.COM,
             "For RemoveMEBlackholeeclipsespamspamBeGoneEarthlink.Net" <spamBeGonepiclist_errors@spam@spamspam_OUTSYMPATICO.CA>
Message-ID:   <LISTSERV%TakeThisOuT2004013002372560spamspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'owner-piclistEraseMEspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9191; Fri, 30 Jan 2004 02:37:26 -0500
Received: from mta108.mail.ukl.yahoo.com [217.12.11.45] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 02:37:25 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta108.mail.ukl.yahoo.com
From: RemoveMEMAILER-DAEMONEraseMEspamspam_OUTyahoo.co.uk
To: @spam@owner-piclistRemoveMEspamEraseMEmitvma.mit.edu
X-Loop: EraseMEMAILER-DAEMONspam@spam@yahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<@spam@viniciusbhspam_OUTspam.....yahoo.co.uk>:
Sorry, your message to spamBeGoneviniciusbhEraseMEspamyahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <owner-piclistspamBeGonespammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta108.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 07:37:27 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <RemoveME4.00CC4410@spam@spamspamBeGonecherry.ease.lsoft.com>; Fri, 30 Jan 2004 1:54:27 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1740 for .....PICLIST@spam@spamEraseMEMITVMA.MIT.EDU; Fri, 30 Jan 2004
         01:54:18 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 8278; Fri, 30 Jan 2004 01:54:03 -0500
Received: from linda-1.paradise.net.nz [202.0.58.20] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with ESMTP ; Fri, 30 Jan 2004 01:54:02 EST
X-Comment: mitvma.mit.edu: Mail was sent by linda-1.paradise.net.nz
Received: from smtp-2.paradise.net.nz (smtp-2a.paradise.net.nz [202.0.32.195])
         by linda-1.paradise.net.nz (Paradise.net.nz) with ESMTP id
         <.....0HSA000DGJ63QQRemoveMEspamlinda-1.paradise.net.nz> for .....PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU;
         Fri, 30 Jan 2004 19:54:03 +1300 (NZDT)
Received: from Paradise (202-0-40-37.adsl.paradise.net.nz [202.0.40.37]) by
         smtp-2.paradise.net.nz (Postfix) with SMTP id 026239E2FF     for
         <PICLISTEraseMEspam@spam@MITVMA.MIT.EDU>; Fri, 30 Jan 2004 19:54:03 +1300 (NZDT)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <001b01c3e6ec$bd319740$0301a8c0@user88l53zxzyb>
Message-ID:  <00db01c3e6fd$f4e3f3c0$7b01a8c0@Paradise>
Date:         Fri, 30 Jan 2004 19:54:48 +1300
Reply-To:     pic microcontroller discussion list <RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <spamBeGonePICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
From:         Russell McMahon <apptechspam_OUTspam@spam@PARADISE.NET.NZ>
Subject: Re: [EE]: Challenge for keen minds
To:           spamBeGonePICLIST@spam@spamMITVMA.MIT.EDU
Precedence: list

>  I have to implement a gate opening detector. It will log date and time
each
> time the gate is open and for how long. Must be battery-driven, battery
must
> last as much as possible, must be rugged and robust, and tamper-proof.
> People WILL try to defeat it.

Depends how techno savvy the defeaters are.

You could consider a "spike" that entered a hole in the lock when the gate
was shut. The spike may give the appearance of being a mechanical key
equivalent but also have some other attribute. eg a slug of brass at the
proper place in the spike would DECREASE inductance of a proximate coil that
it penetrated and be very hard to simulate if they were not aware what you
were doing. Similarly, ferrite or even just steel at SOME but not all
locations along the spike would allow selective inductance increase on some
proximate coils only. Proper code would be present only when gate was fully
shut. Again, users don't SEE any visible mechanism to do the coding.
Replicating the spike shape helps not at all. Even 2 or 3 coils would
probably be enough with one being triggered when the other(s) weren't by the
proper spike.

You could have a magnet at the spike end and a sensor (even reed switch)
that triggered it when the gate started to open. That way power could be
essentially off until the sensor was triggered.

Battery consumption should be easy to keep low if you use sensors (as above)
that notify you only when mechanical action is taking place. This could be
part of the gate latching mechanism or could be independent.

The trouble with IR as a comms method is that you either need to have the
rcvr always on or have to wake it to listen to you. If you are able to open
and shut the gate before doing comms then you could wake the IR up for a
brief period at each event. Something like capacitance coupled comms (I know
of one device that uses this) or
inductive coupling require closish proximity but can be power free until you
need to use them. Is it OK to be in close proximity or do you have to be at
a distance away?
If using IR "semi covertly" you could arrange to power up the receiver every
say 10 seconds and listen for an interrogation signal.

You can get real time clock IC's with wakeup function that draw sub 1 uA.
Your processor need draw power only when it is active and using the "wake on
demand" system as above battery drain can be very low.
Imagine a device that requires 10 mA for 1 second any time the gate is
opened or shut. A 100 mAH battery (modest) would support 100/10 x 3600/2 =
1800 odd opening and shutting pairs. That's about 2.5 per hour 24/7 for a
year.
A set of AA alkaline batteries would give about 20 times as much as this!

Russell McMahon

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body
*** MESSAGE TRUNCATED ***


..
.

2004\01\28@194211 by Liam O'Hagan

flavicon
face
yeah pretty much...

The last issue like this I found end up costing the manufacturer approx $30
million, replacing hundreds of thousands of defective devices before someone
exploited the fault.

At the moment, this seems to be pretty localised, but we cannot be sure if
this person has been doing this for years, but in small enough amounts that
it would be written off as a counting error, but has recently got greedy and
has taken enough to attract some attention.

I have watched the security video of this person defrauding this device
dozens of times, and plenty of other people have done the same, and we
cannot see anything unusual. We've tried a variety of tests with static
discharges up to 25kV, EMI, RF and magnetic interference and many more, but
with no luck, very intruiging

There has to be some method of triggering this extra code externally to the
device, as it has functioned correctly for every other user...

> {Original Message removed}

2004\01\28@200536 by James Caska

flavicon
face
Maybe it's simpler than that? might just be a magic pin-number.. ( If
the device uses one ) or is that just too damn obvious

James Caska
http://www.muvium.com
uVM - 'Java Bred for Embedded'



{Original Message removed}

2004\01\28@200745 by Russell McMahon

face
flavicon
face
> I have watched the security video of this person defrauding this device
> dozens of times, and plenty of other people have done the same, and we
> cannot see anything unusual. We've tried a variety of tests with static
> discharges up to 25kV, EMI, RF and magnetic interference and many more,
but
> with no luck, very intruiging
>
> There has to be some method of triggering this extra code externally to
the
> device, as it has functioned correctly for every other user...

Whatever you do DON'T scare him off.
The losses incurred are presumably small compared to the knowledge to be
gained.
Certainly far far far less than $30M !

If I was doing this with limited code space then something like the last
idea below would be easiest.

Consider one or more of:

- Key pressed longer than usual.

-Key pressed shorter than usual.

-Sequence of short/long key presses.

- PIN number chosen to inform machine that the chosen user is present -
probably in conjunction with other controls.

- Start sequence of key strokes then cancel and restart.

- Miskey PIN then rekey where two together provide cue.

   Is the PIN number miskeyed ?

   Can you get the actual key sequences used
   - better still timings of presses on keys?

- Time and/or date figure in the request

- Amount of money requested "unusual" or reacts with PIN in some way.
   This would be one of the easiest but hard to spot and unlikely to be
fluked by others.

   eg PIN = 3141 & amount = $79.69   = trapdoor on (can you see how)
        Only one chance in 10,000 of this being a fluke.
       Could be MUCH more subtle.

       eg PIN = 3141 & amount = $5.06 (almost uncrackable)
       (ie $ = Subtract PIN digits from 10, dec/inc/dec/inc digits, shift
right once.)

       Doing something like this twice in a row with two different simple
algorithms
       would increase odds of random triggering to about 1 in 10^8.

   Are the amounts REQUESTED unusual?
   Do they always request the same amount of $


   Does the paid amount bear some discoverable relationship to the
requested amount?


If you have ALL the information from a transaction you would have a good
chance of working out the trapdoor. If you analyse all the AVAILABLE
information  and find no clue then the unavailable information probably
holds the clue.

I would have thought that having the altered code would be a very clear
guide to what is going on.
Data entered via keypad (presumably).
Extra routines analyse this data in some manner.
Linkage between the two must exist.

Sounds like fun.
How much will you pay me ? :-)
(I'm just across the pond from you it seems :-) )



           Russell McMahon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@202218 by Liam O'Hagan

flavicon
face
Interesting theories, and let me never let you near the source code of any
of these devices!

The problem we have here is that the device in question only takes 1 signal
as input, from another device which is purely mechanical, and neither device
is accessible from outside the cabinet of the machine. There is other
software / firmware running in the device but it has no input to the device
with the changed code...

Unfortunately the security footage is not clear enough to determine what
keystrokes the person is entering, but theoretically that shouldn't affect
anything. We've verified that the firmware supporting the keystroke entry is
correct and we have source that has been very thoroughly checked.

I have the device that this person defrauded sitting in front of my desk,
and there's no evidence of tampering, or extra hardware that would allow
manipulation from outside the cabinet.

> {Original Message removed}

2004\01\28@205749 by Tom

flavicon
face
I was thinking along the lines of Russells comments for a while until your
last post. If you are doing what I think you're doing, you might want to
also consider the following scenario:

a) Confederate works the machine for some period.  Confederate enters a
series of numbers over time, operating the machine all the while.  Then the
confederate leaves.

b) Your man then steps up and enters the last part necessary to achieve the
oversize payoff and promptly leaves. This is noticed and you review the
security video *of this man* and learn very little.

c) The confederate has done nothing to raise suspicion - just operated the
machine and did not achieve questionable payoffs.  The hitman hits and
leaves quickly.

Just a guess.

During the security video, you mentioned that the video is not clear enough
to determine actual keystrokes entered.  My guess is that the video was put
in place to catch people who *don't* have back door access but rather are
maybe trying to bruteforce the machine to do their bidding.

I also will hazard a guess that the machine in question is operating in
many, many (hundreds if not thousands of) locations and there is no
convenient way to change the hardware to catch keystrokes, keystroke
timing, etc.

Without keystrokes, I'll hazard a final guess: you'll have to figure it out
the hard way going through the two sets of machine code to come up with the
method used.  You have your work cut out for you.  But of course, if it was
easy...

Go get'em, Sherlock!
Tom




At 12:23 PM 1/29/04 +1100, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@212448 by Russell McMahon

face
flavicon
face
> The problem we have here is that the device in question only takes 1
signal
> as input, from another device which is purely mechanical, and neither
device
> is accessible from outside the cabinet of the machine.

Ah. Light dawns. I think I understand the type of machine we are talking
about.
But, of course, I may be wrong.

Does the mechanical signal impart time dependent user information or,
rather, what is the nature of the signal that is transmitted? Can it be
"modulated" by the user? is it INTENDED to be modulated by the user whetnher
in duraction or timing. I'd assume one or more of these if the user expects
(perhaps forlornly) to excercise any intelligent controls over outcomes.

Assume (in the absence of other information for now) that the input device
signals commencement of user action but not the duration of user action.
Looking for susceptibility to timing patterns in the input seems potentially
useful.
eg all user input commences on second boundaries, or 10 second boundaries,
or is or isnt present at the soonest possible time when this is possible.

eg imagine that the machine has a cycle time after the user initiates
action. No user action in between is useful. The user elects to attempt new
action or not at the first time in each cycle when his input will be acted
on.
Yes Yes Yes No Yes No No ....

or: The user times from when the action may first be acted on by a variable
period.
Ready - wait 3 seconds
Ready - wait 1 seconds
Ready - wait 4 seconds
Ready - wait 2 seconds ...
(1000 Pi :-) )

If the duration that the user activates the mechanism for is also conveyed
to the electronics then this would also be usable as a signal, EVEN IF the
duration of signalling was not intended for use by the electronics.

Some combination of time between user activations & time taken after first
available time would provide a lartge number of potential combinations.

Also bear in mind the possibility that the "code" is a little hard to hit
and that the user is TRYING to trigger a sequence but much of the time fails
because his timing efforts are not close enough to what the machine
"desires". This would make it much harder to spot.

Do I get a look at the source code :-)


       Russell McMahon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@212655 by Liam O'Hagan

flavicon
face
Pretty much spot on....

We have records of all metering from the device for the days in question,
and can verify that noone else has used the device in that time...

All the meters add up correctly, except the device reports that it should
have x amount of cash left in it, but has far far less than that...

> {Original Message removed}

2004\01\28@213903 by Liam O'Hagan

flavicon
face
Put it this way,

Consider this device to be like a vending machine, it accepts money, and
dispenses money when a user declines a purchase

When money is entered, an electromechanical mechanism notifies the device in
question that money has been entered. The device in question then verifies
this with its own sensors and notifies the host that money has been entered.

What is happening here, is that the user enters some money, but the host
system apparently records ~10x that amount has been entered. The user then
removes the full 10x amount and walks away...

The electromechanical mechanism is working perfectly, and the host system is
working perfectly, somehow this device in between is inflating the amount of
money entered. The problem we face is that it only inflates the amount for
this one user, and works perfectly normally for other users. The only input
it has is from the eletromechanical device, and it's own sensors (which
can't be "spoofed", I tried that extensively)

> {Original Message removed}

2004\01\28@215826 by Russell McMahon

face
flavicon
face
> The only input it has is from the eletromechanical device, and it's own
sensors (which
> can't be "spoofed", I tried that extensively)


Are you able to advise the nature of the input from the em device.
ie does it fit into any of thre prior cetegories I suggested?
Is it a single output (on/off)?
Has it got duration?
Are its outputs timed as seen by the electronics.

ie what manner of signalling could not possibly be supported by the
interface and what could?

And "how hard can it be" :-) to look at the 'extra' code to get a good gude
from that?


       RM

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@221308 by Anthony Toft

flavicon
face
Is there something 'magic' about the bill the perp is using? A bit
longer or a bit wider?

Or something to do with putting it in and holding it while the machine
is trying to accept it.

If it is coin, is there something with the metalurgy? Difference in
magnetic response etc.

There are all sorts of tools to figure out what is different at the
sauce code level, personally I'd disassemble both the correctly behaving
and incorrectly behaving code so they are expanded the same way.

The main question though, how do you know that the supposed good version
is in fact good. It's entirely possible that _all_ machines are affected
the same way.

> {Original Message removed}

2004\01\28@221522 by Liam O'Hagan

flavicon
face
It has no duration as such, it just goes high - low - high when a coin
passes through it,

The only option to influence the device in question would be to time the
entry of coins to some specific interval. This device is used in about
300000 machines in this country alone, so it would be highly unlikely that
some timed-entry criteria would have gone unnoticed in the 9 12 years this
device has been operating!

How hard can it be? Well the disassembled output bears very little
resemblance to the output from disassembling the binary that's meant to be
in there :(

There is some commonality, but identifying what each mnemonic is meant to do
as the register lables appear to have been mangled by the disassembler a
lot!

> {Original Message removed}

2004\01\28@221930 by Liam O'Hagan

flavicon
face
the coins being entered are fine, we can verify that...

I've disassembled what's meant to be in there, and what is actually in
there, and side by side there's a lot of changes. I'm hoping it's not just a
stuff up on the part of the manufacturer when entering source into their
version control system

> {Original Message removed}

2004\01\28@222425 by Josh Koffman

flavicon
face
Perhaps it's not only time based, but based on the type of coin received
and the sequence it came in? For example, dime, quarter, penny, dime,
dime, all 2 seconds apart? Or perhaps the amount put into the machine?
For example, if the machine was selling $1.00 drinks, it would be
unlikely anyone would have tried to put in $20.00 worth of change.

I'm sure I speak for the majority of the list, but this problem has
really intrigued me! If possible, once you do figure it out, could you
let us know what it was? Perhaps changing details or whatever, but the
general method would be interesting.

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

Liam O'Hagan wrote:
> The only option to influence the device in question would be to time the
> entry of coins to some specific interval. This device is used in about
> 300000 machines in this country alone, so it would be highly unlikely that
> some timed-entry criteria would have gone unnoticed in the 9 12 years this
> device has been operating!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@223437 by Ken Pergola

flavicon
face
Hi Liam,

Does this device have a real-time clock?

Do the incidents happen at a certain time (or window of time) of day or any
other time-pattern you can discern?

Have you done any RF snooping?

Did the suspect (who originally worked at the company that produces these
devices) write the firmware for this device?

Best regards,

Ken Pergola

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@223644 by Liam O'Hagan

flavicon
face
all the same type of coin, interval is difficult to determine as the
surveillance video is accelerated by some unknown amount. :(

> {Original Message removed}

2004\01\28@223851 by Anthony Toft

flavicon
face
> I'm hoping it's not just a stuff up on the part of the
> manufacturer when entering source into their version control system

That too is a possibility...

Do you have access to the design docs etc so you can assess _intent_?
Like Mr Koffman stated this is _very_ interesting, I would _love_ a job
like this!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts30-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spamBeGone20040128040316.KRZZ1796.tomts30-srv.bellnexxia.netspam_OUTspamRemoveMEmitvma.mit.edu>>          for <.....piclist_errorsspamRemoveMESYMPATICO.CA>;
         Tue, 27 Jan 2004 23:03:16 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6225 ; Tue, 27 Jan 2004 23:03:13 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 6768; Tue, 27 Jan 2004 23:03:13 -0500
Date:         Tue, 27 Jan 2004 23:03:13 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <LISTSERVspam@spam@MITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           EraseMElistsjoshRemoveMEspamSTOPspam3MTMP.COM,
             RemoveMEpiclist_errorsKILLspamspamTakeThisOuTSYMPATICO.CA
Message-ID:   <LISTSERV%spamBeGone2004012723031316spam@spam@MITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'RemoveMEowner-piclistspam_OUTspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 6766; Tue, 27 Jan 2004 23:03:13 -0500
Received: from mta442.mail.yahoo.com [216.136.129.97] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 23:03:12 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta442.mail.yahoo.com
From: MAILER-DAEMONspamspamyahoo.com
To: spam_OUTowner-piclistspam_OUTspamspam_OUTmitvma.mit.edu
X-Loop: MAILER-DAEMONspam_OUTspamyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<RemoveMEhbarregrdKILLspamspam@spam@yahoo.com>:
Sorry, your message to hbarregrdspamBeGonespam.....yahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <KILLspamowner-piclistspam.....mitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta442.mail.yahoo.com with SMTP; Tue, 27 Jan 2004 15:03:20 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <spam_OUT6.00CBFB70spamKILLspamcherry.ease.lsoft.com>; Tue, 27 Jan 2004 16:46:02 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 4118 for RemoveMEPICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU; Tue, 27 Jan 2004
         16:45:57 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7281; Tue, 27 Jan 2004 16:44:47 -0500
Received: from smtp1.clear.net.nz [203.97.33.27] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Tue, 27 Jan 2004 16:44:46 EST
X-Comment: mitvma.mit.edu: Mail was sent by smtp1.clear.net.nz
Received: from jc2 (218-101-64-183.dialup.clear.net.nz [218.101.64.183]) by
         smtp1.clear.net.nz (CLEAR Net Mail) with SMTP id
         <KILLspam0HS60049Y4E6UVspamspamBeGonesmtp1.clear.net.nz> for PICLISTspamspamMITVMA.MIT.EDU; Wed,
         28 Jan 2004 10:44:32 +1300 (NZDT)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <001001c3e4fe$2f061620$5d65a8c0@ISLANDERS>
           <RemoveME64jd10pa15sus1okulbnb89p4hbi87u9gvspamBeGonespamRemoveME4ax.com>> Message-ID:  <010c01c3e51e$f10f57c0$7223fea9@jc2>
Date:         Wed, 28 Jan 2004 10:43:38 +1300
Reply-To:     pic microcontroller discussion list <
KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <@spam@PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU>
From:         Jinx <joecolquittspamBeGonespamspamBeGoneCLEAR.NET.NZ>
Subject: Re: [PIC:] Picstart plus as an in circuit programmer? (16F627A)
To:           spamBeGonePICLISTspamMITVMA.MIT.EDU
Precedence: list

> For normal operation, jumpers are placed across the top 4
> spaces to connect the PIC pins to where they normally go. To
> program, the jumpers are removed and a cable is plugged in

That's a pretty easy way to do it (and you can glue the 4 jumpers
together). I've been looking around for a "switching" header to
bypass the need to isolate the PIC before programming. I've
made one from a piece of edge connector and springy contacts
from an edge socket like this (four side by side, 0V isn't broken)

|/
|\
||
||
ab

where "a" goes to the PIC and "b" goes to the rest of the circuit,
and the ICSP breaks the contact and connects to "a" but it was a
real fiddly PITA. Works OK but it's uncertain how long this homer
will keep good ohmic contact when the unit is out in the field, even
with gold plating. And I don't fancy trying to make more than a few
of them. Anyone know of anything suitable off-the-shelf ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
..
.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts34-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spam_OUT20040128015745.DBAC23141.tomts34-srv.bellnexxia.netSTOPspamspammitvma.mit.edu>>          for <RemoveMEpiclist_errorsspamspamSYMPATICO.CA>;
         Tue, 27 Jan 2004 20:57:45 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6146 ; Tue, 27 Jan 2004 20:57:42 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 3414; Tue, 27 Jan 2004 20:57:42 -0500
Date:         Tue, 27 Jan 2004 20:57:42 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <TakeThisOuTLISTSERVspamspamRemoveMEMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           KILLspamlistsjoshspamspamspam_OUT3MTMP.COM,
             piclist_errorsRemoveMEspamSYMPATICO.CA
Message-ID:   <LISTSERV%EraseME2004012720574214STOPspamspamRemoveMEMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spam_OUTowner-piclistRemoveMEspamEraseMEMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 3412; Tue, 27 Jan 2004 20:57:42 -0500
Received: from mta103.mail.scd.yahoo.com [66.218.86.19] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 20:57:41 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta103.mail.scd.yahoo.com
From: TakeThisOuTMAILER-DAEMONRemoveMEspam@spam@yahoo.com
To: EraseMEowner-piclistRemoveMEspammitvma.mit.edu
X-Loop: spamMAILER-DAEMON.....spamspamyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<hbarregrdspam_OUTspam@spam@yahoo.com>:
Sorry, your message to .....hbarregrdspamspam.....yahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <owner-piclistKILLspamspamEraseMEmitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta103.mail.scd.yahoo.com with SMTP; Tue, 27 Jan 2004 12:52:07 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <EraseME21.00CBF63D@spam@spam@spam@cherry.ease.lsoft.com>; Tue, 27 Jan 2004 12:51:34 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 9403 for @spam@PICLISTspamspamKILLspamMITVMA.MIT.EDU; Tue, 27 Jan 2004
         12:51:29 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9570; Tue, 27 Jan 2004 12:51:22 -0500
Received: from berkelium3.baremetal.com [208.184.111.62] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with ESMTP ; Tue, 27 Jan 2004 12:51:21 EST
X-Comment: mitvma.mit.edu: Mail was sent by berkelium3.baremetal.com
Received: from ISLANDERS (cbshost-12-107-16-202.sbcox.net [12.107.16.202]) by
         berkelium3.baremetal.com (8.12.10/8.12.9) with SMTP id i0RHorVb006616
         for <spamBeGonePICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU>; Tue, 27 Jan 2004 09:50:53 -0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Scanned-By: MIMEDefang 2.36
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID:  <001001c3e4fe$2f061620$5d65a8c0@ISLANDERS>
Date:         Tue, 27 Jan 2004 09:51:20 -0800
Reply-To:     pic microcontroller discussion list <RemoveMEPICLISTKILLspamspamRemoveMEMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <TakeThisOuTPICLISTspamMITVMA.MIT.EDU>
From:         David Schmidt <spamBeGonetechsavyKILLspamspamTakeThisOuTDSCHMIDT.COM>
Subject: [PIC:] Picstart plus as an in circuit programmer? (16F627A)
To:           EraseMEPICLIST.....spamKILLspamMITVMA.MIT.EDU
Precedence: list

I'd like to use an SSOP 20 packaged 16F627A in a project.  I have a =
picstart plus, but no programming adapter for an SSOP20.
I would like to solder the SSOP20 into my PCB and program it =
"in-circuit" using my picstart plus (also I may need to change the=20
firmware later to correct for bugs).

- Is the in-circuit programming of the 16F627A the same hookup, voltages =
and algorithm that the picstart plus uses?
(can I just jumper over the 5 pins needed for in-circuit programming =
from the picstart plus?)

Thanks.  The microchip website didn't list the picstart plus as being =
able to program in-circuit, but I suspect that is just because they =
don't offer a hookup cable.

Dave

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*** MESSAGE TRUNCATED ***


..
.

2004\01\28@223853 by Liam O'Hagan

flavicon
face
yes, no, yes, no :)

{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@224304 by Bob Axtell

face picon face
er.. if it's a slot machine, I'll help you for free....

--Bob

Liam O'Hagan wrote:

> yes, no, yes, no :)
>
>
>>{Original Message removed}

2004\01\28@225753 by Bob Ammerman

picon face
Did the suspect (who originally worked at the company that produces these
devices) have access to the source code and/or hardware design of this
device?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@230207 by Jinx

face picon face
> general method would be interesting.

And please don't leave us out when it goes to court

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@230719 by Jinx

face picon face
> Unfortunately the security footage is not clear enough to determine
> what keystrokes the person is entering

> all the same type of coin, interval is difficult to determine as the
> surveillance video is accelerated by some unknown amount. :(

If you've got typical crappy security footage can you/would it help to
do something about that, maybe be a little patient and gather better
evidence. Obviously the footage is good enough to ID the user. but
you might be missing the discretest action

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts34-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <20040130073727.FPKC23141.tomts34-srv.bellnexxia.netSTOPspamspamKILLspammitvma.mit.edu>>          for <@spam@piclist_errors.....spamspamSYMPATICO.CA>;
         Fri, 30 Jan 2004 02:37:27 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8243 ; Fri, 30 Jan 2004 02:37:20 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9173; Fri, 30 Jan 2004 02:37:21 -0500
Date:         Fri, 30 Jan 2004 02:37:21 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <spamLISTSERV.....spam.....MITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           listsjosh.....spam3MTMP.COM,
             "For KILLspamBlackholeeclipsespam_OUTspamEarthlink.Net" <spam_OUTpiclist_errorsspamTakeThisOuTSYMPATICO.CA>
Message-ID:   <LISTSERV%.....2004013002372079.....spamRemoveMEMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spam_OUTowner-piclistTakeThisOuTspamEraseMEMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9171; Fri, 30 Jan 2004 02:37:21 -0500
Received: from mta108.mail.ukl.yahoo.com [217.12.11.45] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 02:37:20 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta108.mail.ukl.yahoo.com
From: EraseMEMAILER-DAEMONspamBeGonespamKILLspamyahoo.co.uk
To: RemoveMEowner-piclistspamBeGonespamspammitvma.mit.edu
X-Loop: @spam@MAILER-DAEMONspamspamyahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<TakeThisOuTviniciusbhKILLspamspam@spam@yahoo.co.uk>:
Sorry, your message to .....viniciusbhRemoveMEspamyahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <KILLspamowner-piclistspamTakeThisOuTmitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta108.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 07:37:23 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <TakeThisOuT11.00CC428Dspamspam_OUTcherry.ease.lsoft.com>; Fri, 30 Jan 2004 1:33:44 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1038 for RemoveMEPICLISTspamspamSTOPspamMITVMA.MIT.EDU; Fri, 30 Jan 2004
         01:33:37 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7309; Fri, 30 Jan 2004 01:32:13 -0500
Received: from sj-iport-4.cisco.com [171.68.10.86] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 01:32:12 EST
X-Comment: mitvma.mit.edu: Mail was sent by sj-iport-4.cisco.com
Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by
         sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0U6WCNv012851 for
         <.....PICLISTEraseMEspamMITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:13 -0800 (PST)
Received: from mac.com (sjc-vpn1-253.cisco.com [10.21.96.253]) by cisco.com
         (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA15067 for
         <spamBeGonePICLISTspamRemoveMEMITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:12 -0800 (PST)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Message-ID:  <.....8215EAE0-52E9-11D8-9E8E-000A95E5DF26EraseMEspammac.com>> Date:         Thu, 29 Jan 2004 21:59:47 -0800
Reply-To:     pic microcontroller discussion list <
spamPICLISTspam_OUTspam@spam@MITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <spamPICLIST@spam@spamSTOPspamMITVMA.MIT.EDU>
From:         William Chops Westfield <spamBeGonewestfwspamBeGonespam@spam@MAC.COM>
Subject: Re: [PIC:] Process
To:           RemoveMEPICLISTRemoveMEspamRemoveMEMITVMA.MIT.EDU
In-Reply-To:  <5.2.0.9.2.20040129125546.01636a58KILLspamspamspammail.cedar.net>> Precedence: list

On Thursday, Jan 29, 2004, at 09:56 US/Pacific, Dave VanHorn wrote:

>
>> Have you tried peer reviews and code walk-throughs?
>
> Not yet.
>
DESIGN reviews might be more useful.  Usually, by the time you
do a code review, you have code that works at least some of the
time, and that can be a lot of pressure against improvement.  It
can be good for improving your coding style, eventually.  At least,
if you can keep the code reviews focussed on meaningful issues and
not on distractions that are really more a matter of personal
perference.  (although, truth be told, figuring out which are which
can be educational and helpful.)

OTOH, Who am I kidding.  I've been at cisco a very long time,
watching from the middle of the inside as we grew from a tiny
company to a very big company.  With constantly changing challenges
in the "quality" area.  Through three different source code control
systems, several compilers, pre and post symbolic debugger, half a
dozen different processors, ISO 9000, international protocol
certifications, and a plethora of test and "release processes."
Mostly, I've seen an awful lot of stuff that doesn't quite seem
to work all that much better than mere admonishments "write good
code."  (of course, maintaining even THAT level past certain critical
sizes of "the engineering department" is doing "ok."  maybe.)

Sigh.
BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistserv@spam@spammitvma.mit.edu with SET PICList DIGEST in the body
*** MESSAGE TRUNCATED ***


..
.

2004\01\28@231131 by Liam O'Hagan

flavicon
face
Yes apparently, although to what extent I don't know...

It's got to be something simple, I have access to the inside of this device,
and I have tools that can generate the necessary pulses on each line, and I
have plenty of time and access to restricted functionality on the device,
yet it is proving extraordinarily difficult to replicate what this person is
doing in the field without causing multiple errors on the host device. Yet
this person is doing it in the field, in plain view of security devices with
no visible tools, no access to the internals of the device, no access to the
restricted functionality, in 3 minutes and without leaving a trace!

Frustrating to say the least...

> {Original Message removed}

2004\01\28@231343 by Liam O'Hagan

flavicon
face
I have design docs, flow charts, timing diagrams, test results, source code
for the binary that's meant to be in there, hardware drawings, schematics
and so on and so forth.

Using an oscilloscope, I can view what the inputs and outputs of this device
do in response to the various stimuli, and I've verified that this is
exactly what it's meant to do. Problem is, I can't recreate what this person
is doing }:(

> {Original Message removed}

2004\01\28@231547 by Liam O'Hagan

flavicon
face
Unfortunately, the device is no longer in the field, it's sitting next to my
desk...

There was talk of installing cameras inside the device, and extra logging,
but thatw as canned when it was realised it would cost a lot more than the
person was getting away with, and would most likely alert them anyway.

> {Original Message removed}

2004\01\28@232829 by Jinx

face picon face
> There was talk of installing cameras inside the device, and extra
> logging, but that was canned when it was realised it would cost a
> lot more than the person was getting away with, and would most
> likely alert them anyway

So it's previous activity that you're trying to re-create, not stop an
ongoing crime. Presumably you have a record of what this person
was able to defraud the machine of so at some point there'll be
legal action

Didn't taking that particular machine OS (replaced by a proper one ?)
alert the perp ? Do you think the one on your desk is the only one, or
are you expecting a similar crime somewhere else ?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@233336 by Ken Pergola

flavicon
face
Liam O'Hagan wrote:

> ...but that was canned when it was realized it would cost a lot...

Hi Liam,

And just think of the litigation costs if the company ever gets solid proof
on this dishonest person.
I know it might sound crazy, but I wonder if the company has thought of
paying the guy (and giving him immunity) to tell them how he does it --
might be cheaper in the long run. Money talks and everyone has a price.

Regards,

Ken Pergola

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\28@234129 by Liam O'Hagan

flavicon
face
This person has defrauded identical machines at a number of locations... I
know of at least 3 and that's only the ones where enough was taken to
actually catch someone's attention.

They have probably been tipped off by the removal of the one I currently
have, so I would expect them to lay low for a while, or at least reduce they
amount they take to insignicant levels so nobody will notice.

Legal action hasn't been attempted yet because there's no proof that this
person defrauded the device expect for the missing money (and they fake
names they used when claiming the cash)

> {Original Message removed}

2004\01\28@234336 by Liam O'Hagan

flavicon
face
well they know who he is, so whether they do that is up to them ;)

I'd like it if they did, it would make my job a lot easier...

> {Original Message removed}

2004\01\28@234548 by Liam O'Hagan

flavicon
face
Make that 11 separate devices so far...

> -----Original Message-----
> From: Liam O'Hagan
> Sent: Thursday, January 29, 2004 3:43 PM
> To:   'pic microcontroller discussion list'
> Subject:      RE: [PIC:] Disassemblers
>
> This person has defrauded identical machines at a number of locations... I
> know of at least 3 and that's only the ones where enough was taken to
> actually catch someone's attention.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\01\29@002134 by William Chops Westfield

face picon face
On Wednesday, Jan 28, 2004, at 18:41 US/Pacific, Liam O'Hagan wrote:

> he only input
> it has is from the eletromechanical device, and it's own sensors (which
> can't be "spoofed", I tried that extensively)
>
Even with, say, those whopping HUGE POWERFUL magnets you can buy
these days?

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@002341 by Josh Koffman

flavicon
face
Ok, so you can't get absolute time...but you could get relative time, ie
insert coin one, wait X time. Insert coin two, wait 2X time.

Do you only have a video of the person doing it once? If you have it
multiple times, you may be able to get a better feel for what it
happening.

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

Liam O'Hagan wrote:
> all the same type of coin, interval is difficult to determine as the
> surveillance video is accelerated by some unknown amount. :(

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts40-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <TakeThisOuT20040130073722.ZJKQ8354.tomts40-srv.bellnexxia.netspam_OUTspammitvma.mit.edu>>          for <KILLspampiclist_errors.....spamTakeThisOuTSYMPATICO.CA>;
         Fri, 30 Jan 2004 02:37:22 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8239 ; Fri, 30 Jan 2004 02:37:18 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9147; Fri, 30 Jan 2004 02:37:19 -0500
Date:         Fri, 30 Jan 2004 02:37:19 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <TakeThisOuTLISTSERVEraseMEspamRemoveMEMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           spam_OUTlistsjoshRemoveMEspam.....3MTMP.COM,
             "For spamBlackholeeclipseKILLspamspamKILLspamEarthlink.Net" <spampiclist_errorsspam_OUTspamSYMPATICO.CA>
Message-ID:   <LISTSERV%STOPspam2004013002371854spam_OUTspamspamBeGoneMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spam_OUTowner-piclistspamspamBeGoneMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9145; Fri, 30 Jan 2004 02:37:19 -0500
Received: from mta108.mail.ukl.yahoo.com [217.12.11.45] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 02:37:18 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta108.mail.ukl.yahoo.com
From: EraseMEMAILER-DAEMONspamKILLspamyahoo.co.uk
To: EraseMEowner-piclistRemoveMEspammitvma.mit.edu
X-Loop: .....MAILER-DAEMONspamspam_OUTyahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<@spam@viniciusbhEraseMEspamspamyahoo.co.uk>:
Sorry, your message to viniciusbhTakeThisOuTspamKILLspamyahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

The original message is over 5K. Message truncated.

Return-Path: <RemoveMEowner-piclistTakeThisOuTspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta108.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 07:37:20 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <@spam@10.00CC443CSTOPspamspamcherry.ease.lsoft.com>; Fri, 30 Jan 2004 1:33:33 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1033 for TakeThisOuTPICLISTTakeThisOuTspamRemoveMEMITVMA.MIT.EDU; Fri, 30 Jan 2004
         01:33:27 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7283; Fri, 30 Jan 2004 01:31:29 -0500
Received: from bandit.rpmservers.com [207.44.248.37] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with ESMTP ; Fri, 30 Jan 2004 01:31:28 EST
X-Comment: mitvma.mit.edu: Mail was sent by bandit.rpmservers.com
Received: from adsl-68-73-54-53.dsl.sfldmi.ameritech.net ([68.73.54.53]
         helo=ubasics.com) by bandit.rpmservers.com with asmtp
         (TLSv1:RC4-MD5:128) (Exim 4.24) id 1AmQOa-0006ZO-TQ for
         spam_OUTPICLISTspamspam.....MITVMA.MIT.EDU; Thu, 29 Jan 2004 22:36:45 -0600
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
           Gecko/20040113
X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja, ko, ko-kp,
                  ko-kr
MIME-Version: 1.0
References: <BAY8-DAV380Gxw8Zw5V0000f28a.....spam@spam@hotmail.com>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
            please include it with any abuse report
X-AntiAbuse: Primary Hostname - bandit.rpmservers.com
X-AntiAbuse: Original Domain - mitvma.mit.edu
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - ubasics.com
Message-ID:  <
spamBeGone4019DF60.7080502spamspam_OUTubasics.com>
Date:         Thu, 29 Jan 2004 23:36:48 -0500
Reply-To:     pic microcontroller discussion list <EraseMEPICLIST.....spamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <spamPICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
From:         "M. Adam Davis" <adampicspamspamTakeThisOuTUBASICS.COM>
Subject: Re: [OT:] Windows XP intermittent performance
To:           RemoveMEPICLISTRemoveMEspamMITVMA.MIT.EDU
In-Reply-To:  <TakeThisOuTBAY8-DAV380Gxw8Zw5V0000f28a@spam@spam@spam@hotmail.com>> Precedence: list

I usually use ad aware to find and kill the majority of spy/mal/adware
type programs, and then a good virus program.

Then you should disconnect any network drives you are not actively
using  (often XP will attempt to scan the drive tree when you open any
file explorer window, which happens every time you save/open/etc)

The only other time consumers I've found have been related to the
individual program you're trying to interact with, or in some cases a
driver problem (a scanner, for instance, which isn't connected but the
driver keeps attempting communication with it which times out and blocks)

But in nearly every case where people have payed me to 'fix' their
machines, I've been able to:
Run an up to date virus scan
Run an adware removal tool
Remove all programs not currently used
Remove all drivers/devices not currently used
Reduce number of items on desktop (no more than maybe a dozen)
Run windowsupdate (load all critical patches)
Turn on the built in firewall
Set internet explorer and OExpress to high security settings (no
executable attachments - few home users /need/ them)
* other stuff

In some case, on slower computers, I also reduce display candy, and
remove the desktop background (which consumes an astonishingly huge
amount of processor time to redraw...)

I've yet to see an XP machine that doesn't speed up significantly after
this.

If that doesn't do the trick, then write down all the programs you use
with their license information, backup your data, email, etc (can use
the system transfer wizard to backup up nearly everything to a CD) and
then reload from scratch.

-Adam

* Other stuff:
Tell them to disallow their kids from loading any sort of music sharing
software such as kazaa
If they are somewhat computer savvy, explain to them how using a
different browser, such as Mozilla, would limit their exposure, and then
install it for them - setting it as the default for browsing.

James Nick Sears wrote:

>Hello,
>
>I have a Windows XP desktop that has been driving me crazy lately.  Generally speaking, it runs fine for a few days and then will all at once (normally on a reboot) get into a slow motion state where it takes forever to boot, logon, open a folder, etc, sometimes to the point where it is completely useless.  I then go through a regimen of defragging and running various Norton Systemworks tools, etc which typically will bring it back to life for a few days, in which it performs very well and then the cycle repeats itself.  In this process I have also turned off the fancy display settings, disabled unnecessary services, set my paging file to one large constant file size, etc.
>
>Yesterday I had a major slowdown (couldn't even program a PIC with the damned thing), defragged my system dri
*** MESSAGE TRUNCATED ***


..
.

2004\01\29@003043 by Liam O'Hagan

flavicon
face
yes indeedy I forget the exact value but it something like 100mT or 10 gauss
or something :)

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@004117 by Liam O'Hagan

flavicon
face
just the once...

> -----Original Message-----
> From: Josh Koffman [SMTP:spamBeGonelistsjoshKILLspamspam3MTMP.COM]
> Sent: Thursday, January 29, 2004 4:07 PM
> To:   PICLIST@spam@spamKILLspamMITVMA.MIT.EDU
> Subject:      Re: [PIC:] Disassemblers
>
> Ok, so you can't get absolute time...but you could get relative time, ie
> insert coin one, wait X time. Insert coin two, wait 2X time.
>
> Do you only have a video of the person doing it once? If you have it
> multiple times, you may be able to get a better feel for what it
> happening.
>
> Josh
> --

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@012320 by William Chops Westfield

face picon face
On Wednesday, Jan 28, 2004, at 20:44 US/Pacific, Liam O'Hagan wrote:
>>
>> And just think of the litigation costs if the company ever gets solid
>> proof on this dishonest person.

It's a criminal matter, presumably, so "society" gets to pay the
count costs.  I supposed there could be a civil trial as well,
but as you say, it hardly seems worthwhile...

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@014014 by Denny Esterline

picon face
> Legal action hasn't been attempted yet because there's no proof that this
> person defrauded the device expect for the missing money (and they fake
> names they used when claiming the cash)
>


I've been following this thread with some interest (as I'm sure, are many
other people) and this caught my attention: "claiming the cash". So this
device puts out some kind of paper ticket, or tokens or something? And the
user redeems them elsewhere?

Is there a possibility of spoofing this process? Could a paper ticket with
some numbers be forged or modified? I'm also reminded of a supposedly true
story I heard about a guy ripping off a casino in LasVegas. He forged $10
silver slot tokens. They never knew until one day they did a hard count and
found many thousands more than there should have been.

Other than that, I can only recommend that you get really cozy with the
code. (or maybe your company can justify contracting a consultant with more
experience with that particular processor?)

-Denny

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@015320 by Kresho

flavicon
face
I know of a case in the past where someone involved in the design of a games
machine made a single pixel in a corner of the display turn on at particular
times to indicate what his next course of action should be. This was
unnoticable to the general populace but for that person looking hard for
that single pixel it was like an unlimited bank account.

I believe he was caught only because some sys admin noticed some time later
that the culprit used someone else's access rights to their development
tools outside of normal working hours.

This could be a similar case - see the pixel flash and then do whatever
sequence of events.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@031225 by Michael Davidson

flavicon
face
On 2004-01-29 at 14:21:03 [+1100], you wrote:
> I've disassembled what's meant to be in there, and what is actually in
> there, and side by side there's a lot of changes. I'm hoping it's not just a
> stuff up on the part of the manufacturer when entering source into their
> version control system

Are there any optimisation switches for the compiler? If so, were both your
pre-dissassembled files compiled with the same settings?

Also, try running both files through diff, it should help pin point exactly
where the changes are.

--
Michael Davidson
Fortune:
The more laws and order are made prominent, the more thieves and
robbers there will be.
               -- Lao Tsu

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@032509 by Mark Hore

flavicon
face
A suggestion for analysing the funny binary.

get an emulator | simulator for this chip (you will need the source code
though) and modify it to output the program counter to a file on each
instruction cycle. Run this emulator with simulated input that would be
expected in normal operation, including the various wait times. run for
a fairly long time.

collate the outputted file  to produce a list of the frequency of call
for each line of code. divide this list into groups based on frequency.
The backdoor code, or at least part of it should be found in the group
that is least frequently called. this should narrow your search down to
approximately 10% of the dissassembled code.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@043304 by Win Wiencke

flavicon
face
<Liam O'Hagan writes in part>
> The problem we have here is that the device in question only takes 1
> signal  as input, from another device which is purely mechanical, and
> neither device  is accessible from outside the cabinet of the machine.
> There is other software / firmware running in the device but it has no
> input to the device with the changed code...

Perhaps the hacker is using ultrasonics.  I once had a debounce routine go
nuts when external vibration turned some mechanical device contacts into the
next best thing to a tuning fork.  The net result was that the false input
swamped everything downstream.  Never paid me anything though...

Win Wiencke

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts26-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <EraseME20040128120829.ZMEC5924.tomts26-srv.bellnexxia.netRemoveMEspam@spam@mitvma.mit.edu>>          for <RemoveMEpiclist_errorsspamspamEraseMESYMPATICO.CA>;
         Wed, 28 Jan 2004 07:08:29 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6591 ; Wed, 28 Jan 2004 07:08:25 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 8218; Wed, 28 Jan 2004 07:08:26 -0500
Date:         Wed, 28 Jan 2004 07:08:26 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <STOPspamLISTSERV.....spamMITVMA.MIT.EDU>
Subject: PICLIST: error report from FITCH5.UNI2.NET
To:           spamBeGonelistsjoshRemoveMEspamRemoveME3MTMP.COM,
             "For @spam@BlackholeeclipsespamBeGonespamEarthlink.Net" <spam_OUTpiclist_errorsspamspamSYMPATICO.CA>
Message-ID:   <LISTSERV%spam2004012807082571spamspamspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spamBeGoneowner-piclistKILLspamspamKILLspamMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 8216; Wed, 28 Jan 2004 07:08:26 -0500
Received: from fitch5.uni2.net [130.227.52.108] by mitvma.mit.edu (IBM VM SMTP
         Level 430) via TCP with ESMTP ; Wed, 28 Jan 2004 07:08:25 EST
X-Comment: mitvma.mit.edu: Mail was sent by fitch5.uni2.net
Received: from HLUSF26A.lundbeck.com ([130.227.160.123])
       by fitch5.uni2.net (8.12.6/8.11.6) with SMTP id i0SC8LKM004112
       for <TakeThisOuTowner-piclistspamspammitvma.mit.edu>; Wed, 28 Jan 2004 13:08:26 +0100
Message-Id: <spamBeGone200401281208.i0SC8LKM004112spamfitch5.uni2.net>> Received: from  ([172.16.0.163]) by HLUSF26A.lundbeck.com; Wed, 28 Jan 2004
         13:06:55 +0100 (CET)
From:
EraseMEWebshield.SMTP.V4.5.MR1a.Mail.ServiceEraseMEspamfitch5.uni2.net> Date: Wed Jan 28 13:07:23 2004
To: <
spamBeGoneowner-piclistspam_OUTspam.....mitvma.mit.edu>
Subject: Returned Mail: Error During Delivery

------ Here is your List of Failed Recipients ------
<spamjanlspamlundbeck.com>


Mail Server is down or unreachable.

-------- Here Is Your Returned Mail --------
Received: FROM lundbeck.com BY ludk0163.lundbeck.com ; Wed Jan 28 12:42:48 2004 +0100
Received: from ([10.10.3.249])
       by HLUIMX26A.lundbeck.com with SMTP ;
       Wed, 28 Jan 2004 12:42:13 +0100 (CET)
Received: from cherry.ease.lsoft.com ([209.119.0.109]) by HLUSF26A.lundbeck.com; Wed, 28 Jan 2004 12:41:39 +0100 (CET)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <RemoveME5.00CC0BCDKILLspamspamKILLspamcherry.ease.lsoft.com>; Wed, 28 Jan 2004 6:42:09 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 6827 for EraseMEPICLISTspamBeGonespamspamMITVMA.MIT.EDU; Wed, 28 Jan 2004
         06:42:03 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7666; Wed, 28 Jan 2004 06:40:39 -0500
Received: from ixion.tartarus.org [195.149.39.210] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with ESMTP ; Wed, 28 Jan 2004 06:40:39 EST
X-Comment: mitvma.mit.edu: Mail was sent by ixion.tartarus.org
Received: from chris by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
         for KILLspamPICLISTspamMITVMA.MIT.EDU id 1Alo3k-0005Mf-00; Wed, 28 Jan 2004
         11:40:40 +0000
References: <E1AlnJJ-0007bo-SXspam_OUTspamspamsmtp.aaisp.net.uk>
           <000001c3e58f$2ad593f0$0b00a8c0@PAARD>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Message-ID:  <20040128114040.GA17956spamspam@spam@ixion.tartarus.org>> Date:         Wed, 28 Jan 2004 11:40:40 +0000
Reply-To:     pic microcontroller discussion list <
spamBeGonePICLIST.....spamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <.....PICLIST@spam@spamMITVMA.MIT.EDU>
From:         Chris Emerson <@spam@chrisspamIXION.TARTARUS.ORG>
Subject: Re: [OT]: JAL licensing (was SCO lobbying Congress about Linux)
To:           PICLISTRemoveMEspamMITVMA.MIT.EDU
In-Reply-To:  <000001c3e58f$2ad593f0$0b00a8c0@PAARD>
Precedence: list

On Wed, Jan 28, 2004 at 12:09:15PM +0100, Wouter van Ooijen wrote:
> > call libraries dynamically" does not apply, because the
> > embedded programs are output from the compiler, not
> > covered by the licence for source of the compiler/libraries.
>
> True for the compiler, not true for the libraries. The output is a
> 'derived work' (lawyer speak) of the libraries.

Have you considered what they do for GNU bison?  The output of bison
contains a significant chunk of bison itself, but there's an exception
which means that a program produced with bison doesn't have to be under
the GPL.

See src/parse-gram.c in the bison source for the text of the exception.

Chris

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


.

2004\01\29@072249 by Alan B. Pearce

face picon face
>- Amount of money requested "unusual" or reacts with PIN in some way.
>    This would be one of the easiest but hard to spot and unlikely to be
>fluked by others.
>
>    eg PIN = 3141 & amount = $79.69   = trapdoor on (can you see how)
>         Only one chance in 10,000 of this being a fluke.
>        Could be MUCH more subtle.
>
>        eg PIN = 3141 & amount = $5.06 (almost uncrackable)
>        (ie $ = Subtract PIN digits from 10, dec/inc/dec/inc digits, shift
>right once.)

This would be easily entered, and identifiable as a trapdoor, as the decimal
key is not used when entering the amount of money, as it needs to be an
integer.

Another trapdoor would be, say the smallest note is a $10, then entering
anything other than a zero as the last digit starts the trapdoor code, and
the last digit gets sent off as a 0 to the host machine.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@074156 by Jake Anderson

flavicon
face
There is or was a cheat code for minesweper that would turn the top left
pixel of your screen red when your mouse was over a mine.


> {Original Message removed}

2004\01\29@080312 by Alan B. Pearce

face picon face
Liam's intriguing conundrum produced these snippets: -

>>Funnily enough, the person that is removing this money originally
>>worked for the company that prodices these devices...

>> Did the suspect (who originally worked at the company that
>> produces these devices) write the firmware for this device?

>no :)

>> Did the suspect (who originally worked at the company that
>> produces these devices) have access to the source code
>> and/or hardware design of this device?

>Yes apparently, although to what extent I don't know...

It seems to me that this person doing the actual defrauding would need a
partner inside the manufacturing, servicing or installation department of
the company, in order to get the defraudable chip fitted in place of the
correct one. Presumably the assembled code is kept on some company server
ready for downloading into the blank chips. Has anyone verified this has not
just been replaced by a hex file assembled elsewhere, but with the same file
name, to get around whatever version the company has in place (or may not
even have). This would imply possible access to someone elses logon to get
write permission to the appropriate directory, and also that a copy of the
company source code was loaded onto some media to take home and modify and
assemble.

So who are his old friends in the company?

Are they likely to be able to report the status of any investigation?

maybe I am being paranoid here, but being the sort of person who likes to
look at other peoples code to see how they got around something, I like to
think along these lines about my code.

>> This person has defrauded identical machines at a number of locations...
>> I know of at least 3 and that's only the ones where enough was taken to
>> actually catch someone's attention.

>Make that 11 separate devices so far...

So is this all one person, or a group of people who all know the modus
operandi? How widely separated are the machines? All in one site? If so then
having an accomplice in the installation or service department may be
likely, as it may be easier to get the machines checked out at manufacture
with the correct part fitted, and then the defraudable part fitted during
installation. How widely available were the operational design documents for
the individual modules of the system? Who ever designed the modified code
must have had an excellent insider knowledge of the system to come up with
the design of a method of defrauding it.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@080726 by Olin Lathrop

face picon face
> If you've got typical crappy security footage can you/would it help to
> do something about that, maybe be a little patient and gather better
> evidence. Obviously the footage is good enough to ID the user. but
> you might be missing the discretest action

It sounds like you've gotten about as much information as you can by
watching this guy.  Time to haul this clown down to the police station and
give him a grilling.  Chances are he'll spill the beans if he thinks he's
saving himself from serious jail time.  He doesn't have to know you really
don't have proof yet.  Just the fact that you know it's him may scare him
into thinking you know a lot more than you do.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@082009 by Dave VanHorn

flavicon
face
Ok, whatever is happening, is happening on the inputs.
What are the input devices, presumably a coin mech switch, and some
buttons/knobs/levers.
Any other possible inputs, like IR sensors for coin drop?
IR devices might make a visible flash in the security camera, but that
depends on view angle.

I'm making the assumption that there isn't any hardware in the box, that
shouldn't be there.

Given the above, it's either accidental, (a bug or test code that got left
in) or deliberate.
Given 30k machines, probably a million plus uses, so anything that can
happen, should have happened.
Possibly someone noticed that "when I do this, that, and then this, I get
money".

It's pretty hard to spoof a coin mech, unless someone did something stupid
like use a hall effect switch.
The good old microswitch with wire lever, is tried and true.

Do you see any physical signs, scratches or marks where they are unusual?

Re-assemble the source, with various debug options on and off, and see what
the resulting binary looks like.
Possibly you can set up an automated way to generate all the combinations,
and pick off the ones that generate the same or similar sized hex for
closer examination.
Of course the source that made that machine may not be what you have, but
if you  can't find a combination that matches up, then you'll know that for
sure.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@133154 by William Couture

picon face
If this is a coin mechanism, can it distinguish between
different coins?  How does it handle slugs (or
unidentifiable coins)?

I'd look for something like:
  if (coin_type == SPECIAL_SLUG)
     {
     reject_coin();
     add_x_to_value();
     }

(though I'd hide it better).  With that code, the slug
never winds up in the coin bin to give the trick away, and
a arbitrary number of slugs gives you an arbitrary value.

Bill

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@144115 by Dave VanHorn

flavicon
face
At 10:27 AM 1/29/2004 -0800, William Couture wrote:
>If this is a coin mechanism, can it distinguish between
>different coins?  How does it handle slugs (or
>unidentifiable coins)?

Coin mechs aren't that smart.
At best, it's Slug (reject, I never see it) or sorted to demominations.

It's possible this rig uses something new and smarter, but when I did
vending, that's all you got.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@144951 by Walter Banks

picon face
It is unlikely the sequence is complicated. In game projects the buried copyright sequences were often implemented as a simple state machine. To activate the code a number of events had to pass in order based on totally ordinary operations.

w..


Liam O'Hagan wrote:
>
> just the once...
>
> > {Original Message removed}

2004\01\29@161831 by Liam O'Hagan

flavicon
face
It's 100% definately on the cash input side...

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@162836 by Liam O'Hagan

flavicon
face
I have only got the source to one binary, the binary which is supposed to be
in the device. The compilation switches are all set by the manufacturer. The
binary that is in the device has no source, the manufacturer cannot explain
where the code changes have come from.

I've used a diff tool to view the disassemblies side by side, but the sheer
volume of changes makes it not very worthwhile.

> {Original Message removed}

2004\01\29@164118 by Ken Pergola

flavicon
face
Liam O'Hagan wrote:

> ...the manufacturer cannot explain where the code changes have come from.

Hi Liam,

Has the company verified that the units are actually shipping with the
correct binaries (hopefully with a few other 'trusted' people that normally
do not perform this job)? I write 'trusted' because you really can't trust
anybody.

Maybe an inside job is still going on altering the binaries.

Regards,

Ken Pergola

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@165329 by Liam O'Hagan

flavicon
face
The binary that the manufacturer has on their server, which they thought was
assembled from the source code they have, doesn't match...

At some stage in the 12 or so years since the code was written, someone has
modified the binary, and nobody has noticed. That binary has been written to
every subsequent device produced by that manufacturer. Hence is has the
potential to be a very widespread major problem.

The person workd for the company between when the code was written, and now,
so they would have had the opportunity to change it.

The devices defrauded (or the ones we know about) are spread at a number of
different locations, and all serviced by different technicians, so tht
pretty much rules out that avenue of investigation. The one person is
responsible for defrauding the whole lot, because the aliases they use are
very similar and they have been identified from video surveillance footage
each time (after the horse has bolted so to speak)

> {Original Message removed}

2004\01\29@165742 by Liam O'Hagan

flavicon
face
Yes a coin mechanism, but no other buttons or switches...It's a very tried
and tru coin mechanism used in the industry for many many years but a
variety of manufacturers without incident.

It also has a couple of IR sensors to detect the coin (including direction)
as it falls through, but these are not visible or accessible from outside
the machine. All the common coin defraud options like stringing and yoyoing
have been verified to not do anything out of the ordinary. These are
standard tests for every device of this type. No extra hardware, no vidible
evidence of tampering.

The only unusual thing discovered to date is the different binary.

> {Original Message removed}

2004\01\29@170157 by Liam O'Hagan

flavicon
face
The coin acceptance is very accurate, based on size, weight, shape, etc

It isn't a special coin as he doesn't retrieve the coins he enters, they
enter a device from which coins are paid out, but rarely the same ones that
are entered, and no unusual coins have been found in the "holding area"

> {Original Message removed}

2004\01\29@170821 by Liam O'Hagan

flavicon
face
very much smarter than that these days...

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@171204 by Liam O'Hagan

flavicon
face
The manufacturer has been programming every device they ship with the
incorrect binary since soem time in the past when it was modified. Nobody
knows when that happened, but it could be anytimg in the last decade...

They have verified that the device I have here contains the modified binary,
and they have confirmed that the same binary has been installed on every
device they ship!

> {Original Message removed}

2004\01\29@172032 by Dave VanHorn

flavicon
face
>
>The person workd for the company between when the code was written, and now,
>so they would have had the opportunity to change it.

Interesting.

Sounds like a firmware update is in the cards.
For all you know, all of them are infected, and nothing stops this guy from
telling others about it, other than he doesn't want to get his cash cow killed.
If he thinks you might be onto him, he might write it in a bathroom
somewhere, hoping to get lost in the confusion.

I'd bet on something like Button,coin,button,coin,button,coin.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@172035 by Dave VanHorn

flavicon
face
At 09:08 AM 1/30/2004 +1100, Liam O'Hagan wrote:
>very much smarter than that these days...

Ok. If the output is anything more than coin or slug (why would you want to
know about slugs anyway?) then that's another possible input device.

I think you said earlier, the thing only accepts one denomination, so does
the machine see it as basically a contact closure, or "1 coin" signal, or
does the machine get more information than that?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@173112 by Liam O'Hagan

flavicon
face
The coin input device accepts or rejects coins, if it accepts a coin it
takes the output signal low for a specific period of time, if it rejects
then nothing.

The device in question notices the signal from the coin acceptor, and waits
for a specific time period to see that coin pass its own sensors. If it
passes within the specific time, it sends a valid coin signal to the host
device.

If the coin doesn't pass in the required time, or it passes only one sensor,
or it passes the sensors in the incorrect direction (and another dozen or so
.... or's...) it sends a specific error signal to the host device.

Somehow, this person, from a position exernal to the device, manages to get
the device in question to send approx 10 valid coin signals for every coin
entered. That's where the modified binary may come into it. The host device
is different in all cases so it can be discounted...

The only legitimate input this person has is the entry of coins.
Illegitimate input such as EMI, static discharge, RF, magnetic etc has been
evaluated and discounted, nobody has tried ultrasound yet, but that's
heading towards a big investment on this person's part for a relatively
small return.

That's about all I can say on this issue. Hopefully I'll be able to disclose
a bit more after it has been resolved and the manufacturer has retrofitted
the affected devices.

> {Original Message removed}

2004\01\29@173322 by Andrew Warren

flavicon
face
Liam O'Hagan <@spam@PICLISTspam_OUTspammitvma.mit.edu> wrote:

> The binary that the manufacturer has on their server, which they
> thought was assembled from the source code they have, doesn't
> match...
>
> At some stage in the 12 or so years since the code was written,
> someone has modified the binary, and nobody has noticed. That
> binary has been written to every subsequent device produced by that
> manufacturer.

Liam:

If the program was written in a high-level language like C, the
difference between the original and the modified source might be much
smaller than it appears from your side-by-side comparisons of
assembly-language disassemblies.

It would make sense for the changes to be small; after all, the
chance of the modification being discovered -- through the
introduction of a bug, or through a noticeable change in the "normal"
behavior of the modified code as compared to the original -- would
increase as more of the original code was changed.

Does the manufacturer have both the original source code AND a copy
of the particular version of the compiler that was used 12 years ago
to create the original binary?  Does the manufacturer have, or have
access to, all versions of the compiler available prior to your
suspect's leaving the manufacturer's employ?

It's worth doing some experimentation, I think, to see whether the
large differences between the two binaries are just the result of
compiling the program with two different compiler versions (or two
different sets of compilation switches or compiler libraries).  You
may find that when you get the original source compiled with exactly
the right compiler and compiler settings, the output binary will just
snap into alignment with the modified binary you took from the
machine on your desk... With the exception of a few lines that
clearly show how the machines are being cheated.

Good luck...

-Andy

=== Andrew Warren -- .....aiwspam.....cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@173607 by Olin Lathrop

face picon face
Liam O'Hagan wrote:
> The binary that the manufacturer has on their server, which they
> thought was assembled from the source code they have, doesn't match...
>
> At some stage in the 12 or so years since the code was written,
> someone has modified the binary, and nobody has noticed. That binary
> has been written to every subsequent device produced by that
> manufacturer. Hence is has the potential to be a very widespread
> major problem.

How much code are we talking about?  What PIC?

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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@174231 by Liam O'Hagan

flavicon
face
It's written in assembly, and we can't be sure that the manufacturer hasn't
implemented legitimate changes or bug fixes and forgotten to update the
source in their source safe. I'm using the original compiler that they have
used (only one version has ever been used). The problem is that the last
time someone legitimately compiled this device was ~10 years ago!

I'm currently investigating whether the input pulse from the coin acceptor
can be modified in terms of duration..

> {Original Message removed}

2004\01\29@174441 by Liam O'Hagan

flavicon
face
It's a Zilog Z86, 1k of code

> -----Original Message-----
> From: Olin Lathrop [SMTP:spamolin_piclistKILLspamspamEMBEDINC.COM]
> Sent: Friday, January 30, 2004 9:34 AM
> To:   RemoveMEPICLISTRemoveMEspamMITVMA.MIT.EDU
> Subject:      Re: [PIC:] Disassemblers
>
> Liam O'Hagan wrote:
> > The binary that the manufacturer has on their server, which they
> > thought was assembled from the source code they have, doesn't match...
> >
> > At some stage in the 12 or so years since the code was written,
> > someone has modified the binary, and nobody has noticed. That binary
> > has been written to every subsequent device produced by that
> > manufacturer. Hence is has the potential to be a very widespread
> > major problem.
>
> How much code are we talking about?  What PIC?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@174648 by Jinx

face picon face
> nothing stops this guy from telling others about it, other than he
> doesn't want to get his cash cow killed

If/when he does get prosecuted, having told others would probably
mean more charges. Conspiracy to defraud at least

It's risky hauling him in for questioning. He *might* put his hands
up, but if he's got anything significant going on in the testicular
department, he'll just fold his arms and "no comment". Then
you're screwed and back to square one

> I'd bet on something like Button,coin,button,coin,button,coin.

I'd bet on that too. If it's not the machine being fooled by anything
you can physically recover or examine it must be something that
he's doing. Better surveillance has to be an option. Given that
there could be an unknown, possibly large, number of shady units
out there, surely there must be some economic incentive to get
useable evidence. Look at the costs they're looking at to replace
f/w for a start (and what price reputation/public confidence if this
got out ?)

Even if by fluke amongst the millions of operations someone else
did stumble across his method, would they necessarily realise what
had happened and capitalise on it ? Could have been anyone. And
could that one lucky transaction have been seen as a "glitch" and
ignored ?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@175857 by Alexander JJ Rice

picon face
       Crumbs, i'd _pay_ good money to be given a problem like this to solve -
it's like the magicians locked box mystery, all i can say is that once you
do find it it will be tremendously satisfying - that feeling the first
time you manage to duplicate the trick ... ahh, engineering bliss!
       I would try to imagine what _you_ would do if you wanted to defraud this
particular machine, it very likely to be somehting simple with a low
chance of detection but also a low chance of accidental activation - it
seems unlikely that it is any sort of physical hack, as people have
mentioned it seem hugely more likely that it is some special sequence of
events. One way would be to 'brute force' that special combination by
simulating select parts of the code - like the bit that adds up the money
entered and the bit that deals with coin return and the keypad and then
feed random data into them and have some simple code that parses the
results looking to see if the amount of 'money' recorded differs from the
amount of money 'entered' and just let it run until it happens. If this
fails then statistically analysing whatever code didn't get run must
surely reveal the trick.
       Alternatively, based on the assumption that there is some sort of timing
loop involved look for ram registers that seem to increment all the time -
whatever it is must be in software if all they had to do to activate the
trick was to alter the binary.  The other thing you mentioned is that when
the trick is active the money that is put in is multiplied by some
constant - well, look for multiply routines, look for groups of rlf
instructions - by the sound of it you machine should mustly be adding
numbers rather than multiplying them together so it shouldnt be too
difficult to spot. From there it should be possible to back-track to find
how the code gets to that point - even if the entry code is something
complex like a function of time, date. money entered etc.
       Other possibility if all else fails would be the 'trust' attack - phone
him/her up claiming to be an employee who has seen him pull this trick and
say you will expose him/her if they don't let you in on the trick.

I think once you find the trick you will be obliged to tell us roughly how
it was done and how you tracked it down for fear of becoming a list pariah
as a result of all us slavering code monkeys desperation! Alternativley
you could keep one 'altered' machine at a private location - or pass round
the code so we can all have a go!


Best of luck

Alex Rice

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@180311 by Olin Lathrop

face picon face
Liam O'Hagan wrote:
> It's a Zilog Z86, 1k of code

If it's just 1K of code, it shouldn't take all that long to start with a
dissassembly listing and end up with commented source code, especially since
the original source code is still available to answer a lot of questions.
Just dig in and do it.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@180931 by Liam O'Hagan

flavicon
face
Here's an example of the disassembled code (from the "good" code, not the
potentially "bad" code)

       ld      (bc),a  ; 0000  02              .
       call    c,Xdc02 ; 0001  dc 02 dc        \.\
       ld      (bc),a  ; 0004  02              .
       call    c,Xdc02 ; 0005  dc 02 dc        \.\
       ld      (bc),a  ; 0008  02              .
       db      0ffddh,3        ; 0009  dd 03           ].
;
       rrca                    ; 000b  0f              .
       and     0ffh            ; 000c  e6 ff           f.
       add     a,b             ; 000e  80              .
       ld      sp,#STACK       ; 000f  31 00 e6        1.f
       ret     m               ; 0012  f8              x
       dec     b               ; 0013  05              .
       and     2               ; 0014  e6 02           f.
       ld      c,0e6h  ; 0016  0e e6           .f
       or      0c0h            ; 0018  f6 c0           v@
       and     0f7h            ; 001a  e6 f7           fw
       ld      bc,Xf5e6        ; 001c  01 e6 f5        .fu
       dec     c               ; 001f  0d              .
       and     0f4h            ; 0020  e6 f4           ft
       jp      m,Xf3e6 ; 0022  fa e6 f3        zfs
       ccf                     ; 0025  3f              ?
       and     0f2h            ; 0026  e6 f2           fr
       jp      m,Xf1e6 ; 0028  fa e6 f1        zfq
       inc     bc              ; 002b  03              .
       and     0f9h            ; 002c  e6 f9           fy
       add     hl,bc           ; 002e  09              .
       and     0fbh            ; 002f  e6 fb           f{
       jr      nc,X008f        ; 0031  30 5c           0\
       ld      a,a             ; 0033  7f              .
       or      c               ; 0034  b1              1
       push    hl              ; 0035  e5              e
       nop                     ; 0036  00              .
       push    hl              ; 0037  e5              e
       db      0ffddh,0        ; 0038  dd 00           ].
;



> {Original Message removed}

2004\01\29@181554 by Mike Harrison

flavicon
face
>The only legitimate input this person has is the entry of coins.
>Illegitimate input such as EMI, static discharge, RF, magnetic etc has been
>evaluated and discounted, nobody has tried ultrasound yet, but that's
>heading towards a big investment on this person's part for a relatively
>small return.

I would say that completely discounting _anything_, however improbable,  is risky. Just because you
can't find a way to break it doesn't mean there isn't a way that you haven't thought of.
You should also not make assumptions about the investment - a determined amateur can achieve a  lot,
and almost any hardware can be picked up cheap if you know where to look.

A good example of this is smartcards, where early ones were designed with the assumption that
hackers would not have access to wafer-probes and electron microscopes, Then some student does a bit
of moonlighting at his college.....

One mistake people make when designing 'secure' systems is that they forget that there will often be
many more man-hours trying to break the system than creating it.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@181555 by Liam O'Hagan

flavicon
face
Hit send a bit soon whoops!

What I meant to say is that the disassembly appears a bit buggered, some of
the mnemoncs are meant to have 2 operands and they only have one for
instance.

> {Original Message removed}

2004\01\29@182139 by Jinx

face picon face
> It's a Zilog Z86, 1k of code

Are there parts of the code that just won't disassemble or look
strange ? It's my understanding that the Z8x has many undoc-
umented op-codes which, without a disassembler written to do
so, might not be reverse-engineerable back to readable code.
For example, every disassembler I've used with 6502 code will
show ??? for any undocumented op-code and it would be easy
to assume these ??? are embedded data or unimplemented
code space. I've used these instructions occassionally to make
snooping difficult and mislead hackers

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@182802 by Mike Harrison

flavicon
face
On Thu, 29 Jan 2004 18:02:26 -0500, you wrote:

>Liam O'Hagan wrote:
>> It's a Zilog Z86, 1k of code
>
>If it's just 1K of code, it shouldn't take all that long to start with a
>dissassembly listing and end up with commented source code, especially since
>the original source code is still available to answer a lot of questions.
>Just dig in and do it.
>

several years ago I was involved in reverse-engineering comms protocols from disassemblies of
typically 32-64K of code. I found that by writing my own disassembler, I could add some simple but
useful features to help figure things out - e.g. labelling all the I/O operations, assigning
symbolic names to RAM locations - even simple things like putting a newline after every jump or
return to make breaks in the flow more obvious. A lot of this is very simple if you're writing a disassembler for a single job - as you discover the
functions of various parts, you can add symbols and re-disassemble it  to get a more meaningful
listing.

It usualy took me about 1-2 days to write a disassembler from scratch (in interpreted BASIC it
doesn't have to be fast or pretty!), although if it's only 1K I'm not sure it would be worth even
that - 1K is really not much code to understand, especially if it wasn't deliberately written to be
obfuscated.


 
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@183011 by Russell McMahon

face
flavicon
face
> Here's an example of the disassembled code (from the "good" code, not the
> potentially "bad" code)
>
>         ld      (bc),a  ; 0000  02              .
>         call    c,Xdc02 ; 0001  dc 02 dc        \.\
>         ld      (bc),a  ; 0004  02              .
>         call    c,Xdc02 ; 0005  dc 02 dc        \.\
>         ld      (bc),a  ; 0008  02              .
.........


Without even trying to understand any of that, it isn't utterly daunting.
Assuming your disassembler is "synced in" it should produce good code. If
it's not then that could explain some differences. If you have data
scattered through the code a 'dumb" disassembly will run through data blocks
as if they are code. When you exit the data block it may at first not be in
sync and make a further mess of the result. A bit of low level digging will
show if this is happening. 1K is not a vast amount of code to rebuild by
hand.

I'm presently trying to fit new code into a 1K Zilog device (Z8PE003) to
upgrade functionality of an existing product.

Every now and then a client gets me to update a 16k odd 8051 program for a
device that he paid money to have the code written for but only has
uncommented source code available for. (In this case the variables have
meaningful alpha English names, but they were written by a Taiwanese
programmer :-) ).

Reverse engineering is entirely doable - just annoying. There's a fair
chance that an intelligent comparison would allow gross functionality
changes to be determined relatively easily.





       Russell McMahon

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@183012 by Mike Harrison

flavicon
face
On Fri, 30 Jan 2004 10:17:18 +1100, you wrote:

>Hit send a bit soon whoops!
>
>What I meant to say is that the disassembly appears a bit buggered, some of
>the mnemoncs are meant to have 2 operands and they only have one for
>instance.

Are you sure the disassembler hasn't just got out of step - this can happen on processors where data
is embedded in the code (unlike on PICs) - this is a common on many architectures.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@183347 by Mike Harrison

flavicon
face
>whatever it is must be in software if all they had to do to activate the
>trick was to alter the binary.
As far as I recall it has not yet been positively established that the code has actually been
tampered with (correct me if I'm wrong), and the differences could be down to legitimate
undocumented changes,

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@184215 by Liam O'Hagan

flavicon
face
Can anyone tell me where the "bc", "a" and "h" etc are defined?

The zilog user's manual and datasheet for the device don't explain what they
are, neither does the source code I have.

They are from the disassembled code obviuously, but do they represent
specific registers. The example code that came with the disassembler used
them extensively so I gather they are some sort of standard register naming.
The source I have uses a different naming convention though and I'd like to
be able to correlate the two...

Thanks in advance!

> {Original Message removed}

2004\01\29@185251 by Liam O'Hagan

flavicon
face
Hrmm there are a few data tables in the source I have. I'll have to get the
disassembler to ignore them, thanks for the help!

> {Original Message removed}

2004\01\29@185914 by Dave VanHorn

flavicon
face
>
>Even if by fluke amongst the millions of operations someone else
>did stumble across his method, would they necessarily realise what
>had happened and capitalise on it ? Could have been anyone. And
>could that one lucky transaction have been seen as a "glitch" and
>ignored ?

I've heard of similar things happening in the point-of-sale and ATM worlds,
from reputable sources (VP at credit card company, president of ATM
manufacturer)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@185915 by Dave VanHorn

flavicon
face
At 10:17 AM 1/30/2004 +1100, Liam O'Hagan wrote:
>Hit send a bit soon whoops!
>
>What I meant to say is that the disassembly appears a bit buggered, some of
>the mnemoncs are meant to have 2 operands and they only have one for
>instance.

In Z-80 code and other families with multi-length instructions, one can put
things in specifically to hose disassemblers.
At verifone, we had a number of those tricks, and an ascii string in the
rom that said, "Nosy little Fucxer aren't you", more or less.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@191158 by Liam O'Hagan

flavicon
face
Sorted those data tables out. I'll have a dig through the source and see if
there are any more data defines...

Finally some progress :D

I'm working through the disassembly of the known code first, then I'm going
apply those same disassembly directives to the didgy code.

> {Original Message removed}

2004\01\29@191404 by Liam O'Hagan

flavicon
face
dodgy even...

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@191746 by Dave VanHorn

flavicon
face
At 12:21 PM 1/30/2004 +1300, Jinx wrote:
> > It's a Zilog Z86, 1k of code
>
>Are there parts of the code that just won't disassemble or look
>strange ? It's my understanding that the Z8x has many undoc-
>umented op-codes which, without a disassembler written to do
>so, might not be reverse-engineerable back to readable code.

Yes it does. I used to write Z8 code.
Anyone need a deal on a pair of Signum emulators?

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@230519 by Liam O'Hagan

flavicon
face
After many hours of fighting the disassember, I've located an OP Code map,
and the output from the disassembler is completely incorrect!

Talk about leading me up the garden path....

Now to write one.

> {Original Message removed}

2004\01\29@231555 by Gaston Gagnon

face
flavicon
face
From my recollection of the Z80, they are registers within the processor:
  a               ;which serve also as accumulator
  b,c,d,e,h,l      ;each may contain one byte
  bc, de, hl      ;each pair may contain a 16bit word
  (bc), (de), (hl) ;each par contain an address for indirect
                   ;addressing purpose.
Exemple:
  ld (bc),a        ; transfer the content of register a at
                   ; the address formed by bc

Gaston Gagnon


Liam O'Hagan wrote:

{Quote hidden}

>>{Original Message removed}

2004\01\29@232842 by Bill Couture

picon face
On Thu, 29 Jan 2004, Mike Harrison wrote:

{Quote hidden}

In "a previous life", I was an anti-virus programmer.  I spent my days
disassembling and analyzing viruses, then writing the detection/removal
for it.

Even before I started that, I had written my own interpreter for the
Intel 80188 (8088 plus a few instructions), and disassembler.  Turned out
to be very handy...

Anyway, let me echo what other people have said -- 1K is not a lot of
code.  It may take you a day or two to go through, but with the help of
the "old" source code, I'll bet it's less work than answering all the
PICLIST'ers questions.

Bill

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@233046 by Dave VanHorn

flavicon
face
At 03:06 PM 1/30/2004 +1100, Liam O'Hagan wrote:
>After many hours of fighting the disassember, I've located an OP Code map,
>and the output from the disassembler is completely incorrect!
>
>Talk about leading me up the garden path....
>
>Now to write one.

I've never seen a Z8 disassembler, but I haven't looked that hard.
You weren't trying to run a Z-80 disassembler on it, were you?
That would be bad.  Many people confuse the two, but the only thing they
have in common, is Zilog.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@233252 by Dave VanHorn

flavicon
face
>
>Anyway, let me echo what other people have said -- 1K is not a lot of
>code.  It may take you a day or two to go through, but with the help of
>the "old" source code, I'll bet it's less work than answering all the
>PICLIST'ers questions.

Holler if you need Z8 help, I think I can throw some liquid wrench on that
part of my brain.
:)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@233253 by Liam O'Hagan

flavicon
face
Thanks Gaston

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@235951 by Edward Gisske

flavicon
face
----- Original Message -----
From: "Dave VanHorn" <dvanhornTakeThisOuTspamCEDAR.NET>
To: <.....PICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Thursday, January 29, 2004 6:14 PM
Subject: Re: [PIC:] Disassemblers

> Yes it does. I used to write Z8 code.
> Anyone need a deal on a pair of Signum emulators?
>
I will trade you for my Signum S-100 8048 CPM based emulator card....

Ed

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\30@013331 by William Chops Westfield

face picon face
On Thursday, Jan 29, 2004, at 15:44 US/Pacific, Liam O'Hagan wrote:

>
> Can anyone tell me where the "bc", "a" and "h" etc are defined?
>
> The zilog user's manual and datasheet for the device don't explain
> what they
> are, neither does the source code I have.
>
>
BC, A, and H are standard register names for a Z80 style processor.
Is the "z86" you mention a Z80 variant, or a Z8 (entirely different
architecture!  Perhaps more than one!) of some kind?

That is, I think perhaps you have the wrong dissassembler...

(how does the dissassembled version of the binary that matches the
source you have look, compared to the source.)

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@050639 by Brian Clewer

flavicon
face
Liam wrote some time ago...

> The reason I ask, is that we (as a 3rd party) test certain devices which
> handle large quantities of money, and someone has recently
> discovered a way
> to remove more money from these devices that he or she is entitled to...
>


Forgive me if I mention anything said before, as I have just picked up this
thread.

One way of finding out what the access sequence is is to put a known good
processor along side the known bad one.  Feed them with exactly the same
input signals and put the device in service running with the bad code.
Record all the data from the input signals and when there is a difference of
opinion, you have the data you need to catch the guy.  You could also use
your camera with a time stamp and have an RTC built into the device so you
then have evidence this was the guy that stole the money, especially if you
see him do it more than once.

Brian.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@051924 by

picon face
> It's a Zilog Z86, 1k of code

But then, why the [PIC] tag ?

Jan-Erik.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@054912 by Russell McMahon

face
flavicon
face
> > It's a Zilog Z86, 1k of code
>
> But then, why the [PIC] tag ?

I'd say (fwiw):

- The original query was couched in PIC related terms.

- It's closer to a microcontroller programming rather than EE topic and
there are no other tags that fit better than these two. A significant
proportion of people on this list who are liable to provide valuable input
would be PIC people - even if it uses an arcane device instead of a PIC :-)


       RM

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@063632 by Mike Harrison

flavicon
face
On Fri, 30 Jan 2004 23:48:55 +1300, you wrote:

>> > It's a Zilog Z86, 1k of code
>>
>> But then, why the [PIC] tag ?
>
>I'd say (fwiw):
>
>- The original query was couched in PIC related terms.
>
>- It's closer to a microcontroller programming rather than EE topic and
>there are no other tags that fit better than these two. A significant
>proportion of people on this list who are liable to provide valuable input
>would be PIC people - even if it uses an arcane device instead of a PIC :-)

Pretty much all the (very interesting) issues under discussion would be exactly  the same if it were
based on a PIC, except maybe disassembler slippage....!

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@090845 by Alan B. Pearce

face picon face
> >If it's just 1K of code, it shouldn't take all that long to start with a
> >dissassembly listing and end up with commented source code, especially
since
> >the original source code is still available to answer a lot of questions.
> >Just dig in and do it.

back when Microprocessors were young (more years than I care to remember)
and such things as word processors were only available to management PA's, I
used to disassemble code by hand, using a ruled sheet that I photocopied. It
had a columns for address, a single byte opcode, operand, mnemonic, and
comment. I would write all the opcodes into the opcode column, then start at
the beginning disassembling. Where there was a multibyte instruction then a
bracket was put across the bytes, and the necessary operand written by the
first byte.

Nowadays I would use a spreadsheet to do the same thing, with the advantage
that the opcodes and address could be electronically loaded. A printout of
the opcode list and it does not take long to disassemble anything, 1k of
code really is an evening in front of the telly. Working out what the code
then does is for the next day at the workbench :)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamlistserv@spam@spammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@105258 by Bob Ammerman

picon face
> > How much code are we talking about?  What PIC?

> It's a Zilog Z86, 1k of code

Good grief, I could completely disassemble that with full comments given the
hardware setup in not more than a day or three!

Bob Ammerman
RAm Systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@155450 by Peter L. Peres

picon face
Imho, look for subliminal channels. Such as, the time between putting in
two successive coins, or coding based on the time between successive coins
put in and/or denominations put in, and more like this. Maybe he needs to
spend 5 dimes to get 'lucky' afterwards and get 10 back.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistserv@spam@spamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@160525 by Peter L. Peres

picon face
> Can anyone tell me where the "bc", "a" and "h" etc are defined?

They are cpu register names and probably defined inside the compiler. You
can probably get at them by compiling a source file containing just and
end directive. The symbol file generated should contain them (it does for
MCS51 compatible tools).

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservRemoveMEspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@170906 by John N. Power

flavicon
face
> From:         Peter L. Peres[SMTP:plpTakeThisOuTspam@spam@ACTCOM.CO.IL]
> Sent:         Friday, January 30, 2004 4:00 PM
> To:   PICLISTTakeThisOuTspamspamBeGoneMITVMA.MIT.EDU
> Subject:      Re: [PIC:] Disassemblers

>> Can anyone tell me where the "bc", "a" and "h" etc are defined?

> They are cpu register names and probably defined inside the compiler. You
> can probably get at them by compiling a source file containing just and
> end directive. The symbol file generated should contain them (it does for
> MCS51 compatible tools).

> Peter

Those register names are used by the Z80, not the Z8. The Z8 numbers its
registers.

John Power

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\31@084916 by Peter L. Peres

picon face
> Those register names are used by the Z80, not the Z8. The Z8 numbers its
> registers.

Maybe someone used them like this as a paradigm. They should still appear
in the symbol file if they are not defined anywhere in the source, and the
compiler/assembler recognises them. I have tried compiling/assembling an
'empty' source file before, to get at the 'hidden' symbols defined by the
toolchain. They appear in the symbol file, as I said. With C the problem
is harder because some symbols are interpreted by the preprocessor and do
not appear in the symbol file at all, but they should also be missing from
disassembler output, so ...

hope this helps anyway,

Peter

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

.


'[PIC:] Disassemblers'
2004\02\01@171523 by Liam O'Hagan
flavicon
face
Yep, the disassembler I have claims to be a "Z8" disassembler but it turns
out it's for the z80...

Should be sorted soon, I've almost completed the disassembly.

> {Original Message removed}

2004\02\01@194525 by Liam O'Hagan

flavicon
face
The original message was asking if anyone remembered the java based online
disassemblerr for PIC's, and whether anyone knew of a similar tool for Z8's

> {Original Message removed}

2004\02\01@211433 by Dave VanHorn

flavicon
face
At 09:17 AM 2/2/2004 +1100, Liam O'Hagan wrote:
>Yep, the disassembler I have claims to be a "Z8" disassembler but it turns
>out it's for the z80...
>
>Should be sorted soon, I've almost completed the disassembly.

I bet it makes better sense now :)

The Z8 was a nice machine, but it divides the clock by 12! so a 12 MHz Z8
only gets you 1 mips max.
The /12 threw me for a loop the first time I tried to set up a timer, I
couldn't believe that number was right!

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

.

2004\02\02@231241 by Liam O'Hagan

flavicon
face
Disassembly is complete, a small section of code has been added that appears
to utilise some registers that were defined as not used in the source I
have, it also contains a number of rotates left :)

Interesting stuff!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\02\02@231655 by Tom

flavicon
face
So how much longer do I have to make my final cleanout of the machine
before the special "feature" is disabled??? ;>

Tom

At 03:14 PM 2/3/2004 +1100, you wrote:
>Disassembly is complete, a small section of code has been added that appears
>to utilise some registers that were defined as not used in the source I
>have, it also contains a number of rotates left :)
>
>Interesting stuff!
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

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