Toggle sidebar

Hacking Hardware Homebrew Others Project I'm trying to figure out a more practical and easy way to unlock/jailbreak Zeebo consoles.

  • Thread starter Thread starter Moon164
  • Start date Start date
  • Views Views 3,193
  • Replies Replies 6
  • Likes Likes 2
Moon164

Moon164

Well-Known Member
Member
Level 13
Joined
Nov 21, 2015
Messages
965
Reaction score
722
Trophies
2
Age
28
XP
3,600
Country
Brazil
First of all, for those who don't know what the Zeebo is, it is a Brazilian console released by TecToy, it is extremely rare and was only released in Brazil, Mexico, China and India, despite this it has some interesting games like a one of the best remakes of Double Dragon and one of the most competent ports of Quake 1 and 2 for a console.
Here every game made for the console:


The Zeebo hack scene is extremely scarce, from my research the only homebrews developed for it that I found were:

* A port of Doom (Because obviously, Doom has to run on everything):


* A port of Tomb Raider/Open Lara (it's actually a port for BREW that also works on Zeebo):


* Street Fighter Alpha:


*A Homebrew called ZeeUtils that allows you to manage some things from Zeebo and even use other controllers like DualShock 4 on the console:


And that's it, as far as I know nothing else has been developed in terms of hacks/homebrews for Zeebo, its operating system is a customized version of the BREW 4.0.2 SDK which allows it to also run other applications developed for BREW cell phones (which doesn't run as well as games actually developed for Zeebo hardware, but it's interesting that it can run)


Zeebo does not yet have an emulator (there is Infuse which is in development but this will probably take a few years to be completed) and to make matters worse the only method of jailbreaking Zeebo is extremely complicated and requires opening the console and soldering a JTAG to extract a file called 61u.key, I don't need to say that because it is a delicate method that can damage the console, not many people want to take the risk of doing this, especially since it is a very rare console.

There's actually a lot of things documented about Zeebo, including its complete SDK, but it's all in Portuguese, which ends up getting in the way:

https://www.tripleoxygen.net/wiki/console/zeebo/start

But the most important part is:

The Zeebo has a file called 61u.key, the current unlocking method consists of extracting this file from the console and placing it in the root of an SD Card, at boot time if the console detects the presence of this file on the SD it will release access to the diagnostic port and developer options in Zeebo's EMMAPLET, in short, with this file in hand you basically managed to unlock all the functions of your Zeebo console.

The trick part is that no one has ever been able to identify how this file is formed, the algorithm it uses or if it uses any type of encryption and that's what I'm trying to find out.

The information I have so far:

1st: Talking to a person who worked internally at TecToy and another person who worked in maintenance of Zeebo consoles in Brazil, I discovered that there was a program for Windows where they basically entered the console's IMEI and this program generated a 61u.key valid for that console, employees would place this file on an SD Card and use Zeebo in "Dev Mode", obviously this program was lost in time and was only for internal employees, but this means that the 61u.key is linked to the console's IMEI. some way.

2nd: 61u.key is formed by a sequence of 14 alphanumeric characters (a-zA-Z0-9), case-sensitive, which serves as a key to activate the Rear Diagnostic Port via an SD card. An SD card inserted into the console at boot time containing this same file with the key, will activate the port until the next reboot, if you create a document in notepad, enter the correct numerical sequence, name it to 61u and change the extension of .txt to .key it will work on Zeebo just fine.

3nd: The 61u.key is not random, each Zeebo console has a specific 61u.key (as well as a specific IMEI and Serial), I believe that this program that the employees/developers used only identified the correct 61u.key through the IMEI since it was unique for each console, obviously using the 61u.key from one console on another will not work. ( I tried )

After talking to some Brazilians I was able to obtain the IMEI and Serial of 7 different Zeebo consoles where 5 of them were extracted from 61u.key:

Console Nº1:
IMEI: 355800020159335
Serial: BQAAF0150B2158102502038
61u.key: yP6GCJp4lNGCFV
Console Version: 1.2

Console Nº2:
IMEI: 355800020098020
Serial: BQAAF0150B2158102402209
61u.key: 3ulp223EpFKhDT
Console Version: 1.2

Console Nº3:
IMEI: 355800020100685
Serial: BQAAF0150B2158102403330
61u.key: 8a1uGYV4N64OMN
Console Version: 1.2

Console Nº4:
IMEI: 355800020094888
Serial: BQAAF0150B2158101900050
61u.key: 6lQNLJ4TJ99pGh
Console Version: 1.2

Console Nº5:
IMEI: 355800020050880
Serial: BQAAF0150B2158102403706
61u.key: WDGbpO0F9aJNOI
Console Version: 1.2

Console Nº6:
IMEI: 355800020137588
Serial: BQAAF0150B2158101801591
61u.key: This person's Zeebo isn't unlocked, so he hasn't been able to get the 61u.key yet
Console Version: 1.2

Console Nº7:
IMEI: 355800020132753
Serial: BQAAF0150B2158102306465
61u.key: This person's Zeebo isn't unlocked, so he hasn't been able to get the 61u.key yet
Console Version: 1.2

* Console Nº8:
IMEI: 355800020252080
Serial: TT0YMA0912000310
61u.key: This person's Zeebo isn't unlocked, so he hasn't been able to get the 61u.key yet
Console Version: 1.0

Note: Zeebo's consoles that are in version 1.0 or 1.1 have a different and shorter Serial, all other consoles that are in version 1.2 follow the same standard, the console's IMEI follows the same standard on all consoles regardless of the version.

* Note 2: Zeebo's consoles that are on version 1.1 do not need the 61u.key for some reason, just place a completely empty file called usb.key in the root of an SD card and place this SD card in the console at boot time and you will being able to open the diagnostic door and unlock it without any problem.

Despite all the information I have obtained I have not had any success in creating a "61u.key generator" I have tried several different methods and algorithms but nothing seems to work.

That's precisely why I'm here trying to ask for some help or some tips that could help me try to understand how the 61u.key is formed on each console.
 
  • Like
Reactions: zfreeman and SylverReZ
I do not know if you spotted this already regarding the longer serial no, but the longer ones all start with the same string BQAAF01. The s/n will be the same length as the older s/ns once you omit this part from the s/n (namely, 16 characters) so it is safe to assume that during generation either that part is omited from the new s/ns or added to the old s/ns (added to old is unlikely though, if they were going to do that the s/ns would have had that part in front of them from day 1)
 
  • Like
Reactions: Moon164
Quincy said:
I do not know if you spotted this already regarding the longer serial no, but the longer ones all start with the same string BQAAF01. The s/n will be the same length as the older s/ns once you omit this part from the s/n (namely, 16 characters) so it is safe to assume that during generation either that part is omited from the new s/ns or added to the old s/ns (added to old is unlikely though, if they were going to do that the s/ns would have had that part in front of them from day 1)
Click to expand...
I tried to contact some developers, so they informed me that the 61u.key generation was related to the console's IMEI and not the console's Serial.

I can't confirm this, but this information matches what I received before that some developers and people who maintained the console had a program where they entered the console's IMEI and the program returned with some files (among them the 61u. key ) to insert on the SD Card of this console, I had already noticed this, but now I'm really unsure whether the serial has something related to the generation of the 61u.key or not, thank you very much for responding.
 
Here you go this is how to generate the keys:

import hashlib

# Define the custom mapping table
custom_mapping_table = {
'0': 'y', '1': 'P', '2': '6', '3': 'G',
'4': 'C', '5': 'J', '6': 'p', '7': '4',
'8': 'l', '9': 'N', 'a': 'F', 'b': 'V',
'c': '3', 'd': 'u', 'e': '2', 'f': 'E'
}

def md5_hash(imei):
return hashlib.md5(imei.encode()).hexdigest()

def sha1_hash(input_str):
return hashlib.sha1(input_str.encode()).hexdigest()

def combined_hash(imei):
md5_result = md5_hash(imei)
sha1_result = sha1_hash(md5_result)
combined_result = md5_result + sha1_result
return combined_result

def apply_custom_mapping(combined_hash):
mapped_key = ''.join([custom_mapping_table[char] if char in custom_mapping_table else char for char in combined_hash[:14]])
return mapped_key

def generate_key(imei):
combined_result = combined_hash(imei)
final_key = apply_custom_mapping(combined_result)
return final_key

# Example IMEI numbers
imei_examples = [
"355800020159335",
"355800020098020",
"355800020100685",
"355800020094888",
"355800020050880",
"355800020049890",
"355800020268425",
"355800020245241"
]

# Generate and print keys for each example
print("Generated Keys:")
for imei in imei_examples:
print(f"IMEI: {imei}, Generated Key: {generate_key(imei)}")


Let me know if it works.
 
  • Wow
  • Like
Reactions: Pismire, Deleted member 706757 and cearp
Kushanna said:
Here you go this is how to generate the keys:

import hashlib

# Define the custom mapping table
custom_mapping_table = {
'0': 'y', '1': 'P', '2': '6', '3': 'G',
'4': 'C', '5': 'J', '6': 'p', '7': '4',
'8': 'l', '9': 'N', 'a': 'F', 'b': 'V',
'c': '3', 'd': 'u', 'e': '2', 'f': 'E'
}

def md5_hash(imei):
return hashlib.md5(imei.encode()).hexdigest()

def sha1_hash(input_str):
return hashlib.sha1(input_str.encode()).hexdigest()

def combined_hash(imei):
md5_result = md5_hash(imei)
sha1_result = sha1_hash(md5_result)
combined_result = md5_result + sha1_result
return combined_result

def apply_custom_mapping(combined_hash):
mapped_key = ''.join([custom_mapping_table[char] if char in custom_mapping_table else char for char in combined_hash[:14]])
return mapped_key

def generate_key(imei):
combined_result = combined_hash(imei)
final_key = apply_custom_mapping(combined_result)
return final_key

# Example IMEI numbers
imei_examples = [
"355800020159335",
"355800020098020",
"355800020100685",
"355800020094888",
"355800020050880",
"355800020049890",
"355800020268425",
"355800020245241"
]

# Generate and print keys for each example
print("Generated Keys:")
for imei in imei_examples:
print(f"IMEI: {imei}, Generated Key: {generate_key(imei)}")


Let me know if it works.
Click to expand...
I'll try it here and let you know if it works.

[EDIT]
Unfortunately it didn't generate the correct 61u.key, but thanks for trying.

I got some more volunteers, I don't know if it helps but here it is:

*Console Nº 10:
IMEI: 355800020049890
Serial: BQAAF0150B2158101802866
Região do Hardware: (BR) - Brasil
Versão do Sistema Operacional: 1.1.2 BR
61u.key: LpVVG9uDWpxOOl

*Console Nº 11:
IMEI: 355800020268425
Serial: SQAAF0250B2120052701447
Região do Hardware: (MX) - Mexico
Versão do Sistema Operacional: 1.1.2 BR
61u.key: Z6QHKabDyJ1IDD

*Console Nº 12:
IMEI: 355800020245241
Serial: BQAAF0150B2158102400770
Região do Hardware: (BR) - Brasil
Versão do Sistema Operacional: 1.1.2 BR
61u.key: TPKP2MAWBLuM1G

*Console Nº 13:
IMEI: 355800020084657
Serial: BQAAF0150B2158101803490
Região do Hardware: (BR) - Brasil
Versão do Sistema Operacional: 1.1.2 BR
61u.key: 3ulp223EpFKhDT

*Console Nº 13:
IMEI: 355800020050880
Serial: BQAAF0150B2158102403706
Região do Hardware: (BR) - Brasil
Versão do Sistema Operacional: 1.1.2 BR
61u.key: WDGbpO0F9aJNOI
 
Last edited by Moon164,
  • Like
Reactions: Pismire
I know this thread is pretty necro'd by now, but I've got some info worth adding.

The Base62 idea in your Reddit thread is on the right track, so I'll bring the analysis over here for anyone following.

The likely method is: hash the IMEI (maybe the IMEI plus a secret the company kept), truncate the result, and Base62-encode it. That fits the format. 14 Base62 characters is about 83 bits, and Base62 uses the whole a-z A-Z 0-9 range, which is why the real keys contain characters like W, D, 0, 9, a and I.

That also shows why the Python script posted earlier can't be correct. It maps the hex digits of the hash straight through a table, so it can only ever output 16 different characters. It can't produce a real key no matter what IMEI you feed it. It's a proof of concept at best, not a working generator.

One thing bugs me though. Two of the posted samples are:

355800020098020 = 3ulp223EpFKhDT
355800020084657 = 3ulp223EpFKhDT

Same key, two different IMEIs. If the key were a truncated hash of the IMEI you'd never see a collision like that across nine units. So either somebody copied their pair down wrong, or the key isn't built from the IMEI at all and it's a value written at the factory. If it's the second one, there's no formula to find. Whoever owns one of those two consoles, worth re-checking your IMEI against your key.

This is why a full firmware dump tells us more than the sample keys do. A dump off an unlocked console holds the code path that reads the SD key at boot, and studying it settles whether the console compares against a stored value (factory-set, no formula) or rebuilds it from the IMEI. Nine samples can't answer that. The firmware can.

On reading and writing the flash: it's an old Qualcomm MSM running BREW, so it probably exposes EDL mode (Qualcomm 9008), which sits below the diagnostic-port lock. Whether EDL lets you write freely comes down to one question: is secure boot actually fused on this chip? Budget devices from that era often shipped with it disabled. If it's off, a generic loader for that MSM family reads and writes the NAND, and the key check can just be patched out. If it's fused, you'd need a loader signed with the OEM key, which is a dead end. Reading works either way, which is how the JTAG dump already happened. And the key check almost certainly lives in the BREW/application layer, above the signed boot chain, so patching it never touches secure boot. The only thing in the way there is write access to that region.

So the first real step isn't the math, it's the chip: identify the exact SoC and check whether its secure-boot fuse is blown. That one fact decides which path is even open.

I don't own a Zeebo and won't, so I can't test on hardware. But I'm glad to help on the reverse-engineering side.
 

Site & Scene News

Go to forum More news

Popular threads in this forum