As I promised , here`s first post on hacking embedded systems.
In a very brief sentence , embedded systems are family of devices , designed for very specific tasks. read Wikipedia article on embedded systems if you`re not familiar with them.
Every single embedded system (or device, if you like this word more) you may find around , have it`s very specific operating system , which is designed based on a core component ,usually a SoC (System On Chip) . I`ll call it 'chip' from now on . Depending on functionality of device , different chips are used , and depending on used chips different operating systems are loaded and executed . In case of embedded systems , operating system is called Firmware .
It may look funny but from your MP3 player or digital camera to your micro-wave oven , all have their specific OS and are considered an embedded system . Basically most of those digital devices around you are some kind of embedded system . You got the point ,right ? ok let`s continue .
Focusing on multimedia players , it`s easier to break them apart and study every single piece of an embedded system. Everybody out there have some story about hacking complex embedded devices such as wireless routers or IP cameras , and everybody try them because it`s actually some kind of linux hacking and programming challenges IMO . There are many creative and cool hacks out there for IP cameras or printers , turning them to your attack platform for further internal compromises. Hacking IP cameras is really fun and I`ll dedicate another post explaining how to convert an AXIS ( or any other brand ) camera to a proxy , for browsing and attacking internal networks.
Back to mp3 players, I consider them very popular devices ,every one carrying one in his pocket or bag . So finding any possibility and vector on them to turn them into evil devices would affect very high number of people. Enough theory , let`s get our hands dirty a bit .
So I decided to know my Creative MuVo-v200 better. Although I learned how to do it the lame way , but I`ll tell you how not to do it , without voiding guarantee of your device. First attempt to hack my MuVo was just to learn internals of an embedded system , but the more I learned about them , better ideas appeared on abuse possibilities .
First step was checking used chips and hardware parts . well , an mp3 player is nothing but a mix of a flash-memory , LCD , and a DSP ( Digital Signal Processor ) . DSP is heart of every mp3 player and can be considered the SoC I`ve mentioned before . DSP is the part boot and use firmware of your device from it`s internal memory . Note that flash-memory used for storing firmware is apart from the flash-memory used for storing songs or files. In case of MuVo-v200 , file storage flash-memory can be unplugged and used as a normal flash disk .
As I didn`t knew I can use Google to find used chip on my device, I opened the cover to take a look :
Heart of device is a SIGMATEL STMP3510 DSP chip .
As usual , checking vendor site returned nothing interesting but few technical marketing papers. There I just learned few tips about internals of STMP 35xx chips. Not bad , but far away from 'enough' . So I googled for more technical details about chip and found interesting notes here . Now I know that my MuVo-v200 is using Motorolla DSP56004-compatible 24-bit signal processor as it`s actual heard of SoC . This also tells me that I should look for technical notes on developing code based on Motorola chips . This piece of information will be used later on studying firmware . Searching for more information about used Motorola chip landed me here . Not every line of this document was interesting for now , but at least gave us the point on what other documents we should look for , for farther technical details. These two data sheets ( 1 , 2 ) also had interesting information inside but second one was really boring and actually had nothing to do with what I was looking for. Finding information about your chip some times may not be this simple, and usually some documents are provided only to resellers or manufactures. Here`s the time to try p2p file-sharing networks . Reading and reviewing these hardware specifications is really boring so that`s enough for now . Now we have enough information about capabilities of the chip and the way it really works. Poor firmware developers, they should study them line by line .... :-/
Time to check firmware ,and software part of the mp3 player. At first glance you may think where the hell from , I can find the firmware of my device ? Well , there are some known ways but we all prefer the most lame tricks :)
The hard way is using some USB device debuggers , which are consisted of a hardware device ,and some software parts using the hardware as their source . We can use them to gain direct access to memory of chip , and dump it . hmm not so interesting for somebody like me know any shit about this topic. so let`s find easier method.
Checking vendor web-site, I noticed that they provide updates for firmwares . cool ! In general you should always go check "support" or "downloads" section of your vendor`s site . If they release anything related to our mission , it`s usually placed there . Files related to my mp3-player are published here .
As you see , among new firmware package there`s another package called "Mass storage Driver" . We get them both . later I`ll tell you more about second package . Now we have a setup package for upgrading firmware . I installed it and instantly checked packages contents . An executable file responsible for handling GUI works, and two other executable files looking like to make the device ready for upgrade process . Other interesting contents of package was two device-driver files , and checking related .ini files beside them told me they are used for loading/unloading device in repair-mode . Before attempting to really upgrade firmware , don`t forget to backup files stored on memory of your devices . Upgrade will usually erase them (although not necessary) . Second , try to find current version of your fimware from vendor site or any other trusted place , and have it for unexpected situations . It`s because some times new firmwares just fuck your device and REMOVE some functionalities you had before , and if you miss old firmware version , you`ll loose them for ever . In case of MuVo , new firmware reduced power of output sound level ! Although they did it to take care of health of my ears but I really missed old loud sound . If you don`t know current version of firmware, firmware upgrade program usually tells you , before upgrading to new firmware .
When you attach USB device to system , OS detect it as a simple storage media , let you upload your files to device . But as you`ve already guessed , this way we can not access memory-chip to upload/download firmware files . Firmware upgrade program actually look for attached device , and try to mount it in a specific way , to be able to access ( read/write) low-level data through USB interface . After successfully mounting device in raw mode , it will attempt to upload new firmware files .
MP3-players firmwares are usually consisted of four binary files. Although files I`ll mention are specific for MuVo players , but usually any device which is build based on same chip (SIGMATEL in our case ) have same or alike names and have exactly the same functionality . The reason is that , although different vendors ship different options and packages , but if they use same chip , they must have follow same specific rules provided by chip manufacture. Let`s review firmware files .
Monitoring firmware upgrade software with simple tools like regmon.exe and procmon.exe (SysInternal tools) you can easily monitor activity of software and upgrade process. Watching upgrade process with these tools , it`s possible to see names and location of files software use as firmware and upload them . Although firmware binary files are really obvious and can be easily differentiate from other files in installer package , but I just mentioned this way in case they are not easily located in your environment or package .
As you see , after some junk events , software finally begin reading small blocks of data from firmware files , and write them to chip memory in raw mode . So now we have name of pieces of firmware files and we can turn back to contents of setup package . There are four files , and I`ll briefly explain their purposes .
Bootmanage.sb is self explaining . This piece of firmware acts like a boot manager in your pc , for mp3 player . When device is powered on , this binary is loaded in memory and try to load the right next-stage of firmware in memory of device. The point is that these devices usually have two working modes . One working mode is when you attach device to your system as a removable media, and the other mode is when you power-on device by battery and listen to music ... . Device have two different firmwares for above modes , so Bootmanager check and see which working mode it`s in , and load appropriate firmware.
usbmsc.sb is the firmware bootmanager load , if it detect device is connected to a USB port . This is actually the firmware introduce your mp3-player as a removable storage media , when you plug it in your pc .
stmpsys.sb is the firmware loaded by bootmanage , when you normally use your player . this is the part we should plan for evil modifications .
resource.bin is a binary file containing resources as it names tell us . When you use your mp3 player you`re working with some menus, you see some images ,texts and etc ... . This is the file holding them all . I`ll explain how to have some fun with this file .
Here you can find more information related to MuVo and other players based on STMP chip.
So far , we learned how to find information about hardware part of our device, check used chip , find it`s capabilities and finally grab firmware files and do a sample upgrade. what next ?
Easy task is to hack visual effects of your mp3-player and customize it to amaze your friends by some odd contents on LCD of your mp3-player. In order to do this , you don`t need to know much details about firmware itself . All you have to do is modifying right contents on resource.bin file , and upload new firmware to your device.
Of course , modifying resource.bin is not as simple as opening it in your favorite editor and change binary data . Firmwares and linked files are usually packed and encoded (some times even worse , encrypted ! ) so modifying raw binary data will corrupt the binary image . In case of SIGMATEL , the hard work of identifying used mechanism to decode firmware and resource files is already done , and to hack your resource.bin file , you simply need to download and use a tiny program . As an example , you can modify and replace resources "0651" and "0652" to replace Creative logo , with your own image . So when you power-on your player you`ll see modified image .
There`s only one note to remember before attempting to resource-hack your mp3-player :
If upgrade process terminated before successful finish by ANY reason (system crash in my case!) be warned that your mp3-player will NOT be usable after failed upgrade process . Not as mp3-player nor even simple flash-disk . But don`t panic , it`s easy to recover and clean-up messes . Remember "Mass Storage Driver" I mentioned before ? Here`s where you need it . All standard mp3-players have a recovery mode for such times. By using a special set of instructions ( like pressing and holding a key on player) while plugging it to USB port , you can switch to recovery mode . In case of MuVo , it`s holding and pressing 'play' button while plugging it to usb port , and you should hold the key until system detect device . Now you can run firmware upgrade software again , and upload firmware again . This instruction may be different for other manufactures , so ask google .
Here the easy part finishes .
Hacking MP3-Player firmwares:
Let`s discuss some serious works and review possible real attack vectors . This is where things get really interesting . Abusing portable media/devices as attack vectors for infecting and attacking end-users is not a new idea nor a new unknown techniques. I`ll briefly review finished works on this topic and finally explain my idea .
Portable devices , or to be more specific flash memories , are well-known for being abused to attack users. A simple and easy vector is infecting file contents and using the Autorun , to execute our malware . Since availability of U3 flash memories, things changed a lot , and new vectors discovered and implemented . But they all were using same trick : using Autorun to execute a file , when plugged to system by user . My favorite story about this trick was the way some attackers tried spreading some infected flash disks among corporate users , and almost all of them curiously plugged the infected flash disk ,and game was over .
The other known attack vector based on using removable devices (This time focusing on a more general vector , USB interface ) was hacking the flash chip itself, to cause overflows on guest operating system . This is also discussed publicly and some demos also presented , in BlackHat 2005 . I contacted Barral recently and he was nice enough to provide some detailed information about their previous work and findings . A detailed post is required to cover findings in this field and some more technical details, which are not presented anywhere else yet . As this vector require extensive work on developing code in kernel land , and I`m a lame at that , I`ve almost paused research on this vector , till get another chance to work on this with other researchers like Barrel ( Thanks for your help Darrin , if you read here! ) .
Back to my own idea , I`ve not been looking for yet another way to autorun malwares placed on flash-disk , nor exploit any flaw through USB interface or device-drivers, as Darrin and Dave presented in BlackHat .
Recently I came across an interesting article titled "Attacking consumer embedded devices" in INSECURE MAGAZINE 14 , covering this topic (hacking embedded devices) . I highly recommend you read it , if you`re not familiar with embedded device hacking techniques .
The new idea is hacking (customizing) firmware of mp3 players in some way that they act as our infection engine. Looking at current available SDK packages for developing mp3-player firmwares , confirm this possibility . New mp3-players ( like MuVo-v200 ) are now capable of writing to flash , among various reading capabilities . And implementing _writing_ to files means much ! Current firmwares are capable of doing complex encode/decode of music files , or browse and modify (currently only delete ) files on attached flash memory . So why not add new module to their firmware to do our tasks , say modifying stored files on memory ?
An output of this research will be a customized version of firmware , which is capable of doing following tasks :
In a very brief sentence , embedded systems are family of devices , designed for very specific tasks. read Wikipedia article on embedded systems if you`re not familiar with them.
Every single embedded system (or device, if you like this word more) you may find around , have it`s very specific operating system , which is designed based on a core component ,usually a SoC (System On Chip) . I`ll call it 'chip' from now on . Depending on functionality of device , different chips are used , and depending on used chips different operating systems are loaded and executed . In case of embedded systems , operating system is called Firmware .
It may look funny but from your MP3 player or digital camera to your micro-wave oven , all have their specific OS and are considered an embedded system . Basically most of those digital devices around you are some kind of embedded system . You got the point ,right ? ok let`s continue .
Focusing on multimedia players , it`s easier to break them apart and study every single piece of an embedded system. Everybody out there have some story about hacking complex embedded devices such as wireless routers or IP cameras , and everybody try them because it`s actually some kind of linux hacking and programming challenges IMO . There are many creative and cool hacks out there for IP cameras or printers , turning them to your attack platform for further internal compromises. Hacking IP cameras is really fun and I`ll dedicate another post explaining how to convert an AXIS ( or any other brand ) camera to a proxy , for browsing and attacking internal networks.
Back to mp3 players, I consider them very popular devices ,every one carrying one in his pocket or bag . So finding any possibility and vector on them to turn them into evil devices would affect very high number of people. Enough theory , let`s get our hands dirty a bit .
So I decided to know my Creative MuVo-v200 better. Although I learned how to do it the lame way , but I`ll tell you how not to do it , without voiding guarantee of your device. First attempt to hack my MuVo was just to learn internals of an embedded system , but the more I learned about them , better ideas appeared on abuse possibilities .
First step was checking used chips and hardware parts . well , an mp3 player is nothing but a mix of a flash-memory , LCD , and a DSP ( Digital Signal Processor ) . DSP is heart of every mp3 player and can be considered the SoC I`ve mentioned before . DSP is the part boot and use firmware of your device from it`s internal memory . Note that flash-memory used for storing firmware is apart from the flash-memory used for storing songs or files. In case of MuVo-v200 , file storage flash-memory can be unplugged and used as a normal flash disk .
As I didn`t knew I can use Google to find used chip on my device, I opened the cover to take a look :
Heart of device is a SIGMATEL STMP3510 DSP chip .
As usual , checking vendor site returned nothing interesting but few technical marketing papers. There I just learned few tips about internals of STMP 35xx chips. Not bad , but far away from 'enough' . So I googled for more technical details about chip and found interesting notes here . Now I know that my MuVo-v200 is using Motorolla DSP56004-compatible 24-bit signal processor as it`s actual heard of SoC . This also tells me that I should look for technical notes on developing code based on Motorola chips . This piece of information will be used later on studying firmware . Searching for more information about used Motorola chip landed me here . Not every line of this document was interesting for now , but at least gave us the point on what other documents we should look for , for farther technical details. These two data sheets ( 1 , 2 ) also had interesting information inside but second one was really boring and actually had nothing to do with what I was looking for. Finding information about your chip some times may not be this simple, and usually some documents are provided only to resellers or manufactures. Here`s the time to try p2p file-sharing networks . Reading and reviewing these hardware specifications is really boring so that`s enough for now . Now we have enough information about capabilities of the chip and the way it really works. Poor firmware developers, they should study them line by line .... :-/
Time to check firmware ,and software part of the mp3 player. At first glance you may think where the hell from , I can find the firmware of my device ? Well , there are some known ways but we all prefer the most lame tricks :)
The hard way is using some USB device debuggers , which are consisted of a hardware device ,and some software parts using the hardware as their source . We can use them to gain direct access to memory of chip , and dump it . hmm not so interesting for somebody like me know any shit about this topic. so let`s find easier method.
Checking vendor web-site, I noticed that they provide updates for firmwares . cool ! In general you should always go check "support" or "downloads" section of your vendor`s site . If they release anything related to our mission , it`s usually placed there . Files related to my mp3-player are published here .
As you see , among new firmware package there`s another package called "Mass storage Driver" . We get them both . later I`ll tell you more about second package . Now we have a setup package for upgrading firmware . I installed it and instantly checked packages contents . An executable file responsible for handling GUI works, and two other executable files looking like to make the device ready for upgrade process . Other interesting contents of package was two device-driver files , and checking related .ini files beside them told me they are used for loading/unloading device in repair-mode . Before attempting to really upgrade firmware , don`t forget to backup files stored on memory of your devices . Upgrade will usually erase them (although not necessary) . Second , try to find current version of your fimware from vendor site or any other trusted place , and have it for unexpected situations . It`s because some times new firmwares just fuck your device and REMOVE some functionalities you had before , and if you miss old firmware version , you`ll loose them for ever . In case of MuVo , new firmware reduced power of output sound level ! Although they did it to take care of health of my ears but I really missed old loud sound . If you don`t know current version of firmware, firmware upgrade program usually tells you , before upgrading to new firmware .
When you attach USB device to system , OS detect it as a simple storage media , let you upload your files to device . But as you`ve already guessed , this way we can not access memory-chip to upload/download firmware files . Firmware upgrade program actually look for attached device , and try to mount it in a specific way , to be able to access ( read/write) low-level data through USB interface . After successfully mounting device in raw mode , it will attempt to upload new firmware files .
MP3-players firmwares are usually consisted of four binary files. Although files I`ll mention are specific for MuVo players , but usually any device which is build based on same chip (SIGMATEL in our case ) have same or alike names and have exactly the same functionality . The reason is that , although different vendors ship different options and packages , but if they use same chip , they must have follow same specific rules provided by chip manufacture. Let`s review firmware files .
Monitoring firmware upgrade software with simple tools like regmon.exe and procmon.exe (SysInternal tools) you can easily monitor activity of software and upgrade process. Watching upgrade process with these tools , it`s possible to see names and location of files software use as firmware and upload them . Although firmware binary files are really obvious and can be easily differentiate from other files in installer package , but I just mentioned this way in case they are not easily located in your environment or package .
As you see , after some junk events , software finally begin reading small blocks of data from firmware files , and write them to chip memory in raw mode . So now we have name of pieces of firmware files and we can turn back to contents of setup package . There are four files , and I`ll briefly explain their purposes .
Bootmanage.sb is self explaining . This piece of firmware acts like a boot manager in your pc , for mp3 player . When device is powered on , this binary is loaded in memory and try to load the right next-stage of firmware in memory of device. The point is that these devices usually have two working modes . One working mode is when you attach device to your system as a removable media, and the other mode is when you power-on device by battery and listen to music ... . Device have two different firmwares for above modes , so Bootmanager check and see which working mode it`s in , and load appropriate firmware.
usbmsc.sb is the firmware bootmanager load , if it detect device is connected to a USB port . This is actually the firmware introduce your mp3-player as a removable storage media , when you plug it in your pc .
stmpsys.sb is the firmware loaded by bootmanage , when you normally use your player . this is the part we should plan for evil modifications .
resource.bin is a binary file containing resources as it names tell us . When you use your mp3 player you`re working with some menus, you see some images ,texts and etc ... . This is the file holding them all . I`ll explain how to have some fun with this file .
Here you can find more information related to MuVo and other players based on STMP chip.
So far , we learned how to find information about hardware part of our device, check used chip , find it`s capabilities and finally grab firmware files and do a sample upgrade. what next ?
Easy task is to hack visual effects of your mp3-player and customize it to amaze your friends by some odd contents on LCD of your mp3-player. In order to do this , you don`t need to know much details about firmware itself . All you have to do is modifying right contents on resource.bin file , and upload new firmware to your device.
Of course , modifying resource.bin is not as simple as opening it in your favorite editor and change binary data . Firmwares and linked files are usually packed and encoded (some times even worse , encrypted ! ) so modifying raw binary data will corrupt the binary image . In case of SIGMATEL , the hard work of identifying used mechanism to decode firmware and resource files is already done , and to hack your resource.bin file , you simply need to download and use a tiny program . As an example , you can modify and replace resources "0651" and "0652" to replace Creative logo , with your own image . So when you power-on your player you`ll see modified image .
There`s only one note to remember before attempting to resource-hack your mp3-player :
If upgrade process terminated before successful finish by ANY reason (system crash in my case!) be warned that your mp3-player will NOT be usable after failed upgrade process . Not as mp3-player nor even simple flash-disk . But don`t panic , it`s easy to recover and clean-up messes . Remember "Mass Storage Driver" I mentioned before ? Here`s where you need it . All standard mp3-players have a recovery mode for such times. By using a special set of instructions ( like pressing and holding a key on player) while plugging it to USB port , you can switch to recovery mode . In case of MuVo , it`s holding and pressing 'play' button while plugging it to usb port , and you should hold the key until system detect device . Now you can run firmware upgrade software again , and upload firmware again . This instruction may be different for other manufactures , so ask google .
Here the easy part finishes .
Hacking MP3-Player firmwares:
Let`s discuss some serious works and review possible real attack vectors . This is where things get really interesting . Abusing portable media/devices as attack vectors for infecting and attacking end-users is not a new idea nor a new unknown techniques. I`ll briefly review finished works on this topic and finally explain my idea .
Portable devices , or to be more specific flash memories , are well-known for being abused to attack users. A simple and easy vector is infecting file contents and using the Autorun , to execute our malware . Since availability of U3 flash memories, things changed a lot , and new vectors discovered and implemented . But they all were using same trick : using Autorun to execute a file , when plugged to system by user . My favorite story about this trick was the way some attackers tried spreading some infected flash disks among corporate users , and almost all of them curiously plugged the infected flash disk ,and game was over .
The other known attack vector based on using removable devices (This time focusing on a more general vector , USB interface ) was hacking the flash chip itself, to cause overflows on guest operating system . This is also discussed publicly and some demos also presented , in BlackHat 2005 . I contacted Barral recently and he was nice enough to provide some detailed information about their previous work and findings . A detailed post is required to cover findings in this field and some more technical details, which are not presented anywhere else yet . As this vector require extensive work on developing code in kernel land , and I`m a lame at that , I`ve almost paused research on this vector , till get another chance to work on this with other researchers like Barrel ( Thanks for your help Darrin , if you read here! ) .
Back to my own idea , I`ve not been looking for yet another way to autorun malwares placed on flash-disk , nor exploit any flaw through USB interface or device-drivers, as Darrin and Dave presented in BlackHat .
Recently I came across an interesting article titled "Attacking consumer embedded devices" in INSECURE MAGAZINE 14 , covering this topic (hacking embedded devices) . I highly recommend you read it , if you`re not familiar with embedded device hacking techniques .
The new idea is hacking (customizing) firmware of mp3 players in some way that they act as our infection engine. Looking at current available SDK packages for developing mp3-player firmwares , confirm this possibility . New mp3-players ( like MuVo-v200 ) are now capable of writing to flash , among various reading capabilities . And implementing _writing_ to files means much ! Current firmwares are capable of doing complex encode/decode of music files , or browse and modify (currently only delete ) files on attached flash memory . So why not add new module to their firmware to do our tasks , say modifying stored files on memory ?
An output of this research will be a customized version of firmware , which is capable of doing following tasks :
- Scan contents of flash-memory , locating interested file formats
- Based on detected file-format , select a pre-defined payload and inject it into stored files
- Modify flash-memory content and inject (write) new autorun files to it . (Smart implementation of old hack!)
- Load appropriate modified usbmsc.sb , to trigger classic overflow attack vectors
- Some rootkit functionality! , to steal interesting files and hide .
- {Many other interesting options...}
In order to achieve any of above tasks , extensive work is required for two main reasons. First , all works should be done under ASM , and even more painful not normal ASM , but a limited version due to architecture of used processor which is NOT a general purpose processor . Second problem is learning how to implement functionalities which require learning current codes through reading them , a tedious and hard work even for ASM experts !
In order to be able to write assembly code for used chip , developer must first locate a reference . As these chips are designed to be re-packaged , hopefully it`s easy to find such reference manual . I could find assembler reference for used Motorola DSP chips here . Such references can not be used to learn assembly from base , but should be used by an experienced assembly developer , to migrate his knowledge to new platform .
Next step would be finding a SDK , providing a base for developing new firmware . Don`t even think about developing a firmware from scratch , because developing new firmware based on available SDK is complex enough ! SKD packages are usually commercial and are not available to public . Creative for example , in order to develop his custom firmware for branded mp3-players should purchase SDK specifically designed for Sigmatel chips , from Sigmatel . And prices are not usually much end-user friendly ! But p2p file-sharing networks are not died yet ;) I could find and download an old version of Sigmatel player SDK easily . it shouldn't`t be hard to locate and download it for other manufactures.
If you remember first paragraphs of this post , I mentioned that there are some documents related to technical details of DSP chip which are not provided free and are classified in some way . Hopefully these documents ( like STMP35xx users manual) are provided with SDK . The SDK package I downloaded had these documents among some other useful PDF files .
So far , based on gathered information , we can build our own mp3-player and customize and develop a custom firmware for it .
Next step , would be building new firmware from source code . If we modify provided codes from SDK or simply want to test raw firmware available in SDK , we should first built it . As we`re cross-compiling , we should find and use a custom compiler supporting target platform and architecture . Asking Google again , reveals that an old customized version of GCC compiler ( 1.x version ) is usually used to compile and build the firmwares based on Motorola 56xxx chips. Here is where I got above note from , but it helped me to find many other resources related to compiling firmwares for Motorola 56xxx chips ,and finally here`s the compiler we need for our work , DSP56k-gcc .Turning back to functionalities of customized firmware , I`ll review some of them with more details .
Scanning contents of flash-memory for interesting file formats , let us locate files in root and sub-directories and reserve their path and extension for later tasks. Some interesting file formats to look for are exe, linux PE files , dll , doc , shell scripts (bat,cmd,sh, etc...) and any file that let us inject payload inside them . The list can be longer , covering media files like mp3,mov,... and possibly ANY file-format that there`s a known vulnerability exist for it !
Injecting payloads based on detected file formats is the main goal of whole of these tasks . A quick and easy implementation in customized firmware may try to infect .exe files as they are easy to modify and it`s easy to code it in asm . You may think that who`ll store .exe in his mp3-player ? The truth is that nowadays mp3-players and flash-disks are actually mixed together and most of people use memory of their mp3-player as their portable stirage media . So many popular file formats may be stored there , among music files . Skipping this possibility ,there are still many known vulnerabilities affecting multimedia file formats ! you can find some interesting samples targeting mp3 , mov and other popular formats in gnucitizen.org blog . Skipping the file-format story and focusing more on injected payload , it can be virtually ANYTHING . the only limitation would be storage of multiple payloads in limited space available for storing firmware files . Payload can be a self-spreading trojan , a key-logger , or anything you imagine .
Infecting file formats is really devilish because like other classical methods , attacker will not make any noise on target system . Classic methods can be blocked with simple prevention methods like disabling autorun . Attacking overflow vulnerabilities are also very unstable , and drawback on using this method is that an end-user can not actually be victim of such attack . because a modified flash-disk will no longer be able to serve it`s legitimate usage if it`s designed to attack device-drivers . Finally it`s not easy to build such flash-disk to be able to attack many different targets(and platforms) . In order to target different systems you must re-program your evil flash-disk .
But using discussed technique , end-user will not notice anything wrong , or even suspicions . Do you really check size of mp3 files every time you listen them? I bet you don`t !
Injecting Autorun files can be used if injection is not possible , for example when there`s no file stored in flash-memory . or when there`s no victim file-format available . this functionality can be used to write autorun files , so when flash-disk is attached , defined tasks/commands are executed .
Load appropriate modified usbmsc.sb , will let us use classic overflow attack in more stable and reliable way . First good point about using multiple usbmsc.sb files , is that we don`t have to re-program our flash-disk for every different target . We can implement a module inside firmware to automatically load best second-stage . Even if we can`t implement an auto-detect method for a smart attack , we can still manually select the right stage from mp3-player menu !
Since this technique (customized firmware) is stealth from user point of view , it will last much longer than classic attacks based on flash-disks . Even a sharp expert will have trouble back-tracing infected files back to firmware of an employee`s mp3-player ! Most people will quickly format the flash-disk you may have gifted them anonymously , but how many of them may really upgrade firmware of device ?
I`m still working on this topic very slowly ,and there are some parts that I can not handle alone. So if you`re interested in this topic feel free to contact me . I may present findings and results of research among some demos in an official upcoming con. , of course if I find a way to bypass my soldier-work and get out of country !!!
hmmm this post is a bit longer than usual , isn`t ?
/* I may update contents of this post to keep it updated or fix errors , or add new items */
In order to be able to write assembly code for used chip , developer must first locate a reference . As these chips are designed to be re-packaged , hopefully it`s easy to find such reference manual . I could find assembler reference for used Motorola DSP chips here . Such references can not be used to learn assembly from base , but should be used by an experienced assembly developer , to migrate his knowledge to new platform .
Next step would be finding a SDK , providing a base for developing new firmware . Don`t even think about developing a firmware from scratch , because developing new firmware based on available SDK is complex enough ! SKD packages are usually commercial and are not available to public . Creative for example , in order to develop his custom firmware for branded mp3-players should purchase SDK specifically designed for Sigmatel chips , from Sigmatel . And prices are not usually much end-user friendly ! But p2p file-sharing networks are not died yet ;) I could find and download an old version of Sigmatel player SDK easily . it shouldn't`t be hard to locate and download it for other manufactures.
If you remember first paragraphs of this post , I mentioned that there are some documents related to technical details of DSP chip which are not provided free and are classified in some way . Hopefully these documents ( like STMP35xx users manual) are provided with SDK . The SDK package I downloaded had these documents among some other useful PDF files .
So far , based on gathered information , we can build our own mp3-player and customize and develop a custom firmware for it .
Next step , would be building new firmware from source code . If we modify provided codes from SDK or simply want to test raw firmware available in SDK , we should first built it . As we`re cross-compiling , we should find and use a custom compiler supporting target platform and architecture . Asking Google again , reveals that an old customized version of GCC compiler ( 1.x version ) is usually used to compile and build the firmwares based on Motorola 56xxx chips. Here is where I got above note from , but it helped me to find many other resources related to compiling firmwares for Motorola 56xxx chips ,and finally here`s the compiler we need for our work , DSP56k-gcc .Turning back to functionalities of customized firmware , I`ll review some of them with more details .
Scanning contents of flash-memory for interesting file formats , let us locate files in root and sub-directories and reserve their path and extension for later tasks. Some interesting file formats to look for are exe, linux PE files , dll , doc , shell scripts (bat,cmd,sh, etc...) and any file that let us inject payload inside them . The list can be longer , covering media files like mp3,mov,... and possibly ANY file-format that there`s a known vulnerability exist for it !
Injecting payloads based on detected file formats is the main goal of whole of these tasks . A quick and easy implementation in customized firmware may try to infect .exe files as they are easy to modify and it`s easy to code it in asm . You may think that who`ll store .exe in his mp3-player ? The truth is that nowadays mp3-players and flash-disks are actually mixed together and most of people use memory of their mp3-player as their portable stirage media . So many popular file formats may be stored there , among music files . Skipping this possibility ,there are still many known vulnerabilities affecting multimedia file formats ! you can find some interesting samples targeting mp3 , mov and other popular formats in gnucitizen.org blog . Skipping the file-format story and focusing more on injected payload , it can be virtually ANYTHING . the only limitation would be storage of multiple payloads in limited space available for storing firmware files . Payload can be a self-spreading trojan , a key-logger , or anything you imagine .
Infecting file formats is really devilish because like other classical methods , attacker will not make any noise on target system . Classic methods can be blocked with simple prevention methods like disabling autorun . Attacking overflow vulnerabilities are also very unstable , and drawback on using this method is that an end-user can not actually be victim of such attack . because a modified flash-disk will no longer be able to serve it`s legitimate usage if it`s designed to attack device-drivers . Finally it`s not easy to build such flash-disk to be able to attack many different targets(and platforms) . In order to target different systems you must re-program your evil flash-disk .
But using discussed technique , end-user will not notice anything wrong , or even suspicions . Do you really check size of mp3 files every time you listen them? I bet you don`t !
Injecting Autorun files can be used if injection is not possible , for example when there`s no file stored in flash-memory . or when there`s no victim file-format available . this functionality can be used to write autorun files , so when flash-disk is attached , defined tasks/commands are executed .
Load appropriate modified usbmsc.sb , will let us use classic overflow attack in more stable and reliable way . First good point about using multiple usbmsc.sb files , is that we don`t have to re-program our flash-disk for every different target . We can implement a module inside firmware to automatically load best second-stage . Even if we can`t implement an auto-detect method for a smart attack , we can still manually select the right stage from mp3-player menu !
Since this technique (customized firmware) is stealth from user point of view , it will last much longer than classic attacks based on flash-disks . Even a sharp expert will have trouble back-tracing infected files back to firmware of an employee`s mp3-player ! Most people will quickly format the flash-disk you may have gifted them anonymously , but how many of them may really upgrade firmware of device ?
I`m still working on this topic very slowly ,and there are some parts that I can not handle alone. So if you`re interested in this topic feel free to contact me . I may present findings and results of research among some demos in an official upcoming con. , of course if I find a way to bypass my soldier-work and get out of country !!!
hmmm this post is a bit longer than usual , isn`t ?
/* I may update contents of this post to keep it updated or fix errors , or add new items */
So attractive ! :P
ReplyDeletetomorrow I will be going to hack my MP3 Player and have fun with it ! :D
thanks alot .
[Spynetc (Arash)]
well I read it, while it looks very interesting, it is a "very" time consuming process, I have done some research on the security of embedded devices, in my case I was working with a basic security device which had an AVR chip. normally socs don't provide you any modulation flexibility, they are just an impact few thousand lines of machine code provided to do what it should. nothing more. while you can imagine adding new features to an embedded device it is very time consuming and sometimes very hard or impossible due the lack of enough space in the code flash memory (in our case something which can find some specified file formats, read it, alter it, and then write it back while having a little instruction set) and its a pain in the ass if you don't have a simulator. (SDKs normally provide that, the reliability is something you should see in action!) but if you have the time it can get very exciting, you can do more than mp3 players. one step closer to the movies; you can have a device which unlocks the digitally locked doors. :)
ReplyDeleteKave,
ReplyDeleteYou`re right about amount of work required to implement new functions, as I`ve already warned about them in post . I studied some of codes from SDK ( when I mean study , think about someone who have very limited development experience!)to see how it read/write to files ,or do encode/decode functionality . Checking documentations and user manuals , I can guarantee possibility of topics I`ve mentioned in post , and I guess there would be not much problem about storage space , since there`s already some free space available , and the basic SDK firmware compared to re-branded firmwares have smaller size , meaning room for some fun.
About using other embedded devices , yes it`s possible to use anything . I`ve seen digital cameras booting linux ! but the goal behind chosing mp3-players ,as I mentioned , is extending the well known and very effective attack , targeting untrained end-users . Two main reasons behind using mp3-players are 1.Low price & 2.Popularity .
Hi, Thanks for sharing your experience,I liked the idea of modifying flash-storage contents. It has business value! e.g. creating more smart USB-sticks to keep private keys. patents pending :)
ReplyDeleteThanks a lot! can't wait to get home to open up my mp3 playing alarm clock to modify it's functions!
ReplyDeletei tired mp3 player resource editor (blinde) but when i try to export/import, the program hangs. Intel cpu, 512mb ram, muvo v100 firmware from creative. please help. thanks,
ReplyDeletethe mp3 hacker
i hope i can do that on my hd30ga9...cause ive reformatted it and i cant restore it...i dont have any backups so thats my biggest problems...
ReplyDeleteyou can email me if you want to try on my hd30ga9...echaxxx@gmail.com
How hard is to change menu and buttons' functions. I do not know assembler just a bit of C. Want to use it as music sequencer for live playing. Will check back often,
ReplyDeletethis may save 200 bucks for street musicians
thanks
As the power is supplied from the battery compartment to the main unit via USB port, I wonder if there is any way to use a sigarlighter plug-to-USB to supply unlimited power in the car and connect the jack to the car stereo aux input jack?
ReplyDeleteIf anyone knows, please advise.
Keny
i just want to browse my music by folders and files not by those damn tags in my sansa e130..
ReplyDeleteGood for people to know.
ReplyDeleteThanks! I have ONLY 1 problem; when i choose system start- picture, all other pictures goes s**t. But, once again; very much thanks for you! (Don't say anything of my bad english!!)
ReplyDeleteHey all..PLs help me out.. i have muvo v200 with sigmatel stmp3510.. the problem is that a few months ago ive not been able to use it.
ReplyDeleteit does not switch on when used with a new battery or does not even display anything when connected to the system.
one thing ive noticed is that the IC goes absolutely blinding hot when connected to the usb of my laptop.
A local Cellphone man says he'll charge 300 INR for changing the IC..
Is it worth??
or can i do it my self??
Please help me out.....
Thx for this post ... I am trying to see what is the fastest one of the latest COBY players (MP301-4G) can switch between tracks using a micro-controller to switch tracks to see if one could create almost seamless switch like a DJ may expect to say cut together a new dance track live in real-time, for example.
ReplyDeleteAny advice?
Thanks
Stevet@evdrive.com
? what if you were some one like me who would like to get int the workings of the mp3 player and alter it to be something its not... like a normal usb drive.. get ridd of the mp3 part of it all together.. reprogram it...
ReplyDeletethe company that made mp3 does not give licenses for mp3 away anymore so mp3 players are dead
ReplyDeleteThanks a fuckton for your post. it may sound strange that in 2018 i'm trying to dig up the grave of this thing but i'm in the process of trying to understand how it works and build a updated version for the new age.
ReplyDeleteyour post is the most helpful thing there is since theres bugger all else is left if there even was something to begin with. thanks again man