FuzzingBarebonesGuide
From RFID Guardian
This is a very basic picture & caption guide to using the Sensor Edge Server, the remote driver, and our beSTORM module, beMRG.
Contents |
Test Platform
- Description: new FSPC running windows xp
- Description: 1ghz machine running Ubuntu
- (Ask Nick for the username/passwords to the machines)
Using the Database, Application Server, and Edge Server web interface
| Screenshot | Caption |
|---|---|
 | This is the Oracle Database login page. Username: system |
 | This is the main database administration page. There are some statistics here, some administration options, and (off screen) any recent errors |
 | This is the Oracle Application Server (OAS) administration login page.
Username: oc4jadmin Password: [Ask Nick] |
 | The OAS administration page.
To restart the edge server, expand the 'home' group, click the 'edge' checkbox, and click 'restart.' You will have to click 'yes' or 'accept' on the next page |
 | The Sensor Edge Server main page.
Notice the navigation bar on the left, as well as the tabs up top. (These pages are better explained later on) The 'Default' group on the left is where you would add a new device, such as the 'remote driver.' You can also check the device status (up/down) from this page. 'Remote' is the name I chose for the remote driver instance. From there, you can restart the remote driver, as well as configure its hostname/port for later use with beSTORM. The filter added to remote is a debug log for all events successfully passed through. The 'Monitor Events' tab shows the 20 most recent events, such as rfid tag reads and device starts. I usually leave this page open with the Firefox add-on 'reloadEvery' enabled to ensure I won't have to update the cookie id often. The 'View log' tab is pretty obvious, and by default loads the last 200 lines of the current log. The 'Event Reports' tab is the database connection. |
 | The remote driver device page.
The 'Start device' button sends the same command as our beSTORM module, beMRG Notice that you can set the hostname/port here. These same values are used in beMRG. |
 | The 'Monitor Events' page.
The most recent 20 events go here, and the inbound queue is almost always empty. You can click the 'Details' icon for more information on a specific read. Also notice this 'MessageEvent' type is generally a status message. |
 | Using the Firefox add-on 'reloadEvery' with one of the /edge pages, like the 'Monitor Events' page, to keep the cookie from expiring. |
 | The 'Event Reports' page is the database link. You can add a 'Start Date' to filter for all requests since this date, or you could use an 'Advanced Search' to narrow more specifically. We will do this later. |
 | This is the result of a time-based database search. Notice the big gap between RFID Pass elements. This is a problem of uncertain origin that must be resolved before a full test can be trusted, as the dropped IDs are often arbitrary. |
 | Here we do an advanced search. The beSTORM module automatically adds 'SESnameid#' to every event, where the # is a number specified in the 'Evironment Variables' screen. If you change this for each trial run, it will be a lot easier to see which Events were successful. |
 | This is the result of that advanced search. We looked for tags from session 'SESnameid5.' Like the monitor page, you can click the details icon for more information. |
Sending events manually (HyperTerminal, beSTORM)
| Screenshot | Caption |
|---|---|
 | After opening hyperterminal, you must edit your connection details (at one of the two screens). The hostname and port must match youre Remote Driver configuration. |
 | The Remote Driver always connects as the client, so you must 'Wait for a call.' |
 | Back in the 'Remote Device' configuration page, click the 'Start Device' button to open the connection. |
 | On the desktop (or in my fuzzing report) is an example frame in the proper XML format. Open 'event.txt' |
 | Copy the event (be sure to get the linefeed at the bottom). |
 | 'Paste to host' to send. |
 | The example frame should now appear in the 'Monitor Events' page. |
 | If you want to send an event manually, through beSTORM, start the module at the very beginning and increment by 1, 5, 10, etc. Incrementing does not send the frame, you must click 'Simulate Current Position' to do so. Also, Yoav suggested that the incrementor value would only increment with each simulated event, so you won't be able to trust it in this way. |
 | I started the module from the beginning and simulated the first ten events (admittedly, I missed/duplicated two events). You can see that there is nothing wrong with the first small batch. |
Using our beSTORM module, beMRG
| Screenshot | Caption |
|---|---|
 | The beSTORM client opening screen. Click 'Load Project' and load D:\upload\beMRG\settings.bsp to load our module. settings.bsp is the default name for the main module file, and is described in XML format. Also have a look with a text editor. |
 | This is the default screen for our loaded module. Notice the XML structure that makes up our module on the right, the previewer at the bottom, and, of course, the 'Start' button. |
 | We want to view the environment variables. |
 | Now we need the Firefox cookie from the Edge Server, or our attempts to remotely start the Remote Driver from beSTORM will fail (specifically, hang, as beSTORM is waiting for a connection and has no timeout enabled). |
 | The cookies browser.. |
 | We need the cookie associated with our machine name, 'vague,' and the cookie specifically associated with 'Path: /edge' |
 | Copy the first section only. |
 | Split the cookie into two chunks. beSTORM has a limit on the Variable Buffer type that shows up in the Environment Variable browser, and sometimes the cookie is too long. |
 | Paste both halves in the Environment Variable browser, and update the nameid. Then save. The cookie needs to be updated every time you have to log in to /edge. The nameid is updated at your discretion, but should be done for every round to easily separate them in the 'Event Reports' tab. |
 | Save the module to save the new cookie and nameid. |
 | After clicking 'Start' in beSTORM and waiting for a bit, beSTORM has sent a few events. You can check the graph for a rough estimate of sessions per second, preview as before, and current attack vector, which is a representation of the current position in the module and can be used to go back to this element. |
 | The monitor tab now shows some of our sent events. They didn't all make it, and the reason why is still unknown. |
 | If we want to view beSTORM's report, which links exceptions with entire frames, click this button and click 'view' in the popup. |
 | This is the first part of the report. Below are frames listed with errors sent by the Perl script.
I believe that the frames recorded are the frame that was current when the exception was noted (as if by the Perl script), so the frame doesn't necessarily have to do with the error listed. At the least, one can get an idea of what errors are occurring. |
Running the unique_id Perl script to post-process the logs
| Screenshot | Caption |
|---|---|
 | in 'D:\upload\beMRG,' run unique_id_log_check.pl. Input the SESnameid number from the round you want to look up, and hit enter. |
 | The script now prints out a little information as it scans the 'I:' directory and outputs a file to 'O:' The lines in the terminal only print when an ID is thought missing, and the notation should be explained in one of the ~beMRG mini-doc files. |
 | Open the latest uniqueID_postcheck.*.log for the results. |
 | Here you can see that we found 28 lines and lost 50. The notation is inclusive, so 1,2,3, & 4 are missing in the first printout. Every *.log file in the directory was scanned, and each gets its own section. The last line is a rough percentage of missing/total lines containing a nameid and uniqueid. |
Various important files
| Screenshot | Caption |
|---|---|
 | This is the main beMRG directory, ~beMRG. This should include two Edge Server guides and a beSTORM user guide. The text files are all docs explaining the contents and the operation, in more and less depth than I have in this barebones guide. Start, obviously, with 'README FIRST' |
 | This is the settings.bsp file opened in a text editor. The layout is XML as defined by beSTORM's grammar in the user guide.
|
 | This image illustrates the Oracle database and server installation directories. 'edge1' was simply added to keep them together. 10.1.3.1 contains the Application Server and Sensor Edge Server, while the database is in 10.2.0 |
 | This is the beSTORM install directory and ~beSTORM\src directory. Currently, this directory contains a few quick test projects (not important), beSTORM's log is in \Log. \src contains example dlls and a Perl script. The helper.cpp file should be imported into your dll, if this isn't illustrated in the stub. |
 | These are the backups I took of the machine after having problems installing on another machine. I believe that 'fresh' is just a windows install, 'working' is the functional database/server copy, and 'aug14' is the last backup, after mild usage, but verified function. |
 | And if you actually want to use the backups, this is the related tool. |
 | The fuzzing filter in the Guardian software file ~/mrg/src/fuzzing/mrg_fuzzing_filter.c. Used to modify the request frame before interpreted by the Guardian*
|
 | The fuzzing raw callback before the Guardian sends the ISO-15693 reply over the contactless interface. |
