Open zacharee opened 10 months ago
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:
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
12345678901234
lets 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, but00000000000000
works. 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, but00000000000000
works. 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:
123456
is the part that would theoretically be unique to a device., and can be any 6 digit string.35
is the RBI code used for devices in most of the world, although I have seen 25
, which doesn't seem to actually exist. China uses 86
.764412
means "Galaxy S23 Ultra U/U1". I'm not sure how Samsung is generating this number. Small variations like 765412
or 764413
don't work. 579646
.
- 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.
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)
If you mean the check digit calculated with Luhn formula then yes. The region I use is EUX
Thanks - I could get it to work with EUX
For 35413692 many don't work indeed... Out of 100 tries, these worked (part after the prefix)
0404047
0460924
0473430
0579509
0635434
0691114
0704982
0734609
0850017
0998709
5411427
5411468
7410385
And plenty of failures all around -- I didn't see a failure in the 0 prefix on these 100 attempts but e.g. 0274804 failed when I tried before properly recording, and conversely some in the 1 range also worked (1048082, 1143164, 1192245 worked but not 1083287...); so it's not a contiguous range... I sure hope they don't actually know exactly what they sold on this server.
I guess whatever we do we'll need some retry logic :/
Hello, I am trying to download the firmware of an sm-g900h but it gives me error 404. I don't know why I am using the imei that is recorded on the back of the device, thank you very much!
sm-g900h
Plenty of old devices (Note 3 , Note 4 S5 and the like) no longer host the FULL latest firmware as a standalone binary, instead they host a Previous / older firmware, and advertise an OTA as the most recent firmware, we can't download OTAs in this manner
G900HXXS1CQD1 is the latest Package, but its not downloadable, G900HXXU1CVHA is advertised as the latest OS, but its an OTA not a full OS package, i faced this issue in my N910C, i could only download 1 version older firmware package that was hosted on external sources, and then OTA updated the phone.
would be nice if someone knows how we can request OTAs
Edit : also wonder how these devices get stock firmwares these days, last i checked smart switch did not support my note 4 or note 5, and i dont think kies works anymore
<firmware>
<model>SM-G900H</model>
<cc>XSG</cc>
<version>
<latest o="6.0.1">G900HXXU1CVHA/G900HOJV1CVH2/G900HXXU1CPCA</latest>
<upgrade>
<value rcount="1" fwsize="27456140">G900HXXS1CQD1/G900HOJV1CQB2/G900HXXU1CPCA</value>
</upgrade>
</version>
</firmware>
Thank you very much for your answer. This device is driving me crazy. The imai and the networks were deleted. I can't get the package that restores everything. greetings!
The ODIN package isn't going to restore your IMEI. Modem info is stored in a persistent partition that never changes.
1.16.8 includes retry logic to loop through a bunch of dummy serials until it finds one that works or runs out. I also made the in-app logic able to compile multiple TACs per model.
It looks like 012345 is a good secondary to 123456, but I added the ones that worked for @martinetd as well. The IMEI field is a bit of a mess with so many generated IMEIs, but I'm not sure what the best way to present them is.
Thanks for the information, I will continue investigating how to restore my IMEI, greetings from Argentina
1.16.8 includes retry logic to loop through a bunch of dummy serials until it finds one that works or runs out. I also made the in-app logic able to compile multiple TACs per model.
It looks like 012345 is a good secondary to 123456, but I added the ones that worked for @martinetd as well. The IMEI field is a bit of a mess with so many generated IMEIs, but I'm not sure what the best way to present them is.
I had somewhat decent luck generating valid IMEIs, usually within 5 tries with this RNG
rng_first_digit = random.choice([0, 5, 7])
rng_second_digit = random.randint(4, 9)
rng_third_digit = random.choice([0, 1, 3, 5, 6, 7])
rng_fourth_digit = random.randint(0, 9)
rng_fifth_sixth = random.randint(00, 99)
https://github.com/ananjaser1211/samloader/commit/d93cd5bfea266ee857b99424f3ef1f9b6b33ff30
totally randomizing all digits or passing statics did not give me much luck, with this there is a good chance a valid imei will be used, incorporating this with TAC list however is a nightmare, i tried scraping swappa IMEIs etc but there seem to be a pattern of consistently marking a TAC for a certain model as a TAC for multiple models, this is obviously invalid, for example G960F and G960N are listed with the same TAC and it does not work (in the swappa csv) for either
I pass the randomizer to FUS and check for response against 408, my concern though is such requests might introduce some limits from samsung, they seem to be clamping down hard for whatever reason.
353326101234567 works for G960F/DBT and 353524091234569 works for G960N/KOO for me.
I have tried it now and it is indeed working! i must have fudged the luhn bit, this makes variables much less thank you!
I have a samsung SM-X210 tablet, no sim card, no imei (aida64, checkimei, etc... returns null). how do i use the app ?
I have a samsung SM-X210 tablet, no sim card, no imei (aida64, checkimei, etc... returns null). how do i use the app ?
Use tablet serial number.
It seems like U and U1 can no longer share TACs. I also had to add a new "020202" dummy serial for the SM-S928U.
Generate serial doesn't work with SM-T727R4 (USC), is such behavior as expecting?
IMEI generation only works for devices whose TAC (first 8 digits of the IMEI) we know. The SM-T727R4 isn't in the database.
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.