The primary motivation for the creation of Kraker Mockery is the misuse of the "debugger" command and other methods used to cripple the web browser's developer tools. Also, the developer tools have two major flaws: the requirement that a web page be kept open while the site is being analyzed and the relative inefficiency of the developer tools due to retention of all web activity in memory (maybe not an issue for beefy PCs).
You will need to download the following files to your Kraker secret directory (that is, the directory created during the
process of installing Kraker and which is named after your shadow secret). Mockery also uses
| mockery.htm |
|
| mockuary.htm |
|
| inspector.htm |
|
| kraker-mock.js |
|
The Mockery server is a bare-bones version of the main Kraker server with the ability to save content to disk and to
communicate the details of the intercepted activity to the browser app. It can be easily modified for your own purposes. It
features three ports: HTTP port 8082, HTTPS port 8083 and port 8084 which is an all-in-one port for HTTP, HTTPS and the
HTTP CONNECT method (that is, it can act as an HTTP proxy). The Mockery server uses the same RSA key and certificate as the
main Kraker server. If a secondary certificate called
The Mockery control panel features three modes of operation: Proxy websocket, Mockery websocket and shadow port manager. In the Proxy websocket mode, it connects to the main Kraker server to receive notifications of activity through the Socks5 port. The activity notification includes domain name, port number and IP address. The purpose is to generate a list of the domains encountered while loading a target web page. Though it is possible to simply capture ALL activity from a website, this is not recommended due to the proliferation of adware and other uninteresting content. The list can be easily narrowed down to just a few domains. Once it has been determined which domains are of interest, the shadow port manager will create the shadow ports in the main proxy and generate a fresh certificate for the Mockery server. Follow these steps:
You will also need to create a new directory inside the secret directory for the saved content. Call this directory "mock" since that is the default name shown at the top of the control panel. Once you're done with the new directory:
Pressing the "Delete files" button will delete files whose names contain the string "-post." or "-resp." (according to the naming scheme employed by the server). It is therefore safe to rename a file to keep it for future reference. This action will also reset the request counter but only for the specific directory. If you are using multiple save directories, each will have its own counter. The counters are maintained by the proxy server and thus will be reset if the server is restarted (which should never be necessary).
The Mockery server uses the system DNS to resolve domain names. It passes request headers unmodified from the web browser
and with the original camel-case. There is also some socket reuse. Most of the time, this will be sufficient. However, you
might wish to avoid the system DNS or some headers may need to be modified or a proxy may be needed for certain sites. You
will have to route the HTTP requests back through the main proxy in order to resolve such issues. This is what the Shadow
option does. The Mockery control panel creates a default shadow port configuration (
Reverse-engineering the behaviour of a website may range in difficulty from trivial to maddeningly hard. For the hard cases, it may be necessary to modify certain files (the main HTML or a script) and have them loaded locally instead of from the website. This is accomplished with a shadow path:
path:
You can create the shadow path in the control panel. Using a local file comes with the added bonus that any changes made to the file will apply to a reloaded web page so you won't need to break the browser cache by closing and restarting the browser. This will be important in the next section. Note that the "Release" button will remove all of the shadow ports but not the shadow paths. You can remove those by saving a blank.
The inspector tool can receive messages issued by a modified file via the
Once you have the template installed somewhere, you can send messages to the inspector with a single command:
The target web page must be launched from the inspector in order to establish the inspector as the parent (messages are sent
from the template script to
The inspector tool can also receive messages from the main proxy server's websocket service. There should not be any reason
to use a websocket. The
You might wish to consider using the web browser's developer tools to debug a script but that is unlikely to help much. I am far from being an expert on that but you can try it. This won't be possible, however, if the target web page is blocking the developer console.
Once you have saved some files and you have created the necessary shadow paths, open the inspector tool in the web browser. Ignore the name field because that is for the websocket which you're not using. Enter the URL for the web page in the target field and open in a plain window or in an iframe. Keep the Mockery control panel online with Shadow enabled (else the requests will not be redirected to the main proxy). Check the response headers for each of the saved files to verify that the response is coming from the main proxy and not the Internet. If everything is working as expected then you can start modifying the files with the template script and send some test messages. Proceed slowly and gradually because it is all too easy to break something which ends up with you getting frustrated with not knowing what the problem might be.
You should keep three copies of each script file. One which is the original unmodified copy, one which you are modifying and one which is a beautified or prettified version. A prettified script is one which has been edited to align braces, add whitespace, wrap long lines and just generally make the script more readable. The prettified script might not be executable because the editing process can break stuff but you will need it in order to identify the areas of interest. You can go here or here to get your script beautified.
When you are confident that you won't have any further need for the Mockery server then you can disconnect the shadow ports
from it. Delete any shadow ports that you no longer need and edit the remainder by either removing the port redirector
entirely (that is, the two "@" symbols with the port number in between) or changing the value to
The inspector has a feature called "Inspect" which will expose the DOM of the target web page. However, you must run the inspector from the same origin otherwise the browser will block access. You might need to apply this:
These are two problematic headers which you might need to deal with. The first one can block embedding in an iframe and the second can block access to the target window even if the inspector is running same-origin and not cross-origin (also, the window cannot be reused). If you run the page in an iframe then the second header won't matter. If neither of these headers is set then you won't need to worry about it. Apply the fix as needed to the shadow port hosting the page. Now run the inspector in the target domain:
Once you have opened the web page, with or without the iframe, press the "Inspect" button (wait for the page to be fully loaded). This will do two things: 1) it will print the Window object and the Body object to the developer console and 2) it will clone the DOM of the web page and add it to the inspector's own DOM in an invisible div. Use your browser's developer tools to poke around.
The decoder is available with a one-line interface at the top of the file viewer. This is only useful for short snippets. You can open the full version of the decoder from the control panel. The primary purpose of the decoder is to convert base64 strings back to the original data. If Unicode is present then prepend the base64 string with "@" to extract it. The decoder can handle a number of different encoding formats. Try this:
\ud83c\udff3\ufe0f. ��️. 55356,57331,65039. ��️. @\xf0\x9f\x8f\xb3\xef\xb8\x8f. @240,159,143,179,239,184,143. @$f09f8fb3efb88f. @#0x1f3f3,0xfe0f. @#127987,65039These are nine different ways of encoding a white flag. The first four are representations of UTF-16. The next three are byte streams representing UTF-8 and you need the "@" symbol to tell the decoder to extract the Unicode. The last two are representations of UTF-32. The "#" symbol tells the decoder to translate to UTF-8 and then the "@" symbol tells the decoder to extract the Unicode. This two-step process is needed because the web browser does not intrinsically understand UTF-32. The only representations that Javascript understands are decimal numbers and hexadecimal in the form
This is fairly complicated but the decoder essentially converts everything to a numeric array (printed to the developer console for reference) and then outputs the array as either Unicode or a stream of 8-bit characters (usually ASCII but could be anything). The comma is used to indicate an array of numbers while the period is used to separate the strings else the whole input would be treated as one string. The dollar sign is used to indicate a string of hexadecimal characters. Finally, you can use an initial up-arrow ( ^ ) to convert the input to base64.