Using the FPGA of an eeColor Color3

The eeColor Color3 device is designed to enhance the colors in televisions that use HDMI input. The device is supposed to work well in all types of viewing environments, with various lighting situations. But what really got me interested in this device is the chip in the center, which is an Altera Cyclone 4, 30K logic element FPGA (EP4CE30F23C6N). I initially found the device in a post on reddit asking if the header on the board was a JTAG or USB header. The author posted high resolution images and a video of the case being opened. Most of the comments seemed to agree that it was a JTAG header.

The author also noted that these devices were being given out for free (with rebate) by Newegg. So I looked around to see if I could get my hands on one for a reasonable price and found the devices being sold on Amazon (search "eecolor") for about $5 to $15! A development board with one of these FPGAs typically retails for over $100. While 30K logic elements is not huge, it is definitely a good starting place for people want to begin developing on FPGAs.

Insides
Having only worked with Xilinx products in the past, I did not have a JTAG cable for Altera products, but I found they are readily available on eBay for about $10. I plugged in the USB Blaster to the eeColor device and Quartus instantly recognized it. I was also able to upload bitstreams without trouble.

There are a few other chips of interest on the board, one of which is a 128P33BF60, which is a 16 MByte parallel flash, which is used to configure the FPGA. According to the Cyclone 4 Handbook the P33 chip is recommended in the AP configuration scheme. Also, the handbook tells us that the FPGA on board uses about 9 MBytes of this memory, so 7 MBytes should be available for other uses. I have not programmed this chip, but it should be relatively easy using the Quartus software. Another chip of note is the 48LC8M16A2, which is a 128 Mbit SDRAM. I have not confirmed that it is connected to the FPGA, but believe that it is.

The other two chips on the left and the right of the FPGA are labeled SiI9136CTU and SiI9233ACTU. These chips are HDMI transmitters and receivers, respectively. While a NDA is required to get the full data sheets of these chips, a product brief and a data brief are available for each of the chips.

The images above come from the product briefs, although there was no circuit diagram available for the SiI9233, my guess is that it does the opposite of the SiI9136. This includes HDCP Decryption. From the "AV Receiver" portion it looks like data comes in the receiver, is then decrypted and sent through the MCU (in this case the FPGA?) and then re-encrypted before transmission. I am not knowlegable about HDCP encryption, this seems like a vulnerable point for copying Hi-Def content, or modifying it. 

Finally, there is an unpopulated pad above the FPGA labeled U15. I imagine that this pad probably was put there for a FTDI USB-to-Serial connection. Several of the pins connect to the FPGA. My guess is that this was used for debugging purposes, but it is odd because there is a hole in the case for a USB connection that is covered by a black sticker. I don't know why this hole would be there if USB was only designed for debugging.

Also miscellaneous components present on the board are a reg/green/orange led near the power supply. A blue led and an IR receiver in front. Also there is a push button on top. All of these elements I believe make for a good cheap starter FPGA development board.

Pinout

While it is easy to get access to the FPGA through the JTAG, the more difficult task is determining what the remaining pins on the FPGA are connected to. I noticed that as soon as I programmed the FPGA, the led near the power supply turned orange. Normally during it's intended operation it is green. I also took a multimeter to all of the unpopulated pads where the FTDI chip goes and found a voltage of around 2.7v. So I assume that the majority of the pins on the FPGA are being pulled high. 

To determine which pins on the FPGA were connected to the orange led, I wrote some quick Verilog code to ground 10 pins and selected the 10 pins in the corner nearest to the led. This worked perfectly, the orange led turned off. By grounding fewer pins, I was able to determine that the red led was on pin AB19 and the green was on pin AB18. When they are both are on, it makes orange.

Using the same process and a multimeter, I was able to determine some of the pins that would go the the FTDI chip (AB14, AB15, AB16). I believe that there are 8 pins that go to open pads, I just have not checked them all yet. However to repeat my process, just watch when the pads go from 2.7v to 0v. 

To find out which pins are connected to the P33 chip is a simple process, look at the pinout information provided by Altera! All of the necessary pins should be labeled under the column "Configuration Function". 

Finding the clock

Finally, most FPGA designs will need a clock, so it was important to find the clock and the frequency. Between the FPGA and the JTAG is a chip labeled Y1, which is a dead giveaway that it is the clock. It is an IDT8102. By looking at the datasheet on Digikey, it looks like it could be any frequency from 4 MHz to 50 MHz, but I could not determine the frequency by it's markings.

So again, I needed to figure out which pin this was connected to on the FPGA. I narrowed the search by opening the Pin Planner in Quartus and only looking at the specific pins which are designed for a clock. I looked at row A first because it was physically closest to the chip. Then I designed a counter that would count to 50 million and change the color of the led once it reached this number, then reset. I did this because routing the clock directly to the led would make it flash to fast, but this way it would only change once a second at most. If I guessed the wrong pin, then the led (probably) wouldn't flash at all. It only took two tries and the clock was found to be at pin A12. 

I found the frequency of the clock to be 25 MHz by very low tech methods. I watched the led blink with a stopwatch out and timed how long it took to blink 100 times. Using simple math, it was easy to find the frequency. While this probably is not the best method, it certainly is cheap and does not require any fancy (and expensive) equipment or a lot of coding/configuration. But looking at the data briefs of the SiI chips, this frequency makes sense. The max frequencies used in those chips is 225 MHz, or 9 times the speed of the clock. 

Testing and Conclusions

Overall, I this this would make a great introductory board for anybody interested in working with FPGAs. It has a simple plug and play JTAG header, it has leds and buttons, it has an unpopulated spot where GPIO pins can be soldered. It also has access to volatile and non-volatile memory. For the more advanced programmer, maybe something interesting can be done with the HDMI connections.

I would really like to encourage people to buy these devices and share their findings. Right now they can be purchased on Amazon for less than $15, and a programming cable on eBay can be purchased for less than $10. FPGAs are an amazing technology and I would like to see a lot more people using them to create cool and innovative projects. 

While my eeColor device is not being developed on I have it running as a bitcoin miner using an Open Source Bitcoin Miner. Right out the door it is capable of 15 megahashs/sec. While this is nothing compared to the ASICs that are on the market or fast GPUs, it is still comparable to CPU mining. Using the killowatt I measured it's power consumption at 2.5 watts while mining. My i7 processor also can mine bitcoins at max of around 15 megahashs/sec. I for one am impressed that this $15 piece of specialized hardware is so capable and again, I would love to see people doing some cool things with it. I will continue to work with the board and post more of my findings here.

Update 5-8-13: Many of the cheap devices on Amazon have sold out after the HAD post, try instead searching eBay for "color3 hdmi"

Retrieving ST-Link/V2 Firmware from Update Utility

Introduction

The STM32F3DISCOVERY is a small circuit board with a great microcontroller. The ARM Cortex-M4 chip has 256 KB of flash memory, 48 KB of RAM, USB and more. The board has huge amounts of header pins connected to the microcontroller and has a gyroscope, accelerometer and compass on board. For the 11 USD that this board costs, you definitely get a lot of functionality.

ST-Link/V2 chip is next to Crystal

The board also has 2 USB ports, one which is connected directly to the microcontroller, and the other connected to the smaller microcontroller pictured above (STM32F1) and is used for programming and debugging the device. STMicroelectronics calls the programming solution ST-Link/V2. When used with the proper software, it works quite well. However Linux support was initially lacking, but texane and OpenOCD were able to create working drivers. My goal was to dump the firmware.

So why get the firmware?

While ST-Link/V2 has many great features, there are a few features lacking. The STM32F1 microcontroller has a pair of USART lines running to the STM32F3 which are unconnected by default. STMicroelectronics however was kind enough to provide solder bridges on the reverse side of the board (SB13 and SB15 in the picture below) that should be simple for even an amateur to solder.

SB15 and SB13 (on the right) can be soldered to connect USART lines

The problem is that even if these lines are connected, it is not clear whether the firmware will support talking to the STM32F3 over USART or not. So by analyzing the firmware, we can find out if there is a built in ST-Link/V2 command for talking through USART or not. Additionally, it would be nice to modify the firmware so that the board shows up as a USB-to-serial device also, so that no development drivers or software are needed to interact with the STM32F3.

Sniffing USB

So how do you go about getting the firmware for the ST-Link/V2 anyway? The chip is designed to send and receive firmware from the STM32F3, not itself. However, looking at the STMicroelectronics website, you can find a ST-Link/V2 firmware update file. When you extract it there is a readme, a dll and an executable, no firmware file. So my solution for getting the firmware is to sniff USB while the firmware update is taking place. 

There are a number of USB sniffing programs out there, but many are designed specifically for Linux, others are very out of date and designed for Windows XP, and still others are not widely known and may contain malware or might not provide the functionality I need. My solution is to hook the bulk send and receive requests in the firmware update utility.

Detours

While I have written programs that manually hook functions before, that approach is very cumbersome and messy. I decided to look at hooking libraries and came across a free library by Microsoft called Detours. This library was very easy to use and took about 30 lines of coding on my part.

To use the library, you create your own function with the same calling convention and arguments as the one you want to hook and place your code in it. You can optionally call the original function from inside your function. Then in DllMain, you call DetoursAttach() to specify your hook function and the original function and that is basically it!

Detours works good for functions that are part of the Win32 library, however if you are trying to hook a function that is not part of Win32, or one that you do not have a .lib file for, Detours also works great in that situation! For instance I wanted to hook the functions WinUsb_WritePipe() and WinUsb_ReadPipe(), which are part of the Windows Driver Kit, which I did not have. Luckily, the names were exported in the WinUsb.dll file, so I was able to use DetoursFindFunction() to get the address of the function.

To inject the dll file into the executable is also made simple by Detours. One of the example programs in the Detours library is called "withdll" and basically it launches an executable of your choosing with a dll of your choosing. Using this method is wonderful because it makes my hook dll very portable. The next time I want to hook something from the WinUsb library, I can use the exact same dll with the program "withdll".

The firmware

Once the functions were hooked, I had their buffers dumped to a file that I could read in a hex editor. Below is an image of the result. The format of the file is the word "ReadPipe" or "WritePipe", followed by the 1 byte endpoint number, followed by 4 bytes describing the length of the data, then the data itself. In the image below, the last WritePipe contains the start of the firmware. However at first glance the data does not appear as it should.

Dump file from hooked USB calls

Decrypting the firmware

If I tried to run the firmware image captured above though a disassembler, I would get a bunch of garbage. I ran the USB dump file through a program I wrote in order to concatenate all of the firmware together. It was simple to recognize the firmware in the dump file because it was always sent in 1 KB chunks. While the image was begin concatenated together, I ran statistics and found that there was about 100 bytes of each character 0x00 through 0xFF. This typically means that the file is encrypted or compressed, otherwise there would be a higher concentration of values like 0x00 and 0xFF than any other value. 

My first guess was that it was encryption rather than compression because the file length was a multiple of 1 KB exactly. More than likely a compressed file would not be a multiple of 1 KB chunks because the whole point of compression is to make things smaller! 

So then I needed to figure out how the firmware was encrypted and if I could decrypt it. I knew that the firmware was stored in the firmware update utility (because where else would it be?) so I tried looking at the file with a hex editor with no luck. From all of the firmware images I have examined, STMicroelectronics always puts their name in unicode in the firmware file near the end. That did not exist in this executable, so it was likely that it was encrypted within the file.

Disassembling and debugging

Knowing that the firmware image was most likely encrypted, my instinct was to look for the encryption function in the executable file, if it existed at all. So I opened up the executable in IDA Pro and got something  that looked like the image below. All of the function and variable names are my own, but the identification of the start and end of the function were the work of IDA Pro. At the top of the image IDA Pro shows all of the functions which it has identified in blue. The light blue are functions are functions which it has found names for. The dark blue functions are functions IDA Pro does not have names for. These are most likely the meat and potatoes of the program.

After looking at the light blue functions, it looked like the majority were Windows MCF functions, not encryption functions, so they were ignored. I then started at the beginning of the program looking for some dark blue functions that looked like they might be encryption functions. The very first function at address 0x401000 turned out looking very suspicious. It looked suspicious because it had a lot of bit logic in it, particularly exclusive-or operations (in yellow) which seem to be very common in encryption algorithms.

So I opened up the firmware updater in the OllyDbg debugger and placed a break point on 0x401000 and a few other functions. As soon as I tried to send the firmware, the breakpoints were going off left and right. In the function 0x401000, one of the arguments that was passed to it was "I am a key, wawawa". So thank you STMicroelectronics for making it very obvious what the key is and what function uses it.

Identifying the encryption method

While it is not necessary to identify the encryption method to get the unencrypted firmware from memory, it is necessary if I want to upload my own firmware to the ST-Link/V2 chip. I am not an expert in encryption and it would definitely be difficult for me to identify the algorithm just by looking at it, so I had to figure out a way to identify the algorithm in a simpler manner.

Having worked briefly with Blowfish and some open source implementations, I knew that Blowfish used an array of bytes called an S-Box. I have no idea what a S-Box is, but I know the bytes are standardized, not just random digits. I also know that changing them to something else could weaken the algorithm, so the majority of the time they are not changed. So I wondered if whatever this encryption was also had S-Box's, which, again, are a large array of unchanging bytes.

So I looked at the disassembly of the function at 0x401000 (which I named genkey) and noticed a lot of references to an array starting at 0x435000. I looked at the the contents of the array and saw the following bytes: 52 09 6a d5 30 36 a5 38 bf 40 a3 9e 81 f3 d7 fb. When I googled those numbers, I found a Wikipedia entry confirming that this function was used for AES-128 encryption.

Getting the decrypted firmware

To get the decrypted firmware was simple. Once I identified the encryption key, I simply put a breakpoint on that data in order to identify any encryption functions that used the key. I then monitored what data came in and what data went out of the functions which caused to breakpoints to trigger in order to find the function that actually decrypted data. Once I found the decryption function, I simply copied the decrypted data out of memory after the function executed.

Analysis

So I now have the decrypted firmware, but an interesting question is why the firmware was ever decrypted in the first place. It turns out that the firmware uploader stores the firmware in encrypted state, decrypts it and send re-encrypts it with a different key before sending it to the ST-Link/V2 chip. Why they do this, I have no idea. The firmware would be much more secure if it was encrypted with the key that the ST-Link/V2 used in the first place and put that image in the firmware uploader executable.

The re-encryption key

The key which is used to encrypt the firmware again is actually (possibly) dynamic. When the firmware updater first starts, it communicates with the ST-Link/V2 chip and sends the command 0xF3 0x08. The chip then responds back with 20 bytes of data. The first 4 and last 12 bytes are then encrypted with the key "best performance". These 16 encrypted bytes are then used as the encryption key for sending the firmware.

Firmware sending protocol

Before sending the actual firmware image, the firmware updater tells the ST-Link/V2 chip where it wants to upload the data. In the USB long pictured above, this starts at 0x03BB. 0xF3 is a byte that means that this is a Device Firmware Update (DFU) command. 0x01 most likely tells the chip that it will be sending a firmware image next. 0x0002 I believe is a transaction number. 0x752F is sort of a simple checksum, it is the summation of all of the bytes being sent. Finally 0x0400 is the size of the chunk of firmware being sent.

None of these actually tell the ST-Link/V2 the location to upload the firmware. I believe these occur in earlier requests. One request contains the 5 bytes 21 00 40 00 08, with 0x08004000 being the location the firmware is most likely uploaded to. I do not know what the 0x21 means, however this byte is sometimes also 0x41. This will need to by analyzed further. 

It is interesting that data is uploaded to 0x08004000 and each upload is spaced 1 KB after the last until it reaches 0x0800AC00. Then the last 1 KB of the file is uploaded to 0x08003C00. 0x08000000 and up is all flash memory, however it is interesting that the code is not uploaded to the beginning of the flash memory. This could be because code is possibly executing in the earlier portion of the flash and should not be overwritten. Maybe at some point the code will be copied over to the beginning of the flash? Or maybe the beginning of the flash is supposed to be a failsafe in case the firmware arrives corrupted. Or maybe it is just a boot loader for the uploaded flash. It will be interesting to see what the flash memory looks like when I get access.

Upcoming work

Now that I actually have a copy of the firmware, I will need to analyze it. I have taken some initial glances at the firmware, but will need to study it more in depth. I am familiar with x86 assembly, but ARM assembly is completely new to me. Also, I am not quite sure how to work IDA Pro with ARM firmware. It will not automatically identify the beginning and ends of the functions, I must identify individual bytes as code, then IDA Pro will be able to tell me more. So right now I am just making guesses at which parts are code and seeing what IDA Pro does with it. It seems to be working, but since I can't yet understand ARM assembly, I don't know if the data is being interpreted properly or not. If anybody has a more methodical way of marking functions in IDA Pro, I would love to hear it. Particularly if somebody knows how to locate the main routine.

I did look around in the firmware and saw that it contained the same AES-128 S-Box array. It also contained the string "USBC", something that was used in the ST-Link/V1 firmware based on texane's code. Using that, it should be easier to identify the AES-128 functions and other functions in the firmware.

So my goal now is to analyze the firmware and eventually add functionality to it. Eventually I would like to modify it so that it will use the USART on the STM32F3DISCOVERY that is currently unconnected. Or maybe identify code in the firmware that already uses the the USART, and I just need to know the command. The firmware image is 28 KB and the STM32F1 chip which is used for the ST-Link/V2  has a 64 KB flash, so there should be more than enough room to add a few routines.

Turning Point Clicker Emulation with Arduino and nRF24L01

Turning Point Clicker Emulation with Arduino and nRF24L01

The Turning Point ResponseCard RF, often referred to as a clicker, sends user input to a hub for polling purposes. The user can select a button labeled 1-9 and 0, or A-J and the clicker will send the result to the hub which collects all of the responses. Travis Goodspeed details some of the inter-workings of the Turning Point ResponseCard RF in his blog. He found out that the device always sends it’s answer to the MAC address 0x123456. Then the payload itself is preambled with the clickers MAC address and then the user input, which is ascii 0 through 9 or a question mark. Finally the packet is terminated with a 2-byte CRC.


The heart of the clicker is a Nordic chip, nRF24E1 or nRF24LE1 for later models. This chip includes a nRF24L01 wireless transceiver, which is readily available on ebay for about $2 and can be quickly attached to an Arduino or other microcontroller. This article will discuss how to use an nRF24L01 chip along with an Arduino to emulate and extend the functionality of the Turning Point ResponseCard RF.

The code for the nRF24L01 Clicker Emulator is here. The Arduino code with the nRF24L01 chip can do the following:

• Listen to audience responses and generate statistics
• Block all audience responses
• Respond as a single clicker with a select answer
• Respond as all clickers with a select answer
• Respond as all clickers, each with a random answer
• Display all active audience members MAC addresses
• Automatically respond with the most popular answer

Setup

Connecting the nRF24L01 with the Arduino is quite easy. There are a total of 8 pins that need to be connected. Vcc is connected to the 3.3v source and ground to ground. The nRF24L01 then communicates through 4-wire SPI, so those wires are connected to the proper pins based on your version of Arduino. Finally the CE line can be hooked to any unused digital pin and is used for enabling RX and TX operations. The IRQ line is active low and can also be hooked to any digital pin. It is used to inform when TX has taken place or there are packets in the RX buffer and other similar matters.

The inputs on the nRF24L01 are 5v tolerant, so no additional circuitry is needed between the two devices. Also, note that your SPI pins may or may not be the same as those reflected in the Arduino documentation. I used a knock-off Arduino Nano ($12 on ebay) and several of the pins were reversed. Your best bet is to look at the Atmega328 datasheet to determine the correct SPI pins.

Coding

Writing code for the Arduino is also pretty simple because Arduino is already distributed with a SPI library, which can communicate with the nRF24L01 at it’s full 8mhz. Which is very useful when packets are being sent as hundreds of different clickers. In order to interact with the clicker hub, it is important that the nRF24L01 talk in the same format. Below are some of the variables that need changed:

• CRC should be set to 2 bytes in length or disabled if jamming
• PRIM_RX is set for receiving and unset for transmitting
• Auto-Acknowledge should be disabled
• Having this enabled forces the nRF24L01 to send Enhanced ShockBurst packets, which are incompatible
• Acknowledge packets should be manually generated
• The address width is set to “01” corresponding with 3 byte MAC addresses
• RF_DR is set to 1Mbps
• RF_PWR can be set to 0dBm at power cost but longer range
• The status register must frequently be cleared in order to reset the interrupts

After all of the registers have been set, it is important to also set the destination address and the payload. There is no length field for the payload. It will transmit as many bytes as you send to it, up to 32. In the case of the clicker emulator, I send 4 bytes. Three of the bytes are the source MAC, or the emulated source MAC, followed by a 1 byte answer.

To receive an acknowledgment, the source MAC address must be stored in the nRF24L01. Two source MAC addresses can be stored at a time plus four more that only vary from the second MAC by the last byte. Currently this program ignores acknowledgements and assumes that the packet went through, which is OK in low traffic situations, but may cause failures at long distances or with lots of audience members responding. To overcome this, the nRF24L01 sends multiple copies of each packet by using the REUSE_TX_PL command and holding CE high. More copies can be sent by holding CE high for longer.

Eventually acknowledgement packets will be accounted for after some real world testing. Much of the development of this was done without a hub to test against, so advancements will come with more access to the hub. The acknowledgement packet is sent to the clickers MAC and is composed of a one byte status and a two byte CRC. The value 0x04 lights a red light on the clicker, 0x06 is a green light and 0x53 is an orange blinking light. The others cause no response in the LED and it is not clear what their functions are. The only issue now is determining when to listen for the acknowledgement packet and after how long to give up or try again.

Conclusions

There really is no security in the Turning Point devices. Once the MAC address for the hub was known, it was simple to just listen for packets on that MAC address. There is nothing to stop a user from then emulating that devices MAC address, which can be done with a single SPI command. While one of the Turning Point devices is sold at campus bookstores for around 50 USD, this device can be created for 14 USD and has extended functionality compared to the clickers. While the code in the clickers themselves is locked, it is possible to program all of this functionality directly into the nRF24LE01 chip.

Dealfun DealWheel - Programming for free stuff

    There was once a website called DealFun. It was a so called "penny auction", It charges customers 60 cents per bid. The item being auctioned starts at zero dollars and every time somebody bids on it, it goes up a penny. Auctions usually had a start time of 24hrs. Within the last few seconds of the auction people really start to bid, every bid placed resets the auction time to 15 seconds. So a $300 item might go for $200, but getting the price up that high requires 20,000, sixty cent bids, or $12000 worth of bids! So there were many people paying for the items, but only one person actually got it.

    In order to incentivise people to use their website, they had various promotions, such as 100 free bids with the purchase of 250 bids. They also implemented something called the Deal Wheel. Which is something like the Wheel of Fortune, so every time the user spun the wheel, they would win a prize. They would win 1-10 free bids or a mystery prize. Spins were limited to once per day. Bids were almost worthless because of the difficulty of actually winning an auction. Mystery prizes were actually physical prizes though. So I decided to write a program that would win a mystery every spin.

    The DealWheel itself was a Flash app on their website. Figuring out how this operates is the first step in determining how to only win mystery prizes. We will start with a program called Wireshark (formerly known as Ethereal). This program monitors network traffic. So we will start it up and select the network interface that brings us the internet. We will make an assumption that the flash app is communicating over HTTP, and that it is communicating to the same DealFun server that is serving the webpage. Looking at the info column for these specific conditions yields good results. In particular a POST request to DealFun, requesting a file named /dealwheel/spin.php looks particularly interesting. 

    If you look at the post data, you will see that the flash app sends prize%5Fid=2, or prize_id=2 in the screenshot above. This wheel should be pretty easy to rig. We just need to find out what the id's correspond with. If you look further into the capture, you will see the file /dealwheel/wheel.xml is loaded. This file gives the flash app, everything it needs to know in order to build the wheel, including the id. We now know that mystery prizes have a prize_id of 10.

    It is now time to build an app to send our prize id to DealFun. I did this in C# as my first attempt at making a program in the language and was rather impressed with C#. It was pretty simple to build a gui and the HTTP interface was not bad, but still not very flexible. Many lines of the HTTP header can be hard coded into the app, such as the user agent, the file being requested and so on. However some things need to be dynamic, like the cookies, since they do expire. I also needed to build a login prompt in my app to authenticate the user.

    So once the user logs in to the app and the cookie is stored, the wheel.xml file is loaded and parsed so that if DealFun ever changes it's prizes, the app will still work. The user can then select what prize they would like from a drop down list and the program will send the POST request to spin.php with the proper id and authenticated cookies.

    After a few months, the app no longer worked. By using WireShark, I was able to analyse the problem and find out that the login interface had changed and I would get an authenticated cookie, but DealFun would also redirect and deauthenticate it. However in the browser I was able to login just fine. Most likely the error was not emulating a browser close enough, either by not loading the homepage before logging in or having and improper referrer in the HTTP header or something similar. While it is possible to have the app simulate a browser more closely, that is also a lot more work, and it was a fight working with the C# HTTP library and custom headers.

    After a little research, I found a tool called Fiddler. This is basically a proxy that you install on your computer that redirects all web browser traffic through. While the stream is running through Fiddler, it has the ability to modify, stop or redirect it. In our case, we will want to modify a stream that is directed towards dealfun.com and contains the path /dealwheel/spin.php . From there, we will replace the POST data containing the prize_id from the DealWheel app with the prize we want (most likely 10 for a mystery prize).

    Fiddler was surprisingly lacking in documentation, however with their plugin FiddlerScript, made it easy to guess which functions should be used. For this purpose, Fiddler seemed to work very well and did just what it needed. However because scripting is done in JavaScript, I feel that Fiddler may not be as flexible as it could be if it had a C++ API or something similar. The advantage of it is that it just works from the moment you launch it. Also the DealWheel script was able to be accomplished in 2 lines of code and once it is running, you just use the browser as you normally would. The disadvantage is you need to modify the code if you want a prize other than the mystery prize.

    As of this writing the DealWheel has been "under maintenance" for several months. It also appears that DealFun has not had any auctions for 5 days. My guess is that DealFun is out for the count. I believe they probably got shut down because their premise is a sham and has been likened to gambling. Still, I'm happy to have won some free stuff from them. You can download the C# program and the Fiddler script from my code page. Happy Hacking!