Excuse me, your clouds are leaking
I recently started playing around with Gliffy, a nice online diagramming tool that has become quite popular. Gliffy makes sharing your diagrams with the world easy. Unfortunately, many Gliffy users do not realize that they are sharing their diagrams with the entire world. Some quick Google searches revealed a number of entertaining diagrams.
This data ranges from boring to concerning. I held back a few that I felt were not responsible to disclose. At any rate, this highlights the dangers of using “cloud services” and not educating employees about the inherent risks this involves. Also, some of this is just plain laziness from those who probably know better.
After assuring Google I was indeed a human about a dozen times, here are the highlights:
- A GitHub Migration Map — Author Unknown
- “esecurity” flow chart
- An org chart with salary information
- The “melvyn” flow chart
- A single sign on app flow
- I don’t even know
- qwest.com current architecture solution
- Lubricant Supply Chain
- “Confidential” Application Design Docs
- Another Org Chart
- A Networking Diagram with Passwords
- UI Mockups
- MyBook General Photo Album Confidential API
- A Really Detailed Internal Business Process
- Marketing Plan With $ Figures
- Some Sort of Business Plan
- Music Studio SEO Strategy
- Facebook Ad Campaign Results
- Fax Numbers in a Payroll Process
- Payroll Email Process – Info Disclose
- Another Org Chart
- Another Internal Network Diagram
- ATM Vendor Proprietary Information
- DoD Stuff
- More DoD Stuff
- Even More DoD Stuff (I hope this stuff isn’t classified)
- Another Internal/External Network Diagram
- Hot Sexy Text Chat Mockup
- Zombie Attack Flow Chart
Also, SOPA and PIPA are bad. Please let your representatives know. See: reddit.com for a nice write up.
@bitexploder, @sorcerer13 and @rossja
“Voight-Kampff’ing The BlackBerry PlayBook” at INFILTRATE 2012
Last week, we gave a talk at Immunity’s awesome INFILTRATE conference in Miami Beach, FL. Our presentation, “Voight-Kampff’ing The BlackBerry PlayBook”, discussed some of the black-box style, independent research we performed on the BlackBerry PlayBook. Although some content was similar to our PlayBook talk at SecTor 2011, there were some very notable additions. In particular, we discussed reverse engineering of PlayBook firmware images; flaws in authorization of AppWorld downloads; and exposure of an authorization token used for BlackBerry Bridge (the PlayBook’s PIM and email sync component).
The lattermost point has stirred up a bit of press post-INFILTRATE, so we’d like to clarify a few things:
1. The exposure of the authorization token is facilitated by a bug in the Persistent Publish/Subscribe (PPS) facility of the QNX operating system. This bug causes the contents of otherwise-inaccessible files to be readable from a special file in the same directory. RIM was made aware of this PPS bug as a result of our SecTor talk, as well as notification from others, and again by us prior to INFILTRATE (with special emphasis on disclosure of the Bridge token) — they have fixed this PPS bug in Tablet OS 2.0 (beta).
2. This token exposure effectively renders the BlackBerry handset password moot. The exposed authorization token is accessible after the user has “unlocked” BlackBerry Bridge (where “unlocking” would entail entering the paired BlackBerry device’s password if one is set). Unlocking Bridge is an expected behavior/process for Bridge users. After all, if you’re using Bridge on your device, you’re going to do this. In the case where a BB handset password has not been set, a malicious actor could just request this token from the Bridge service directly.
3. This isn’t “sniffing”. Some highly misinformed comments on news articles have suggested things like “a bad guy would have to be within 10 meters to exploit this.” This issue is not, I repeat not related to Bluetooth (which is used by BlackBerry Bridge). As an aside, despite the title of the article, threatpost has one of the best (press) write-ups so far.
4. The pervasiveness of malicious mobile applications exacerbates this flaw. Unless you’ve been living under a rock, you know that even “savvy” users are frequently duped by seemingly legitimate applications which later turn out to be doing Bad Things. The downplaying of this as an attack vector is nonsense, and the “if dumb users install malicious apps, they deserve whatever’s coming to them” argument is silly. Note that client-side browser or document reader vulnerability could even render this vector moot in the end.
In upcoming posts, we’ll dive a bit deeper into the meat of our research, so stay tuned. For those interested, we have posted the slides at SlideShare, and uploaded some initial code to the Intrepidus Group GitHub page.
Android Backdoor Fail – The Kindle Fire Easter Egg
Happy New Year! And for all you Kindle Fire owners, happy early Easter as well. TeamAndIRC released their code and write-up for BurritoRoot which restores root level ADB access on the Kindle Fire. There were other ways to root the Fire before the latest update from Amazon, but this one is attention deserving because of how blatantly the developers left this back door wide open.
You can follow along even without a Fire by grabbing the 6.2.1 software update from Amazon’s site. Download the “bin” file, extract it, then find the “service.jar” framework file. This jar will be in the Android format, so to view this in jd-gui, you’ll want to convert it first (dex2jar works well).
Besides the standard com.android.server package you would expect to see in the service framework file, you’ll also notice there’s a “com.lab126.services” package (Lab126 appears to have done work for a number of Kindle releases). At that point, it’s pretty hard to ignore a class called “EasterEggReceiver”. There’s not much to this class and nothing has been obfuscated to make it hard to follow. Any application which broadcasts an intent message to the “com.amazon.internal.E_COMMAND” service with the correct extra data can enable the ADB daemon to restart as root. No permissions are needed to send that intent and there are no checks in the framework to see who sent the intent message (like maybe try to limit this to only apps with a certain signature) — simply any Android app on the device can call this backdoor feature.
Dex2Jar view of Kindle Fire's Services framework file
The means of data passing and the severity of this “feature” are different from the HTCLoggers.apk issue from October of last year, but I think they are both signs of the same trend. Mobile developers writing any sort of inter-process communication call or service need to ensure they are communicating only with other trusted apps. Android already gives you a way to do this, if your apps are signed with the same certificate. I’m a fan of Easter Eggs, but sometimes you want to make sure to limit who can walk away with your tasty burrito.
Man-in-the-Middle (MiTM) and certificate setup on Android 4.0
The Nexus Galaxy and Android’s Ice Cream Sandwich (ICS) are finally here. If you’ve done Android application testing in the past, you’ve probably have tried to install your own Certificate Authority (CA) cert on to an Android device or emulator. This process was somewhat painful and required root level access on physical devices. We have an old blog post here on that process, but that all changes now with ICS.
Installing a certificate can now be done in the Settings->Security menu of an Android 4.0 device and handled in the “Credential Storage” section. This does not require the device to be rooted (at least on the builds we’ve seen so far). The “Trusted Credentials” setting will list both the system wide installed certificates as well as any user added ones. An additional feature is now with a few simple clicks, the end user can disable any CA certificate on their device. Is your vendor still hanging with DigiNotar? Now you can disable that yourself without having to pull files from the device. Just click on the certificate, scroll down to the bottom of the pop-up message, then click the “Disable” button on the right.
Android 4.0 Credential Storage menu
Installing your own certificate is almost as easy. Here was my process. I needed the CA cert I generated in Mallory loaded onto to my Nexus. Mallory creates a unique CA certificate per-installation and stores it in Mallory’s “ca” directory. To move this onto the phone, I started up Python’s SimpleHTTPServer in that directory.
~/mallory/current/src/ca$ python -m SimpleHTTPServer
Now on the phone, I pointed the browser to that server on port 8000 in order to download the “ca.cer” file (adjust your IP address/port/filename as necessary).
http://192.168.90.1:8000/ca.cer
On my device, this dropped the CA certificate to the SD card. Back in Settings->Security screen, find the “Install from storage” option. Click that and your “ca.cer” file gets loaded into the “Trusted Credentials” store under the “User” tab. No bouncing castles or root needed. This will require you to set a passcode on your device (if there is not one already). Face unlock doesn’t appear to cut it just yet.
Mallory's CA Cert loaded on the device
~benn
EA Origin vulnerabilities, responsible disclosure, and the Force
If you’re a gamer like me, you’ve probably been waiting for the release of Star Wars: The Old Republic, currently being developed by Bioware. I’ve been looking for beta codes, and came across Penny Arcade’s beta code give-away some time ago (bless their souls).
As I was signing up for the beta, I noticed something interesting: the registration page immediately told you if the email you’d typed in matched an EA Origin account. This piqued my interest: was this exploitable, other than testing if email addresses were associated with Origin? I signed up with my Origin account, and strangely, it asked for a new password, without authenticating my current password. Digging further, I realized that you could reset the password to a new one of your choosing, with one caveat: the holder of the email account needs to access the verification link sent to the email address as part of signup. Here’s the email:
NewUser:
Thank you for joining the Star Wars™: The Old Republic™ community! To complete your registration and activate your account, simply verify your email address by clicking here. Remember, we will update or create an EA account using this email address upon your email validation.
Normally, this would be good enough to prevent unauthorized password resets, but I found it strange that nowhere on the registration page or the email did it say that my password would be reset, and no indication after the reset. Conceivably, you could sign up a large number of Origin accounts for the SWTOR beta, and if the target doesn’t log into his Origin account immediately, he’d be unaware his account has been compromised. If you’re a gamer, you’ve probably signed up for a dozen betas, hoping to get lucky now and then – a “confirm you want to join the Star Wars beta” email from EA would raise no suspicions whatsoever.
I decided to report the issue to EA. I couldn’t find a security contact on their website, but a bit of e-stalking later with a colleague, found the email address of the EA CISO, and shot off an email describing what I’d found. To my surprise, instead of being ignored or receiving a letter from their legal department, I got a response within the hour – “Do you mind sharing your details so we can address the issue promptly? We take security very seriously and would like to get on it right away.” I couldn’t have asked for anything better.
Four days and some email exchanges later, I received an email from one of their Online Development Directors: thank you for reporting the issue, a patch has been deployed – oh and we’d like to send you some free SWTOR swag to show our appreciation.
This was a pretty fun experience for me. It wasn’t a critical vulnerability, but had the potential for mass abuse. EA was on the ball in fixing the bug, and kept me in the loop. You don’t get that too often. Now if only I could use this to have EA give me a permanent beta testing status for all games 
USRP for NFC Part 1
The USRP from Ettus Research is an awesome tool for radio analysis. It’s a really complex tool that is capable of doing almost anything involving radio signals (see these two previous Insight posts by Corey and myself, and Raj). That doesn’t even scratch the surface, though. This post will go into the detailed hardware setup for investigating NFC over the air communication using the USRP.
For the RFnoID project, a group of us temporarily turned into nocturnal, lab-dwelling creatures to get this set up. Full credit for this post goes to my group members: Rob Lee-Own, Scott Velivis, and Vincent Lin.
Step 1: Obtain USRP. Ettus Research has several models. For the RFnoID project, we used the plain ol’ black USRP1. At Intrepidus Group, we have the USRP N210. An enormous, frustrating, caveat to the USRP will be mentioned later, but for now, keep this in mind: The USRP1 uses USB, while the N210 uses Gigabit Ethernet to communicate with the computer. Select with care!
Step 2: Select your daughter boards. The USRP requires RFID works in three frequencies: 125 KHz, 13.56 MHz, and 900 MHz. We’re going to be focusing on ISO14443-A, which operates at 13.56 MHz. For the rest of this article, NFC refers to the 13.56 MHz band. We’ll need one daughter board for receiving, and one for transmitting. The low frequency transmit and receive daughterboards (LFTX and LFRX) should fit the bill for 13.56 MHz RF communication at DC to 30 MHz.
Step 3: Select your antennae! This part took trial and error, including some home brew (courtesy of Scott and Rob):
We ended up going with two of the DLP-RFID-ANT from Digi-Key at $40.
Here’s the tl;dr so far:
- USRP @ $1700 (USRP N210) or $700 (USRP 1)
- LFTX, LFRX @ $75 each
- 2x DLP-RFID-ANT @ $40 each
At this point, you should be able to hook it all up, set up GNU radio on your computer, plug in the USRP, and capture NFC goodness right out of the air. Wahoo!
In this video, we’re issuing a read command using libnfc in the left terminal, and detecting NFC energy using the USRP in the right terminal.
Still with me? Good. Here’s where we started spending long nights in the lab banging our heads against the desk. First, a little background on the software/protocol: NFC at its most basic level follows the ISO 14443-4 “Transmission protocol” specification. You can purchase that from ISO for 136 CHF. Google tells me that’s about $150 in real money. The real gem to pull out of those endless pages is that 0×52 is the WUP (wakeup) command, and it will wake up all tags in the area. 0×26 does something similar. In short, we used some hack-y Python to convert hex numbers into a wave format the USRP could understand and transmit. Code here. Feel free to use that code, but please credit RFnoID if you do find it useful. The USRP will modulate this wave at the carrier frequency. You do not need to do that part. You can set up the USRP to use that .wav file using:
from gnuradio import gr
gr.wavfile_source(“wave52.wav”, True)
We’ll get more into the software behind this in Part 2. Back to the hardware. Here’s what we were trying to get:
Notice that wave is 5.5V peak-to-peak. The NFC tag gets its energy from the RF signal the reader (or, in this case, the USRP) transmits. That’s the energy required to wake up and power an NFC tag.
When we transmitted, the tag simply wasn’t responding. Looking at our signal using the oscilloscope, we found that our signal was roughly .5V peak-to-peak. We required an amplifier to boost the signal to the 5.5V level and, luckily, found one in the lab. The amp doesn’t have to be this fancy, but needs to be SMA-in, SMA-out. We’re still searching for a cheaper amplifier that meets our criteria. Luckily Scott understands antennas much better than I do and says: “the 13.56mhz band is so narrow that even a very non-linear amp would look linear for a ~200khz bandwidth.” We’ll keep this post updated if we find something cheap that fits our criteria.
The second major issue we encountered came when we tried to do 2 things: first, detect energy in the NFC band; and second, send a blocking signal (0×52 works well for this purpose because it re-starts the tag’s initialization and anti-collision routine). We were using a USRP1. Remember we mentioned before that the USRP1 connects to the computer using USB. We were getting a large delay (~300 microseconds) we believe was coming from the USB stack (in the Linux kernel) buffering before sending a complete frame, causing a delay in detecting the RF energy. In theory, the USRP N210, which connects via Gigabit Ethernet, would not have this issue and could send frames as soon as they were received from the USRP.
More on the software (GNU radio and the scripts we used) in Part 2!
-Max
OWASP ATL: Mobile Application Assessment Presentation
I recently gave a presentation at OWASP ATL on the OWASP Mobile Top 10 and how to assess mobile applications. This was a light weight discussion of the OWASP Mobile Top 10 and some topical and technical concerns related to securing mobile applications.
Download the presentation here: [download id="276"]
These videos show various testing techniques on real applications. The applications targeted didn’t have any serious problems. In the case of the game, “WordFeud”, a Scrabble clone, the game maintained game state on the server and tampering with client side values did not yield any interesting results. The SoundCloud demonstration shows how it uses the iOS data protection API to avoid storing OAuth tokens in the applications file sandbox and instead uses KeyChain.
Video Demo Series Here:
iPad SSL MiTM
- http://www.youtube.com/watch?v=0453HDZYdGU
- http://www.youtube.com/watch?v=kZ1pKShrKyk
- http://www.youtube.com/watch?v=NvyM1wzwT2o
- http://www.youtube.com/watch?v=HRRqL7IAkJw
- http://www.youtube.com/watch?v=24FT-plmjAs
iOS Application MiTM
- http://www.youtube.com/watch?v=Hgk310uUdjI
- http://www.youtube.com/watch?v=x1T6kjtcpLw
- http://www.youtube.com/watch?v=0VwJ1bss5wA
- http://www.youtube.com/watch?v=50NAa324WC0
- http://www.youtube.com/watch?v=btl147-ioKQ
- http://www.youtube.com/watch?v=5YFC2L0vapM
- http://www.youtube.com/watch?v=UL6mjywzBwU
Sound Cloud and Data Protection
Manitree: AndroidManifest.xml Auditor
Part of my presentation at this year’s Rochester Security Summit on Android security, included a reference to a tool that would help automate the process of detecting insecure app’s on Android devices. This was basically my research into how effective analyzing the AndroidManifest.xml file was at detecting insecurities in an app.
AndroidManifest.xml Insecurities:
It turns out that if you think about it, there’s probably a lot of ways you can screw up an app by putting wrong values in the the manifest file. Hopefully you remember that the AndroidManifest.xml is the file included inside of all APK’s that defines what permissions the app requires along with defining some of the operating parameters. For instance, if you wanted to create a content provider, you would make something like this:
<provider android:name=".provider.DropboxProvider"
android:authorities="com.dropbox.android.Dropbox">
<grant-uri-permission android:pathPrefix="/" />
</provider>
But what is that grant-uri-permission gibberish, right? In this case, it means that anything that is located in a path that starts with “/” is able to access the provider. Probably not so good if you’re storing sensitive information in it like DropBox was doing.
That’s just one example but here are some others to consider:
- Leaving debug mode enabled
- Granting incorrect read or write permissions to a service, receiver, or provider
- Setting a high intent priority (read also malware)
- Setting a hidden dialer using the “android_secret_code” feature
How effective is this:
This isn’t a complete way of analyzing an Android device by any means, but here’s a few examples where it could have helped. Do you remember the DropBox post I made a couple months ago? That flaw that was caused by incorrect permissions in the AndroidManifest.xml was a good example that’s very easy to detect.
How about the HTCLogger hub bub. Could we have detected these problems by analyzing the manifest file? No – not really. But it would have picked up the fact that it was registering a hidden dialer code so when you would dial *#*#482564#*#* a hidden menu would appear giving you access to its settings.
In summary, we’ve found that analyzing Android’s manifest file is effective to give you a summary of items that need to be reviewed, and it’s very effective when you need to analyze a large quantity of apps in a short period of time. It isn’t very good at truly performing a vulnerability scan on an app, but it will pull up some items of interest. When you’re testing a device for app’s that are insecure, there may be hundreds installed and this technique is pretty good at flagging ones that you should pay attention to and then allow you to follow up with some of the manual techniques.
Manitree: AndroidManifest.xml Device Auditing Tool
Manitree is a tool that will review an AndroidManifest.xml file, APK package, or an entire device(or devices) for insecure values in the AndroidManifest.xml file.
Usage: manitree.py -f [MANIFESTFILE | APKFILE] | -D
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-f INPUTFILE path to AndroidManifest.xml or APK (e.g.
/home/user/com.something.apk, ./
Device Mode Options:
-D Device Mode: Perform a full test on a device
-d Download from a physical device.(Device mode only)
-e Download from an emulated device.(Device mode only)
--path=TMPPATH Set path of where files are temporarily downloaded.
(Default /tmp/AT)
-u Test only user apps
Output Options:
-T OUTPUTTXT Save results to a text file (defaults to console)
-H OUTPUTHTML Save results to HTML (defaults to console)
Debug Options:
-v Display verbose output
-q Quiet mode
-t Test mode. Check to see that environment has been setupDevice Test Mode:
Look for connected devices and download all of the APK’s for processing:
./manitree.py -D
Test only the emulators:
./manitree.py -D -e
Test only user apps:
./manitree.py -D -u
Test multiple devices:
./manitree.py -D -u
1: HT12345688
2: emulator-5554
3: emulator-5556
4: emulator-5558More than one device found.
Select which device to use or A to test all the devices: A
Individual File Mode:
If you’re already extracted the manifest file, you can review it like so:
./manitree.py -f AndroidManifest.xml
If you haven’t extracted it, you can just give it an APK and it will extract if for you:
./manitree.py -f com.intrepidusgroup.app.apk
Directory Mode:
Same idea as above but if you’ve already downloaded a large pile of APK’s, you can analyze them at once:
./manitree.py -f apks/
Reporting:
run a report on a previous test:
./reporter.py
run a report on a specific device:
./reporter.py -D HTCS000001
run a report on a specific package and filter only high findings:
./reporter.py -P com.intrepidusgroup.app -r high
Requirements:
- Linux (soon MacOSX)
- Python 2.6+
- adb (included)
- AXMLPrinter2.jar (included)
Get It:
The tool is open source and hosted on GitHub: https://github.com/antitree/manitree
You can also just download the latest tar ball from here: [download id="275"]
NFC Intent Filters in Android 4.0 – Don’t forget the AAR
If you were developing a NFC application on Gingerbread for Android and were using intent filters, you had to be concerned about other applications on the device trying to intercept those intent messages. We did a blog post about this in May titled “Hijacking NFC Intents on Android“. Well with Ice Cream Sandwich, you now have a new NDEF record which you can add to specify that your app should handle the NFC intent (and if your app isn’t installed, the user should then get prompted to download it from the market). This new tag is being called an Android Application Record (AAR).
In our past blog example, if you were writing your NDEF message using an application on Android, you would want to include a second NDEF record into your NDEF message. Here’s how that code would look:
NdefMessage msg = new NdefMessage(
new NdefRecord[] { rtdUriRecord, NdefRecord.createApplicationRecord(“com.google.android.apps.maps”) });
Google has a good example of a full “Beam” application which supports AAR in the latest SDK (or you can view it online here). You’ll see the AAR is commented out in the code example, but you get the picture. This ends up being a great compromise for developers creating NFC applications. If you want to leave around generic NFC tags where it doesn’t matter what application handles the data, you don’t need to change a thing. However, if you need to launch a particular app, include one extra record. We’re not sure how well this will carry over to other platforms besides Android, but at least for now, our Blackberry Bold 9930 with NFC just ignores the extra NDEF record and handles the URL in the tag as expected.
Now the rest of this post is just so we can geek out about what an AAR actually is when written to a tag. We used an Ultralight-C and then read the tag data with libnfc. Here’s a screenshot of the values.
We’ve highlighted the AAR information. This appears to be using a Text Record Type Definition which follows the RTD external name format. If I’m reading the specs right, here’s what some of those values mean:
54 – RTD_TEXT
0F – Length of EXT tag (“android.com:pkg”)
1C – Length of Text data (“com.google.android.apps.maps”)
After that is our ASCII values for that record until our end of NDEF message marker “FE” (you can also see the Well Known URI record in the tag before the AAR data).
~benn
The story of how qemu met MIPS and created netcat
Earlier this week I found myself in a predicament when I was reversing a stripped down MIPS embedded device. The device had minimal available memory and the only real executables on it were an even more stripped down busybox executable, tftp, and tcpdump. My goal was to obtain tcpdump logs being captured on device, but due to the lack of NFS support and the minimal available memory, I had very few options.
Initially I attempted to write the tcpdump logs to a file, and tftp them up to my local box. This became an issue when the log file became too large and all of the running processes started crashing. Trying to get my timing correct for the tftp command to execute, before everything went haywire, became a serious frustration. This is when I decided to go down a different route and try using everyone’s friend netcat. Unfortunately, I could not find a working netcat binary for the device, so I had to compile my own…
First, I downloaded every MIPS netcat I could find and tried to run them on the device. None worked – the output when trying to run them looked like:
# ./netcat
./netcat: line 1: syntax error: "(" unexpected
Which is extremely frustrating because that output looks like the shell is trying to run the netcat binary as a shell script. Anyway, after a few hours of failing, this is when I decided that I needed to compile my own netcat. This day long endeavor took much longer than I anticipated. I am writing this up in the hope that I can save someone else this frustration.
I knew I was going to build a Debian based MIPS system using qemu on Ubuntu 11.04. I found this tutorial that helped greatly:
Mistake: I assumed which architecture I needed. Make SURE you know which architecture and endianness you are going to be building against. There is a very easy trick to understand this. Pull a file of of the device, and run the ‘file’ command against it. In my case it looked like this:
$ file some_elf_binary
some_elf_binary: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked (uses shared libs), stripped
The “LSB” in that line stands for Least Significat Bit and means you should be building a MIPSEL virtual machine. If it says “MSB,” or Most Significant Bit you should build a MIPS virtual machine. I did not take the time to understand this, and now have a MIPS and MIPSEL virtual machine.
To reiterate – run ‘file’ on an existing executable
LSB = Create MIPSEL virtual machine
MSB = Create MIPS virtual machine
Creating the virtual machine with qemu is pretty easy, but time consuming.
First you must install the correct packages on Ubuntu (the ‘extra’ package provides the MIPS architecture):
sudo aptitude install qemu qemu-kvm-extras
Now you need to pull the initrd and vmlinux files from Debian for your virtual machine type. The initrd is the initial ramdisk and is used to load a temporary filesystem in memory. The vmlinux is the kernel that will be loaded into memory.
At the time of writing this, these links work for downloading the files for the respective architecture:
http://ftp.de.debian.org/debian/dists/stable/main/installer-mipsel/current/images/malta/netboot/
http://ftp.de.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/
The next step is creating a file that will be your virtual hard disk.
qemu-img create -f raw hda.img 1G
Simple enough. Now to boot the initrd/vmlinux combination which will get you to the Debian installer.
NOTE: The ‘-M malta’ that relates to the ‘malta’ Debian images I downloaded. The tutorial I mentioned above uses ‘-M mips’ – this was a hanging point for me. When booting with ‘-M mips’ it just hung, no output, nothing.
MIPSEL:
qemu-system-mipsel -M malta -kernel vmlinux-2.6.26-2-4kc-malta -initrd initrd.gz -hda hda.img -append "root=/dev/ram console=ttyS0" -nographic
MISP:
qemu-system-mips -M malta -kernel vmlinux-2.6.26-2-4kc-malta -initrd initrd.gz -hda hda.img -append "root=/dev/ram console=ttyS0" -nographic
Follow the instructions in the installer, and at the end it will tell you everything is completed and to remove the CD rom or boot media. At this point I waited for the VM to reboot into the installer again, and then had to kill the host’s ‘qemu-system’ process.
NOTE: There is a dialog that tells you that there is no boot loader, and you will have to append some arguments to the kernel. Make sure you take note what device it tells you (sometimes it will be /dev/hda1, others /dev/sda1)
If all went well, you should now be able to boot into the MIPS or MIPSEL OS. As explained above, my two installations had different root partitions that I needed to boot into. Another hanging point when creating my second MIPSEL VM.
MIPSEL:qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda hda.img -append root=/dev/sda1 -nographic
MIPS:qemu-system-mips -M malta -kernel vmlinux-2.6.32-5-4kc-malta -hda hda.img -append root=/dev/hda1 -nographic
Finally we have a MIPS VM shell. I will use netcat as an example of how I built a binary that worked on the end MIPS embedded system. First step is to obviously download the source.
Using wget to pull it down on the MIPS VM, I realized I had to install a compiler.
apt-get install gcc
worked just fine.
Mistake: I did not think about how I had to compile these applications. The end device is very stripped down, and who knows what libraries it even has on it. So after some trial and error I realized that I had to compile with static library linking. It has been a while since I have compiled something like this, so I found this that explains that all you need to do is add the ‘-static’ flag to the compiler arguments, prior to finding that link I asked in the IG chat room, and got a similar response:
[10/11/11 5:10:46 PM] wuntee: how do you force automake/autoconf/gcc whatever to do static librarys, vs dynamic?
[10/11/11 5:11:38 PM] Jeremy: -static
[10/11/11 5:11:39 PM] Sid: -static
[10/11/11 5:11:46 PM] Sid: ^ that
[10/11/11 5:11:46 PM] Jeremy: Zach, go on… say it
[10/11/11 5:11:49 PM] Zach twitches
[10/11/11 5:11:52 PM] Jeremy: -static
[10/11/11 5:11:57 PM] Jeremy: -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static -static
[10/11/11 5:11:57 PM] Sid: -static
[10/11/11 5:12:36 PM] Zach: “./configure –help”
RTFM… Thanks guys.
Mistake: There are MANY options you can pass to the compiler when compiling something for MIPS:. The output of the ‘file’ command on a working executable can be helpful here. In my case it says “ELF 32-bit LSB executable, MIPS, MIPS-II” which meant I wanted to also pass ‘-mips2′ to the compiler.
Configuring and making netcat was easy enough after figuring out all of the options:
CPPFLAGS="-mips2 -static" CFLAGS="-mips2 -static" ./configure && make
Running file on this looks close enough to the working executable, and it is statically linked like I wanted:
some_elf_binary: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked (uses shared libs), stripped
netcat: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, stripped
You can then put the executable on the device, and it hopefully will run. One last thing you can do to the binary in order to conserve space is strip it. This can be done with the strip command.
After about a day of getting this working, the end netcat file was only 750k, and allowed me to obtain tcpdump output. Hope this helps someone.
