The first built camera was installed in a remote place with no Ethernet connection, so it had to be WiFi-connected.
The second camera, however, would replace an existing outdated IP camera, so there was Ethernet connection. Considering this, I decided to power it through Ethernet.
Or does technology licensing work against the company?
In the previous article I mentioned the reasons for licensing the technology. But still one question remains unanswered: if you license technology for financial reasons – to earn money – is it worth it? Or, stated more typically,
Yes, it is good to make extra money, but by licensing our technology, aren’t we just creating or empowering our competitors, who would now directly compete with our own products, and therefore damage our profits?
I’ve been working for the technology licensing units more than ten years, and there seem to be confusion of why companies license technologies to other companies, and from other companies. Isn’t it easier/better/more reliable to develop your own?
And understanding why it happens is very important, because for example when you design the SDK for the licensing, many design decisions would be influenced by this reasoning. Hence this explanation is necessary, so the engineers would understand what is needed.
and how did we end up in this situation?
There is a couple of wires inside your car which control many car components, from lights and signal to trunk, ABS and even brakes. This couple of wires is called “CAN bus”, CAN meaning Controller Area Network. Access to this bus by hackers gives them significant control of the car, and as has been shown in recently published car hacks, this is possible, and has been done.
At the source of the hack is the fact that CAN bus has no security, and anyone with the ability to intercept and inject messages can take over the car. Therefore right after reading about those hacks, many people who are familiar with security but not with car manufacturing process, often ask this question: why does the CAN bus is so insecure?
In this article I will try to explain, why CAN bus evolved this way, and what are security challenges to secure it.
I have developed several multimedia applications using Qt4 and Qt5. In past, when creating Karaoke Lyrics Editor with Qt4, I initially used Phonon, which was offered by Qt4 multimedia framework. Unfortunately I quickly found the issues with this framework, making it less useful for my purpose:
This article explains how to reverse-engineer file formats by using what is called a known plaintext attack. This is a kind of attack when an attacker has an ability to pass the plaintext to the oracle (in our case the enryption algorithm) and receive back the encrypted text, and do it as many times as needed.
Yesterday I was working on adding support for reading Encore! Lyric files in the Karaoke player. I do not have this player anymore (I had purchased the lifetime license from Igor Marinin, but its author revoked it after I reached out to him asking whether the music he bundled with the player is properly licensed, as it appeared to be pirated – do not deal with this guy). However my friend sent me a few files to look at, which appear encrypted. So I asked him to create a file with a single lyric line of 96 ‘@’ characters.
The ‘@’ was chosen because its binary representation of 01000000 makes it the easiest to detect the XOR-based encryption patterns, while it is a printable ASCII character which is easy to type and has a known encoding. Also the string contains the same characters so if it is XORed agains a fixed size key, we would see the repeated pattern. I have asked him also to create another lyric with multiple lines of ‘A’ characters, to test my theories.
Worked on adding support for the EMZ karaoke format to the Karaoke Player application, and would like to share another good reverse-engineering technique.
EMZ is a Karaoke format similar to the old Karafun, based on a password-protected ZIP archive. Unlike Karafun, the password is not embedded into the archive, but is derived from a some kind of “login”. The editor is able to create the password-protected files, and can open them without Internet connection, so the password derivative algorithm is built into the software, and is not stored on the remote server. This is a classic example of “security through obscurity”, and, as usual it does not work well.
Normally finding out the algorithm would require reverse-engineering the Editor binary. It is written in Deplhi, so this would be less than a pleasant way to spend the weekend. But due to Delphi’s heavy usage of Win32 API, this is not needed at all! Leave your IDA and Ollydbg on a shelf, and see how easy this could be done.
Once in a while during development a software engineer needs to embed the binary object as byte array in C or Java language. While coding a solution is simple, it could be achieved by the following command line on Linux or cygwin:
For unsigned data:
od -v -t u1 <binary file> | cut -c9- | sed 's/\([0-9]\+\)/\1,/g'
For signed data (Java byte arrays):
od -v -t d1 <binary file> | cut -c9- | sed 's/\([0-9]\+\)/\1,/g'