SamloaderKotlin
SamloaderKotlin copied to clipboard
Samsung is now requiring matching IMEIs or serial numbers to download firmware
In order to download firmware from Samsung's servers, an IMEI or serial number that matches the given model needs to be provided.
This issue is for discussing workarounds and approaches to retrieving firmware in light of the new requirement.
Posting here just for reference.
Using this model: SM-A346M and this CSC: TPA I get this error:
"Bad return status: toIndex(62) is greater than size (32)"
Trying a couple of hours later I get a 401 error so I guess it is probably related to this? I was going to open a new issue before I saw the 401.
EDIT: using a service like https://samfw.com/firmware/SM-A346M/TPA/A346MUBU4BWK2 that probably gets the same url does work.
For SM-A336B EUX I also get toIndex (62) is greater than size (32)
With several versions:
- A336BXXU7DWK6/A336BOXM7DWK6/A336BXXU7DWK6/A336BXXU7DWK6
- A336BXXS7CWJ1/A336BOXM7CWH2/A336BXXS7CWJ1/A336BXXS7CWJ1 (55 is greater than size 32)
- A336BXXU7CWH2/A336BOXM7CWH2/A336BXXU7CWH2/A336BXXU7CWH2 (index 3 out of bounds for length 3)
Someone who's better at reverse engineering Windows apps than I am will need to find the new method in Smart Switch. I have a feeling it's not only the key that's changed.
The release notes for v0.1.8 of samfusdl say they now require the IMEI for devices with a modem or the Serial Number for the rest. In addition, the Model and Region must match-up with the IMEI/SN.
The release notes for v0.1.8 of samfusdl say they now require the IMEI for devices with a modem or the Serial Number for the rest. In addition, the Model and Region must match-up with the IMEI/SN.
(I'm the author of the linked project)
Yep, that seems to be the case unfortunately. I posted more details in a comment here: https://github.com/ivanmeler/SamFirm_Reborn/issues/15#issuecomment-1865275436
I've had no luck in bypassing the IMEI/serial number check. Spoofing old client versions doesn't seem to work. I'm guessing older versions of the official Smart Switch client don't work anymore either.
I'm nowhere near good enough at reverse engineering assembly to find the new keys myself, so I unfortunately can't test or play around with values.
The release notes for v0.1.8 of samfusdl say they now require the IMEI for devices with a modem or the Serial Number for the rest. In addition, the Model and Region must match-up with the IMEI/SN.
(I'm the author of the linked project)
Yep, that seems to be the case unfortunately. I posted more details in a comment here: ivanmeler/SamFirm_Reborn#15 (comment)
I've had no luck in bypassing the IMEI/serial number check. Spoofing old client versions doesn't seem to work. I'm guessing older versions of the official Smart Switch client don't work anymore either.
I have a good imei database of samsung, can I help?
I'm nowhere near good enough at reverse engineering assembly to find the new keys myself, so I unfortunately can't test or play around with values.
Please see https://github.com/ivanmeler/SamFirm_Reborn/issues/15#issuecomment-1865439788. I posted a script to extract the keys from publicly downloadable sources.
I don't know how long this will last, but setting the IMEI to 12345678901234 lets me download arbitrary combos.
I don't know how long this will last, but setting the IMEI to
12345678901234lets me download arbitrary combos.
Interesting. That works for me too--even for devices without a modem where a serial number would normally be needed.
It's strange because it's neither an IMEI nor a serial number length, but lengths longer than 15 and shorter than 11 don't work. Maybe someone left a test value in the logic.
I bet you're right. Variations of that, like 12345678901235, return the 408 error, but 00000000000000 works. Definitely feels like some hardcoded test values.
you are right, hope they don't remove this test value
I bet you're right. Variations of that, like
12345678901235, return the 408 error, but00000000000000works. Definitely feels like some hardcoded test values.
00000000000000 imei is a common thing on LDU, phones that have modems unsynced with bootloaders, or even phones with EFS corrupted, so this particular imei might last
I bet you're right. Variations of that, like
12345678901235, return the 408 error, but00000000000000works. Definitely feels like some hardcoded test values.00000000000000 imei is a common thing on LDU, phones that have modems unsynced with bootloaders, or even phones with EFS corrupted, so this particular imei might last
FIXED MAYBE
The test values don't work anymore. It looks like you only need a serial number, though, even for devices with an IMEI, and it looks like you might only need a matching model now. I can download U and U1 firmware on any US CSC for my S23 Ultra using my serial.
It looks like there's an input size limit of 150 on the IMEI field. Going over that causes error 400 instead of 408. I'm not sure if we can use that for anything, but it might come in handy.
Would be funny if we could grab a list of TACs from swappa or other gsm dbs and generate randomized imeis according to selected device.
I tried last week some of the imeis from swappa and could download Fold 4 fw, so they were legit for sammy servers.
LE: Not sure how legal this becomes, but might be a nasty workaround...
I don't think there are any legal problems here since the IMEI isn't being used to register a device on a network.
Some thoughts on generating IMEIs:
- It looks like only the TAC and RBI matter. 35-764412-123456-5 (without dashes) lets me download for SM-S918U1.
123456is the part that would theoretically be unique to a device., and can be any 6 digit string.35is the RBI code used for devices in most of the world, although I have seen25, which doesn't seem to actually exist. China uses86.764412means "Galaxy S23 Ultra U/U1". I'm not sure how Samsung is generating this number. Small variations like765412or764413don't work.- The S22 Ultra U/U1 TAC seems to be
579646. - The last digit of the IMEI is the check digit, which is pretty easy to calculate: https://simplycalc.com/luhn-source.php, https://www.imei.info/calc.
- Swappa has a TAC index: https://swappa.com/imei/tac.
- Swappa has a TAC index: https://swappa.com/imei/tac.
Yeah, seen that, but it's neither something you can call to fetch a imei at download request, nor a list you can integrate as a db inside the app...
There is this, but the models are listed by marketing name instead of actual model name: http://tacdb.osmocom.org/
We might have a way in with 123456789012347. Instead of 408, this returns 400 with the current arguments.
I downloaded the database from osmocom.org, filtered it to only Samsung, and added a couple models of my own: https://github.com/zacharee/SamloaderKotlin/blob/master/common/src/commonMain/resources/MR/files/tacs.csv.
I think this might be the best way forward. If people are willing to contribute the TAC for their devices, we can probably grow it pretty quickly. It's easy enough to google "[MODEL] IMEI" and get results from Swappa, but it's also really tedious.
#128 I've made a PR to add some TACs for my devices
I made it so 1.16.7 will fetch the tacs.csv file directly from GitHub if it can so I'm not just releasing updates with new TACs.
I also nabbed a couple TACs from @BlackMesa123's commits.
The last part is the tricky part: none of this helps devices without a radio. There is a bit of a system for how Samsung's serial numbers work, but I can't find any documentation on how the last 6 digits should be generated based on the first 5, and randomly playing around with the letters hasn't worked out. We might need a serials.csv file with full serial numbers in it, which doesn't seem great.
I would like to add that I found a couple of TAC(s) which doesn't work with every combination but I had to make a few tries before getting a working one. This happened with a recent TAC but I don't know if this is an issue
I've renamed and edited this issue to describe what it's turned into, since the discussion moved away from the original issue, and there weren't any posts specifically about it.
Hmm just TAC might not be enough.
For my device model/region it looks like TAC + [1 or 2] + 5 digits + luhn code is accepted, anything outside (0 or 3+) fails -- so they also have a range in there.
The model is also listed with other TAC prefixes in https://github.com/zacharee/SamloaderKotlin/issues/130 and I've tried some at random but nothing seems to get through in other ranges (I only tried a couple), so it's probably region locked or something.
I guess we're going to need a different format (model+region => valid prefixes?), with prefixes potentially more specific than TAC, and a lot of manual work updating it...
There is a strange think for SM-X516B:
It has 2 TAC because it is dual SIM but any generated IMEI doesn't work expect this two ones: 354136920920257 (TAC SIM 1) 354171670920256 (TAC eSIM slot)
Do you have ideas
I assume you're respecting the parity digit when you generate IMEI? ( https://simplycalc.com/luhn-calculate.php if guessing manually) samsung servers will reject anything that doesn't match.
(I'd try but no idea what region you're using, getting 403 errors with the few I tried)