mirror of
https://github.com/Next-Flip/Momentum-Firmware.git
synced 2026-04-24 03:29:57 -07:00
Wiki > Docs
This commit is contained in:
Clara K
2
documentation/.gitignore
vendored
2
documentation/.gitignore
vendored
@@ -1,2 +0,0 @@
|
||||
/html
|
||||
/latex
|
||||
@@ -1,137 +0,0 @@
|
||||
# Flipper Application Manifests (.fam)
|
||||
|
||||
All components of Flipper Zero firmware — services, user applications, and system settings — are developed independently. Each component has a build system manifest file named `application.fam`, which defines the basic properties of that component and its relations to other parts of the system.
|
||||
|
||||
When building firmware, **`fbt`** collects all application manifests and processes their dependencies. Then it builds only those components referenced in the current build configuration. See [FBT docs](./fbt.md#firmware-application-set) for details on build configurations.
|
||||
|
||||
## Application definition
|
||||
|
||||
A firmware component's properties are declared in a Python code snippet, forming a call to the `App()` function with various parameters.
|
||||
|
||||
Only two parameters are mandatory: **_appid_** and **_apptype_**. Others are optional and may only be meaningful for certain application types.
|
||||
|
||||
### Parameters
|
||||
|
||||
- **appid**: string, application ID within the build system. It is used to specify which applications to include in the build configuration and resolve dependencies and conflicts.
|
||||
|
||||
- **apptype**: member of FlipperAppType.\* enumeration. Valid values are:
|
||||
|
||||
| Enum member | Firmware component type |
|
||||
| ----------- | ------------------------------------------------------------------------------------------- |
|
||||
| SERVICE | System service, created at early startup |
|
||||
| SYSTEM | Application is not being shown in any menus. It can be started by other apps or from CLI |
|
||||
| APP | Regular application for the main menu |
|
||||
| PLUGIN | Application to be built as a part of the firmware and to be placed in the Plugins menu |
|
||||
| DEBUG | Application only visible in Debug menu with debug mode enabled |
|
||||
| ARCHIVE | One and only Archive app |
|
||||
| SETTINGS | Application to be placed in the system settings menu |
|
||||
| STARTUP | Callback function to run at system startup. Does not define a separate app |
|
||||
| EXTERNAL | Application to be built as `.fap` plugin |
|
||||
| METAPACKAGE | Does not define any code to be run, used for declaring dependencies and application bundles |
|
||||
|
||||
- **name**: name displayed in menus.
|
||||
- **entry_point**: C function to be used as the application's entry point. Note that C++ function names are mangled, so you need to wrap them in `extern "C"` to use them as entry points.
|
||||
- **flags**: internal flags for system apps. Do not use.
|
||||
- **cdefines**: C preprocessor definitions to declare globally for other apps when the current application is included in the active build configuration.
|
||||
- **requires**: list of application IDs to include in the build configuration when the current application is referenced in the list of applications to build.
|
||||
- **conflicts**: list of application IDs with which the current application conflicts. If any of them is found in the constructed application list, **`fbt`** will abort the firmware build process.
|
||||
- **provides**: functionally identical to **_requires_** field.
|
||||
- **stack_size**: stack size in bytes to allocate for an application on its startup. Note that allocating a stack too small for an app to run will cause a system crash due to stack overflow, and allocating too much stack space will reduce usable heap memory size for apps to process data. _Note: you can use `ps` and `free` CLI commands to profile your app's memory usage._
|
||||
- **icon**: animated icon name from built-in assets to be used when building the app as a part of the firmware.
|
||||
- **order**: order of an application within its group when sorting entries in it. The lower the order is, the closer to the start of the list the item is placed. _Used for ordering startup hooks and menu entries._
|
||||
- **sdk_headers**: list of C header files from this app's code to include in API definitions for external applications.
|
||||
- **targets**: list of strings and target names with which this application is compatible. If not specified, the application is built for all targets. The default value is `["all"]`.
|
||||
|
||||
#### Parameters for external applications
|
||||
|
||||
The following parameters are used only for [FAPs](./AppsOnSDCard.md):
|
||||
|
||||
- **sources**: list of strings, file name masks used for gathering sources within the app folder. The default value of `["*.c*"]` includes C and C++ source files. Applications cannot use the `"lib"` folder for their own source code, as it is reserved for **fap_private_libs**.
|
||||
- **fap_version**: tuple, 2 numbers in the form of (x,y): application version to be embedded within .fap file. The default value is (0,1), meaning version "0.1".
|
||||
- **fap_icon**: name of a `.png` file, 1-bit color depth, 10x10px, to be embedded within `.fap` file.
|
||||
- **fap_libs**: list of extra libraries to link the application against. Provides access to extra functions that are not exported as a part of main firmware at the expense of increased `.fap` file size and RAM consumption.
|
||||
- **fap_category**: string, may be empty. App subcategory, also determines the path of the FAP within the apps folder in the file system.
|
||||
- **fap_description**: string, may be empty. Short application description.
|
||||
- **fap_author**: string, may be empty. Application's author.
|
||||
- **fap_weburl**: string, may be empty. Application's homepage.
|
||||
- **fap_icon_assets**: string. If present, it defines a folder name to be used for gathering image assets for this application. These images will be preprocessed and built alongside the application. See [FAP assets](./AppsOnSDCard.md#fap-assets) for details.
|
||||
- **fap_extbuild**: provides support for parts of application sources to be built by external tools. Contains a list of `ExtFile(path="file name", command="shell command")` definitions. **`fbt`** will run the specified command for each file in the list.
|
||||
|
||||
Note that commands are executed at the firmware root folder, and all intermediate files must be placed in an application's temporary build folder. For that, you can use pattern expansion by **`fbt`**: `${FAP_WORK_DIR}` will be replaced with the path to the application's temporary build folder, and `${FAP_SRC_DIR}` will be replaced with the path to the application's source folder. You can also use other variables defined internally by **`fbt`**.
|
||||
|
||||
Example for building an app from Rust sources:
|
||||
|
||||
```python
|
||||
sources=["target/thumbv7em-none-eabihf/release/libhello_rust.a"],
|
||||
fap_extbuild=(
|
||||
ExtFile(
|
||||
path="${FAP_WORK_DIR}/target/thumbv7em-none-eabihf/release/libhello_rust.a",
|
||||
command="cargo build --release --verbose --target thumbv7em-none-eabihf --target-dir ${FAP_WORK_DIR}/target --manifest-path ${FAP_SRC_DIR}/Cargo.toml",
|
||||
),
|
||||
),
|
||||
```
|
||||
|
||||
- **fap_private_libs**: list of additional libraries distributed as sources alongside the application. These libraries will be built as a part of the application build process.
|
||||
Library sources must be placed in a subfolder of the `lib` folder within the application's source folder.
|
||||
Each library is defined as a call to the `Lib()` function, accepting the following parameters:
|
||||
|
||||
- **name**: name of the library's folder. Required.
|
||||
- **fap_include_paths**: list of the library's relative paths to add to the parent fap's include path list. The default value is `["."]`, meaning the library's source root.
|
||||
- **sources**: list of filename masks to be used for gathering include files for this library. Paths are relative to the library's source root. The default value is `["*.c*"]`.
|
||||
- **cflags**: list of additional compiler flags to be used for building this library. The default value is `[]`.
|
||||
- **cdefines**: list of additional preprocessor definitions to be used for building this library. The default value is `[]`.
|
||||
- **cincludes**: list of additional include paths to be used for building this library. Paths are relative to the application's root. This can be used for providing external search paths for this library's code — for configuration headers. The default value is `[]`.
|
||||
|
||||
Example for building an app with a private library:
|
||||
|
||||
```python
|
||||
fap_private_libs=[
|
||||
Lib(
|
||||
name="mbedtls",
|
||||
fap_include_paths=["include"],
|
||||
sources=[
|
||||
"library/des.c",
|
||||
"library/sha1.c",
|
||||
"library/platform_util.c",
|
||||
],
|
||||
cdefines=["MBEDTLS_ERROR_C"],
|
||||
),
|
||||
Lib(
|
||||
name="loclass",
|
||||
cflags=["-Wno-error"],
|
||||
),
|
||||
],
|
||||
```
|
||||
|
||||
For that snippet, **`fbt`** will build 2 libraries: one from sources in `lib/mbedtls` folder and another from sources in the `lib/loclass` folder. For the `mbedtls` library, **`fbt`** will add `lib/mbedtls/include` to the list of include paths for the application and compile only the files specified in the `sources` list. Additionally, **`fbt`** will enable `MBEDTLS_ERROR_C` preprocessor definition for `mbedtls` sources.
|
||||
For the `loclass` library, **`fbt`** will add `lib/loclass` to the list of the include paths for the application and build all sources in that folder. Also, **`fbt`** will disable treating compiler warnings as errors for the `loclass` library, which can be useful when compiling large 3rd-party codebases.
|
||||
|
||||
Both libraries will be linked with the application.
|
||||
|
||||
## `.fam` file contents
|
||||
|
||||
The `.fam` file contains one or more application definitions. For example, here's a part of `applications/service/bt/application.fam`:
|
||||
|
||||
```python
|
||||
App(
|
||||
appid="bt_start",
|
||||
apptype=FlipperAppType.STARTUP,
|
||||
entry_point="bt_on_system_start",
|
||||
order=70,
|
||||
)
|
||||
|
||||
App(
|
||||
appid="bt_settings",
|
||||
name="Bluetooth",
|
||||
apptype=FlipperAppType.SETTINGS,
|
||||
entry_point="bt_settings_app",
|
||||
stack_size=1 * 1024,
|
||||
requires=[
|
||||
"bt",
|
||||
"gui",
|
||||
],
|
||||
order=10,
|
||||
)
|
||||
```
|
||||
|
||||
For more examples, see `.fam` files from various firmware parts.
|
||||
@@ -1,80 +0,0 @@
|
||||
# FAP (Flipper Application Package)
|
||||
|
||||
[fbt](./fbt.md) supports building applications as FAP files. FAPs are essentially `.elf` executables with extra metadata and resources bundled in.
|
||||
|
||||
FAPs are built with the `faps` target. They can also be deployed to the `dist` folder with the `fap_dist` target.
|
||||
|
||||
FAPs do not depend on being run on a specific firmware version. Compatibility is determined by the FAP's metadata, which includes the required [API version](#api-versioning).
|
||||
|
||||
## How to set up an application to be built as a FAP
|
||||
|
||||
FAPs are created and developed the same way as internal applications that are part of the firmware.
|
||||
|
||||
To build your application as a FAP, create a folder with your app's source code in `applications_user`, then write its code the way you'd do when creating a regular built-in application. Then configure its `application.fam` manifest, and set its _apptype_ to FlipperAppType.EXTERNAL. See [Application Manifests](./AppManifests.md#application-definition) for more details.
|
||||
|
||||
- To build your application, run `./fbt fap_{APPID}`, where APPID is your application's ID in its manifest.
|
||||
- To build your app and upload it over USB to run on Flipper, use `./fbt launch_app APPSRC=applications/path/to/app`. This command is configured in the default [VS Code profile](../.vscode/ReadMe.md) as a "Launch App on Flipper" build action (Ctrl+Shift+B menu).
|
||||
- To build all FAPs, run `./fbt faps` or `./fbt fap_dist`.
|
||||
|
||||
## FAP assets
|
||||
|
||||
FAPs can include static and animated images as private assets. They will be automatically compiled alongside application sources and can be referenced the same way as assets from the main firmware.
|
||||
|
||||
To use that feature, put your images in a subfolder inside your application's folder, then reference that folder in your application's manifest in the `fap_icon_assets` field. See [Application Manifests](./AppManifests.md#application-definition) for more details.
|
||||
|
||||
To use these assets in your application, put `#include "{APPID}_icons.h"` in your application's source code, where `{APPID}` is the `appid` value field from your application's manifest. Then you can use all icons from your application's assets the same way as if they were a part of `assets_icons.h` of the main firmware.
|
||||
|
||||
Images and animated icons should follow the same [naming convention](../assets/ReadMe.md#asset-naming-rules) as those from the main firmware.
|
||||
|
||||
## Debugging FAPs
|
||||
|
||||
**`fbt`** includes a script for gdb-py to provide debugging support for FAPs, `debug/flipperapps.py`. It is loaded in default debugging configurations by **`fbt`** and stock VS Code configurations.
|
||||
|
||||
With it, you can debug FAPs as if they were a part of the main firmware — inspect variables, set breakpoints, step through the code, etc.
|
||||
|
||||
### Setting up debugging environment
|
||||
|
||||
The debugging support script looks up debugging information in the latest firmware build directory (`build/latest`). That directory is symlinked by `fbt` to the latest firmware configuration (Debug or Release) build directory when you run `./fbt` for the chosen configuration. See [fbt docs](./fbt.md#nb) for details.
|
||||
|
||||
To debug FAPs, do the following:
|
||||
|
||||
1. Build firmware with `./fbt`
|
||||
2. Flash it with `./fbt flash`
|
||||
3. [Build your FAP](#how-to-set-up-an-application-to-be-built-as-a-fap) and run it on Flipper
|
||||
|
||||
After that, you can attach with `./fbt debug` or VS Code and use all debug features.
|
||||
|
||||
It is **important** that firmware and application build type (debug/release) match and that the matching firmware folder is linked as `build/latest`. Otherwise, debugging will not work.
|
||||
|
||||
## How Flipper runs an application from an SD card
|
||||
|
||||
Flipper's MCU cannot run code directly from external storage, so it needs to be copied to RAM first. That is done by the App Loader application responsible for loading the FAP from the SD card, verifying its integrity and compatibility, copying it to RAM, and adjusting it for its new location.
|
||||
|
||||
Since FAP has to be loaded to RAM to be executed, the amount of RAM available for allocations from heap is reduced compared to running the same app from flash, as a part of the firmware. Note that the amount of occupied RAM is less than the total FAP file size since only code and data sections are allocated, while the FAP file includes extra information only used at app load time.
|
||||
|
||||
Applications are built for a specific API version. It is a part of the hardware target's definition and contains a major and minor version number. The App Loader checks if the application's major API version matches the firmware's major API version.
|
||||
|
||||
The App Loader allocates memory for the application and copies it to RAM, processing relocations and providing concrete addresses for imported symbols using the [symbol table](#symbol-table). Then it starts the application.
|
||||
|
||||
## API versioning
|
||||
|
||||
Not all parts of firmware are available for external applications. A subset of available functions and variables is defined in the "api_symbols.csv" file, which is a part of the firmware target definition in the `firmware/targets/` directory.
|
||||
|
||||
**`fbt`** uses semantic versioning for the API. The major version is incremented when there are breaking changes in the API. The minor version is incremented when new features are added.
|
||||
|
||||
Breaking changes include:
|
||||
|
||||
- Removing a function or a global variable
|
||||
- Changing the signature of a function
|
||||
|
||||
API versioning is mostly automated by **`fbt`**. When rebuilding the firmware, **`fbt`** checks if there are any changes in the API exposed by headers gathered from `SDK_HEADERS`. If so, it stops the build, adjusts the API version, and asks the user to go through the changes in the `.csv` file. New entries are marked with a "`?`" mark, and the user is supposed to change the mark to "`+`" for the entry to be exposed for FAPs, or to "`-`" for it to be unavailable.
|
||||
|
||||
**`fbt`** will not allow building a firmware until all "`?`" entries are changed to "`+`" or "`-`".
|
||||
|
||||
**NB:** **`fbt`** automatically manages the API version. The only case where manually incrementing the major API version is allowed (and required) is when existing "`+`" entries are to be changed to "`-`".
|
||||
|
||||
### Symbol table
|
||||
|
||||
The symbol table is a list of symbols exported by firmware and available for external applications. It is generated by **`fbt`** from the API symbols file and is used by the App Loader to resolve addresses of imported symbols. It is build as a part of the `fap_loader` application.
|
||||
|
||||
**`fbt`** also checks if all imported symbols are present in the symbol table. If there are any missing symbols, it will issue a warning listing them. The application won't be able to run on the device until all required symbols are provided in the symbol table.
|
||||
@@ -1,15 +0,0 @@
|
||||
# This is a UPC-A Barcode Generator for the Flipper Zero hardware.
|
||||
|
||||
## Author: [McAzzaMan](https://github.com/McAzzaMan/flipperzero-firmware/tree/UPC-A_Barcode_Generator/applications/barcode_generator)
|
||||
|
||||
<img src=https://i.imgur.com/bMSAiuK.png>
|
||||
|
||||
It will eventually be expanded into other barcode types. It currently only generates UPC-A type barcodes.
|
||||
|
||||
<img src=https://i.imgur.com/bxTdzuA.png>
|
||||
|
||||
<b> -Controls- </b> </br>
|
||||
Hitting the centre button on the Flipper toggles edit mode.
|
||||
When in edit mode, left and right will change the digit to be changed, and up and down will adjust the digit value.
|
||||
|
||||
<img src=https://i.imgur.com/lGbzdwH.png>
|
||||
@@ -1,58 +0,0 @@
|
||||
_### How to use the Bluetooth remote control function of your Flipper :_
|
||||
|
||||
Once your Flipper is turned on, navigate with the "up" and "down" buttons until you reach the "Plugins" menu
|
||||
|
||||
|
||||
|
||||
Enter with the "middle" button and choose the "Bluetooth Remote" function
|
||||
|
||||
|
||||
|
||||
From this menu (**and only this one**), you will find a new bluetooth device named _Control "Flipper Name"_
|
||||
|
||||
Pair your Phone/Tablet/Computer/... to this device and you're good to go for controlling your remote devices ! (I skip the doc on how to pair 2 bluetooth devices...)
|
||||
|
||||
Once paired, the Flipper LED will remain blue/fixed throughout the session in the "Bluetooth Remote" menu. If you leave the menu, the led goes off/the Bluetooth connection disappears: The blue led is a good way to know if you are connected or not.
|
||||
|
||||
You will find in the main menu the different types of remote controls available
|
||||
|
||||
|
||||
|
||||
**Keynote**
|
||||
|
||||
Ultra simplified keyboard only for moving around in a document for example, or for certain presentations (Powerpoint or others...)
|
||||
|
||||
|
||||
|
||||
**Full keyboard**
|
||||
|
||||
You know what it is and how to use it ;)
|
||||
|
||||
|
||||
|
||||
**Media**
|
||||
|
||||
Up : Volume increase
|
||||
Down: Volume decrease
|
||||
Middle : Play/Stop
|
||||
Left : Rewind
|
||||
Right : Forward
|
||||
|
||||
|
||||
|
||||
**Mouse**
|
||||
|
||||
Up : Up
|
||||
Down : Down
|
||||
Left : Left
|
||||
Right : Right
|
||||
Middle : Mouse Left button
|
||||
Back : Mouse Right Button
|
||||
|
||||
|
||||
|
||||
To **exit** each menu, simply **long press the "back" button**, which gives you the option to choose to leave the Bluetooth menu for good, choose another remote or stay on the one you were on.
|
||||
|
||||
|
||||
|
||||
Doc by Foul (2022).
|
||||
@@ -1,35 +0,0 @@
|
||||
# How to change Flipper name:
|
||||
## [Feature & Documentation By Unleashed/xMasterX](https://github.com/DarkFlippers/unleashed-firmware/documentation/CustomFlipperName.md)
|
||||
|
||||
## Instruction
|
||||
1. Read [How to build](https://github.com/ClaraCrazy/Flipper-Xtreme/blob/main/documentation/HowToBuild.md) and [How to install](https://github.com/RogueMaster/flipperzero-firmware/blob/dev/documentation/HowToInstall.md) to know how to build and install firmware
|
||||
2. Follow how to build instructions to prepare all things before continuing
|
||||
3. Run release build to verify all is ok - `./fbt COMPACT=1 DEBUG=0 updater_package`
|
||||
4. Clear build files - `./fbt COMPACT=1 DEBUG=0 updater_package -c`
|
||||
5. Run command with extra environment var before `./fbt` that variable should contain your custom name in alphanumeric characters - max length 8 chars
|
||||
`CUSTOM_FLIPPER_NAME=Name ./fbt COMPACT=1 DEBUG=0 updater_package` - where `Name` write your custom name
|
||||
6. Copy `dist/f7-C/f7-update-local` folder to microSD `update/myfw/` and run `update` file on flipper from file manager app (Archive)
|
||||
7. Flash from microSD card only!!!! .dfu update from qFlipper will not work properly since name and serial number will be changed
|
||||
8. Done, you will have custom name, serial number and bluetooth mac address
|
||||
9. Also you can skip 5-7 and flash with `CUSTOM_FLIPPER_NAME=Name ./fbt COMPACT=1 DEBUG=0 FORCE=1 flash_usb_full`
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
### I'm using Windows and name changing / building firmware doesn't work
|
||||
- Use PowerShell or VSCode terminal(powershell by default)
|
||||
- Clear build files - `.\fbt.cmd COMPACT=1 DEBUG=0 updater_package -c`
|
||||
- Enter this in same terminal `$Env:CUSTOM_FLIPPER_NAME="Name"`
|
||||
- Run release build - `.\fbt.cmd COMPACT=1 DEBUG=0 updater_package`
|
||||
- Flash as described before (see 6.)
|
||||
- If something still not work - Run powershell or VSCode as Admin
|
||||
### Name stays same for every new build
|
||||
- Clear build files - `./fbt COMPACT=1 DEBUG=0 updater_package -c`
|
||||
- Try again
|
||||
### I want to return my original name and serial number
|
||||
- Flash stock FW or any CFW using microSD card offline update method
|
||||
|
||||
Or
|
||||
- Clear build files - `./fbt COMPACT=1 DEBUG=0 updater_package -c`
|
||||
- Run release build - `./fbt COMPACT=1 DEBUG=0 updater_package`
|
||||
- Copy `dist/f7-C/f7-update-local` folder to microSD `update/myfw/` and run `update` file on flipper from file manager app (Archive)
|
||||
- Flash from microSD card only, .dfu update from qFlipper will not work properly since name and serial number will be changed
|
||||
@@ -1,12 +0,0 @@
|
||||
## How to extend SubGHz supported frequency range
|
||||
|
||||
#### CC1101 Frequency range specs: 300-348 MHz, 386-464 MHz, and 778-928 MHz
|
||||
#### This setting will extend to: 281-361 MHz, 378-481 MHz, and 749-962 MHz
|
||||
|
||||
1. Please do not do that unless you know what exactly you are doing
|
||||
2. You don't need extended range for almost all use cases
|
||||
3. Extending frequency range and transmitting on frequencies that outside of hardware specs can damage your hardware!
|
||||
4. Flipper Devices team and/or unleashed/RogueMaster fw developers are not responsible of any damage that can be caused by using CFW or extending frequency ranges!!!
|
||||
|
||||
If you really sure you need that change, find `subghz/assets/extend_range.txt` file on your microSD, read comments on first lines
|
||||
and change `false` to `true`
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,119 +0,0 @@
|
||||
# Key Combos
|
||||
|
||||
There are times when your Flipper feels blue and doesn't respond to any of your commands due to a software issue. This guide will help you solve this problem.
|
||||
|
||||
## Basic combos
|
||||
|
||||
### Hardware reset
|
||||
|
||||
- Press `LEFT` and `BACK` and hold for a couple of seconds
|
||||
- Release `LEFT` and `BACK`
|
||||
|
||||
This combo performs a hardware reset by pulling the MCU reset line down.
|
||||
Main components involved: Keys -> DD8(NC7SZ32M5X, OR-gate) -> DD1(STM32WB55, MCU).
|
||||
|
||||
It won't work only in one case:
|
||||
|
||||
- The MCU debug block is active and holding the reset line from inside.
|
||||
|
||||
### Hardware Power Reset
|
||||
|
||||
- Disconnect the USB cable and any external power supplies
|
||||
- Disconnect the USB once again
|
||||
- Make sure you've disconnected the USB and any external power supplies
|
||||
- Press `BACK` and hold for 30 seconds (this will only work with the USB disconnected)
|
||||
- If you haven't disconnected the USB, then disconnect it and repeat the previous step
|
||||
- Release the `BACK` key
|
||||
|
||||
This combo performs a reset by switching SYS power line off and then on.
|
||||
Main components involved: Keys -> DD6(bq25896, charger).
|
||||
|
||||
It won't work only in one case:
|
||||
|
||||
- Power supply is connected to USB or 5V_ext
|
||||
|
||||
### Software DFU
|
||||
|
||||
- Press `LEFT` on boot to enter DFU with Flipper boot-loader
|
||||
|
||||
It won't work only in one case:
|
||||
|
||||
- Flipper boot-loader is damaged or absent
|
||||
|
||||
### Hardware DFU
|
||||
|
||||
- Press `OK` on boot to enter DFU with ST boot-loader
|
||||
|
||||
It won't work only in one case:
|
||||
|
||||
- Option Bytes are damaged or set to ignore the `OK` key
|
||||
|
||||
## DFU combos
|
||||
|
||||
### Hardware Reset + Software DFU
|
||||
|
||||
- Press `LEFT` and `BACK` and hold for a couple of seconds
|
||||
- Release `BACK`
|
||||
- Device will enter DFU with an indication (Blue LED + DFU Screen)
|
||||
- Release `LEFT`
|
||||
|
||||
This combo performs a hardware reset by pulling the MCU reset line down. Then, the `LEFT` key indicates to the boot-loader that DFU mode is requested.
|
||||
|
||||
It won't work in two cases:
|
||||
|
||||
- The MCU debug block is active and holding the reset line from inside
|
||||
- Flipper boot-loader is damaged or absent
|
||||
|
||||
### Hardware Reset + Hardware DFU
|
||||
|
||||
- Press `LEFT`, `BACK` and `OK` and hold for a couple of seconds
|
||||
- Release `BACK` and `LEFT`
|
||||
- The device will enter DFU without an indication
|
||||
|
||||
This combo performs a hardware reset by pulling the MCU reset line down. Then, the `OK` key forces MCU to load the internal boot-loader.
|
||||
|
||||
It won't work in two cases:
|
||||
|
||||
- The MCU debug block is active and holding the reset line from inside
|
||||
- Option Bytes are damaged or set to ignore the `OK` key
|
||||
|
||||
### Hardware Power Reset + Software DFU
|
||||
|
||||
- Disconnect the USB and any external power supplies
|
||||
- Press `BACK` and `LEFT` for 30 seconds
|
||||
- Release `BACK`
|
||||
- The device will enter DFU with an indication (Blue LED + DFU Screen)
|
||||
- Release `LEFT`
|
||||
- Plug in the USB
|
||||
|
||||
This combo performs a reset by switching the SYS power line off and then on. Next, the `LEFT` key indicates to the boot-loader that DFU mode is requested.
|
||||
|
||||
It won't work in two cases:
|
||||
|
||||
- Power supply is connected to USB or 5V_ext
|
||||
- Flipper boot-loader is damaged or absent
|
||||
|
||||
### Hardware Power Reset + Hardware DFU
|
||||
|
||||
- Disconnect the USB and any external power supplies
|
||||
- Press `BACK` and `OK` and hold for 30 seconds
|
||||
- Release `BACK` and `OK`
|
||||
- The device will enter DFU without indication
|
||||
- Plug in the USB
|
||||
|
||||
This combo performs a reset by switching the SYS power line off and then on. Next, the `OK` key forces MCU to load the internal boot-loader.
|
||||
|
||||
It won't work in two cases:
|
||||
|
||||
- Power supply is connected to USB or 5V_ext
|
||||
- Option Bytes are damaged or set to ignore the `OK` key
|
||||
|
||||
# Alternative ways to recover your device
|
||||
|
||||
If none of the described methods helped you:
|
||||
|
||||
- Make sure the battery charged
|
||||
- Disconnect the battery and connect again (requires disassembly)
|
||||
- Try to flash the device with ST-Link or another programmer that supports SWD
|
||||
|
||||
If you're still here and your device is not working: it's not a software issue.
|
||||
@@ -1,61 +0,0 @@
|
||||
# MultiConverter
|
||||
|
||||
## Author: [theisolinearchip](https://github.com/theisolinearchip/flipperzero_stuff/tree/main/applications/multi_converter)
|
||||
|
||||
An expanded version of my previous __Dec/Hex Converter__, this time allowing more units and a _(probably poorly made from a design-point-of-view)_ selector mode
|
||||
to swap between different unit groups.
|
||||
|
||||
I wrote it with the idea of _expanding the unit list_ on mind, so adding new ones it's a matter of increasing an array of constants + defining the proper conversion functions.
|
||||
|
||||
(Actually the whole project is more about "making the framework" rather than providing _ALL_ of the possible units : D)
|
||||
|
||||
 
|
||||
|
||||
## Current conversions
|
||||
|
||||
- `Decimal / Hexadecimal / Binary`
|
||||
- `Celsius / Fahernheit / Kelvin`
|
||||
- `Kilometers / Meters / Centimeters / Miles / Feet / Inches`
|
||||
- `Degree / Radian`
|
||||
|
||||
## Usage
|
||||
|
||||
Base keyboard allows numbers from `0` to `F`, being disabled (or not) according to the current selected unit.
|
||||
|
||||
Long press on `0` toggles a __negative__ value; long press on `1` sets a __decimal point__ (only if allowed by the current selected unit).
|
||||
|
||||
`<` removes the last character; `#` changes to __Unit Select Mode__.
|
||||
|
||||
### Unit Select Mode
|
||||
|
||||
`Left` and `Right` to swap between __origin unit__ and __destination unit__ (notice the _destination_ will change according to the current selected _origin_).
|
||||
|
||||
`Ok` to save the changes and go back to the __Display Mode__; `Back` to go back without changing any unit.
|
||||
|
||||
## Adding new units
|
||||
|
||||
1. Add the new units in the `MultiConverterUnitType` enum on `multi_converter_definitions.h` (basic definitions header). Notice each enum element will be used as an array index later.
|
||||
|
||||
2. Increase the `MULTI_CONVERTER_AVAILABLE_UNITS` constant on `multi_converter_units.h` (units main header file).
|
||||
|
||||
3. Set a pair of functions for __converting__ units and to __check__ if a target unit is allowed to work with the destination unit (both on `multi_converter_units.h`
|
||||
and `multi_converter_units.c`; follow the already built-in units for more info).
|
||||
|
||||
4. Add the proper `MultiConverterUnit` structs for each new unit.
|
||||
|
||||
5. Add each new struct to the main `multi_converter_available_units` array.
|
||||
|
||||
And that's it! The system will fetch the new units and display it!
|
||||
|
||||
## Known issues, TODO-list, etc.
|
||||
|
||||
This is an initial release, so expect some bugs and issues (also I don't work with C that much, so there're probably lots of things that can be improved and/or changed!).
|
||||
|
||||
- I've noticed some small decimal variations when "going deep" with some units (like converting __miles__ to __centimeters__ and things like that); probably due to the precision-level required. Need to check that.
|
||||
- Pending: improve overflow checks.
|
||||
- The way some long numbers are shown could probably be improved to look fancier.
|
||||
- Both _origin_ and _destination buffers_ are the same. The destination one could probably be longer in order to avoid certain _overflow scenarios_.
|
||||
- The GUI needs improvement too: there's a whole __widget/views system__ built in the Flipper that allows things like setting up keys, showing "Save/Back/Cancel" messages with
|
||||
callbacks and stuff like that. Didn't know anything about them, so I moved on with something more basic (which is probably fine since it's not a "very big project"); but
|
||||
a more "standard" way with the regular GUI stuff provided by the firmware will be interesting...
|
||||
- More GUI stuff: the _long click buttons_ for adding a decimal point / negative number aren't very clear on the view itself (I tried to add a small dot / dash symbol, but I think those are small enough to be a little bit confusing)
|
||||
@@ -1,51 +0,0 @@
|
||||
# flipperzero-nrf24
|
||||
|
||||
## Author: [mothball187](https://github.com/mothball187/flipperzero-nrf24/tree/main/mousejacker)
|
||||
|
||||
An [NRF24](https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf) driver for the [Flipper Zero](https://flipperzero.one/) device. The NRF24 is a popular line of 2.4GHz radio transceivers from Nordic Semiconductors. This library is not currently complete, but functional.
|
||||
|
||||
# How to use
|
||||
- Connect NRF24 to flipper using provided pinouts
|
||||
- Open NRF24: Sniffer, and scan channels, switch between modes/channels using buttons
|
||||
- When you got address -> Open NRF24: Mouse Jacker
|
||||
- Select Address and open badusb file
|
||||
- Done
|
||||
|
||||
# Demo (YouTube)
|
||||
[](https://www.youtube.com/watch?v=C5hbyAjuU4k)
|
||||
|
||||
## Warning
|
||||
These apps are for **educational purposes** only. Please use this code responsibly and only use these apps on your own equipment.
|
||||
|
||||
## Acknowledgments
|
||||
The NRF24 sniffing technique was discovered and shared by Travis Goodspeed in [his blog](http://travisgoodspeed.blogspot.com/2011/02/promiscuity-is-nrf24l01s-duty.html).
|
||||
|
||||
The mousejack vulnerabilities were discovered and reported by Marc Newlin, see [the blog](https://www.bastille.net/research/vulnerabilities/mousejack/technical-details) for technical details.
|
||||
|
||||
Much of the driver code was inspired by [RadioHead's Arduino library](https://www.airspayce.com/mikem/arduino/RadioHead/classRH__NRF24.html).
|
||||
Much of the mousejack code was inspired by the [Jackit project](https://github.com/insecurityofthings/jackit).
|
||||
|
||||
|
||||
# Pinout from from NoComp/Frog
|
||||
<img src="https://media.discordapp.net/attachments/937479784726949900/994495234618687509/unknown.png?width=567&height=634">
|
||||
|
||||
# Mousejacker / NRF24 pinout by UberGuidoZ
|
||||
2/A7 on FZ goes to MOSI/6 on nrf24l01<br>
|
||||
3/A6 on FZ goes to MISO/7 on nrf24l01<br>
|
||||
4/A4 on FZ goes to CSN/4 on nrf24l01<br>
|
||||
5/B3 on FZ goes to SCK/5 on nrf24l01<br>
|
||||
6/B2 on FZ goes to CE/3 on nrf24l01<br>
|
||||
8/GND on FZ goes to GND/1 on nrf24l01<br>
|
||||
9/3V3 on FZ goes to VCC/2 on nrf24l01<br>
|
||||
IRQ/8 is left disconnected on nrf24l01<br>
|
||||
|
||||
|
||||
|
||||
If the nRF module is acting a bit flakey, try adding a capacitor to the vcc/gnd lines!
|
||||
I've not tried the Plus model so it may have a bigger need for a cap.
|
||||
Otherwise, I haven't had any major issues.
|
||||
Anything from a 3.3 uF to 10 uF should do. (Watch your positive/negative placement! Negative to ground.)
|
||||
I learned if you wanna get fancy, include a 0.1 uF cap in parallel.
|
||||
The 3.3 uF to 10 uF will respond to slow freq changes while the 0.1 uF will respond to the high freq switching spikes that the larger one cannot. That said, a single 10 uF will likely suffice for the Mousejack attack. ¯\\\_(ツ)_/¯
|
||||
|
||||
|
||||
@@ -1,146 +0,0 @@
|
||||
# Executing code from RAM
|
||||
|
||||
In Flipper firmware, we have a special boot mode that loads a specially crafted system image into RAM and transfers control to it. System image executing in RAM has full write access to whole Flipper's flash memory — something that's not possible when running main code from same flash.
|
||||
|
||||
We leverage that boot mode to perform OTA firmware updates, including operations on radio stack running on second MCU core.
|
||||
|
||||
|
||||
# How does Flipper OTA work?
|
||||
|
||||
Installation of OTA updates goes through 3 stages:
|
||||
|
||||
## 1. Backing up internal storage (`/int/`)
|
||||
|
||||
It is a special partition of Flipper's flash memory, taking up all available space not used by firmware code. Newer versions of firmware may be of different size, and simply installing them would cause flash repartitioning and data loss.
|
||||
|
||||
So, before taking any action upon the firmware, we back up current configuration from `/int/` into a plain tar archive on SD card.
|
||||
|
||||
|
||||
## 2. Performing device update
|
||||
|
||||
For that, main firmware loads an updater image - a customized build of main Flipper firmware — into RAM and runs it. Updater performs operations on system flash that are described by an Update manifest file.
|
||||
|
||||
First, if there's a Radio stack image bundled with the update, updater compares its version with currently installed one. If they don't match, updater performs stack deinstallation followed by writing and installing a new one. The installation itself is performed by proprietary software, FUS, running on Core2, and leads to a series of system restarts.
|
||||
|
||||
Then updater validates and corrects Option Bytes — a special memory region containing low-level configuration for Flipper's MCU.
|
||||
|
||||
After that, updater loads a `.dfu` file with firmware to be flashed, checks its integrity using CRC32, writes it to system flash and validates written data.
|
||||
|
||||
|
||||
## 3. Restoring internal storage and updating resources
|
||||
|
||||
After performing operations on flash memory, system restarts into newly flashed firmware. Then it performs restoration of previously backed up `/int` contents.
|
||||
|
||||
If update package contains an additional resources archive, it is extracted onto SD card.
|
||||
|
||||
|
||||
# Update manifest
|
||||
|
||||
Update packages come with a manifest that contains a description of its contents. The manifest is in Flipper File Format — a simple text file, comprised of key-value pairs.
|
||||
|
||||
## Mandatory fields
|
||||
|
||||
Update manifest must contain the following keys in given order:
|
||||
|
||||
* __Filetype__: a constant string, "Flipper firmware upgrade configuration";
|
||||
|
||||
* __Version__: manifest version. Current value is 2;
|
||||
|
||||
* __Info__: arbitraty string, describing package contents;
|
||||
|
||||
* __Target__: hardware revision the package is built for;
|
||||
|
||||
* __Loader__: file name of stage 2 loader that is executed from RAM;
|
||||
|
||||
* __Loader CRC__: CRC32 of loader file. Note that it is represented in little-endian hex.
|
||||
|
||||
## Optional fields
|
||||
|
||||
Other fields may have empty values, is such case updater skips all operations related to such values.
|
||||
|
||||
* __Radio__: file name of radio stack image, provided by STM;
|
||||
|
||||
* __Radio address__: address to install the radio stack at. It is specified in Release Notes by STM;
|
||||
|
||||
* __Radio version__: Radio major, minor and sub versions followed by branch, release, and stack type packed into 6 hex-encoded bytes;
|
||||
|
||||
* __Radio CRC__: CRC32 of radio image;
|
||||
|
||||
* __Resources__: file name of TAR acrhive with resources to be extracted on SD card;
|
||||
|
||||
* __OB reference__, __OB mask__, __OB write mask__: reference values for validating and correcting option bytes.
|
||||
|
||||
|
||||
# OTA update error codes
|
||||
|
||||
We designed the OTA update process to be as fail-safe as possible. We don't start any risky operation before validating all related pieces of data to ensure we don't leave the device in partially updated, or bricked, state.
|
||||
|
||||
Even if something goes wrong, Updater gives you an option to retry failed operations, and reports its state with an error code. These error codes have an `[XX-YY]` format, where `XX` encodes an operation that failed, and `YY` contains extra details on its progress where the error occured.
|
||||
|
||||
| Stage description | Code | Progress | Description |
|
||||
|:-----------------------:|-------:|------------|--------------------------------------------|
|
||||
| Loading update manifest | **1** | **13** | Updater reported hardware version mismatch |
|
||||
| | | **20** | Failed to get saved manifest path |
|
||||
| | | **30** | Failed to load manifest |
|
||||
| | | **40** | Unsupported update package version |
|
||||
| | | **50** | Package has mismatching HW target |
|
||||
| | | **60** | Missing DFU file |
|
||||
| | | **80** | Missing radio firmware file |
|
||||
| Backing up LFS | **2** | **0-100** | FS read/write error |
|
||||
| Checking radio FW | **3** | **0-99** | Error reading radio firmware file |
|
||||
| | | **100** | CRC mismatch |
|
||||
| Uninstalling radio FW | **4** | **0** | SHCI Delete command error |
|
||||
| | | **80** | Error awaiting command status |
|
||||
| Writing radio FW | **5** | **0-100** | Block read/write error |
|
||||
| Installing radio FW | **6** | **0** | SHCI Install command error |
|
||||
| | | **80** | Error awaiting command status |
|
||||
| Radio is updating | **7** | **10** | Error waiting for operation completion |
|
||||
| Validating opt. bytes | **8** | **yy** | Option byte code |
|
||||
| Checking DFU file | **9** | **0** | Error opening DFU file |
|
||||
| | | **1-98** | Error reading DFU file |
|
||||
| | | **99-100** | Corrupted DFU file |
|
||||
| Writing flash | **10** | **0-100** | Block read/write error |
|
||||
| Validating flash | **11** | **0-100** | Block read/write error |
|
||||
| Restoring LFS | **12** | **0-100** | FS read/write error |
|
||||
| Updating resources | **13** | **0-100** | SD card read/write error |
|
||||
|
||||
|
||||
# Building update packages
|
||||
|
||||
|
||||
## Full package
|
||||
|
||||
To build full update package, including firmware, radio stack and resources for SD card, run `./fbt COMPACT=1 DEBUG=0 updater_package`
|
||||
|
||||
|
||||
## Minimal package
|
||||
|
||||
To build minimal update package, including only firmware, run `./fbt COMPACT=1 DEBUG=0 updater_minpackage`
|
||||
|
||||
|
||||
## Customizing update bundles
|
||||
|
||||
Default update packages are built with Bluetooth Light stack.
|
||||
You can pick a different stack, if your firmware version supports it, and build a bundle with it passing stack type and binary name to `fbt`:
|
||||
|
||||
`./fbt updater_package COMPACT=1 DEBUG=0 COPRO_OB_DATA=scripts/ob_custradio.data COPRO_STACK_BIN=stm32wb5x_BLE_Stack_full_fw.bin COPRO_STACK_TYPE=ble_full`
|
||||
|
||||
Note that `COPRO_OB_DATA` must point to a valid file in `scripts` folder containing reference Option Byte data matching to your radio stack type.
|
||||
|
||||
In certain cases, you might have to confirm your intentions by adding `COPRO_DISCLAIMER=...` to the build command line.
|
||||
|
||||
|
||||
## Building partial update packages
|
||||
|
||||
You can customize package contents by calling `scripts/update.py` directly.
|
||||
For example, to build a package only for installing BLE FULL stack:
|
||||
|
||||
```shell
|
||||
scripts/update.py generate \
|
||||
-t f7 -d r13.3_full -v "BLE FULL 13.3" \
|
||||
--stage dist/f7/flipper-z-f7-updater-*.bin \
|
||||
--radio lib/STM32CubeWB/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/stm32wb5x_BLE_Stack_full_fw.bin \
|
||||
--radiotype ble_full
|
||||
```
|
||||
|
||||
For full list of options, check `scripts/update.py generate` help.
|
||||
@@ -1,46 +0,0 @@
|
||||
# RoadMap
|
||||
|
||||
# Where we are now (0.x.x branch)
|
||||
|
||||
Our goal for the 0.x.x branch is to build an API and apps that are stable and usable. The first public release in this branch is 0.43.1.
|
||||
|
||||
## What's already implemented
|
||||
|
||||
**System and HAL**
|
||||
|
||||
- Furi Core
|
||||
- Furi HAL
|
||||
- Loading applications from SD
|
||||
|
||||
**Applications**
|
||||
|
||||
- SubGhz: all most common protocols, reading RAW for everything else
|
||||
- 125kHz RFID: all most common protocols
|
||||
- NFC: reading/emulating MIFARE Ultralight, reading MIFARE Classic and DESFire, basic EMV, and basic NFC-B/F/V
|
||||
- Infrared: all most common RC protocols, RAW format for everything else
|
||||
- GPIO: UART bridge, basic GPIO controls
|
||||
- iButton: DS1990, Cyfral, Metakom
|
||||
- Bad USB: full USB Rubber Ducky support, some extras for Windows Alt codes
|
||||
- U2F: full U2F specification support
|
||||
|
||||
**External applications**
|
||||
|
||||
- Bluetooth
|
||||
- Snake game
|
||||
|
||||
# Where we're going (Version 1)
|
||||
|
||||
The main goal for 1.0.0 is to provide the first stable version for both Users and Developers.
|
||||
|
||||
## What we're planning to implement in 1.0.0
|
||||
|
||||
- More protocols (gathering feedback)
|
||||
- User documentation (work in progress)
|
||||
- FuriHal: deep sleep mode, stable API, examples, documentation (work in progress)
|
||||
- Application improvements (a ton of things that we want to add and improve that are too numerous to list here)
|
||||
|
||||
## When will it happen, and where can I see the progress?
|
||||
|
||||
Release 1.0.0 will likely happen around the end of 2023Q1.
|
||||
|
||||
You can track the development progress in our public Miro board: https://miro.com/app/board/uXjVO_3D6xU=/?moveToWidget=3458764522498020058&cot=14
|
||||
@@ -1,17 +0,0 @@
|
||||
# Sentry Safe plugin
|
||||
|
||||
## Author: [H4ckd4ddy](https://github.com/H4ckd4ddy/flipperzero-sentry-safe-plugin)
|
||||
|
||||
Flipper zero exploiting vulnerability to open any Sentry Safe and Master Lock electronic safe without any pin code.
|
||||
|
||||
[Demo and Vulnerability described here](https://github.com/H4ckd4ddy/bypass-sentry-safe)
|
||||
|
||||
### Usage
|
||||
|
||||
- Start "Sentry Safe" plugin
|
||||
- Place wires as described on the plugin screen
|
||||
<br>(Flipper GPIO) 8/GND -> Black wire (Safe)
|
||||
<br>(Flipper GPIO) 15/C1 -> Green wire (Safe)
|
||||
|
||||
- Press enter
|
||||
- Open safe
|
||||
@@ -1,66 +0,0 @@
|
||||
# UniRF Remix / Sub-GHz Remote
|
||||
|
||||
### The UniRF Tool *requires* the creation of custom user map with `.txt` extension in the `unirf` folder on the sdcard.
|
||||
|
||||
#### If these files are not exist or not configured properly, **you will receive an error each time you try to select wrong file in the UniRF Tool**.
|
||||
|
||||
## You can add as many `.txt` map files as you want, file name doesn't matter!
|
||||
|
||||
## Incorrect or unconfigured file error
|
||||
|
||||
If the `.txt` file has not been properly configured, the following error will be thrown when trying to run the UniRF Remix app:
|
||||
|
||||
```
|
||||
Config is incorrect.
|
||||
|
||||
Please configure map
|
||||
|
||||
Press Back to Exit
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Setting up the `unirf/example.txt` file:
|
||||
|
||||
```
|
||||
UP: /ext/subghz/Up.sub
|
||||
DOWN: /ext/subghz/Down.sub
|
||||
LEFT: /ext/subghz/Left.sub
|
||||
RIGHT: /ext/subghz/Right.sub
|
||||
OK: /ext/subghz/Ok.sub
|
||||
ULABEL: Up Label
|
||||
DLABEL: Down Label
|
||||
LLABEL: Left Label
|
||||
RLABEL: Right Label
|
||||
OKLABEL: Ok Label
|
||||
```
|
||||
|
||||
The UP/DOWN/LEFT/RIGHT/OK file locations must be set to the specific file you want mapped to that directional pad direction.
|
||||
|
||||
The ULABEL/DLABEL/LLABEL/RLABEL/OKLABEL variables should be set to the text to be displayed for each of the files set earlier.
|
||||
|
||||
## Example:
|
||||
|
||||
```
|
||||
UP: /ext/subghz/Fan1.sub
|
||||
DOWN: /ext/subghz/Fan2.sub
|
||||
LEFT: /ext/subghz/Door.sub
|
||||
RIGHT: /ext/subghz/Garage3.sub
|
||||
OK: /ext/subghz/Garage3l.sub
|
||||
ULABEL: Fan ON
|
||||
DLABEL: Fan OFF
|
||||
LLABEL: Doorbell
|
||||
RLABEL: Garage OPEN
|
||||
OKLABEL: Garage CLOSE
|
||||
```
|
||||
|
||||
## Notes
|
||||
* ##### App Usage
|
||||
- Press a button to send the assigned capture file.
|
||||
- Press Back button to exit app.
|
||||
|
||||
* ##### Universal RF Map
|
||||
- File path should not have any spaces or special characters (- and _ excluded).
|
||||
- Labels are limited to 16 characters.
|
||||
- Why? This is to prevent overlapping elements on screen.
|
||||
- For example: If you set your label or file to ```WWWWWWWWWWWWWWW``` you'll be over the screen limits.
|
||||
@@ -1,63 +0,0 @@
|
||||
## How to add new SubGHz frequencies
|
||||
|
||||
#### CC1101 Frequency range specs: 300-348 MHz, 386-464 MHz, and 778-928 MHz
|
||||
|
||||
Edit user settings file located on your microSD card - `subghz/assets/setting_user.txt`
|
||||
|
||||
in this file you will find we already have extra frequencies added
|
||||
if you need your custom one, make sure it doesn't listed here
|
||||
|
||||
### Default frequency list
|
||||
```
|
||||
/* 300 - 348 */
|
||||
300000000,
|
||||
303875000,
|
||||
304250000,
|
||||
310000000,
|
||||
315000000,
|
||||
318000000,
|
||||
|
||||
/* 387 - 464 */
|
||||
390000000,
|
||||
418000000,
|
||||
433075000, /* LPD433 first */
|
||||
433420000,
|
||||
433920000 /* LPD433 mid */
|
||||
434420000,
|
||||
434775000, /* LPD433 last channels */
|
||||
438900000,
|
||||
|
||||
/* 779 - 928 */
|
||||
868350000,
|
||||
915000000,
|
||||
925000000,
|
||||
```
|
||||
|
||||
### User frequencies added AFTER that default list! You need to continue until you reach the end of that list
|
||||
|
||||
### If you want to disable default list and use ONLY user added frequecies from user settings file
|
||||
Change that line
|
||||
`#Add_standard_frequencies: true`
|
||||
to
|
||||
`Add_standard_frequencies: false`
|
||||
|
||||
### To add your own frequency to user list
|
||||
Just add new line
|
||||
`Frequency: 928000000` - where `928000000` is your frequency, keep it in that format! it should be 9 digits!
|
||||
|
||||
### Hopper frequency list
|
||||
To add new frequecy to hopper:
|
||||
add new line `Hopper_frequency: 345000000`<br>
|
||||
But remember! You should keep it as small as possible, or hopper functionality would be useless!<br>
|
||||
If `#Add_standard_frequencies: true` is not changed<br>
|
||||
Your frequencies will be added after default ones
|
||||
|
||||
### Default hopper list
|
||||
```
|
||||
310000000,
|
||||
315000000,
|
||||
318000000,
|
||||
390000000,
|
||||
433920000,
|
||||
868350000,
|
||||
```
|
||||
@@ -1,65 +0,0 @@
|
||||
# Unit tests
|
||||
|
||||
## Intro
|
||||
|
||||
Unit tests are special pieces of code that apply known inputs to the feature code and check the results to see if they are correct.
|
||||
They are crucial for writing robust, bug-free code.
|
||||
|
||||
Flipper Zero firmware includes a separate application called [unit_tests](/applications/debug/unit_tests).
|
||||
It is run directly on Flipper devices in order to employ their hardware features and rule out any platform-related differences.
|
||||
|
||||
When contributing code to the Flipper Zero firmware, it is highly desirable to supply unit tests along with the proposed features.
|
||||
Running existing unit tests is useful to ensure that the new code doesn't introduce any regressions.
|
||||
|
||||
## Running unit tests
|
||||
|
||||
To run the unit tests, follow these steps:
|
||||
|
||||
1. Compile the firmware with the tests enabled: `./fbt FIRMWARE_APP_SET=unit_tests`.
|
||||
2. Flash the firmware using your preferred method.
|
||||
3. Copy the [assets/unit_tests](assets/unit_tests) folder to the root of your Flipper Zero's SD card.
|
||||
4. Launch the CLI session and run the `unit_tests` command.
|
||||
|
||||
**NOTE:** To run a particular test (and skip all others), specify its name as the command argument.
|
||||
See [test_index.c](applications/debug/unit_tests/test_index.c) for the complete list of test names.
|
||||
|
||||
## Adding unit tests
|
||||
|
||||
### General
|
||||
|
||||
#### Entry point
|
||||
|
||||
The common entry point for all tests is the [unit_tests](applications/debug/unit_tests) application. Test-specific code is placed into an arbitrarily named subdirectory and is then called from the [test_index.c](applications/debug/unit_tests/test_index.c) source file.
|
||||
|
||||
#### Test assets
|
||||
|
||||
Some unit tests require external data in order to function. These files (commonly called assets) reside in the [assets/unit_tests](/assets/unit_tests) directory in their respective subdirectories. Asset files can be of any type (plain text, FlipperFormat (FFF), binary, etc.).
|
||||
|
||||
### Application-specific
|
||||
|
||||
#### Infrared
|
||||
|
||||
Each infrared protocol has a corresponding set of unit tests, so it makes sense to implement one when adding support for a new protocol.
|
||||
To add unit tests for your protocol, follow these steps:
|
||||
|
||||
1. Create a file named `test_<your_protocol_name>.irtest` in the [assets](assets/unit_tests/infrared) directory.
|
||||
2. Fill it with the test data (more on it below).
|
||||
3. Add the test code to [infrared_test.c](applications/debug/unit_tests/infrared/infrared_test.c).
|
||||
4. Update the [assets](assets/unit_tests/infrared) on your Flipper Zero and run the tests to see if they pass.
|
||||
|
||||
##### Test data format
|
||||
|
||||
Each unit test has three sections:
|
||||
|
||||
1. `decoder` - takes in a raw signal and outputs decoded messages.
|
||||
2. `encoder` - takes in decoded messages and outputs a raw signal.
|
||||
3. `encoder_decoder` - takes in decoded messages, turns them into a raw signal, and then decodes again.
|
||||
|
||||
Infrared test asset files have an `.irtest` extension and are regular `.ir` files with a few additions.
|
||||
Decoder input data has signal names `decoder_input_N`, where N is a test sequence number. Expected data goes under the name `decoder_expected_N`. When testing the encoder, these two are switched.
|
||||
|
||||
Decoded data is represented in arrays (since a single raw signal may be decoded into several messages). If there is only one signal, then it has to be an array of size 1. Use the existing files as syntax examples.
|
||||
|
||||
##### Getting raw signals
|
||||
|
||||
Recording raw IR signals are possible using the Flipper Zero. Launch the CLI session, run `ir rx raw`, then point the remote towards Flipper's receiver and send the signals. The raw signal data will be printed to the console in a convenient format.
|
||||
@@ -1,69 +0,0 @@
|
||||
# Universal Remotes
|
||||
|
||||
## Televisions
|
||||
|
||||
Adding your TV set to the universal remote is quite straightforward. Up to 6 signals can be recorded: `Power`, `Mute`, `Vol_up`, `Vol_dn`, `Ch_next`, and `Ch_prev`. Any of them can be omitted if not supported by your TV.
|
||||
|
||||
Each signal is recorded using the following algorithm:
|
||||
|
||||
1. Get the remote and point it to Flipper's IR receiver.
|
||||
2. Start learning a new remote if it's the first button or press `+` to add a new button otherwise.
|
||||
3. Press a remote button and save it under a corresponding name.
|
||||
4. Repeat steps 2-3 until all required signals are saved.
|
||||
|
||||
The signal names are self-explanatory. Remember to make sure that every recorded signal does what it's supposed to.
|
||||
|
||||
If everything checks out, append these signals **to the end** of the [TV universal remote file](/assets/resources/infrared/assets/tv.ir).
|
||||
|
||||
## Audio players
|
||||
|
||||
Adding your audio player to the universal remote is done in the same manner as described above. Up to 8 signals can be recorded: `Power`, `Play`, `Pause`, `Vol_up`, `Vol_dn`, `Next`, `Prev`, and `Mute`. Any of them can be omitted if not supported by the player.
|
||||
|
||||
The signal names are self-explanatory.
|
||||
On many remotes, the `Play` button doubles as `Pause`. In this case, record it as `Play` omitting the `Pause`.
|
||||
Make sure that every signal does what it's supposed to.
|
||||
|
||||
If everything checks out, append these signals **to the end** of the [audio player universal remote file](/assets/resources/infrared/assets/audio.ir).
|
||||
|
||||
## Air conditioners
|
||||
|
||||
Air conditioners differ from most other infrared-controlled devices because their state is tracked by the remote.
|
||||
The majority of A/C remotes have a small display that shows the current mode, temperature, and other settings.
|
||||
When the user presses a button, a whole set of parameters is transmitted to the device, which must be recorded and used as a whole.
|
||||
|
||||
In order to add a particular air conditioner to the universal remote, 6 signals must be recorded: `Off`, `Dh`, `Cool_hi`, `Cool_lo`, `Heat_hi`, and `Heat_lo`.
|
||||
Each signal (except `Off`) is recorded using the following algorithm:
|
||||
|
||||
1. Get the remote and press the **Power Button** so that the display shows that A/C is ON.
|
||||
2. Set the A/C to the corresponding mode (see table below), leaving other parameters such as fan speed or vane on **AUTO** (if applicable).
|
||||
3. Press the **POWER** button to switch the A/C off.
|
||||
4. Start learning a new remote on Flipper if it's the first button or press `+` to add a new button otherwise.
|
||||
5. Point the remote to Flipper's IR receiver as directed and press **POWER** button once again.
|
||||
6. Save the resulting signal under the specified name.
|
||||
7. Repeat steps 2-6 for each signal from the table below.
|
||||
|
||||
| Signal | Mode | Temperature | Note |
|
||||
| :-----: | :--------: | :---------: | ----------------------------------- |
|
||||
| Dh | Dehumidify | N/A | |
|
||||
| Cool_hi | Cooling | See note | Lowest temperature in cooling mode |
|
||||
| Cool_lo | Cooling | 23°C | |
|
||||
| Heat_hi | Heating | See note | Highest temperature in heating mode |
|
||||
| Heat_lo | Heating | 23°C | |
|
||||
|
||||
Finally, record the `Off` signal:
|
||||
|
||||
1. Make sure the display shows that the A/C is ON.
|
||||
2. Start learning a new signal on Flipper and point the remote towards the IR receiver.
|
||||
3. Press the **POWER** button so that the remote shows the OFF state.
|
||||
4. Save the resulting signal under the name `Off`.
|
||||
|
||||
The resulting remote file should now contain 6 signals. You can omit any of them, but you then won't be able to use their functionality.
|
||||
Test the file against the actual device. Make sure that every signal does what it's supposed to.
|
||||
|
||||
If everything checks out, append these signals **to the end** of the [A/C universal remote file](/assets/resources/infrared/assets/ac.ir).
|
||||
|
||||
## Final steps
|
||||
|
||||
The order of signals is not important, but they should be preceded by the following comment: `# Model: <Your model name>` in order to keep the library organized.
|
||||
|
||||
When done, open a pull request containing the changed file.
|
||||
@@ -1,98 +0,0 @@
|
||||
## What is this?
|
||||
|
||||
This document lists all the included special apps that ship with Xtreme. It gives you an idea of what to expect VS other firmware options
|
||||
|
||||
## Thank you to the authors!
|
||||
|
||||
The Flipper and its community wouldn't be as rich as it is without your contributions and support. Thank you for all you have done.
|
||||
|
||||
## GPIO
|
||||
- [Lightmeter](https://github.com/oleksiikutuzov/flipperzero-lightmeter)
|
||||
- [Air Mouse](https://github.com/ginkage/FlippAirMouse/)
|
||||
- [Wifi Marauder](https://github.com/0xchocolate/flipperzero-firmware-with-wifi-marauder-companion)
|
||||
- [Wifi Deauther](https://github.com/Timmotools/flipperzero_esp8266_deautherv2)
|
||||
- [IFTTT Virtual Button for ESP8266 (By Ferrazzi)](https://github.com/Ferrazzi/FlipperZero_IFTTT_Virtual_Button)
|
||||
- [Flashlight (By xMasterX)](https://github.com/xMasterX/flipper-flashlight)
|
||||
- [GPIO Reader 1](https://github.com/biotinker/flipperzero-gpioreader)
|
||||
- [GPIO Reader 2](https://github.com/aureli1c/flipperzero_GPIO_read)
|
||||
- [Sentry Safe](https://github.com/H4ckd4ddy/flipperzero-sentry-safe-plugin)
|
||||
- [Distance Sensor](https://github.com/Sanqui/flipperzero-firmware/tree/59656ca5fb644e0d4484259986b86a0b963f323d/applications/hc_sr04)
|
||||
- [Temperature Sensor](https://github.com/Mywk/FlipperTemperatureSensor)
|
||||
- [i2c Tools](https://github.com/NaejEL/flipperzero-i2ctools)
|
||||
- [GPS](https://github.com/ezod/flipperzero-gps)
|
||||
- [Mouse Jacker](https://github.com/mothball187/flipperzero-nrf24/tree/main/mousejacker)
|
||||
- [Sniffer](https://github.com/mothball187/flipperzero-nrf24/tree/main/nrfsniff)
|
||||
- [Scanner](https://github.com/vad7/nrf24scan)
|
||||
- [ColecoVision Controller](https://github.com/ezod/flipperzero-rc2014-coleco)
|
||||
|
||||
|
||||
## Games
|
||||
- [2048](https://github.com/eugene-kirzhanov/flipper-zero-2048-game)
|
||||
- [Arkanoid](https://github.com/DarkFlippers/unleashed-firmware/tree/dev/applications/plugins/arkanoid)
|
||||
- [BlackJack](https://github.com/teeebor/flipper_games)
|
||||
- [Doom](https://github.com/p4nic4ttack/doom-flipper-zero/)
|
||||
- Multi Dice - In-house
|
||||
- [Flappy Bird](https://github.com/DroomOne/flipperzero-firmware/tree/dev/applications/flappy_bird)
|
||||
- [Game 15](https://github.com/x27/flipperzero-game15)
|
||||
- [Game of Life (Updated to work by tgxn) (By itsyourbedtime)](https://github.com/tgxn/flipperzero-firmware/blob/dev/applications/game_of_life/game_of_life.c)
|
||||
- Heap defense - Author Unknown
|
||||
- [Mandelbrot Set (By Possibly-Matt)](https://github.com/Possibly-Matt/flipperzero-firmware-wPlugins)
|
||||
- [Minesweeper](https://github.com/panki27/minesweeper)
|
||||
- [Snake](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/plugins/snake_game)
|
||||
- [Solitaire](https://github.com/teeebor/flipper_games)
|
||||
- [Tetris](https://github.com/jeffplang/flipperzero-firmware/tree/tetris_game/applications/tetris_game)
|
||||
- [Tic Tac Toe](https://github.com/gotnull/flipperzero-firmware-wPlugins/tree/420/applications/plugins/tictactoe_game)
|
||||
- [Tamagotchi(By GMMan)](https://github.com/GMMan/flipperzero-tamagotch-p1)
|
||||
- [Video Poker (By PixlEmly)](https://github.com/PixlEmly/flipperzero-firmware-testing/blob/420/applications/VideoPoker/poker.c)
|
||||
- [Yatzee (By emfleak)](https://github.com/emfleak/flipperzero-yatzee)
|
||||
|
||||
|
||||
## Misc
|
||||
- [Authenticator (TOTP / HOTP)](https://github.com/akopachov/flipper-zero_authenticator)
|
||||
- [Barcode Generator](https://github.com/McAzzaMan/flipperzero-firmware/tree/UPC-A_Barcode_Generator/applications/barcode_generator)
|
||||
- [Caesar Cipher](https://github.com/panki27/caesar-cipher)
|
||||
- Calculator - In house / notIntense
|
||||
- [Counter](https://github.com/Krulknul/dolphin-counter)
|
||||
- [Hex Viewer](https://github.com/QtRoS/flipper-zero-hex-viewer)
|
||||
- [Mouse Jiggler](https://github.com/Jacob-Tate/flipperzero-firmware/blob/dev/applications/mouse_jiggler/mouse_jiggler.c)
|
||||
- [Converter](https://github.com/theisolinearchip/flipperzero_stuff/tree/main/applications/multi_converter)
|
||||
- [Vibrator](https://github.com/qqmajikpp/flipperzero-firmware-wPlugins/tree/420/applications/plugins/orgasmotron)
|
||||
- [Paint](https://github.com/n-o-T-I-n-s-a-n-e)
|
||||
- [UART Echo](https://github.com/flipperdevices/flipperzero-firmware/pull/831)
|
||||
- [USB HID Autofire](https://github.com/pbek/usb_hid_autofire)
|
||||
- [USB Keyboard & Mouse](https://github.com/huuck/FlipperZeroUSBKeyboard) / (https://github.com/DarkFlippers/unleashed-firmware)
|
||||
- [Wii EC Analyzer](https://github.com/csBlueChip/FlipperZero_WiiEC)
|
||||
|
||||
|
||||
## Music
|
||||
- [BPM Tapper (By panki27)](https://github.com/panki27/bpm-tapper)
|
||||
- [Metronome](https://github.com/panki27/Metronome)
|
||||
- [Morse Code](https://github.com/DarkFlippers/unleashed-firmware/pull/144)
|
||||
- Music Beeper - Author Unknown
|
||||
- [Music Player](https://github.com/flipperdevices/flipperzero-firmware/pull/1189)
|
||||
- [Ocarina](https://github.com/invalidna-me/flipperzero-ocarina)
|
||||
- [Software Automatic Mouth aka SAM](https://github.com/ctoth/SAM)
|
||||
- [Tuning Fork](https://github.com/besya/flipperzero-tuning-fork)
|
||||
- [Music Tracker](https://github.com/DrZlo13/flipper-zero-music-tracker)
|
||||
|
||||
|
||||
## Tools
|
||||
- [Bluetooth Remote](https://github.com/flipperdevices/flipperzero-firmware/pull/1330)
|
||||
- [Clock](https://github.com/kowalski7cc/flipperzero-firmware/tree/clock-v1) / In house
|
||||
- [Countdown Timer](https://github.com/0w0mewo/fpz_cntdown_timer)
|
||||
- [DAP Link](https://github.com/flipperdevices/flipperzero-firmware/pull/1897)
|
||||
- [DTMF](https://github.com/litui/dtmf_dolphin)
|
||||
- [Dolphin Backup & Restore](https://github.com/flipperdevices/flipperzero-firmware/pull/1384)
|
||||
- [iButton Fuzzer](https://github.com/DarkFlippers/unleashed-firmware)
|
||||
- [NFC Magic](https://github.com/flipperdevices/flipperzero-firmware/pull/1966)
|
||||
- [POCSAG Pager](https://github.com/xMasterX/flipper-pager)
|
||||
- [Password Generator](https://github.com/anakod/flipper_passgen)
|
||||
- [PicoPass](https://github.com/flipperdevices/flipperzero-firmware/pull/1366)
|
||||
- [RFID Fuzzer](https://github.com/RogueMaster/flipperzero-firmware-wPlugins/pull/245)
|
||||
- [Spectrum Analyzer](https://github.com/jolcese/flipperzero-firmware/tree/spectrum/applications/spectrum_analyzer)
|
||||
- [Sub-Ghz Bruteforce](https://github.com/derskythe/flipperzero-subbrute/tree/master)
|
||||
- [Sub-Ghz Playlist](https://github.com/darmiel/flipper-playlist)
|
||||
- [Protocol Visualizer](https://github.com/antirez/protoview)
|
||||
|
||||
|
||||
---
|
||||
@@ -1,103 +0,0 @@
|
||||
# Flipper Build Tool
|
||||
|
||||
FBT is the entry point for firmware-related commands and utilities.
|
||||
It is invoked by `./fbt` in the firmware project root directory. Internally, it is a wrapper around [scons](https://scons.org/) build system.
|
||||
|
||||
## Requirements
|
||||
|
||||
Install Python packages required by assets build scripts: `pip3 install -r scripts/requirements.txt`
|
||||
|
||||
## NB
|
||||
|
||||
- `fbt` constructs all referenced environments and their targets' dependency trees on startup. So, to keep startup time as low as possible, we're hiding the construction of certain targets behind command-line options.
|
||||
- `fbt` always performs `git submodule update --init` on start, unless you set `FBT_NO_SYNC=1` in the environment:
|
||||
- On Windows, it's `set "FBT_NO_SYNC=1"` in the shell you're running `fbt` from
|
||||
- On \*nix, it's `$ FBT_NO_SYNC=1 ./fbt ...`
|
||||
- `fbt` builds updater & firmware in separate subdirectories in `build`, and their names depend on optimization settings (`COMPACT` & `DEBUG` options). However, for ease of integration with IDEs, the latest built variant's directory is always linked as `built/latest`. Additionally, `compile_commands.json` is generated in that folder (used for code completion support in IDE).
|
||||
|
||||
## Invoking FBT
|
||||
|
||||
To build with FBT, call it and specify configuration options & targets to build. For example:
|
||||
|
||||
`./fbt COMPACT=1 DEBUG=0 VERBOSE=1 updater_package copro_dist`
|
||||
|
||||
To run cleanup (think of `make clean`) for specified targets, add the `-c` option.
|
||||
|
||||
## VSCode integration
|
||||
|
||||
`fbt` includes basic development environment configuration for VS Code. Run `./fbt vscode_dist` to deploy it. That will copy the initial environment configuration to the `.vscode` folder. After that, you can use that configuration by starting VS Code and choosing the firmware root folder in the "File > Open Folder" menu.
|
||||
|
||||
- On the first start, you'll be prompted to install recommended plugins. We highly recommend installing them for the best development experience. _You can find a list of them in `.vscode/extensions.json`._
|
||||
- Basic build tasks are invoked in the Ctrl+Shift+B menu.
|
||||
- Debugging requires a supported probe. That includes:
|
||||
- Wi-Fi devboard with stock firmware (blackmagic).
|
||||
- ST-Link and compatible devices.
|
||||
- J-Link for flashing and debugging (in VSCode only). _Note that J-Link tools are not included with our toolchain and you have to [download](https://www.segger.com/downloads/jlink/) them yourself and put them on your system's PATH._
|
||||
- Without a supported probe, you can install firmware on Flipper using the USB installation method.
|
||||
|
||||
## FBT targets
|
||||
|
||||
FBT keeps track of internal dependencies, so you only need to build the highest-level target you need, and FBT will make sure everything they depend on is up-to-date.
|
||||
|
||||
### High-level (what you most likely need)
|
||||
|
||||
- `fw_dist` - build & publish firmware to the `dist` folder. This is a default target when no others are specified.
|
||||
- `fap_dist` - build external plugins & publish to the `dist` folder.
|
||||
- `updater_package`, `updater_minpackage` - build a self-update package. The minimal version only includes the firmware's DFU file; the full version also includes a radio stack & resources for the SD card.
|
||||
- `copro_dist` - bundle Core2 FUS+stack binaries for qFlipper.
|
||||
- `flash` - flash the attached device with OpenOCD over ST-Link.
|
||||
- `flash_usb`, `flash_usb_full` - build, upload and install the update package to the device over USB. See details on `updater_package` and `updater_minpackage`.
|
||||
- `debug` - build and flash firmware, then attach with gdb with firmware's .elf loaded.
|
||||
- `debug_other`, `debug_other_blackmagic` - attach GDB without loading any `.elf`. It will allow you to manually add external `.elf` files with `add-symbol-file` in GDB.
|
||||
- `updater_debug` - attach GDB with the updater's `.elf` loaded.
|
||||
- `blackmagic` - debug firmware with Blackmagic probe (WiFi dev board).
|
||||
- `openocd` - just start OpenOCD.
|
||||
- `get_blackmagic` - output the blackmagic address in the GDB remote format. Useful for IDE integration.
|
||||
- `get_stlink` - output serial numbers for attached STLink probes. Used for specifying an adapter with `OPENOCD_ADAPTER_SERIAL=...`.
|
||||
- `lint`, `format` - run clang-format on the C source code to check and reformat it according to the `.clang-format` specs.
|
||||
- `lint_py`, `format_py` - run [black](https://black.readthedocs.io/en/stable/index.html) on the Python source code, build system files & application manifests.
|
||||
- `cli` - start a Flipper CLI session over USB.
|
||||
|
||||
### Firmware targets
|
||||
|
||||
- `faps` - build all external & plugin apps as [`.faps`](./AppsOnSDCard.md#fap-flipper-application-package).
|
||||
- **`fbt`** also defines per-app targets. For example, for an app with `appid=snake_game` target names are:
|
||||
- `fap_snake_game`, etc. - build single app as `.fap` by its application ID.
|
||||
- Check out [`--extra-ext-apps`](#command-line-parameters) for force adding extra apps to external build.
|
||||
- `fap_snake_game_list`, etc - generate source + assembler listing for app's `.fap`.
|
||||
- `flash`, `firmware_flash` - flash the current version to the attached device with OpenOCD over ST-Link.
|
||||
- `jflash` - flash the current version to the attached device with JFlash using a J-Link probe. The JFlash executable must be on your `$PATH`.
|
||||
- `flash_blackmagic` - flash the current version to the attached device with a Blackmagic probe.
|
||||
- `firmware_all`, `updater_all` - build a basic set of binaries.
|
||||
- `firmware_list`, `updater_list` - generate source + assembler listing.
|
||||
- `firmware_cdb`, `updater_cdb` - generate a `compilation_database.json` file for external tools and IDEs. It can be created without actually building the firmware.
|
||||
|
||||
### Assets
|
||||
|
||||
- `resources` - build resources and their manifest files
|
||||
- `dolphin_ext` - process dolphin animations for the SD card
|
||||
- `icons` - generate `.c+.h` for icons from PNG assets
|
||||
- `proto` - generate `.pb.c+.pb.h` for `.proto` sources
|
||||
- `proto_ver` - generate `.h` with a protobuf version
|
||||
- `dolphin_internal`, `dolphin_blocking` - generate `.c+.h` for corresponding dolphin assets
|
||||
|
||||
## Command-line parameters
|
||||
|
||||
- `--options optionfile.py` (default value `fbt_options.py`) - load a file with multiple configuration values
|
||||
- `--extra-int-apps=app1,app2,appN` - force listed apps to be built as internal with the `firmware` target
|
||||
- `--extra-ext-apps=app1,app2,appN` - force listed apps to be built as external with the `firmware_extapps` target
|
||||
- `--proxy-env=VAR1,VAR2` - additional environment variables to expose to subprocesses spawned by `fbt`. By default, `fbt` sanitizes the execution environment and doesn't forward all inherited environment variables. You can find the list of variables that are always forwarded in the `environ.scons` file.
|
||||
|
||||
## Configuration
|
||||
|
||||
Default configuration variables are set in the configuration file: `fbt_options.py`.
|
||||
Values set in the command line have higher precedence over the configuration file.
|
||||
|
||||
You can find out available options with `./fbt -h`.
|
||||
|
||||
### Firmware application set
|
||||
|
||||
You can create customized firmware builds by modifying the list of applications to be included in the build. Application presets are configured with the `FIRMWARE_APPS` option, which is a `map(configuration_name:str -> application_list:tuple(str))`. To specify an application set to use in the build, set `FIRMWARE_APP_SET` to its name.
|
||||
For example, to build a firmware image with unit tests, run `./fbt FIRMWARE_APP_SET=unit_tests`.
|
||||
|
||||
Check out `fbt_options.py` for details.
|
||||
@@ -1,110 +0,0 @@
|
||||
# Command syntax
|
||||
|
||||
BadUsb app uses extended Duckyscript syntax. It is compatible with classic USB Rubber Ducky 1.0 scripts but provides some additional commands and features, such as custom USB ID, ALT+Numpad input method, SYSRQ command, and more functional keys.
|
||||
|
||||
# Script file format
|
||||
|
||||
BadUsb app can execute only text scrips from `.txt` files, no compilation is required. Both `\n` and `\r\n` line endings are supported. Empty lines are allowed. You can use spaces or tabs for line indentation.
|
||||
|
||||
# Command set
|
||||
|
||||
## Comment line
|
||||
|
||||
Just a single comment line. The interpreter will ignore all text after the REM command.
|
||||
|Command|Parameters|Notes|
|
||||
|-|-|-|
|
||||
|REM|Comment text||
|
||||
|
||||
## Delay
|
||||
|
||||
Pause script execution by a defined time.
|
||||
|Command|Parameters|Notes|
|
||||
|-|-|-|
|
||||
|DELAY|Delay value in ms|Single delay|
|
||||
|DEFAULT_DELAY|Delay value in ms|Add delay before every next command|
|
||||
|DEFAULTDELAY|Delay value in ms|Same as DEFAULT_DELAY|
|
||||
|
||||
## Special keys
|
||||
|
||||
| Command | Notes |
|
||||
| ------------------ | ---------------- |
|
||||
| DOWNARROW / DOWN | |
|
||||
| LEFTARROW / LEFT | |
|
||||
| RIGHTARROW / RIGHT | |
|
||||
| UPARROW / UP | |
|
||||
| ENTER | |
|
||||
| DELETE | |
|
||||
| BACKSPACE | |
|
||||
| END | |
|
||||
| HOME | |
|
||||
| ESCAPE / ESC | |
|
||||
| INSERT | |
|
||||
| PAGEUP | |
|
||||
| PAGEDOWN | |
|
||||
| CAPSLOCK | |
|
||||
| NUMLOCK | |
|
||||
| SCROLLLOCK | |
|
||||
| PRINTSCREEN | |
|
||||
| BREAK | Pause/Break key |
|
||||
| PAUSE | Pause/Break key |
|
||||
| SPACE | |
|
||||
| TAB | |
|
||||
| MENU | Context menu key |
|
||||
| APP | Same as MENU |
|
||||
| Fx | F1-F12 keys |
|
||||
|
||||
## Modifier keys
|
||||
|
||||
Can be combined with a special key command or a single character.
|
||||
|Command|Notes|
|
||||
|-|-|
|
||||
|CONTROL / CTRL||
|
||||
|SHIFT||
|
||||
|ALT||
|
||||
|WINDOWS / GUI||
|
||||
|CTRL-ALT|CTRL+ALT|
|
||||
|CTRL-SHIFT|CTRL+SHIFT|
|
||||
|ALT-SHIFT|ALT+SHIFT|
|
||||
|ALT-GUI|ALT+WIN|
|
||||
|GUI-SHIFT|WIN+SHIFT|
|
||||
|
||||
## String
|
||||
|
||||
| Command | Parameters | Notes |
|
||||
| ------- | ----------- | ----------------- |
|
||||
| STRING | Text string | Print text string |
|
||||
|
||||
## Repeat
|
||||
|
||||
| Command | Parameters | Notes |
|
||||
| ------- | ---------------------------- | ----------------------- |
|
||||
| REPEAT | Number of additional repeats | Repeat previous command |
|
||||
|
||||
## ALT+Numpad input
|
||||
|
||||
On Windows and some Linux systems, you can print characters by pressing `ALT` key and entering its code on Numpad.
|
||||
|Command|Parameters|Notes|
|
||||
|-|-|-|
|
||||
|ALTCHAR|Character code|Print single character|
|
||||
|ALTSTRING|Text string|Print text string using ALT+Numpad method|
|
||||
|ALTCODE|Text string|Same as ALTSTRING, presents in some Duckyscript implementations|
|
||||
|
||||
## SysRq
|
||||
|
||||
Send [SysRq command](https://en.wikipedia.org/wiki/Magic_SysRq_key)
|
||||
|Command|Parameters|Notes|
|
||||
|-|-|-|
|
||||
|SYSRQ|Single character||
|
||||
|
||||
## USB device ID
|
||||
|
||||
You can set the custom ID of the Flipper USB HID device. ID command should be in the **first line** of script, it is executed before script run.
|
||||
|
||||
| Command | Parameters | Notes |
|
||||
| ------- | ---------------------------- | ----- |
|
||||
| ID | VID:PID Manufacturer:Product | |
|
||||
|
||||
Example:
|
||||
`ID 1234:abcd Flipper Devices:Flipper Zero`
|
||||
|
||||
VID and PID are hex codes and are mandatory. Manufacturer and Product are text strings and are optional.
|
||||
@@ -1,127 +0,0 @@
|
||||
# Infrared Flipper File Formats
|
||||
|
||||
## Infrared Remote File Format
|
||||
|
||||
### Example
|
||||
|
||||
Filetype: IR signals file
|
||||
Version: 1
|
||||
#
|
||||
name: Button_1
|
||||
type: parsed
|
||||
protocol: NECext
|
||||
address: EE 87 00 00
|
||||
command: 5D A0 00 00
|
||||
#
|
||||
name: Button_2
|
||||
type: raw
|
||||
frequency: 38000
|
||||
duty_cycle: 0.330000
|
||||
data: 504 3432 502 483 500 484 510 502 502 482 501 485 509 1452 504 1458 509 1452 504 481 501 474 509 3420 503
|
||||
#
|
||||
name: Button_3
|
||||
type: parsed
|
||||
protocol: SIRC
|
||||
address: 01 00 00 00
|
||||
command: 15 00 00 00
|
||||
|
||||
### Description
|
||||
|
||||
Filename extension: `.ir`
|
||||
|
||||
This file format is used to store an infrared remote that consists of an arbitrary number of buttons.
|
||||
Each button is separated from others by a comment character (`#`) for better readability.
|
||||
|
||||
Known protocols are represented in the `parsed` form, whereas non-recognized signals may be saved and re-transmitted as `raw` data.
|
||||
|
||||
#### Version history:
|
||||
|
||||
1. Initial version.
|
||||
|
||||
#### Format fields
|
||||
|
||||
| Name | Use | Type | Description |
|
||||
| ---------- | ------ | ------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| name | both | string | Name of the button. Only printable ASCII characters are allowed. |
|
||||
| type | both | string | Type of the signal. Must be `parsed` or `raw`. |
|
||||
| protocol | parsed | string | Name of the infrared protocol. Refer to `ir` console command for the complete list of supported protocols. |
|
||||
| address | parsed | hex | Payload address. Must be 4 bytes long. |
|
||||
| command | parsed | hex | Payload command. Must be 4 bytes long. |
|
||||
| frequency | raw | uint32 | Carrier frequency, in Hertz, usually 38000 Hz. |
|
||||
| duty_cycle | raw | float | Carrier duty cycle, usually 0.33. |
|
||||
| data | raw | uint32 | Raw signal timings, in microseconds between logic level changes. Individual elements must be space-separated. Maximum timings amount is 1024. |
|
||||
|
||||
## Infrared Library File Format
|
||||
|
||||
### Examples
|
||||
|
||||
- [TV Universal Library](/assets/resources/infrared/assets/tv.ir)
|
||||
- [A/C Universal Library](/assets/resources/infrared/assets/ac.ir)
|
||||
- [Audio Universal Library](/assets/resources/infrared/assets/audio.ir)
|
||||
|
||||
### Description
|
||||
|
||||
Filename extension: `.ir`
|
||||
|
||||
This file format is used to store universal remote libraries. It is identical to the previous format, differing only in the `Filetype` field.\
|
||||
It also has predefined button names for each universal library type, so that the universal remote application can understand them.
|
||||
See [Universal Remotes](/documentation/UniversalRemotes.md) for more information.
|
||||
|
||||
### Version history:
|
||||
|
||||
1. Initial version.
|
||||
|
||||
## Infrared Test File Format
|
||||
|
||||
### Examples
|
||||
|
||||
See [Infrared Unit Tests](/assets/unit_tests/infrared/) for various examples.
|
||||
|
||||
### Description
|
||||
|
||||
Filename extension: `.irtest`
|
||||
|
||||
This file format is used to store technical test data that is too large to keep directly in the firmware.
|
||||
It is mostly similar to the two previous formats, with the main difference being the addition of the parsed signal arrays.
|
||||
|
||||
Each infrared protocol must have corresponding unit tests complete with an `.irtest` file.
|
||||
|
||||
Known protocols are represented in the `parsed_array` form, whereas raw data has the `raw` type.\
|
||||
Note: a single parsed signal must be represented as an array of size 1.
|
||||
|
||||
### Version history:
|
||||
|
||||
1. Initial version.
|
||||
|
||||
#### Format fields
|
||||
|
||||
| Name | Use | Type | Description |
|
||||
| ---------- | ------------ | ------ | ---------------------------------------------------------------- |
|
||||
| name | both | string | Name of the signal. Only printable ASCII characters are allowed. |
|
||||
| type | both | string | Type of the signal. Must be `parsed_array` or `raw`. |
|
||||
| count | parsed_array | uint32 | The number of parsed signals in an array. Must be at least 1. |
|
||||
| protocol | parsed_array | string | Same as in previous formats. |
|
||||
| address | parsed_array | hex | Ditto. |
|
||||
| command | parsed_array | hex | Ditto. |
|
||||
| repeat | parsed_array | bool | Indicates whether the signal is a repeated button press. |
|
||||
| frequency | raw | uint32 | Same as in previous formats. |
|
||||
| duty_cycle | raw | float | Ditto. |
|
||||
| data | raw | uint32 | Ditto. |
|
||||
|
||||
#### Signal names
|
||||
|
||||
The signal names in an `.irtest` file follow a convention `<name><test_number>`, where the name is one of:
|
||||
|
||||
- decoder_input
|
||||
- decoder_expected
|
||||
- encoder_decoder_input,
|
||||
|
||||
and the number is a sequential integer: 1, 2, 3, etc., which produces names like `decoder_input1`, `encoder_decoder_input3`, and so on.
|
||||
|
||||
| Name | Type | Description |
|
||||
| --------------------- | ------------ | ----------------------------------------------------------------------------------------------------- |
|
||||
| decoder_input | raw | A raw signal containing the decoder input. Also used as the expected encoder output. |
|
||||
| decoder_expected | parsed_array | An array of parsed signals containing the expected decoder output. Also used as the encoder input. |
|
||||
| encoder_decoder_input | parsed_array | An array of parsed signals containing both the encoder-decoder input and expected output. |
|
||||
|
||||
See [Unit Tests](/documentation/UnitTests.md#infrared) for more info.
|
||||
@@ -1,49 +0,0 @@
|
||||
# LF RFID key file format
|
||||
|
||||
## Example
|
||||
|
||||
```
|
||||
Filetype: Flipper RFID key
|
||||
Version: 1
|
||||
Key type: EM4100
|
||||
Data: 01 23 45 67 89
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Filename extension: `.rfid`
|
||||
|
||||
The file stores a single RFID key of the type defined by the `Key type` parameter.
|
||||
|
||||
### Version history
|
||||
|
||||
1. Initial version.
|
||||
|
||||
### Format fields
|
||||
|
||||
| Name | Description |
|
||||
| -------- | --------------------- |
|
||||
| Key type | Key protocol type |
|
||||
| Data | Key data (HEX values) |
|
||||
|
||||
### Supported key types
|
||||
|
||||
| Type | Full name |
|
||||
| ----------- | ----------------- |
|
||||
| EM4100 | EM-Micro EM4100 |
|
||||
| H10301 | HID H10301 |
|
||||
| Idteck | IDTECK |
|
||||
| Indala26 | Motorola Indala26 |
|
||||
| IOProxXSF | Kantech IOProxXSF |
|
||||
| AWID | AWID |
|
||||
| FDX-A | FECAVA FDX-A |
|
||||
| FDX-B | ISO FDX-B |
|
||||
| HIDProx | Generic HIDProx |
|
||||
| HIDExt | Generic HIDExt |
|
||||
| Pyramid | Farpointe Pyramid |
|
||||
| Viking | Viking |
|
||||
| Jablotron | Jablotron |
|
||||
| Paradox | Paradox |
|
||||
| PAC/Stanley | PAC/Stanley |
|
||||
| Keri | Keri |
|
||||
| Gallagher | Gallagher |
|
||||
@@ -1,255 +0,0 @@
|
||||
# NFC Flipper File Formats
|
||||
|
||||
## NFC-A (UID) + Header
|
||||
|
||||
### Example
|
||||
|
||||
Filetype: Flipper NFC device
|
||||
Version: 3
|
||||
# Nfc device type can be UID, Mifare Ultralight, Mifare Classic, Bank card
|
||||
Device type: UID
|
||||
# UID, ATQA and SAK are common for all formats
|
||||
UID: 04 85 92 8A A0 61 81
|
||||
ATQA: 00 44
|
||||
SAK: 00
|
||||
|
||||
### Description
|
||||
|
||||
This file format is used to store the UID, SAK and ATQA of a NFC-A device. It does not store any internal data, so it can be used for multiple different card types. Also used as a header for other formats.
|
||||
|
||||
Version differences:
|
||||
|
||||
1. Initial version, deprecated
|
||||
2. LSB ATQA (e.g. 4400 instead of 0044)
|
||||
3. MSB ATQA (current version)
|
||||
|
||||
UID can be either 4 or 7 bytes long. ATQA is 2 bytes long. SAK is 1 byte long.
|
||||
|
||||
## Mifare Ultralight/NTAG
|
||||
|
||||
### Example
|
||||
|
||||
Filetype: Flipper NFC device
|
||||
Version: 3
|
||||
# Nfc device type can be UID, Mifare Ultralight, Mifare Classic
|
||||
Device type: NTAG216
|
||||
# UID, ATQA and SAK are common for all formats
|
||||
UID: 04 85 90 54 12 98 23
|
||||
ATQA: 00 44
|
||||
SAK: 00
|
||||
# Mifare Ultralight specific data
|
||||
Data format version: 1
|
||||
Signature: 1B 84 EB 70 BD 4C BD 1B 1D E4 98 0B 18 58 BD 7C 72 85 B4 E4 7B 38 8E 96 CF 88 6B EE A3 43 AD 90
|
||||
Mifare version: 00 04 04 02 01 00 13 03
|
||||
Counter 0: 0
|
||||
Tearing 0: 00
|
||||
Counter 1: 0
|
||||
Tearing 1: 00
|
||||
Counter 2: 0
|
||||
Tearing 2: 00
|
||||
Pages total: 231
|
||||
Pages read: 231
|
||||
Page 0: 04 85 92 9B
|
||||
Page 1: 8A A0 61 81
|
||||
Page 2: CA 48 0F 00
|
||||
...
|
||||
Page 224: 00 00 00 00
|
||||
Page 225: 00 00 00 00
|
||||
Page 226: 00 00 7F BD
|
||||
Page 227: 04 00 00 E2
|
||||
Page 228: 00 05 00 00
|
||||
Page 229: 00 00 00 00
|
||||
Page 230: 00 00 00 00
|
||||
Failed authentication attempts: 0
|
||||
|
||||
### Description
|
||||
|
||||
This file format is used to store the UID, SAK and ATQA of a Mifare Ultralight/NTAG device. It also stores the internal data of the card, the signature, the version, and the counters. The data is stored in pages, just like on the card itself.
|
||||
|
||||
The "Signature" field contains the reply of the tag to the READ_SIG command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 31)
|
||||
|
||||
The "Mifare version" field is not related to the file format version but to the Mifare Ultralight version. It contains the response of the tag to the GET_VERSION command. More on that can be found here: <https://www.nxp.com/docs/en/data-sheet/MF0ULX1.pdf> (page 21)
|
||||
|
||||
Other fields are the direct representation of the card's internal state. Learn more about them in the same datasheet.
|
||||
|
||||
Version differences:
|
||||
|
||||
1. Current version
|
||||
|
||||
## Mifare Classic
|
||||
|
||||
### Example
|
||||
|
||||
Filetype: Flipper NFC device
|
||||
Version: 3
|
||||
# Nfc device type can be UID, Mifare Ultralight, Mifare Classic
|
||||
Device type: Mifare Classic
|
||||
# UID, ATQA and SAK are common for all formats
|
||||
UID: BA E2 7C 9D
|
||||
ATQA: 00 02
|
||||
SAK: 18
|
||||
# Mifare Classic specific data
|
||||
Mifare Classic type: 4K
|
||||
Data format version: 2
|
||||
# Mifare Classic blocks, '??' means unknown data
|
||||
Block 0: BA E2 7C 9D B9 18 02 00 46 44 53 37 30 56 30 31
|
||||
Block 1: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 3: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
|
||||
Block 4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 7: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
|
||||
...
|
||||
Block 238: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 239: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
|
||||
Block 240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 241: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 242: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 243: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 244: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 245: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 246: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 247: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 248: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 249: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 251: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 252: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 253: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 254: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
Block 255: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
|
||||
|
||||
### Description
|
||||
|
||||
This file format is used to store the NFC-A and Mifare Classic specific data of a Mifare Classic card. Aside from the NFC-A data, it stores the card type (1K/4K) and the internal data of the card. The data is stored in blocks, there is no sector grouping. If the block's data is unknown, it is represented by '??'. Otherwise, the data is represented as a hex string.
|
||||
|
||||
Version differences:
|
||||
|
||||
1. Initial version, has Key A and Key B masks instead of marking unknown data with '??'.
|
||||
|
||||
Example:
|
||||
|
||||
...
|
||||
Data format version: 1
|
||||
# Key map is the bit mask indicating valid key in each sector
|
||||
Key A map: 000000000000FFFF
|
||||
Key B map: 000000000000FFFF
|
||||
# Mifare Classic blocks
|
||||
...
|
||||
|
||||
2. Current version
|
||||
|
||||
## Mifare DESFire
|
||||
|
||||
### Example
|
||||
|
||||
Filetype: Flipper NFC device
|
||||
Version: 3
|
||||
# Nfc device type can be UID, Mifare Ultralight, Mifare Classic
|
||||
Device type: Mifare DESFire
|
||||
# UID, ATQA and SAK are common for all formats
|
||||
UID: 04 2F 19 0A CD 66 80
|
||||
ATQA: 03 44
|
||||
SAK: 20
|
||||
# Mifare DESFire specific data
|
||||
PICC Version: 04 01 01 12 00 1A 05 04 01 01 02 01 1A 05 04 2F 19 0A CD 66 80 CE ED D4 51 80 31 19
|
||||
PICC Free Memory: 7520
|
||||
PICC Change Key ID: 00
|
||||
PICC Config Changeable: true
|
||||
PICC Free Create Delete: true
|
||||
PICC Free Directory List: true
|
||||
PICC Key Changeable: true
|
||||
PICC Max Keys: 01
|
||||
PICC Key 0 Version: 00
|
||||
Application Count: 1
|
||||
Application IDs: 56 34 12
|
||||
Application 563412 Change Key ID: 00
|
||||
Application 563412 Config Changeable: true
|
||||
Application 563412 Free Create Delete: true
|
||||
Application 563412 Free Directory List: true
|
||||
Application 563412 Key Changeable: true
|
||||
Application 563412 Max Keys: 0E
|
||||
Application 563412 Key 0 Version: 00
|
||||
Application 563412 Key 1 Version: 00
|
||||
Application 563412 Key 2 Version: 00
|
||||
Application 563412 Key 3 Version: 00
|
||||
Application 563412 Key 4 Version: 00
|
||||
Application 563412 Key 5 Version: 00
|
||||
Application 563412 Key 6 Version: 00
|
||||
Application 563412 Key 7 Version: 00
|
||||
Application 563412 Key 8 Version: 00
|
||||
Application 563412 Key 9 Version: 00
|
||||
Application 563412 Key 10 Version: 00
|
||||
Application 563412 Key 11 Version: 00
|
||||
Application 563412 Key 12 Version: 00
|
||||
Application 563412 Key 13 Version: 00
|
||||
Application 563412 File IDs: 01
|
||||
Application 563412 File 1 Type: 00
|
||||
Application 563412 File 1 Communication Settings: 00
|
||||
Application 563412 File 1 Access Rights: EE EE
|
||||
Application 563412 File 1 Size: 256
|
||||
Application 563412 File 1: 13 37 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
||||
|
||||
### Description
|
||||
|
||||
This file format is used to store the NFC-A and Mifare DESFire specific data of a Mifare DESFire card. Aside from the NFC-A data, it stores the card type (DESFire) and the internal data of the card. The data is stored per-application, and per-file. Here, the card was written using those pm3 commands:
|
||||
|
||||
hf mfdes createapp --aid 123456 --fid 2345 --dfname astra
|
||||
hf mfdes createfile --aid 123456 --fid 01 --isofid 0001 --size 000100
|
||||
hf mfdes write --aid 123456 --fid 01 -d 1337
|
||||
|
||||
Version differences:
|
||||
None, there are no versions yet.
|
||||
|
||||
## Mifare Classic Dictionary
|
||||
|
||||
### Example
|
||||
|
||||
# Key dictionary from https://github.com/ikarus23/MifareClassicTool.git
|
||||
|
||||
# More well known keys!
|
||||
# Standard keys
|
||||
FFFFFFFFFFFF
|
||||
A0A1A2A3A4A5
|
||||
D3F7D3F7D3F7
|
||||
000000000000
|
||||
|
||||
# Keys from mfoc
|
||||
B0B1B2B3B4B5
|
||||
4D3A99C351DD
|
||||
1A982C7E459A
|
||||
AABBCCDDEEFF
|
||||
714C5C886E97
|
||||
587EE5F9350F
|
||||
A0478CC39091
|
||||
533CB6C723F6
|
||||
8FD0A4F256E9
|
||||
...
|
||||
|
||||
### Description
|
||||
|
||||
This file contains a list of Mifare Classic keys. Each key is represented as a hex string. Lines starting with '#' are ignored as comments. Blank lines are ignored as well.
|
||||
|
||||
## EMV resources
|
||||
|
||||
### Example
|
||||
|
||||
Filetype: Flipper EMV resources
|
||||
Version: 1
|
||||
# EMV currency code: currency name
|
||||
0997: USN
|
||||
0994: XSU
|
||||
0990: CLF
|
||||
0986: BRL
|
||||
0985: PLN
|
||||
0984: BOV
|
||||
...
|
||||
|
||||
### Description
|
||||
|
||||
This file stores a list of EMV currency codes, country codes, or AIDs and their names. Each line contains a hex value and a name separated by a colon and a space.
|
||||
|
||||
Version differences:
|
||||
|
||||
1. Initial version
|
||||
@@ -1,266 +0,0 @@
|
||||
# File Formats for Flipper's SubGhz Subsystem
|
||||
|
||||
## `.sub` File Format
|
||||
|
||||
Flipper uses `.sub` files to store SubGhz transmissions. These are text files in Flipper File Format. `.sub` files can contain either a SubGhz Key with a certain protocol or SubGhz RAW data.
|
||||
|
||||
A `.sub` files consist of 3 parts:
|
||||
|
||||
- **header**: contains file type, version, and frequency
|
||||
- **preset information**: preset type and, in case of a custom preset, transceiver configuration data
|
||||
- **protocol and its data**: contains protocol name and its specific data, such as key, bit length, etc., or RAW data
|
||||
|
||||
Flipper's SubGhz subsystem uses presets to configure the radio transceiver. Presets are used to configure modulation, bandwidth, filters, etc. There are several presets available in stock firmware, and there is a way to create custom presets. See [SubGhz Presets](#adding-a-custom-preset) for more details.
|
||||
|
||||
## Header format
|
||||
|
||||
Header is a mandatory part of `.sub` file. It contains file type, version, and frequency.
|
||||
|
||||
| Field | Type | Description |
|
||||
| ----------- | ------ | ----------------------------------------------------------------- |
|
||||
| `Filetype` | string | Filetype of subghz file format, must be `Flipper SubGhz Key File` |
|
||||
| `Version` | uint | Version of subghz file format, current version is 1 |
|
||||
| `Frequency` | uint | Frequency in Hertz |
|
||||
|
||||
## Preset information
|
||||
|
||||
Preset information is a mandatory part for `.sub` files. It contains preset type and, in case of custom preset, transceiver configuration data.
|
||||
|
||||
When using one of the standard presets, only `Preset` field is required. When using a custom preset, `Custom_preset_module` and `Custom_preset_data` fields are required.
|
||||
|
||||
| Field | Description |
|
||||
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `Preset` | Radio preset name (configures modulation, bandwidth, filters, etc.). When using a custom preset, must be `FuriHalSubGhzPresetCustom` |
|
||||
| `Custom_preset_module` | Transceiver identifier, `CC1101` for Flipper Zero |
|
||||
| `Custom_preset_data` | Transceiver configuration data |
|
||||
|
||||
Built-in presets:
|
||||
|
||||
- `FuriHalSubGhzPresetOok270Async` — On/Off Keying, 270kHz bandwidth, async(IO throw GP0)
|
||||
- `FuriHalSubGhzPresetOok650Async` — On/Off Keying, 650kHz bandwidth, async(IO throw GP0)
|
||||
- `FuriHalSubGhzPreset2FSKDev238Async` — 2 Frequency Shift Keying, deviation 2kHz, 270kHz bandwidth, async(IO throw GP0)
|
||||
- `FuriHalSubGhzPreset2FSKDev476Async` — 2 Frequency Shift Keying, deviation 47kHz, 270kHz bandwidth, async(IO throw GP0)
|
||||
|
||||
### Transceiver Configuration Data
|
||||
|
||||
Transceiver configuration data is a string of bytes, encoded in hex format, separated by spaces. For CC1101 data structure is: `XX YY XX YY .. 00 00 ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ`, where:
|
||||
|
||||
- XX holds register address,
|
||||
- YY contains register value,
|
||||
- 00 00: marks register block end,
|
||||
- `ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ`: 8 byte PA table (Power amplifier ramp table).
|
||||
|
||||
You can find more details in the [CC1101 datasheet](https://www.ti.com/lit/ds/symlink/cc1101.pdf) and `furi_hal_subghz` code.
|
||||
|
||||
## File Data
|
||||
|
||||
`.sub` file data section contains either key data — protocol name and its specific data, bit length, etc., or RAW data — an array of signal timings, recorded without any protocol-specific processing.
|
||||
|
||||
### Key Files
|
||||
|
||||
`.sub` files with key data files contain protocol name and its specific data, such as key value, bit length, etc.
|
||||
Check out the protocol registry for the full list of supported protocol names.
|
||||
|
||||
Example of a key data block in Princeton format:
|
||||
|
||||
```
|
||||
...
|
||||
Protocol: Princeton
|
||||
Bit: 24
|
||||
Key: 00 00 00 00 00 95 D5 D4
|
||||
TE: 400
|
||||
```
|
||||
|
||||
Protocol-specific fields in this example:
|
||||
|
||||
| Field | Description |
|
||||
| ----- | --------------------------------- |
|
||||
| `Bit` | Princeton payload length, in bits |
|
||||
| `Key` | Princeton payload data |
|
||||
| `TE` | Princeton quantization interval |
|
||||
|
||||
This file may contain additional fields, more details on available fields can be found in subghz protocols library.
|
||||
|
||||
### RAW Files
|
||||
|
||||
RAW `.sub` files contain raw signal data that is not processed through protocol-specific decoding. These files are useful for testing or sending data not supported by any known protocol.
|
||||
|
||||
For RAW files, 2 fields are required:
|
||||
|
||||
- `Protocol`, must be `RAW`
|
||||
- `RAW_Data`, contains an array of timings, specified in microseconds Values must be non-zero, start with a positive number, and interleaved (change sign with each value). Up to 512 values per line. Can be specified multiple times to store multiple lines of data.
|
||||
|
||||
Example of RAW data:
|
||||
|
||||
Protocol: RAW
|
||||
RAW_Data: 29262 361 -68 2635 -66 24113 -66 11 ...
|
||||
|
||||
Long payload not fitting into internal memory buffer and consisting of short duration timings (< 10us) may not be read fast enough from the SD card. That might cause the signal transmission to stop before reaching the end of the payload. Ensure that your SD Card has good performance before transmitting long or complex RAW payloads.
|
||||
|
||||
## File examples
|
||||
|
||||
### Key file, standard preset
|
||||
|
||||
Filetype: Flipper SubGhz Key File
|
||||
Version: 1
|
||||
Frequency: 433920000
|
||||
Preset: FuriHalSubGhzPresetOok650Async
|
||||
Protocol: Princeton
|
||||
Bit: 24
|
||||
Key: 00 00 00 00 00 95 D5 D4
|
||||
TE: 400
|
||||
|
||||
### Key file, custom preset
|
||||
|
||||
Filetype: Flipper SubGhz Key File
|
||||
Version: 1
|
||||
Frequency: 433920000
|
||||
Preset: FuriHalSubGhzPresetCustom
|
||||
Custom_preset_module: CC1101
|
||||
Custom_preset_data: 02 0D 03 07 08 32 0B 06 14 00 13 00 12 30 11 32 10 17 18 18 19 18 1D 91 1C 00 1B 07 20 FB 22 11 21 B6 00 00 00 C0 00 00 00 00 00 00
|
||||
Protocol: Princeton
|
||||
Bit: 24
|
||||
Key: 00 00 00 00 00 95 D5 D4
|
||||
TE: 400
|
||||
|
||||
### RAW file, standard preset
|
||||
|
||||
Filetype: Flipper SubGhz RAW File
|
||||
Version: 1
|
||||
Frequency: 433920000
|
||||
Preset: FuriHalSubGhzPresetOok650Async
|
||||
Protocol: RAW
|
||||
RAW_Data: 29262 361 -68 2635 -66 24113 -66 11 ...
|
||||
RAW_Data: -424 205 -412 159 -412 381 -240 181 ...
|
||||
RAW_Data: -1448 361 -17056 131 -134 233 -1462 131 -166 953 -100 ...
|
||||
|
||||
### RAW file, custom preset
|
||||
|
||||
Filetype: Flipper SubGhz RAW File
|
||||
Version: 1
|
||||
Frequency: 433920000
|
||||
Preset: FuriHalSubGhzPresetCustom
|
||||
Custom_preset_module: CC1101
|
||||
Сustom_preset_data: 02 0D 03 07 08 32 0B 06 14 00 13 00 12 30 11 32 10 17 18 18 19 18 1D 91 1C 00 1B 07 20 FB 22 11 21 B6 00 00 00 C0 00 00 00 00 00 00
|
||||
Protocol: RAW
|
||||
RAW_Data: 29262 361 -68 2635 -66 24113 -66 11 ...
|
||||
RAW_Data: -424 205 -412 159 -412 381 -240 181 ...
|
||||
RAW_Data: -1448 361 -17056 131 -134 233 -1462 131 -166 953 -100 ...
|
||||
|
||||
# SubGhz configuration files
|
||||
|
||||
SubGhz application provides support for adding extra radio presets and additional keys for decoding transmissions in certain protocols.
|
||||
|
||||
## SubGhz `keeloq_mfcodes_user` file
|
||||
|
||||
This file contains additional manufacturer keys for Keeloq protocol. It is used to decode Keeloq transmissions.
|
||||
This file is loaded at subghz application start and is located at path `/ext/subghz/assets/keeloq_mfcodes_user`.
|
||||
|
||||
### File format
|
||||
|
||||
File contains a header and a list of manufacturer keys.
|
||||
|
||||
File header format:
|
||||
|
||||
| Field | Type | Description |
|
||||
| ------------ | ------ | ------------------------------------------------------------------ |
|
||||
| `Filetype` | string | SubGhz Keystore file format, always `Flipper SubGhz Keystore File` |
|
||||
| `Version` | uint | File format version, 0 |
|
||||
| `Encryption` | uint | File encryption: for user-provided file, set to 0 (disabled) |
|
||||
|
||||
Following the header, file contains a list of user-provided manufacture keys, one key per line.
|
||||
For each key, a name and encryption method must be specified, according to comment in file header. More information can be found in keeloq decoder source code.
|
||||
|
||||
### Example
|
||||
|
||||
# to use manual settings and prevent them from being deleted on upgrade, rename *_user.example files to *_user
|
||||
# for adding manufacture keys
|
||||
# AABBCCDDEEFFAABB:X:NAME
|
||||
# AABBCCDDEEFFAABB - man 64 bit
|
||||
# X - encryption method:
|
||||
# - 0 - iterates over both previous and man in direct and reverse byte sequence
|
||||
# - 1 - Simple Learning
|
||||
# - 2 - Normal_Learning
|
||||
# - 3 - Secure_Learning
|
||||
# - 4 - Magic_xor_type1 Learning
|
||||
#
|
||||
# NAME - name (string without spaces) max 64 characters long
|
||||
Filetype: Flipper SubGhz Keystore File
|
||||
Version: 0
|
||||
Encryption: 0
|
||||
AABBCCDDEEFFAABB:1:Test1
|
||||
AABBCCDDEEFFAABB:1:Test2
|
||||
|
||||
## SubGhz `setting_user` file
|
||||
|
||||
This file contains additional radio presets and frequencies for SubGhz application. It is used to add new presets and frequencies for existing presets. This file is being loaded on subghz application start and is located at path `/ext/subghz/assets/setting_user`.
|
||||
|
||||
### File format
|
||||
|
||||
File contains a header, basic options, and optional lists of presets and frequencies.
|
||||
|
||||
Header must contain the following fields:
|
||||
|
||||
- `Filetype`: SubGhz setting file format, must be `Flipper SubGhz Setting File`.
|
||||
- `Version`: file format version, current is `1`.
|
||||
|
||||
#### Basic settings
|
||||
|
||||
- `Add_standard_frequencies`: bool, flag indicating whether to load standard frequencies shipped with firmware. If set to `false`, only frequencies specified in this file will be used.
|
||||
- `Default_frequency`: uint, default frequency used in SubGhz application.
|
||||
|
||||
#### Adding more frequencies
|
||||
|
||||
- `Frequency`: uint — additional frequency for the subghz application frequency list. Used in Read and Read RAW. You can specify multiple frequencies, one per line.
|
||||
|
||||
#### Adding more hopper frequencies
|
||||
|
||||
- `Hopper_frequency`: uint — additional frequency for subghz application frequency hopping. Used in Frequency Analyzer. You can specify multiple frequencies, one per line.
|
||||
|
||||
Repeating the same frequency will cause Flipper to listen to this frequency more often.
|
||||
|
||||
#### Adding a Custom Preset
|
||||
|
||||
You can have as many presets as you want. Presets are embedded into `.sub` files, so another Flipper can load them directly from that file.
|
||||
Each preset is defined by the following fields:
|
||||
|
||||
| Field | Description |
|
||||
| ---------------------- | ------------------------------------------------------------------------------------------------------------------ |
|
||||
| `Custom_preset_name` | string, preset name that will be shown in SubGHz application |
|
||||
| `Custom_preset_module` | string, transceiver identifier. Set to `CC1101` for Flipper Zero |
|
||||
| `Custom_preset_data` | transceiver configuration data. See [Transceiver Configuration Data](#transceiver-configuration-data) for details. |
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
# to use manual settings and prevent them from being deleted on upgrade, rename *_user.example files to *_user
|
||||
Filetype: Flipper SubGhz Setting File
|
||||
Version: 1
|
||||
|
||||
# Add Standard frequencies for your region
|
||||
Add_standard_frequencies: true
|
||||
|
||||
# Default Frequency: used as default for "Read" and "Read Raw"
|
||||
Default_frequency: 433920000
|
||||
|
||||
# Frequencies used for "Read", "Read Raw" and "Frequency Analyzer"
|
||||
Frequency: 300000000
|
||||
Frequency: 310000000
|
||||
Frequency: 320000000
|
||||
|
||||
# Frequencies used for hopping mode (keep this list small or Flipper will miss the signal)
|
||||
Hopper_frequency: 300000000
|
||||
Hopper_frequency: 310000000
|
||||
Hopper_frequency: 310000000
|
||||
|
||||
# Custom preset
|
||||
# format for CC1101 "Custom_preset_data:" XX YY XX YY .. 00 00 ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ, where: XX-register, YY - register data, 00 00 - end load register, ZZ - 8 byte Pa table register
|
||||
|
||||
#Custom_preset_name: AM_1
|
||||
Custom_preset_module: CC1101
|
||||
Custom_preset_data: 02 0D 03 07 08 32 0B 06 14 00 13 00 12 30 11 32 10 17 18 18 19 18 1D 91 1C 00 1B 07 20 FB 22 11 21 B6 00 00 00 C0 00 00 00 00 00 00
|
||||
|
||||
#Custom_preset_name: AM_2
|
||||
#Custom_preset_module: CC1101
|
||||
#Custom_preset_data: 02 0D 03 07 08 32 0B 06 14 00 13 00 12 30 11 32 10 17 18 18 19 18 1D 91 1C 00 1B 07 20 FB 22 11 21 B6 00 00 00 C0 00 00 00 00 00 00
|
||||
```
|
||||
@@ -1,29 +0,0 @@
|
||||
# iButton key file format
|
||||
|
||||
## Example
|
||||
|
||||
```
|
||||
Filetype: Flipper iButton key
|
||||
Version: 1
|
||||
# Key type can be Cyfral, Dallas or Metakom
|
||||
Key type: Dallas
|
||||
# Data size for Cyfral is 2, for Metakom is 4, for Dallas is 8
|
||||
Data: 12 34 56 78 9A BC DE F0
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Filename extension: `.ibtn`
|
||||
|
||||
The file stores a single iButton key of the type defined by the `Key type` parameter.
|
||||
|
||||
### Version history
|
||||
|
||||
1. Initial version.
|
||||
|
||||
### Format fields
|
||||
|
||||
| Name | Description |
|
||||
| -------- | -------------------------------------------- |
|
||||
| Key type | Currently supported: Cyfral, Dallas, Metakom |
|
||||
| Data | Key data (HEX values) |
|
||||
@@ -1,20 +0,0 @@
|
||||
## .kl file format
|
||||
|
||||
A .kl file is a binary file format which stores, for each ascii code point in order from *ASCII(0)* to *ASCII(127)*, a 16 bit little endian value composed of a *USB HID code* in the low order byte and a *bit set of modifier keys* in the high order byte.
|
||||
|
||||
*USB HID codes* for each key of a standard 102/105 key keyboard are (as displayed passing option `-k` to the software):
|
||||
|
||||
|
||||
----------------------------------------------------------------------
|
||||
| 35 | 1e | 1f | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 2d | 2e | <- |
|
||||
----------------------------------------------------------------------
|
||||
| -> | 14 | 1a | 08 | 15 | 17 | 1c | 18 | 0c | 12 | 13 | 2f | 30 | |
|
||||
------------------------------------------------------------------| |
|
||||
| o | 04 | 16 | 07 | 09 | 0a | 0b | 0d | 0e | 0f | 33 | 34 | 31 | |
|
||||
----------------------------------------------------------------------
|
||||
| ^ | 64 | 1d | 1b | 06 | 19 | 05 | 11 | 10 | 36 | 37 | 38 | ^ |
|
||||
----------------------------------------------------------------------
|
||||
| ctrl | gui | alt | 2c | alt | gui | ctrl |
|
||||
----------------------------------------------------------------------
|
||||
|
||||
*Modifier key bits* are, in order starting from bit 1: *lctrl*, *lshift*, *lalt*, *lgui*, *rctrl*, *rshift*, *ralt*, *rgui*.
|
||||
@@ -1,179 +0,0 @@
|
||||
<h1 align="center"><code>Xtreme Firmware Documentation</code></h1>
|
||||
|
||||
<p align="center">
|
||||
<img src="https://user-images.githubusercontent.com/55334727/209031152-efbca66c-3fe0-41b5-a860-e0d7522a9279.png">
|
||||
</p>
|
||||
|
||||
<h2 align="center">Install:</h2>
|
||||
|
||||
**NOTE: If you are coming from a different FW, it is recommended to delete / clear your "apps" folder on the SD card prior to updating. This folder houses all the .fap files, which do not update to the correct API versions by default if old ones are present (Thanks flipper devs). This does `NOT` remove any of your saved files!**
|
||||
<br><br>
|
||||
|
||||
<h3> Web Updater / Mobile App / Automatic qFlipper Update</h3>
|
||||
|
||||
- Go to the latest release from [The releases tab](https://github.com/ClaraCrazy/Flipper-Xtreme/releases/latest)
|
||||
- Download the .tgz file
|
||||
- Run your updater of choice with it
|
||||
|
||||
- Enjoy!
|
||||
<br>
|
||||
|
||||
-----
|
||||
<br>
|
||||
|
||||
<h3> Manual Update (Because qFlipper loves to break every now and then for no reason at all)</h3>
|
||||
|
||||
- Download the latest release (.zip) from [The releases tab](https://github.com/ClaraCrazy/Flipper-Xtreme/releases/latest)
|
||||
- Extract the archive. This is now your new Firmware folder
|
||||
- Open [qFlipper](https://flipperzero.one/update), head to `SD/Update` and simply move the firmware folder there
|
||||
- On the Flipper, hit the `Arrow Down` button, this will get you to the file menu. Hit `Arrow Left` once, and then simply search for your updates folder
|
||||
- Inside that folder, select the Firmware you just moved onto it, and run the file thats simply called `Update`
|
||||
|
||||
- Enjoy!
|
||||
|
||||
----
|
||||
|
||||
<br>
|
||||
<h2 align="center">Build it yourself:</h2>
|
||||
|
||||
```bash
|
||||
To download the needed tools:
|
||||
$ git clone --recursive https://github.com/ClaraCrazy/Flipper-Xtreme.git
|
||||
$ cd Flipper-Xtreme/
|
||||
|
||||
To flash directly to the Flipper (Needs to be connected via USB, qFlipper closed)
|
||||
$ ./fbt flash_usb
|
||||
|
||||
To just compile firmware
|
||||
$ ./fbt updater_package
|
||||
|
||||
If building FAPS:
|
||||
$ ./fbt fap_dist
|
||||
|
||||
If building image assets:
|
||||
$ ./fbt resources icons dolphin_ext
|
||||
```
|
||||
|
||||
<br>
|
||||
<h2 align="center">Safe for work mode:</h2>
|
||||
|
||||
**Enable SFW mode with the steps listed below**
|
||||
<br>
|
||||
|
||||
- Navigate to the main screen
|
||||
- Press the UP button on the Flipper
|
||||
- Press the 'SFW Mode' toggle
|
||||
|
||||
----
|
||||
|
||||
<br>
|
||||
<h2 align="center">Support the project</h2>
|
||||
|
||||
**If you like Xtreme Firmware and wish to help out, we would love it if you contributed to the project ❤️**
|
||||
<br>
|
||||
|
||||
- [Bunq - My bank](https://bunq.me/ClaraK)
|
||||
- [Paypal](https://paypal.me/RdX2020)
|
||||
- [Patreon](https://patreon.com/CynthiaLabs)
|
||||
- `Monero`: 41kyWeeoVdK4quzQ4M9ikVGs6tCQCLfdx8jLExTNsAu2SF1QAyDqRdjfGM6EL8L9NpXwt89HJeAoGf1aoArk7nDr4AMMV4T
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
|
||||
<br>
|
||||
<h2 align="center">Applications we use thanks to the awesome contributers and community ❤️</h2>
|
||||
|
||||
## GPIO
|
||||
- [Lightmeter](https://github.com/oleksiikutuzov/flipperzero-lightmeter)
|
||||
- [Air Mouse](https://github.com/ginkage/FlippAirMouse/)
|
||||
- [Wifi Marauder](https://github.com/0xchocolate/flipperzero-firmware-with-wifi-marauder-companion)
|
||||
- [Wifi Deauther](https://github.com/Timmotools/flipperzero_esp8266_deautherv2)
|
||||
- [IFTTT Virtual Button for ESP8266 (By Ferrazzi)](https://github.com/Ferrazzi/FlipperZero_IFTTT_Virtual_Button)
|
||||
- [Flashlight (By xMasterX)](https://github.com/xMasterX/flipper-flashlight)
|
||||
- [GPIO Reader 1](https://github.com/biotinker/flipperzero-gpioreader)
|
||||
- [GPIO Reader 2](https://github.com/aureli1c/flipperzero_GPIO_read)
|
||||
- [Sentry Safe](https://github.com/H4ckd4ddy/flipperzero-sentry-safe-plugin)
|
||||
- [Distance Sensor](https://github.com/Sanqui/flipperzero-firmware/tree/59656ca5fb644e0d4484259986b86a0b963f323d/applications/hc_sr04)
|
||||
- [Temperature Sensor](https://github.com/Mywk/FlipperTemperatureSensor)
|
||||
- [i2c Tools](https://github.com/NaejEL/flipperzero-i2ctools)
|
||||
- [GPS](https://github.com/ezod/flipperzero-gps)
|
||||
- [Mouse Jacker](https://github.com/mothball187/flipperzero-nrf24/tree/main/mousejacker)
|
||||
- [Sniffer](https://github.com/mothball187/flipperzero-nrf24/tree/main/nrfsniff)
|
||||
- [Scanner](https://github.com/vad7/nrf24scan)
|
||||
- [ColecoVision Controller](https://github.com/ezod/flipperzero-rc2014-coleco)
|
||||
|
||||
|
||||
## Games
|
||||
- [2048](https://github.com/eugene-kirzhanov/flipper-zero-2048-game)
|
||||
- [Arkanoid](https://github.com/DarkFlippers/unleashed-firmware/tree/dev/applications/plugins/arkanoid)
|
||||
- [BlackJack](https://github.com/teeebor/flipper_games)
|
||||
- [Doom](https://github.com/p4nic4ttack/doom-flipper-zero/)
|
||||
- Multi Dice - In-house
|
||||
- [Flappy Bird](https://github.com/DroomOne/flipperzero-firmware/tree/dev/applications/flappy_bird)
|
||||
- [Game 15](https://github.com/x27/flipperzero-game15)
|
||||
- [Game of Life (Updated to work by tgxn) (By itsyourbedtime)](https://github.com/tgxn/flipperzero-firmware/blob/dev/applications/game_of_life/game_of_life.c)
|
||||
- Heap defense - Author Unknown
|
||||
- [Mandelbrot Set (By Possibly-Matt)](https://github.com/Possibly-Matt/flipperzero-firmware-wPlugins)
|
||||
- [Minesweeper](https://github.com/panki27/minesweeper)
|
||||
- [Snake](https://github.com/flipperdevices/flipperzero-firmware/tree/dev/applications/plugins/snake_game)
|
||||
- [Solitaire](https://github.com/teeebor/flipper_games)
|
||||
- [Tetris](https://github.com/jeffplang/flipperzero-firmware/tree/tetris_game/applications/tetris_game)
|
||||
- [Tic Tac Toe](https://github.com/gotnull/flipperzero-firmware-wPlugins/tree/420/applications/plugins/tictactoe_game)
|
||||
- [Tamagotchi(By GMMan)](https://github.com/GMMan/flipperzero-tamagotch-p1)
|
||||
- [Video Poker (By PixlEmly)](https://github.com/PixlEmly/flipperzero-firmware-testing/blob/420/applications/VideoPoker/poker.c)
|
||||
- [Yatzee (By emfleak)](https://github.com/emfleak/flipperzero-yatzee)
|
||||
- [Pong (By [nmrr])](https://github.com/nmrr/flipperzero-pong)
|
||||
- [Asteroids (By [antirez])](https://github.com/antirez/flipper-asteroids)
|
||||
|
||||
|
||||
## Misc
|
||||
- [Authenticator (TOTP / HOTP)](https://github.com/akopachov/flipper-zero_authenticator)
|
||||
- [Barcode Generator](https://github.com/McAzzaMan/flipperzero-firmware/tree/UPC-A_Barcode_Generator/applications/barcode_generator)
|
||||
- [Caesar Cipher](https://github.com/panki27/caesar-cipher)
|
||||
- Calculator - In house / notIntense
|
||||
- [Counter](https://github.com/Krulknul/dolphin-counter)
|
||||
- [Hex Viewer](https://github.com/QtRoS/flipper-zero-hex-viewer)
|
||||
- [Mouse Jiggler](https://github.com/Jacob-Tate/flipperzero-firmware/blob/dev/applications/mouse_jiggler/mouse_jiggler.c)
|
||||
- [Converter](https://github.com/theisolinearchip/flipperzero_stuff/tree/main/applications/multi_converter)
|
||||
- [Vibrator](https://github.com/qqmajikpp/flipperzero-firmware-wPlugins/tree/420/applications/plugins/orgasmotron)
|
||||
- [Paint](https://github.com/n-o-T-I-n-s-a-n-e)
|
||||
- [UART Echo](https://github.com/flipperdevices/flipperzero-firmware/pull/831)
|
||||
- [USB HID Autofire](https://github.com/pbek/usb_hid_autofire)
|
||||
- [USB Keyboard & Mouse](https://github.com/huuck/FlipperZeroUSBKeyboard) / (https://github.com/DarkFlippers/unleashed-firmware)
|
||||
- [Wii EC Analyzer](https://github.com/csBlueChip/FlipperZero_WiiEC)
|
||||
|
||||
|
||||
## Music
|
||||
- [BPM Tapper (By panki27)](https://github.com/panki27/bpm-tapper)
|
||||
- [Metronome](https://github.com/panki27/Metronome)
|
||||
- [Morse Code](https://github.com/DarkFlippers/unleashed-firmware/pull/144)
|
||||
- Music Beeper - Author Unknown
|
||||
- [Music Player](https://github.com/flipperdevices/flipperzero-firmware/pull/1189)
|
||||
- [Ocarina](https://github.com/invalidna-me/flipperzero-ocarina)
|
||||
- [Software Automatic Mouth aka SAM](https://github.com/ctoth/SAM)
|
||||
- [Tuning Fork](https://github.com/besya/flipperzero-tuning-fork)
|
||||
- [Music Tracker](https://github.com/DrZlo13/flipper-zero-music-tracker)
|
||||
|
||||
|
||||
## Tools
|
||||
- [Bluetooth Remote](https://github.com/flipperdevices/flipperzero-firmware/pull/1330)
|
||||
- [Clock](https://github.com/kowalski7cc/flipperzero-firmware/tree/clock-v1) / In house
|
||||
- [Countdown Timer](https://github.com/0w0mewo/fpz_cntdown_timer)
|
||||
- [DAP Link](https://github.com/flipperdevices/flipperzero-firmware/pull/1897)
|
||||
- [DTMF](https://github.com/litui/dtmf_dolphin)
|
||||
- [Dolphin Backup & Restore](https://github.com/flipperdevices/flipperzero-firmware/pull/1384)
|
||||
- [iButton Fuzzer](https://github.com/DarkFlippers/unleashed-firmware)
|
||||
- [NFC Magic](https://github.com/flipperdevices/flipperzero-firmware/pull/1966)
|
||||
- [POCSAG Pager](https://github.com/xMasterX/flipper-pager)
|
||||
- [Password Generator](https://github.com/anakod/flipper_passgen)
|
||||
- [PicoPass](https://github.com/flipperdevices/flipperzero-firmware/pull/1366)
|
||||
- [RFID Fuzzer](https://github.com/RogueMaster/flipperzero-firmware-wPlugins/pull/245)
|
||||
- [Spectrum Analyzer](https://github.com/jolcese/flipperzero-firmware/tree/spectrum/applications/spectrum_analyzer)
|
||||
- [Sub-Ghz Bruteforce](https://github.com/derskythe/flipperzero-subbrute/tree/master)
|
||||
- [Sub-Ghz Playlist](https://github.com/darmiel/flipper-playlist)
|
||||
- [Protocol Visualizer](https://github.com/antirez/protoview)
|
||||
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user