Hacking Hardware Picofly - a HWFLY switch modchip

saladus · Jan 28, 2023

TheSynthax said:
No, no reason to unless you have something you don't want reverse engineered. The first stage is part of the Chinese firmware, it's just there to make it hard to understand what it's doing. It handles that decryption step.

I'm sorry i think i might have misunderstood

. i thought we were talking about bootloaders when talking about the first and second stage

ByteFun · Jan 28, 2023

The first thing the startup code does is initialize the hardware, copy the contents of flash memory into RAM, and start the main function. We get the identifier of the flash memory. The chip voltage rises and the clock frequency rises to 333 MHz. In this mode, we can no longer work with flash memory. Perhaps the decryption algorithm expands the flash ID as a key into block 0x100, but perhaps this is the context for the decryptor.

ghjfdtg · Jan 28, 2023

*sigh* i hate how people pretend this is some unbreakable protection. Read the following thread starting here. You will see how few unique bytes this flash id really has. Easy to bruteforce:
https://forums.raspberrypi.com/viewtopic.php?f=144&t=300338&p=1811696#p1811489

ByteFun · Jan 28, 2023

ghjfdtg said:
*sigh* i hate how people pretend this is some unbreakable protection. Read the following thread starting here. You will see how few unique bytes this flash id really has. Easy to bruteforce:
https://forums.raspberrypi.com/viewtopic.php?f=144&t=300338&p=1811696#p1811489

It's not a problem to brute force the ID. The ID is already there. Problem with decryption algorithm. Is it a standard, known algorithm or proprietary?

TheSynthax · Jan 28, 2023

ByteFun said:
It's not a problem to brute force the ID. The ID is already there. Problem with decryption algorithm. Is it a standard, known algorithm or proprietary?

it's blowfish-448

ByteFun · Jan 28, 2023

TheSynthax said:
it's blowfish-448

Are you sure? I haven't compared yet. Where are such conclusions from? I'm just wondering how you came to this.

TheSynthax · Jan 28, 2023

ByteFun said:
Are you sure? I haven't compared yet. Where are such conclusions from? I'm just wondering how you came to this.

binwalk

There's a blowfish-256 section as well. Here's the raw output:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
317964        0x4DA0C         mcrypt 2.2 encrypted data, algorithm: blowfish-256, mode: CBC, keymode: 4bit
317971        0x4DA13         mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit

binkinator · Jan 28, 2023

ghjfdtg said:
*sigh* i hate how people pretend this is some unbreakable protection. Read the following thread starting here. You will see how few unique bytes this flash id really has. Easy to bruteforce:
https://forums.raspberrypi.com/viewtopic.php?f=144&t=300338&p=1811696#p1811489

from the article they state that the IDs have a pattern to them:

E6 60 08 10 07 30 75 31
E6 60 58 38 83 3E BB 38
E6 60 58 38 83 6D AF 39
E6 60 58 38 83 94 9D 38

from this thread we already have:

E6 61 60 F4 23 15 3A 37
E6 61 41 03 E7 28 91 24

It looks like they’ve already incremented the second byte by one and I expect that the initial E6 will change once they’ve exhausted the second byte, so I think all 64 bits are fair game here.

vittorio said:
Can share the fw

Post automatically merged: Jan 28, 2023

someone send me an id of a rp2040

Are you saying you (or SWIM) can re-encrypt the FW based on a new ID?

evil_santa · Jan 28, 2023

I don't know if it's useful but I found a binwalk alternative.
https://github.com/onekey-sec/unblob

ghjfdtg · Jan 28, 2023

Didn't look for the JEDEC standard describing these IDs (paywalled) but it's likely 32 bits serial number and everything else is manufacturer id and production date. Not very random at all.

vittorio · Jan 28, 2023

I'm looking at how to do it, we probably have to decrypt it on the raspberry of the guy who dumped the fw

FruithatMods · Jan 28, 2023

TheSynthax said:
No, no reason to unless you have something you don't want reverse engineered. The first stage is part of the Chinese firmware, it's just there to make it hard to understand what it's doing. It handles that decryption step.

There is no such thing as a Chinese firmware because the firmware wasn't developed by anyone in China.

Someone from gbatemp mistranslated a post from a foreign site that was calling the waveshare pi pico boards the "chinese boards" because the blank pcb boards are made in China.

Please stop repeating this as it is misinformation.

TheSynthax · Jan 28, 2023

vittorio said:
I'm looking at how to do it, we probably have to decrypt it on the raspberry of the guy who dumped the fw

the flash ID of that Pico would be sufficient for decryption.

vittorio · Jan 28, 2023

do you have the site where to buy pikofly?

linuxares · Jan 28, 2023

vittorio said:
do you have the site where to buy pikofly?

It doesn't exist

SylverReZ · Jan 28, 2023

vittorio said:
do you have the site where to buy pikofly?

Pikofly is not a product

FruithatMods · Jan 28, 2023

M4x1mumReZ said:
Pikofly is not a product

So why are there multiple photos and videos floating around of the chip in operation?

SylverReZ · Jan 28, 2023

FruithatMods said:
So why are there multiple photos and videos floating around of the chip in operation?

I'm referring to the fact that Pikofly is not a mass produced product if that makes sense. I am aware of the videos and images released.

CompSciOrBust · Jan 28, 2023

FruithatMods said:
Please stop repeating this as it is misinformation.

Sir, this is GBATemp

binkinator · Jan 28, 2023

impeeza said:
If someone is interested on the Pico related boards, a must have tool is the PicoTool (https://github.com/raspberrypi/picotool) but the tool needs compilation to use.

The instructions on page are a bit dry. I found another set of instructions on https://shawnhymel.com/2168/how-to-build-openocd-and-picotool-for-the-raspberry-pi-pico-on-windows/ but they are a little bit scrambled and have unnecessary steps.

Here are the steps I did use to build PicoTool from source using MSYS MinGW:

First you need

Download the latest version from: https://github.com/msys2/msys2-installer/releases

Install the version corresponding to your Operating System (64 or 32 bits).

Accept the defaults in installation program of MSYS2 once you finish the installation you will have shortcuts for MSYS2, MinGW32 and MinGW64. MSYS2 is used to compiling POSIX binaries for Linux from Windows.

MinGW32 & MinGW64 compile Native Windows binaries using a linux toolchain (gcc, bash, etc.)

Launch MSYS2 shell and execute the command: pacman -Syuu several times until you get the message: "there is nothing to do".

After you have a MSYS environment set up you need to Install Build prerequisites following these steps:

Bash:

pacman -Syu --noconfirm pacman -Su --noconfirm pacman -S --noconfirm git make libtool pkg-config autoconf automake texinfo wget mingw-w64-x86_64-toolchain mingw-w64-x86_64-gcc mingw-w64-x86_64-cmake mingw-w64-x86_64-python mingw-w64-x86_64-libusb

Seems what was upon a time when the libusb of Mingw had a error and you need to install an old version, that can be acomplished using:

Bash:

cd ~ wget https://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-libusb-1.0.26-1-any.pkg.tar.zst pacman -U --noconfirm https://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-libusb-1.0.26-1-any.pkg.tar.zst

Then you need to setup the Pico-SDK and the Pico-Examples needed to successfull compile:

Bash:

cd ~ git clone -b master https://github.com/raspberrypi/pico-sdk.git cd pico-sdk git submodule update --init cd .. git clone -b master https://github.com/raspberrypi/pico-examples.git export PICO_SDK_PATH=~/pico-sdk

You can be sure all is setup to go running these commands:
gcc
Result:

Bash:

gcc.exe: fatal error: no input files compilation terminated.

ld
Result:

Bash:

C:\msys64\mingw64\bin\ld.exe: no input files

make
Result:

Bash:

make: *** No targets specified and no makefile found. Stop.

mingw32-make
Result:

Bash:

mingw32-make: *** No targets specified and no makefile found. Stop.

echo $PICO_SDK_PATH
Result:

Bash:

/home/<YOURUSER>/pico-sdk

and now you are ready to start the building process:

Bash:

cd ~ git clone -b master https://github.com/raspberrypi/picotool.git cd picotool mkdir build cd build cmake -G "MSYS Makefiles" -DPC_LIBUSB_INCLUDEDIR="/mingw64/include/libusb-1.0" .. make -j

The last step is to copy the needed external libraries to the same folder of the new build executable, you need to take them with the Exe file if you like to use outside the MSYS environment.

Bash:

cp /mingw64/bin/libusb-1.0.dll . cp /mingw64/bin/libgcc_s_seh-1.dll . cp /mingw64/bin/libstdc++-6.dll . cp /mingw64/bin/libwinpthread-1.dll . ./picotool.exe

Wonderful work as usual, friend!

If anyone gets the following error:

Code:

wwiii@wwiii-VAIO MSYS ~/picotool/build
$ cmake -G "MSYS Makefiles" -DPC_LIBUSB_INCLUDEDIR="/mingw64/include/libusb-1.0" ..
CMake Error: Could not create named generator MSYS Makefiles

Generators
* Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Ninja Multi-Config           = Generates build-<Config>.ninja files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.


wwiii@wwiii-VAIO MSYS ~/picotool/build
$ which cmake
/usr/bin/cmake

wwiii@wwiii-VAIO MSYS ~/picotool/build

It's because regular cmake has priority in your path over the mingw version.

Try this to fix it:

Code:

wwiii@wwiii-VAIO MSYS ~/picotool/build
$ export PATH=/mingw64/bin:$PATH

wwiii@wwiii-VAIO MSYS ~/picotool/build
$ which cmake
/mingw64/bin/cmake

wwiii@wwiii-VAIO MSYS ~/picotool/build
$ cmake -G "MSYS Makefiles" -DPC_LIBUSB_INCLUDEDIR="/mingw64/include/libusb-1.0" ..

e: and if you get the following...

Code:

$ ./picotool.exe info
No accessible RP2040 devices in BOOTSEL mode were found.

but:

Device at bus 2, address 1 appears to be a RP2040 device in BOOTSEL mode, but picotool was unable to connect. You may need to install a driver. See "Getting
    started with Raspberry Pi Pico" for more information

Look here: https://github.com/raspberrypi/picotool/issues/20

https://zadig.akeo.ie/

Hacking Hardware Picofly - a HWFLY switch modchip

Well-Known Member

Member

Well-Known Member

Member

Well-Known Member

Member

Well-Known Member

Garfield’s Fitness Coach

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

The inadequate, autocratic beast!

Dat one with the Rez

Well-Known Member

Dat one with the Rez

🤔

Garfield’s Fitness Coach

Similar threads

Popular threads in this forum