Somewhat technical musings

Compiling Windows Executables on Linux

2011-03-29T15:53:00.000-07:00

For me Windows is like that girl that you want to forget about but you can't because she seems to be everywhere and too many people like her. As a software engineer you can't just leave windows behind because too many people still rely on it. If only there were a way that I could continue to use Linux but easily provide the same software for Windows.

What I'm talking about is cross compiling. It simply refers to compiling software to run on a target system that is different from the system running the compiler. This has been common in the Linux community and the embedded development communities for years. I'm going to describe the steps to installing cross compilers for Windows 32-bit and 64-bit on Fedora 14. I'm also going to show how to set-up Eclipse projects and create build configurations that will use the cross compilers to generate binary files that will run on Windows.

Thanks to Eric van Pienbroek and some other volunteers, Fedora 15 will be shipped with the MinGW64 (Minimum GNU tools for Windows x64) cross compiling toolchain. Until then you can install the compilers using the repository file from the Cross Compiler Framework wiki page. Alternatively this can be done from the command line with the following:

cd /etc/yum.repos.d

sudo wget http://build1.openftd.org/fedora-cross/fedora-cross.repo

Now that the repository is set-up you can install the toolchain using the following command:

sudo yum install mingw32-gcc mingw32-gcc-c++ mingw64-gcc mingw64-gcc-c++

Congratulations you can now compile Windows executables from your Fedora machine! All of your favorite GCC tools are provided for working with Windows executables such as strip, nm, ar, and even GDB! All tools are prefixed with i686-w64-mingw32- or x86_64-w64-mingw32-. You can even build code using autoconf tools using the mingw32-configure and mingw64-configure tools. Continue reading if you want to learn how to set-up Eclipse projects to cross compile using your newly installed cross toolchain.

Open Eclipse and select new C++ project. For the project type select 'Empty Project' and 'Linux GCC' for the toolchain. While Eclipse does provide options 'Cross-Compile Project' and 'Cross GCC' I have found both lacking full support. For example, if you select a Cross GCC toolchain Eclipse will ask you for the prefix of the tool chain which in our case would be i686-w64-mingw32-. In the project options under 'C/C++ Build'-> 'Tool Chain Editor' you can select the tools you want to use to build the project and there are a few listed such as 'Cross G++ Compiler' and 'Cross GCC Compiler' but there is no cross archiver or cross assembler, even though these tools are supplied by the MinGW toolchain.

For this reason I suggest selecting the 'Linux GCC' toolchain. Then open the project options and under 'C/C++ Build' -> 'Settings' add the prefix i686-w64-mingw32- (or x86_64-w64-mingw32- for 64-bit executables) to each tools command.

Because these binaries are built with the MinGW32/64 they require libgcc_s_sjlj-1.dll to be distributed with the binary. The DLL can be found in the /usr/i686-w64-mingw32/sys-root/mingw/bin (or /usr/x86_64-w64-mingw32/sys-root/mingw/bin) directory. The extra DLL is required to for setjmp/longjmp C exception handling and is approximately 500K in size.

If you're not too worried about the size of your binaries you can have the linker statically link in this code, that way you won't have to distribute the shared DLL with your binary. To do this you need to tell the linker to statically link the binary. Open the project properties in Eclipse and select 'C/C++ Build' -> 'Settings' then select the 'Miscellaneous' option of the linker. Add the -static option to the 'Linker flags' text box.

When building binaries with C++ you will also be required to distribute libstdc++-6.dll with your binary. This is the standard C++ library and is quite large (~6MB). Like libgcc_s_sjlj-1.dll it can be statically compiled into your binary with the -static option to the linker. The resulting size of your binary will depend on how much of the standard library you happen to utilize.

Now that you can build Windows executables and DLL without leaving Linux, get out there and try it out! If you find that this is helpful don't forget to thank Erik van Pienbroek and the rest of the Fedora MinGW64 special interest group for all their hard work that has made this possible. If I have enough time and there is enough interest I will post about how to use GDB to debug the Windows binaries built with the MinGW64 toolchain.

Decompressing Flash Files

2010-06-27T09:10:00.000-07:00

For those of you who know me, you know that I tend to jump from interest to interest. Lately my interest has been reverse engineering, probably since I'm going to the ReCon conference in July. Anyway while surfing my RSS feeds the other day I came across a post that talked about an SWF disassembler plug-in for IDA Pro and yesterday I had some free time to play around with it.

After looking at the sample file provided I decided I wanted to look at a real flash application. Since I had Pandora running in the background I figured that it would be a perfect since I always wondered if I could extend the client or create my own. After a quick look at the page source I found the location of the SWF file.

<EMBED src="https://www.pandora.com:443/radio/tuner_9_1_0_0_pandora.swf"
quality=high
bgcolor=#FFFFFF
allowscriptaccess=always...

Using wget I downloaded the file and opened it up in IDA Pro. Unfortunately the SWF plug-in for IDA won't show any code because the file has been compressed and the plug-in does not know how to decompress the file. You can tell it's been compressed because the signature is CWS instead of FWS.

After a little googleing I found a ton of sites that offered me flash decompilers but I wasn't about to pay $80+ and the free options smelled of adware. After a little more searching I came across a blog post about Improving SWF Compression. In the post he describes how to compress SWF files and even provides an archive with tools and source. Since his intention was to use ZIP utilities to compress the SWF data he dumped the data out into a file, then zipped it and reinserted it into a compressed SWF file. Looking at his source it was easy to tweak it a little to extract the data from a compressed SWF file, decompress it, and recreate an uncompressed file that could be read by IDA's SWF plug-in.

The source code can be found here: SWFDecompress.java

Updated: Added the link to the SWF plug-in.

On a side not I also discovered that you can embed the Pandora player in your own webpages, Click Here to see (click again to hide).

Catalyst 8.6 on Fedora 9 x86_64

2008-06-20T18:10:00.000-07:00

    For those of us with ATI video cards running Linux, ATI is supporting us with a Linux version of their Catalyst drivers.  They can be downloaded by going to the ATI driver download page and selecting Linux x86_64 and the video card make and model.  From there you can download the self-extracting archive which will either install the driver or build a package.
    It is always a good idea to install from a package since they are easier to update and remove than by hand.    Unfortunately there are a few errors in the package and it will not build correctly on Fedora 9.  I was able to fix these errors and get the package to build although, I cannot use the driver since it has not been updated to work with the XOrg server contained in the Fedora 9 distro. But downgrading the XOrg server is another post.
    Once you have downloaded the self-extracting archive we must extract the files so that we can patch them.  To do this we use the --extract option of the archive.

./ati-driver-installer-8-6-x86.x86_64.run --extract ati

Now that the files are extracted we must patch the .spec file that is used to specify the package build instructions. Use ATI-fglrx.spec-tmpl.patch to patch the file fixing errors with files being included in the package but not listed as part of the installed files as well as an invalid changelog entry.

patch ./ati/packages/Fedora/ATI-fglrx.spec-tmpl < ./ATI-fglrx.spec-tmpl.patch

Next we must patch the a script used to create the directory structure for the package. There were some issues with the directories for the x86_64 build. ati-packager.sh.patch will fix these errors allowing the package to build.

patch ./ati/packages/Fedora/ati-packager.sh < ./ati-packager.sh.patch

Now that the files have been patched we can now build the package.

cd ati

./ati-installer.sh 8-6 --buildpkg Fedora/F9

If all works out as planned you should see messages about 5 different packages created. Congratulations you have successfully build the Fedora 9 package! Now you can use yum to install the packages.

yum localinstall --nogpgcheck ATI-fglrx-8.501-1.f9.x86_64.rpm

yum localinstall --nogpgcheck ATI-fglrx-control-center-8.501-1.f9.x86_64.rpm

yum localinstall --nogpgcheck ATI-fglrx-IA32-libs-8.501-1.f9.x86_64.rpm

yum localinstall --nogpgcheck kernel-module-ATI-fglrx-2.6.25.4-30.fc9.x86_64-8.501-1.f9.x86_64.rpm

exit

*Note - The ATI-fglrx-devel-8.501-1.f9.x86_64.rpm file is only required for development.
As I said at the beginning of the post even after successfully building the Fedora 9 package, it will not work on the default Fedora 9 distro. For the driver to work the XOrg server must be downgraded. I have seen a few guides that describe how to downgrade the XOrg server to the version that came with Fedora 8 but I have not yet attempted this myself.

Fixing the MBR

2008-06-08T10:25:00.000-07:00

This weekend I decided that I was going to load Fedora 9 onto my laptop and dual boot with Windows XP. First of all I have a Toshiba Satellite A305-S6843 which is a great laptop and has never given me any problems. I comes with an Intel T8100 (2.1 GHz), 4 GB RAM, 2x200 GB HD and an ATI Mobility Radeon HD 3470. It originally came with Windows Vista but after only a month I was fed up with it and paid the $140 for the OEM Windows XP Pro x64. I installed XP on the first 200GB HD leaving the second hard drive open. So this weekend I decided that I would load Fedora 9 onto the second hard drive.
After much frustration and searching (thats another story) I was able to get the live fedora 9 CD to boot and installed the OS that way. Apparently I wasn't paying attention and told it to install grub on the boot sector for the second drive. So when I restarted it booted directly into windows as if nothing had happened. I was able to press F12 and use the BIOS's built-in boot manager to select the second hard drive and boot into linux that way. For a while that was fine but then I decided that I would load grub into the MBR so that I could easily select which OS to boot. I did it using the grub-install command

grub-install /dev/sda1

Oops! I just overwrote the boot sector of the windows partition. Consequently this also made it impossible to mount the ntfs partition or boot at all. When trying to boot the MBR all that was displayed was 'GRUB'.
At this point I was pretty sure that I had lost everything on the windows drive and would have to re-install Windows. I just happened to stumble across a post by a guy who had a similar problem and he described how he fixed it using the Windows 98 SE boot disk. This gave me the idea to use the Windows install CD and the recovery console.
Solution

Step 1:	Insert the Windows XP install CD and restart the computer. If your computer uses SATA with AHCI you will either need to set it to compatability mode in the BIOS or create a slipstream disk with the SATA drivers
Step 2:	When the setup finishes loading drivers it will ask you if you want install the Windows XP operating system or if you want to use the Recovery console. Press R to enter the recovery console.
Step 3:	Use the fixmbr command to fix the master boot record. fixmbr
Step 4:	Use the fixboot command to fix the boot sector of the drive. fixboot c:
Step 5:	Exit the Recover console to restart the computer. exit If you set the SATA to compatability don't forget to set it back in the BIOS.
Step 6:	Boot into Linux and bring up the terminal. Run the grub console. grub
Step 7:	Set the root linux partition using the root command. The root partition is set using the hard drive number. For my system linux was installed on the second hard drive (hd1) and the first partition on that hard drive (0). root (hd1,0) You'll know you selected the correct partition when the grub console responds telling you it found the filesystem ext2fs.
Step 8:	Tell grub to setup the MBR. setup (hd0)
Step 9:	The /etc/grub/grub.conf file will probably need to be edited to reflect the correct hard drives and paths. I am not going to get into this here because there are plenty of tutorials on the internet about how to do this.

That should allow you to use grub to boot into both Windows XP and Linux.