Toggle sidebar

Hacking Hardware Picofly - a HWFLY switch modchip

  • Thread starter Thread starter mathew77
  • Start date Start date
  • Views Views 3,819,364
  • Replies Replies 17,077
  • Likes Likes 15
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.
Click to expand...
I'm sorry i think i might have misunderstood :lol:. i thought we were talking about bootloaders when talking about the first and second stage :lol:
 
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.
 
  • Like
Reactions: FruithatMods, binkinator and saladus
ByteFun said:
Are you sure? I haven't compared yet. Where are such conclusions from? I'm just wondering how you came to this.
Click to expand...
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
 
Last edited by TheSynthax,
  • Like
Reactions: ron2797k, ByteFun, mathew77 and 1 other person
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
Click to expand...

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
Click to expand...

from this thread we already have:

E6 61 60 F4 23 15 3A 37
E6 61 41 03 E7 28 91 24
Click to expand...

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:

someone send me an id of a rp2040
Click to expand...

Are you saying you (or SWIM) can re-encrypt the FW based on a new ID?
 
  • Love
  • Like
Reactions: peteruk and impeeza
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.
Click to expand...

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.
 
  • Like
  • Love
  • Haha
Reactions: mathew77, peteruk, impeeza and 3 others
FruithatMods said:
So why are there multiple photos and videos floating around of the chip in operation?
Click to expand...
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.
 
  • Like
Reactions: impeeza
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
Click to expand...
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

1674923398238.png


https://zadig.akeo.ie/
 
Last edited by binkinator,
  • Love
Reactions: impeeza, marhalloweenvt and SylverReZ

Site & Scene News

Go to forum More news

Popular threads in this forum