Do you have annoying clicking (similar to seeking CD player) sound coming from inside of your Toyota dash, sometimes only happening at set heater temperature setting? It could be “indecisive” heater control servo.
Below is how I fixed the noise in a Toyota Ist (hint: it is was a problem with sliding contacts inside of the servo).
Continue reading Mysterious clicking noise inside dash of a Toyota Ist
While I was fixing indecisive heater control servo in a Toyota Ist, I discovered a wiring horror left a by a wire-twisting moron:
Continue reading Head unit wiring clean up after wire-twister
WARNING: DO NOT BUY MINI0806 UNDER ANY CIRCUMSTANCES.
You have been warned.
Here is simple reason why: out of 8 mini0806s that passed through my hands, 5 failed and one dying(failure rate >60%).
Continue reading One year with Mini0806
The script.
nvtk_mp42gpx.py
Here it is: nvtk_mp42gpx.py
Alternative version: nvtk_mp42gpx_older.py
What does it do?
This script will attempt to extract GPS data from Novatek MP4 file and output it in GPX format.
Usage: ./nvtk_mp42gpx.py -i<inputfile> -o<outfile> [-f]
-i input file (will quit if does not exist)
-o output file (will quit if exists unless overriden)
-f force (optional, will overwrite output file)In short: it takes Novatek encoded MP4 file (with embedded GPS data) and extract GPS data in GPX format (as separate file). Note; it does not modify the original MP4 file.
In long:
Box:
Camera:
GPS mount:
Mounting position:
A119 vs A118c:
A119 vs A118c vs DR400G-HDII vs Mini0806:
To be continued…
Alternative title: why my mini0806 was crashing and stopped working after a light drop.
One of the differences between mini0805 and mini0806 is this heat sink:
It is a bitch to remove, so I gently coerced it with a blade:
After some time of gentle pushing and heating it managed to peel off:
Revealing Samsung ram chip and Ambarella A7LA50 SoC:
Here is why it was not working after slight drop (and crashing before that):
Pulled out pads! Note that the blade I used to remove would cause other side of pads missing if I applied too much pressure.
My theory is following: the heat sink that bridges RAM and SoC is causing stress on these chips. Mostly because it is glued and not mechanically pressed against the chips. This is a very silly design flaw, if for example, only SoC would have the heat sink (like found on IP cameras) then there would not be any stresses. I don’t think RAM needs heat sinking on those things.
I am tempted to take dremel to my other mini and split the heat sink in two…
This is a continuation from here.
Here is the complete script that can reset any given Hikvision camera with firmware of up to 5.3 (allegedly).
The security through obscurity aspect of it, and inability to reset the camera without contacting the Hikvision support under normal circumstances puts me off the Hikvision hardware entirely.
There is an obvious problem with contacting Hikvision support, no way they will provide support for cameras bought from Aliexpress. Since password reset is not under owner’s control, it means that owner does not technically own the camera.
This script will discover the Hikvision cameras (both via UDP and magical frame 0x8033) on local L2. You can also specify to reset a camera with a specific MAC address (although it is not too difficult to modify it to own all the cameras, but I purposely left that bit out).
The script is a bit crude and inefficient (too many byte to ASCII conversions).
The reset code algorithm was lifted off here: https://www.ipcamtalk.com/hik-pw-reset.php. I had to “pythonise” it from javascript.
TL;DR: do not buy Hikvision cameras as the official password recovery involves Hikvision support, while “hackers” can own your camera once they get L2 access to your network.
After conflicting information on the net I finally purchased el-cheapo endoscope camera and took some snaps of the differential.
Pictures are crap but enough to confirm that the diff is Torsen:
What you see is the helical gear shafts (I also confirmed that by spinning the wheel and observed the shafts spinning).
If it was clutch type it would had clutches, shims and cam mechanism visible instead.
In conclusion at least my JDM GRB STI came with Torsen (and it does not look like it was after market installation as all the bolts and seals are pristine).
I got couple of Hikvision cameras that needed to have their passwords reset.
Instead of reset-to-factory default button these cameras have very elaborate password reset process.
Officially one must download SADP tool, get the serial number off the camera, fetch it to the Hikvision support, then they generate you a reset code that you plug in into the camera.
The unreliable Hikvision support can be bypassed with this tool (more details here).
I feel very dirty because I had to install the SADP in a Windows virtual machine (it does not work under Linux).
Interesting that the tool is build around QT and libpcap so technically it should not be too difficult to port it to Linux.
Looking at traffic captures the tool discovers the camera via multicast (239.255.255.250, udp port 37020) with this payload:
<?xml version="1.0" encoding="utf-8"?><Probe><Uuid>13A888A9-F1B1-4020-AE9F-05607682D23B</Uuid><Types>inquiry</Types></Probe>
The camera responds to with this:
<?xml version="1.0" encoding="UTF-8"?> <ProbeMatch><Uuid>FC25924E-AFE2-49E6-ACC9-F84A6859054D</Uuid> <Types>inquiry</Types> <DeviceType>38930</DeviceType> <DeviceDescription>DS-2CD2432F-IW</DeviceDescription> <DeviceSN>DS-2CD2432F-IW20150126CCCH502126167</DeviceSN> <CommandPort>8000</CommandPort> <HttpPort>80</HttpPort> <MAC>c0-56-e3-fe-42-92</MAC> <IPv4Address>10.1.1.251</IPv4Address> <IPv4SubnetMask>255.255.255.0</IPv4SubnetMask> <IPv4Gateway>10.1.1.1</IPv4Gateway> <IPv6Address>::</IPv6Address> <IPv6Gateway>::</IPv6Gateway> <IPv6MaskLen>64</IPv6MaskLen> <DHCP>false</DHCP> <AnalogChannelNum>0</AnalogChannelNum> <DigitalChannelNum>1</DigitalChannelNum> <SoftwareVersion>V5.2.5build 141201</SoftwareVersion> <DSPVersion>V5.0, build 140714</DSPVersion> <BootTime>2016-03-06 09:18:17</BootTime> </ProbeMatch>
This is all nice and easy to replicate, except when discovering that when resetting the password the tool talks to camera directly via ethernet frames:
Reset packet:
12:14:16.063953 52:54:00:db:ae:e4 > XX:XX:XX:XX:XX:XX, ethertype Unknown (0x8033), length 80:
0x0000: 2102 0142 0000 173a 0604 0a00 ba54 5254 !..B...:.....TRT
0x0010: 00db aee4 0a01 0102 XXXX XXXX XXXX 0a01 ........XXXXXX..
0x0020: 01fb ffff ff00 5252 5364 5264 6572 6439 ......RRSdRderd9
0x0030: 0000 a100 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 ..
Response packet:
12:14:16.094857 XX:XX:XX:XX:XX:XX > 52:54:00:db:ae:e4, ethertype Unknown (0x8033), length 260:
0x0000: 2101 01f6 0000 173a 0604 0b01 8a3b XXXX !......:.....;XX
0x0010: XXXX XXXX 0a01 01fb ffff ffff ffff 0000 XXXX............
0x0020: 0000 ffff ff00 4453 2d32 4344 3234 3332 ......DS-2CD2432
0x0030: 462d 4957 3230 3135 3031 3236 4343 4348 F-IW20150126CCCH
0x0040: XXXX XXXX XXXX XXXX XX00 0000 0000 0000 XXXXXXXXX.......
0x0050: 0000 0000 0000 0000 9812 0000 1f40 0000 .............@..
0x0060: 0001 0000 0000 5635 2e32 2e35 6275 696c ......V5.2.5buil
0x0070: 6420 3134 3132 3031 0000 0000 0000 0000 d.141201........
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 5635 2e30 2c20 6275 696c ......V5.0,.buil
0x00a0: 6420 3134 3037 3134 0000 0000 0000 0000 d.140714........
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 3230 3136 2d30 332d 3036 ......2016-03-06
0x00d0: 2030 393a 3138 3a31 3700 0000 0000 0000 .09:18:17.......
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 ......
Now looking further it appears that discovery as well as expected UDP communication there is also ethernet frame type of communication going on in parallel:
Broadcast:
12:13:29.539493 52:54:00:db:ae:e4 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x8033), length 80:
0x0000: 2102 0142 0000 1739 0604 0300 80b6 5254 !..B...9......RT
0x0010: 00db aee4 0a01 0102 ffff ffff ffff 0000 ................
0x0020: 0000 0000 0000 fe80 0000 0000 0000 889f ................
0x0030: 720d 7c8f 8429 0000 0000 0000 0000 0000 r.|..)..........
0x0040: 0000 ..
Response:
12:13:29.555356 XX:XX:XX:XX:XX:XX > 52:54:00:db:ae:e4, ethertype Unknown (0x8033), length 416:
0x0000: 2101 01f6 0000 1739 0604 0400 8c42 XXXX !......9.....BXX
0x0010: XXXX XXXX 0a01 01fb ffff ffff ffff 0000 XXXX............
0x0020: 0000 ffff ff00 4453 2d32 4344 3234 3332 ......DS-2CD2432
0x0030: 462d 4957 3230 3135 3031 3236 4343 4348 F-IW20150126CCCH
0x0040: XXXX XXXX XXXX XXXX XX00 0000 0000 0000 XXXXXXXXX.......
0x0050: 0000 0000 0000 0000 9812 0000 1f40 0000 .............@..
0x0060: 0001 0000 0000 5635 2e32 2e35 6275 696c ......V5.2.5buil
0x0070: 6420 3134 3132 3031 0000 0000 0000 0000 d.141201........
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 5635 2e30 2c20 6275 696c ......V5.0,.buil
0x00a0: 6420 3134 3037 3134 0000 0000 0000 0000 d.140714........
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 3230 3136 2d30 332d 3036 ......2016-03-06
0x00d0: 2030 393a 3138 3a31 3700 0000 0000 0000 .09:18:17.......
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 029c 5648 0a01 0101 0000 ........VH......
0x0100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0110: 0000 0000 0000 0000 0000 0000 0000 0007 ................
0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0130: 0000 0000 0000 0000 0000 0000 0000 0050 ...............P
0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0160: 0000 4453 2d32 4344 3234 3332 462d 4957 ..DS-2CD2432F-IW
0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0190: 0000
So theoretically it is possible to create a tool based on the reset password code generator to completely cut out middle man.
This is the way I see it working:
1) Discover camera and get serial number and camera ip
2) Get camera date/time via simple GET to port 80.
3) Generate reset code with camera serial number and date/time
4) send magic packet to reset camera.
I found some examples of the traffic that does not contain fe80 0000…XXXX…0000 bit at the end (looks like previous version of SADP Tool didn’t append that crap). I successfully replayed that packet.
I have noticed that the checksum does not include the source (header) of the packet, so as long as the MAC address matches in the body the header can be spoofed.
I have changed the mac address on VM where SADP Tool was running and looks like4 bytes between Source MAC and Destination MAC in the body changes. As well as 2x 2 bytes surrounding 06040300.
If I increment any number by one and decrement @ 0x0018 the packet gets response. This implies that the check sum is only 2 bytes long.
So far I figured out the check sum for older type of discovery packet (without crap at the end of the packet).
the check sum is located here:
0x0010: 00db aee4 0a01 0102 ffff ffff ffff 0000
In this example it is 0102.
Actually the check sum is 0201 (reversed order).
The check sum algorithm is 16-bit one’s complement.
The trick (which was given away by comparing sequential packets) is to ignore the header, and to reverse order in these two bytes:
0x0000: 2102 0142 0000 1739 0604 0300 80b6 5254
in example above they are check-summed as b680.
Next step is to see if I can apply the same method to the password reset packet….
At this stage I solved the following: discovery via frames, discovery via UDP, generate reset code and reset the camera via frame.
There is a potential problem to get camera time reliably (in case it is not configured in same subnet).
After poking around Sadp.dll I found these interesting XML strings:
<?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><Types>inquiry</Types></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><Types>update</Types><MAC>%s</MAC><Password>%s</Password><IPv4Address>%s</IPv4Address><CommandPort>%d</CommandPort><HttpPort>%d</HttpPort><IPv4SubnetMask>%s</IPv4SubnetMask><IPv4Gateway>%s</IPv4Gateway><IPv6Address>%s</IPv6Address><IPv6Gateway>%s</IPv6Gateway><IPv6MaskLen>%d</IPv6MaskLen><DHCP>%s</DHCP></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><MAC>%s</MAC><Types>reset</Types><Code>%s</Code></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><MAC>%s</MAC><Types>reset</Types><Code>%s</Code><Password>%s</Password></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><MAC>%s</MAC><Types>reset</Types><SyncIPCPassword>true</SyncIPCPassword ><Code>%s</Code><Password>%s</Password></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><MAC>%s</MAC><Types>getcode</Types></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><MAC>%s</MAC><Types>exchangecode</Types><Code>%s</Code></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><MAC>%s</MAC><Types>activate</Types><Password>%s</Password></Probe> <?xml version="1.0" encoding="utf-8"?><Probe><Uuid>%s</Uuid><MAC>%s</MAC><Types>getencryptstring</Types></Probe>
None of that proved to be useful of extracting local time (except inquiry).
ILDVR INC-MH40D06 or hacking cheap chinese camera part 2 (or unbricking the camera via uBoot).
While was poking around, I managed to brick the camera.
I tried to change the /etc/password on rootfs, unfortunately due to nature jffs2 small changes to file system are not quiet possible if there is not enough space of erase block size increment (in this case it was 64k).
I moved away udevadm to be able to change /etc/passwd only to find I could not move it back or change the /etc/password anyway.
Any attempt led to No space left on device. I put this to my lack of experience with jffs2. At that stage I knew camera was bricked. I saved udevadm binary which I moved away via wget (I moved it to the /mnt/flash/web/browse/ which made it accessible via http). I confirmed it was bricked after reboot (no networking due to unable to mount the flash partitions, as udev was not setting up the block devices in /dev).
Now, I knew that not everything was lost, since I still had uBoot working.
Specifically there was tftp tool to upload/download memory chunks to tftp server.
Since I am using Ubuntu I installed tftp server:
apt-get install tftpd-hpaIt took me awhile to figure out how to read and write to flash (the give away was sf probe 0;sf read 0x82000000 0x50000 0x2b0000;bootm 0x82000000 as bootcmd).
To map the flash memory into a specific address in RAM of specific offset of flash memory (flash address) and specific length (flash partition size):
sf read $MEMORY_ADDRESS $FLASH_OFFSET $SIZEI use the default address of 0x82000000 (no idea how it is determined normally, I guess it is high enough not to interfere with uBoot?).
For Flash Offset and size I used data from cat /proc/mtd
If these things are unknown I guess it is possible to infer them from bootcmd or by dumping the whole flash and then binwalk (I haven't tried this).
the /proc/mtd looked like this:
dev: size erasesize name
mtd0: 00050000 00010000 "boot"
mtd1: 002b0000 00010000 "kernel"
mtd2: 00200000 00010000 "rootfs"
mtd3: 00b00000 00010000 "data"
Rest is simple arithmetic:
The partition I was after was mtd2 (rootfs), so the offset worked out to 0x50000+0x2b0000=0x300000 (mtd0 + mtd1) the size is 0x20000.
To map the mtd2 to memory I ran following:
sf probe 0
sf read 0x82000000 0x300000 0x200000
Note: sf probe 0 needed to initialise flash.
I changed the ip address/netmask and tftp server address via this command (my tftp server is on 192.168.1.2):
set env ipaddr 192.168.1.200
set env serverip 192.168.1.2
set env netmask 255.255.255.0Then I put the mapped flash via tftp to the tftp server:
tftp 0x82000000 rootfs 0x200000Once I had the image I loaded into mtd device emulation on local machine. This is where erasesize comes handy (found in /proc/mtd earlier): 0x10000 = 64KiB.
To setup mtd device on a linux box you need to do the following:
modprobe mtdram total_size=2048 erase_size=64
modprobe mtdblock
modprobe jffs2
dd if=/var/lib/tftp/rootfs of=/dev/mtdblock0
mkdir /tmp/target
mount -t jffs2 /dev/mtdblock0 /tmp/target/You might need to install mtd and jffs2 related packages: apt-get install mtd-utils
If it complains about "wrong superblock" while attempting to mount jffs2 most likely you got size/offset wrong when you ran sf read.
Once you have file system mounted copy it into a directory for future manipulations.
In the copy I fixed the /etc/passwd. I copied in the udevadm binary that I moved away.
Then I repacked the directory back into jffs2 image:
mkfs.jffs2 -r ~/rootfs_ipcam -e 64 -n -m size -o /var/lib/tftpboot/rootfs_fixed
Only to find out that the image turned out to be larger then the target size of 2MiB. I guess they used proprietary tools to build their jffs2 to cram it right into 2MiB. I was off by 140KiB or so. I managed to reclaim space by removing mkfs.fat and e2fsck (since this particular camera does not have physical SD-Card slot). Alternative was getting all partitions and re-shuffling the layout (relatively easy, but tedious).
Once I had the image built I confirmed that was OK by mounting the same way as original image.
The final step was downloading new image via tftp and flashing it:
tftp 0x82000000 rootfs_fixed
sf erase 0x300000 0x200000
sf write 0x82000000 0x300000 0x200000WARNING: Don't get the size/offset wrong as you will have bad times!