RE: Point-of-Sale Activation 03-09-2018, 04:39 PM
#86
From my deconstruction of the FYDiSaUI installer apk bcrypt or some variant of the blowfish cypher was used to hash the PIN of each device. There are a few mentions of it in the gibberish of opening up the main files in a text editor. bcrypt specifically. When Intel was involved in the construction of the hardware you could spot the hash by eye because it repeated a specific set of 32 characters over and over again. You then just ran it through https://crackstation.net/ and you had your PIN.
Since they started using ARM64 processors and FYDiSaUI they changed up the entire thing. This is as of winter of 2017.
There is no reason to pick the lock anymore, though. I gave very good instructions on jiggling the door handle and walking right through without the lock mattering. After some more tests it turns out that VUDU is tied into the entire security package as well somehow. I'm not sure exactly what that's about but VUDU is all over the new UI code and inside the installer package is an entire folder dedicated to activating your VUDU account. Also if you use my method to simply uninstall the PoSA, VUDU stops working, claiming you rooted your device.
Just use ADB and uninstall the DiSa user interface and GoogleInit will pop right up and your device will be free of that terrible little company's BS. They can't create program updates that stop you from uninstalling any program you know is running from the ADB command line. It is a hack they cannot ever stop you from using.
The only reason Google locks are harder to get through is because Android IS Google and even then there's the google lock apk easily found through, ironically, a Google search.
I was proud when I decrypted my first Nextbook's PIN and activated it, only to immediately do it again to another one for a friend. There was a certain sense of accomplishment, but I believe in removing locks rather than picking them when it comes to security software.
Hopefully some of my knowledge can help you guys decrypt if that's what you want, but believe in the power of Linux and use ADB and the shell command!
EDIT: Noticed someone else was eyeballing the hashes too back before the ARM processors were installed and the whole hardware setup changed. Guess it wasn't that hard of a hack. I am noticing a few repeating characters within the new hashes but no longer the straightforward 32 bit encryption that kept repeating itself so obviously. I'm thinking look for the commonalities between all the strings and take the repeating pieces out and combine them in a 32 bit hash and run it through crackstation maybe?
But bcrypt is mentioned in the install file gibberish and it becomes harder to crack the more effort you put into doing it by design, so I'm guessing it can't be as easy as cutting different pieces out of different strings. This is why I gave up on the decryption activation and just removed the software. Why use all that time and energy figuring out the puzzle when you can remove it altogether with a whole lot less power?
Just my opinion.
Since they started using ARM64 processors and FYDiSaUI they changed up the entire thing. This is as of winter of 2017.
There is no reason to pick the lock anymore, though. I gave very good instructions on jiggling the door handle and walking right through without the lock mattering. After some more tests it turns out that VUDU is tied into the entire security package as well somehow. I'm not sure exactly what that's about but VUDU is all over the new UI code and inside the installer package is an entire folder dedicated to activating your VUDU account. Also if you use my method to simply uninstall the PoSA, VUDU stops working, claiming you rooted your device.
Just use ADB and uninstall the DiSa user interface and GoogleInit will pop right up and your device will be free of that terrible little company's BS. They can't create program updates that stop you from uninstalling any program you know is running from the ADB command line. It is a hack they cannot ever stop you from using.
The only reason Google locks are harder to get through is because Android IS Google and even then there's the google lock apk easily found through, ironically, a Google search.
I was proud when I decrypted my first Nextbook's PIN and activated it, only to immediately do it again to another one for a friend. There was a certain sense of accomplishment, but I believe in removing locks rather than picking them when it comes to security software.
Hopefully some of my knowledge can help you guys decrypt if that's what you want, but believe in the power of Linux and use ADB and the shell command!
EDIT: Noticed someone else was eyeballing the hashes too back before the ARM processors were installed and the whole hardware setup changed. Guess it wasn't that hard of a hack. I am noticing a few repeating characters within the new hashes but no longer the straightforward 32 bit encryption that kept repeating itself so obviously. I'm thinking look for the commonalities between all the strings and take the repeating pieces out and combine them in a 32 bit hash and run it through crackstation maybe?
But bcrypt is mentioned in the install file gibberish and it becomes harder to crack the more effort you put into doing it by design, so I'm guessing it can't be as easy as cutting different pieces out of different strings. This is why I gave up on the decryption activation and just removed the software. Why use all that time and energy figuring out the puzzle when you can remove it altogether with a whole lot less power?
Just my opinion.
(This post was last modified: 03-09-2018, 04:52 PM by chesterbeatdeath.)


![[+]](https://sinister.li/images/modern/collapse_collapsed.png)