I read Richard Stallman’s story about how he was able to fix a printing problem in the MIT AI lab long time ago. The main point is that if you know how to modify a device or an instrument then you have the ability to extend the functionality well and you can make things more useful. In order to do so, you will have to understand the underlying mechanism about how a thing works. In the old days before any computer code is popular, one might learn how a machine works by just looking how it works if one has good amount domain knowledge. However, the universal applications using computer program to control machines makes modification harder. Computer is a wonderful tool to process complicated information and procedures but it also allows concealing about how a device or an instrument works. When there is no source code or some simple API document allowing you to get some understand how the computer controlling a device or an instrument, then some reverse engineering is un-avoidable. This is my story about how I learn to “hack” a machine in order to do some interesting science.
I got a Ph.D in theoretical physics. My thesis was about stochastic fluctuations in non-equilibrium system. My major interests were to use some statistical mechanics framework to explain interesting natural phenomena. What kind of non-equilibrium system can be more interesting than life itself? I started working as a post-doc in UCSF after graduate school. Initially, I mostly focused on some biological network analysis of protein-protein interactions and gene regulations in the beginning. Trained as a theorist with some computational skills, my initial research plan followed my advisor’s paradigm, which was to gather data in public domain and did analysis on the data to publish new analysis results. However, while there are a few successful cases, such approach is in general not favored in the biological research field in my opinion. First of all, unless you know all the details of the initial experiment that generates the data, it is very likely one might not have enough information to interpret the new analysis results or the interpretation might be simply wrong. Secondly, the researchers who generate the data should have done some “first-order” analysis that reveals most significant information with straightforward analysis with the data set. Most low hanging fruits should be presented in the initial study. Secondly analysis on such data set is just harder and may not have the proportional impact as the initial analysis. Moreover, the biological research field generally values original experiments more than fancy theoretical analysis, although there is a new trend after more and more quantitative emphasis on biological study recently. These lines of thought made me to decide I would need to do my own experiments to gather my own data. But, how?
My advisor in UCSF was also a theoretical physicist who became a bioinformatist and built a career in UCSF providing his quantitative skill to the research community in UCSF. However, as far as I could tell, he had very limited experience in experimental sciences. That has been said, the setup in the new UCSF mission campus was indeed great for me who only had mostly theoretical background to learn new tricks in experimental biological sciences. Our lab was surrounded by some of the best molecule biology labs in the country. I started to learn some basic molecule techniques from the post-docs and graduate students in those labs. I still remember some generous graduate students and post-docs spent their time to show me how to do the basic like how to do precision pipetting. My first few attempts to do simple PCR failed miserably because I was not really able to pipet the 1 ul enzyme precisely for the reaction. Sometimes, I felt so embarrassing since I was not even able to calculate the amount regents for PCR and carried the reaction out correctly even though I though I had no problem to attack some difficult and highly mathematical problems in physics if I wanted to. The learning curve was indeed quite steep, however, I had some other advantage: trained as a physicist, I knew some of the fundamental principles on how certain instruments worked. Moreover, it was more or less easy for me to understand how software could be written and how the software controlling the instruments worked. These skills allowed me to do something interesting and went beyond to do some experiments that the vendor could not support.
When I was analyzing some of the time course microarray data, one question we asked was about how to explain certain pattern in the time course. Were there some fundamental and new principles in governing the dynamics of gene expression? Although microarray allowed monitoring a large number of gene expression at the mRNA level at once, the resolution in time and expression level was quite rough. Could I get a better measuring system for understanding gene regulation dynamics with much better time resolution and expression level quantitation? At that time, GFP-fused proteins were used to measure gene expression at the protein level. Two labs in UCSF worked hard to tag several thousands of proteins in S. cerevisiae with GFP and study their static expression under several conditions and the localization of the proteins in a cell. The high throughput measurements of protein expression were done by using a flow cytometer. A flow cytometer uses a flow stream to separate individual cell such that high throughput optical measurement for each individual cells can be done. Although you can do tons of single cell measurement at once, the typically experiment setup is that you still need to collect cells, put them into a tube, put the tube into the flow cytometer and click a number of buttons on the control software to get the measurement done. I did try to take time course this way manually. For a simple low time resolution experiment, like measurement every 20 minute for several hours, I will have run between the incubator of my cell culture and the instrument room of the flow cytometer all the time. I will have to check the cell density and wash the cell and the flow cytometer intake every 20 minutes. Well, to do large-scale experiments with this way was just probably not my style. I needed to find a better way to do it.
The previous study using the same flow cytometer that I was using was indeed done with a robotic setup. The interesting part was that the robotic system was synchronized to the flow cytometer software by simulating UI events to trigger the measurement software to start and stop recording. The flow cytometer vendor did not support such feature yet. I think it was Joe deRisi figured out how to do that and wrote some program that controlled a sample-delivering robot and trigger the measurement software automatically. Instead of the robotic sample delivering system, I was also setting up a different sampling delivering system that used a bioreactor to deliver live culture continuously to the flow cytometer. Even though I could using same UI simulation hack that Joe did, I was also trying to find some other to collect the data more efficiently since pulling the data out of the instrument software was also quite painful to do. It would be nice I could have controlling system and data collection system in one single program that I had more or less full control on the control and data flow. Joe did notice that the vendor’s software running on a PC talked to the embedding system on the instrument through a standard network interface. Basically, the instrument was controlling by an embedding system and data was collected by the same system. The software running on a PC was merely a frontend and a client. If we could figure out the data stream between the PC and the embedding system, we could do much more than the vendor’s software could do. By the way, we did try to talk with the vendor to see whether we could get some documentation about it. Well, as usual, the vendor was quite reluctant to reveal more. (Now, I am on the vendor side. I probably understand their concern better. But, we did not ask too much. What we needed was some simple description about the communication protocol. It had to be already somewhere in their software organization. Otherwise, software engineer could not write the code.)
I did not remember why I knew how to sniff the network communication. I probably learnt that because I installed some on-the-edge linux software that did not work after installation and I needed to do some tcpdump or so to see what was going on to fix the problem as a hobby. So, I installed “ethereal” (it is now called Wireshark) and start to dump the TCP/IP data stream between the vendor’s software on the PC and the embedding system. Of course, I was hopping they simply used some clear text protocol. Unfortunately, they were using some sort of binary protocol. However, when I was staring at those hex numbers of the output from an “ethereal” session. I did notice some regularity. This means, at least, they did not encrypt the data. Great, at least, I could start to guess what those hex numbers represented. Some portion of the data stream had some regularity. The numbers seems repeating similar pattern every 4 bytes. What could they be? Well, there were a lot of things in computer represented with 32 bits. On the other hand, the most common one for such instrument was probably some floating numbers. Yes, I took those 4 byte chucks and figured out the right byte orders, treated them as IEEE float number format, then I wrote some short code to translate them. The number I got totally make sense!! I could read those numbers and understand what they were. Moreover, I could start to tell which parts are control commands, and which parts are data. The rest of that week, I was running between the lab doing some experiments, collected more TCP/IP data streams under different conditions and went to a hospital to stay with my wife who was expecting a new baby in the antepartum department of hospital. I took my laptop with me and worked on deciphering the data and code while my wife was resting.
Eventually, I got to a point that I could decipher and read the data stream to get everything I needed without using the vendor’s controlling software. The next thing is to combine such knowledge to write my own software (GUI application for control and data processing) to bypass the control application from the vendor. I used the same old version Borland C/C++ to build a GUI interface under Windows such that other people can use it too. (If I were the only user, some scripting through a command line interface was probably good enough.) The results were much useful than the original software that the vendor provides. We could combine the data acquisition and an external robot seamlessly to make the measurement more reliable. Actually, there were a few glitches here and there initially since I was almost the sole developer for the project and there were no comprehensive testing and user case studies. Most of them got fixed and could be fixed easily. However, I was always afraid something might be broken after a vendor software/firmware upgrade. It is possible that the vendor can totally do a firmware upgrade that changing the protocol that I have reversed engineered. If so, I will need to restart the whole process.
There were also some side-effect after people can really see the “raw data”. The flowcytometer integrated the electric signals from photo multiplier tubes to get total fluorescence. Anyone who had some experience in such numerical integration method would not be surprised with negative values. My code faithfully reported some of the negative values reported by the firmware of the machine. However, it caused me some trouble. I could not remember how many times I needed to explain the meaning of such negative values to my colleagues who did not know how such machine and algorithm worked.
To be able to control the acquisition for the flow cytometer is an important step stone for what I wanted to do: monitoring GFP expression of a few proteins in real time. I wrote a few simple program with few simple parts (a chemostats as an incubator and a syringe pump to deliver the sample), I was able to see the time course of gene induction by staving the yeast cells for some essential ingredient. I though it was a great system to really measure how gene circuits response to environmental perturbation to get a better understanding and modeling about gene regulations. We wrote a paper using the system to study a particular amino acid synthesis pathway. Unfortunately, due to the hacky nature of the code and lack of general instrumentation mind set in biological research field. We might be the only group that was doing such thing. Although we can share our code, it will be much easier if the vendor opens their protocols such that we can make sure the code will work across different machines. If so, there might be much more other researchers who will like to use such powerful tools to study gene expression in real time.
Since then, I proudly quitted my postdoc job, and got “real job” in few bio-tech companies working on mostly on data analysis, software and algorithm development. I am hoping that the company I am working for now or in the further will embrace openness and I like to see people hacking a machine beyond its original purpose to generate interesting scientific research results.
