Detecting an emulator from the inside: some reversing needed

[BigEd]

At least some 6502 system emulators will have some inaccuracy, such that a suitably careful measurement from the inside, using running 6502 code, will be able to detect that it is not running on real hardware.

Mark Pilgrim demonstrated such a piece of code at the 2014 Kansasfest - but all I can find about it is a few screenshots and an Apple ][ disk image. (There's also a link to run the image in an in-browser emulation using JSMess - see here.)

I wonder if anyone is interested in digging in, reverse-engineering the code, and discovering how Mark tackled the challenge.

Quote:

Self-booting disk that can detect if it is running in (known) Apple II emulators.

Presented at the 2014 Kansasfest Apple II convention, this self-booting disk image will detect a number of major emulators. Utilizing differences in the amount of self-sync bytes after the data epilogue, multiple emulators and "real" hardware can be surmised.

I'm guessing that the code uses disk or video timing to detect emulation - I think there's no timer on the Apple II (but I could be wrong.)

[nyef]

BigEd wrote:

Quote:

Self-booting disk that can detect if it is running in (known) Apple II emulators.

Presented at the 2014 Kansasfest Apple II convention, this self-booting disk image will detect a number of major emulators. Utilizing differences in the amount of self-sync bytes after the data epilogue, multiple emulators and "real" hardware can be surmised.

I'm guessing that the code uses disk or video timing to detect emulation - I think there's no timer on the Apple II (but I could be wrong.)

Sounds like disk format emulation differences. "Self-sync bytes" are an FF byte written over ten bit periods (with two leading zeros) on the disk. The disk controller ignores leading zeros during a read, so at some point in a series of five self-sync bytes it will sync up to the actual written bitstream. The data epilogue is a series of three bytes written to the disk after the end of a sector of data (there is also a data prologue and address prologue and epilogue).

Another detection angle might be the Don Lancaster "Vapourlock" system, which relies on the memory access patterns of high-resolution mode combined with reading an unmapped I/O port to obtain the last value on the bus (held due to bus capacitance) to perform raster effects, but I'd imagine that many emulators simply don't match that level of fidelity.

Of course, the next trick would be to tweak an emulator to be detected as real hardware through either method.

[BigEd]

Thanks for those details!

Matt Godbolt's four-part writeup of JSBeeb is worth reading, for those interested in the very fine details of emulation. In the Beeb there's a lot of emphasis on the timers and on the variable-speed clock. To do the same job on the Apple II would presumably mean emphasis on modelling floating busses and the disk I/O.
http://xania.org/Emulation
http://bbc.godbolt.org/

[MattGodbolt]

Oh blimey - thanks for the hat tip I've just discovered this forum and was browsing and then stumbled upon this post. Cheers, Ed

[BigEd]

Glad to see you here Matt - better late than never!
Cheers
Ed

[MattGodbolt]

I'm embarrassed I hadn't found this forum before - it would have really helped in the early stages!

[GARTHWILSON]

MattGodbolt wrote:

I'm embarrassed I hadn't found this forum before - it would have really helped in the early stages!

Make sure you also check out the non-forum part of the website (http://6502.org/). There's a lot there!