New issue with loading

[lixmffm]

Won't display bereals, message is:

SOMETHING WENT WRONG: "" something went wrong, please try refreshing the page or re-login It's quiet here, nobody has posted anything yet.

[U14-dev]

Yes bereal changed the api so any 3rd party site is down atm^

[OldUse558]

A quick fix if possible would be amazing!

[lp9707]

Same here- Hope it works soon!

[CyberTimon]

Same issue here. I think the problem affects everyone. I really hope for a fix!

[retoheusser]

It looks like only the endpoint https://mobile.bereal.com/api/feeds/friends-v1 is affected. It suddenly responds with a 401 code when authorized with the bearer token. All other endpoints are still working using the same authorization.

Does anyone have the possibility to intercept the request and see what info is additionally required to make the endpoint return the friends feed?

[U14-dev]

They enforce a signature now ^ So no quick fix etc... they prob don't want any 3rd party apps to exist anylonger

[11prasicc11]

i always get stressed when this happens, i hope bro you solve this stupid problem soon :(

[retoheusser]

They enforce a signature now ^ So no quick fix etc... they prob don't want any 3rd party apps to exist anylonger

Good to know. How did you find out? Do you have more information on that?

[U14-dev]

nothing new But now it is enforced and will return 401 if the signature is wrong.

[CyberTimon]

No way to get the sig through reverse engineering or catching it with a logged in device such as an android phone?

[dudeofxyz]

do you guys think its possible to get it back or it’s down permanently?

[s-alad]

Looks bad

[NeedNot]

nothing is impossible but something like this if someone manages to crack it it's best for everyone if they dont share it otherwise bereal will just change it again

[h4rqq]

It seems like this time is really messed up .-.

[rvaidun]

Might be the end.

[Ein-Tim]

Can someone explain what happened? And why some parts are still working (e.g. the Profile) but not the feed?

[mynameisnitro]

We need reverse engineering requests but I didn't manage to bypass certificate pinning

[U14-dev]

No need to do this, signature can't be logged this way

[mynameisnitro]

No need to do this, signature can't be logged this way

Why? Isn't the signature included in the headers ?

[U14-dev]

It is included but can't just reuse it since a unique sig is generated for every req.... as i mentioned before it is not a easy fix here an could be the end

[11prasicc11]

I pray to God that this can be resolved, you are good guys, unite all of you on this project. I believe in you 🦾🎖️ ask senior colleagues, how can this be avoided

[NeedNot]

I pray to God that this can be resolved, you are good guys, unite all of you on this project. I believe in you 🦾🎖️ ask senior colleagues, how can this be avoided

no seriously if anyone does manage to reverse engineer the algo please do not tell anyone. don't even say you did it otherwise bereal is just going to reset it. they are in a position where you can spend weeks figuring out what they did and they can basically press a button and put you back to step 1. so from here I think all public befake projects are done. And anyone who wants to keep going just has to be smart themselves.

[yandevelop]

Hi, I am the developer of another BeReal "Unblur/BeFake" alternative called Bea. In theory, it should be possible to fetch the "bereal-signature" from a valid device and using this for x amount of time ig. In Bea, you can also upload a "BeFake" and the way this is done is by copying the headers of a valid "native" request sent from the device and reusing this later to post a BeFake. Until now I have not received any issues and posting a BeFake through this way should still be working. So in theory this could be a workaround (might be a bit wiry): Use MITM to intercept device calls from the BeReal app and copy the Authorization token, bereal-signature, bereal-device-id etc. and use them in BeFake (this may only be valid for a short period of time). If I find out anything new I will report back here! Edit: To bypass SSL pinning, you could use https://github.com/NyaMisty/ssl-kill-switch3 and inject this into the BeReal IPA via Azule or Sideloadly (if you arent jailbroken)

[NeedNot]

Hi, I am the developer of another BeReal "Unblur/BeFake" alternative called Bea. In theory, it should be possible to fetch the "bereal-signature" from a valid device and using this for x amount of time ig. In Bea, you can also upload a "BeFake" and the way this is done is by copying the headers of a valid "native" request sent from the device and reusing this later to post a BeFake. Until now I have not received any issues and posting a BeFake through this way should still be working. So in theory this could be a workaround (might be a bit wiry): Use MITM to intercept device calls from the BeReal app and copy the Authorization token, bereal-signature, bereal-device-id etc. and use them in BeFake (this may only be valid for a short period of time). If I find out anything new I will report back here! Edit: To bypass SSL pinning, you could use https://github.com/NyaMisty/ssl-kill-switch3 and inject this into the BeReal IPA via Azule or Sideloadly (if you arent jailbroken)

no you can't a signature is 3 parts an integer which has typically been a 1 separated by a : and a timestamp separated by a : and a hash for the content you are sending all encoded in base64

currently, just the friends feed has been enforced along with like the auth and settings stuff. so yeah currently posting works along with backing up memories but soon that wont be the case.

Like I said please if someone out there is smart enough to crack it PLEASE do not say anything to anyone because it will just get changed and maybe there are already people out there who have and are using it so you would be screwing everyone.

[yandevelop]

Alright, thank you for the clarification! I didn't know that this only affects the friends feed.

[yandevelop]

Well I just tried what I stated above and actually, it works... Edit: You don't even need all those headers, mandatory headers are:

• authorization
• bereal-signature
• bereal-device-id
• bereal-timezone

Having left all others out, the request still succeds. Will update on how long this remains valid

[NeedNot]

Well I just tried what I stated above and actually, it works... Edit: You don't even need all those headers, mandatory headers are:

• authorization
• bereal-signature
• bereal-device-id
• bereal-timezone

Having left all others out, the request still succeds. Will update on how long this remains valid

what did you change? even intercepting an actual sent request and changing the signature invalidates it

[yandevelop]

Nothing, just copied the values from intercepted request. Using BeReal on iOS 15.1 version 1.21.5 as seen in the headers

[NeedNot]

• bereal-timezone

what are the exact ios headers since i dont have any sort of ios device to get them from. i wonder if Ios is still allowed to go without a header.

if this is the case then ig we are saved till next week but we are still screwed in the long run

[NeedNot]

yeah it is 0% replicable here

[yandevelop]

Which header do you mean exactly lol? No, iOS BeReal app is not allowed to go without headers. The headers sent to BeReal from a iOS device should not differ from those made from an android device afaik.

[NeedNot]

[yandevelop]

"Device-id" is not the correct key here. It should be: "bereal-device-id"

[NeedNot]

"Device-id" is not the correct key here. It should be: "bereal-device-id"

ah i missed that. ok so it appears that it now enforces the length of the signature but not the content of the signature. (before we were just putting 1s in all the fields) weird why bereal would be doing it like this

[yandevelop]

So putting in any random string with a correct length should be sufficient?

[NeedNot]

So putting in any random string with a correct length should be sufficient?

no, it appears that maybe bereal isn't hashing the content? I am very confused by all this i am not exactly sure what is happening lol. common sense would say that this 1:1707590123576:‚|[¾ntÈƒù7ýõ»¦Ò±¡¨¤²˜²ÿ[` which is a decoded signature must be the content hashed so it would be impossible to reuse and would have to figure out how to create your own hash. but it does seem to accept signatures from the emulator but only ones from the emulator.

[yandevelop]

With what algorithm are you trying to decode it?

[NeedNot]

With what algorithm are you trying to decode it?

base64

[NeedNot]

yeah this doesn't make sense but it explains the 401 error not 400 my guess is they dont enforce the validity of the signature things like updating your pfp still require it sadly

[yandevelop]

Hmm yeah I would definetely say that this is not base64 encoded. I think that they use more complex hashing algorithms that aren't per sé decodable in the first place (as base64 would be)

[NeedNot]

Hmm yeah I would definetely say that this is not base64 encoded. I think that they use more complex hashing algorithms that aren't per sé decodable in the first place (as base64 would be)

the signature itself is base64 and that's how we get the timestamp and the 1 for some reason. the last section is what is still a mystery but it seems to be 62 bytes. not 64 but 62, unless im somehow losing 62 doing something wrong in the process. it could very easily be the byte output of a hashing algorithm that wasn't encoded first so as a result we just get strange UTF-8 chars

[rvaidun]

BeReal signature is just a B64 encoding and once decoding you get 1:{UNIX TS}:{64 seemingly random bytes} Since it is 64 bytes I am strongly suspecting a SHA256 hash but I could be wrong. Signatures are also only valid when sending headers with the correct device-id. Changing either sig or device id results in 401. I am guessing the bytes are generated by running device ID, UNIX time and maybe some other data thru a hashing algorithm to generate a unique signature on every request.

[yandevelop]

Yeah I also suppose that they are adding some salt to the hash so it's basically hopeless to try and decode it

[s-alad]

Does anyone have experience decompiling / unpacking apps and reading through them. I think it's the best shot for finding hints and clues on how they are generating the byte code for the decoded base64.

The signatures also do not seem to expire, perhaps there might be a method of just churning out many valid sig+device id pairs

[NeedNot]

Yeah I also suppose that they are adding some salt to the hash so it's basically hopeless to try and decode it

you can't really decode a hash to begin with. you can brute force guess it. we pretty much see how the hash is being created but it's a difficult process but it's possible

[NeedNot]

I still stand by what i said. Give it a few weeks and no signature will work because they will enforce it. Unless im missing something with the endpoints like sending or receiving friend requests or setting your settings those endpoints check the signature so you can't reuse them. I'm not sure what is going on here and why the signature can be reused but I dont think it's going to last like this forever

[s-alad]

They def seem to be set up in a way where they are supposed to expire, having a unix timestamp in the encoded b64, and also sending the timezone. So it would be only a temporary fix.

[yandevelop]

Depending on what you are trying to achieve, this was already discussed here: https://github.com/yandevelop/Bea/issues/24

TLDR: The bundle id of your side loaded ipa doesn't match with the one's the Firebase auth server expects it to be. There is currently no fix besides installing the ipa via TrollStore or making sure the bundle id is the same as the original one ("AlexisBarreyat.BeReal"). I will try to fix this as soon as I have the time to (prob. early March)

[yandevelop]

No

[BZHugs]

https://gist.github.com/BZHugs/1bf36c111af77667e558697c10c0691b <- deleted (ping me on X if u want)

@.dev It's up to you!