-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some detail of RTL8372 firmware & Any progress on reverse engineering the UID algorithm? #4
Comments
Sorry for this late reply. Oddly, rather than github informing me of pending open issues, it was a reply on servethehome.com that got my attention. Anyway, I will allocate time this weekend to take a look at these developments and try to gather any new insight. |
Before I delve into the code, I can confirm that same reset button boot loop is experienced with the SWTG118AS v1.0 and I wrote a little explanation at https://forums.servethehome.com/index.php?threads/horaco-2-5gbe-managed-switch-8-x-2-5gbe-1-10gb-sfp.41571/post-428606 |
@libc0607 @FanFansfan It's AES encryption. The sbox in bytes are at I haven't dug into it just yet but my assumption is |
I can confirm that on the two operational managed switches (ZX-SWTG124AS) the UID starts with: 10 09 3F 30 D4 xx xx xx. |
Maybe he had set the wrong size in the reading script? @FanFansfan Thank you for the flash information. And I've noticed that after reading the UID, it reads the |
Did some timing analysis on the LA captured data, @up-n-atom you're right it's AES-128. It reads the sbox data 10 rounds.
|
Based on the LA capture maybe we can recover the 16-byte block being encrypting. The "step 0" above should be generating the round-key or sth. |
You are right. The log (10s_auth_success_full) only reads 16B (4 x 4Bytes), so there is no more OTP data.
No problem. |
Doing some calculations. Let's assume that the available byte in each flash read is only the first byte. I think the hardware is doing some "pre-fetch" job for 8051 so every read command reads 3 bytes, which is the longest possible instruction length of 8051.
From that we can calculate that the last 4 bytes of the 16-byte key is Assume the key is Using the s-box data read from section 1.0:
So the raw data should be:
It makes no sense, and the error (not matching the logic analyzer value) starts from the second round. Conclusion: The key is less likely just Edit: Went through the draft then I found where I got messed up. As it's my first time play with AES, I decided to try it in paper and pencil then I made a small mistake when calculating the round-key ... should use python instead. (;′⌒`) |
Early lazy assessment by utilizing the key expansion code from https://goggleheadedhacker.com/blog/post/reversing-crypto-functions-aes#key-expansion and proxing the self.RCON and self.SBOX access to print offsets and the value. Passing in SBOX[ DD463 ] = 04
SBOX[ DD463 ] = 04
SBOX[ DD433 ] = 63
SBOX[ DD499 ] = 33
SBOX[ DD4B2 ] = d2
SBOX[ DD468 ] = 96
SBOX[ DD48E ] = 39
SBOX[ DD48A ] = 5b
SBOX[ DD513 ] = e1
SBOX[ DD470 ] = 27
SBOX[ DD49F ] = 50
SBOX[ DD4B5 ] = 13
SBOX[ DD456 ] = 26
SBOX[ DD439 ] = 6f
SBOX[ DD4A8 ] = 9d
SBOX[ DD4E9 ] = 4e
SBOX[ DD492 ] = cf
SBOX[ DD4E0 ] = 95
SBOX[ DD481 ] = 2f
SBOX[ DD47B ] = 52
SBOX[ DD51D ] = 87
SBOX[ DD44D ] = a2
SBOX[ DD43C ] = 01
SBOX[ DD4BB ] = c4
SBOX[ DD475 ] = 2c
SBOX[ DD46F ] = eb
SBOX[ DD4DB ] = c2
SBOX[ DD458 ] = 3f
SBOX[ DD4FB ] = e8
SBOX[ DD4F7 ] = 1c
SBOX[ DD47D ] = d6
SBOX[ DD50D ] = 57
SBOX[ DD476 ] = 1a
SBOX[ DD4AE ] = 21
SBOX[ DD44C ] = d4
SBOX[ DD453 ] = b7
SBOX[ DD4FE ] = 1f
SBOX[ DD501 ] = 8b
SBOX[ DD4F1 ] = ae
SBOX[ DD4BC ] = a7 I will do the same for the cipher later. |
let me reword that because it was an implementation error take the 4 byte unique id as a lower case hex string and concat it to itself enc.py from Cryptodome.Cipher import AES
uid = b'10093f30' # lowercase 32bit hex string sliced from the 128bit unique id - read 4Bh
key = b'59494F4754fff00\0' # hardcoded in the flash at DD55Fh or update at C4418h
pt = uid + uid # plaintext concat uid for 128bits
cipher = AES.new(key, AES.MODE_ECB)
otp = cipher.encrypt(pt) # returns the otp bytes
print(otp[:8].hex()) python -m venv .venv
source .venv/bin/activate
python3 -m pip install pycryptodomex
python3 enc.py output 572dad0d4ff6c745 |
Good work |
Amazing, now we know all the details of the crab firmware! Thanks for your great work!
Ahh that's the combination I never wanted to try 😂It must be a bug wrote by Realtek 😂😂 |
I generated my own (for a different UID) OTG and uploaded it to the flash drive. |
Hi.
A week ago, @FanFansfan and I started some exploration on some RTL8372 firmware, and I found your repo yesterday. See our discussion (mainly) here and here (a little bit) (sry for zh-cn, pls use translate).
In short:
I don't know if it's worth spending time on reverse engineering the algorithm. Making an FPGA MITM module on the SPI bus may better than that.
Any suggestions? And, is there someone experienced on 8051 RE watching here?
The text was updated successfully, but these errors were encountered: