FUS Now Requires a Valid IMEI or Serial Number

TheRealMrWicked commented 9 months ago

Once again Samsung has made changes now requiring a valid IMEI or Serial number to download Firmware from their servers.

Bifrost has been updated and works properly, see this commit for the implementation.

Thank you - MrWicked

Firmeware commented 9 months ago

I suggest passing the IMEI as an argument like something like this instead of engraving it like marble in request.py.

Thanks

TheRealMrWicked commented 9 months ago

@Firmeware I hope you dont mind, I used your code and made a pull request to close this issue.

martinetd commented 9 months ago

Yes that's roughly what I had in mind as well, didn't have time to do it.

I'll check/fiddle with it a bit over the weekend and merge it, thanks again!

Firmeware commented 9 months ago

@TheRealMrWicked A small cosmetic change may be necessary in your push request on file main.py. I had just duplicated line 18 and changed "region" to "imei" for testing purposes. But since you've updated the README.md file, it might be more consistent on line 19 to put "device serial/imei number" instead of "device imei code". I've just done a test for an A12, setting the serial number instead of the imei number, and it works without any change on the code.

martinetd commented 9 months ago

So I played around with it a bit:

checkupdate doesn't require the imei, the argument shouldn't be required for check
https://github.com/ananjaser1211/samloader is apparently better maintained than this and made the option -i, let's align...
https://github.com/zacharee/SamloaderKotlin/issues/116#issuecomment-1869732033 describes pretty well how the imei is formed, we should randomize the device part and recalculate the end unless asked not to... Oh I got beaten to it: https://github.com/zacharee/SamloaderKotlin/blob/master/common/src/commonMain/resources/MR/files/tacs.csv - and they're adding more as we speak. It doesn't have the TAC you listed so it'll definitely need a manual override, but we should make this automagic.

So:

'll just change the arg to -i and make it unused for checkupdate for now, let's get this in as stopgap
need to take a moment to implement the imei checksum (luhn algorithm) and randomize the end, the algorithm is trivial this shouldn't take long
need to add the csv file and try look it up if arg not specified

martinetd commented 9 months ago

decrypt was broken (it also needs imei and wasn't passed); I've fixed that and only done the first point.

I'm not sure how much free time I'll have in the next few days, but the next step definitely is looking up tac and randomizing the device part; will have a look as I'm able.

@ananjaser1211 hi btw, not sure where you got the download code from but your decrypt function is also broken right now :) (We should merge back at some point; I don't care about repo being in my namespace nor having commit rights as long as it's maintained, but you have issues closed so it's not great for external contributions like this...)

ananjaser1211 commented 9 months ago

Hey mate!, the code is forked from https://github.com/samloader/samloader @ 0e53d8032699a4039ea6f5310ebec05f8f417f07 and modified as i went along, issues were not enabled (and in my samfirm.NET fork etc) as they are for debugging and figuring out FUS with my friend, i generally apply required fixes to samloader, samfirm.NET and an internal sambot i use since we run into issues often,

Decrypt does need IMEI in samloader python, will update my repo, since this fork is older it should be the main hub, my repo is for experimentation and debugging (you dont really need the whole FUS logging stuff), nonetheless i have enabled issues incase someone uses it

TheRealMrWicked commented 9 months ago

@ananjaser1211 Can you open issues for your fork of SamFirm.Net btw, in case I need to make any, like I said before, it seems like you are defacto maintainer of it now.

martinetd commented 9 months ago

I've added a function that'll fill up a valid imei from a prefix, so you can pass e.g. -i 35123456 and get a chance at a random id in there that can work if the TAC matches and the star aligns (more details in https://github.com/zacharee/SamloaderKotlin/issues/116 but basically they're far from accepting everything that's a valid TAC)

I've also implemented TAC lookup from model, but that fails way too often so I've shoved it in another temporary branch for now; will update it if there's any breakthrough in bifrost. If nothing else we can probably make it work with a brute retry loop but I'd rather avoid that... I guess we'll have to make do with manually giving a prefix for now.

ananjaser1211 commented 9 months ago

Its a very good start, from what i understand, there are statics, a random number generated by some samsung algorithim, and the luhn check bit

ive looked at many IMEIs of the same model / TAC number, can't figure out a rhyme or reason of how the IMEI is calculated, i should mention that on samsung ROMs there is likely a check that checks if its a valid samsung IMEI, i will be trying to break that down and figure out the logic behind it (i say this because when you pass a non samsung IMEI to a samsung phone few checks will fail)

there exists websites that "generate" samsung valid IMEIs, so someone somewhere broke that logic before, the other difficult part is building a tac index that covers most common firmwares, all the websites i thought to scrape from were difficult or behind cloudflare sadly.

ideally we do not want to pass our OWN imeis, i have a feeling samsung has the power to block them from requesting firmwares int he best case scenario, they are coming down very hard after firmware downloaders, its been a cat and mouse game for the past month or so.

martinetd commented 9 months ago

Yeah would be interesting to know if there's any logic behind the next-to-last 6 digits (last 6 before luhn check digit), or if they just know what range they manufactured.

Also, I wouldn't trust these sites 100%: I've just tried https://www.imei.info/services/imei_generator/c19bf153-da86-4156-b5d2-64908c1b9d7d/ and out of the 10 IMEI that were listed only 7 worked (for -m SM-G990U2 -r CCT -- model comes what it says about the IMEI in the detail), so I'd wager they just picked a TAC and randomly grabbed from it.. OTOH they seem to have more details about TACs than what we have at this point, the new list in https://github.com/zacharee/SamloaderKotlin/issues/130 gives 82 TACs for this model but it's shared with plenty of others, and the other models didn't work with these IMEI (it's because they're all under the same commercial name, but actual model varies by country...)

I agree I don't want to use my own IMEI anywhere so for now randomizing 5 digits will be good enough, someone who wants to use samloader can definitely get their own IMEI, but hopefully someone will figure something better.

Firmeware commented 9 months ago

it still work with the serial number but is required to pad spaces on right or left with quote or double double like this. samloader -m SM-A127F -r XEF -i **"RF8xxxxxxxx "** download -v $(samloader -m SM-A127F -r XEF checkupdate) -O .

ananjaser1211 commented 9 months ago

~i feel like finding serial numbers might be more difficult than IMEIs, and with IMEIs we have the ability to "randomize them"~

~@martinetd i have implemented some randomizer based on yours with some logic for the first 4 bits, it gets me a firmware with decent success rates,~

Edit : scratch all that its useless, the 6 digit dont seem to matter and can be whatever

The only thing left is to build a TAC database, and cross check the model with it, but for now it does not incriminate anyone and risk getting imei blacklists i guess, its not perfect

Firmeware commented 9 months ago

@ananjaser1211 Personally, I think it's much easier to find the serial number of a WIFI tablet than its IMEI. But that's just my humble opinion. ;)

ananjaser1211 commented 9 months ago

@ananjaser1211 Personally, I think it's much easier to find the serial number of a WIFI tablet than its IMEI. But that's just my humble opinion. ;)

Thats what i get for not reading the earlier conversation haha, fair enough!

Firmeware commented 9 months ago

one solution might be to keep the transmitted value as it is if it contains at least one alphabetical character.

martinetd commented 9 months ago

@Firmeware sorry I also didn't realize -- I've made it so length check/expansion isn't done on alnum codes and pushed to master, please let me know if this doesn't work for you

(with that in mind we probably should name this something else than 'dev-imei' and the original -n sounds better... It's not like we've published a new version so that can work for now)

I actually don't know where to get (or if there even is) a serial number for my phone, did you try to change a couple of digits to see if it goes through? If so we probably could use some extending rule from a prefix like imei for these...

@ananjaser1211 I fudged my push yesterday, the TAC lookup code is https://github.com/martinetd/samloader/commits/tac_lookup/ Lookup works but requires way too many retries to be usable, we need a more precise table (this has too much mixing up through commercial names, I think we'll want a table with (model,region) that's much more strict) I guess for starters something like this + allow a dozen of retry + keep track of what worked to reuse on further run for the given model would work, but if samsung starts to rate limit the number of attempts it'd be easy to block so I think we're just going to need a much more curated list...

Firmeware commented 9 months ago

thanks it works again for my tablet A6 without any modification from my side

Feliz ano novo para todos Bonne Année à tous Happy near year to all

Firmeware commented 9 months ago

@martinetd I actually don't know where to get (or if there even is) a serial number for my phone, did you try to change a couple of digits to see if it goes through? If so we probably could use some extending rule from a prefix like imei for these...

to get the serial number you can get it from the menu "settings" and "about phone " or with adb command like this

[arch@archLinux ~]$ adb shell getprop ro.serialno 
RZCXNNXXNX
[arch@archLinux ~]$ adb get-serialno
RZCXNNXXNX

or with the IMEI number from the site (https://imeicheck.com/fr/verifier-imei) exemple for an A52 5G with the IMEI like the mine with a different SNR

IMEI.info: Galaxy A52s 5G (SM-A528B) SAMSUNG IMEI: TAC: 351364 FAC: 03 SNR: 670399 CD: 4

martinetd commented 9 months ago

Thanks! imeicheck is interesting, it shows the serial is computed from the imei.. Picking three in a row (with last digit fixed):

358832931001832 -> RF8R41NZKPF
358832931001840 -> RF8R41NZKQW
358832931001857 -> RF8R41NZKRK

It's possible to leading part comes straight form the TAC so that might be computable as well, but at the very least the "serial" part follows smoothly (3, 4, 5 -> P, Q, R) so if we can just figure the last key digit that can be randomizable as well to some extent...

Well, will leave that for now, but food for thoughts.

Firmeware commented 9 months ago

I'd say the SNR is sufficient because a phone with two IMEIs returns the same serial number. And I suspect the first characters are the code designating the manufacturing plant and therefore correspond neither to the TAC nor to the FAC since they are different for a dual sim phone

EDIT: more explanation here https://fr.tab-tv.com/2023/08/14/explication-du-decodage-du-numero-de-serie-du-telephone-samsung-2001-2020/

RF8R41NZKRK R -------------> code product F8 ------------ > factory code R4 ------------> Production date 1NZKRK -----> serial number

martinetd / samloader

FUS Now Requires a Valid IMEI or Serial Number #6