Plateforme de Hacking


HackBBS.org est une communauté faisant évoluer un système de services vulnérables.

Nous apprenons à exploiter de manière collaborative des solutions permettant de détourner les systèmes d'informations.
Cet apprentissage nous permet d'améliorer les technologies que nous utilisons et/ou de mieux comprendre l'ingénierie social.

Nous défendons les valeurs de l'entraide, du challenge personnel et contribuons modestement à rendre l'expérience des utilisateurs finaux la plus agréable possible.

Vous pouvez nous rencontrer via notre salon irc.
Le forum est en cours de remplacement par une version plus moderne, et tout aussi faillible que l'ancien ^^.
A ce jours nous enregistrons plusieurs dizaines de hack réussi contre notre site, et ce chiffre est en constante évolution. Merci a tous les contributeurs!

La refonte est en version alpha. Cette nouvelle plateforme permet de pentester à distance sans avoir son matériel à disposition.
Via l'exécution de scripts python connecté en websocket à l'ihm web, nous pouvons piloter le chargement de scénario
d'attaque/défense en "multijoueur" ^^.
Le système permet de charger des scripts de bibliothèques partagées et de chiffrer les échanges selon les modules déployés.
Vous trouverez dans la rubrique article de nombreux tutoriels afin de mieux comprendre la sécurité informatique,
ainsi que différents articles plus poussés.
Hacker
  • Sniffing
  • Cracking
  • Buffer overflow
  • Créations d'exploits
  • Social engineering
  • L'anonymat sur le web, spoofing
  • Bypass-proxy, Bypass-firewall
  • Injection de code SSI, SQL, etc...
  • Utilisation d'exploits, création de scripts(php, irc, perl)
We make porn

Please Donate To Bitcoin Address: [[address]]

Donation of [[value]] BTC Received. Thank You.
[[error]]
Nous vous recommandons de sniffer votre réseau lors de votre navigation sur le site. La refonte vous fournira un outillage pour réaliser vos attaques/défenses.

Vous êtes perdu? Utilisez le moteur de recherche du site!



Challenges
Vous pourrez également participer à de nombreux challenges en constant renouvellement (si possible :p)
Dernièrement, les missions relativent aux derniers produits open sources marchent bien :)

Votre ultime challenge sera de défacer HackBBS. De nombreuses failles sont présentes. A vous de les trouver et de les exploiter.

Cet ultime test permettra de constater votre réactions face à une faille.
Black ou White? ^^

Ezine du moment: p46-16.txt
                              ==Phrack Magazine==



                 Volume Five, Issue Forty-Six, File 16 of 28



****************************************************************************



                        VisaNet Operations (Continued)



4.22 TRANSACTION AMOUNT



This is a variable field from three to twelve digits in length.  The transaction

amount includes the amount in 4.28, Secondary Amount.  Therefore, field 4.22

must be greater than or equal to field 4.28.



The transaction amount is presented by the terminal with an implied decimal

point.  For example $.01 would be represented in the record as "001".  When the

terminal is used with an authorization system which supports the US dollar as

the primary currency, the amount field must be limited to seven digits

(9999999). [...]  The terminal may be used with authorization system which

support other currencies that require the full twelve-digit field.



4.23 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



4.24 DEVICE CODE/INDUSTRY CODE



This field is used to identify the device type which generated the transaction

and the industry type of the merchant.  Table 4.24 provides a brief summary of

the current codes.



                                   TABLE 4.24

                           Device Code/Industry Code



C                                      C

O                                      O

D                                      D

E          DEVICE TYPE                 E            INDUSTRY TYPE

-------------------------------------------------------------------------------

0   Unknown or Unsure                  0   Unknown or Unsure

1          RESERVED                    1              RESERVED

2          RESERVED                    2              RESERVED

3          RESERVED                    3              RESERVED

4          RESERVED                    4              RESERVED

5          RESERVED                    5              RESERVED

6          RESERVED                    6              RESERVED

7          RESERVED                    7              RESERVED

8          RESERVED                    8              RESERVED

9          RESERVED                    9              RESERVED

A          RESERVED                    A              RESERVED

B          RESERVED                    B   Bank/Financial Institution

C   P.C.                               C              RESERVED

D   Dial Terminal                      D              RESERVED

E   Electronic Cash Register (ECR)     E              RESERVED

F          RESERVED                    F   Food/Restaurant

G          RESERVED                    G   Grocery Store/Supermarket

H          RESERVED                    H   Hotel

I   In-Store Processor                 I              RESERVED

J          RESERVED                    J              RESERVED

K          RESERVED                    K              RESERVED

L          RESERVED                    L              RESERVED

M   Main Frame                         M   Mail Order

N          RESERVED                    N              RESERVED

O          RESERVED                    O              RESERVED

P   POS-port                           P              RESERVED

Q       RESERVED for POS-port          Q              RESERVED

R          RESERVED                    R   Retail

S          RESERVED                    S              RESERVED

T          RESERVED                    T              RESERVED

U          RESERVED                    U              RESERVED

V          RESERVED                    V              RESERVED

W          RESERVED                    W              RESERVED

X          RESERVED                    X              RESERVED

Y          RESERVED                    Y              RESERVED

Z          RESERVED                    Z              RESERVED

--------------------------------------------------------------------------------



4.25 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



4.26 ISSUING INSTITUTION ID/RECEIVING INSTITUTION ID



This six-digit field is provided by the merchant signing member and is present

when the terminal is used to process transactions which can not be routed using

the cardholder Primary Account Number.  When a value is present in this field,

it is used as an RIID for all valid transaction codes, field 4.12, except 81

through 88.  This field is used as an IIID for transaction codes 81 through 88.

Table 4.26 provides a summary of the RIID codes for check acceptance.



                                   TABLE 4.26

                          Check Acceptance RIID Values



                         Vendor                 RIID

                         ---------------------------

                         JBS, Inc             810000

                         Telecheck            861400

                         TeleCredit, West     894300 [note; telecredit has been

                         TeleCredit, East     894400  mutated/eaten by equifax]

                         ---------------------------



4.27 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



4.28 SECONDARY AMOUNT (CASHBACK)



NOTE: "Cashback" is NOT allowed on Visa cards when the Customer Data Field,

see section 4.18, has been manually entered.



This is a variable length field from three to twelve digits in length.  The

Secondary Amount is included in field 4.22, Transaction Amount.



The secondary amount is presented by the terminal with an implied decimal point.

For example $.01 would be represented in the record as "001".  This field will

contain 000 when no secondary amount has been requested.  Therefore, when the

terminal is used with an authorization system which supports the US dollar as

the primary currency, the secondary amount field must be limited to seven

digits (9999999).  The terminal may be used with authorization systems which

support other currencies that require the full twelve-digit field.



4.29 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



4.30 MERCHANT NAME



This 25-character field contains the merchant name provided by the signing

member.  the name must correspond to the name printed on the customer receipt.

The name is left justified with space fill.  The first character position can

not be a space.  This field must contain the same used in the data capture

batch.



4.32 MERCHANT STATE



This two-character field contains the merchant location state abbreviation

provided by the singing member.  The abbreviation must correspond to the state

name printed on the customer receipt and be one of the Visa accepted

abbreviations.  This field must contain the same data used in the data capture

batch.



4.33 SHARING GROUP



This one to fourteen-character field contains the group of debit card/network

types that a terminal may have access to and is provided by the singing member.

The values must correspond to one of the Visa assigned debit card /network

types.  This data is part of the VisaNet debit data.



4.34 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



4.35 MERCHANT ABA NUMBER



This fixed length field is twelve digits in length.  If this field is not used,

its length must be zero.  If this field is not used, the following field must

also be empty.



This number identifies the merchant to a debit switch provided by the signing

member.  The number is provided by the signing member.



4.36 MERCHANT SETTLEMENT AGENT NUMBER



This fixed length field is four digits in length.  If this field is not used,

its length must be zero.  If this field is not used, the previous field must

also be empty.



This number identifies the merchant settling agent.  The number is provided by

the signing member.



4.37 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



4.38 AGENT NUMBER



This six-digit field contains an agent number assigned by the signing member.

The number identifies an institution which signs merchants as an agent of a

member.  The member uses this number to identify the agent within the member

systems.  The acquirer BIN, Agent, Chain, Merchant, Store, and Terminal numbers

are required to uniquely identify a terminal within the VisaNet systems.



4.39 CHAIN NUMBER



This six-digit field contains a merchant chain identification number assigned

by the singing member.  The member uses this number to identify the merchant

chain within the member systems.  The acquirer BIN, Agent, Chain, Merchant,

Store, and Terminal numbers are required to uniquely identify a terminal within

the VisaNet systems.



4.40 BATCH NUMBER



This three-digit field contains a batch sequence number generated by the

terminal.  The number will wrap from 999 to 001.  This number is that data

capture batch number.



4.41 REIMBURSEMENT ATTRIBUTE



This is a single character fixed length field.



This field contains the reimbursement attribute assigned by the singing member.

This field must be a "space".



4.42 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



4.43 APPROVAL CODE



This contains a six-character fixed length field.



This field is only present in cancel transactions and contains the original

approval code from the original transaction.



The approval code was returned in the authorization response of the transaction

to be canceled.



4.44 SETTLEMENT DATE



This contains a four-digit fixed length field.



This field is only present in cancel transactions and contains the settlement

date from the original transaction and is in the format MMDD.



The settlement date was returned in the authorization response of the

transaction to be canceled.



4.45 LOCAL TRANSACTION DATE



This contains a four-digit fixed length field.



This field is only present in cancel transactions and contains the transaction

date from the original transaction and is in the format MMDD.



The transaction date was returned in the authorization response of the

transaction to be canceled as MMDDYY.



4.46 LOCAL TRANSACTION TIME



This contains a six-digit fixed length field.



This field is only present in cancel transactions and contains the transaction

time from the original transaction and is in the format HHMMSS.



The transaction time was returned in the authorization response of the

transaction to be canceled.



4.47 SYSTEM TRACE AUDIT NUMBER



This contains a six-character fixed length field.



This field is only present in cancel transactions and contains the trace audit

number from the original transaction.



The trace audit number was returned in the authorization response of the

transaction to be canceled.



4.48 ORIGINAL AUTHORIZATION TRANSACTION CODE



The field is a two-character fixed length field and must contain the original

AUTHORIZATION TRANSACTION CODE (filed 4.12) of the transaction to be canceled.

Currently, the only transaction that can be canceled in an Interlink Debit

Purchase.



4.49 NETWORK IDENTIFICATION CODE



This contains a single character fixed length field.



This field is only present in cancel transactions and contains the network ID

from the original transaction.



The network ID was returned in the authorization response of the transaction to

be canceled.



4.50 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



5.0 RESPONSE RECORD DATA ELEMENT DEFINITIONS



The following subsections will define the authorization response record data

elements.



5.01 PAYMENT SERVICE INDICATOR



This field contains the one-character payment service indicator.  It must be

placed in the batch detail record for terminals that capture.



Table 5.01 provides a summary of current Values.



                                   TABLE 5.01

                        Payment Service Indicator Values



        VALUE   DESCRIPTION

        ------------------------------------------------------------------

          A     REPS qualified

          Y     Requested a "Y" in field 4.14 and there was a problem

                REPS denied (VAS edit error or BASE I reject)

          N     Requested an "N" in field 4.14 or requested a "Y" in field

                4.14 and request was downgraded (by VAS)

        space   If "Y" sent and transaction not qualified  (VAS downgrade)

        -------------------------------------------------------------------



5.02 STORE NUMBER



This four-digit number is returned by VisaNet from the authorization request for

formats "J" and "G", and can be used to route the response within a store

controller and/or a store concentrator.



5.03 TERMINAL NUMBER



This four-digit number is returned by VisaNet from the authorization request for

formats "J" and "G", and can be used to route the response within a store

controller and/or a store concentrator.



5.04 AUTHORIZATION SOURCE CODE



This field contains a one-character code that indicates the source of the

authorization.  The received code must be placed in the data capture detail

transaction record when data capture is enabled.



Table 5.04 provides a summary of current codes.



                                   TABLE 5.04

                           Authorization Source Codes



 Code   Description

--------------------------------------------------------------------------------

  1     STIP: time-out response

  2     LCS: amount below issuer limit

  3     STIP: issuer in Suppress-Inquiry mode

  4     STIP: issuer unavailable

  5     Issuer approval

  6     Off-line approval, POS device generated

  7     Acquirer approval: BASE I unavailable

  8     Acquirer approval of a referral

  9     Use for non-authorized transactions; such as credit card credits [yum!]

  D     Referral: authorization code manually keyed

  E     Off-line approval: authorization code manually keyed

--------------------------------------------------------------------------------



5.05 TRANSACTION SEQUENCE NUMBER



This field contains the four-digit code which was generated by the terminal as

the sequence number for the transaction and passed to the authorization center

in the authorization request record.  The sequence number can be used by the

terminal to match request and response messages.  The transaction sequence

number is returned by VisaNet without sequence verification.



5.06 RESPONSE CODE



This field contains a two-character response code indicating the status of the

authorization.



Table 5.06 provides the response codes for formats "J" and "G".  A response code

of "00" represents an approval.  A response code of "85" represents a successful

card verification returned by TRANSACTION CODES 58, 68, and 88.  All other

response codes represent a non-approved request.



The value returned is stored in the batch transaction detail record for

terminals that capture.



                                   TABLE 5.06

           Authorization Response Codes For Record Formats "J" & "G"



  Authorization     Response                                        AVS Result

 Response Message     Code       Response Definition                   Code

--------------------------------------------------------------------------------

   EXACT MATCH         00        Exact Match, 9 digit zip               X

   EXACT MATCH         00        Exact Match, 5 digit zip GRIND         Y

  ADDRESS MATCH        00        Address match only                     A

    ZIP MATCH          00        9-digit zip match only                 W

    ZIP MATCH          00        5-digit zip match only GRIND           Z

     NO MATCH          00        No address or zip match                N

 VER UNAVAILABLE       00        Address unavailable                    U

      RETRY            00        Issuer system unavailable              R

 ERROR INELIGIBLE      00        Not a mail/phone order                 E

 SERV UNAVAILABLE      00        Service not supported                  S

    APPROVAL           00        Approved and completed              see above

     CARD OK           85        No reason to decline                see above

      CALL             01        Refer to issuer                        0

      CALL             02        Refer to issue - Special condition     0

    NO REPLY           28        File is temporarily unavailable        0

    NO REPLY           91        Issuer or switch is unavailable        0

    HOLD-CALL          04        Pick up card                           0

    HOLD-CALL          07        Pick up card - Special condition       0

    HOLD-CALL          41        Pick up card - Lost                    0

    HOLD-CALL          43        Pick up card - Stolen                  0

 ACCT LENGTH ERR       EA        Verification Error                     0

 ALREADY REVERSED      79        Already Reversed at Switch [ya got me] 0

   AMOUNT ERROR        13        Invalid amount                         0

  CAN'T VERIFY PIN     83        Can not verify PIN                     0

   CARD NO ERROR       14        Invalid card number                    0

  CASHBACK NOT APP     82        Cashback amount not approved           0

   CHECK DIGIT ERR     EB        Verification Error                     0

  CID FORMAT ERROR     EC        Verification Error                     0

     DATE ERROR        80        Invalid Date                           0

      DECLINE          05        Do not honor                           0

      DECLINE          51        Not Sufficient Funds                   0

      DECLINE          61        Exceeds Withdrawal Limit               0

      DECLINE          65        Activity Limit Exceeded                0

 ENCRYPTION ERROR      81        Cryptographic Error                    0

      ERROR xx         06        General Error                          0

     ERROR xxxx        06        General Error                          0

    EXPIRED CARD       54        Expired Card                           0

  INVALID ROUTING      98        Destination Not Found                  0

   INVALID TRANS       12        Invalid Transaction                    0

  NO CHECK ACCOUNT     52        No Check Account                       0

  NO SAVE ACCOUNT      54        No Save Account                        0

   NO SUCH ISSUER      15        No Such Issuer                         0

      RE ENTER         19        Re-enter Transaction                   0

    SEC VIOLATION      63        Security Violation                     0

   SERV NOT ALLOWED    57        Trans. not permitted-Card              0

   SERV NOT ALLOWED    58        Trans. not permitted-Terminal          0

   SERVICE CODE ERR    62        Restricted Card                        0

     SYSTEM ERROR      96        System Malfunction [whoop whoop!]      0

     TERM ID ERROR     03        Invalid Merchant ID                    0

      WRONG PIN        55        Incorrect PIN                          0

  xxxxxxxxxxxxxxxxxx   xx        Undefined Response                     0

--------------------------------------------------------------------------------



5.07 APPROVAL CODE



This field contains a six-character code when a transaction has been approved.

If the transaction is not approved the contents of the field should be ignored.

The approval code is input to the data capture detail transaction record.



5.08 LOCAL TRANSACTION DATE



This field contains a six-digit local date calculated (MMDDYY) by the

authorization center using the time zone differential code provided in the

authorization request message.  This date is used by the terminal as the date to

be printed on the transaction receipts and audit reports, and as the date input

to the data capture transaction detail record.  This field is only valid for

approved transactions.



5.09 AUTHORIZATION RESPONSE MESSAGE



This field is a sixteen-character field containing a response display message.

This message is used by the terminal to display the authorization results.

Table 5.06 provides the message summary.   The messages are provided with "sp"

space fill.  This field is mapped to the RESPONSE CODE, field 5.06, for all

non-AVS transactions and for all DECLINED AVS transactions.  For APPROVED AVS

transactions (response code = "00" or "85"), it is mapped to the AVS RESULT

CODE, field 5.10.



5.10 AVS RESULT CODE



This one-character field contains the address verification result code.  An

address verification result code is provided for transactions and provides an

additional indication that the card is being used by the person to which the

card was issued.  The service is only available for mail/phone order

transactions.



Table 5.06 provides a summary of the AVS Result Codes.



An ANSI X3.4 "0" is provided for all non-AVS transactions and all declined

transactions.



5.11 TRANSACTION IDENTIFIER



This numeric field will contain a transaction identifier.  The identifier will

be fifteen-digits in length if the payment service indicator value is an "A" or

it will be zero in length if the payment service indicator value is not an "A".

This value is stored in the batch detail record for terminals that capture and

is mandatory for REPS qualification.



5.12 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



5.13 VALIDATION CODE



This alphanumeric field will contain a validation code.  The code will contain a

four-character value if the payment service indicator value is an "A" or it will

be zero in length if the payment service indicator value is not an "A".  This

value is stored in the batch detail record for terminals that capture and is

mandatory for REPS qualification.



5.14 FIELD SEPARATOR



The authorization record format specifies the use of the "FS" character.



5.15 NETWORK IDENTIFICATION CODE



This one-character fixed length field contains the identification code of the

network on which the transaction was authorized.  The network ID must be printed

on the receipt.



5.16 SETTLEMENT DATE



This four-digit fixed length field contains the transaction settlement date

returned by the authorizing system (MMDD).  The settlement date must be printed

on the receipt.



5.17 SYSTEM TRACE AUDIT NUMBER



This six-character fixed length field contains a trace audit number which is

assigned by the authorizing system.  The trace audit number must be printed on

the receipt.



5.18 RETRIEVAL REFERENCE NUMBER



This twelve-character fixed length field contains the transaction retrieval

reference number returned by the authorizing system.  The reference number

should be printed on the receipt.



5.19 LOCAL TRANSACTION TIME



This six-digit fixed length field contains the transaction time returned by the

authorizing system (HHMMSS).  The time must be printed on the receipt.



6.0 CONFIRMATION RECORD DATA ELEMENT DEFINITIONS



The following subsections define the debit confirmation response record data

elements.



6.01 NETWORK IDENTIFICATION CODE



This one character fixed length field contains the identification code of the

network on which the transaction was authorized.  The network ID is printed on

the receipt.



6.02 SETTLEMENT DATE



This four-digit fixed length field contains the transaction settlement date

returned by the authorizing system.



6.03 SYSTEM TRACE AUDIT NUMBER



This six-character fixed length field contains the system trace audit number

which is assigned by the authorizing system.



7.0 CHARACTER CODE DEFINITIONS



The following subsections will define the authorization request record character

set and character sets used for track 1 and track 2 data encoded on the magnetic

stripes.



The authorization request records are generated with characters defined by ANSI

X3.4-1986.  The data stored on the cardholder's card in magnetic or optical form

must be converted to the ANSI X3.4 character set before transmission to VisaNet.



Section 7.01 provides track 1 character set definition.  Section 7.02 provides

track 2 character set definition.  Section 7.03 provides the ANSI X3.4-1986 and

ISO 646 character set definitions.  Section 7.04 provides a cross reference

between the track 1, track 2, and ANSI X3.4 character sets.  Section 7.05

describes the method for generating and checking the Mod 10 Luhn check digit for

credit card account numbers.  Section 7.06 describes the method for generating

the LRC byte for the authorization request message and for testing the card

swipe's LRC byte.  Section 7.07 provides sample data for an authorization

request and response for record format "J" testing.



The POS device/authorization must perform the following operations on track

read data before it can be used in an authorization request message.



   1. The LRC must be calculated for the data read from the track and compared

      to the LRC read from the track.  The track data is assumed to be read

      without errors when on character parity errors are detected and the

      calculated and read LRC's match.



   2. The starting sentinel, ending sentinel, and LRC are discarded.



   3. The character codes read from the magnetic stripe must be converted from

      the encoded character set to the set used for the authorization request

      message.  The characters encoded on track 1 are six-bit plus parity codes

      and the characters encoded on track 2 are four-bit plus parity codes, with

      the character set used for the request message defined as seven-bit plus

      parity codes.



All characters read from a track must be converted to the request message

character set and transmitted as part of the request.  The converted track data

can not be modified by adding or deleting non-framing characters and must be a

one-for-one representation of the characters read from the track.  [sounds like

they mean it, eh?]



7.1 TRACK 1 CHARACTER DEFINITION



Table 7.01 provides the ISO 7811-2 track 1 character encoding definitions.  This

"standards" format is a SAMPLE guideline for expected credit card track

encoding; ATM/debit cards may differ.  Actual cards may differ [not], whether

they are Visa cards or any other issuer's cards.



Each character is defined by the six-bit codes listed in Table 7.01.



Track 1 can be encoded with up to 79 characters as shown in Figure 7.01



+---------------------------------------------------------+

|SS|FC| PAN|FS|  NAME|FS| DATE| DISCRETIONARY DATA |ES|LRC|

+---------------------------------------------------------+



LEGEND:



             Field  Description                                  Length  Format

--------------------------------------------------------------------------------

                SS  Start Sentinel                                 1        %

                FC  Format Code ("B" for credit cards)             1       A/N

               PAN  Primary Account Number                      19 max     NUM

                FS  Field Separator                                1        ^

              NAME  Card Holder Name (See NOTE below)           26 max     A/N

                FS  Field Separator                                1        ^

              DATE  Expiration Date (YYMM)                         4       NUM

Discretionary Data  Option Issuer Data (See NOTE below)         variable   A/N

                ES  End Sentinel                                   1        ?

               LRC  Longitudinal Redundancy Check                  1

                                                                  ---

                    Total CAN NOT exceed 79 bytes----->           79

--------------------------------------------------------------------------------



                                  FIGURE 7.01

                          Track 1 Encoding Definition



NOTE: The CARD HOLDER NAME field can include a "/" as the surname separator

      and a "." as the title separator



      The DISCRETIONARY DATA can contain any of the printable characters from

      Table 7.01



                                   TABLE 7.01

                          Track 1 Character Definition



                       b6   0   0   1   1

BIT NUMBER             b5   0   1   0   1      (a) These character positions

-------------------------------------------        are for hardware use only

b4 b3 b2 b1    ROW/COL      0   1   2   3

-------------------------------------------    (b) These characters are for

0  0  0  0        0        SP   0  (a)  P          country use only, not for

0  0  0  1        1        (a)  1   A   Q          international use

0  0  1  0        2        (a)  2   B   R

0  0  1  1        3        (c)  3   C   S      (c) These characters are

0  1  0  0        4         $   4   D   T          reserved for added

0  1  0  1        5        (%)  5   E   U          graphic use [nifty]

0  1  1  0        6        (a)  6   F   V

0  1  1  1        7        (a)  7   G   W

1  0  0  0        8         (   8   H   X      (%) Start sentinel

1  0  0  1        9         )   9   I   Y      (/) End sentinel

1  0  1  0        A        (a) (a)  J   Z      (^) Field Separator

1  0  1  1        B        (a) (a)  K  (b)      /  Surname separator

1  1  0  0        C        (a) (a)  L  (b)      .  Title separator

1  1  0  1        D         -  (a)  M  (b)      SP Space

1  1  1  0        E         -  (a)  N  (^)      +-----------------------+

1  1  1  1        F         /  (?)  O  (a)      |PAR|MSB|B5|B4|B3|B2|LSB|

                                                +-+---+-----------------+

                                                  |   |--- Most Significant Bit

                                                  |--- Parity Bit (ODD)

                                               Read LSB First



7.02 TRACK 2 CHARACTER DEFINITION



Table 7.02 provides the ISO 7811-2 track 2 character encoding definitions.  This

"standards" format is a SAMPLE guideline for expected credit card track

encoding; ATM/debit cards may differ.  Actual cards may differ, whether they are

Visa cards or any other issuer's cards.



Each character is defined by the four-bit codes listed in Table 7.02.



Track 2 can be encoded with up to 40 characters as shown in Figure 7.02.



+--------------------------------------------------------+

|SS|    PAN   |FS| DATE|    DISCRETIONARY DATA    |ES|LRC|

+--------------------------------------------------------+



LEGEND:



             Field  Description                                  Length  Format

--------------------------------------------------------------------------------

                SS  Start Sentinel                                 1     0B hex

               PAN  Primary Account Number                      19 max     NUM

                FS  Field Separator                                1        =

Discretionary Data  Option Issuer Data (See NOTE below)         variable   A/N

                ES  End Sentinel                                   1     0F hex

               LRC  Longitudinal Redundancy Check                  1

                                                                  ---

                    Total CAN NOT exceed 40 bytes----->           40

--------------------------------------------------------------------------------



                                  FIGURE 7.02

                          Track 2 Encoding Definition



NOTE: The PAN and DATE are always numeric.  The DISCRETIONARY DATA can be

      numeric with optional field separators as specified in Table 7.02.





                                   TABLE 7.02

                             Track 2 Character Set



b4  b3  b2  b1     COL              (a) These characters are for

------------------------------          hardware use only

0   0   0   0       0      0

0   0   0   1       1      1        (B) Starting Sentinel

0   0   1   0       2      2

0   0   1   1       3      3        (D) Field Separator

0   1   0   0       4      4

0   1   0   1       5      5        (F) Ending Sentinel

0   1   1   0       6      6

0   1   1   1       7      7

1   0   0   0       8      8        +---------------------------+

1   0   0   1       9      9        | PAR | MSB | b3 | b2 | LSB |

1   0   1   0       A     (a)       +---------------------------+

1   0   1   1       B     (B)          |     |

1   1   0   0       C     (a)          |     |--- Most Significant Bit

1   1   0   1       D     (D)          |--- Parity Bit (ODD)

1   1   1   0       E     (a)

1   1   1   1       F     (F)        Read LSB first



[ tables 7.03a, 7.03b, and 7.04 deleted...

  If you really need a fucking ascii table that bad go buy a book.]



[ section 7.05 - Account Data Luhn Check deleted...

  as being unnecessary obtuse and roundabout in explaining how the check works.

  the routine written by crazed luddite and murdering thug is much clearer. ]



7.06 CALCULATING AN LRC



When creating or testing the LRC for the read of the card swipe, the

authorization request record, the debit confirmation record or the VisaNet

response record; use the following steps to calculate the LRC:



1) The value of each bit in the LRC character, excluding the parity bit, is

   defined such that the total count of ONE bits encoded in the corresponding

   bit location of all characters of the data shall be even (this is also known

   as an EXCLUSIVE OR (XOR) operation)



      For card swipes, include the start sentinel, all the data read and

      the end sentinel.



      For VisaNet protocol messages, begin with the first character past

      the STX, up to and including the ETX.



2) The LRC characters parity bit is not a parity bit for the individual parity

   bits of the data message, but it only the parity bit for the LRC character

   itself.  Calculated as an even parity bit.



[ i list a routine for calculating an LRC o a string later on in the document ]



7.07 TEST DATA FOR RECORD FORMAT "J"



The following two sections provide sample data for testing record format "J"

with the VisaNet dial system.



7.07.01 TEST DATA FOR A FORMAT "J" AUTHORIZATION REQUEST



Table 7.07a provides a set of test data for record format "J" authorization

request.



                                  TABLE 7.07a

                        Test Data For Record Format "J"



 Test Data      Byte #   Length   Format   Field Name

--------------------------------------------------------------------------------

     J            1         1       A/N    Record Format

 0, 2, or 4       2         1       A/N    Application Type

     .            3         1       A/N    Message Delimiter

   401205        4-9        6       A/N    Acquirer BIN

123456789012    10-21       12      NUM    Merchant Number

    0001     *  22-25       4       NUM    Store Number

    0001     *  26-29       4       NUM    Terminal Number

    5999        30-33       4       NUM    Merchant Category Code

    840         34-36       3       NUM    Merchant Country Code

   94546        37-41       5       A/N    Merchant City Code

    108         42-44       3       NUM    Time Zone Differential

    54          45-46       2       A/N    Authorization Transaction Code

  12345678      47-54       8       NUM    Terminal Identification Number

     Y           55         1       A/N    Payment Service Indicator

    0001     *  56-59       4       NUM    Transaction Sequence Number

     @           60         1       A/N    Cardholder Identification Code

D, H, T, or X    61         1       A/N    Account Data Source

 Track or                                  Customer Data Field

Manual Data

    "FS"        N.A.        1       "FS"   Field Separator

  0000123       N.A.      0 to 43   A/N    Transaction Amount

    "FS"        N.A.        1       "FS"   Field Separator

     ER         N.A.      0 or 2    A/N    Device Code/Industry code

    "FS"        N.A.        1       "FS"   Field Separator

                N.A.      0 or 6    NUM    Issuing/Receiving Institution ID

    "FS"        N.A.        1       "FS"   Field Separator

    000         N.A.      3 to 12   NUM    Secondary Amount (Cashback)

    "FS"        N.A.        1       "FS"   Field Separator

--------------------------------------------------------------------------------



NOTE:* Denotes fields that are returned in the response message



7.07.2 RESPONSE MESSAGE FOR TEST DATA



Table 7.07b provides the response message for the test data provided in section

7.07.1.



                                  TABLE 7.07b

               Response Message For Test Data - Record Format "J"



 Test Data      Byte #   Length   Format   Field Name

--------------------------------------------------------------------------------

A, Y, N, or   *   1        1       A/N     Payment Service Indicator

 "space"

   0001       *  2-5       4       NUM     Store Number

   0001       *  6-9       4       NUM     Terminal Number

    5         *   1        1       A/N     Authorization Source Code

   0001       * 11-14      4       NUM     Transaction Sequence Number

    00        * 15-16      2       A/N     Response Code

  12AB45      * 17-22      6       A/N     Approval Code

  111992      * 23-28      6       NUM     Transaction Date (MMDDYY)

AP ______       29-44      16      A/N     Authorization Response Message

0, Sp, or "FS"   45        1       A/N     AVS Result Code

              *Variable  0 or 15   NUM     Transaction Identifier

    "FS"                           "FS"    Field Separator

              *Variable  0 or 4    A/N     Validation Code

    "FS"                           "FS"    Field Separator

--------------------------------------------------------------------------------

NOTE: * Move to data capture record for VisaNet Central Data Capture (CDC)

--------------------------------------------------------------------------------



                                [ section two ]

                              [ finding visanet ]



finding visanet isn't hard, but it can be tedious.  visanet rents time off of

compuserve and X.25 networks.  the compuserve nodes used are not the same

as their information service, cis.  to identify a visanet dialup after

connecting, watch for three enq characters and a three second span to hangup.

if you've scanned out a moderate portion of your area code, you probably have a

few dialups.  one idea is to write a short program to dial all the connects you

have marked as garbage or worthless [ you did keep em, right? ]  and wait

for the proper sequence.  X.25 connections should work similarly, but i don't

know for sure.  read the section on visanet usage for other dialup sources.



                                [ section three ]

                        [ visanet link level protocol ]



messages to/from visanet have a standard format:



    stx - message - etx - lrc



the message portion is the record formats covered in section one.  lrc values

are calculated starting with the first byte of message, going up to and

including the etx character.  heres an algorithm that calculates the lrc for a

string. note: in order to work with the visanet protocols, append etx to the

string before calling this function.



unsigned char func_makelrc(char *buff)

{

   int i;

   char ch, *p;



   ch = 0;

   p = buff;



   for(;;)  {

      ch = (ch^(*p));

      p++;

      if(!(*p))

         break;

   }



   return ch;

}



for a single authorization exchange, the easiest kind of transaction, the

sequence goes like this:



host   enq                   stx-response-etx-lrc   eot

term      stx-request-etx-lrc                    ack

                                                          



matching this sequence with test record formats from section one, 7.07, heres

an ascii representation of a transaction.  control characters denoted in <>'s.

[of course, you wouldn't really have a carriage return in middle of a message.

duh. ]  this transaction would be for card number 4444111122223333 with an

expiration date of 04/96.  the purchase amount is $1.23.  visanet responds with

an approval code of 12ab45.



host: 



term: J0.401205123456789012000100015999840945461085412345678Y0001@H444411

      112222333304960000123ER000



host: Y00010001500010012AB45111992APPROVAL 12AB45123456789012345

      ABCD



term: 



host: 



authorizing multiple transactions during one connect session is only slightly

more complicated.  the etx character on all messages sent to visanet are changed

to etb and the application type is changed from '0' to '2' [section one 4.02].

instead of responding after a transaction with eot, visanet instead polls the

terminal again with enq.  this continues until the terminal either changes back

to the single transaction format or issues an eot to the host.



heres a short list of all control characters used:



stx: start-of-text, first message framing character signaling message start

etx: end-of-text, the frame ending character the last message of a sequence

eot: end-of-transmission, used to end an exchange and signal disconnect

enq: enquiry, an invitation to transmit a message or retransmit last item

ack: affirmative acknowledgment, follows correct reception of message

nak: negative acknowledgment, used to indicate that the message was not

     understood or was received with errors

syn: delay character, wait thirty seconds

etb: end-of-block, the end framing character used to signal the end of a message

     within a multiple message sequence



other quick notes: visanet sometimes sends ack before stx on responses

                   lrc characters can hold any value, such as stx, nak, etc

                   visanet can say goodbye at any time by sending eot

                   people can get very anal about error flow diagrams



                                [ section four ]

                    [ half the story; central data capture ]



a full transaction requires two steps, one of which is described in this

document: getting the initial authorization.  an authorization does basically

nothing to a person's account.  oh, you could shut somebody's account down for

a day or two by requesting a twenty thousand dollar authorization, but no other

ill effects would result.  central data capture, the second and final step in a

transaction, needs information from both the authorization request and

response, which is used to generate additional data records.  these records are

then sent to visanet by the merchant in a group, usually at the end of each day.



                                [ section five ]

                            [ common applications ]



access to visanet can be implemented in a number of ways: directly on a pos

terminal, indirectly via a lan, in a hardware specific device, or any

permutation possible to perform the necessary procedures.  card swipers commonly

seen at malls are low tech, leased at around fifty dollars per month, per

terminal.  they have limited capacity, but are useful in that all of the

information necessary for transactions is self contained.  dr delam and maldoror

found this out, and were delighted to play the role of visanet in fooling the

little device.  close scrutiny of section one reveals atm formats, phone order

procedures, and new services such as direct debit from checking/savings and

checks by phone.  start noticing the stickers for telecheck and visa atm cards,

and you're starting to get the picture.



                               [ section seven ]

                              [ brave new world ]



could it be?  yes, expiration dates really don't matter....

this article written to thank previous Phrack writers...

please thank me appropriately...

800#s exist...

other services exist... mastercard runs one...

never underestimate the power of asking nicely...

numerous other formats are available... see section one, 3.0 for hints...

never whistle while you're pissing...



Manifest
Le but de ce site est de mieux comprendre la sécurité informatique.
Un hacker par définition est une personne qui cherche à améliorer les systèmes d'information dans le seul et unique but de contribuer à la stabilité de ces systèmes!
La croyance populaire laisse entendre que les hackers sont des pirates.
C'est vrai. Mais il y a différents types de pirate.
Tout comme il y a différents types de personnes.
Les bavures courantes auxquelles on pense lorsqu'on évoque le terme de pirate informatique
seraient les hacks de compte msn, ordinateurs lâchement trojantés avec des exploits déjà tous faits
et encore peut-on classifier en tant que hack le fait de spammer
alors que depuis plus de 15 ans des scripts tous faits le font extrêmement bien?

Ce ne sont pas des hackers qui font ça!!!
Nous appelons ces gens des lammers! Quand ils sont mauvais,
ou des black hat lorsqu'ils sont doués dans la mise en application de leurs méfaits.
Aucun amour propre - Aucune dignité
Agissent par dégout, vengeance ou simple plaisir.
Les raisons peuvent être nombreuses et je ne prétends pas devoir juger qui que ce soit.
Je pense juste que l'on ne doit pas utiliser l'épée de fly pour commettre des injustices.
Il est 100 fois plus profitable d'améliorer un système que de marcher sur un château de sable... même si marcher sur un château de sable est rigolo :P
A vous de trouver votre amusement. ;)

Tu peux réagir sur la shootbox


Disclaimer Veuillez lire obligatoirement les règles ci-dessous avant de consulter ce site.
Conformément aux dispositions des différentes lois en vigueur, intrusions et maintenances frauduleuses sur un site, vol et / ou falsification de données.
Vous ne devez en aucun cas mettre en application les stratagèmes mis en place par ce site, qui sont présentés uniquement à titre d’éducation et de recherche dans le domaine de la protection de données.
Vous ne devez en aucun cas utiliser ce que vous aurez découvert, sauf si vous avez une autorisation écrite de l’administrateur d’un site ou que celui-ci vous ai ouvert un compte uniquement pour la recherche de failles.
Tout cela est interdit et illégal ne faites pas n'importe quoi.
Vous acceptez donc que l'administrateur de ce site n'est en aucun cas responsable d'aucun de vos actes. Sinon quittez ce site.
Vous êtes soumis à ce disclaimer.
ET À CE TITRE, NI LA COMMUNAUTÉ, NI L'ADMINISTRATEUR, NI L'HÉBERGEUR, NE POURRONT, NI NE SERONT RESPONSABLE DE VOS ACTES.