---- START NEW MESSAGE --- Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-8.05) id ADF7136A0218; Wed, 28 Jan 2004 19:28:55 -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 <9.00CC1D1D@cherry.ease.lsoft.com>; Wed, 28 Jan 2004 22:13:17 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 4047 for PICLIST@MITVMA.MIT.EDU; Wed, 28 Jan 2004 22:13:08 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 4972; Wed, 28 Jan 2004 22:11:10 -0500 Received: from mta11.adelphia.net [68.168.78.205] by mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with SMTP ; Wed, 28 Jan 2004 22:11:09 EST X-Comment: mitvma.mit.edu: Mail was sent by mta11.adelphia.net Received: from cowshed.8m.com ([69.161.133.142]) by mta11.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040129031112.ZOCR11898.mta11.adelphia.net@cowshed.8m.com> for ; Wed, 28 Jan 2004 22:11:12 -0500 Received: from ayrshire (ayrshire [192.168.1.10]) by cowshed.8m.com (8.9.3/8.9.3) with ESMTP id WAA21852 for ; Wed, 28 Jan 2004 22:39:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Message-ID: <000401c3e615$45394a30$0a01a8c0@ayrshire> Date: Wed, 28 Jan 2004 22:09:12 -0500 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Anthony Toft Subject: Re: [PIC:] Disassemblers To: PICLIST@MITVMA.MIT.EDU In-Reply-To: <2193429B07D9914D97216EBBAA6AB8BD1A04F3@whitlam.corp.gli.com.au> Precedence: list X-RCPT-TO: Status: U X-UIDL: 371856191 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----- > From: pic microcontroller discussion list > [mailto:PICLIST@MITVMA.MIT.EDU] On Behalf Of Liam O'Hagan > Sent: Wednesday, January 28, 2004 9:41 PM > To: PICLIST@MITVMA.MIT.EDU > Subject: Re: [PIC:] Disassemblers > > > 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----- > > From: Russell McMahon [SMTP:apptech@PARADISE.NET.NZ] > > Sent: Thursday, January 29, 2004 1:25 PM > > To: PICLIST@MITVMA.MIT.EDU > > Subject: Re: [PIC:] Disassemblers > > > > > 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 > > -- > 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 -- 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 .