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 itself, but 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. 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'
Before you proceed: there is NO working solution yet, and I was not able to run unmodified Mac OS X guest on AMD CPU under VirtualBox. It runs fine under KVM however.
Installing it on a machine with Intel CPU is not a problem. While VirtualBox does not officially support OS X guests on non-Mac hardware, it is still trivial to do so, as described in the following post.
However this will not be enough on AMD CPU, where the OS X kernel will halt (Mavericks) or crash (Yosemite) on boot. More changes are needed.
As frequently complained, Dell XPS13 which is otherwise a very nice ultrabook unfortunately offers horrible wireless experience while running Linux. Typical wireless issues include:
- Not connecting to certain access points (some WPA2-PSK) at all, or taking long time to establish the connection;
- Dropping the wireless connection frequently and keeping reconnecting;
- Having bad wireless throughput;
Those issues are traced to the Intel N6230 WiFi card used by XPS13. Intel wireless cards are unfortunately supported rather poorly on Linux. Therefore the best way to address this issue is to replace this card. I had great experience with Atheros cards under Linux – they have a native driver developed in Linux kernel which is the most mature, and feature-rich. Because of this I purchased Atheros AR5B95 AR9285 Half Mini PCI-E card for $7.99. Other cards should work too, just make sure they are Half Mini PCI-E form factor.
Once you receive your card, the replacement is straightforward. See below how to disassemble XPS13 and replace the wireless card.
Following up the second week task for the excellent Cryptography course by Prof. Jonathan Katz at Coursera, and took the second programming assignment. This time it is about breaking the one-time pad encryption when the code was reused, and more than one ciphertext is intercepted. Again, the suggested approach required too much manual work, and I decided to extend the previous solution and see whether it would work here as well.
The analysis of previous solution applies here mostly, but with two major differences:
I have signed up for the excellent Cryptography course by Prof. Jonathan Katz at Coursera, and took the first programming assignment which was about breaking the Vigenere cipher. The instructor explained one of the ways to do it, and recommended to rely on letter distribution in English. But while the suggested approach was interesting, I decided to try something different and see if it is possible to break the cipher without using the statistic distribution.
I’ve seen a number of suggestions of how to implement a splash screen properly. Most typical implementation is through activities. To show it, you need to make it the first activity in your application, which has a few disadvantages:
- It is an activity, so it will use the Android-specific effect (typically sliding) to switch from splash screen to main menu, giving you little to no control over how you want your splash screen to disappear;
- If you have an option to disable splash screen, the first activity would still show (since it is in manifest), and you’d have to close it and switch to main activity, which will have undesirable UI effects.
A much better way is to implement it as a view inside the same main activity. This would avoid both issues above.
OpenSuSE 13.2 comes with BTRFS chosen as your default rootfs, replacing the old trusted ext4. Unfortunately the kernel version it ships with contains a known flaw which breaks some software using preallocated files and mmap() on them. Known issues have been reported for rtorrent (failed synchronization) and KDE (plasma-desktop crashes and could not be restarted even from terminal until reboot). Therefore please use ext4 filesystem for your root fs.
If you already used btrfs, you have two choices:
– Upgrade your kernel to at least 3.17.2 which would allegedly fix this issue. OpenSuSE offers those kernels in this repository. Unfortunately this may break some 3rd party components such as NVidia proprietary drivers.
– Downgrade your filesystem to ext4. The latter could be done as following:
- Boot from the rescue CD (you can use OpenSuSE 13.2 installation CD), mount the root file system and copy (cp -ax) its content to another disk with ext4 or other Linux root-compatible FS (not FAT/NTFS);
- Umount the root file system, and run mkfs.ext4 on it. Then mount it again as newroot, and copy (cp -ax) the files back.
- Run blkid and find out the new UUID for your root partition. Edit newroot/etc/fstab, and replace the UUID in the line mounting rootfs; replace btrfs by ext4 too.
- Chroot into it: mount /proc newroot/proc -o bind; mount /devc newroot/dev -o bind; mount /sys newroot/sys -o bind; chroot newroot
- Edit /etc/sysconfig/storage and set your rootfs as ext4: DEFAULT_FS=”ext4″
- Reinstall grub (if you forgot, you’ll get grub rescue shell at boot) by running grub2-install. Yast-bootloader does not install it properly.
- Reboot and enjoy.
Due to the excellent work of Gabriel L.Somlo it is possible to run the emulated Mac OS X on Linux under Qemu/KVM. The changes seem to be minimal, and the operating system emulation works well – as long as you have the Intel CPU, that’s it.
If you have only the AMD CPU, the emulation only works without the KVM, i.e. when you run qemu without the -enable-kvm option. With this option the emulation hangs on the grey screen with Apple logo. Enabling the verbose boot (-v option to Chameleon) shows an empty black screen instead.
This happens because Continue reading