I am trying to base64 decode of the following cookie from CTF challenge as a learning exercise
%2BiEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H%2BINemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX
This cookie contains a flag that needs to be decrypted. I tried using the following command in Linux but it returns garbage
echo "%2BiEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H%2BINemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX" | base64 -d
I know % is not a base64 character. How can I decode this cookie since it contains % and get the flag that can be further decrypted?
Following Luke Josha Park's suggestion, I did the following in Chrome Developer's console
cookie=atob('+iEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H+INemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX
')
and I am getting
"ú!¶SÈ¡L!]l^Mb¥ÎÃÔ5é8´) ù,§.Òó«aCüµwÿ³jÙ»å(©L}HâO:>\Êaº7y1Ayìñ"±3¶¦"
How to make sense of it or have I done it incorrectly?
%2B is the URL encoding of the symbol +, which is a base64 character. Try URL decoding your original string to produce:
+iEftn9TF4DIoUwhXQRsXk1ipRbOigvD1H+INemWOLQpoPksFJSnLozS86thQ/wfH7V3Dhb/s2rZrbvlKJSpTJh9SJ3iAhFPOj5cymG6N3kGMRNBeYLs8SKxMxydtqaX
Related
Hi Guys Im currently capturing some traffic from an android application, but the requests it is sending out to server seems encrypted. Would you guys know how to decrypt such requests? Or is that impossible to do?
platform=android&version=1.0.31&lang=en&requestId=44&time=1485552535566&batch=%5b%7b%22id%22%3a177205%2c%22time%22%3a1485552512601%2c%22name%22%3a%22collectResource%22%2c%22params%22%3a%5b155%5d%2c%22hash%22%3a1948904473%7d%5d&sessionId=674937_bc59a16eae9e1559b2e60ae068baf4e7
That's not encrypted, it's encoded. Do a search for "online url decode". In your example you will get:
platform=android&version=1.0.31&lang=en&requestId=44&time=1485552535566&batch=[{"id":177205,"time":1485552512601,"name":"collectResource","params":[155],"hash":1948904473}]&sessionId=674937_bc59a16eae9e1559b2e60ae068baf4e7
The %xx are url encoded hex values. For example %22 is the hex version of the double quote character. I think that if you use javascript or other tool to decode the url encoding or manually change all % strings to the equivalent characters, you will see that the message is really just url encoded plain text.
I am trying to do oauth 2 with Paw. It doesn't appear to be encoding my Client ID and Client Secret correctly. My server expects username:password format. I have tried it in the same field, separate, with same results.
Example
Input = VjE6MHJ:SjZvR24=
Base 64 encode result = `VmpFNk1ISjpTalp2UjI0PQ==
Paw result = VmpFNk1ISjpTalp2UjI0JTNE
The base 64 result works and returns a token, but Paw does not as it is encoded wrong.
It's a late answer, sorry! It seems like the only difference is that the = sign at the end of your password, is URL encoded by Paw, while your server doesn't expects a URL encoded value.
According to the OAuth 2 spec / 2.3.1. Client Password, we need to URL encode the Client ID and Client Secret. Then the question is, should we also encode the = sign? It's not very clear from the spec. Have you tested with other clients (maybe client implementation of OAuth, in JS/Swift/Python/Java)?
I writing an application that using http request for authentication. Because of security matter, I am using WireShark to sniff the http packet to see if can steal the username and password.
When using WireShark, I got this encoded string:
TlRMTVNTUAADAAAAGAAYAHIAAADcANwAigAAAAQABABYAAAAEgASAFwAAAAEAAQAbgAAABAAEABmAQAAFYKI4gYDgCUAAAAP255D/F478qJlQoJwEti1LGgAcABzAGwAZQBlAGsAYgBvAG8AawBIAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGao0slMmaggkTP6jJJHJUwEBAAAAAAAABaWp/E9p0QGDaAQ319vuYgAAAAACAAQASABQAAEABABIAFAABAAEAGgAcAADAAQAaABwAAcACAAFpan8T2nRAQYABAACAAAACAAwADAAAAAAAAAAAQAAAAAgAAAkOEBAmC7E+a9Pa8Y4gF0J9zeqVTsT7BCXKEhznVGMpwoAEAAAAAAAAAAAAAAAAAAAAAAACQAkAEgAVABUAFAALwAxADkAMgAuADEANgA4AC4AMQAuADEAMQAzAAAAAAAAAAAAAAAAAFq8ggyPeAnfXnSiV12/Z1Y=
I do research online, and I guess this is Base64 encoded. Then, I tried to decode from this website:
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
I managed to see my username which is sleekbook, but the others still seems unknown to me. Is it because it's not Base64 encoding or it's further encrypted by some other algo as well?
I am trying for a way to pass binary data to a server over http, via the URL field in the browser. Is there a way to bypass the automatic http encoding done by the browser so I can just encode the data by myself.
e.g.: Instead of the byte with value 48, to fill in the URL %30 so that the browser doesn't re-encode the url and I end up with %2530
Solved: To whom may encounter similar problems in the future. You can do so by using wget parameter
--restrict-file-name=ascii
Which basically ensures that '%' won't be escaped
Use base64 encoding, that's what it's designed to do.
I managed to do so, by writing my own tcp client to connect to the http server and transmit the request, by inputting it manually.
Use the base62 encoding.
The encoded string doesn't contain any character that will be URL-encoded.
I have a JavaScript request going to a ASP.Net (2.0) HTTP handler which passes the request to a java web service. In this system special characters, such as those with an accent do not get passed on correctly.
E.G.
Human input: Düsseldorf
becomes a JavaScript asynch request to http://site/serviceproxy.ashx?q=D%FCsseldorf, which is valid in ISO-8859-1 as well as in UTF-8 as far as I can tell. (unless it's %c3%bc in UTF-8)
HttpContext.Current.Request.QueryString.Get("q") returns D�sseldorf which is where trouble begins.
but HttpUtility.UrlEncode(HttpContext.Current.Request.QueryString.Get("q"), Encoding.GetEncoding("ISO-8859-1")) returns D%3fsseldorf (a '?')
and HttpUtility.UrlEncode(HttpContext.Current.Request.QueryString.Get("q"), Encoding.UTF8) returns D%ef%bfsseldorf
So it the value doesn't get decoded nor re-encoded correctly to be passed on to the java service.
Notice HttpContext.Current.Request.Url.Query is ?q=D%FCsseldorf&output=json&from=1&to=10
while HttpContext.Current.Request.QueryString.ToString() is q=D%ufffdsseldorf&output=json&from=1&to=10
Why is this, and how can I tell the HttpContext to honor the request headers which include:
Content-Type=application/x-www-form-urlencoded;+charset=UTF-8
and decode the URL's QueryString using the UTF-8 charset.
Addendum: As the answer notes, the trouble lies not so much in the decoding as the encoding; using escape() in JavaScript does not escape according to UTF-8, while using encodeURIComponent() does.
I don't know what the default character encoding used by your server (IIS?) is, or if it can be changed, but I can tell you a few things that might help.
0xFC is the ISO-8859-1 encoding for ü. While the Unicode code point is U+00FC, when encoded with UTF-8, this requires two bytes, and becomes 0xC3 0xBC.
If a UTF-8 decoder were to see the illegal byte sequence 0xFC, it would decode it as a Unicode "replacement character", U+FFFD, and pick up where it saw the beginning of another valid byte sequence, in this case 's'.
The reason you get %3f is that '?' is the "replacement character" for the Latin character set, similar to � in the Unicode character set.
I believe what you're seeing is the client encoding with ISO-8859-1, but the server is decoding with UTF-8. As soon as it hits the server, your data is corrupted. I recommend that you modify the client to use UTF-8 encoding; it should be requesting http://site/serviceproxy.ashx?q=D%C3%BCsseldorf
It sounds like you are constructing these URLs from JavaScript, so you should use the encodeURI and encodeURIComponent functions, not escape.
I am getting the same problem with an ASP.NET generic handler when the URL is typed directly into IE8. Characters are being sent through as char 65533, and yet I do have IE8 set to
[x] Send UTF-8 URLs.
In my scenario, I'm debugging an HTTP handler in Visual Studio and typing the address of the handler directly into the browser:
http://localhost/myHandler.ashx?term=xxxxxx
and then stepping through the code. The client will be passing UTF-8 encoded URLs, but is there a way to debug the code when IE8 running on the development machine is the client?