[Android Software/Hacking General [Developers Only]] ogurets:
Hi everyone! This is a deep dev-related question, but I don't have permission to post into dev forums.

My goals are - implement Wifi monitor mode and enable FM Transmission capability. Since they are both related to one chip, I decided to put them into one post (sorry if this decision was wrong).

What do we have now:

The chip - general info

Is an ARM7-based SoC, combining features of it's ancestors: WLAN (MT5921), Bluetooth/FM (MT6616) and GPS (MT3326).

I've found the drivers for it in this repo: https://github.com/bq/aquaris-E5, wlan path: mediatek/kernel/drivers/combo/drv_wlan, fm path: mediatek/kernel/drivers/fmradio/mt6620.

There is an NVRAM map here: http://www.datasheet-pdf.com/datasheet-download.php?id=955336

And it's description (with pinout, block chart, but no specific details about it's ARM core): http://www.bluetooth.org/tpg/RefNotes/MT6620_RIN_Product_Brief_20101110.docx

Added: Found out that we cannot trust /system/build.prop for checking out a chip id. Drivers (lsmod) are not good indication either. You can use a built-in ioctl utility to issue a request directly to the chip like this:

ioctl -l 4 /dev/fm -1073416950

It doesn't parse a proper hex representation of the ioctl (0xС004f519) correctly, so I had to use this signed notation.

Turned out that Philips S388 has MT6627, which doesn't even have an FM Tx block in hardware: http://www.cnping.com/wp-content/uploads/2015/12/MT6627_Data_Sheet_v03a.pdf

Unluckily, my another device (PAP4044 Duo) has an MT6628 chip, which also doesn't support Tx: https://github.com/luckasfb/Develop...s/MT6628/MT6628T_external_datasheet_v1.2b.pdf

But curiously, it doesn't even have FM_IOCTL_TX_SUPPORT ioctl implemented, while S388 responds fine to it. You can check it for your device like this:

ioctl -l 4 /dev/fm -1073416935

If you get a "01 00 00 00" response, it would mean really good news - that your device supports TX and it is not disabled by the driver!

Wlan - low level packet reading/writing

libhardware_legacy.so on my Philips S388 enables wifi by calling "wifi_change_fw_path", which loads one of the 3 firmware (driver?) flavors: "STA", "STA+P2P" or "AP".

Firmware is located at /etc/firmware/WIFI_RAM_CODE, I attached it to the post.

According to "firmware_download" function, firmwares can be single-chunked (like this one) or have the header described by these structs:

typedef struct _FWDL_SECTION_INFO_T
{
UINT_32 u4Offset;
UINT_32 u4Reserved;
UINT_32 u4Length;
UINT_32 u4DestAddr;
} FWDL_SECTION_INFO_T;

typedef struct _FIRMWARE_DIVIDED_DOWNLOAD_T
{
UINT_32 u4Signature;
UINT_32 u4CRC; /* CRC calculated without first 8 bytes included */
UINT_32 u4NumOfEntries;
UINT_32 u4Reserved;
FWDL_SECTION_INFO_T arSection[];
} FIRMWARE_DIVIDED_DOWNLOAD_T;

u4Signature is "MTKW" for multi-chunk files. I've attached one of these multi-chunk firmwares also for you to see how they look like.

The chunks themselves look packed/encrypted, no visible headers. Doesn't look like a proper ARM code either.

And this part of code suggests some on-chip encryption (WTF?! It's not a smart-card or crypto chip):

prInitCmdDownloadBuf->u4DataMode = 0 | 0x1; // enable encryption

Added: Now I'm sure the stuff is encrypted. I've tried to figure out the cipher's specs and think it is either 8-byte block cipher or streaming cipher. Analyzing some datasheets and background info on Mediatek I've narrowed down possible candidates to RC4, DES, 3DES or some makeshift repeating key xor cipher.

I've seen some weird patterns in data like these, enforcing the latter idea:

View attachment 4120336

But xor'ing different parts together does not break data uniformity. Also a Hamming distance analysis doesn't apply here - it gives a key length of 36 bytes, which doesn't make sense.

If someone's good with crypto, I desperately need your advice.

Added2: I've effectively excluded RC4 as it doesn't produce repeating patterns and 95% sure it is 3DES in EDE mode like this:

openssl des -e -nosalt -des-ede3 -in plaintext -out 3des.cyp

Also using test mode MCR (MCU Register?) functions, I've managed to dump around 4 megs of something (attached as "something.zip"), which, according to the driver sources, could contain the decrypted firmware at offset 0x60000. And it does, judging by the size of the block and location of some characteristic zero-gaps, but despite of being non-packed and non-crypted, still doesn't make sense as an ARM code.

FM Transmission

Driver contains ioctls for TX mode:

#define FM_IOCTL_TX_SUPPORT _IOWR(FM_IOC_MAGIC, 25, int32_t*)
#define FM_IOCTL_RDSTX_SUPPORT _IOWR(FM_IOC_MAGIC, 26, int32_t*)
#define FM_IOCTL_RDSTX_ENABLE _IOWR(FM_IOC_MAGIC, 27, int32_t*)
#define FM_IOCTL_TX_SCAN _IOWR(FM_IOC_MAGIC, 28, struct fm_tx_scan_parm*)

And their implementation:

/*****tx function****/
ops->bi.tx_support = mt6620_Tx_Support;
ops->bi.pwrupseq_tx = mt6620_PowerUpTx;
ops->bi.tune_tx = MT6620_SetFreq_Tx;
ops->bi.pwrdownseq_tx = mt6620_PowerDownTx;
ops->bi.tx_scan = mt6620_TxScan;

Don't worry about TX_SUPPORT, the support availability seems to be out of the question:

static fm_s32 mt6620_Tx_Support(fm_s32 *sup)
{
*sup=1;
return 0;
}

However, I cannot guarantee the TX is not disabled by firmware (see above). Didn't dig well into this, since this feature is my 2-nd priority.

This is a tough stuff to pull off alone, so I'm looking for those who's interested and willing to join the effort.