Xiazhiri

nRF52, Amiibo, Voltage Glitch Attack and Apple Find My

2024-05-18T04:00:00.000Z

date

May 18, 2024

slug

nrf52-amiibo-voltage-glitch-and-apple-find-my

status

Published

Emulating Amiibos

My family's fascination with Animal Crossing necessitates frequent use of Amiibo to invite villagers to their island. Researching available Amiibo emulation methods revealed several options:

NTAG 215:

At its core, Amiibo utilizes NTAG 215 tags. Pre-printed cards are readily available online, and blank cards can be written to using TagMo on a smartphone. These cost approximately $0.07 per card. The drawback is that these cards can only be written to once, necessitating the management of a multitude of physical cards.

NFC Protocol:

NFC Amiibo emulation options range from the aforementioned Amiloop/AmiiboLink, priced at around $2.50, to the pricier N2 Elite and PowerTag, which can cost hundreds of dollars. There's even a method involving 3DS emulation using HubSteven/3ds_ir. The underlying principle of these methods is to connect the device to a computer/smartphone via Bluetooth and write the desired Amiibo data. This allows for unlimited rewriting and currently seems to be the most efficient solution.

Bluetooth Protocol:

Since the Switch's NFC module is integrated into the Joy-Con, emulating a Joy-Con via Bluetooth allows for the transmission of Amiibo data by mimicking a legitimate controller. This includes using Raspberry Pi to emulate Joy-Con functionality with mart1nro/joycontrol. Unfortunately, due to open-source licensing issues, this feature was removed #80, requiring manual code reversion.

Similarly, EasyMCU_ESP32 uses ESP32 to emulate a controller, but the firmware code is not open source. The author has written informative articles on Joycon emulation: ESP32 Simulate NS JoyCon and Pro, Compatible with Amiibo and Amiibo Fake.

There's also a method using Android phones to emulate Bluetooth controllers, but it's limited to specific models.

This approach can be cumbersome, as it requires controller-like pairing each time it's used.

Espruino

While browsing the AmiiboLink / AmiLoop forum post, I discovered that nRF52 can be flashed with Espruino.

Unlike Arduino, this project utilizes a JavaScript interpreter with a web-based IDE Espruino.com IDE, connecting to the device via Web Bluetooth through a browser. This eliminates the need for a data cable during development, making it even more accessible than Arduino. It even has its own "app store" EspruinoApps with some intriguing examples, such as detecting LED flashes on an electricity meter to calculate power consumption with Smart Meter and simulating AirTags with apps/openhaystack.

AmiLoop can function as a Puck.js Puck.js. Thanks to the configuration provided by DanTheMan827, GitHub Actions can be used to effortlessly compile the firmware.

Here is the firmware I compiled:

espruino_2v21.19_amiibolink.hex

Firmware Backup and Flashing

AmiLoop and AmiiboLink share identical hardware, allowing for cross-flashing of firmware. However, their respective apps for controlling Amiibo switching are not interchangeable.

The current factory firmware comes in two versions: v3 and v4. The v4 firmware enables nRF's APPPROTECT chip protection, preventing debugging and data dumping via SWD. However, this lock can be bypassed using a full erase command or a voltage glitch attack.

Due to bootloader incompatibility, flashing requires SWD programming using DAPLink/CMSIS-DAP. The configuration file is as follows:

The OpenOCD/telnet backup/flashing/unlocking steps are as follows:

Voltage Glitch Attack

For nRF52 with APPPROTECT enabled, debugging and data dumping via SWD are disabled. A voltage glitch attack involves altering the chip's power supply at a precise moment, causing it to skip certain logic checks.

A YouTube video by Joe Grand showcases the use of a voltage glitch attack to recover $2 million worth of BTC from a cold wallet.

The video features a humorous moment where the seasoned hacker forgets to ground the device. Ultimately, his wife and children join in celebrating his success. It reminded me of my childhood, watching my father solder a radio with a soldering iron. Having a hands-on, tech-savvy parent is truly a blessing.

For nRF52, atc1441 offers a more affordable solution with ESP32_nRF52_SWD, which utilizes an ESP32 and a MOS switch for the voltage glitch attack. It even features a webpage for adjusting the glitch timing. For increased attack success rates, removing two capacitors is recommended.

This brought back memories of playing NES as a child. On summer evenings with low voltage, the console would display glitched, mosaic-like visuals, inadvertently helping me bypass a challenging level in Metal Max.

Apple Find My and OpenHaystack

I mentioned Espruino's ability to emulate AirTags using OpenHaystack. I had placed a cheap Chinese AirTag alternative, AIYATO, in a package to track its location. The price was astonishingly low at just $3. While it can provide some location updates, it lacks the precision of ultra-wideband technology. For tracking valuables and pets, using genuine AirTags remains the better option.

Find My

The OpenHaystack project provides insights into the Find My network's workflow: An AirTag broadcasts its public key → Nearby iPhones receive the broadcast → iPhones encrypt their GPS location with the public key and upload the encrypted data and the public key hash to Apple's servers → The AirTag owner's phone decrypts the location data using their private key.

To prevent replay attacks and tracking via broadcasts, AirTags periodically rotate their public keys. This rotation is time-based, and if the device loses power and its clock resets, it utilizes a secondary key. Once the clock synchronizes, it resumes rotation based on the primary key. Based on observations, AirTags don't constantly broadcast location reports; they only do so after being separated from their owner for a certain duration.

Since only the hash of the public key is uploaded and the keys are rotated, it would be challenging to block OpenHeystack unless Apple abandons old devices and introduces a new protocol.

Sending Custom Data

This mechanism can also be leveraged to send custom data, allowing for the placement of sensors in offline environments for data transmission. dakhnod/FakeTag implemented a sensor that sends mailbox arrival notifications.

positive-security/send-my takes a more direct and ingenious approach, utilizing Apple's servers as storage. The sender encodes data bits into a public key, and the receiver checks the server for the presence or absence of the public keys, interpreting the results as 0s and 1s to receive the message.

Retrieving Data

OpenHeystack requires a Mail plugin to send requests to Apple's servers (similar to older versions of AltStore). However, Mail plugins have been deprecated in newer macOS versions. In testing, malmeloo/FindMy.py and hajekj/OfflineFindRecovery were able to successfully retrieve data from the servers.

If you simply want to access location history for Find My devices, fjxmlzn/FindMyHistory is a useful tool, although it can only retrieve newer data locally. Apple's servers store records for the past seven days.

It's important to note that while OpenHeystack utilizes Apple's Find My network, the devices will not appear in the Find My app. You can obtain the private keys for your bound devices from Keychain. FindMy.py/issues/4 provides instructions on extracting private keys from Keychain and the calculation method for rotating public keys.

Conclusion

nRF52 offers superior energy efficiency compared to ESP32, making it ideal for battery-powered devices. Its low power consumption, coupled with Espruino's user-friendliness, unlocks immense potential in DIY and IoT applications, particularly in areas like smart homes, wearables, and environmental monitoring.

Simultaneously, the OpenHaystack project offers valuable insights into the inner workings of Apple's Find My network while raising important considerations surrounding privacy and security. As technology continues to advance, nRF52, Espruino, and OpenHaystack are poised to bring forth even more exciting possibilities and innovations.

Android System Development Intro (WIP)

2023-12-01T05:00:00.000Z

There are a lot of articles about Android application development on the Internet, but not many articles about system development, this article intends to record the Android system development related content, and also a summary of my work in the previous few years.

This article is planned to be structured as follows

1. Gerrit & Code

Simply, AOSP source code is a collection of git repositories managed by a manifest file, and Gerrit is the system hold all the code. It is also used to control permissions and code review.

Managing gerrit is done through ssh connections on gerrit port 29418, e.g..

The process of importing AOSP source code into Gerrit is iterate over all the repositories in the manifest, then create project using the create-project command, then git push the code into the corresponding project.

Creating a new stable branch in Code Management is just iterating through all the repositories and fixing the version with create-branch command. The manifest for the version can be generated by repo manifest -r -o, which is usually generated during dailybuild.

WIP

2. Android system compilation

3. System Modification

3.1 Application Integration

3.2 System Modifications

4. System Application Development

5. Other tools

5.1 OpenGrok

Patch Vysor 4.1.77

2022-05-15T04:00:00.000Z

Patch

Result

Debug

Mercury MIPC251C-4 Web Camera with ONVIF and PTZ Control

2019-07-23T04:00:00.000Z

TL;DR

Charles cannot capture packets. APK decompile but no luck, control CMD implemented in JNI. But WireShark can capture control packets for iOS app. Login logic can be found in admin web page.

The Script: https://github.com/likaci/mercury-ipc-control

Overview

Recently, I found a Mercury IPC on SMZDM. Apart from supporting PTZ and night vision features, it also claims to support the ONVIF protocol. So I decided to buy one and add it to HomeAssistant for monitoring. However, after getting my hands on it, I realized that things weren't as simple as it seemed. Here are my findings.

Integrating with HomeAssistant

According to the HomeAssistant documentation on ONVIF Camera, integrating should be as simple as adding a couple of lines in the configuration file. But whether I used the default configuration or tried various ports on the backend page, I couldn't add the camera successfully.

Finally, using DSM Surveillance Station from Synology, I found the correct port. Later, I discovered that I could also find the correct port using iSpy. The port is 2020.

Here is the HomeAssistant configuration:

ONVIF and RTSP Parameters

ONVIF URL:

http://192.168.2.x:2020/onvif/device_service

RTSP 1920x1080 URL:

rtsp://admin:pass@192.168.2.x:554/stream1

RTSP 640x480 URL: rtsp://admin:pass@192.168.2.x:554/stream2

PTZ / Pan-Tilt-Zoom Control

After integrating with HomeAssistant and DSM Surveillance Station, I realized that PTZ control was not working. It seems that the claim of ONVIF support only applies to recording.

The rest of this article focuses on how to control the PTZ function.

Capturing Packets

I tried capturing packets using Charles, but the application didn't go through the configured proxy.

Decompiling the Android App

After unsuccessful attempts to capture packets using Charles, I tried decompiling the Mercury Security App. To my surprise, I found a lot of code related to com.tplink.ipc, indicating that Mercury is indeed a sibling of TP-Link. The app is obfuscated, which makes it challenging to analyze.

Adding Local LAN Devices: com.tplink.ipc.ui.device.add.DeviceAddByDeviceDetailInputFragment

Login: com.tplink.ipc.ui.device.add.DeviceAddByDeviceDetailInputFragment#xcom.tplink.ipc.core.IPCAppContext#devReqAddDevice(java.lang.String, int, java.lang.String, java.lang.String, int, int). The devReqAddDevice method calls a native function, and the actual implementation is found in libIPCAppContextJNI.so. It seems that the network requests are made within the JNI code, making it difficult to capture them using Charles. Decompiling the .so library is not worth the effort, so let's try a different approach.

WireShark iOS Packet Capture

Using rvictl, I can also capture packets over 3G/4G connections, which is useful for capturing packets related to issues that only occur in a 4G environment. Additionally, for devices that do not support setting up a proxy, I can enable the iPhone's personal hotspot and capture packets that way.

To capture packets, run the following command:

rvictl -s 0000xxxx-00xxxxxxxxxxxxxx

I discovered the network requests for the login and PTZ control steps:

Login

Retrieve stok:

Control

Use the obtained stok to send POST requests:

Summary

Currently, it seems that obtaining the stok is the key to controlling the PTZ function. It can be obtained by capturing packets, but it seems to become invalid after the device restarts or after some time has passed (not confirmed).

Obtaining `stok`

Although this camera has a web interface, it does not support PTZ control through the web. Therefore, in the initial packet capture, I did not consider the web interface. However, after analyzing the web interface, I found that the login verification process uses the same logic.

Here are the steps:

Retrieve the RSA public key and nonce (both change every time)

Encrypt the password password as tpPassword using TP-Link's universal encryption method

Append :nonce to tpPassword as tpPassword:nonce

Encrypt tpPassword:nonce using the public key as rsaPassword

Send rsaPassword as the password for camera verification

Regarding steps 2 and 3, here is the record:

Encrypting Password as `tpPassword` Using TP-Link Encryption

A search for "RDpbLfCPsJZ7fiv" reveals various implementations of this encryption method.

Encrypting `tpPassword` as `rsaPassword` Using RSA

In the image, a = a.concat(":", $.authRltObj.nonce) appends the nonce. c.setPublicKey($.authRltObj.key) sets the public key. The subsequent sendAjaxReq is thecontinuation of the process.

The Script

Based on the analysis above, I have written a control script.

https://github.com/likaci/mercury-ipc-control

Android Method Trace Generation and Analysis

2017-10-11T04:00:00.000Z

The Profiler tool in Android Studio 3.0 has made significant progress compared to the 2.0 version. I have reviewed the relevant source code and recorded the following information:

Generating Trace Files

There are two main ways to generate trace files as mentioned in the official documentation.

Code

The first method involves adding code to your project:

This will generate the trace file.

ddmlib

The second method involves using ddms/Android Monitor to manually generate the trace file. ddms relies on a library called ddmlib, which can be found in the Android SDK at tools/lib/ddmlib-*.jar.

There are not many articles available about ddmlib, but you can refer to the following resources: Hidden Boss - Getting Started with ddmlib and Using adb with ddmlib, Building Framework Libraries.

Command-line Tool

While exploring the source code, I encountered numerous challenges and wrote a command-line tool called AndroidMethodTraceRunner.

To use it, run the following command: $ java -jar mtr.jar -p com.your.package -o output.trace -t 10 to trace for 10 seconds. Please note that it requires Java 8 to run.

There are two main issues to be aware of:

AndroidDebugBridge.init(true) - If set to false, the client cannot be accessed.

You must close ddms and the Studio monitor/profiler, otherwise, they will preempt the client and cause a connection failure.

Here are a few key concepts related to ddmlib:

Bridge - adb

Device - the connected device

Client - the application

The main code snippet is as follows:

Android Studio

However, Android Studio 3.0 does not use ddmlib.

The general call stack is as follows:

Trace Parsing/Reading

GUI

ddms or Android Studio 2.0/IntelliJ IDEA can directly open trace files, but they are not as user-friendly as the profiler in Android Studio 3.0.

Command Line Tool

Based on the above analysis I wrote a command line tool based on ddmlib to run Android Method Trace on the fly.

https://github.com/likaci/AndroidMethodTraceRunner

Locate Android ARP storms with WireShark and strace

2017-09-30T04:00:00.000Z

In the past few days, some users have been complaining about Android TV sending a lot of ARP packets. The user use Wireshark to grab packets and found that the TV sends 1000 arp packets in a minute, but can't locate the specific app.

Finally, use strace -f -p PID | grep sendto and wireshark to locate the process

Lint Aosp App With SonarQube

2017-06-06T04:00:00.000Z

Background

Third-party apps can directly use Lint to display results in Android Studio. When compiling the source code, running lint packages/apps/Calendar/ in the project root directory after "make" can also lint. However, when actually using lint vendor/letv/apps/Camera/, it prompts No bytecode found: Has the project been built? (Camera), and there are also false positives for resource usage.

Cause

Analyzing the lint source code reveals that

lint/detector/api/Project.java#654

Lint will try to find ModuleName_intermediates/classes.jar in the out directory. If it cannot be found, it will report "No bytecode found".

For example, /letv/workspace/DEMETER_FINAL/out/target/common/obj/APPS/StvCamera_intermediates

However, there are two reasons for not finding it:

Starting from Android M, AOSP uses Jack for compilation (JaCoCo starting from Android N?), and classes.jar is not generated during Jack compilation. Instead, classes.jack / classes.dex are generated.

In the getIntermediateDirs() method, moduleName = mDir.getName() instead of LOCAL_PACKAGE_NAME specified in vendor/letv/app/**/Android.mk

Disabling Jack / dex2jar

For problem 1, either disable Jack to prevent the generation of classed.jar during make, or convert classes.dex to classes.jar.

Disabling Jack for the entire project will cause make to fail. Disabling at the module level has been tried, but it does not work.

Testing dex2jar is feasible.

Modifying lint-api.jar

For problem 2, modifying lint-api.jar is simpler than compiling the entire lint tool. The method is similar to modifying CrossWalk.jar.

The modification process is described in https://github.com/likaci/android-lint-mod-jar/commits/master

In addition, the lint used in the source code environment is an older version from DEMETER_FINAL/prebuilts/devtools/tools/lint. Using the latest lint-api for modification directly, but the latest lint requires jre8 to execute.

Usage

Take DEMETER_FINAL/vendor/letv/apps/Camera/ as an example.

Download https://github.com/likaci/android-lint-mod

Modify line 92 of bin/lint to set JAVACMD="/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java" to the appropriate jre8 path.

Make the entire AOSP project.

Download dex2jar from https://github.com/pxb1988/dex2jar/releases and extract it to a suitable path.

Afterwards, run SonarScanner specifying -Dsonar.android.lint.report=./lint-report.xml

References

Using Lint to Improve Your Code - https://developer.android.com/studio/write/lint.html

Compiling with Jack - https://source.android.com/source/jackey

Using SonarQube with Jenkins Continuous Integration and GitHub to Improve Code Review - http://macoscope.com/blog/using-sonarqube-with-jenkins-continuous-integration-and-github-to-improve-code-review/