[Replicant] Replicant on Nexus One

[Denis 'GNUtoo' Carikli]

On Tue, 23 Jan 2018 01:02:00 +0000
Kurtis Hanna <kurtis at riseup.net> wrote:

> Hi Denis,
Hi,

> I'm curious, does nonfree software (via the modem) control the
> microphone on the S2 and S3, or not?
The rationale behind that is what software is able 

> Also, Have these hardware audits for currently supported Replicant
> devices been published on Replicant's redmine somewhere?
Yes, they are links to them on the device pages:
https://redmine.replicant.us/projects/replicant/wiki/GalaxyS3I9300
links to:
https://redmine.replicant.us/projects/replicant/wiki/GalaxyS3I9300PrivacySecurityEvaluation


If I quote the page:
> The bootloader is proprietary and signed.
I don't have good references on it being signed. Still, it's a well
known fact that.

[...]

> Modem related:
> The modem runs non-free software, which is loaded but not shipped by
> Replicant.
Here as with the bootloader, since it's not free software, it's nonfree.

>     When using flight mode, The main CPU has to ask the modem to
> power itself off.
This can be found in libsamsung-ipc and samsung-ril source code.

> The modem is isolated:
>         It doesn't use shared memory with the CPU, instead it uses an
> "HSIC" bus.
This can be found in the Linux kernel driver for the modem.

> We are not aware of it being able to access the GPS, but
> it wouldn't be surprising if it still could (by having a direct
> connection to it: since no schematics are publicly available we have
> easy no way to check). It has no access to the other CPU peripherals.
Here the rationale is that the CPU controls the CODEC. This is
typically the case with many devices using ARM SOCs. Qualcomm is an
exception in that area. It can be verified by looking at the sounds
driver in the kernel source code.

Typically you have that:
SOC(CPU that runs the Linux kernel)
  ^                      ^
  | I2S or PCM           | I2C (Control)
  | (digital Sound)      |
  v                      v
+----------------------------+<->Speaker
| CODEC                      |<->Microphone
+----------------------------+<->Headphones jack
  ^                     ^
  | I2S                 | I2S
  +------> Modem sound  +----->Bluetooth sound


== Analysis example ==
Now we will redo this analysis for the i9300. We'll start with the
modem.

First, the device is made by Samsung and its codename is i9300,
so we look in device/samsung/i9300/BoardConfig.mk, and we find that:
> # Kernel
> TARGET_KERNEL_SOURCE := kernel/samsung/smdk4412
> TARGET_KERNEL_CONFIG := cyanogenmod_i9300_defconfig
So we can now go in kernel/samsung/smdk4412 and look for
cyanogenmod_i9300_defconfig inside it. Such configurations are
typically found in arch/arm/configs, so I found it there.

looking at cyanogenmod_i9300_defconfig with 
> grep MODEM arch/arm/configs/cyanogenmod_i9300_defconfig | grep -v ^#
shows:
> CONFIG_EHCI_MODEM_PORTNUM=2
> CONFIG_SEC_MODEM_M0=y
> CONFIG_SEC_MODEM=y
> CONFIG_UMTS_MODEM_XMM6262=y

grepping the source code shows mention of UMTS_MODEM_XMM6262 in
drivers/misc/modem_if/

This then shows 2 drivers involved:
- modem_modemctl_device_xmm6262.c: Looking at the source file shows
  that there is nothing interesting there: It is a driver made to power
  on and off the modem and reset it trough GPIOs.
- modem_link_device_hsic.c: This is the interesting part. HSIC is a bus
  that connects the modem to the Exynos SOC. Since I didn't know if
  HSIC enabled a device to have access to the Exynos SOC's RAM
  (Through DMA), I remember having asked someone who knew, probably on
  IRC, but I don't remember who.

For the sound we proceed the same way:
> $ grep CONFIG_SND arch/arm/configs/cyanogenmod_i9300_defconfig | \
> grep > -v "^#"
And we have:
> CONFIG_SND=y
> CONFIG_SND_TIMER=y
> CONFIG_SND_PCM=y
> CONFIG_SND_HWDEP=y
> CONFIG_SND_RAWMIDI=y
> CONFIG_SND_JACK=y
> CONFIG_SND_DEBUG=y
> CONFIG_SND_USB=y
> CONFIG_SND_USB_AUDIO=y
Theses are generic configuration, not very interesting.

> CONFIG_SND_SOC=y
> CONFIG_SND_SOC_SAMSUNG=y
> CONFIG_SND_SAMSUNG_I2S=y
This is the Exynos SOC drivers

> CONFIG_SND_SOC_SAMSUNG_MIDAS_WM1811=y
This is probably the driver that binds together the SOC and the CODEC

> CONFIG_SND_SOC_SAMSUNG_I2S_SEC=y
> CONFIG_SND_SAMSUNG_ALP=y
> CONFIG_SND_USE_SUB_MIC=y
> CONFIG_SND_USE_MUIC_SWITCH=y
> CONFIG_SND_SOC_I2C_AND_SPI=y
> CONFIG_SND_SOC_WM_HUBS=y
Some other configurations and drivers involved in it.

> CONFIG_SND_SOC_WM8994=y
This is probably the CODEC driver

[...]
> CONFIG_SND_SOC_USE_EXTERNAL_MIC_BIAS=y

Here having just read the kernel configuration, we can deduce with
high enough confidence that it should use something that is similar to
the hardware configuration I described above with the ASCII art.

> Terminal profile
This is a link to
https://terminal-profile.osmocom.org/decode.php?tp=ffffffff7f1f00dfff00001fa2010a860749000000000000000000000010

There are more information on what it is here:
https://terminal-profile.osmocom.org, but I'm not fluent with the SIM
standard, so I do not a high enough confidence to draw conclusions.

> TODO:
The device evaluation is not complete

>     Investigate TrustZone and other potential issues with the
> bootloader.
Here TrustZone is to be taken into account as it runs on the same CPU
than Replicant, with higher privilege, so it may be able to make
Android do things like enable the microphone.

A way to deal with it would be to buy an extra Samsung Galaxy S3, and
to make sure the eMMC is blanked in a way that the bootrom would skip
it, and then to boot it on a microSD and start investigating how we can
remove the code that runs in TrustZone.
This can probably be done without much work, but to have a functional
device, the device would need to use a Linux kernel that doesn't depend
on TrustZone. Adding support for the Galaxy S3 in the upstream Linux
could fix that. Also we need to investigate how to deal with this
modification, for instance how users are supposed to do it, and whether
it can be done without nonfree software being redistributed along the
way.

> Investigate device factory reset security in both
> Replicant and its recovery (Does it really wipe files?)
Deleting a file on a hard disk doesn't really delete the file content,
but only marks the space occupied by it as free. We need to understand
if Replicant recovery wipes the data correctly or not and what can be
recovered after it did a full wipe.
To do that one need to:
- Install latest Replicant and recovery image
- Fill the internal memory with many files (Music, documents, etc)
- Wipe everything from the recovery
- install Replicant 4.2 recovery and boot on it
- Do adb shell "cat /dev/block/mmcblkN" > mmcblkN.raw (Change N with the
  right number for the internal eMMC). This will produce a dump on your
  computer.
- Analyze the dump with photorec.
- Also check if there is a wipe settings inside Replicant settings,
  and how it works. If it does it without the recovery, redo the same
  analysis for it.

> Investigate
> the flash layout,
I don't know what it means here, I lack context

> EMMC partitions,
This means looking at all the EMMC partitions and looking if there is
anything we missed. TrustZone should be on one of such partition for
instance.

> EMMC firmware
The EMMC firmware is non-free(it's inside the eMMC, Replicant doesn't
see it), see the following CCC talk for more details:
https://media.ccc.de/v/34c3-8784-emmc_hacking_or_how_i_fixed_long-dead_galaxy_s3_phones

This talk can also be useful for booting on uSD instead of the internal
eMMC to do test related to TrustZone and analyze EMMC partitions.

> If not, can
> you post on the wiki any notes that you took when you did these
> hardware audits so that others can reference them?
The above is a kind of rough HOWTO, can you try to convert it to a
proper wiki page, or if you can't, point to it and ask people to do it
while you point to it.

> Are there any legal issues related to us posting the images that
> Jookia put in the chat in the wiki?
Paul knows how to do it properly. I guess you still have something that
looks like fair-use on such material.

Also if there are schematics, the wiki should be updated to take that
into account too (like at least mention that there are some schematics
or diagram on the web), else the wiki information would have become
inaccurate over time.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20180123/9a8edf70/attachment.asc>