SENHA
Olá pessoal, abaixo tem um codigo para descobrir a senha do banco de dados ACCESS, eu gostaria que alguém pudesse me explicar passoa a passo qual a lógica desse cod?, se possÃvel detalhadamente, como que eles sabiam que isso iria chegar na senha? Como eles chegaram a esta conclusão?
============================================================
Dim n As Long, s1 As String * 1, s2 As String * 1
Dim lsClave As String
Open "c:\Banco.mdb" For Binary As #1
Open text1.text For Binary As #2
Seek #1, &H43
Seek #2, &H43
For n = 1 To 40 Step 2
s1 = Input(1, 1)
s2 = Input(1, 2)
If (Asc(s1) Xor Asc(s2)) <> 0 Then
lsClave = lsClave & Chr(Asc(s1) Xor Asc(s2))
End If
s1 = Input(1, 1)
s2 = Input(1, 2)
Next
Close 1
Close 2
MsgBox "A senha é...:" & lsClave
att,
Rodrigo Porto
============================================================
Dim n As Long, s1 As String * 1, s2 As String * 1
Dim lsClave As String
Open "c:\Banco.mdb" For Binary As #1
Open text1.text For Binary As #2
Seek #1, &H43
Seek #2, &H43
For n = 1 To 40 Step 2
s1 = Input(1, 1)
s2 = Input(1, 2)
If (Asc(s1) Xor Asc(s2)) <> 0 Then
lsClave = lsClave & Chr(Asc(s1) Xor Asc(s2))
End If
s1 = Input(1, 1)
s2 = Input(1, 2)
Next
Close 1
Close 2
MsgBox "A senha é...:" & lsClave
att,
Rodrigo Porto
Não serei capaz de explicar TUDO passo-a-passo, mas vou colaborar:
'Declaramos variáveis
Dim n As Long, s1 As String * 1, s2 As String * 1
Dim lsClave As String
'Abrimos o arquivo .mdb num arquivo binário (para procurar bites especÃficos)
Open "c:\Banco.mdb" For Binary As #1
Open text1.text For Binary As #2
'Returns aLong specifying the current read/write position within
'a file opened using the Open statement.
Seek #1, &H43
Seek #2, &H43
For n = 1 To 40 Step 2
'Imput : ReturnsString containing characters from a file opened in Input or Binary mode.
s1 = Input(1, 1)
s2 = Input(1, 2)
'Caso exista algum caracter nesta posição:
If (Asc(s1) Xor Asc(s2)) <> 0 Then
lsClave = lsClave & Chr(Asc(s1) Xor Asc(s2))
End If
s1 = Input(1, 1)
s2 = Input(1, 2)
Next
Close 1
Close 2
MsgBox "A senha é...:" & lsClave
Resumindo, o cara descobriu que a senha é guardada nesta posição binária do arquivo e utiliza estas funções para recuperála.
Infelizmente o Acces não utiliza nenhuma funcionalidade de encriptação para maquiar esta informação; talvez isto se explica pelo fado da necessidade de manter compatibilidade com outros sistemas e de outros fabricantes.
Muito útil inclusive seu post para quem fica se matando de tentar encontrar formas de segurança para database acess. eu particularmente desisti
'Declaramos variáveis
Dim n As Long, s1 As String * 1, s2 As String * 1
Dim lsClave As String
'Abrimos o arquivo .mdb num arquivo binário (para procurar bites especÃficos)
Open "c:\Banco.mdb" For Binary As #1
Open text1.text For Binary As #2
'Returns aLong specifying the current read/write position within
'a file opened using the Open statement.
Seek #1, &H43
Seek #2, &H43
For n = 1 To 40 Step 2
'Imput : ReturnsString containing characters from a file opened in Input or Binary mode.
s1 = Input(1, 1)
s2 = Input(1, 2)
'Caso exista algum caracter nesta posição:
If (Asc(s1) Xor Asc(s2)) <> 0 Then
lsClave = lsClave & Chr(Asc(s1) Xor Asc(s2))
End If
s1 = Input(1, 1)
s2 = Input(1, 2)
Next
Close 1
Close 2
MsgBox "A senha é...:" & lsClave
Resumindo, o cara descobriu que a senha é guardada nesta posição binária do arquivo e utiliza estas funções para recuperála.
Infelizmente o Acces não utiliza nenhuma funcionalidade de encriptação para maquiar esta informação; talvez isto se explica pelo fado da necessidade de manter compatibilidade com outros sistemas e de outros fabricantes.
Muito útil inclusive seu post para quem fica se matando de tentar encontrar formas de segurança para database acess. eu particularmente desisti
Ok, Access não tem segurança mesmo.
Cabe a você analizar a quem ira desenvolver,
que tipo de projeto sera, qual os riscos e quais
as consequencias caso alguém descubra a senha.
A partir dai você passa ao cliente os custos baseado
em access e a um outro banco considerado seguro.
Cabe a você analizar a quem ira desenvolver,
que tipo de projeto sera, qual os riscos e quais
as consequencias caso alguém descubra a senha.
A partir dai você passa ao cliente os custos baseado
em access e a um outro banco considerado seguro.
Então quer dizer que isso também dá para fazer em programas em VB.
A maioria das pessoas fazem a conexão com o Banco de Dados pelo Load do form, daà então ficaria muito fácil de descobrir a senha do Banco lendo o arquivo executável em binário, estou certo?
att,
Rodrigo
A maioria das pessoas fazem a conexão com o Banco de Dados pelo Load do form, daà então ficaria muito fácil de descobrir a senha do Banco lendo o arquivo executável em binário, estou certo?
att,
Rodrigo
Eu faço um arquivo .INI com a string de conexão criptografada e no load eu carrego esse arquivo... acho que fica mais dificil de descobrir a senha. Deixar senhas dentro do programa é realmente um risco, já que temos diversos leitores hexadecimais que facilmente mostra o "dump" do programa.
Realmente essa é uma boa idéia André, talvez eu implante essa idéia em meus projetos, pois estou trabalhando num projeto e não quero correr muitos riscos na área de proteção. Se alguém tiver algum artigo excelente que fale sobre PROTEÇÃO, como os crakers trabalham, e o que eles fazem para quebrar programas, qual a técnica utilizada, me mande por favor.
att,
Rodrigo Porto
att,
Rodrigo Porto
Mas veja bem, criptografar seu .exe não agrega segurança ao arquivo .mdb que tem diversas fragilidades se for para ambiente multiusuário conforme meu post em outro tópico.
http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=187830&varPagina=2
Se o objetivo for segurança a opção correta é utilizar um SGBD e a melhor dica que vejo é o MS SQL server 2005 Express (Free e perfeitamente escalonável)
Facil de migrar a partir do .mdb e praticamente sem trabalho caso seja necessário a versão para grandes empresas se um dia chegar a esta necessidade.
http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=187830&varPagina=2
Se o objetivo for segurança a opção correta é utilizar um SGBD e a melhor dica que vejo é o MS SQL server 2005 Express (Free e perfeitamente escalonável)
Facil de migrar a partir do .mdb e praticamente sem trabalho caso seja necessário a versão para grandes empresas se um dia chegar a esta necessidade.
Olá Emerson Tadeu, vejo que és um rapaz que tem muitos conhecimentos, te agradeço pelas dicas. Por acaso existe algum BD atual que ainda não conseguiram quebrar sua proteção?
att,
Rodrigo Porto
att,
Rodrigo Porto
Aqui não funcionou... o que vai em Text1.text?
Olá André, esta quebra de banco é para o Access 2000 e eu achei no próprio site, depois vc dá uma olhadinha. Valeu.
att,
Rodrigo Porto
att,
Rodrigo Porto
Leia os topicos abaixo:
1º http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=188722
2º http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=187830&varPagina=2
Além disto em vários posts venho explicando que nem Access ou qualquer Sistema de armazenamento de informação através de arquivo (.mdb, .dbf, .txt, .dat) que seja acessado diretamente pode ser lá o que for tem proteção consistente num ambiente corporativo (rede e multi-user).
Para segurança plena somente utilizando um SGBD que cria uma interface entre o user/aplicativo e os arquivos depósitos de dados que só podem ser gerenciados pela aplicação isolando-os da exposição direta na rede.
1º http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=188722
2º http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=187830&varPagina=2
Além disto em vários posts venho explicando que nem Access ou qualquer Sistema de armazenamento de informação através de arquivo (.mdb, .dbf, .txt, .dat) que seja acessado diretamente pode ser lá o que for tem proteção consistente num ambiente corporativo (rede e multi-user).
Para segurança plena somente utilizando um SGBD que cria uma interface entre o user/aplicativo e os arquivos depósitos de dados que só podem ser gerenciados pela aplicação isolando-os da exposição direta na rede.
Tópico encerrado , respostas não são mais permitidas