How to inspect the contents of /dev/sdt?

I have what I hope is not a huge problem, but could end up being a very large problem.

For some context, I mistakenly ran this command on my 27'' iMac:

sudo dd if=ubuntu-rescue.img of=/dev/sdt bs=1m

after which, it gave me the following output:

233+1 records in
233+1 records out
244570112 bytes transferred in 2.275065 secs (107500277 bytes/sec)

The problem is, that I was NOT INTENDING to move the ubuntu-rescue.img to the location of /dev/sdt. Yikes!

What I am trying to do now, is figure out what the original contents of /dev/sdt/ was (before I erroneously wrote data to that file), and if there is a way to inspect the contents (to either delete the disk image that was mistakenly copied there, or in some way restore the contents of /dev/sdt back to its original state).

Also, would this dd command erase everything that was there before, or just add data to it?

The main problem for me right now, is that I am unaware of what /dev/sdt is (is it a file? a driver? a mounted drive? etc..), so I have no way of knowing how to inspect the damage that was done. So I need to understand what I am looking at when I run this command:

ls /dev

and how to inspect/access/read the contents of these files.

Can someone please help me?

~~~~~~~~~~~~~~~~~~~~

Update #1:

For some further analysis, here are various output from various commands:

Not a directory:

$ cd /dev/sdt
-bash: cd: /dev/sdt: Not a directory

"Special Character" file

$ file /dev/sdt
/dev/sdt: character special

Verbose ls output:

$ ls -l /dev/sdt
crw-rw-rw-  1 root  wheel    0,   0 Dec 28 14:02 /dev/sdt

"Size of" /dev/sdt

$ du -sk /dev/sdt
0   /dev/sdt

Update #2

I ran the same commands from update #1 on a new mac mini (that didn't have its /dev/sdt drive tampered with dd, and it gave me the exact same output as I got on the the iMac after I ran the erroneous dd command, does this mean that the /dev/sdt didnt "record" the contents of the dd transfer? Because the "size" of /dev/sdt displays as zero when I run $ ls -l /dev/sdt. Could it be that I got lucky, and didn't do any permanent damage?

Update #3

Both of these commands: $ du -sk /dev/sdt and $ ls -l /dev/sdt give me the same results on the iMac (where the erroneous dd command was run) as it did on the untouched Mac Mini...showing that the data stored in /dev/sdt reads at 0 bytes. This makes me assume that that this drive is a temporary system drive that is not meant to store data, because even after 240 Mb of data was erroneously dd'd into it, it still reads at zero byes. Lastly, I was given a good idea (by user frostschutz) to run this command: dd if=/dev/sdt of=mystery bs=1M count=234 and compare the results of the "mystery" file with the contents of the ubuntu-resuce.img, and the output from that experimental dd left me with a file called "mystery" which was exactly zero bytes. So I am starting to feel confident that I didn't do any lasting damage, and that this drive is always empty.

Update #4

After listing to your very helpful discussions, and reading more on an another (separate, but closely-related) question of mine here on U&L, I discovered that my question has already been asked, so for anyone wanting to read more on this discussion, you can look here.