---- START NEW MESSAGE --- Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-8.05) id A104437B007A; Thu, 29 Jan 2004 16:10:44 -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 <12.00CC3A59@cherry.ease.lsoft.com>; Thu, 29 Jan 2004 18:55:04 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 5397 for PICLIST@MITVMA.MIT.EDU; Thu, 29 Jan 2004 18:54:58 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 8715; Thu, 29 Jan 2004 18:53:09 -0500 Received: from pd3mo1so.prod.shaw.ca [24.71.223.10] by mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with ESMTP ; Thu, 29 Jan 2004 18:53:09 EST X-Comment: mitvma.mit.edu: Mail was sent by pd3mo1so.prod.shaw.ca Received: from pd4mr4so.prod.shaw.ca (pd4mr4so-qfe3.prod.shaw.ca [10.0.141.215]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HS900H08ZBT1F@l-daemon> for PICLIST@MITVMA.MIT.EDU; Thu, 29 Jan 2004 16:45:29 -0700 (MST) Received: from pn2ml3so.prod.shaw.ca (pn2ml3so-qfe0.prod.shaw.ca [10.0.121.147]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HS90074ZZBTW8@l-daemon> for PICLIST@MITVMA.MIT.EDU; Thu, 29 Jan 2004 16:45:29 -0700 (MST) Received: from UALBERTA.ca (h24-65-14-55.ed.shawcable.net [24.65.14.55]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0HS900K06ZBS2V@l-daemon> for PICLIST@MITVMA.MIT.EDU; Thu, 29 Jan 2004 16:45:29 -0700 (MST) MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <2193429B07D9914D97216EBBAA6AB8BD1A0522@whitlam.corp.gli.com.au> Message-ID: <40199B2E.42FAAFDC@UALBERTA.ca> Date: Thu, 29 Jan 2004 16:45:50 -0700 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Robert Rolf Organization: U of Alberta Subject: Re: [PIC:] Disassemblers KISS or not To: PICLIST@MITVMA.MIT.EDU Precedence: list X-RCPT-TO: Status: U X-UIDL: 371856381 Liam O'Hagan wrote: > This device doesn't work quite like that, you put in money, spend some of > it, and refund the rest. So does he have control of how much is spent each time (betting I assume)? If so, he just has to bet the right values in the right sequence to trigger the payout. Look for code sequences that compare RAM variables to an imbedded constant. > The limit that you can put in is many thousands of dollars, we've watched > the footage and can see that he puts in no more than $40... Is he appear to be putting in the same amount each time? Does he frequent a particular batch of machines (geographical area) that you could add a data logger to record his inputs and outputs? > The code has been shifted around a fair bit but there are also large blocks > of code that are comepletely different. With only 1k of bin, it shouldn't be that hard to just do the disassembly. I've done 6k of Z80 with CP/M "Resource" in about 3 days to find a timing bug on a Summagraphics digitizing tablet (extra strobe the was causing bad data transfer when attached to a damn fast interface). Sounds like the diassembler you're using has problems ('meant to have two operands but only have one' comment). It also looks like it's way out of sync. The disassembled code looks 'stupid' in places. e.g. > push hl ; 0035 e5 e > nop ; 0036 00 . > push hl ; 0037 e5 e > db 0ffddh,0 ; 0038 dd 00 ]. > does nothing useful, especially when you have a DB 0xxxx embedded in the flow. One trick that I've seen used is to put a random bytes at the end of every return instruction to cause disassemblers to loose sync, as yours has. You have to go though and label every apparent call reference to see if it makes sense, then restart the disassembly. Resource was really good at this. I sure looks like your fastest bet is going to be an emulation of the buggered code with a long trace buffer to figure out what is 'real' and what is giggersish from sync loss. R -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. .