Close
0%
0%

Wac0m Rip0ff : Wacom I2C hacked!

I broke my YOGA Book touch keyboard while trying to replace the battery, So I have a chance to reverse engineer the Wacom I2C HID digitizer

Similar projects worth following
Recently, I need to replace the battery of my Lenovo YOGA Book, but in the procedure of open it up, I accidentally broke the keyboard second time (touchscreen made of GLASS). So I can finally replace w31Rd Romania layout keyboard with US layout. but the old cracked glass still has the Wacom digitizer sticking to it (That is the second one that I have). So after 6 years of experience in Electronics and Computer. I finally graduated from high school and brave enough to do the first and successful hardware reverse engineering. !

BLE version is out! More info on Wac0m RipOff BLE edition

I reverse engineered the Wacom I2C EMR pad taken from Lenovo YOGA Book, first started by probing all pads connected to the Wacom board. There're 8 pins total connected to touchscreen chip board which is connected to YOGA's mainboard. the main character of this project is W9013 the REALLY SECRET Wacom proprietary chip that ONLY Wacom engineer team has access to datasheet(Try search it up, You won't find it ;P). I started by peeling of the copper sheet protecting the board against EMI, since this technology (Wacom EMR) rely on radio emission similar to RFID and NFC. take a look at the second pic in project gallery. I labeled 6 pins plus the main Vcc/Vdd rail. all the pins labeled with number are corresponding to FPC connector pin order

1. Unknow

2. SCL (No pull-up D:)

3. SDA (No pull-up D:)

4. Unknow

5. IRQ, goes low when w9013 is ready to send (pen present)

6. Chip Reset Active low, useful for re-establish/initialize I2C comm.

7. 3v3 Vdd

8. GND

(I suspect that the remain pins are used for IRQ on other detection, Because this chip is very similar to one used in Samsung Galaxy Note 8.0 tab, btw my dad own one of these, might try probing later too). 

The host seems to used 1MHz I2C, but I confirmed that the w9013 works with 400kHz too (on my F1C100s and STM32).

right now, I ported the Wacom i2c driver from mainline Linux kernel to STM32 (using STM32CubeIDE). I currently using the STM32F3 DISCO board,  because I can share the I2C bus with onboard sensor (Pull-up already there 10k). also the onboard ST-Link provide the 8MHz clock for HSE and Serial ACM for debugging. It's worth buying board (I've been using this board for 3 years now Since Grade 10, 3 years ago). 

the STM32F3 is capable of USB device (USB gadget I would say). And I use the USB HID feature and writing my own HID descriptor. The tool that I use is HID descriptor tool from usb.org (by the way, the latest version is younger that me just ~1 year xD). but the output of the program is in non-friendly-C format, so I literally wrote entire thing in C array. 

This project is now working properly on Windows 10 (my main target OS). 

  • 1 × Wacom I2C digitizer (W9013 based). You can find this exact OEM part by searching for Lenovo yoga book keyboard replacement
  • 2 × 4.7kOhm Resistor for pull-up on the original probing with my Laptop open. there're pull-up on the bus somewhere on the main board
  • 1 × Logic Analyzer that accept 1MHz [optional] I don't have much buck to buy the reliable Logic analyzer, but at lease my Arduino UNO SUMP logic sniffer done the job and doesn't cause the i2c bus to lock up.
  • 1 × STM32F3 Discovery Board in fact, any STM32 should work with some code modification.
  • 1 × Teensy++ 2.0 For the Arduino version, Other teensy might work as well

  • More commands | More nicey

    TinLethax08/31/2021 at 16:03 0 comments

    recently I came across the Linux commit by alistair23. The newer w9013 variant seems to support the X/Y tilting and Pen distance detection. In his commit have something that currently mainline doesn't have, It's the other commands. You can set the report rate and put device to sleep and wake them - via command obviously. Unfortunately, my w9013-s have the firmware version 0x0333 which isn't support the X/Y Tilting and Pen Distance report. but I yet to test the variable sample rate and sleep/wake mode, since this feature is really useful for my Wac0m RipOff BLE project.

    His version of wacom_i2c.c can be found here

  • Wac0m RipOff BLE is here !

    TinLethax08/31/2021 at 07:50 0 comments

    I finally made the functional version of this project with Bluetooth (ignore the "Low energy" for now 😅). I'm using nRF51822 with Arduino core made by sandeepmistry on GitHub and I ported the HID code to make it compatible with Digitizer. I created new project page in Hackaday.io here.

  • Wac0m RipOff BLE coming soon !

    TinLethax08/14/2021 at 05:01 0 comments

    I'm really excited to tell you that the next revision of Wac0m RipOff project is coming with Wireless Bluetooth Low energy support ! Yesterday I've been researching for the suitable Bluetooth-Capable MCU. I came across many like HC-05 with RN-42 firmware (HID capable), STM32WB (Also HID capable) and nRF51822 (Arduino compatible). but I decided to go with Arduino again this time because : USB is hard, Bluetooth is 1000 times harder! (Except for the last one). 

    first, the HC-05 module (based on BC417 made by CRS). Though the RN-42 firmware is just a firmware not really a code, but Someone on Arduino forum found out that in the firmware has the HID descriptor embedded byte by byte, and only way to implement my own HID descriptor is to modify the firmware. But there're couple reasons that keeping me away from using HC-05 

    1. I need to write the Python script to rearrange the memory address (the firmware is plain text) that look like this :

    @06eb31 0005 
    @06eb32 0001 
    @06eb33 0009
    @06eb34 0006

    That portion of code is the HID descriptor taken from that .xpv firmware file  

    That is possible to write some script to move the byte to next mem address (but since I don't code Python sadly), but the next reason is make it almost impossible.

    2. These HID descriptor likely has the pre-defined array size and event memory address is fixed. so I really need to dig down to the compiler + CPU programming manual. that will cost me (probably) years to finally made through it, but I don't have that much time. so I move to next solution

    Second, STM32WB. To be honest, I really love using STM32. It's IDE (CubeIDE, formerly knows as ACE) is based on Eclipse, and I've been using for 3 years now. It's really easy to use but also really advance in the same time. I came across the STM32WB30CE, BLE capable (via another Cortex M0 beside the main M4 core). I thought that the BLE middleware is really easy to use like USB (<- not easy, just not CRAZY COMPLEXT). Thing went unexpected. The BLE middleware is really complicated. Also in order to make radio works. It's required the external 32MHz Xtal (My habit : avoid using external OSC, just lazy to design the HF board). So again I abandoned this idea.

    Last one, nRF51822 (NRF51822-04 module to be precise). I came across video on the Hugatry's HackVlog YouTube channel making video about Arduino with that Nordic NRF thingy. I did some little research and find out that this Nordic chip is really flexible, I can literally remap i2c pin to any pin any where! so I only need a small nRF51 module board with couple pins exposed to use with Wacom w9013. All the thing to do is just to port the BLEHID library (done), port the sketch (done) and test it out (not yet, haven't buy that module). 

    Once I got the nRF51 module on hand. I'll make video about it too.

    P.S. for who wonder Why I don't go with ESP32. That thing is too powerful, I'd probably use 1 out of 10 from it. 

  • Ported to Teensy++ 2.0

    TinLethax07/28/2021 at 15:53 0 comments

    two days ago, I ported the WacomRipOff project from STM32 to Teensyduino. And It works ! only change I've done is instead of using interrupt waiting to receive the data from w9013, polling is the way to go because the Interrupt on my teensy is buggy. Anyway here is the GitHub repo https://github.com/TiNredmc/WacomRipOff_Teensy

  • Finally working!

    TinLethax07/26/2021 at 11:48 0 comments

    I finally make it working (at least on Windows 10). I already committed to my GitHub, so the latest code is now working! Also, I'm now understanding the way to report the correct hid event, so let me guide through. the number in parentheses corresponding to bit number of actual report. 

    Pen report only :

    -(7)(6)In-range(5)2nd barrel btn(4)Eraser Tip Down (3)1st barrel btn (2)Invert (1)Pen  Tip Down (0)
    No pen00000000
    Pen Tip Hove00100000
    Pen Tip Down00100001
    Eraser Tip Hover00100010
    Eraser Tip Down00101010
    1st barrel BTN0010010X
    2nd barrel BTN0011000X

    X means don't care : can be Pen tip touch surface or just hovering.

    Total packet report :

    Report ID (fixed)0
    (7)
    0
    (6)
    0
    (5)
    0(4)0(3)0(2)1
    (1)
    0(0)
    Pen reportNULLNULLInRangeBT2ErsrBT1invrtPen
    X (Lower byte)7<-----0
    X (Upper byte)15<-----8
    Y (Lower byte)7<-----0
    Y (Higher byte)15<-----8
    pressure (Lower Byte)7<-----0
    pressure (Higher Byte)15<-----8

    X max is 21424, Y max is 13390, Pressure max is 2047. all min at 0

  • Many attempts had done, Really needs help.

    TinLethax06/25/2021 at 08:20 0 comments

    I've tried many way to report the event, but it seems like Windows and Linux has difference under the hood input HID system. BTW the HID descriptor I wrote is followed the Microsoft's Document about the necessary HID report and report sequence (hovering pen, pen down, eraser side hovering, etc...). But even I following the Microsoft's guideline. Windows is still acting weird, for example my STM32 doesn't even send the pen down bit, but windows just buggy thinking that the pen is down the whole time render this unusable.

    If anyone out there had knowledge about these USB HID report, Digitizer HID. Help would really be appreciated.

  • digitizer is now working (partially)

    TinLethax06/12/2021 at 04:38 0 comments

    Couple minutes ago I finally get the USB HID work ! By changing the USB device name from "Wacom Rip off" to "Wac0m Rip off". I still had no idea why this change make the cursor actually move (as I said earlier that the "evtest" did shows event report). But I suspect that the word "Wacom" is used for driver probing (grep from device name to load driver, Name match ?).

    Anyway, There're main 3 problems

    1. Y axis is inverted

    2. Hovering the pen over the pad does generate event, but cursor doesn't move along unless pen tip is down

    3. Sometime Eraser side works with randomly having problem from number 2

    The 2 latest commits are on my GitHub repo. 

  • USB HID is now report correctly

    TinLethax06/11/2021 at 14:25 0 comments

    I be able to get the STM32 to report the USB HID event correctly, But still can't move the cursor on both Windows 10 and Linux (Debian X.org). but for some reason, it's behaving like relative mouse on Android 11 (My Xperia 10 II). So anyway, the code is already on my GitHub repo.

  • Code on GitHub.

    TinLethax06/08/2021 at 13:24 0 comments

    Here's the code I just push to my repo on GitHub, Note that I'm using the STM32F3 Discovery board (DISCO). here's the repo https://github.com/TiNredmc/WacomRipoff

  • STM32 as USB HID and interfacing the w9013

    TinLethax06/08/2021 at 12:55 0 comments

    Yesterday I've been working with my STM32F3 Disco board to interface with the w9013 chip on the Wacom i2c digitizer. By far, I wrote the HID descriptor and be able to send packet to the host. but I still have problem interfacing with w9013 (probably I2C pull up problem). I will create new GitHub repo of this soon.

View all 10 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates