Unbricking AliExpress digital peephole
I came across a Tuya wireless digital peephole that got bricked during a Wi-Fi pairing process. Since then, it’d been stuck in a reboot loop with no way to perform a factory reset. Yes, the product’s developer forgot to add any hardware reset button. After turning the device on, the display briefly shows the camera feed before freezing, and the device keeps rebooting.
First look
Disassembly is fairly easy, just 3 + 4 small screws. Be cautious when disconnecting the display flexible flat cable and the Wi-Fi antenna from the PCB, as they are pretty delicate. The battery is attached to the bottom side of the PCB.
A quick inspection of both sides of the PCB reveals that two SoCs are present - one labeled Goke GK7202V300 and the other a Hi3861 module. The Goke SoC is the brain of the device, while the HiSense Hi3861 is the Wi-Fi module.
Luckily, at the top of the PCB there are labeled UART pads. Two sets of them, one for Goke on the left, the other for the Wi-Fi module. These may help us figure out what the issue may be.
Listening to Serial
To communicate with the device, I used a CP2102 USB to UART converter, which operates at 3.3V on TXD/RXD pins. According to the Goke product features page, it also uses 3.3V on I/O pins:
Operating voltage: (Core voltage: 0.9v / IO voltage: 3.3v / SDRAM voltage: 1.8 v)
Always be cautious with I/O voltages! If unsure, peek into datasheets (which are rather sparse for Goke chips), and use a voltmeter. You can either destroy your UART converter or the device SoC if the voltages don’t match.
When soldering wires to the pads, make sure the battery is disconnected and safely put away. Wire RXD pad to TXD pin, TXD pad to RXD pin, and GND to GND. Plug the USB converter in.
Any serial terminal emulator can be used - PuTTY if you’re on Windows, screen, minicom, picocom on Linux. Select correct COM port and set speed to 115200 bauds, and parameters to 8n1 (8 data bits, 1 stop bit, no parity bit). You need to connect the battery back to the device. Then, turn the device on and you should see a boot sequence in the terminal. Also, nothing burnt, so I guess the product page provided correct voltage information.
Let’s take a look at the first output:
DRAM: 2823 init
********Hello RTOS********
version : RTOS UP
open-version : RTOS 3.3.6
build data : Feb 9 2
RTOS # Mount procfs finished.
Spi Nor ID:0xEF 0x60 0x17 0x00 0x00 0x00 0x00 0x00
Spi is locked. lock address[0 => 0x80000]
Spi Nor Flash Info:
Name:"W25Q64FW" Size:8MB Block:64KB
******** usb_init in **********
usb v3.05 2019-10-22 09:32
XHCI: 64 bytes context size, 32-bit DMA
usbus0: 5.0Gbps Super Speed USB v3.0
******** usb_init ok**********
Vendor Watchdog Timer: 0.01 initialized. default_margin=60 sec (nodeamon= 0)
wtdg init ok. ver=Mar 29 2022, 01:09:21uhub0: <vendor 0x0000 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
.
system will config syslink gpio mux.
PDT_ENXUN_DOORBELL
[01-01 00:00:00.107 ERROR-]:PDT_SYSLINK_Init[319]:gk_syslink_init fail ret 68690008
[01-01 00:00:00.110 ERROR-]:PDT_SYSLINK_Init[320]:SYSLINK CLK GPIO4_0
[sl-error][m:0x01][l:523],syslink unexist!
[sl-info][m:0x01][l:476],syslink version 1.2.0
system will config syslink gpio mux.
PDT_ENXUN_DOORBELL
[sl-info][m:0x01][l:241],eb
[sl-info][m:0x01][l:241],57
[sl-info][m:0x01][l:241],96
[sl-info][m:0x01][l:241],ae
[sl-info][m:0x01][l:241],cb
[sl-info][m:0x01][l:241],0b
[sl-info][m:0x01][l:241],89
[sl-error][m:0x01][l:230],boot info error!
- snip -
received boot int,len:8,msg:poweron
hisyslink sucess!
system will config syslink sdio mux.
level: 3, bp_level_max: 7
[sl-info][m:0xa4][l:281],message proc thread run
[sl-info][m:0xa7][l:38],nid:1 set_chn_alive ok
Spi is locked. lock address[0 => 0x80000]
[sl-info][m:0xa7][l:127],osal_proc_mkdir - parent is NULL! proc=0x408f0f60
LOCAL_ID=0
<6>Vendor Media Memory Zone Manager
[sl-info][m:0xa2][l:181],host gpio recv thread run
load sys.ko OK!
load region.ko OK!
load vgs.ko OK!
load isp.ko OK !
load vi.ko OK !
load vpss.ko OK!
load vo.ko OK!
load rc.ko OK!
load venc.ko OK!
load chnl.ko OK!
load vedu.ko OK!
load h264e.ko OK!
load h265e.ko OK!
load jpege.ko OK!
load ive.ko OK!
load aio.ko ....OK!
load ai.ko ....OK!
load ao.ko ....OK!
load aenc.ko ....OK!
load adec.ko ....OK!
load mipi_rx driver successful!
load acodec.ko ....OK!
Mount jffs on nor.
Mount jffs on nor finished.
enLogLevel= 2, enLogOn=0
lsadc init ok. ver=Mar 29 2022, 01:09:21.
initlializing pwm...
pwm_motor_pulse_interval = 100000
semMCreate, opt = 9
avEncInit start, sensorMode = 26
GetFullLinesStdFromSensorType=1350
GC2053_SENSOR_1080P_30FPS_LINEAR_MODE
GetFullLinesStdFromSensorType=1350
VENC INIT OK!
ISP INIT OK!
AudioDet Sens: 3
----------------soundDetectInit: sensitivity[98]
bIrcut = 0
rtc init ok. ver=May 31 2021, 18:04:46.
[00:00:00:177 DEBUG-camflash]:FLASH_EMMC_Init[78]:EMMC is not supported
[00:00:00:179 DEBUG-CamFlash]:CAM_FLASH_Read[319]:HANDLE=0, Address=0x7e0000, Len=0x10000
[00:00:00:188 DEBUG-CamFlash]:CAM_FLASH_Read[321]:totalread =0x10000, end.
[00:00:00:193 DEBUG-CamFlash]:CAM_FLASH_Read[319]:HANDLE=1, Address=0x7f0000, Len=0x10000
[00:00:00:203 DEBUG-CamFlash]:CAM_FLASH_Read[321]:totalread =0x10000, end.
[00:00:00:209 DEBUG-CamFlash]:CAM_FLASH_Write[347]:HANDLE=0, Address=0x7e83b0, Len=0xd0
[00:00:00:217 DEBUG-CamFlash]:CAM_FLASH_Write[349]:totalwrite =0xd0, end.
[00:00:00:223 DEBUG-CamFlash]:CAM_FLASH_Write[347]:HANDLE=1, Address=0x7f83b0, Len=0xd0
[00:00:00:231 DEBUG-CamFlash]:CAM_FLASH_Write[349]:totalwrite =0xd0, end.
TUYA Start Init!!Dbg:channel_enable:1 1 0
Dbg:fps:20
Dbg:gop:20
Dbg:bitrate:1024 kbps
Dbg:video_main_width:1920
Dbg:video_main_height:1080
Dbg:video_freq:90000
Dbg:video_codec:4
Dbg:audio_codec:106
Dbg:audio_sample:8000
Dbg:audio_databits:16
Dbg:audio_channel:0
Dbg:init ring buffer Channel:0 Enable:1
Dbg:video_bitrate 1024, video_fps 20
Dbg:init ring buffer success. channel:0
Dbg:init ring buffer Channel:1 Enable:1
Dbg:video_bitrate 512, video_fps 20
Dbg:init ring buffer success. channel:1
Dbg:init ring buffer Channel:2 Enable:0
Dbg:init ring buffer Channel:3 Enable:0
Dbg:init ring buffer Channel:4 Enable:0
Dbg:init ring buffer Channel:5 Enable:0
Dbg:init ring buffer Channel:6 Enable:0
Dbg:init ring buffer Channel:7 Enable:0
Dbg:init ring buffer Channel:8 Enable:0
Dbg:init ring buffer Channel:9 Enable:1
Dbg:AUDIO audio_sample 8000, audio_databits 16, audio_fps 25
Dbg:init ring buffer success. channel:9
Dbg:init ring buffer Channel:10 Enable:0
Dbg:init ring buffer Channel:11 Enable:0
Dbg:init ring buffer Channel:12 Enable:0
Dbg:init ring buffer Channel:13 Enable:0
Dbg:init ring buffer Channel:14 Enable:0
Dbg:init ring buffer Channel:15 Enable:0
static dns for h2.iot-dns.com
num 1: a20e0e92
num 2: 379f4d6
num 3: 12c32cf7
num 4: 378a63b
num 8: 3419a69b
num 9: 22d691ec
num 10: 239ba6d6
num 14: 3419a69b
num 15: 22d691ec
[01-01 18:12:15:0 TUYA Debug][tuya_iot_com_api.c:96] init fs. Path: /home/
[01-01 18:12:15:7 TUYA Info][kv_storge.c:43] Init Kvs With File:/home/
[01-01 18:12:15:13 TUYA Debug][simplekv.c:916] path:/home/
[01-01 18:12:15:19 TUYA Debug][simplekv.c:952] get encrypt_key[- REDACTED -]
[01-01 18:12:15:26 TUYA Debug][simplekv.c:983] both file exist
[01-01 18:12:15:31 TUYA Debug][simplekv.c:280] size in: 0 and final: 28700 And mag_rec_max: 512
[01-01 18:12:15:40 TUYA Debug][simplekv.c:295] create data hd success
[01-01 18:12:15:46 TUYA Debug][simplekv.c:1026] read from normal file
[01-01 18:12:15:53 TUYA Debug][simplekv.c:736] curr db is V2. No need to upgrade
[01-01 18:12:15:61 TUYA Debug][simplekv.c:526] head check success
[01-01 18:12:15:66 TUYA Debug][simplekv.c:629] read and check head success
[01-01 18:12:15:74 TUYA Debug][simplekv.c:1041] read from normal file success
[01-01 18:12:15:80 TUYA Debug][uni_thread.c:161] Init Thread Del Mgr
[01-01 18:12:15:86 TUYA Debug][simplekv.c:1079] init from normal file success.
[01-01 18:12:15:93 TUYA Debug][uni_thread.c:220] Thread:sys_timer Exec Start. Set to Running Status
[01-01 18:12:15:102 TUYA Debug][sys_timer.c:63] system timer has been inited
[01-01 18:12:15:109 TUYA Debug][sys_timer.c:34] system timer process run.
[01-01 18:12:15:116 TUYA Debug][sys_timer.c:63] system timer has been inited
[01-01 18:12:15:123 TUYA Debug][sys_timer.c:63] system timer has been inited
[01-01 18:12:15:130 TUYA Err][online_log_serv.c:317] log stats ufread fail.
[01-01 18:12:15:137 TUYA Debug][uni_thread.c:220] Thread:cmmod Exec Start. Set to Running Status
[01-01 18:12:15:145 TUYA Debug][online_log_serv.c:581] log serv init success
[01-01 18:12:15:152 TUYA Debug][ty_work_queue.c:22] init work queue. stack size:2560 pro:3 num:2
[01-01 18:12:15:161 TUYA Debug][ty_work_queue.c:27] ty work queue create success
Set Country Code:CN
unm_set_dns_cache_priority ->2
unm_set_dns_region 2
[01-01 18:12:15:176 TUYA Err][tuya_ipc_video_msg.c:686] init video msg success
WIFI Set Mode 2
---------hwl_wf_station_connect-----------
Upon reviewing the output, an experienced eye spots hints of U-Boot sequence,
LiteOS and Tuya SDK. The process stops with hwl_wf_station_connect and
after a short time is interrupted (let’s assume by a watchdog) and rebooted in a
cycle. This roughly corresponds with the statement mentioned at the beginning,
that the device was bricked during an unsuccessful attempt to pair with the
Wi-Fi network.
Entering the bootloader
It is sometimes possible to backup and restore firmware from within the
bootloader shell. To enter it, you need to smash Enter and / or B key during
very early boot process. Once you’re in, you can use commands such as help or
printenv. The firmware contents can be extracted from the device over the
network if the bootloader has access to Ethernet, via an SD card, or through the
YMODEM protocol. Unfortunately, in this case none of these options were
possible, because the bootloader got stuck and restarted every time after minute
or so. I therefore had to move on to the next step.
You can also enter bootloader in firmware update mode by shorting two pads at the upper left corner on top side of the PCB (see picture below) during start up. It (probably) allows flashing firmware from SD card.
Extracting the firmware
First things first, we need to read the intact original contents of our flash memory into a binary file. This will allow any reverse engineering, analysis and modifications we need to make.
The flash on the board is Winbond 25Q64JWSIQ which is a 64Mb NOR type flash memory. To read the firmware from the flash memory, I used a cheap CH341A programmer in SPI mode with 3.3V to 1.8V converter module and a SOIC8 clip. This clip will allow you to comfortably read the flash without any soldering.
A gentle reminder about voltages, again! Read the flash memory datasheet before connecting it to anything. If you exceed maximum ratings, the flash memory will get fried.
Get your packages ready. You’ll need binwalk, flashrom, jefferson,
mtd-utils-jffs.
Perform the read out by running the following command in your shell:
flashrom --programmer ch341a_spi --read goke_original_fw.bin
Analysing the firmware
binwalk goke_original_fw.bin
binwalk utility is the most effective first step to find out what we’re
working with. It reveals two binaries related to the bootloader (u-boot.bin)
and the main program (p2pcam.bin). Then, several JFFS2 data partitions which
may hold some configuration (JFFS2 is a filesystem optimized for flash memories
of embedded devices):
/home/user/work/goke_original_fw.bin
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
17952 0x4620 gzip compressed data, original file name: "u-boot.bin", operating system: Unix, timestamp: 2022-10-22 10:45:00, total size: 63014
bytes
115344 0x1C290 gzip compressed data, original file name: "u-boot.bin", operating system: Unix, timestamp: 2022-10-22 10:47:22, total size:
159794 bytes
524304 0x80010 gzip compressed data, original file name: "p2pcam.bin", operating system: Unix, timestamp: 2023-10-12 06:29:16, total size:
3743706 bytes
6225920 0x5F0000 JFFS2 filesystem, little endian, nodes: 138, total size: 262140 bytes
6583180 0x64738C JFFS2 filesystem, little endian, nodes: 3, total size: 432 bytes
6684672 0x660000 JFFS2 filesystem, little endian, nodes: 29, total size: 65532 bytes
6981096 0x6A85E8 JFFS2 filesystem, little endian, nodes: 278, total size: 817688 bytes
8192012 0x7D000C JFFS2 filesystem, little endian, nodes: 37, total size: 65520 bytes
8257568 0x7E0020 gzip compressed data, operating system: Unix, timestamp: 1970-01-01 00:00:00, total size: 174 bytes
- snip -
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Analyzed 1 file for 85 file signatures (187 magic patterns) in 49.0 milliseconds
Let’s extract all the data and inspect it quickly:
binwalk -e goke_original_fw.bin
tree extractions | less
The most interesting part is the contents of the JFFS2 filesystems. There are mostly some sound files, insignificant configuration files, CA certificates, camera calibration data, etc. So what now?
extractions
├── goke_original_fw.bin -> /home/user/work/goke_original_fw.bin
└── goke_original_fw.bin.extracted
├── 1C290
│ └── decompressed.bin
├── 4620
│ └── decompressed.bin
├── 5F0000
│ └── jffs2-root
│ ├── chmemcfg
│ ├── di.wav
│ ├── eye.conf
│ ├── hardinfo.bin
│ ├── hwcfg.ini
│ ├── image
│ │ └── OS02G10
│ │ ├── 3DNR_X_MANUAL_DEBUG_day_ISO100.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_day_ISO1600.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_day_ISO200.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_N_ISO100.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_N_ISO1600.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_N_ISO200.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_N_ISO3200.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_N_ISO400.txt
│ │ ├── 3DNR_X_MANUAL_DEBUG_N_ISO6400.txt
│ │ └── 3DNR_X_MANUAL_DEBUG_N_ISO800.txt
│ ├── image.ini
│ ├── log_seq_stat
│ ├── low_power.wav
│ ├── mac
│ ├── NoId.wav
│ ├── one_key_call.wav
│ ├── OTA_MD5
│ ├── PasswordError.wav
│ ├── Reset.wav
│ ├── res_ivp
│ ├── RouterConnect.wav
│ ├── ServerConnect.wav
│ ├── silent_reboot
│ ├── tuya.cfgs
│ ├── tuya_enckey.db
│ ├── tuya_user.db
│ ├── UpgradeSuccess.wav
│ ├── WaitWifiConfig.wav
│ └── WiredConnect.wav
- snip -
127 directories, 166 files
(Optional) Reverse engineering fun
Of course, you can have some fun (at your own risk) with reverse engineering the main program itself:
objdump -D -b binary -m arm extractions/goke_original_fw.bin.extracted/80010/decompressed.bin
| less
strings extractions/goke_original_fw.bin.extracted/80010/decompressed.bin |
grep -i -E '(boot|dns|door|goke|home|http|los_|syslink|user|pass|wifi)' |
less
Take your time. Again, as when analysing logs from serial terminal, you’re going to find hints of LiteOS kernel, Tuya OS / SDK, and maybe something else, too!
Factory reset
During the whole process up until now, I had multiple ideas about how to fix the issue. Burning an OpenIPC firmware being one of them. But performing factory reset should be the most straightforward way. I could not find any hidden button or PCB pads which would perform it. Diving deeper into Tuya documentation about factory reset helped.
Tuya SDK documentation
describes how factory reset is performed. We need to remove files
tuya_enckey.db, tuya_user.db and tuya_user.db_bak.
Patching
We need to delete files tuya_enckey.db and tuya_user.db, which we’ve seen in
the extractions folder. They are present in a JFFS partition at offset
0x5F0000 with total size 262140 bytes (binwalk was useful here).
Previous analysis of the firmware binary revealed the offset where the JFFS2 config partition resides, and it’s length:
- snip -
524304 0x80010 gzip compressed data,
original file name:
"p2pcam.bin",
operating system:
Unix, timestamp:
2023-10-12 06:29:16,
total size: 3743706
bytes
6225920 0x5F0000 JFFS2 filesystem,
little endian, nodes:
138, total size:
262140 bytes
6583180 0x64738C JFFS2 filesystem,
little endian, nodes:
3, total size: 432
bytes
- snip -
The partition we are looking for is at 0x5F0000 (which is 6225920 in decimal) and is 262140 bytes long. Therefore, we need to extract the data between 0x5F0000 and 0x62FFFC.
Extract the config partition from the firmware binary file:
dd if=goke_original_fw.bin of=config.jffs2 bs=1 skip=6225920 count=262140
We need to find erase size first:
jffs2dump -c -v config.jffs2 | grep -i clean
Which yields:
Cleanmarker at 0x00000000, totlen 0x0000000c
Obsolete Cleanmarker at 0x00010000, totlen 0x0000000c
Obsolete Cleanmarker at 0x00020000, totlen 0x0000000c
Obsolete Cleanmarker at 0x00030000, totlen 0x0000000c
This tells us a Cleanmarker is in the filesystem every 0x10000 bytes. Therefore, the erase size is 0x10000 bytes (which is 65536B, in other words 64kB).
Now we will mount the JFFS2 image, remove the mentioned files and re-create the image:
modprobe mtdram erase_size=64
modprobe mtdblock
dd if=config.jffs2 of=/dev/mtdblock0
mount -t jffs2 /dev/mtdblock0 /mnt
rm /mnt/{tuya_enckey,tuya_user}.db
umount /mnt
dd if=/dev/mtdblock0 of=config_new.jffs2 bs=1 count=262140
Check that the files have the same size and that they differ in the two inodes being deleted:
ls -l config.jffs2 config_new.jffs2
-rw-r--r-- 1 user user 262140 Nov 14 14:45 config.jffs2
-rw-r--r-- 1 user user 262140 Nov 14 17:07 config_new.jffs2
diff <(jffs2dump -c -v config.jffs2) <(jffs2dump -c -v config_new.jffs2)
--- /dev/fd/64
+++ /dev/fd/65
@@ -1,5 +1,8 @@
Cleanmarker at 0x00000000, totlen 0x0000000c
-Empty space found from 0x0000000c to 0x00010000
+ Dirent node at 0x0000000c, totlen 0x00000031, #pino 1, version 69, #ino 9, nsize 9, name hwcfg.ini
+ Dirent node at 0x00000040, totlen 0x00000036, #pino 1, version 70, #ino 0, nsize 14, name tuya_enckey.db
+ Dirent node at 0x00000078, totlen 0x00000034, #pino 1, version 71, #ino 0, nsize 12, name tuya_user.db
+Empty space found from 0x000000ac to 0x00010000
Obsolete Cleanmarker at 0x00010000, totlen 0x0000000c
Inode node at 0x0001000c, totlen 0x00000547, #ino 75, version 9, isize 14458, csize 1283, dsize 1303, offset 6889
Obsolete Inode node at 0x00010554, totlen 0x00000073, #ino 99, version 123, isize 29868, csize 47, dsize 4096, offset 12288
@@ -694,4 +697,4 @@
Obsolete Inode node at 0x0003f468, totlen 0x0000007a, #ino 99, version 121, isize 29868, csize 54, dsize 4096, offset 4096
Obsolete Inode node at 0x0003f4e4, totlen 0x0000007b, #ino 99, version 122, isize 29868, csize 55, dsize 4096, offset 8192
Inode node at 0x0003f560, totlen 0x00000a9c, #ino 75, version 8, isize 14458, csize 2648, dsize 2793, offset 4096
-Empty space: 65532, dirty space: 0
+Empty space: 65372, dirty space: 0
For some reason, hwcfg.ini inode is also relocated, but it correctly points to
the original #ino 9, so it shouldn’t bother us. The important thing is, that
tuya_enckey.db and tuya_user.db inodes now point to the #ino 0, which
means they are effectively deleted. The original inodes and contents remain
intact, as JFFS2 only appends new changes on top of existing ones. Only on
certain occasions garbage collection is triggered and cleans the blocks.
Now, we have the modified config partition image, we can splice it back into the firmware binary file (mind you, it needs to be at the exact same place as the original one and also exactly the same size):
cp goke_{original,modified}_fw.bin
dd if=config_new.jffs2 of=goke_modified_fw.bin bs=1 seek=6225920 conv=notrunc
Check that the files have the same size and only differ in the config partition:
ls -l goke_original_fw.bin goke_modified_fw.bin
-rwxr-xr-x 1 user user 8388608 Nov 14 17:10 goke_modified_fw.bin
-rwxr-xr-x 1 user user 8388608 Nov 7 19:22 goke_original_fw.bin
diff <(binwalk goke_original_fw.bin) <(binwalk goke_modified_fw.bin)
2c2
< /home/user/work/goke_original_fw.bin
---
> /home/user/work/goke_modified_fw.bin
12c12
< 6225920 0x5F0000 JFFS2 filesystem, little endian, nodes: 138, total size: 262140 bytes
---
> 6225920 0x5F0000 JFFS2 filesystem, little endian, nodes: 141, total size: 262140 bytes
47c47
< Analyzed 1 file for 85 file signatures (187 magic patterns) in 60.0 milliseconds
---
> Analyzed 1 file for 85 file signatures (187 magic patterns) in 63.0 milliseconds
Flashing the patched firmware
As a final step before testing the device is flashing the modified firmware binary back into the flash memory. This is a very sensitive task.
flashrom --programmer ch341a_spi --write goke_modified_fw.bin
flashrom v1.5.1 on Linux 6.12.31-0-lts (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Updating flash chip contents... Erase/write done from 0 to 7fffff
Verifying flash... VERIFIED.
Testing the device
Finally, assemble the device and power it on. It should now enter a pristine network pairing mode. See if it works. In my case, it worked perfectly!
