Hacking Hardware Picofly - a HWFLY switch modchip

  • Thread starter Thread starter mathew77
  • Start date Start date
  • Views Views 3,671,765
  • Replies Replies 17,052
  • Likes Likes 15
the code is on C, I am not getting there yet.

If somebody likes, this is my code on Arduino:

C-like:
#include "pico/unique_id.h"
String cadena;


void setup() {
  // put your setup code here, to run once:

  Serial.begin(115200);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }
  // send an intro:
  Serial.println("\n\nPico Unique Board ID:");
  Serial.println();
}

void loop() {
  pico_unique_board_id_t board_id;
  pico_get_unique_board_id(&board_id);
  //pico_get_unique_board_id_string;
  cadena = "";
  for (int i = 0; i < PICO_UNIQUE_BOARD_ID_SIZE_BYTES; ++i) {
 //   Serial.write(board_id.id[i]);
    //Serial.write(13);
    //Serial.write(10);
    cadena += board_id.id[i];
  }
  Serial.println(cadena);
  delay(5000);
}

I am using Raspberry Pi Pico/RP2040 https://github.com/earlephilhower/arduino-pico board library on the Arduino IDE, that have the unique_id.h file.
If you use micropython, you can simple run this in Shell (I am using Thorny to communicate with Pico):
Code:
>>> import ubinascii
>>> import machine
>>> ubinascii.hexlify(machine.unique_id())
 
Last edited by marhalloweenvt,
if you can find the payload let's try to decrypt it, theoretically a software hack on the switch is also possible since a webkit exploit has come out, only a kernel exploit is missing
 
Or decrypt existed and remove decryptor from 1st stage.
This is the goal. I mean, you can't just patch one place by changing the ID. But, is it possible to make the get ID function return the same set of bytes? Sounds like a dirty patch, but can work as a temporary security bypass solution ))
Post automatically merged:

The encrypted firmware is located at 1000297C, the decryption magic happens at about 10013622. But I still can't start debugging and the context is missing. SWD disabled, OpenOCD saying "DAP init failed"
 
Last edited by ByteFun,
Well. I successfully connected the debugger. The container is not checked for integrity, but any modification of the firmware will reset the chip into firmware download mode. Perhaps there are some checks during the execution of the firmware. But after doing something, I was able to start debugging and breakpoints also work. Gradually learning microcontrollers))
 
Well. I successfully connected the debugger. The container is not checked for integrity, but any modification of the firmware will reset the chip into firmware download mode. Perhaps there are some checks during the execution of the firmware. But after doing something, I was able to start debugging and breakpoints also work. Gradually learning microcontrollers))
Сan you write to me on 4pda?
 
The amount of new users who just register to dip in on this exact topic is, at least, a little suspicious.
Because the forum is quite popular and the specific topic might be discussed in different languages elsewhere. They join this place to ask\provide some feedback on their findings, no?
 
So is it like actively under development in China with closed source code?
The only thing i can say, it works fine with Mariko (with few exceptions).

I can't say who is bEhind the development, but Right now I wonder is thiS the only Thing they cAn do... ;)
 

Site & Scene News

Popular threads in this forum