Category Archives: Uncategorised

HUSQVARNA rip-off pricing in NZ

So, I came across an interesting, but not surprising thing with Husqvarna MSRP prices in NZ compared to USA.

I recently looked at Husqvarna 445 and when googled for it, I got multiple MSRP prices (one for NZ, on for AU and another for USA).

Husqvarna 445 MSRP by country:
USA: 329.95 USD

AU: 899.00 AUD (~$690 USD)

NZ: 1019.00 NZD (~$745 USD)

According to NZ customs duty calculator using US MSRP price as base the fair MSRP price in NZ should have been $599 NZD (~$440 USD).

What is with the ~$150 USD price difference between NZ and Australia? According to Husqvarna Americans are twice better than Australians and more than twice better than Kiwis. They treat Kiwis like chumps that will buy thing at whatever prices Husqvarna feels like.

Guess what, from now on I will be avoiding the Husqvarna until these greedy corporate types will pull their heads out of their asses and set fair MSRP prices. In this global economy it is very stupid not to have standardised prices across the globe.

If I really wanted to buy one, no way in hell I would be buying it in NZ, as for about $150NZ I can get it shipped from the states.

Cross-flash M1015/9420-8i LSI controller quasi-official way

WARNING: don’t blame me if you brick your card ;).

Building large cost effective storage solutions present a problem: lack of cost effective HBAs.
The solution to this problem is an interesting controller from IBM/Lenovo M1015. These can be bought for about 70USD on ebay.
The only problem with that controller is that the firmware it comes with (aka WebBIOS) is utter crap.
This problem can be resolved thanks to LSI providing alternative firmware images.

I generally flash these cards in Pass-Through mode, as they are not suitable for hardware raid scenario (lack of battery and RAM). Besides in low cost situation it is far better to use mdadm RAID (or ZFS) than hardware RAID (due to flexibility in reshaping, monitoring and fault recovery). With hardware RAID you simply cannot start with 3-disk RAID5 and grow it a disk at a time to 12-disk RAID6 without moving data to another storage.

I decided to write this guide as I could not find a guide that would use the tools and firmware images directly acquired from official sources (LSI/Avago/Broadcom).

All the guides include their own download links, which present security (malware) and possible bricking issues (if images were corrupted).

The goal of this guide is to stick to only files sourced from LSI (now Broadcom) as well as avoiding using Windows (Linux friendly).
By the time someone reads this the version and links will change so I am including search keywords on how to find the files in question.

I will be focusing on Pass-Through mode firmware (IT mode), but the only difference to IR mode is the 2118it.bin vs 2118ir.bin.

Continue reading

Prezzy card scam

A while ago I was gifted a prezzy card. These buggers:
They are actually Kiwi bank.
This prezzy card is not accepted in many places. In addition it needs to be activated.
I was putting it off, until the bloody thing expired.

So these bastards take legal tender (that does not have expiry) and set expiry on it.
I simply see no point of these things as cash is accepted pretty much everywhere, and it can also be deposited in your account (stating obvious here).

What these gift card/prepay debit cards companies rely on is chumps like me that let their cards expire.
This is a very shady business model.

So if you want to be a good friend and want to gift some cash, just gift the cash. No prezzy card or Dicksmith gift cards or any other stupid vouchers, thank you very much.

As for Kiwibank – shame on you for supporting such scam.

Reverse engineering Hikvision SADP Tool (now with script!)

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: 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.

ILDVR INC-MH40D06 or hacking cheap chinese camera part 2

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-hpa

It 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):


I 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

set env ipaddr
set env serverip
set env netmask

Then I put the mapped flash via tftp to the tftp server:

tftp 0x82000000 rootfs 0x200000

Once 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 0x200000

WARNING: Don't get the size/offset wrong as you will have bad times!