How do I decode this! It's not base64 [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 12 years ago.

Here's what I know...

this "GxvS117MfVw=" when decoded turns to "56699"

now what does this "+sB6hF46GyU=" turn into "?????"

" not included

I tried base64 decoder and it doesn't seem to be right. It is supposed to be a number. I am not sure about the length, I don't think it should exceed 5 numbers. I would really appreciate it if you can decode it for me and show me how. Thank you!!

Edit:

I understand this might be insufficient data as this is my first post. Well I think it's php and its encoded like this

pubcredentials.php?id=GxvS117MfVw=

Please provide of the info you need and i'll try as much as I can to get it

Edit 1:

I got another one "L0sgBFUTpsE=开发者_如何学C" turns to "53096"

" not included

I am getting asked why would "L0sgBFUTpsE=" turns to "53096" Just to let you know that I did not decode this. This info was available to me when I was able to it decode it before they changed their decoding methods. So those are TRUE!

---

If the data represents Base-64 encoded material, the bytes encoded in the string are:

$ b64 -d "+sB6hF46GyU=" 
Base64:
0x0000: +sB6hF46GyU=
Binary:
0x0000: FA C0 7A 84 5E 3A 1B 25 00                        ..z.^:.%.
$

For reference, the same program decodes the other set as:

$ b64 -d "GxvS117MfVw="
Base64:
0x0000: GxvS117MfVw=
Binary:
0x0000: 1B 1B D2 D7 5E CC 7D 5C 00                        ....^.}\.
$

Consequently, I'm not sure how you came up with the answer 56699 that you claim it means in the question.

I needed to work with Base-64 stuff, and wrote the program to suit my particular needs at the time.

For details on Base 64, see RFC3548.

Each group of 4 Base-64 encoded characters represents 1-3 bytes of binary (unencoded) data. The strings you give are both 12 bytes long, representing 7-9 bytes of binary data. The strings actually encode just 8 bytes; the '=' at the end means that what would otherwise be the 9th byte is not present.

From the RFC:

               Table 1: The Base 64 Alphabet

  Value Encoding  Value Encoding  Value Encoding  Value Encoding
      0 A            17 R            34 i            51 z
      1 B            18 S            35 j            52 0
      2 C            19 T            36 k            53 1
      3 D            20 U            37 l            54 2
      4 E            21 V            38 m            55 3
      5 F            22 W            39 n            56 4
      6 G            23 X            40 o            57 5
      7 H            24 Y            41 p            58 6
      8 I            25 Z            42 q            59 7
      9 J            26 a            43 r            60 8
     10 K            27 b            44 s            61 9
     11 L            28 c            45 t            62 +
     12 M            29 d            46 u            63 /
     13 N            30 e            47 v
     14 O            31 f            48 w         (pad) =
     15 P            32 g            49 x
     16 Q            33 h            50 y

So, 'GxvS' is:

6        49       47       18
000110   110001   101111   010010

Regrouping:

000110.11  0001.1011   11.010010

Interpreted as hex:

0x1B  0x1B  0xD2

Which is what my program gave as the first three bytes.

If I had to guess, you've got an 8-byte 'integer' encoded in Base-64 instead of decimal. And it is not a direct mapping to the 56699; it is some sort of session identifier that is associated with the ID 56699.

---

Even though the strings look like if there are base64-encoded - based on the character repertoire given in the examples above and the distinctive = character(s) at the end of the string - the transformation 56699 --> GxvS117MfVw= might consist of several steps including compression and/or encryption algorithms with a base64-encoding as its last step.

So as VeeBee said: without any further information it's impossible to identify the steps required for the way back GxvS117MfVw= --> 56699.