Changing your MAC address on new Android devices

Few months ago I flashed my Android device with Cyanogenmod-based LegacyXperia ROM. Before that I was using anonymization script, I created that was able to change MAC address, block some Play Store’s services sending unknown binary data and masking device hostname (used by DHCP). Obviously after upgrade, the script stopped working, so I tried to make it work again.

Apparently newer Android systems changed its way of turning wifi on and off (before, MAC changing was just invoking ip command), so now wlan0 interface is not present when it is off and after turning it on device will most likely authenticate to any known network, effectively leaking its HW address. Because of that I needed to find another way.

A bit of research and compiling iw tool later, I found out that when wifi is being turned off by GUI, wifi card kernel module is removed from kernel, so card’s interface as well as its physical device disappear from system. So the first step to make it work is to insert module back (wl12xx_sdio in my case, it seems to be very popular card on Android devices so probably you have the same). Inserting the module, however generates another problem: GUI cannot manipulate wifi now, so we have to do everything manually. The next steps are to invoke wpa_supplicant to authenticate to network and starting DHCP client daemon.

Doing this that way allows us to do one additional thing, increasing our privacy. Since we have to start supplicant ourselves, we can provide custom config to it. And if we have to write script anyway, we could have separate scripts for every network we know. Then we will be (almost) sure that we are connecting to the network we want.

The connecting script is available from my new repository with Android scripts for increasing privacy. I hope there will be more of them in future. As I have written in first paragraph, there are few other things to do. Or maybe there is something more I do not know about, yet…

PS: this script was tested only on Cyanogenmod 10.2 (based on Android 4.3) and may not work on new (5.*) systems.

Posted in Uncategorized | Tagged , , , , , , | Leave a comment

Decoding Aztec code from polish vehicle registration certificate

About a year ago I interested in mysterious 2D code placed in my car’s registration certificate. After quick research on Google it turned out to be even more mysterious because nobody knew how to decode it. There was even no official document like act or regulation that describes the code somehow. People knew that the code is Aztec code and that’s it. Some companies shared web and Android apps to decode this. And all of them was sending base64 to some server and receive decoded data.

Of course for me it wasn’t rewarding so I started my research on it. After initially scanning the code I’ve seen long string that I immediately recognized as base64. The real fun started after that, because stream I’ve got after that was so strange that at first I had no idea what to do. Upon closer examination it was clear that this data is not damaged but encoded in somewhat strange way. Few days later I was almost sure that this is not encoding but rather compression, because some unique parts of stream was easily readable by human. About a month of learning about compression, looking for even most exotic decompression tools and I was left with almost nothing. I had only weak guess on how decompression parameters could be encoded. I gave up…

Polish vehicle registration certificate (source: pwpw.pl)

Polish vehicle registration certificate (source: pwpw.pl)

About a year later I tried one more time. This time I was a bit more lucky. I found a program that decodes the code. Again. But this time was different. I shut down my network connection to make sure. And it worked! So now a bit of reverse engineering and it’s done. I will skip any details because I do not want to piss off the company which created this, even though I was right and I HAD right to do this.

As usual the source code is available on my Github profile. There is also a bit more information about whole scanning/decoding process. If you like to know more technical details about the algorithm or how to decode the data, everything can be found in README file in the repo.

Posted in Uncategorized | Tagged , , | 9 Comments

Kernel module for ST7565 based displays

Today I pushed kernel module driving ST7565 based displays to my github. I wanted to write kernel module some time ago and st7565 was first thing i thought of. Unfortunately I hadn’t enough motivation and when I got some I burnt my display 🙁 so it wasn’t done. This autumn I had other chance to make it real, because I started embedded systems course on university. And there it is: I’ve got working kernel module that can handle graphic LCD.

The module itself is fairly universal. Nevertheless I don’t know any existing gLCD driver that was included to the mainline kernel so have no idea how that thing should look. Because of that I implemented it as char device. It is storing bare pixel data so there aren’t any sophisticated functions to draw rectangle or something. Its advantages are that it isn’t limiting applications the module can be used to and make any userspace handling function very easy to write. It is also worth to note that the module is providing possibility to read data from buffer which is impossible in the module itself.

Beside that basic functionality it allows to switch off backlight and change brightness using sysfs attributes. The module is also portable thanks to possibility to change CS, A0, RST and backlight pin it is using so you are not tied to the ones I used and reconfiguration does not force you to recompile but just reload the module with different parameters. The exact scheme of the connection more or less is the same as on my previous approach to playing with that display.

PS: there is also new revision of my tool for font-making for that display. Now it is able to create any picture as long as its height is divisible by 8 (it is just simplification, made because of method of storing pixels). You can always implement algorithm that is OR-ing the picture with part of data that is already on display (of course using my module 🙂 ). It is still available on Gist.

Posted in Uncategorized | Tagged , , , , , , | Leave a comment

Netstat & Co. for Android and Big Brother Google story

Yesterday I pushed net-tools optimized for Android to my github. Main goal was to provide full-featured netstat for Android devices. By the way I succeeded to compile arp, ifconfig, rarp and route utilities. Feel free to clone.

Additionally while playing with netstat compiled that way I noticed that not all connections are listed. It is interesting because the connection I found out to be hidden is something called C2DM or its successor GCM and that connection is started just after establishing Internet connection (so probably Google knows about every wifi and 3g connection you use) and attempt to find application responsible for this failed because of this strange netstat behavior so all I know now is that it is using some kind of custom protocol to send strange, probably compressed or encrypted data straight way to uncle Google.

Due to the fact that it uses mtalk.google.com domain I suspected Talk app for this but uninstalling it didn’t help. The more successful approach was to add this domain to /etc/hosts and the other option is to add iptables rule to block this traffic. It is fairly easy because it is using non-standard port (5228) so we can just do

iptables -A OUTPUT -p tcp --dport 5228 -j DROP

Disadvantage of the second method is that it has to be done after each system reboot. There will also be few FIXMEs from bionic libc but nevertheless it will work.

BTW: If you are interested in looking at that traffic it can be hijacked using tcpdump on your Android device.

Posted in Uncategorized | Tagged , , , , , | Leave a comment

CP210x (USB to TTL adapter) for Android devices

Few days ago, while searching for something interesting I can do with my Android phone I found out that Sony is publishing kernel source of all their (and old SE ones too) ROMs. Beside hacking the kernel itself I was wondering if it is possible to compile additional kernel modules (stock ROM provides only internal WiFi module’s drivers). Well.. it was. The first one I tried was driver of my cheap, Chinese USB to serial adapter based on CP2102 chip.

Prerequisites

  • kernel source – it is important to be the same kernel as the one working on your device. Otherwise it would probably be necessary to boot your system with kernel compiled with source you have and it will not be described in this tutorial. The reason it is important is that between kernel version compatibility is not guaranteed. Different configuration could mess with functionality too (but not tried myself). I have Sony Ericsson device so I downloaded from its official repository.
  • cross-compiler – while compiling programs for Android you definitely should get special version of a compiler because Android is different than usual Linux box so compiler options are different too. The easiest way is to download official NDK which has built-in compilers and easy-to-use script to make standalone toolchain out of them. Same toolchain should also work as compiler for kernel but I haven’t tested it myself. In case it didn’t there is very powerful tool for making your own toolchain for any platform supported by GCC so in practice any you can imagine called crosstool-ng (on Arch available on AUR).
  • uucp source code

Kernel module

We will start with a kernel module. First of all we will unpack our kernel. In case of SE kernel need to be uncompressed and then unpacked so I did:

bzcat 4_1_B_0_431_tar.bz2 | tar -xv
cd kernel

And changed dir to kernel. Next thing I had to do was patching Makefile, because it complained about unused variables. If you are using Sony or SE kernel you probably need to do it too. If so create file named Makefile.patch with your favorite editor, i.e.

vim Makefile.patch

and paste following content:

--- Makefile	2012-05-25 12:07:05.000000000 +0200
+++ Makefile.new	2014-08-20 21:16:50.642703198 +0200
@@ -342,7 +342,6 @@
 KBUILD_CPPFLAGS := -D__KERNEL__
 
 KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-		   -Werror \
 		   -fno-strict-aliasing -fno-common \
 		   -Werror-implicit-function-declaration \
 		   -Wno-format-security \

Now you can patch it with:

patch Makefile < Makefile.patch

Then we can start the compilation process which should end in a second. I assume you have working toolchain in your $PATH and it is prefixed with arm-unknown-eabi- (arm-unknown-eabi-gcc, etc.). If its name is different change all occurrences of arm-unknown-eabi- below.

make mrproper
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make semc_iyokan_defconfig
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make prepare
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make modules_prepare
ARCH=arm CROSS_COMPILE=arm-unknown-eabi- make modules SUBDIRS=drivers/usb/serial CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_CP210X=m

If everything worked you should have your module compiled in drivers/usb/serial directory. It is worth to note you could compile any other module the same way. It is only important to change SUBDIRS to your module location and ensure it is configured to be built by issuing make menuconfig or setting appropriate CONFIG-* variable to ‘m’.

Now you can copy modules to your devices. With adb it will be:

adb push drivers/usb/serial/usbserial.ko /mnt/sdcard/others
adb push drivers/usb/serial/cp210x.ko /mnt/sdcard/others

We have two modules to copy here since cp210x (and any other serial device driver) depends on usbserial and without it being already in kernel it would be impossible to insert cp210x and furthermore it will give you strange error message (tested :). So now, again with help of ADB, we can insert our modules.

adb shell
su
cd /mnt/sdcard/others
insmod ./usbserial.ko
insmod ./cp210x.ko

After that you can connect your device and device you compiled module for and test if it works. Serial adapters should create new device file in /dev and, at least with CP210x, it uses ttyUSB* name so you can list it with:

ls -l /dev/ttyUSB*

You can also read from your port as simply as by typing

cat /dev/ttyUSB0

Now after you connect some device talking UART you should see its output.

Program to easily control our port – cu and the rest of uucp package

Warning: in the following steps I assume that you have directories like /data/local/bin and /data/local/etc already on your device. As far as I remember there is only /data/local by default.

At first we need to unpack our source and create some useful directories. Then we will configure our script in build-uucp so we won’t get garbage in source directory and could easily clean things when something goes wrong.

tar -zxvf uucp-1.07.tar.gz
mkdir build-uucp
mkdir install-uucp
cd build-uucp/

Then we will patch our program so it will work on Android out of the box. If we omitted following patch it would be necessary to create configuration file, configure program to read it before work and whole bunch of similar fun. So it is easier to let him know where he could store his files now. You can obviously use the one you want to. If you stay with my config you won’t be able to start cu as normal user which is no problem because by default you won’t have permission to use serial terminal.

Now the procedure is the same as with previous patch. I assume you used policy.h.patch name and the content is:

--- policy.h	2003-05-29 08:08:45.000000000 +0200
+++ policy.h.new	2014-08-20 12:03:45.595405893 +0200
@@ -297,7 +297,7 @@
    systems the lock files are placed in /etc/locks.  On some they are
    placed in /usr/spool/locks.  On the NeXT they are placed in
    /usr/spool/uucp/LCK.  */
-/* #define LOCKDIR "/usr/spool/uucp" */
+#define LOCKDIR "/data/local/etc/spool/uucp"
 /* #define LOCKDIR "/etc/locks" */
 /* #define LOCKDIR "/usr/spool/locks" */
 /* #define LOCKDIR "/usr/spool/uucp/LCK" */
@@ -572,7 +572,7 @@
 /* The name of the default spool directory.  If HAVE_TAYLOR_CONFIG is
    set to 1, this may be overridden by the ``spool'' command in the
    configuration file.  */
-#define SPOOLDIR "/usr/spool/uucp"
+#define SPOOLDIR "/data/local/etc/spool/uucp"
 /* #define SPOOLDIR "/var/spool/uucp" */
 
 /* The name of the default public directory.  If HAVE_TAYLOR_CONFIG is
@@ -580,7 +580,7 @@
    configuration file.  Also, a particular system may be given a
    specific public directory by using the ``pubdir'' command in the
    system file.  */
-#define PUBDIR "/usr/spool/uucppublic"
+#define PUBDIR "/data/local/etc/spool/uucppublic"
 /* #define PUBDIR "/var/spool/uucppublic" */
 
 /* The default command path.  This is a space separated list of
@@ -644,21 +644,21 @@
 /* The default log file when using HAVE_TAYLOR_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``logfile''
    command in the configuration file.  */
-#define LOGFILE "/usr/spool/uucp/Log"
+#define LOGFILE "/data/local/etc/spool/uucp/Log"
 /* #define LOGFILE "/var/spool/uucp/Log" */
 /* #define LOGFILE "/var/log/uucp/Log" */
 
 /* The default statistics file when using HAVE_TAYLOR_LOGGING.  When
    using HAVE_TAYLOR_CONFIG, this may be overridden by the
    ``statfile'' command in the configuration file.  */
-#define STATFILE "/usr/spool/uucp/Stats"
+#define STATFILE "/data/local/etc/spool/uucp/Stats"
 /* #define STATFILE "/var/spool/uucp/Stats" */
 /* #define STATFILE "/var/log/uucp/Stats" */
 
 /* The default debugging file when using HAVE_TAYLOR_LOGGING.  When
    using HAVE_TAYLOR_CONFIG, this may be overridden by the
    ``debugfile'' command in the configuration file.  */
-#define DEBUGFILE "/usr/spool/uucp/Debug"
+#define DEBUGFILE "/data/local/etc/spool/uucp/Debug"
 /* #define DEBUGFILE "/var/spool/uucp/Debug" */
 /* #define DEBUGFILE "/var/log/uucp/Debug" */
 
@@ -669,17 +669,17 @@
 /* The default log file when using HAVE_V2_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``logfile''
    command in the configuration file.  */
-#define LOGFILE "/usr/spool/uucp/LOGFILE"
+#define LOGFILE "/data/local/etc/spool/uucp/LOGFILE"
 
 /* The default statistics file when using HAVE_V2_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``statfile''
    command in the configuration file.  */
-#define STATFILE "/usr/spool/uucp/SYSLOG"
+#define STATFILE "/data/local/etc/spool/uucp/SYSLOG"
 
 /* The default debugging file when using HAVE_V2_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``debugfile''
    command in the configuration file.  */
-#define DEBUGFILE "/usr/spool/uucp/DEBUG"
+#define DEBUGFILE "/data/local/etc/spool/uucp/DEBUG"
 
 #endif /* HAVE_V2_LOGGING */
 
@@ -692,16 +692,16 @@
    be replaced by the system name (if there is no appropriate system,
    "ANY" will be used).  No other '%' character may appear in the
    string.  */
-#define LOGFILE "/usr/spool/uucp/.Log/%s/%s"
+#define LOGFILE "/data/local/etc/spool/uucp/.Log/%s/%s"
 
 /* The default statistics file when using HAVE_HDB_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``statfile''
    command in the configuration file.  */
-#define STATFILE "/usr/spool/uucp/.Admin/xferstats"
+#define STATFILE "/data/local/etc/spool/uucp/.Admin/xferstats"
 
 /* The default debugging file when using HAVE_HDB_LOGGING.  When using
    HAVE_TAYLOR_CONFIG, this may be overridden by the ``debugfile''
    command in the configuration file.  */
-#define DEBUGFILE "/usr/spool/uucp/.Admin/audit.local"
+#define DEBUGFILE "/data/local/etc/spool/uucp/.Admin/audit.local"
 
 #endif /* HAVE_HDB_LOGGING */

If you prefer I have it on my gist so you can just issue one command and get it. Then we are patching as usually:

patch ../uucp-1.07/policy.h < policy.h.patch

As mentioned above you can change path of uucp’s files by issuing the following (remember to escape every occurrence of slash with backslash, otherwise it will fail):

sed -i "s/\/data\/local\/etc/[your-path]/" ../uucp-1.07/policy.h

Now you are ready to compile. It can be done with following commands. Your compiler should have same name (at least if you use NDK’s compiler). It is important to note that I had to switch off HAVE_SYSCONF flag since it was causing ugly errors. In my case makescript couldn’t also find a rule to make ftw.o so I had to make it myself. If you have no trouble here, just omit the line after make.

CC=arm-linux-androideabi-gcc AR=arm-linux-androideabi-ar RANLIB=arm-linux-androideabi-ranlib \
../uucp-1.07/configure --prefix=`pwd`/../install-uucp/ --host=arm-linux-androideabi
sed -i "s/#define HAVE_SYSCONF 1/#define HAVE_SYSCONF 0/" config.h
make
cd unix; make ftw.o; cd ..; make
make install
adb push ../install-uucp/bin/cu /mnt/sdcard/others
adb shell
su
cp /mnt/sdcard/others/cu /data/local/bin/

Finally you can test the program with the following and you should be able to talk RS232 with just a phone/tablet!

cu -lttyUSB0 -s115200

where 115200 is the speed the device you connect to transmits.

BTW: uucp have few other tools and by following this tutorial you compiled them all so you can explore them on your own.

Posted in Tutorials | Tagged , , , , | Leave a comment

Historia Pojazdu na Androida

Tym razem wyjątkowo piszę po polsku, bo i sprawa jest typowo polska. Wczoraj na Google Play pojawił się mój program umożliwiający proste sprawdzenie historii pojazdu z poziomu urządzenia w systemem Android. Jak zauważył pewnie każdy czytający polskie serwisy o tematyce IT pod koniec czerwca MSW udostępniło serwis umożliwiający sprawdzenie historii pojazdu przez Internet. Serwis ten stanowi interfejs dostępu do części danych zgromadzonych w bazie CEPiK.

Widok programu pokazującego podstawowe dane pojazdu

Widok programu pokazującego podstawowe dane pojazdu

Tuż po tym jak przetestowałem funkcjonalność tego serwisu, zadałem sobie pytanie: dlaczego by nie zrobić czegoś takiego na telefon. I tak po kilku dniach pisania oddaję do użytku wszystkim program przenoszący ową funkcjonalność na Androida. Program ten rzecz jasna komunikuje się z serwisem ministerialnym. Jako taki wymaga on więc do pobrania danych takich samych danych wejściowych, czyli: aktualnego numeru rejestracyjnego, numeru VIN, daty pierwszej rejestracji oraz, chyba już obowiązkowego we wszystkich formularzach, przepisanego kodu CAPTCHA.

Po wprowadzeniu powyższych danych możliwy jest dostęp do takich informacji jak rok produkcji pojazdu, status jego rejestracji, ważność polisy OC oraz badania technicznego czy też, najbardziej przydatnego chyba (przynajmniej dla potencjalnych kupców danego pojazdu), stanu licznika podczas ostatniego przeglądu. Z tym ostatnim haczyk jest taki, że stan licznika diagności zbierają dopiero od tego roku, jeśli więc auto nie przeszło w tym roku jeszcze przeglądu to musicie obejść się smakiem. Oprócz wymienionych baza udostępnia wiele innych mniej lub bardziej przydatnych danych. Można też pobrać raport w formacie PDF, co również jet funkcją dostępną w oryginalnym serwisie.

W (mam nadzieję niedalekiej) przyszłości mam zamiar dodać kilka funkcji sprawiających, że program ten będzie nieco bardziej atrakcyjny (o ile możliwość użycia smartfona lub tabletu komuś nie wystarcza) niż oryginalny serwis. Kod źródłowy programu jest dostępny (jak zawsze) w serwisie GitHub, dokładniej tu. Udostępniłem go w zasadzie robię z dwóch powodów: po pierwsze zawsze staram się dzielić efektami swojej pracy, po drugie  dane, które powierzą mojej aplikacji użytkownicy są jak by nie patrzeć danymi poufnymi. Dlaczego więc ktoś miałby mi ufać na słowo? Wiem, że takich, niestety, znajdzie się wielu, ale dla tych bardziej uświadomionych technologicznie będzie to dowód, że z ich danymi nie dzieje się nic złego.

Na koniec skoro już jesteśmy przy kwestiach prywatności warto wspomnieć wymagania aplikacji jeżeli chodzi o uprawnienia. Program wymaga dostępu do Internetu (co jest raczej oczywiste) i komunikuje się wyłącznie z serwisem historiapojazdu.gov.pl (niedowiarki niech odpalą sobie emulator i Wiresharka) oraz praw do zapisu na karcie pamięci (wymagane tylko do zapisu PDFa).

BTW: dzisiaj mój GIST powiększył się o prosty programik, napisany w C, jako zadanie z przedmiotu Telekomunikacja, do przesyłania plików przez port szeregowy przy użyciu protokołu XMODEM.

Posted in Uncategorized | Tagged , , , | 2 Comments

SDC file format description and security analysis of SDM

As promised in my previous post I’m publishing description of Microsoft’s SDC file format. At the beginning I’d like to explain what SDC file is. SDC is the abbreviation of Secure Download Cabinet/Secure Digital Container. It is used by Microsoft in its Dreamspark program (formerly MSDNAA). Theoretically it is secure container that can be sent using Internet without additional encryption and it should prevent its content from being read by any third party. But that’s theory, let’s look at how it works in practice.

Overview

Firstly let’s look at the packing process. Let’s say we are in Microsoft and we want to “secure” some data. We got some file (or possibly few files) ie. Windows ISO. Next we generate some random number and write it down somewhere. Now we use least significant byte of that number to do XOR on EVERY single byte of that file. Now it may be considered secure 🙂 But some day Microsoft realized it isn’t enough. So what did they do? They used deflate (it is compression method used ie. in zip, gzip). Actually there are two versions of the deflate: one with all headers necessary to realize method of compression by using a tool like binwalk and the other that haven’t any header. Now it is time to combine all the files we have in one. Of course we still need to know some information about them (ie. their size before/after compression, file name). After concatenation we need to count CRC of all the data we have as of now. And finally we need to build a file header. At first we need to write header size. Then starts actual header. It is important because here starts region that will be encrypted. Here is some info about the header itself and then about each file. It is possibly padded with random data (don’t know for sure). Now we need two random 32-byte keys consisting of printable characters. We use first to encrypt filenames and the second to encrypt whole header (beside its size). Finally we concatenate header with the rest and here we have SDC file.

Header format

Sample header

Sample header

So, we have basic overview on the format, now let’s look at the details. You think it isn’t secure, huh? It would be worse. On the right you can see example header after decryption. First four bytes determine size of the header counting from the next byte. After that we have area encrypted using Blowfish (sometimes referred blowfish-compat) with ECB mode (Electronic CodeBook) using the key stored in edv variable of webpage linked from SDX file. In that area we have 3 dwords describing the header itself. First is header signature. It can be one of the following values: 0xb4, 0xb5, 0xc4, 0xd1. All I know now is that the one with sig = 0xd1 can store files larger than 4 GiB. The next value is interesting one. It looks like it is used to “encrypt” file name in memory so that the static analysis would result in “not found”. As in other cases it is “very advanced encryption”, the same situation as with the whole file: get all the buffer, iterate through it and XOR with the value’s LSB. I have to admit that this one is even does the job. Now we have something called header size. Actually it is probably number of files packed in the container. While reversing I concluded that SDM iterates from 0 to that number, and while this it is reading 0x38 bytes from file. Next it is probably reading fileNameLength and fileName, so whole header must be in format:

<size><description><0x38-bytes-of-file-description><fileNameLength><fileName><0x38...>

and so on until we reach headerSize. Then we have a lot of values not necessary to unpack the file. First of them is offset of file name. While its value is usually 0 (at least in newer headers with blowfish encryption) it is still probably possible to encounter a file with this value greater than zero. If that happened the first thing to do is probably decrypt filename and then move pointer this amount of bytes right. Next value describes file attributes. In fact I didn’t bother about what bit means what attribute, but I suppose it is the same map as in FAT (see my libfatdino library). The next three values are timestamps (creation, access and modification). They all are in Windows 64-bit format called “file time” used for instance by .NET Framework’s DateTime class (DateTime.FromFileTime method; they are number of 100-nanosecond ticks that elapsed since epoch at 1st January 1601 midnight and I suppose that this value is unsigned). That format is very interesting in comparison with another approach of saving date on 64-bit value used on Linux. UNIX timestamp traditionally uses 1st January of 1970 as its epoch and there is usually signed value in use. It isn’t as precise as Windows (counts only seconds) but its end is about 300 billion (10^9) years in future and since it is signed, in past too. Comparing to that Windows’ date will wrap about year 60000 A.C. and cannot store any date before 1601. I know that is still unreachable (like 4 billion computers in 80’s 🙂 but good to know:) After that we have size of the compressed file (be beware of the difference between 64-bit variant and 32-bit one). When we have container with only one file the equation

compressedSize + headerSize + 4 == sdcSize

should always be true. The next one is uncompressed size of the file which can be used to check if the file has been downloaded entirely. After that there is boolean that indicates if file is inflated (compressed), another one-byte value that is probably reserved for future use, one-word padding, which is also interesting because it looks like it contains random numbers (really?). And after that more padding (this time empty) after which we have size of the file name. It may be a bit tricky because the size we have here is the size AFTER decryption and blowfish demands its output to have length divisible by 8. So to decrypt it we need to count next divisor of 8. File name is encrypted using the same method as the header itself and the second key from edv.

Decryption key

Now something more about the keystring (edv). Its format is:

<crc>^^<fileNameKey><headerKey><xorKey>

where:

  • <crc> is a checksum of whole data area of a file (everything beside header size and header)
  • <fileNameKey> is the key used to encrypt file names
  • <headerKey> is the key used to encrypt whole header
  • <xorKey> is the key used to “encrypt” the files

Security of the whole program

People who are familiar with security should already know how insecure is the SDM. For others I have short description.

  1. At first the files itself AREN’T ENCRYPTED in any way. They are only XORed using one byte long key. XOR itself is very weak protection, even with extremely long key. It is due to the fact that many file formats have some of their bytes predictable (this concerns EXEs, ISOs and ZIPs and these are the formats most frequent on Dreamspark). That predictable bytes are usually the beginnings (headers) which usually have so called magic bytes to easily identify file format. So when we know what byte we expect we could try to XOR that byte with actual byte and it is very probable that we get the “encryption” key.
  2. Deflate which is used to hide this patterns from the end user is just compression method. We don’t need anything special to decompress this data.
  3. ECB which is used as blowfish encryption mode is the most insecure mode of block ciphers. It can cause some parts of data to be revealed without actual decryption (see: Wikipedia).
  4. All the data SDM downloads/sends from/to Microsoft’s servers are UNENCRYPTED. Everything: request from the user, SDC itself and decryption keys are all plaintext so with knowledge how SDC looks we can decrypt the file even when it is not intended for us, but we are only in the middle of its road. Furthermore malicious node is able to modify the file on the fly and i.e. put a backdoor into the file, for instance Windows image.

Conclusion

For all the above reasons Secure Download Manager cannot be called a software for securely downloading the files from Microsoft’s servers. All the users using this are the same way INSECURE as users downloading i.e. their copy of Windows from warez sites. Both are susceptible to MITM attacks.

So we still don’t know the answer: why Microsoft is using dedicated software to share their software. The only answer I have is that it is just for making user’s not using Microsoft’s operating system life difficult. In place of decision-making people like the ones in European Commission I would think if this policy is not intended to be only to keep Microsoft’s monopoly for operating system.

Update 20.07.2014

Description updated thanks to GMMan and his great work on reverse engineering the whole program. He also reminded me about older variants of SDC files. I have currently sample(s) of files with 0xb3, 0xb5 and 0xd1 signatures. I know at the moment that there are also signatures 0xa9, 0xb2, 0xb4, 0xc4 and it is possible that they still are reachable through Dreamspark. It is also likely that Microsoft (or Kivuto on Microsoft’s order) will create new format so if you have a sample of file with different header, please let me know in comments!

Posted in Uncategorized | Tagged , , , , , | 2 Comments

How to bypass Secure Download Manager while downloading from Dreamspark

About a month or so ago I had an urgent need to download a copy of Microsoft Windows from Dreamspark. Unfortunately I haven’t Windows installed then so had to do this using Linux. After successful transaction I was given a link to SDX file and program called SDM. It looked that it would be easy. But it wasn’t. Program that I was encouraged to download was archive with .pkg extension. As I discovered few minutes later it was OS X application package. So the next step was to try to download Windows version and try to execute it with help of Wine. It failed. Then I tried to find some tips on the Net. I found a few other people having the same problem. Some of them could download using Wine and some not. For me there was only one solution: do it myself. As you probably guessed that way was a (almost) full success.

Solution

If you already have SDC file please do not skip since you probably still don’t have a key needed to unpack the file. The first step is to open SDX file in your favorite text editor. You will see a link. Open it in a web browser. Now you need to get to page source. The way it can be done depends on your web browser. Now we need to find few strange values in the code. The easiest way to achieve this is to search for keyword ‘edv*’ where * is the number of file you want to download counting from 1 (they are on ‘Items’ list on page you opened). Now you need to copy somewhere values of the following variables: ‘oiopu*’, ‘oiop*’, ‘fileID*’ (*-see above). The last one we need is ‘dlSelect*’ but for that one you need to search cause it is in a different place. Now you can build URL that will let you to file containing two interesting values: file URL and decryption string. This URL’s format is:

http://[SDXdomain]/WebStore/Account/SDMAuthorize.ashx?oiopu=[oiopu]&f=[fileID]&oiop=[oiop]&dl=[dlSelect]

Now you should see XML file that looks similar to this:

1
2
3
4
5
6
7
8
<information>
 <oiopua>01234abcd-0123-4567-890a-0123456789ab</oiopua>
 <edv>0123456789^^0123456789QwErTyUiOpAsDfGhJkLzXc0123456789QwErTyUiOpAsDfGhJkLzXc12345678</edv>
 <linkAvailable>1</linkAvailable>
 <errorTextKey/>
 <invokeExternalDownload>0</invokeExternalDownload>
 <fileUrl><![CDATA[http://software.dreamspark.com/dreamspark/ENGLISH/SDCfileName.sdc]]></fileUrl>
</information>

The last step here will be downloading file from fileUrl and saving edv value in file. The important thing is that the file with a key should be named exactly as SDC file with addition of ‘.key’ suffix.

Update:

I’ve just discovered that things are getting a bit different when the file size exceeds 2.0 GB. In that case Dreamspark is splitting file in two or more files. That situation could be easily recognized, because sdc file name’s suffix is: ‘.01.sdc’. In that case you need to try to download file which URL differs by only that one digit, ie. ‘.01.sdc’, ‘.02.sdc’, ‘.03.sdc’. When you encounter last file it should have smaller size than the rest and incrementing that number by one should give you BlobNotFound error.

After downloading all the files they just need to be joined into one. It can be easily achieved with dd, ie.

dd if=pl_windows_7_professional_with_sp1_x64_dvd_u_676944.02.sdc >> pl_windows_7_professional_with_sp1_x64_dvd_u_676944.01.sdc

and then optionally

dd if=pl_windows_7_professional_with_sp1_x64_dvd_u_676944.03.sdc >> pl_windows_7_professional_with_sp1_x64_dvd_u_676944.01.sdc

After that you will get sdc file prepared to unpack.

Unpacking SDC

Now since you have SDC file you can start unpacking it. The previous part was, at least for me, very easy. The problem started when I tried to discover how the file is stored in that container. But don’t worry, I’ve written simple program to do it for you. As of now (1st June) it is still in really early alpha stage and have lot of constraints. It is able to unpack containers that contains only one file packed, doesn’t create any directories, cannot verify file’s checksum and probably few other problems I don’t remember or don’t know about.

If you were searching a bit in the Internet, you probably found out that someone cracked that container in the past. Unfortunately Microsoft changed format since then. It is also possible that in response to this article it will be changed again. To make it a bit harder for them to block my software I’m publishing source code on github and after the process of reverse engineering is finished will write second article describing how things works under the hood and describe sdc file format.

But let’s get back to unpacking. Now you need to download xSDM from github. The newest version can be downloaded by typing

git clone https://github.com/v3l0c1r4pt0r/xSDM.git

in your terminal (of course you need to have git installed). Nevertheless I advice you to download newest tagged release. You can do this by clicking on releases on project page and then choosing the one on the top (or first beta/stable if any) and clicking on “tar.gz”. tar.gz can be unpacked by typing

tar -zxvf xSDM-[tag-name].tar.gz

into console. Then get into xSDM directory by typing

cd xSDM

(or your release directory) and compile the program by standard

./configure
make
make install

where installation is optional. Now to unpack your file you just need to type

src/xsdm [path-to-your-sdc-file]

And that’s it, you should now be able to open file you downloaded. As mentioned above the program is in very early alpha so I cannot guarantee that it will work in any case. If you will encounter any problems feel free to open issue on project page at github.

Posted in Tutorials | Tagged , , , , , , | 39 Comments

TP-Link TD-W8901G UART pinout

Some people might wonder: what is the pinout of my router’s serial connection. If you’re a happy owner of TP-Link TD-W8901G and asking that yourself, here is the answer:

TP-Link TD-W8901G's pinout

TP-Link TD-W8901G’s pinout

In the link below there is also this router’s pinout and moreover author states that to make that port working there is a need to modify some resistors. I have V3.5 of that router and didn’t notice any mod to be necessary.

It is possible to solder goldpins in here and router so far haven’t fried. Of course you can try communicating without stable connection and it even works but after training your fingers while waiting for the firmware download/upload to complete you’ll change your mind, I guarantee:).

PS: that model is the one that was one of the victims of massive DNS changing some time ago so if this is the one you’re using as your bridge to the Internet you may be also interested in this.

PS2: if you have another router and want to find out what is the serial port pinout I recommend going here.

Posted in Just knowledge | Tagged , , , , , | Leave a comment

Graphic LCD based on ST7565 chip under Raspberry Pi

Hi, today I’d like to show you how to connect and use gLCD module with Raspberry Pi as host. The display I have is only bare display without any board not like the one in Adafruit’s offer. It can be powered by 3V3 Raspberry but the display itself needs a bit more power so we will need a few capacitors to build a circuit for that purpose. It will also make the connection a bit complicated (can be seen in the photo on the right). Nevertheless I think that the process is still rather easy.

Overview

Connected display

Connected display

As far as I know ST7565 based displays can be connected on two ways: parallel and serial. In case of serial connection, which I used to save few GPIO’s, it is possible to program it using SPI or just only GPIO’s. The display that I have is a bit different than most of the others because it has external backlight, which is additionally single LED so it is very power-saving (15mA). The only problem with that backlight was that the vendor didn’t told anything about parameters of that diode so I needed to figure it out myself.. The second problem while connecting the display itself might be amount of cables that need to be connected when using breadboard. Despite these two facts the whole process should be easy.

Physical connections

Connection scheme

Connection scheme

As said before the only step that may be a bit complicated is connecting so called step-up voltage circuit, made of 4 capacitors. The capacitors that we will use are 1uF electrolytic caps. Beside that we need to use another 5 caps (same as before) to connect parallel inputs to ground. So in sum we need 9 of them. Now we only need to connect VDD to 3V3 pin on Raspberry, ground from the schematic on the right with GND pin, SDATA to SMOSI on Pi, SCLK to SCLK and A0, RST and CS to any free GPIO. It is good to remember their numbers cause we will need it in a moment 🙂 It is important to use numbers used by Linux kernel, not wiringPi which has its own names. At last we need to connect the backlight. As said I have ECO backlight so I had to connect mine using 10 Ohm resistor. You can connect it to 3V3 or if you like to have control during runtime use GPIO, just like any other LED.

Configuring the program

Now I have to mention something about a program itself, because depending on how your vendor implemented the things your display will almost surely need a bit different settings. General procedure will look the same on every ST7565-based display. Main differences will be on particular commands during setup procedure.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
uint8_t init()
{
  if (!bcm2835_init()) {
    return 0;
  }
  bcm2835_gpio_fsel(LCD_BACK,BCM2835_GPIO_FSEL_OUTP);		//backlight
  bcm2835_gpio_fsel(LCD_A0,BCM2835_GPIO_FSEL_OUTP);		//A0
  bcm2835_gpio_fsel(LCD_RST,BCM2835_GPIO_FSEL_OUTP);		//RST
  bcm2835_gpio_fsel(LCD_CS,BCM2835_GPIO_FSEL_OUTP);		//CS
  bcm2835_gpio_write(LCD_CS,HIGH);				//set CS to high to indicate the bus as free
  bcm2835_gpio_write(LCD_RST,LOW);
  bcm2835_delayMicroseconds(1);
  bcm2835_gpio_write(LCD_RST,HIGH);				//hardware reset
  //setup SPI
  bcm2835_spi_begin();
  bcm2835_spi_chipSelect(BCM2835_SPI_CS_NONE);			//manual CS control
  bcm2835_spi_setClockDivider(BCM2835_SPI_CLOCK_DIVIDER_4);	//set speed to 62.5MHz (fastest supported)
 
  int i;
  bcm2835_gpio_write(LCD_CS,LOW);
  for(i = 0; i &lt; sizeof(initcmd)/sizeof(uint8_t); i++)
    transfer(initcmd[i],0);
  bcm2835_gpio_write(LCD_CS,HIGH);
  bcm2835_gpio_write(LCD_BACK,HIGH);				//turn backlight on
 
  return 1;
}

I think that the code above should be generally clear. The most important for us is for loop that is executing every byte from initcmd array. Its content will look like that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
const uint8_t initcmd[] = 
{
  0xa1,							//screen orientation
  0x41,							//set starting line
  0xc0,							//page count direction
  0xa3,							//1/7 bias
  0x2c,							//vc
  0x2e,							//vc+vr
  0x2f,							//vc+vr+vf
  0x24,							//voltage regulator (0x20-0x27)
  0xa6,							//do not reverse the display
  0xaf,							//display on
  0xa4,							//display from ram
  0x81,							//turn on brightness regulation
  0x18							//set brightness (0x0-0x40)
};

The most important values here are:

  • voltage regulator – 0x20 means the darkest, as seen above in my case 0x24 worked
  • bias – I saw displays that had 1/9 so you need to make sure how is in yours and set it according to chips documentation linked at the end

You may also want to play with commands like screen orientation, page direction, display reverse or brightness to fit them to your needs. Now you have tell the program which GPIO you used as backlight (if you weren’t using GPIO you will now need to comment out few lines that sets backlight up), CS, RST and A0.

The program itself

To compile the program you will need to use external library named libbcm2835. It can be installed on ArchLinux ARM by issuing pacman -S libbcm2835 as root. If you are ready you can compile the program by typing: gcc -o lcd lcd.c -lbcm2835 assuming you didn’t change the filename. The simple program I’ve written, basing on the one posted on Gist by tmeissner here and ST7565’s documentation supports transferring single byte (commands too), whole framebuffer, or writing 5×8 single ASCII character or character string. Basing on both codes: mine and Meissner’s I think it is possible to do anything you could think about with that display.

Font creation

Standard ASCII table and traditional 'Hello World!':)

Standard ASCII table and traditional ‘Hello World!’:)

Ending slowly it’s time to tell something about fonts. As I said it is possible to simply write characters on the screen. To understand how all that thing works you need to know how the pixels are transfered to the display. The best explanation of the ST7565 display’s work can be in my opinion found here. TL;DR: the whole pixel space is divided into eight, 8-pixel high, horizontal pages divided into 128 columns that are 8 pixels high. If you didn’t understand, try link above. Nevertheless single letter is 8-pixel high and 5-pixel long so we need 5 bytes to store one letter. Its pixel map starts at left, top corner so it’s our (0,0) point and setting LSBof the first byte lights highest pixel. The font that is available in the code is Fixed 5×8 if someone is curious, it’s one of the default fonts in Xorg. To speed up conversion of the font to the display’s format I made simple OpenGL program to do the job for me. The code is of course available to download (check out my github).

DLs

Traditionally, at last some downloads:

Posted in Tutorials | Tagged , , , , , , , | 2 Comments
« Older
Newer »