Hacking Hardware Picofly - a HWFLY switch modchip

[saladus]

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]

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]

*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]

*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]

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]

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]

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]

*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.

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?

 

[chappo]

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

 

[ghjfdtg]

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]

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]

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]

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]

do you have the site where to buy pikofly?

 

[linuxares]

do you have the site where to buy pikofly?

It doesn't exist

 

[SylverReZ]

do you have the site where to buy pikofly?

Pikofly is not a product

 

[FruithatMods]

Pikofly is not a product

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

 

[SylverReZ]

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]

Please stop repeating this as it is misinformation.

Sir, this is GBATemp

 

[binkinator]

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

Spoiler: Install a MSYS environment

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:

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:

Spoiler: Manual version of LibUSB

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:

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:

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

ld
Result:

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

make
Result:

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

mingw32-make
Result:

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

echo $PICO_SDK_PATH
Result:

/home/<YOURUSER>/pico-sdk

and now you are ready to start the building process:

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.

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:

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:

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...

$ ./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/