A while ago I picked up a ScoutGuard 550 wildlife camera with the grand plan of capturing interesting wildlife in local woods.
Fast forward a couple of years and with nothing but pigeon shots to show I decided to have a go at tackling one of the features always bugged me. Each photo has a logo in the bottom left corner. In reality this isn't a big deal but it did strike me as slightly annoying since I'd paid for the camera and I shouldn't have to advertise on their behalf.
An example shot from google (not mine) showing the logo.
A quick google for "scoutguard firmware" lead to this page which contained a link to an updated firmware package and install instructions. Excellent. The firmware wasn't even packaged, it was just the raw binary blob and it loaded up perfectly in IDA. Tracking down the offending code was just a case of finding the cross reference to the ScoutGuard string.
If I'd been paying full attention at this point I would have realised that my camera only displayed "ScoutGuard" and not "HCO ScoutGuard". It turns out that there are many different versions of the ScoutGuard camera around (despite them all having the same model number) and they apparently have different firmware. The procedure to load the firmware varies between models too. Some instructions state that simply copying the firmware onto the root of the SD card and rebooting is sufficient, while other models require plugging in USB as well as the controller and then copying the firmware over USB. This isn't an option on my device since the USB and controller ports are combined into a single 10 pin USB mini connector.
Since the software only route was out, it was time to look at the hardware.
The photo below is the main board. Ignore the glue blob, that was an attempt at ghettotronics over some test pads (more on those in a later post).
The four points next to the glue blob however scream out serial port and a quick test verified this was the case.
The output from the serial console was just general debugging information and nothing overly helpful, but restarting the camera with the controller and SD card plugged in presented me with a useful (although extremely minimal) debug console. Basically there were options to read from or write to memory. The read option dumped out data in the fairly typical hex output format of <address> : <bytes> <ascii>:
UNZOK!
Loader NT96210 Start ...
Loader v1.0 02/02/2010 17:11:36
----------------------------------------------------
Novatek NT96210
Copyright (c) 2004 Novatek Microelectronic Corp.
Kernel ver: 2.00.003, build: Aug 18 2009, 18:09:51
Driver ver: 2.00.002, build: Dec 09 2009, 20:31:03
Application ver: 2.00.002, build: Jul 24 2009, 12:06:00
Project ver: 1.00.000, build: 20070511
----------------------------------------------------
> ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: WAV: Invalid bits per sample value
ERR: pIconParam->uiIconID= 175
ERR: Icon Width > Rectangle Width.
>
h : display help message
? : display help message
r 0xHex_Address [0xHex_Length]: read contents of memory
w 0xHex_Address 0xHex_Data : write data to memory
> r 0 150000
addr = 0x00000000, length = 0x00150000
00000000 : E59FF000 E59FF018 E59FF018 E59FF018 ................
00000010 : E59FF018 E59FF018 E59FF018 E59FF018 ................
00000020 : 0001DF3C 0001DCE0 0001DCE8 0001DD04 <...............
00000030 : 0001DD0C 00000000 0001DE10 0001DD18 ................
00000040 : EB005FB4 EAFFFFFE E1A00000 E1A00000 ._..............
00000050 : 3639544E 20303132 30302E31 3030302E NT96210 1.00.000
00000060 : 37303032 31313530 00114C48 F3A8AA55 20070511HL..U...
00000070 : 00000000 00000000 00000000 00000000 ................
00000080 : 5A5A5A5A 000008AC 00000FFF 000000FF ZZZZ............
00000090 : 02331103 98101010 98101028 3020049F ..3.....(..... 0
000000A0 : 84C30201 3020049F 84C30201 97100000 ...... 0........
000000B0 : 97100014 00000000 00000000 00000000 ................
This output was being logged by putty so it just took a quick bit of python to turn the text back into binary and I had a copy of the RAM image that could be loaded into IDA.
Comparing my image against the firmware I'd downloaded showed that (unsurprisingly) there were quite a few similarities but there were sufficient differences to make it clear that this wasn't just a recompile with a few minor modifications. I'd guess that the OEM provides basic libraries and that vendors like HCO are left to customise the code however they like. For instance, the code that prints text to the screen is functionally identical (only differences are due to compiler optimisation settings) yet the code that calls this function (the code that picks up the text for the logo) is significantly different.
Getting back to the mission goal though, a quick search through the image found that the ScoutGuard string I was after was located at 0x3cf44:
0003CF40 : 000F8430 6F635320 75477475 20647261 0... ScoutGuard
0003CF50 : 00000000 0011AB44 0011AB47 001118A4 ....D...G.......
0003CF60 : E92D4FF0 E1A04000 E59F0548 E1A05001 .O-..@..H....P..
0003CF70 : E5D00000 E59F1538 E24DD034 E0811100 ....8...4.M.....
Setting the string to null provided the desired result - no logo:
An example shot from google (not mine) showing the logo.
A quick google for "scoutguard firmware" lead to this page which contained a link to an updated firmware package and install instructions. Excellent. The firmware wasn't even packaged, it was just the raw binary blob and it loaded up perfectly in IDA. Tracking down the offending code was just a case of finding the cross reference to the ScoutGuard string.
If I'd been paying full attention at this point I would have realised that my camera only displayed "ScoutGuard" and not "HCO ScoutGuard". It turns out that there are many different versions of the ScoutGuard camera around (despite them all having the same model number) and they apparently have different firmware. The procedure to load the firmware varies between models too. Some instructions state that simply copying the firmware onto the root of the SD card and rebooting is sufficient, while other models require plugging in USB as well as the controller and then copying the firmware over USB. This isn't an option on my device since the USB and controller ports are combined into a single 10 pin USB mini connector.
Since the software only route was out, it was time to look at the hardware.
The photo below is the main board. Ignore the glue blob, that was an attempt at ghettotronics over some test pads (more on those in a later post).
The four points next to the glue blob however scream out serial port and a quick test verified this was the case.
The output from the serial console was just general debugging information and nothing overly helpful, but restarting the camera with the controller and SD card plugged in presented me with a useful (although extremely minimal) debug console. Basically there were options to read from or write to memory. The read option dumped out data in the fairly typical hex output format of <address> : <bytes> <ascii>:
UNZOK!
Loader NT96210 Start ...
Loader v1.0 02/02/2010 17:11:36
----------------------------------------------------
Novatek NT96210
Copyright (c) 2004 Novatek Microelectronic Corp.
Kernel ver: 2.00.003, build: Aug 18 2009, 18:09:51
Driver ver: 2.00.002, build: Dec 09 2009, 20:31:03
Application ver: 2.00.002, build: Jul 24 2009, 12:06:00
Project ver: 1.00.000, build: 20070511
----------------------------------------------------
> ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: AVI: not open yet.
ERR: Usicd_Close
ERR: WAV: Invalid bits per sample value
ERR: pIconParam->uiIconID= 175
ERR: Icon Width > Rectangle Width.
>
h : display help message
? : display help message
r 0xHex_Address [0xHex_Length]: read contents of memory
w 0xHex_Address 0xHex_Data : write data to memory
> r 0 150000
addr = 0x00000000, length = 0x00150000
00000000 : E59FF000 E59FF018 E59FF018 E59FF018 ................
00000010 : E59FF018 E59FF018 E59FF018 E59FF018 ................
00000020 : 0001DF3C 0001DCE0 0001DCE8 0001DD04 <...............
00000030 : 0001DD0C 00000000 0001DE10 0001DD18 ................
00000040 : EB005FB4 EAFFFFFE E1A00000 E1A00000 ._..............
00000050 : 3639544E 20303132 30302E31 3030302E NT96210 1.00.000
00000060 : 37303032 31313530 00114C48 F3A8AA55 20070511HL..U...
00000070 : 00000000 00000000 00000000 00000000 ................
00000080 : 5A5A5A5A 000008AC 00000FFF 000000FF ZZZZ............
00000090 : 02331103 98101010 98101028 3020049F ..3.....(..... 0
000000A0 : 84C30201 3020049F 84C30201 97100000 ...... 0........
000000B0 : 97100014 00000000 00000000 00000000 ................
This output was being logged by putty so it just took a quick bit of python to turn the text back into binary and I had a copy of the RAM image that could be loaded into IDA.
Comparing my image against the firmware I'd downloaded showed that (unsurprisingly) there were quite a few similarities but there were sufficient differences to make it clear that this wasn't just a recompile with a few minor modifications. I'd guess that the OEM provides basic libraries and that vendors like HCO are left to customise the code however they like. For instance, the code that prints text to the screen is functionally identical (only differences are due to compiler optimisation settings) yet the code that calls this function (the code that picks up the text for the logo) is significantly different.
Getting back to the mission goal though, a quick search through the image found that the ScoutGuard string I was after was located at 0x3cf44:
0003CF40 : 000F8430 6F635320 75477475 20647261 0... ScoutGuard
0003CF50 : 00000000 0011AB44 0011AB47 001118A4 ....D...G.......
0003CF60 : E92D4FF0 E1A04000 E59F0548 E1A05001 .O-..@..H....P..
0003CF70 : E5D00000 E59F1538 E24DD034 E0811100 ....8...4.M.....
Setting the string to null provided the desired result - no logo:
This is a photo of the ceiling which is actually white. The colour balance is all wrong due to the camera being in low light mode but the IR LEDs were disconnected.
Despite the main goal being achieved, this isn't exactly a practical solution since the string has to be modified in RAM each time the device boots. One option would be to hook up a small microprocessor (like an ATTiny) to the serial port and use this to overwrite the string in memory when the device boots. I suspect there is sufficient room in the case to do this and it would be easy to power the chip from the power lines on the serial port. Still, it seems like an ugly solution. Replacing the firmware is still the ultimate goal and tackling that will be left to a later post.
No comments:
Post a Comment