TUMPA Mac El Capitan 10.11.2 (FTDI FT2232HL)

    If you want to skip my longwinded journey to finding the fix for this on El Capitan, I understand. However, if you don’t mind a good weaving tale, please feel free to join me for the next few paragraphs below!

    Remember that little TUMPA I was messing with a little while back? I got in a hardware debugging and learning mood, so I decided to fire up my TUMPA board. As a side note, work has since replaced my laptop and I’m no longer running Ubuntu on a Lenovo, but instead I’m on a MacBook Pro. For the most part, the transition has been hardly noticeable. I did what I had always done on Linux, which is to plug that bad boy in and low and behold, NOTHING! Yeah… I had the same reaction, which was disappointment, to say the least. I figured there was no way that Mac wouldn’t be able to plug and play this device when Linux could! Clearly I was very wrong.

    So I headed over to the ol’ Googs for some help. That first link looked quite promising, so I decided to go for it! I simply followed along and downloaded the driver from here. I basically did a normal installation procedure, but if you’re curious I did this:

• Download DMG
• Open DMG
• Double click pkg from opened DMG
• Look in /System/Library/Extensions/
• • Turns out, El Capitan has non-system kexts installed in /Library/Extensions/… *learned!*
• ls -l /Library/Extensions/
• See FTDIUSBSerialDriver.kext
• Good! Let's plug in the TUMPA

    Plugged the board in, but no change… When I checked kextstat, it returned nothing.

    Well according to that post, and everything I had read so far, I needed to fire up the kext, so I did what I thought was right and manually loaded that kext.

    I will tell you that again, I plugged in the device and no change. Now, from this point on, I’ll save you all a little time and just let you know the exact answer I used to fix it. Not the adventure I had while trying to do so, though that IS quite a wonderful story! If you’re curious, just ask and I can post it. It involves many driver attempts, many different drivers, many modifications, and many emails to many support teams.

    The answer actually came from one of my favorite learning resources, irc.freenode.net! I absolutely LOVE IRC. I use xChat Azure on my Mac and I absolutely love every minute of it. I am constantly in a multitude of channels on irc.freenode.net, but mainly I hang out in:

• #Cisco
• #Exploiteers
• #Powershell
• #Python
• #Regex
• #OpenOCD

    I would probably be in more channels than these, but the ones listed are basically the topics I work with almost daily. They are also the rooms that I have found to be the most helpful and welcoming. All of them have been very helpful when I need assistance. I just make sure to read the room rules and ask my questions accordingly. I make sure to always thank the people who take time out of their day to assist me with my questions. If you stop in and see me, Mitch-_-, feel free to say “Hi"! I’ll try to help with anything I can.
    I wanted to make sure to give a major thank you to @PaulFertser on the #OpenOCD IRC.freenode.net channel! He really is a very helpful resource. He helped me get OpenOCD installed and walked me through getting it working for JTAG. Then I could confirm that that the JTAG portion was at least connected and working using libusb. The last remaining part was not necessarily Paul's wheelhouse, but he did suggest a blog post that helped point me in the right direction. It was ultimately the turning point to getting the driver working properly! Thanks again, Paul!

    To get this working, I had to combine both steps from the tiaowiki.com install TUMPA on a Mac, and this Mommosoft Blog. The combination was editing the Info.plist in the steps from the wiki, but in the blog post, he lists the "bcdDevice" id as being a critical item to include. When looking in the Info.plist, I did notice that it was on all <key> entries... I figured that must have been my missing item, because the TIAO wiki does not list the "bdcDevice" in it's entries.
    To edit your FTDI kernel extension, open a terminal and enter:

1	sudo nano /Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist

       Once inside this Info.plist via nano, you can search by using CTRL+W. By using that key combination, I searched for “1792", which is the bcdDevice ID for FT2232H chips. I believe that is just the bcdDevice ID for all FTDI FT2232H chips, not 100% positive on that though. It was listed on almost every one of them, so that was promising. I then used CTRL+W to find “FT2232H”, which was just a good starting place to put my <key> information. I decided to put it between FT2232H_A and FT2232H_B.
    I then entered the two new following keys:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

<key>FT2232H-TIAO-0</key> <dict> <key>CFBundleIdentifier</key> <string>com.FTDI.driver.FTDIUSBSerialDriver</string> <key>IOClass</key> <string>FTDIUSBSerialDriver</string> <key>IOProviderClass</key> <string>IOUSBInterface</string> <key>bConfigurationValue</key> <integer>1</integer> <key>bInterfaceNumber</key> <integer>0</integer> <key>bcdDevice</key> <integer>1792</integer> <key>idProduct</key> <integer>35480</integer> <key>idVendor</key> <integer>1027</integer> </dict> <key>FT2232H-TIAO-1</key> <dict> <key>CFBundleIdentifier</key> <string>com.FTDI.driver.FTDIUSBSerialDriver</string> <key>IOClass</key> <string>FTDIUSBSerialDriver</string> <key>IOProviderClass</key> <string>IOUSBInterface</string> <key>bConfigurationValue</key> <integer>1</integer> <key>bInterfaceNumber</key> <integer>1</integer> <key>bcdDevice</key> <integer>1792</integer> <key>idProduct</key> <integer>35480</integer> <key>idVendor</key> <integer>1027</integer> </dict>

Warning: Lengthy explination on how to get idVendor, idProduct, and bcdDevice.

    To give a little extra information on the topic, the “bcdDevice”, “idProduct”, and “idVendor” are the <key>’s that really matter to us. The way I located these, which should be the same IDs for anyone doing the TUMPA, would be System Information > Hardware > USB > TIAO USB Multi-Protocol Adapter. From within there, you should see the information listed below, except for the bcdDevice id. The product ID for the TUMPA was “0x8a98”, and the vendor ID was “0x0403”. To covert these to decimal which is what the kext uses, we need to convert them in the terminal. You can do this quickly by using

1	echo $((0x8a98)) && echo $((0x0403))

    You will then see the output of the <key> values we used accordingly above. I mainly included this definition for anyone that might be researching El Capitan and FTDI or FT2232HL chips. Their IDs might be different, but I wanted to make sure to include how those values were populated. The long and short of how I got the bcdDevice value was really two different ways. First was, it was listed on the Mommosoft blog. Ha. The second, which was just a confirmation that “1792" would work and was the right one, was when I had done a few “ioreg" commands. If you are curious about the usb devices that are connected to your machine, you can run “ioreg” and it will list the items. Then once you have listed them, if you would like to find a specific item, you can grep for it. In our case, "ioreg | grep TIAO” would return the TIAO USB information. To dig deeper than that, you could even run items against your specific results, such as "ioreg -r -n "TIAO USB Multi-Protocol Adapter@14100000" -c AppleUSBDevice”. If we want to get even fancier, we can grep for just the items we want about our device…

1	ioreg -r -n "TIAO USB Multi-Protocol Adapter@14100000" -c AppleUSBDevice | grep -i "bcddevice\|idproduct\|idvendor"

     This should give you plenty of output to identify whatever device you are trying to use. Now, back to the stuff you came here for!

    After you modify the Info.plist, you will need to remove SIP (System Integrity Protection), which is a new feature in the world of Mac. It’s a security feature that is turned on by default in El Capitan. When you go to use a driver(kext) that has not been signed, it will not allow it to start. When we added the entries into the Info.plist, you have changed the contents so the kext is no longer signed. Therefore, you will need to disable SIP.

    Verify if SIP is enabled or disabled with

1	csrutil status

    If SIP is already disabled, you can proceed to reboot and loading the kext. The process for disabling SIP is outlined here. Disabling SIP requires a reboot (and so does installing the kext and changing the Info.plist, so there will be no shortages of reboots in this process). After disabling SIP and rebooting, you will need to manually load the kext.

1	sudo kextload /Library/Extensions/FTDIUSBSerialDriver.kext

    Once you have the device plugged in and the kext loaded from the command above, you can run ls for the device.

1	ls -l /dev/tty.*

    You should see something along the lines of this. (I know this picture is for cu.*, I was just learning at the time that tty was what I needed…)

    Clearly, the “bcdDevice” was the key to getting the TUMPA recognized, which is a missing field from the tiaowiki article! Once we have that device recognized, we will either use Channel A or Channel B depending on your use case. As stated in the TUMPA Manual, TTL will be using Channel B. It’s listed under Board Dimensions at the bottom of that specific article.
    From your terminal window, you can now type “minicom -s” and it will prompt you for setting up your minicom connection. You will need to set the device to "/dev/tty.usbserial-TIM0394B” if you are going to be using TTL for loopback testing, which is what I am doing. Save your configuration as “tumpa” for ease of use.
    Please Note: My board was already in TTL loopback mode from previous testing, if you need to put yours in TTL loopback mode. Please see the article I have posted at tiaowiki.
    HINT: If you would like to have a shortcut to your configuration with minicom, you can add an alias. Such as:

1	alias tumpa='minicom tumpa'

or

1	alias tumpa=‘sudo minicom tumpa'

    You will enter either one, depending on your use case. I usually prefer to run minicom with sudo, even though I have very few reasons to do so. Regardless, now we can use our alias and fire up minicom!

    From here, you should be able to use minicom as you would have on Linux or any platform that has it, and test typing with the device showing activity and the output showing back up on screen as is. I hope this has been helpful for anyone that has tried to use a TUMPA on a Mac with El Capitan. Along those lines, I hope this is helpful for anyone that has a unique PID with their FTDI FT2232HL chip, because these directions should work for that as well! Until next time, thank you for reading!

-Mitch B.