Audio Device connection proof

I might add -
The device is not a USB device. It's connected via a regular audio jack to the motherboard or audio card.

Assuming you've had the task to prove a certain audio device was plugged to a PC you investigate - say, a speaker or a microphone. Now, Given the only evidence you can analyze is a dd copy of it's hard drive - How would you approach proving an audio device was connected and what device was it?

Connected how? Not USB, as per your second posting – so how, then? Special PCI card with customer connection? Wireless? Bluetooth? Or … again, analog copper? (You must be pulling my leg.)

1. Examine the driver and driver-related specifications for the device. If the device talks any kind of protocol, that's what you want to go for. If that protocol contains any identification data … take it from there.

2. If it doesn't, but just talks raw analog (or possibly digital) audio signals over a copper connector, I'll mount a multi-year research project with the goal to determine if physical connectors of these devices leave traces on connection – a bit like ballistics fingerprinting.

In other words, if the device doesn't talk protocol, you can almost certainly give up. There is unlikely to be anything that identifies the device. (But again, if you want to make 100% sure, you go for the device driver source code, how it talks to the device, and how it talks to the operating system. The audio card just might measure various electrical parameters for auto configuration, and they can be used for fingerprinting. But don't get your hopes up …)

Assuming you've had the task to prove a certain audio device was plugged to a PC you investigate - say, a speaker or a microphone. Now, Given the only evidence you can analyze is a dd copy of it's hard drive - How would you approach proving an audio device was connected and what device was it?

Connected how? Not USB, as per your second posting – so how, then? Special PCI card with customer connection? Wireless? Bluetooth? Or … again, analog copper? (You must be pulling my leg.)

1. Examine the driver and driver-related specifications for the device. If the device talks any kind of protocol, that's what you want to go for. If that protocol contains any identification data … take it from there.

2. If it doesn't, but just talks raw analog (or possibly digital) audio signals over a copper connector, I'll mount a multi-year research project with the goal to determine if physical connectors of these devices leave traces on connection – a bit like ballistics fingerprinting.

In other words, if the device doesn't talk protocol, you can almost certainly give up. There is unlikely to be anything that identifies the device. (But again, if you want to make 100% sure, you go for the device driver source code, how it talks to the device, and how it talks to the operating system. The audio card just might measure various electrical parameters for auto configuration, and they can be used for fingerprinting. But don't get your hopes up …)

So basically, If we're talking about analog copper - It's a lost battle then.
Best case scenario with analog copper - I can tell a certain audio device was using "this and that" driver via the releveant registry entry and tell the date the entry was updated by the key's timestamp?
Or is there any other info I might be able to dig into?

Joe.

2. If it doesn't, but just talks raw analog (or possibly digital) audio signals over a copper connector, I'll mount a multi-year research project with the goal to determine if physical connectors of these devices leave traces on connection – a bit like ballistics fingerprinting.

Nice research project wink , though I am afraid that - if successful - it will prove at the most that device (actually jack) was connected, not if the device was on (think of external amplified speakers with switch and volume knob or any mic with a switch).

jaclaz

Best case scenario with analog copper - I can tell a certain audio device was using "this and that" driver via the releveant registry entry and tell the date the entry was updated by the key's timestamp?

That, of course, will probably depend on the specific driver. I imagine the 'standard scenario' is pretty much as you state, and that most, perhaps all, Microsoft-provided drivers do it that way.

What the particular driver does … is another research project. It may misbehave …
indeed some early Windows drivers I remember did nothing but misbehave …

It may misbehave …
indeed some early Windows drivers I remember did nothing but misbehave …

… indeed some early Windows I remember did nothing but misbehave… wink

jaclaz

I think there are registry artifacts in some cases, maybe this could help

https://msdn.microsoft.com/en-us/library/dd370810(v=VS.85).aspx