Comments on "A novice guide to Homebrew data bugs"
Goto page Previous  1, 2  :||:
Networking/Security Forums -> Physical Security and Social Engineering

Author: M3DU54Location: Las Palmas de Gran Canaria PostPosted: Wed Nov 23, 2005 9:35 pm    Post subject:
    ----
phreakre wrote:
Abso-freakin-lutely brilliant.
That's awesome, M3Dz!

Umm... Thanks Omega, glad you liked it : ).


phreakre wrote:
Sorry for the long delay in replies, as you can probably tell from the frequency of my posts, I've been busy this week and haven't had much time for the internet, sadly.

This week - lol ... I've been busy for the last year or so - accounting for the recent rumours that I musta died. Nice to see you back : )

phreakre wrote:
First, thanks again for the lengthy reply to my earlier statements. I've been thinking about this project a lot the last few days and I was wondering if you thought a 2.4ghz [ the wifi b/g band in the US ] application of this would be hard [ especially w/ regards to interference ] or defeat the purpose of the pieces you chose? Tagging along with my last question about 433 vs 418 mhz, I know that the 2.4ghz range is completely unregulated right now in the US [thus everything seems to operate there in the US ] and I thought maybe all that traffic would mask the presence of a bug like this to a site survey.


Well, the major problems with 2ghz is that at low power they are strictly line-of-site, and even then 'low power' is quite power hungry in comparison to lower frequencies. However, There are some particular niches where Ghz modules fit quite well.

I couldn't really comment on interference in the 2Ghz band in the US, perhaps we've got some US HAM enthusiasts with first-hand knowledge of whats going on in-and-around the 2ghz spectrum. However, any interference that is present can normally be dealt with by using a VAGI at your side, or even a parabolic if you have serious signal issues.

Actually, thats something I wanted to cover in the original article till I realised it would double the length. One of the other tricks we use is to place a bug or two-way tap on an ethernet segment ... for example, in the Horizontal-Crossconnect or inside of devices such as network Laser Printers, or dangling from the back of a cavity-wall mounted socket.

These use WiFi modules (Yes, WiFi comes in pretested integratable modules too) - What you do is tweak the frequency slightly to nudge it out-of-band (Giving you private channels) and then lift any compliance limiting done on board for a signal boost. There are problems...

-Its not easy to use these devices at high-speed as most microcontrollers (The simplest option) are too slow to control the module.

- They gave great power consumption and so need an external supply

- Someone will undoubtedly insist that its near-impossible to install such a device, meaning I would also have to show SCD-boxes and outline a classic SCD entry methodology. Whilst complex this makes for one hell of an article.


Also, once we discount common MCU's as a controller we must find something to replace them. This is typically done with large-scale programmable logic in the form of Field Programmable Gate Arrays (Look up 'FPGA') ... Essentially, these are just a configurable array of millions of logic gates which we set in order to create a specific behaviour. Essentially, we create our own custom chip.

In creating an ASIC (Application Specific Integrated Circuit) we are going to scare off a LOT of people. The fact that we can define and burn these ASICs using a higer-level language such as VHDL/Verilog does little to relax the initial apprehension.

Unfortunately, whilst VHDL/Verilog reduces this task from designing and arranging individual logic gates to specifying the intended operation in a descriptive/behavioral language... the language itself is NOT sequential. There is no instruction pointer, no stack, no orderly exectution. The entire 'program' executes 'at the same time'. This is a sufficiently different form of programming to intimidate most people - despite the deceptively C/Java-like syntax, were talking about a whole new mindset. I really couldn't reccomend writing a protocol stack and driver to interface an FPGA to an 802.11 module as a first foray into FPGA's and, as cheap as it is to get into, I doubt many of our readership have ever really come across them.


But still...

If anyone really wants to know how FPGA-based taps and bugs work, and how one would get safe and unquestioned entry into just about ANY target corporation to plant one, then I will oblige. Even though the FPGA side of the devices themselves is a bit beyond what can be taught in a forum such as this, the whole operation, and the technology used to gain entry, should be interesting for everyone.

Actually, that reminds me - The SCD-Box is possibly the most useful bit of kit a phreak/social-engineer can have at their disposal - Yet it never got a 'box colour' and I've not seen any decent articles on them. Strange. Maybe we got enough material for a set of articles that will show the tech. side of Social Engineering.

What you think ?

-Meds


Last edited by M3DU54 on Wed Nov 23, 2005 11:30 pm; edited 1 time in total

Author: capiLocation: Portugal PostPosted: Wed Nov 23, 2005 10:12 pm    Post subject:
    ----
I think the topics you mentioned would make for a very interesting article series, M3DU54. I would most definetly enjoy reading about it in more detail, and I'm sure many others would as well.

You should get in touch with alt.don about featuring the articles on the homepage, as we have recently done with others.

Author: alt.don PostPosted: Wed Nov 23, 2005 11:30 pm    Post subject:
    ----
Hi M3Dz,

The article series sounds good to me. Feel free to drop me a pm so we can chat about it.

Author: M3DU54Location: Las Palmas de Gran Canaria PostPosted: Fri Nov 25, 2005 11:59 pm    Post subject:
    ----
Thanks Capi, Don ...

Just thrown up an intro for the SCD thing, guess theres no backing out now huh ? : ) I'll follow this series up with one on 802.11 based taps once I figure out HTH to present it.

I've tried to link the two by scenario ... pointless teaching taps if you can't get in to install one - or teaching how to get in, if you don't have any idea of what to do once your there. So, I guess one article kinda begs the other.

Oh, and I'll try to keep the 'incitement' vibe to a minimum ; )

-Meds

Author: alt.don PostPosted: Sat Nov 26, 2005 12:54 am    Post subject:
    ----
Cool beans M3Dz. The whole line of sight issue with some of the bugs due to their RF allocation does pose some interesting problems for those tyring to monitor them.

Author: M3DU54Location: Las Palmas de Gran Canaria PostPosted: Sun Nov 27, 2005 11:19 pm    Post subject:
    ----
alt.don wrote:
Cool beans M3Dz. The whole line of sight issue with some of the bugs due to their RF allocation does pose some interesting problems for those tyring to monitor them.

Whilst line of sight and short range is a big issue, you can often find that these effects can be minimised with directional tuned antennas and stronger receivers. Often, low power bugs require a quality scanner and parabolic to pick up - but, they can be picked up far beyond their expected operating range.

There are many scanners with digital output too, which allows us to interface a PC or laptop for the decode whiles still taking advantage of the scanners superior selectivity and sensitivity. Alternatively, one can often connect dedicated receiving hardware directly to the audio-out on the scanner.

Remember that all broadcasts go to the horizon unless absorbed... The problem is detection because as they spread they 'thin out'. Long range systems usually provide increased directivity and power at the source, but similarly, low power sources can be made long range by utilizing increased directivity and sensitivity at the receiver.

A good example is parabolic sniping of AccessPoints... Whilst its expected that your parabolic can focus your power and thus send it further, many people don't realise how effective they are at 'pulling in' the remote AP ... whilst the actual operator may get poor signals from his own garden, a sniper can get excellent signals from a kilometer or more away.

There are also some problems tracing back a tight beam (especialy when 'bounced') - which is one of the advantages radio pirates gain by using STL's (Site to Transmitter Links) based on old satelite LNB's (without the dish) at the transmitter rooftop ... The actual studio can be anywhere in a 90 degree arc of the LNB and as far as 5km away. It may also 'bounce' the signals off a building or storage tank or similar at some distance penalty.

Of course, that only protects the studio - or in our case, the receiver. Although, unlike the pirates STL link, we can't bounce : /


In covert data gathering operations the chance of locating the remote end is greatly reduced If you buffer, Keep only interesting information, and then release it in scheduled busts. This means that any interference is going to be brief and not likely to give away the location of the remote end. Interference is much more likely to give away the presence of a transmitter than a bugsweep (Bugsweeps ain't too common)

Also, if a bug sweep were performed, theres a strong chance it's going to miss the operating window of a burst transmitter completely. You can have the best trained personel and the highest-quality OSCOR equipment but if the bug ain't transmitting at the time it ain't gonna show.

And distance isn't always a factor. For example, a PIC based receiver built into a walkman, coat lining or similar can allow a 'monkey' to password-gather in a sensitive organisation without the need to revisit the machine(s) ... or, indeed, do anything more conspicuous than cross the room at one of the burst times. They needn't even be aware of the actual location or type of compromised device, or even be aware they are carrying a collector.

Thats called a stooged proxy:

For example, one deep penetration I discussed with a colleague was a restricted site set 1km down a private access road with a guardpost on the motorway turnoff. A proxy receiver was attached inside the plastic rear bumper of an employees car, and the data was remotely retrieved while the car was parked outside of his home at night. The battery system was two large 6v 'square' batteries with a sleeping PIC (powersaving) which woke on the carrier detect line of the receiver module and first determined if this was a burst from the bug or a query from the collector - It then stored or unloaded as appropriate. Battery life was calculated to be well over two years, although it was retreived after just two months.

Just let the employee unsuspectingly collect the data and courier it for us... Later a quick identifying burst from the collecting agent and the proxy device happily relays back everything it has picked up while parked outside of the target site.

Its little tricks like that which make the whole field so interesting : )


-Meds

Author: jason_K_blackLocation: Newcastle, Australia PostPosted: Tue May 30, 2006 5:12 pm    Post subject: Ideas for experimentation
    ----
In the old saying ď I liked the product so much, I brought the company ď I like this article thread so much, I had to sign up to the forum to add to it, it is a little gem, and this is no mean feat, as I donít write on forums, I like to stay off the radar with what I am thinking or researching, and I have been thinking along these lines for a year or two, I even have some info on bugging VGA port I saved from the net a few years ago, I have just been too busy (lazy) to do anything about it, till now, I have just spent the weekend digging out my prototyping box and updating it.

I would like to thank M3DU54 for taking the time to write the three parts to the original thread

The purpose of this reply is to add some ideas for experiments; no I donít have any source code, I can code small section of code, when I have to, but thatís all, I am a hardware boy, not a software jock. Also to provide some useful sources of information.

Idea one: Cellular Relay

Instead of a hand held receiver to receive the burst transmitted captured codes, you could create a burst transmitter wireless cellular relay. This is not as hard as you may think. I read an US magazine called CIRCUIT CELLAR................This mag is FIVE STAR, its web sites are:

Web site: http:// www.circuitcellar.com
File transfer site: ftp://ftp.circuitcellar.com/pub/

This magazine is a medium to advanced level electronicsí magazine dealing with embedded computer project, PICís, AVR, Embedded boards and computer projects, but that shouldnít deter any novice, you must learn sometime,

Back to the idea, the April 2006 issue #189 has an article called MONITOR AND CONTROL WITH TEXT MESSAGING by Ken Merk. Basically it consists of some switches connected to microcontroller (flash 186 board) and transmits via a wireless cellular modem (data only) module (http://www.bluetreewireless.com). The modem is a standalone unit and is RS-232 and uses AT commands to transmit data via SMS into PC running HyperTerminal.

While the source code isnít suited to the PICís, it is a good ref point on how to use SMS and AT codes to drive the modem.

The source code can be downloaded at ftp://ftp.circuitcellar.com/pub/circuit_cellar/2006/189/merk-189.zip

Well, how is this going to work, the first part, the bug can be set to transmit as the keys are typed, the receiver which doesnít have to be inside the targetís building, but close enough to receive the signal from the tap, storeís the scancode in the memory, just like in the original thread to this article. At some time when it is sure nobody is going to be using the computer, so that you know the receive isnít going to be interrupted, it switches into relay mode, dialling the PC phone number via an RS-232 connection to the wireless cellular modem and transmit via SMS the contents of the days activities to the PC running Hyper Terminal.


While it is SMS based, it allows two way communication and control from anywhere in the world, and is a good example of how to transmit using SMS. It is possible to transmit via the Internet as data, but you need to establish TCP/IP protocol on the microcontroller, and that might need something a little more dedicated than the PICís chip.

The back issue archive has tons of simular types of project and source code, and a wealth of info on using PICís and wireless modules and well worth a browse.


Idea Two: Tapped Mouse Port

Now while tapping the keyboard would capture everything typed in on that breached computer, it would create on big text log that would take some skill to work out what is being typed, and just how it fits together, and in what application. Idea two is to expand the bug to capture the mouse port as well, now while capturing the movement is possible, I still have trouble working out as to how you could sync the cursor, and we would have to know exactly what applications, and how they are stored, are running on the computer. This isnít feasible, instead we look at capturing the clicking of the right and left mouse buttons, we can then include them by either assigning un used scancode or creating and adding our own, in the log of scan codes as they are typed.

This would show when a string of code is been entered in dialog boxes and such
And make life easier in deciphering the text log.

Idea Three: Internal concealment

While discussing ways to build data bugís, you must consider wayís to hide it, a bug that plugís into the cable, isnít going to last long if the personís using the computer starts to poke around back, so if the plan is to use for any length of time, you have to consider hiding internally in either the keyboard or the PC itself.

Modern slim line keyboards if you have played with them consist of a very small PCB connected to two plastic membranes, when the keys are pressed, the contact from one sheet connects to the contact on the other. There isnít very much room at all to hide the bug, even if you design using surface mounted components, you will be hard pressed to fit it in, and if you are doing it on site, it is going to be a nightmare.
You could find out what brand and make is being used and pre prepare the bug in it and swap the keyboards over, but this could raise concerns from the operate if they notice the difference in feel of the keys




So, the alternative is to hide the bug inside the PC itself by building it onto a PC expansion board card that has the interrupt lines cut, as far as the PC knows the slot is empty Once the card is in, you would need to supply some sort of external aerial, as the PCís case would shield most of the signal, and then work out how to connect to the ports being bugged by either splitter cable to the ports (still not very stealthy) or by tapping internally the data lines for those ports, by connecting wires to the board or socket, you should be able to trace the pcb lines back from the socket to find a suitable point to tap, or if you are lucky to have a MOBO that uses cables to link the ports, plugging into them.

I have been planning to experiment with the latter, and also include some VGA bugging into the design, as mentioned above, I have a couple of design ideas as to how it could be done.

What about USB

One thing to consider is that the current PS2 connector for keyboards is on its last legs; with everything going USB (Iím currently using a 4 button USB trackball)
We need to also consider ways to tap into the data stream between the device and CPU to recover the scancode.

Tapping the Data bus:

As mentioned above it is possible to tap the PCís Data Bus, the following book
HACKING THE XBOX an introduction to reverse engineering by Andrew ďbunnieĒ huang, details experiments in reverse engineering the XBOX.
Now you might say why this is important, just remember the original XBOX is nothing more than a cut down PC motherboard, with a few sneaky security tricks.
The first five chapters are basic stuff for novice hackers; change the LED, hardrive CD RomÖetc but chapter six and up start dealing with the data bus and how the boards Bios chip is fake, it does nothing at all, the real Bios is hidden else where.
The point of this is that in chapter 8, the book details how to make a device to eavesdrop on the Hype Transport bus connection between the North bridge and south bridge bus chips, including, pcb design, and how to attach the bug pcb to the motherboard without cutting the data bus. It also show how to view what is going on, while it is not transmitting like what we have been discussing, it would make a good starting point for further experimentation ad research.


Well thatís just a couple of ideas to keep in mind for further experimentation and research.

Author: Blasterdito PostPosted: Tue Jul 08, 2008 4:26 pm    Post subject: firmware issue
    ----
Hi

First of all thnx to the author for taking the time to write this article.

Secondly, I have zero experince with programing but decided to learn c pic after reading this article.
So after a couple of weeks of researching on the hardware and software , I finaly was ready to do some programing and compiling.

I starded with trying to comile the initial firmaware

Code:
#include <16F84A.h>
#use delay(clock=10000000)
#fuses NOWDT,HS, NOPUT, NOPROTECT
#use rs232(baud=1200,parity=N,xmit=PIN_A2,rcv=PIN_A3,bits=9)

void clockwait(void);

void main()
{
   unsigned char byt;   // Holds each byte received

   setup_counters(RTCC_INTERNAL,RTCC_DIV_1);

   while(1)         // Loop forever...
   {
      byt=0;         // Starting a new data frame

      clockwait();      // Ignore start bit
      for(t=0;t<8;t++)      // Grab eight bits of data...
      {
         clockwait();
            byt|=input(PIN_A0)<<t;
      }
      clockwait();         // Ignore parity bit
      clockwait();      // Ignore stop bit

      putc(byt);         // Send byte to the transmitter

   }            // ... rinse and repeat :)
}

clockwait()
{
   // Waits for the next clock cycle...
      while(!input(PIN_A1));   // Wait for clock to go HI
      while(input(PIN_A1));   // Wait for clock to go LO
}





and i got this compiler error

"
>>> Warning 203 "main.c" Line 15(1,1): Condition always TRUE
*** Error 12 "main.c" Line 19(11,12): Undefined identifier t
*** Error 12 "main.c" Line 19(15,16): Undefined identifier t
*** Error 12 "main.c" Line 19(19,20): Undefined identifier t
*** Error 12 "main.c" Line 22(33,34): Undefined identifier t
4 Errors, 1 Warnings.
Halting build on first failure as requested.
BUILD FAILED: Tue Jul 08 16:19:30 2008


After reading about the errors i start to understand the problem , but if anybody is in the mood for helping out, that would be nice. if not I will post a solution as soon as I find it.


P.S I know that this error post may be a stupid question , but plz bear in mind that this is my first experince in any type of programing.

Moderator note: edited to add code tags - capi

Author: Blasterdito PostPosted: Thu Jul 10, 2008 10:37 am    Post subject:
    ----
I found out that variable "t" needed to be declared, this is how i tryed it.

Code:
while(1) // Loop forever...
{

byt=0; // Starting a new data frame

clockwait(); // Ignore start bit


unsigned char t ;                 // VARIABLE DECLARATION


for(t=0; t<8; t++) // Grab eight bits of data...
{
clockwait();
byt|=input(PIN_A0)<<t;



These are the errors I still get

"Executing: "C:\Program Files\PICC\Ccsc.exe" +FM "main.c" +DF +LN +T +A +M +Z +Y=9 +EA
>>> Warning 203 "main.c" Line 15(1,1): Condition always TRUE
*** Error 51 "main.c" Line 20(7,15): A numeric expression must appear here
*** Error 12 "main.c" Line 21(11,12): Undefined identifier t
*** Error 12 "main.c" Line 21(16,17): Undefined identifier t
*** Error 12 "main.c" Line 21(21,22): Undefined identifier t
*** Error 12 "main.c" Line 24(33,34): Undefined identifier t
5 Errors, 1 Warnings.
Halting build on first failure as requested.


Don't exactly know how to define the numerical expression??

Moderator note: I've edited this post again to add [code] tags around the code. Please do so in the future, to preserve formatting - capi

Author: Blasterdito PostPosted: Thu Jul 10, 2008 4:58 pm    Post subject:
    ----
Problem solved.

The variable t is declared by inserting "unsigned char t;" into the start of the program, if not c++ it's always rightt after start of the program.

Like this

Code:


----code snip----

void clockwait(void);

void main()

{
unsigned char byt; // Holds each byte received
unsigned char t; // declaration of variable t

----code snip---



Also the function "Clockwait" needs to be defined the same way as it is declared,

In other words , replace "Clockwait()" at the end of the code with "void Clockwait(void), (as it is in the beginning of the code).

And now I'm moving on to the next part of the guide


cheers Wink



Networking/Security Forums -> Physical Security and Social Engineering


output generated using printer-friendly topic mod, All times are GMT + 2 Hours

Goto page Previous  1, 2  :||:
Page 2 of 2

Powered by phpBB 2.0.x © 2001 phpBB Group