广岛秋泽个人页面-阿里云开发者社区

Inside a low budget consumer hardware espionage implant

The following analysis was performed on a S8 data line locator which replied to the hidden SMS command for version query (*3646655*) with: Ver=MTK6261M.T16.17.01.10 build=2017/01/10 17:33 Introduction A while back Joe Fitz tweeted about the S8 data line locator1. He referred to it as “Trickle down espionage” due to its reminiscence of NSA spying equipment. The S8 data line locator is a GSM listening and location device hidden inside the plug of a standard USB data/charging cable. It supports the 850, 900, 1800 and 1900 MHz GSM frequencies. Its core idea is very similar to the COTTONMOUTH product line by the NSA/CSS [1] in which an RF device is hidden inside a USB plug. Those hidden devices are referred to as implants. The device itself is marketed as a location tracker usable in cars, where a thief would not be able to identify the USB cable as a location tracking device. Its malicious use-cases can, however, not be denied. Especially since it features no GPS making its location reporting very coarse (1.57 km deviation in my tests). It can, e.g., be called to listen to a live audio feed from a small microphone within the device, as well as programmed to call back if the sound level surpasses a 45 dB threshold. The fact that the device can be repackaged in its sliding case, after configuring it, i.e. inserting a SIM, without any noticeable marks to the packaging suggests its use-case: covert espionage. S8 data line locator capabilities The S8 data line locator has several eavesdropping, espionage and spying capabilities. A SMS message log could look like this: Listen in Calling the S8 data line locator for 10 seconds establishes a call and allows you to listen to the microphone feed from the device. Call back Sending 1111 via SMS to the device enables voice activated call back. It is acknowledged via the following SMS reply: DT: Set voice monitoring, voice callback and sound sensitivity:400 Once the audio level goes above 40 dB the device calls back the number that send the 1111 command. Sending 0000 disables the audio triggered call back. It is replied by: DT: Voice monitoring cancelled successfully. Query location Accoding to the manual sending ‘dw’ via SMS to the device yields a reply SMS with the location. This reply is in the form: Loc:Street, ZIP City, Country http://gpsui.net/u/xxxx Battery: 100% The ‘xxxx’ are replaced with characters ‘0-9,A-Z,a-z’ and the Street, ZIP City, Country line with the appropriate street, ZIP, city and country. The link to http://gpsui.net can be accessed without authorization. It forwards to Google maps. The location was never more accurate than 1.57 km off. During the query the device will use a mobile data connection to an unknown endpoint (presumably gpsui.net). This is confirmed by a “MMS/Internet” charge by my provider. My provider does not discern MMS and Internet, but it is save to assume there is an Internet connection established during location query. This issue was the stepping stone for this analysis. Because the device sends unknown data to an unknown third party it can not - at least with a clear conscious - be used in, e.g., a penetration test. You simply can not use a potentially pre-owned tool. I therefore tried to analyze and eliminate this phone-home “feature”. Hardware To gain access to the devices innards we first tear of the metal shield of the USB connector: S8 data line locator removing USB connector shield. Next, we remove the plastic cover: S8 data line locator removing USB connector shield. Chips After opening the device we can identify the chips: It features: MediaTek MT6261MA: Low budget chip often used in cheap Chinese smartwatches. No official documentation nor information about the chip is available from MediaTek. RDA 6626e: “a high-power, high-efficiency quad-band front-end Module […] designed for GSM850, EGSM900, DCS1800, PCS1900 handheld digital cellular equipment.” Connections So far I could identify 3 different avenues to connect to the device: USB (passthrough) The USB A-connector and the Micro-B cable are not connected to the MT6261MA. They merely pass the signal from one to the other: UART The next connection is a UART: Interfacing with it yields, approximately 3 seconds after booting the device: screen /dev/ttyUSB0 115200 # 8N1 F1: 0000 0000 V0: 0000 0000 [0001] 00: 1029 0001 01: 0000 0000 U0: 0000 0001 [0000] G0: 0002 0000 [0000] T0: 0000 0C73 Jump to BL ~~~ Welcome to MTK Bootloader V005 (since 2005) ~~~ **===================================================** Bye bye bootloader, jump to=0x1000a5b0 However, the output stops there. Input to the device is ignored. It is likely there exist a different firmware version that accepts AT modem commands2. The boot banner of that alternate firmware references “ZhiPu”3 (some file names of the FAT12 in the firmware flash of my device contain this string as well, so the device firmware is likely related to that other firmware). USB (MTK) The DP and DM pads on the USB connector are not connected to the D+ and D- lines of the USB connector. However, the V and GND pads are. The DP and DM pads are instead routed to the MT6261MA processor as illustrated here: Next, a USB cable must be soldered to these connectors as follows: The device will then be recognized as an MediaTek phone USB endpoint with the following data: ID 0e8d:0003 MediaTek Inc. MT6227 phone This is often called the “MTK boot repair”, “MTK DM DP flash”, etc. It will allow us to interface with the device and dump the firmware ROM and flash. Dumping firmware To dump the firmware I use the open source Fernvale research OS [2]. It was initially targeted for the MT6260 processor. It has, however, been ported to the MT6261 and also works on the MT6261MA. Obtaining and building fernly’s MT6261 branch A suitable fork of fernly by Urja “urjaman” Rannikko can be obtained and build as follows: git clone https://github.com/urjaman/fernly git clone https://github.com/robertfoss/setup_codesourcery.git sudo setup_codesourcery/setup.sh /usr/local/bin/codesourcery-arm-2014.05.sh cd fernly git checkout fernly6261 make CROSS_COMPILE=arm-none-eabi- exit cp 95-fernvale-simple.rules /etc/udev/rules.d/. Dumping ROM To dump the flash we run: echo "data = [" > rom.py fernly/build/fernly-usb-loader /dev/fernvale fernly/build/dump-rom-usb.bin >> rom.py echo " ] f = open('rom.bin','wb') for s in data: f.write(chr(int(s,16))) f.close() " >> rom.py python rom.py The file rom.bin will now (at least according to the fernly repository documentation) contain the devices ROM. Dumping flash To dump the flash of the device we need to patch flashrom as follows: git clone https://github.com/flashrom/flashrom cd flashrom/ git checkout c8305e1dee66cd69bd8fca38bff2c8bf32924306 patch -p0 < ../fernly/flashrom-fernvale.patch # manually fix Makefile.rej to complete patching The patch does not cleanly apply so you need to fix the rejected Makefile (Makefile.rej) manually yourself. Once this was done we can first load the fernly firmware into the devices RAM via: fernly/build/fernly-usb-loader -w /dev/fernvale fernly/build/stage1.bin fernly/build/firmware.bin Next, we can use the fernvale_spi programmer we patched into flashrom. We first let it recognize the flash via: flashrom/flashrom --programmer fernvale_spi:dev=/dev/fernvale And then read the flash via: flashrom/flashrom --programmer fernvale_spi:dev=/dev/fernvale -c "MX25L3205(A)" --read flash.dat flash.dat will now contain the devices flash memory. Writing flash attempt Writing the flash can be performed via: flashrom/flashrom --programmer fernvale_spi:dev=/dev/fernvale -c "MX25L3205(A)" --write flash.dat However, the flash seems to be block protected and the block protect bits can not be disabled by flashrom. I have not (yet) found a way to disable the block protect. Analysis Mostly for my personal education I did some more analysis then the obligatory firmware dump. SIM sniffing (via SIMtrace) First, I sniffed the communication between the device and the SIM. Interestingly, it accessed all records of the telephone book and SMS storage. More specifically it accesses the following files, which are not needed to provide the services rendered by the device itself: ADF EF(ECC) EF(EXT2) EF(SMS) DF(TELECOM) DF(PHONEBOOK) EF(ADN) EF(ANRA1) EF(SMS) Other SIM accesses seems to be normal. This is probably not an elaborate scheme to harvest phone numbers and send them to China, but rather the way the default manufactured SIM code was implemented and it was never trimmed down to the needs of this device. Nevertheless, I found it interesting seeing how the device is accessing virtually everything on the SIM. GPRS sniffing attempt (via OpenBTS) Next, I tried to sniff the Internet traffic to figure out what is send to whom via the mobile data connection. To this end, I used a Ettus B100 with OpenBTS. Unfortunately, the S8 data line locator did not connect to the GPRS. This caused the following alternative response to the dw location command: Loc:Please link:http://gpsui.net/smap.php?lac=1000&cellid=10&c=901&n=70&v=7100 Battery:67% Flash contents The most interesting things could be found in the dumped flash. OS Strings in the flash.dat suggest the device is probably running Nucleus RTOS: $ strings -a flash.dat Copyright (c) 1993-2000 ATI - Nucleus PLUS - Version ARM 7/9 1.11.19 Other strings that may help identify the OS are: $ strings -a flash.dat | grep "\.c" psss\components\src\bl_Secure_v5.c psss\components\src\SSS_secure_shared_v5.c hal\system\bootloader\src\bl_Main.c hal\system\bootloader\src\bl_Main.c hal\system\bootloader\src\bl_FTL.c hal\system\bootloader\src\bl_FTL.c hal\system\bootloader\src\bl_FTL.c hal\storage\flash\mtd\src\flash_disk.c hal\system\bootloader\src\bl_Main.c hal\peripheral\src\dcl_pmu6261.c hal\system\cache\src\cache.c hal\peripheral\src\dcl_rtc.c hal\peripheral\src\dcl_pmu6261.c hal\system\bootloader\src\bl_FTL.c hal\system\bootloader\src\bl_FTL.c hal\peripheral\src\rtc.c hal\peripheral\src\rtc.c hal\peripheral\src\rtc.c hal\peripheral\src\rtc.c hal\peripheral\src\rtc.c hal\peripheral\src\rtc.c hal\storage\flash\mtd\src\flash_mtd_sf_dal.c hal\peripheral\src\dcl_pmu_common.c hal\peripheral\src\dcl_f32k_clk.c hal\peripheral\src\dcl_f32k_clk.c hal\peripheral\src\dcl_gpio.c hal\peripheral\src\dcl_pmu_common.c hal\system\cache\src\cache.c hal\peripheral\src\dcl_f32k_clk.c hal\peripheral\src\dcl_gpio.c hal\peripheral\src\gpio.c hal\system\bootloader\src\bl_FTL.c hal\peripheral\src\rtc.c hal\peripheral\src\bmt_hw.c hal\peripheral\src\dcl_pmu6261.c hal\storage\flash\mtd\src\flash_mtd.c hal\peripheral\src\gpio.c custom\common\hal\combo_flash_nor.c hal\peripheral\src\dcl_rtc.c hal\peripheral\src\dcl_rtc.c hal\storage\flash\mtd\src\flash_disk.c custom\common\hal\combo_flash_nor.c hal\storage\flash\mtd\src\flash_mtd_sf_dal.c hal\system\emi\src\emi.c sss\components\src\SSS_secure_shared_common.c alice.c ddload.c plutommi\Framework\GDI\gdisrc\gdi.c C.cKi hal\audio\src\v1\audio_service.c ddload.c ddload.c plutommi\Framework\GDI\gdisrc\gdi_image_hwjpg_v2.c plutommi\Framework\GDI\gdisrc\gdi_image_hwjpg_v2.c plutommi\Framework\GDI\gdisrc\gdi_util.c plutommi\Framework\GDI\gdisrc\gdi_util.c hal\audio\src\v1\audio_service.c ddload.c FAT12 filesystems (?) Searching the flash.dat for the FAT12 file systems that are supposedly present in on MediaTek phones, we get: $ hexdump -C flash.dat 002c1e20 00 00 00 00 00 00 00 00 00 ef cd 4e 4f 20 4e 41 |...........NO NA| 002c1e30 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 00 00 |ME FAT12 ..| 002c1e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 002c1e50 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 4d 4d 4d |..........MMMMMM| 002c1e60 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d |MMMMMMMMMMMMMMMM| * 002c1ff0 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 55 aa |MMMMMMMMMMMMMMU.| [...] 002d8400 eb 58 90 46 69 6c 65 53 79 73 20 00 02 01 01 00 |.X.FileSys .....| 002d8410 01 80 00 9b 01 f8 02 00 01 00 01 00 01 00 00 00 |................| 002d8420 9b 01 00 00 80 00 29 00 00 21 30 4e 4f 20 4e 41 |......)..!0NO NA| 002d8430 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 00 00 |ME FAT12 ..| 002d8440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 002d8450 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 4d 4d 4d |..........MMMMMM| 002d8460 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d |MMMMMMMMMMMMMMMM| * 002d85f0 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 55 aa |MMMMMMMMMMMMMMU.| [...] 002dbc00 ff ff ff ff ff de 9e 68 00 00 00 00 00 50 ba ff |.......h.....P..| 002dbc10 55 93 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |U...............| 002dbc20 00 00 00 00 00 00 00 00 00 ef cd 4e 4f 20 4e 41 |...........NO NA| 002dbc30 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 00 00 |ME FAT12 ..| 002dbc40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 002dbc50 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 4d 4d 4d |..........MMMMMM| 002dbc60 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d |MMMMMMMMMMMMMMMM| * 002dbdf0 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 4d 55 aa |MMMMMMMMMMMMMMU.| However, two of the partitions do not appear to be valid FAT12 file systems: $ fls -o 5646 flash.dat -f fat12 Invalid magic value (Not a FATFS file system (magic)) $ fls -o 5826 flash.dat -f fat12 v/v 6531: $MBR v/v 6532: $FAT1 v/v 6533: $FAT2 d/d 6534: $OrphanFiles $ fls -o 5853 flash.dat -f fat12 Invalid magic value (Not a FATFS file system (magic)) And the middle FAT12 block seems to be corrupted as well, i.e. only orphan files: $ fls -o 5826 flash.dat -rp -f fat12 v/v 6531: $MBR v/v 6532: $FAT1 v/v 6533: $FAT2 d/d 6534: $OrphanFiles -/r * 469: $OrphanFiles/MP0B_001 -/r * 470: $OrphanFiles/ST33A004 -/r * 471: $OrphanFiles/ST33B004 [...] An attempt was made to extract the files: fls -o 5826 flash.dat -Frp -f fat12 | while read line; do path=$(echo "$line" | awk -F':' '{print $2}') mkdir -p $(dirname $path); icat -o 5826 flash.dat $(echo "$line" | grep -oE "[0-9]+" | head -n1) > $path done But most files are empty. The results are also very inconsistent, i.e., when changing SIM cards there are significant changes to the files listed by The Sleuthkit. This indicates that those are either not FAT12 partitions or a modified FAT12 variant. Further analysis was hence done using hexdump. Configuration data The flash also contained some configuration data. First, the IMSI of the inserted SIM and the number that is used to remote control the device could be found in the flash: $ hexdump -C flash.dat 002e2ad0 00 00 00 00 32 xx xx xx xx xx xx xx xx xx xx xx |....2xxxxxxxxxxx| 002e2ae0 xx xx 37 00 00 01 00 01 00 00 00 00 00 00 00 00 |xx7.............| 002e2af0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 002e2b10 00 00 00 00 00 00 00 00 00 00 00 2b 34 39 31 xx |...........+491x| 002e2b20 xx xx xx xx xx xx xx xx 00 00 00 00 00 00 00 00 |xxxxxxxx........| 002e2b30 00 00 00 00 00 00 00 00 00 00 00 00 00 67 70 73 |.............gps| 002e2b40 75 69 2e 6e 65 74 00 00 00 00 00 00 00 00 00 00 |ui.net..........| 002e2b50 00 00 00 00 00 00 00 00 00 00 00 00 00 67 70 73 |.............gps| 002e2b60 75 69 2e 6e 65 74 00 00 00 00 00 00 00 00 00 00 |ui.net..........| 002e2b70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * In the above flash segment you can also see a reference to gpsui.net. This is presumably the remote server which is contacted to turn the MCC, MNC, LAI and CID codes into street, city and country information as well as the link to gpsui.net which forwards to Google maps. However, because writing to the flash could not be achieved this hypothesis could not be confirmed. Hidden commands Eventually, there was a small find potentially making this effort worthwhile. Searching the flash.dat for the dw,1111 and 0000 commands reveals more hidden commands: $ hexdump -C flash.dat 00069530 8c ae 00 00 8d ae 8e ae 72 65 73 74 6f 72 65 00 |........restore.| 00069540 00 00 00 00 00 00 00 00 01 00 00 00 68 68 68 00 |............hhh.| 00069550 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 |................| 00069560 69 6d 73 69 00 00 00 00 00 00 00 00 00 00 00 00 |imsi............| 00069570 03 00 00 00 74 69 6d 65 7a 6f 6e 65 00 00 00 00 |....timezone....| 00069580 00 00 00 00 04 00 00 00 74 69 6d 65 00 00 00 00 |........time....| 00069590 00 00 00 00 00 00 00 00 05 00 00 00 61 71 65 00 |............aqe.| 000695a0 00 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00 |................| 000695b0 61 71 63 00 00 00 00 00 00 00 00 00 00 00 00 00 |aqc.............| 000695c0 07 00 00 00 73 65 72 76 65 72 00 00 00 00 00 00 |....server......| 000695d0 00 00 00 00 08 00 00 00 64 64 64 00 00 00 00 00 |........ddd.....| 000695e0 00 00 00 00 00 00 00 00 09 00 00 00 72 65 67 00 |............reg.| 000695f0 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 |................| 00069600 61 71 62 00 00 00 00 00 00 00 00 00 00 00 00 00 |aqb.............| 00069610 0b 00 00 00 71 71 71 00 00 00 00 00 00 00 00 00 |....qqq.........| 00069620 00 00 00 00 0c 00 00 00 64 77 00 00 00 00 00 00 |........dw......| 00069630 00 00 00 00 00 00 00 00 0d 00 00 00 6c 6f 63 00 |............loc.| 00069640 00 00 00 00 00 00 00 00 00 00 00 00 0e 00 00 00 |................| 00069650 66 61 61 00 00 00 00 00 00 00 00 00 00 00 00 00 |faa.............| 00069660 0f 00 00 00 66 66 66 00 00 00 00 00 00 00 00 00 |....fff.........| 00069670 00 00 00 00 10 00 00 00 31 31 31 31 00 00 00 00 |........1111....| 00069680 00 00 00 00 00 00 00 00 11 00 00 00 30 30 30 30 |............0000| 00069690 00 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 |................| 000696a0 72 70 74 00 00 00 00 00 00 00 00 00 00 00 00 00 |rpt.............| 000696b0 13 00 00 00 67 62 72 70 74 00 00 00 00 00 00 00 |....gbrpt.......| 000696c0 00 00 00 00 14 00 00 00 74 72 61 63 6b 00 00 00 |........track...| 000696d0 00 00 00 00 00 00 00 00 15 00 00 00 6d 6f 6e 69 |............moni| 000696e0 74 6f 72 00 00 00 00 00 00 00 00 00 16 00 00 00 |tor.............| 000696f0 73 6f 73 6f 6e 00 00 00 00 00 00 00 00 00 00 00 |soson...........| 00069700 17 00 00 00 73 6f 73 6f 66 66 00 00 00 00 00 00 |....sosoff......| 00069710 00 00 00 00 18 00 00 00 73 6f 73 00 00 00 00 00 |........sos.....| 00069720 00 00 00 00 00 00 00 00 19 00 00 00 71 63 73 6f |............qcso| 00069730 73 00 00 00 00 00 00 00 00 00 00 00 1a 00 00 00 |s...............| 00069740 6c 65 64 6f 6e 00 00 00 00 00 00 00 00 00 00 00 |ledon...........| 00069750 1b 00 00 00 6c 65 64 6f 66 66 00 00 00 00 00 00 |....ledoff......| 00069760 00 00 00 00 1c 00 00 00 66 6c 69 67 68 74 6f 6e |........flighton| 00069770 00 00 00 00 00 00 00 00 1d 00 00 00 66 6c 69 67 |............flig| 00069780 68 74 6f 66 66 00 00 00 00 00 00 00 1e 00 00 00 |htoff...........| 00069790 65 73 69 6f 6e 6f 77 00 00 00 00 00 00 00 00 00 |esionow.........| 000697a0 1f 00 00 00 65 73 69 6f 61 64 64 72 00 00 00 00 |....esioaddr....| 000697b0 00 00 00 00 20 00 00 00 68 62 74 6f 6e 00 00 00 |.... ...hbton...| 000697c0 00 00 00 00 00 00 00 00 21 00 00 00 68 62 74 6f |........!...hbto| 000697d0 66 66 00 00 00 00 00 00 00 00 00 00 22 00 00 00 |ff.........."...| 000697e0 65 73 69 6f 6c 6f 63 61 74 65 74 79 70 65 00 00 |esiolocatetype..| 000697f0 23 00 00 00 65 65 65 00 00 00 00 00 00 00 00 00 |#...eee.........| 00069800 00 00 00 00 24 00 00 00 73 6e 64 73 74 6f 70 00 |....$...sndstop.| 00069810 00 00 00 00 00 00 00 00 25 00 00 00 64 64 65 00 |........%...dde.| 00069820 00 00 00 00 00 00 00 00 00 00 00 00 26 00 00 00 |............&...| 00069830 66 6f 72 6d 61 74 74 66 00 00 00 00 00 00 00 00 |formattf........| 00069840 27 00 00 00 68 65 6c 70 00 00 00 00 00 00 00 00 |'...help........| 00069850 00 00 00 00 28 00 00 00 2a 65 38 31 2a 00 00 00 |....(...*e81*...| 00069860 00 00 00 00 00 00 00 00 29 00 00 00 2a 65 38 30 |........)...*e80| 00069870 2a 00 00 00 00 00 00 00 00 00 00 00 2a 00 00 00 |*...........*...| 00069880 2a 72 65 62 6f 6f 74 2a 00 00 00 00 00 00 00 00 |*reboot*........| 00069890 2b 00 00 00 2a 33 36 34 36 36 35 35 2a 00 00 00 |+...*3646655*...| 000698a0 00 00 00 00 2c 00 00 00 69 6d 65 69 73 65 74 00 |....,...imeiset.| However, most of those commands do not function correctly. It seems the devices firmware is shared among several such location tracking and listening devices, e.g., there are commands referring to LEDs and a TF card, both of which this device do no feature, however, other devices available online do. An incomplete list of the found commands and there replies is: help: replies with the following commands: dw: Locate qqq: Device binding 1111: Sound Alarm Monitor on 0000: Sound Alarm Monitor off ddd: Reset all tasks aqb: Get Username Password eee: Recording saved dde: Cleanup TF card hhh: Device status loc: same as dw imsi: Query IMEI and IMSI faa: “DTMG: Set voice monitoring, SMS reply and sound sensitivity successfully:40”, “DTMG: Unusual sound detected” fff: “DT: Set voice monitoring, voice callback and sound sensitivity successfully:40” 1111: “DT: Set voice monitoring, voice callback and sound sensitivity successfully:400” 0000: “DT: Voice monitoring cancelled successfully.” gbrpt: “Report:Location the continuous escalation has been closed.” track: “Track:Caller answer mode the device is set to reply location.” hbton: “Hbt:Device is turned on real-time online” hbtoff: “Hbt: Device online has been closed” esionow: “…” ? esioaddr: “Setting esio addr and port fail!” esiolocatetype: “Esio:Reporting location type has been updated to 0.” server: “Setting server addr and port fail!” reg: “…” ? monitor: “Monitor:Caller answer mode the device is set to automatically answer.” eee: “Tf-Card check fails of is insufficient free space!” sndstop: “Cam:No task is running, cancel failed!” *e81*: “…” ? *e80*: “…” ? soson, sosoff, sos, qcsos: ? ledon, ledoff: ? flighton, flightoff: ? aqe: “Setting apn fail!” imeiset: “…” does not seem to set the IMEI restore: “Restore ok!” formattf: ? time: “…” ? timezone: “Setting time zone ok. Current time zone 0” age: “…” ? *3646655*: queries for version information *reboot*: reboots the device Interestingly the reply strings could not be found in the flash in plaintext. This suggests that some of the data is compressed. The message log of me trying some of the found hidden commands to populate the above list is as follows: It seems that we can use esioaddr to change the address used to lock up the location information. However, no connection to a given domain nor IP is actually made. The device will simply report the addr invalid in the location report. The server command sets a different server. Changing it does not result in the addr invalid responses, as can be seen from this second message log: Provider call logs and itemized bill Because the GPRS sniffing failed I resort to the billing of my provider to further analyze the communication habits of the S8 data line locator. Obviously reply SMS are billed. More interesting is the Internet access patterns. dw or loc commands and during idle During location queries the device will use “MMS/Internet” service. The following is a segment in which first repeated location queries were performed, then the devices was left idle: Even during idle the device sometimes uses the “MMS/Internet” service. Even though I deactivated all tracking features that I may have activated during my previous testing, I can not be 100 % sure that this is not something that I activated, maybe while stumbling through the gpsui.net website. However, I regardless of whether I activated this “feature” or not, I do not want it and would like to know what data is actually send and how to deactivate it. gpsui.net Going deeper into the gpsui.net website would probably result in a new writeup in itself. It is a very big surveillance hub, just replace the xxxx in http://gpsui.net/u/xxxx with some letters and numbers and you can see random people’s locations. The website also makes a reference to ZhiPu: It seems this is the company that makes these trackers. You can get your credentials for login by texting aqb to your S8 data line monitor. The username as well as the password are 6 digit numbers. They are also located in the flash right before the IMSI. Detection When sending data the S8 data line locator can be detected with a CC308+ (a cheap Chinese RF detector): The S8 data line locator seems to be badly shielded. A location request via the dw command causes noticeable electronic noise by the device. It seems in general to cause all sorts of RF interference. Future work While I did not (yet) succeed with my original goal to disable the mobile data phone home “feature’, it was nevertheless a fun exercise and hopefully someone finds this useful or at least educational. Future work needs to be done on several things: Issues I was not able yet to write new firmware via flashrom because I was not able to disable block protection on the flash, yet. Maybe a different avenue for flashing new firmware could be the SPFlash tool4 and/or the Flash tool. However, that would not be open source. If know something about the weird FAT12 file system used in the device or are able to flash your S8 data line locator please contact me with details! Further, I tried to capture the GPRS data connection of the device, but was unable to do so. It would not use GPRS when connected to my network. Currently, I do not know how the APN is configured. The SIM trace does not indicate that the EF(ACL) is ever accessed. However, as I found the correct APN configuration stored in the devices flash, this suggests the device acquires this information via a setup SMS by the service provider. Ideas Dremel the board smaller, e.g., you don’t need the USB connector. This way the S8 data line locator could be turned into a “modular” bug that could be placed where ever there is a 5 V 1 A power source. Appendix: Fuck up No writeup would be complete without at least one fuck up. So here it is: While using the S8 data line locator with OpenBTS I provisioned imaginary numbers. When switching SIM cards I forgot to turn of the voice activated callback. So long story short, some guy with the number 3333333 listend in on me for 2 minutes: I did not notice this until I reviewed the logs! So my resume on these little hardware espionage implants: They are stealthy and dangerous as fuck! Bibliography [1] NSA/CSS, “ANT product catalog (USB),” leaked documents (pdf: https://cryptome.org/2013/12/nsa-ant-usb.pdf). [2] A. “bunnie” Huang and S. X. Cross, “Fernvale: An open hardware and software platform, based on the (nominally) closed-source mT6260 soC,” talk at the 31st Chaos Communication Congress (slides: http://www.bunniefoo.com/fernvale/fernvale-31c3.pdf, video: https://www.youtube.com/watch?v=hpEqDPYtf9s). 原文链接：https://ha.cking.ch/s8_data_line_locator/

剖析 GSM 加密机制以及位置更新的过程

你有没有想过打开手机时会发生什么？它是如何以安全的方式与网络进行通信？几乎所有人都知道TCP / IP，并且可能许多人还是专家，但是谈到电信方面，很少有人知道它的内部原理。 gsm中的消息结构是什么？它使用的加密类型是什么？因此，今天我们将详细介绍gsm的加密标准，以及手机如何更新移动网络的位置。当你打开手机发生了什么？当您打开手机时，它首先启动其无线电资源和移动管理程序。手机通过SIM或网络接收附近地区支持的频率列表。它根据功率级别和移动提供商在一个单元上存储。之后，它会对认证发生的网络位置，进行更新过程。位置更新成功后，手机获得TMSI，现在就可以进行其他的操作了。现在，通过查看移动应用程序调试日志来验证上面的结论。下面的屏幕截图是来自模拟在PC上工作的移动电话的一个osmocom移动应用程序。 SIM发送的移动网络信息 camping on a cell 位置更新请求，包括它的LAI、TMSI 允许位置更新并使用可见的加密标准。目标我们将通过osmocom-bb用wirehark捕获gsm数据，并分析整个gsm认证和加密的过程是如何发生的。我们也会看到位置更新过程是如何发生的。我们已经在上一篇博客中详细介绍了osmocom-bb和建立呼叫的过程。这个博客中会跳过那一部分。 GSM加密标准 A5 / 0 - 未使用加密。为了完整性。 A5 / 1-A5 / 1是用于在GSM蜂窝电话标准中提供空中通信隐私的流密码。它是为了使用GSM而指定的七种算法之一。它最初是保密的，但由于泄漏和逆向工程已经为大众熟知。密码中的一些严重弱点已经被发现。 A5 / 2-A5 / 2是用于在GSM蜂窝电话协议中提供语音隐私的流密码。它用于出口，却并非强于（事实上仍然很弱）A5 / 1。它是为使用GSM所定义的七种A5加密算法之一。 A5 / 3（Kasumi） - KASUMI是用于UMTS，GSM和GPRS移动通信系统的块密码。在UMTS中，KASUMI用于名为UEA1和UIA1的机密性和完整性算法。在GSM中，KASUMI用于A5 / 3密钥流生成器和GEA3密钥流生成器中的GPRS中。还有一些用的较少，所以没有被提到。 GSM认证和加密是如何发生的？每个GSM手机都有一个用户识别模块（SIM）。 SIM通过使用国际移动用户身份（IMSI）为移动电话提供独特的身份。 SIM卡就像一个钥匙，失去的话手机就无法运作。它能够存储个人电话号码和短信息。它还存储诸如A3认证算法，A8加密密钥生成算法，认证密钥（KI）和IMSI之类的安全相关信息。移动台存储了A5加密算法。认证认证过程检查用户SIM卡的有效性，然后判断移动台是否允许在特定网络上。网络通过使用挑战响应方法来完成用户的认证。首先，通过空中接口向移动台发送128位随机数（RAND）。 RAND被传递给SIM卡，通过A3认证算法与Ki一起发送。 A3算法的输出，经签名的响应（SRES）通过空中接口从移动台发送回网络。在网络上，AuC将SRES的值与从移动台接收的SRES的值进行比较。如果SRES的两个值匹配，认证成功，并且用户加入网络。 AuC实际上不存储SRES的副本，但是根据需要查询HLR或VLR。生成SRES 匿名当新的GSM用户第一次打开手机时，其IMSI将被发送到网络上的AuC。之后，临时移动用户身份（TMSI）被分配给用户。除非绝对有必要的话，否则IMSI在此之后很少传输。这样可以防止潜在的窃听者通过其IMSI识别GSM用户。用户继续使用相同的TMSI，具体取决于位置更新发生的频率。每次发生位置更新时，网络都会分配一个新的TMSI到手机。 TMSI与IMSI一起存储在网络中。移动台使用TMSI向网络报告或呼叫启动期间。类似地，网络使用TMSI来与移动台进行通信。访客位置寄存器（VLR）执行TMSI的分配，管理和更新。当关闭时，移动台将TMSI存储在SIM卡上，以确保在再次接通电源时可用. 数据的加密和解密 GSM使用加密密钥来保护用户数据和空中接口的信号。一旦用户认证，通过A8加密密钥生成算法发送RAND（从网络传送）和KI（来自SIM卡），以产生加密密钥（KC）。 A8算法存储在SIM卡上。然后使用A8算法创建的KC与A5加密算法一起加密或解密数据。 A5算法在移动电话的硬件中实现，因为它必须即时加密和解密数据。加密密钥（Kc）的生成使用Kc进行数据加密/解密 GSM授权/加密过程 GSM授权/加密过程 1.当您第一次打开手机时，MS将IMSI发送到网络。 2.当MS请求访问网络时，MSC / VLR通常要求MS进行认证。 MSC将IMSI转发到HLR，并请求认证Triplets。 3.当HLR收到IMSI和认证请求时，首先检查其数据库，确保IMSI有效并属于网络。一旦实现了这一点，它将把IMSI和认证请求转发到认证中心（AuC）。 AuC将使用IMSI查找与该IMSI相关联的Ki。 Ki是个人用户认证密钥。当创建SIM卡时，它是与IMSI配对的128位数字。 Ki只存储在SIM卡和AuC上。 Auc还将生成一个称为RAND的128位随机数。 RAND和Ki被输入到A3加密算法中。输出是32位签名响应（SRES）。当请求认证时，SRES本质上是发送给MS的“挑战”。 RAND，SRES和Kc统称为三元组。 HLR将三元组发送给MSC / VLR。 4.然后，VLR / MSC将只将RAND值转发给MS。 5.MS使用存储在其sim中的Ki和网络发送的RAND值来计算SRES。 MS将此SRES值发送回MSC / VLR。 6.MSC / VLR将SRES值与HLR向其发送的值进行匹配。如果它匹配，它成功授权MS。 7.一旦经过认证，移动和网络都可以通过A8算法使用Ki和RAND值来生成Kc。 8.使用具有A5加密算法的唯一生成密钥（Kc）对数据进行加密/解密。位置更新步骤位置更新过程当你打开你的手机，它首先告诉网络，我在这里，我想注册到网络。之后它发送一个位置更新请求，包括它以前的LAI，它是TMSI。收到TMSI后，如果TMSI不在数据库中，则VLR请求IMSI，收到IMSI后，VLR根据其IMSI向HLR询问用户信息。如果VLR在它的数据库里没有找到TMSI，它将使用LAI找到MS连接到的旧VLR的地址。向旧VLR发送请求，请求用户的IMSI。 VLR提供与MS发送的TMSI相对应的IMSI。请注意，IMSI可能是从移动设备获得的。这不是优先选择，因为位置更新请求被清楚地发送，因此可以用于确定IMSI和TMSI之间的关联。 HLR又要求AuC为这个IMSI的三元组。 HLR将三元组（Rand，Kc，SRES）转发到VLR / MSC。 MSC将从VLR获取详细信息，并只将RAND值传给MS。 MS将再次计算SRES，并将其发送回MSC。 MSC将验证存储在VLR中的SRES，并将与MS发送的SRES进行比较。如果两者匹配，则位置更新成功。成功后，HLR更新发生，它将更新其当前位置，并将TMSI分配给该MS。由于在加密之后TMSI任务被发送，TMSI与用户之间的关系不能由未经授权的用户获得。 GSM手机回复表明新的TMSI分配已经完成。现在，我们将分析wirehark中的gsm数据包，看看在空中的真实情况。 1.立即分配 - 由MS请求的无线信道和MS分配的无线信道MS提供商。我们还可以看到在这个频道中正在使用什么样的控制信道（SDCCH / SACCH）。 2.位置更新请求 - MS发送位置更新请求，其中包括以前的LAI，它是TMSI。 3.验证请求 - VLR / MSC将HLR中的RAND转发给MS。我们可以清楚地看到网络发送到移动电话中的随机值。 4.MS中的SRES生成 - MS将使用存储在sim.5中的Ki的帮助，使用A3认证算法生成SRES值。 5.认证响应 - MS将发送其计算的SRES值。我们可以清楚地看到SRES的值。 6.加密模式命令 - BSC向移动设备发送CIPHERING MODE命令。密码已经被启用，所以这个消息是通过加密传输的。手机用CIPHERED模式回复它。我们也可以看到下面的加密模式完成包。我们可以看到它正在使用A5 / 1密码。 7.接受位置更新 - 成功认证后，位置更新发生在MS向网络提供位置信息的地方。 8.TMSI重新分配完成 - MS提供商将向MS分配TMSI，并且该消息将被加密，使得没有人可以嗅探用户的身份（TMSI）。 9.无线电频道发布 - 分配的无线电频道由MS。现在呢？注意到有时运营商根本没有使用任何加密，以便能够处理更多的网络负载。加密/解密过程增加了开销。有时，身份验证过程的配置存在问题，攻击者可以使用它来绕过完整的身份验证. GSM安全是一个很大的的但还尚未开发的领域，还有很多工作需要探索和完成。现在，当您了解如何分析最低级别的gsm数据时，您可以阅读，分析和修改osmocom的代码，以便将任意帧发送到网络或从网络发送到手机。您可以开始模糊gsm级协议，以了解您是否可以实际破解任何网络设备。还有很多事情要做，但这需要对gsm网络有深刻理解，还有关于这方面的法律问题。我建议您创建自己的gsm网络并运行您的测试，如果你想继续这样做的话。我们将在gsm上发布更多博客文章。敬请期待！参考资料： https://www.sans.org/reading-room/whitepapers/telephone/gsm-standard-an-overview-security-317 http://mowais.seecs.nust.edu.pk/encryption.shtml 原文链接：http://payatu.com/dissecting-gsm-encryption-location-update-process/

广岛秋泽个人页面-阿里云开发者社区

个人介绍

擅长的技术

利用Excel分析IC卡校验码，另附突破金额655.35教程

Inside a low budget consumer hardware espionage implant

Mac OSX 编译 LeanSDR

使用Bash Bunny从被锁定的系统抓取登陆凭据

剖析 GSM 加密机制以及位置更新的过程

破解火车票上的身份证号码

一个简单的Dump转文本工具—Dump2Text

利用烧鹅制作简单BadUSB，插谁谁怀孕

KeySweeper 微软无线键盘嗅探装置

GSM Sniffing入门之硬件篇

GSM Sniffing入门之软件篇：GSMTAP抓取与SMS(Short Message Service)

Motorola C118修改滤波器组件

伪基站和空中信息拦截

OpenSesame:一个能够攻击fixed-pin设备的工具

Kali Linux更新源以及设置中文

将PS/2接口鼠标改造成USB接口鼠标

《头文字D》热门同人插画欣赏

一张图让你理清渗透思路

终端机的安全性

Nexus设备渗透测试平台 – Kali Linux NetHunter

关于站队,有深度

几种开源许可证的区别

[转载]三款SDR平台对比：HackRF，bladeRF和USRP

[追加评论]三款SDR平台对比：HackRF，bladeRF和USRP

12个有趣的 XSS Vector