☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sexta-feira, 26 de maio de 2017

🎮 Isekai List 2017

 

Bellacosa Mainframe apresenta a lista de isekai em 2017

☕ Um Café no Bellacosa Mainframe

2017 — O Ano em que o Isekai Virou Linha de Produção

Se 2015 apresentou o sucesso de Overlord e 2016 consolidou o gênero com obras como Re:Zero e KonoSuba, 2017 foi o ano em que a indústria percebeu que havia encontrado uma mina de ouro.

Foi praticamente como descobrir um novo compilador COBOL capaz de transformar uma única especificação em dezenas de programas diferentes.

Os estúdios passaram a adaptar light novels em ritmo industrial.

Truck-kun praticamente ganhou carteira assinada.

A tela de login do outro mundo passou a ser um item obrigatório em cada temporada.

Mas seria injusto dizer que todos eram iguais.

2017 trouxe alguns experimentos muito interessantes:

  • um restaurante que servia dois mundos;

  • um smartphone levado para um universo medieval;

  • um mundo inspirado no período Sengoku;

  • uma fantasia baseada em MMORPG;

  • um herói extremamente poderoso;

  • e até um isekai onde o protagonista praticamente administra sua nova vida sem grandes preocupações.

Foi também um ano que consolidou vários clichês:

  • Guildas de aventureiros

  • Cartões de status

  • Magia por níveis

  • Reencarnação

  • Invocação

  • Harém

  • Cheat Skills

  • Demônio Rei

  • RPG medieval

A partir dali, praticamente todos os anos passariam a lançar dezenas de isekais. (Banco de Personagens de Anime)



Os Principais Isekais de 2017

1) Isekai wa Smartphone to Tomo ni.

Título original: 異世界はスマートフォンとともに。
Título internacional: In Another World With My Smartphone

Episódios: 12

Resumo

Touya Mochizuki morre por acidente após um erro divino.

Como pedido de desculpas, Deus permite que ele renasça em outro mundo levando seu smartphone.

O aparelho continua funcionando graças à energia divina.

Logo Touya se torna praticamente invencível.

Personagens

  • Touya Mochizuki

  • Yumina

  • Elze

  • Linze

  • Yae

  • Leen

  • Sushie

O que o diferenciava

Foi um dos primeiros grandes sucessos do subgênero "protagonista absurdamente overpower".

O smartphone funciona como:

  • GPS

  • câmera

  • biblioteca

  • mapa

  • calculadora

  • pesquisa

Praticamente um Google portátil medieval.

Easter Eggs

  • várias magias lembram RPGs clássicos;

  • referências discretas a MMORPGs;

  • inúmeras piadas com tecnologia moderna em ambiente medieval.


2) Isekai Shokudou

Título original: 異世界食堂

Título internacional: Restaurant to Another World

Episódios: 12

Resumo

Todos os sábados uma pequena porta conecta um restaurante japonês ao mundo de fantasia.

Ao invés de batalhas...

Existem refeições.

Cada cliente descobre um novo prato.

Personagens

  • Master

  • Aletta

  • Kuro

  • Altorius

  • Tatsugorou

O diferencial

É praticamente um anti-isekai.

Não existe herói.

Não existe guerra.

O protagonista verdadeiro é...

A comida.

Easter Eggs

Cada episódio apresenta receitas reais da culinária japonesa e ocidental.


3) Knight's & Magic

Título original: ナイツ&マジック

Episódios: 13

Resumo

Um engenheiro apaixonado por robôs morre e renasce em um mundo onde existem enormes mechas mágicos.

Agora ele utiliza seus conhecimentos de engenharia para revolucionar completamente a tecnologia daquele universo.

Personagens

  • Ernesti Echevarria

  • Adeltrud

  • Archid

  • Edgar

  • Dietrich

Diferencial

Mistura:

  • Isekai

  • Engenharia

  • Robôs gigantes

  • Fantasia medieval

Uma combinação bastante rara.

Easter Eggs

Os Silhouette Knights lembram diversos mechas clássicos dos anos 80 e 90.


4) Sengoku Night Blood

Título original: 戦刻ナイトブラッド

Episódios: 12

Resumo

Yuzuki é transportada para um mundo alternativo inspirado no período Sengoku.

Os famosos generais japoneses aparecem reinterpretados como guerreiros sobrenaturais.

Personagens

  • Yuzuki

  • Oda Nobunaga

  • Sanada Yukimura

  • Date Masamune

  • Toyotomi Hideyoshi

Diferencial

Mistura história japonesa com fantasia e elementos de otome game.

Easter Eggs

Diversos personagens são versões romantizadas de figuras históricas reais. (Animowiec)


5) The Master of Ragnarok & Blesser of Einherjar

Título original: 百錬の覇王と聖約の戦乙女

(Light novel iniciada em 2013; adaptação em anime viria depois, mas a franquia já ganhou destaque em 2017.)

Resumo

Yuuto utiliza seu smartphone e conhecimentos modernos para liderar um reino inspirado na mitologia nórdica.

Personagens

  • Yuuto

  • Felicia

  • Mitsuki

  • Linnea

Diferencial

Mistura:

  • estratégia militar

  • política

  • economia

  • administração de reino


6) .hack//G.U. Trilogy (continuidade de influência)

Embora não seja lançamento televisivo tradicional em 2017, a franquia .hack continuava extremamente influente sobre praticamente todo o conceito moderno de "personagem preso em outro mundo digital".

Muitos autores de light novels citam a série como inspiração.


Temas que dominaram 2017

O protagonista Overpowered

Se antes o herói precisava sofrer...

Agora bastava chegar.

Já era o mais forte.


Smartphones

A tecnologia começou a entrar nos mundos medievais.

Era uma espécie de:

Mainframe + Cloud + Google Maps

Tudo no bolso.


Engenharia

Knight's & Magic mostrou que conhecimento técnico também pode ser um superpoder.

Algo muito próximo do pensamento de um programador COBOL.

Não basta lançar magia.

É preciso entender como a máquina funciona.


Slice of Life

Restaurant to Another World provou que um isekai não precisava salvar o mundo.

Às vezes...

Basta servir um bom prato de curry.


Curiosidades

  • 2017 consolidou a adaptação em massa de light novels para anime.

  • O número de obras classificadas como isekai cresceu significativamente em relação aos anos anteriores. (Banco de Personagens de Anime)

  • Muitos protagonistas passaram a manter lembranças completas da vida anterior.

  • Os "Status Screens" inspirados em RPG tornaram-se quase obrigatórios.

  • Guildas de aventureiros passaram a aparecer em praticamente todas as produções.


Easter Eggs do Bellacosa Mainframe ☕

Imagine um analista de sistemas IBM em 2017.

Ele termina um compile COBOL, toma um café e resolve assistir a um anime.

No primeiro episódio...

O protagonista morre.

No segundo...

Já ganhou habilidades máximas.

No terceiro...

Já fundou um reino.

Enquanto isso, o pobre programador ainda espera o RUNSTATS terminar para executar o REBIND do Db2.

Talvez seja justamente esse o encanto dos isekais: oferecer, por vinte minutos, a fantasia de que existe um mundo onde nenhuma mudança depende de uma janela de produção aprovada pelo Change Manager.


Conclusão

2017 marcou a transição definitiva do isekai de um gênero em ascensão para um verdadeiro fenômeno industrial. A fórmula "protagonista transportado para outro mundo" mostrou enorme versatilidade: havia espaço para ação desenfreada, engenharia com robôs, gastronomia, política e fantasia histórica. Ao mesmo tempo, muitos clichês que hoje associamos ao gênero — telas de status, habilidades apelonas, guildas, magia em níveis e protagonistas extremamente competentes — tornaram-se padrão. Esse período consolidou um modelo de produção que influenciaria praticamente todas as temporadas seguintes e preparou o terreno para a grande explosão de sucessos que viria em 2018 e nos anos posteriores. (OtakuPT)

☕ Um Café no Bellacosa Mainframe

Portal Isekai — A Linha do Tempo dos Mundos Paralelos

Atravesse o portal e explore os animes isekai lançados entre 2009 e 2025. Cada grimório anual reúne títulos, personagens, episódios, curiosidades, referências e mundos que mudaram o gênero.

17 anos catalogados
2009–2025 linha do tempo
1 portal dimensional

A grande biblioteca dos animes isekai

Um portal se abriu dentro do Bellacosa Mainframe. Do outro lado, aventureiros reencarnados, heróis convocados, jogadores presos em mundos virtuais, magos, demônios, fazendeiros, cozinheiros e administradores de reinos aguardam sua próxima missão.

Este índice organiza os artigos anuais da série Isekai List, começando em 2009 e avançando até 2025. Use a busca para localizar um ano, escolha a ordem cronológica ou abra cada artigo diretamente em uma nova aba. Também é possível visualizar o conteúdo dentro do próprio portal.

🧭 Console de Navegação Dimensional

17 grimórios encontrados.

Arquivo recuperado do mainframe

Grimórios Isekai por Ano

Sistema online
2025
Nova geração

Isekai List 2025

O ano em que o isekai começou a experimentar novos algoritmos, misturando fórmulas clássicas, continuações e novas variações.

2024
Expansão dimensional

Isekai List 2024

Um ciclo carregado de continuações, novos sistemas mágicos, protagonistas improváveis e múltiplas atualizações de firmware.

2023
Diversificação

Isekai List 2023

Fantasia, culinária, agricultura, aventura e slow life dividem espaço em um dos anos mais variados do gênero.

2022
Firmware atualizado

Isekai List 2022

Novas temporadas, adaptações aguardadas e mundos paralelos operando com sistemas cada vez mais especializados.

2021
Reinos conectados

Isekai List 2021

Heróis, vilões, estrategistas e habitantes de outros mundos disputam espaço em uma temporada de forte produção.

2020
Produção intensiva

Isekai List 2020

O gênero domina o horário de produção e se transforma em uma das principais forças da indústria de anime.

2019
Linha de montagem

Isekai 2019

A indústria amplia o catálogo e transforma mundos paralelos em uma linha constante de lançamentos e adaptações.

2018
Produção em massa

Isekai List 2018

O gênero entra definitivamente em produção em massa, multiplicando mundos, heróis e sistemas de habilidades.

2017
Industrialização

Isekai List 2017

O isekai vira linha de produção, recebe novas fórmulas narrativas e conquista uma audiência cada vez maior.

2016
Reinicialização

Isekai List 2016

Um ano decisivo, marcado por obras que reiniciaram o sistema operacional do gênero e redefiniram suas possibilidades.

2015
Ascensão imperial

Isekai List 2015

O isekai deixa de ser apenas um nicho, amplia seu público e começa a construir um verdadeiro império comercial.

2014
Permanência no outro mundo

Isekai List 2014

Os protagonistas descobrem que voltar para casa nem sempre é o objetivo principal de uma aventura em outro mundo.

2013
Nova identidade

Isekai List 2013

O gênero encontra uma identidade moderna e começa a estabelecer elementos que dominariam a década seguinte.

2012
Grande reinicialização

Isekai List 2012

O ano em que mundos virtuais, light novels e comunidades online ajudaram a reiniciar a indústria dos animes.

2011
Compilando o futuro

Isekai List 2011

Um período de transição em que os elementos do isekai moderno começam a ser compilados dentro da indústria.

2010
Pré-explosão

Isekai List 2010

Antes da grande explosão comercial, o gênero reiniciava silenciosamente seus códigos narrativos fundamentais.

2009
Código ancestral

Isekai List 2009

O começo desta linha do tempo: um gênero ainda em reinicialização, preparando terreno para sua evolução.

Janela dimensional

🌀 Visualizador de Artigos

Escolha “Ver no portal” em qualquer ano para carregar o artigo.

Portal em modo de espera Selecione um ano para iniciar a transferência.

O que você encontra neste índice de animes isekai?

Animes por ano

Uma organização cronológica dos lançamentos e continuações mais relevantes entre 2009 e 2025.

Histórias e personagens

Resumos, protagonistas, companheiros, vilões, sistemas mágicos e elementos marcantes de cada produção.

Curiosidades e easter eggs

Referências escondidas, relações com light novels, mangás, RPGs, jogos e outras obras da cultura japonesa.

Estilo Bellacosa

Uma viagem descontraída pelos mundos paralelos, misturando anime, nostalgia, tecnologia e o bom humor do mainframe.

Um Café no Bellacosa Mainframe
Onde cada anime é um programa e cada mundo paralelo é uma nova LPAR.

Voltar ao início ↑

quinta-feira, 25 de maio de 2017

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

 

Bellacosa Mainframe e a engenharia social 

☕ Um Café no Bellacosa Mainframe — Especial Red Team

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu 

🌭 Pretexting, autoridade inventada, confiança contextual e como uma identidade falsa funciona porque todos esperam que ela exista

Chicago.

Restaurante sofisticado.

Recepção impecável.

Pessoas bem vestidas.

Uma reserva.

Um nome.

E um adolescente com confiança suficiente para atravessar um controle social inteiro sem precisar apresentar praticamente nada além de convicção.

— Abe Froman.

Quem?

Abe Froman.

O Rei da Salsicha de Chicago.

É uma das melhores piadas de Curtindo a Vida Adoidado.

E, ao mesmo tempo, uma aula quase perfeita de engenharia social.

Porque Ferris não prova matematicamente que é Abe Froman.

Não apresenta certificado digital.

Não faz reconhecimento facial.

Não mostra token.

Não passa por biometria.

Não apresenta uma cadeia criptográfica assinada por uma autoridade certificadora da indústria de embutidos de Illinois.

Ele faz algo muito mais simples.

Ele ocupa um espaço social onde Abe Froman deveria existir.

E durante alguns minutos...

isso basta.

Bem-vindo ao terceiro episódio de:

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

Hoje vamos falar de uma distinção que deveria estar tatuada na parede de qualquer War Room:

Identity ≠ Authentication ≠ Authorization

E, talvez mais importante:

parecer legítimo não é o mesmo que ser legítimo.


🌭 Quem diabos é Abe Froman?

A força da cena está justamente no absurdo.

Ferris encontra um nome.

Uma reserva.

Uma posição social implícita.

E decide ocupar aquela identidade.

Observe o que acontece.

O nome existe.

A reserva existe.

O restaurante espera alguém com aquele nome.

Portanto, a chegada de uma pessoa alegando ser aquela identidade parece plausível.

Essa é a essência do pretexting.

Você não inventa qualquer história.

Você cria uma história que encaixa no ambiente.


🎭 Pretexting não é simplesmente mentir

Essa distinção é importante.

Mentira pode ser qualquer afirmação falsa.

Pretexting é mais sofisticado.

É construir um contexto.

Uma narrativa.

Um papel.

Um motivo.

Uma expectativa.

Ferris não diz simplesmente:

— Quero essa mesa.

Ele implicitamente diz:

— Sou a pessoa que vocês já esperavam.

Isso muda completamente a dinâmica.


🧠 O cérebro ama histórias coerentes

Pessoas não processam cada interação como um sistema criptográfico.

Nós utilizamos heurísticas.

Contexto.

Padrões.

Expectativas.

Se alguém entra numa sala usando crachá, segurando notebook e reclamando do Wi-Fi, nossa cabeça rapidamente conclui:

funcionário.

Se alguém liga dizendo:

— Sou da equipe de infraestrutura, estamos fechando um incidente crítico...

A frase ativa um contexto.

Se a pessoa conhece nomes internos, horários, sistemas e jargão, a história fica ainda mais convincente.

Ferris entende isso intuitivamente.


🔴 Engenharia social ataca modelos mentais

Tecnologia implementa regras.

Pessoas interpretam situações.

Essa diferença cria superfície de ataque.

Um firewall pode perguntar:

SOURCE IP?
DESTINATION?
PORT?
PROTOCOL?

Uma pessoa pergunta coisas muito mais nebulosas:

— Essa história faz sentido?

— Essa pessoa parece saber do que está falando?

— Parece urgente?

— Parece importante?

— Eu deveria ajudar?

Ferris trabalha nessa camada.


🪪 Identity: quem você afirma ser?

Vamos começar pela primeira palavra.

Identity.

Identidade é uma afirmação.

Você diz:

“Eu sou Vagner.”

Ou:

“Eu sou o administrador.”

Ou:

“Eu sou Abe Froman.”

Isso é apenas a declaração.

Nada foi provado ainda.

Em sistemas, seria algo como:

USER = ABE_FROMAN

Muito bonito.

Mas absolutamente insuficiente.


🔐 Authentication: prove

Authentication responde:

“Você realmente é quem afirma ser?”

Senha.

Token.

Biometria.

Smartcard.

Certificado.

MFA.

Passkey.

Algum mecanismo precisa transformar uma alegação de identidade numa identidade aceita.

Então:

Identity:
"I am Abe Froman"

Authentication:
"Prove it."

Ferris tenta atravessar exatamente esse intervalo.

Ele apresenta identidade suficiente para que ninguém exija autenticação forte.


🚪 Authorization: mesmo sendo você, pode fazer isso?

Aqui está a terceira camada.

Você pode ser realmente quem diz ser.

Pode autenticar corretamente.

E ainda assim não deveria necessariamente poder executar qualquer coisa.

Isso é authorization.

Identity
   ↓
Authentication
   ↓
Authorization
   ↓
Action

Essas quatro coisas são diferentes.

E sistemas ruins misturam tudo.


☕ “Mas ele é diretor”

Excelente.

Isso prova o quê?

Talvez identidade social.

Não autorização técnica.

— Ele é diretor.

— Então pode acessar produção?

Não necessariamente.

— Ele é vice-presidente.

— Então pode alterar firewall?

Espero que não.

— Ele é CEO.

— Então pode consultar qualquer dado de cliente?

Talvez a resposta correta seja:

não.

Autoridade organizacional não deveria se transformar automaticamente em privilégio técnico.

Ferris adora ambientes onde isso acontece.


🎩 Autoridade inventada

Uma das ferramentas mais antigas da engenharia social é autoridade.

Pessoas são condicionadas a responder a sinais de hierarquia.

Título.

Tom de voz.

Urgência.

Confiança.

Conhecimento interno.

Ferris utiliza quase todos.

Ele não precisa apresentar poder real.

Precisa transmitir sinais de poder suficientes.

Abe Froman não é apenas um nome.

É um personagem com status.

O “Rei da Salsicha de Chicago”.

A própria ideia sugere alguém importante dentro daquele universo.


🏢 Agora transforme o restaurante numa empresa

Imagine uma ligação:

— Bom dia, aqui é Marcos, da equipe do diretor financeiro. Estamos fechando o trimestre e precisamos liberar uma alteração imediatamente.

Nada necessariamente comprova identidade.

Mas a história contém:

cargo;

contexto;

urgência;

processo conhecido.

Agora acrescente:

— O Paulo está numa reunião com o conselho e pediu para eu resolver isso antes das 15h.

Paulo realmente existe.

Está realmente numa reunião.

A pessoa do outro lado sabe disso.

A narrativa começa a ganhar textura.


🔎 E de onde veio toda essa informação?

OSINT.

LinkedIn.

Redes sociais.

Calendário público.

Site da empresa.

Apresentações.

Documentos.

Vagas.

Postagens.

Uma história falsa pode ser construída com fatos verdadeiros.

Isso é uma combinação poderosa.


🧩 Verdade + mentira = história plausível

Um bom pretexto raramente precisa ser 100% inventado.

Na verdade, quanto mais verdade houver ao redor da mentira central, melhor.

Imagine:

Empresa real
+
Funcionário real
+
Projeto real
+
Prazo real
+
Nome real
+
Urgência plausível
+
Identidade falsa

A história inteira parece legítima.

O único elemento falso pode ser justamente quem está falando.

Ferris faria isso magnificamente.


🧠 Contexto reduz questionamento

Pense em duas abordagens.

Primeira:

— Me dê acesso ao sistema.

Provavelmente recebe:

— Quem é você?

Agora:

— Sou da equipe de suporte do projeto Atlas. A Patrícia abriu o ticket 8231 porque o serviço que integra o faturamento com o mainframe parou depois da mudança desta manhã. Preciso validar a conta técnica antes da janela fechar.

Subitamente temos uma narrativa.

Mesmo sem qualquer prova real, parece haver estrutura.

É aí que procedimentos precisam derrotar intuição.


🧯 Procedimento existe para dias convincentes

Esse ponto é fundamental.

Controles não são criados apenas para bloquear histórias ruins.

São criados para bloquear histórias excelentes.

Qualquer pessoa consegue desconfiar de:

— Oi, sou hacker, me passa sua senha?

Parabéns ao treinamento de segurança.

O problema é:

— Sou Felipe da IBM, estou com a equipe da migração do z/OS Connect e preciso confirmar a conta técnica que vocês configuraram ontem.

Agora a pessoa hesita.

Talvez realmente exista Felipe.

Talvez realmente exista projeto.

Talvez realmente tenha ocorrido mudança ontem.

É nesse momento que processo importa.


🔐 Nunca autentique alguém pela qualidade da história

Essa frase deveria entrar em treinamento corporativo.

Uma história boa não é autenticação.

Conhecer nome interno não é autenticação.

Conhecer projeto não é autenticação.

Saber seu gerente não é autenticação.

Falar jargão não é autenticação.

Estar irritado não é autenticação.

Parecer importante não é autenticação.

E usar um crachá bonito também não.


🪪 Crachá: o cosplay corporativo da confiança

Crachás são interessantes.

Servem para identificação visual.

Mas pessoas frequentemente confundem:

possui crachá

com:

possui autorização.

Ferris provavelmente adoraria um ambiente onde basta parecer funcionário.

Porque elementos visuais criam confiança contextual.

Uniformes fazem isso.

Coletes.

Pranchetas.

Notebook.

Fones.

Pasta.

Tudo isso conta histórias.


🚪 Tailgating: Abe Froman entrou atrás de alguém

Outro exemplo clássico.

Uma porta controlada por crachá.

Pessoa legítima passa.

Outra vem atrás carregando caixas.

— Segura pra mim?

O funcionário segura.

Tecnicamente, o sistema de controle de acesso funcionou perfeitamente.

Ele autenticou uma pessoa.

O problema é que duas entraram.

A falha não está no leitor.

Está no modelo social ao redor dele.


☕ O sistema perguntou uma coisa, o humano respondeu outra

O sistema pergunta:

“Este crachá está autorizado?”

O humano entende:

“Esta pessoa parece pertencer aqui?”

São perguntas diferentes.

Engenharia social vive nessas diferenças.


🔴 Ferris procura permissões sociais

Nem toda autorização está no RACF.

Existem permissões invisíveis.

Quem pode interromper uma reunião?

Quem pode pedir exceção?

Quem pode entrar pela porta lateral?

Quem pode solicitar urgência?

Quem pode dizer:

— Depois regularizamos.

Essas permissões sociais são valiosas.

Porque muitas vezes não estão documentadas.


📞 Help Desk: onde identidade encontra misericórdia

Help Desk é um alvo clássico justamente porque existe para ajudar pessoas que perderam acesso.

Isso cria um paradoxo.

Usuário legítimo:

— Esqueci minha senha.

Atacante:

— Esqueci minha senha.

Do ponto de vista verbal, são idênticos.

Então o sistema precisa de processo.

Validação.

MFA.

Callback.

Verificação independente.

Porque simpatia não autentica.


🧠 “Mas ele sabia meu CPF”

Informação pessoal virou péssimo autenticador.

Datas.

Documentos.

Endereços.

Nomes.

Parentes.

Empregadores.

Muitos desses dados já circularam por vazamentos.

Outros estão publicamente disponíveis.

O atacante conhecer uma informação não significa que é a pessoa.

Esse é outro erro clássico:

confundir knowledge com identity.


🔐 Algo que você sabe

Historicamente, autenticação foi dividida em fatores.

Algo que você sabe.

Algo que você tem.

Algo que você é.

Senha.

Token.

Biometria.

Combinar fatores aumenta resistência.

Mas mesmo MFA pode ser atacado socialmente.

O atacante pode tentar convencer o usuário a aprovar uma solicitação.

Então volta Ferris.

Tecnologia e comportamento precisam trabalhar juntos.


📲 “Aprove a notificação que acabou de chegar”

Imagine:

— Sou do suporte. Estamos corrigindo sua conta. Você vai receber uma notificação. Pode aprovar?

E a notificação chega.

Agora o usuário pensa:

Claro, ele disse que chegaria.

Isso é engenharia social usando o próprio mecanismo de segurança como parte da história.

O controle funciona.

A narrativa captura o usuário.


🤹 O truque não é quebrar o controle

Essa é uma ideia recorrente nesta série.

Ferris não precisa destruir controles.

Ele tenta fazer os próprios controles trabalharem para ele.

Isso é muito mais elegante.

Se uma pessoa legítima aprovar.

Se uma conta legítima autenticar.

Se um fluxo legítimo executar.

O atacante parece menos atacante.


🏦 Autoridade financeira

Empresas sofrem particularmente com golpes baseados em autoridade executiva.

Pedidos urgentes.

Transferências.

Mudanças de conta.

Faturas.

A lógica é sempre parecida.

A pessoa não obedece porque é idiota.

Obedece porque a organização a treinou para responder a hierarquia e urgência.

O atacante utiliza a cultura contra a própria cultura.


🧬 Cultura organizacional também é superfície de ataque

Esse ponto merece destaque.

Se uma empresa possui cultura onde:

“não questione diretor”,

então autoridade vira vetor.

Se possui cultura onde:

“resolver rápido é mais importante que processo”,

urgência vira vetor.

Se possui cultura onde:

“cliente VIP sempre ganha exceção”,

status vira vetor.

Red Team pode revelar isso.


🧪 Engenharia social autorizada não é pegadinha

Esse é outro ponto importante.

Um bom exercício não deve existir apenas para humilhar funcionário.

“HAHA! VOCÊ CLICOU!”

Isso ensina medo.

Não segurança.

O objetivo é descobrir:

processo funcionou?

controle existia?

a pessoa tinha canal para verificar?

o procedimento era realista?

havia pressão operacional?

O erro individual frequentemente é sintoma de desenho ruim.


🔴 Não culpe o humano por seguir o sistema humano

Se um funcionário precisa escolher entre:

seguir processo e tomar bronca;

ou quebrar processo e resolver problema;

adivinhe o que vai acontecer ao longo do tempo.

Segurança precisa encaixar na operação.

Caso contrário, nasce Shadow IT.

Exceção.

Atalho.

E Ferris começa a circular.


🦖 Abe Froman chega ao mainframe

Agora vamos transportar nosso Rei da Salsicha para um ambiente mainframe.

Imagine alguém ligando:

— Sou da equipe de aplicação. Estamos com erro de acesso no batch noturno. Preciso validar a permissão de uma conta técnica.

Parece plausível.

Talvez a pessoa conheça:

nome da aplicação;

job;

dataset;

Lpar;

horário;

time responsável.

Isso impressiona.

Mas nada disso deveria substituir autenticação e procedimento.


🔐 RACF não deveria acreditar em storytelling

RACF é maravilhoso justamente porque trabalha com regras.

Identidade.

Perfis.

Grupos.

Recursos.

Permissões.

Ele não fica emocionalmente impressionado com:

— Mas o diretor pediu!

Se arquitetura e processo estiverem corretos, autoridade informal não deveria atravessar o controle técnico.

O problema aparece quando humanos concedem a exceção.


🧨 SPECIAL: o Rei da Salsicha quer poder demais

Imagine alguém com RACF SPECIAL.

A discussão muda completamente.

Contas privilegiadas são especialmente valiosas.

Por isso PAM, segregação, logs, MFA e revisão são fundamentais.

Abe Froman não deveria conseguir chegar até:

ALTUSER ...
PERMIT ...
CONNECT ...

apenas porque parece convincente.


📡 z/OS Connect e identidade distribuída

Sistemas modernos complicam ainda mais a questão.

Uma identidade pode atravessar camadas.

Mobile
 ↓
Identity Provider
 ↓
API Gateway
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL

Cada componente pode possuir visão diferente da identidade.

Quem autenticou?

Quem autorizou?

Qual identidade chegou ao backend?

Foi propagada?

Foi mapeada?

Virou conta técnica?

Esse tipo de pergunta é ouro para Red Team.


🧠 Identidade perdida no caminho

Imagine:

Usuário A autentica no frontend.

Backend chama mainframe com conta compartilhada.

Para o mainframe, todas as pessoas parecem:

APIUSER

Agora surge uma pergunta maravilhosa:

Quem realmente executou a transação?

A aplicação talvez saiba.

O mainframe talvez não.

Auditoria pode ficar fragmentada.

É aí que arquitetura de identidade importa.


🧾 Non-repudiation: depois ninguém lembra quem foi

Uma operação crítica deveria poder ser atribuída.

Quem fez?

Com qual identidade?

De qual origem?

Em qual contexto?

Se tudo termina numa conta técnica compartilhada, a história fica nebulosa.

Ferris agradece novamente.


🤖 Abe Froman ganha voz sintética

Agora entramos em 2026.

Uma das grandes mudanças é que sinais sociais podem ser reproduzidos em escala crescente.

Texto.

Voz.

Imagem.

Vídeo.

Isso significa que:

“eu reconheci a voz”

se torna um fator menos confiável isoladamente.

A defesa precisa depender menos de familiaridade.

Mais de canais autenticados.

Processos.

Verificação independente.


📞 “Mas parecia exatamente meu chefe”

Esse é o problema.

Por décadas, voz funcionou informalmente como autenticação.

Você reconhece alguém.

Confia.

Hoje essa confiança precisa ser revista.

Não significa que toda ligação é falsa.

Significa que operações sensíveis precisam de mecanismos além da percepção.


🧠 Deepfake não cria a vulnerabilidade

Ele amplifica uma vulnerabilidade que já existia:

confiamos em sinais sociais.

Ferris faria Abe Froman com presença física.

Hoje alguém pode construir pretexto digitalmente.

O princípio não mudou.

A escala mudou.


🎯 Red Team deveria testar identidade, não apenas senha

Uma operação madura pode perguntar:

Se alguém alegar ser executivo, o que acontece?

Se alguém conhecer informações internas, ganha confiança?

Se fornecedor ligar fora do fluxo, existe validação?

Se uma conta for comprometida, há detecção contextual?

Se alguém usar voz convincente, processo resiste?

Essas perguntas testam a arquitetura real de identidade.


🧩 Identity ≠ Authentication ≠ Authorization

Voltemos ao coração deste artigo.

IDENTITY
"Eu sou Abe Froman"

≠

AUTHENTICATION
"Prove que é Abe Froman"

≠

AUTHORIZATION
"O verdadeiro Abe Froman pode fazer isso?"

Três perguntas.

Três controles.

Três falhas possíveis.

Misture qualquer duas e Ferris entra.


☕ E ainda existe uma quarta pergunta

Mesmo que você seja quem diz.

Mesmo que esteja autenticado.

Mesmo que possua permissão.

Precisamos perguntar:

essa ação faz sentido agora?

Isso é contexto.

Um usuário pode possuir autorização para transferir dinheiro.

Mas transferência de valor enorme às 03h17 de um país inesperado talvez mereça atenção.

Então:

Identity
↓
Authentication
↓
Authorization
↓
Context
↓
Action

Segurança moderna precisa cada vez mais dessa camada.


🚨 Zero Trust: Abe Froman não ganha mesa automaticamente

Zero Trust é frequentemente resumido de maneira pobre como:

“não confie em ninguém.”

Não é exatamente isso.

É mais próximo de:

não transforme confiança implícita em autorização permanente.

Verifique.

Contextualize.

Limite.

Monitore.

Ou, no restaurante:

— Senhor Froman?

— Sim.

— Excelente. Precisamos confirmar sua reserva por outro canal.

Ferris:

— Droga.

Fim do episódio.


🧠 A pergunta Bellacosa

Numa War Room eu colocaria esta pergunta:

“Que frases fazem nossos funcionários pararem de questionar?”

“Sou diretor.”

“É urgente.”

“É auditoria.”

“É produção.”

“É da segurança.”

“É cliente VIP.”

“É ordem do presidente.”

“É incidente.”

“É do fornecedor.”

A resposta revela muito sobre a cultura de confiança.


🌭 O poder de parecer esperado

Abe Froman funciona porque o restaurante já espera Abe Froman.

Esse detalhe é genial.

O pretexto mais forte frequentemente entra por uma expectativa existente.

Manutenção agendada.

Auditoria.

Fornecedor esperado.

Novo funcionário.

Entregador.

Consultor.

Equipe de limpeza.

Migração.

Suporte.

O atacante procura uma história que o ambiente esteja preparado para aceitar.


🧱 Segurança começa quando plausibilidade deixa de ser suficiente

O sistema maduro diz:

“Isso parece plausível.”

Mas continua:

“Vamos verificar.”

Essa pequena diferença impede muita coisa.

Não precisamos tratar todo mundo como criminoso.

Precisamos separar cortesia de controle.

Você pode ser educado.

Prestativo.

Rápido.

E ainda verificar identidade.


🎬 Ferris venceu porque entendeu a cena

Ele não era Abe Froman.

Mas entendeu que o restaurante não possuía uma maneira forte de diferenciar:

a pessoa esperada

de:

alguém que sabia o nome esperado.

Esse é um problema clássico de autenticação.

E continua atual.


☕ Epílogo: longa vida ao Rei da Salsicha

Ferris Bueller entrou no restaurante com uma identidade emprestada.

E nos deixou uma bela lição de segurança.

Identidade é uma afirmação.

Autenticação é prova.

Autorização é permissão.

Contexto é validação contínua.

Nenhuma dessas coisas deveria ser substituída por:

“Ele parecia saber o que estava falando.”

Porque o atacante competente faz exatamente isso.

Ele aprende.

Observa.

Pesquisa.

Constrói pretexto.

Adota linguagem.

Explora expectativas.

E então aparece na porta.

Talvez de terno.

Talvez com crachá.

Talvez por telefone.

Talvez através de uma conta comprometida.

Talvez por API.

Talvez usando uma voz sintética.

Mas sempre trazendo a mesma pergunta:

“Vocês vão verificar quem eu sou ou apenas acreditar que eu deveria estar aqui?”

No restaurante de Chicago, por alguns minutos, a resposta foi confiança.

E Ferris ganhou a mesa.

No seu ambiente corporativo, essa mesma confusão pode significar:

acesso;

credencial;

privilégio;

transação;

dados;

produção.

Então da próxima vez que alguém aparecer dizendo ser muito importante, carregando uma história perfeitamente plausível, lembre-se:

Abe Froman também parecia legítimo.

SAVE FERRIS.

No próximo artigo:

Você Conhece o Diretor Rooney? — OSINT Antes do Google Existir

Porque antes de alguém inventar uma boa mentira...

precisa descobrir verdades suficientes para torná-la convincente.

☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Ferris Bueller’s Red Team

Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?

  • Red Team
  • OSINT
  • Engenharia Social
  • Blue Team
  • MFA
  • PAM
  • IA Generativa
  • RACF
  • z/OS
  • Mainframe
1

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.

Red Team • Recon • Threat Modeling • Criatividade Adversarial
2

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.

Integridade • Db2 • Auditoria • Insider Threat • Dados
3

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.

Engenharia Social • Pretexting • Identity • Authentication
4

“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir

Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.

OSINT • Recon • LinkedIn • GitHub • Attack Surface
5

Cameron, Atenda o Telefone — Social Engineering as a Service

Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.

Social Engineering • Swiss Cheese Model • Human Risk
6

O Diretor Rooney Está Procurando Malware no Lugar Errado

Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.

SOC • SIEM • EDR • Zero Trust • Engenharia Social
7

A Ferrari do Cameron Não Tinha MFA

Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.

MFA • PAM • Least Privilege • Privileged Access
8

Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup

Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.

Backup • Restore • Rollback • Db2 • VSAM • Recovery
9

Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente

Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.

Blue Team • SOC • Cognitive Bias • Incident Response
10

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.

Generative AI • Agents • Deepfake • Voice Cloning • OSINT
11

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.

Mainframe • RACF • z/OS • CICS • Db2 • MQ • Zowe
12

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.

Red Teaming • Purple Team • Detection • Resilience • Learning

🎬 Página principal da temporada

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.

☕ Acessar o especial completo SAVE FERRIS

Sobre a série SAVE FERRIS — Red Team

A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.

O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.

A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.

Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.

terça-feira, 2 de maio de 2017

Ishuzoku Reviewers: quando descobrimos que os romanos inventaram o review de puteiro dois mil anos antes do anime

 

Bellacosa Mainframe em o que Pompeia Ostia Antiga e Ishuzoku reviewers tem em comum

☕ Um Café no Bellacosa Mainframe

Ishuzoku Reviewers: quando descobrimos que os romanos inventaram o review de puteiro dois mil anos antes do anime

⭐ De Ostia Antica aos aventureiros japoneses: mudaram as espécies, apareceu a Internet, caiu o Império Romano — mas aparentemente ninguém conseguiu impedir o cliente de deixar sua avaliação

Por Vagner Bellacosa


Existe um momento inevitável em qualquer conversa realmente séria entre dois homens num boteco.

Começamos discutindo História.

Depois arqueologia.

Falamos sobre Roma.

Analisamos urbanismo.

Entramos em alfabetização no mundo antigo.

Debatemos globalização.

Passamos pela evolução dos sistemas de informação.

Alguém pede outra bebida.

E quinze minutos depois estamos discutindo:

reviews de puteiro.

Normal.

A humanidade funciona assim há pelo menos dois mil anos.

E talvez essa seja justamente a descoberta mais importante deste Café.

Porque recentemente eu estava lembrando de uma visita que fiz a Ostia Antica, a antiga cidade portuária associada ao abastecimento de Roma.

Não visitei correndo.

Caminhei.

Entrei nas construções.

Observei ruas.

Termas.

Casas.

Comércio.

Armazéns.

Mosaicos.

Detalhes.

E, naturalmente, como todo pesquisador comprometido com a compreensão integral da civilização romana...

fui procurar os lugares relacionados à prostituição.

😂

Pesquisa de campo.

Nada além disso.


🏛️ Primeiro: Roma não era feita somente de imperadores

Quando pensamos no Império Romano, nosso cérebro imediatamente carrega:

LOAD ROMAN-EMPIRE

CAESAR
LEGIONS
COLOSSEUM
SENATE
TEMPLES
AQUEDUCTS
GLADIATORS

Mas existe outro arquivo.

Muito maior.

ROMAN.DAILY.LIFE

E nele encontramos:

comerciantes,

marinheiros,

escravos,

libertos,

trabalhadores,

taberneiros,

prostitutas,

clientes,

viajantes,

fofoqueiros,

bêbados,

apaixonados,

picaretas,

gente reclamando,

gente fazendo propaganda,

e gente desenhando obscenidades na parede.

Em outras palavras:

seres humanos.


✍️ A parede romana era uma rede social

Uma das coisas mais extraordinárias preservadas em cidades romanas são os grafites.

E aqui precisamos abandonar aquela ideia moderna de que escrever na parede significava necessariamente aquilo que hoje chamaríamos de vandalismo.

A cultura epigráfica romana era muito mais presente no cotidiano.

Em Pompeia, por exemplo, foram preservadas milhares de inscrições.

E no famoso lupanar da cidade existe uma concentração extraordinária delas.

Estudos modernos contabilizam perto de 150 textos e imagens no edifício, incluindo nomes, saudações, provocações, referências sexuais, desenhos, pequenas frases e outros registros. Curiosamente, apenas cerca de um terço desse conjunto é explicitamente sexual.

Isso muda nossa imagem do lugar.

Não era simplesmente:

ENTRAR
↓
SERVIÇO
↓
SAIR

Havia também:

ENTRAR
↓
OLHAR PAREDE
↓
LER
↓
RIR
↓
RECONHECER NOME
↓
ESCREVER ALGUMA COISA
↓
OUTRA PESSOA LER

Pronto.

Temos uma comunidade.


🌐 OSTIA SOCIAL NETWORK v1.0

Se um programador fosse documentar aquela arquitetura:

SYSTEM NAME:
ROMAN WALL NETWORK

VERSION:
1.0

FRONT-END:
PLASTER

INPUT DEVICE:
SHARP OBJECT

DATABASE:
WALL

USER AUTHENTICATION:
NONE

ANONYMOUS POSTING:
SUPPORTED

IMAGES:
SUPPORTED

TEXT:
SUPPORTED

COMMENTS:
SUPPORTED

MODERATION:
QUESTIONABLE

EXPECTED RETENTION:
DAYS / YEARS

ACTUAL RETENTION:
~2,000 YEARS

😂

E existe uma característica fundamental.

O autor escrevia esperando um leitor.

Isso parece banal.

Não é.

Porque significa que aquela pessoa reconhecia a parede como um espaço de comunicação.


👨‍💻 READ virou WRITE

Imagine um sujeito entrando.

Ele olha uma inscrição.

Lê.

Olha outra.

Ri.

Discorda.

Então vê um espaço vazio.

Ocorre naquele instante uma das transições mais importantes da história da computação:

USER STATUS:

READ-ONLY
   ↓
   ↓
"I DISAGREE"
   ↓
   ↓
READ-WRITE

🤣

A Internet seria inevitável.

Era apenas questão de esperar dois mil anos.


⭐ E então aparecem os reviews

Aqui precisamos tomar cuidado com uma tentação moderna.

Nem toda inscrição sexual romana era literalmente um Google Review.

Algumas eram anúncios.

Outras eram provocações.

Outras registravam nomes.

Outras eram ostentação.

Outras podiam ser insultos ou difamação.

Algumas simplesmente registravam experiências ou desejos.

Portanto traduzir tudo como:

⭐⭐⭐⭐ “Ótimo serviço, recomendo.”

seria anacrônico.

Mas existe algo fascinantemente parecido com o ecossistema contemporâneo de reputação.

A epigrafia pompeiana preserva dezenas de inscrições que oferecem serviços sexuais indicando nomes, preços e, em alguns casos, tipos específicos de serviço. Um estudo recente trabalha com aproximadamente 45 exemplos desse tipo.

Ou seja:

NOME
+
SERVIÇO
+
PREÇO
+
REPUTAÇÃO

Do ponto de vista de informação comercial...

meu amigo...

isso já começa a parecer assustadoramente familiar.


💰 Marketplace romano

Imagine a cena.

Você chega a uma cidade desconhecida.

Não conhece ninguém.

Não existe:

Google Maps,

TripAdvisor,

Reddit,

WhatsApp,

Telegram,

Yelp,

Instagram.

Mas existe uma parede.

E alguém escreveu alguma informação.

Agora você possui algo que não tinha cinco minutos antes:

informação de mercado.

CLIENTE
   ↓
INFORMAÇÃO
   ↓
ESCOLHA
   ↓
EXPERIÊNCIA
   ↓
NOVA INFORMAÇÃO
   ↓
PRÓXIMO CLIENTE

Isso é um feedback loop.


🧠 E isso explica por que os grafites são tão importantes

Quando vemos inscrições desse tipo, a primeira reação é rir.

E devemos.

Os próprios romanos certamente riam.

Mas depois aparece uma segunda camada.

Para aquela comunicação funcionar, precisava existir algum nível de alfabetização funcional entre parte das pessoas que frequentavam aqueles ambientes.

Isso não significa que “todo romano sabia ler”.

Muito menos que todos possuíam alfabetização literária.

Os níveis de alfabetização no mundo romano continuam sendo discutidos pelos historiadores e provavelmente variavam enormemente conforme região, gênero, condição social e contexto.

Mas a própria pesquisa sobre os grafites do lupanar destaca um espectro de alfabetização: pessoas capazes apenas de reconhecer ou copiar letras, outras capazes de escrever nomes ou frases curtas e outras com competência mais sofisticada.

Ou seja:

ROMAN LITERACY

LEVEL 0:
não lê

LEVEL 1:
reconhece símbolos/nome

LEVEL 2:
lê palavras simples

LEVEL 3:
escreve nome/frase

LEVEL 4:
escreve texto elaborado

LEVEL 5:
corrige a gramática do LEVEL 3

O Level 5 provavelmente já era insuportável naquela época.

😂


🌍 E então aparece a globalização romana

Agora coloque isso numa cidade portuária como Ostia.

Gente chegando.

Gente partindo.

Mercadorias circulando.

Idiomas se encontrando.

Latim.

Grego.

Línguas regionais.

Símbolos reconhecíveis.

Moedas.

Rotas comerciais.

Contratos.

Portos.

Estradas.

Roma havia construído uma coisa extraordinária:

um gigantesco protocolo de interoperabilidade humana.

Não era uniformidade.

Era interoperabilidade.


🔌 ROMAN EMPIRE PROTOCOL

RFC: ROMA-001

TRANSPORT:
roads + ships

CURRENCY:
standardized enough to trade

LANGUAGE:
Latin / Greek + local languages

IDENTITY:
Roman institutions

APPLICATION LAYER:
commerce

SOCIAL LAYER:
gossip

REVIEW SYSTEM:
wall

🤣

E aí chegamos ao ponto que me fascinou caminhando por aquelas ruínas.

Alguém poderia chegar de longe.

Encontrar uma mensagem.

Compreender pelo menos parte dela.

E pensar:

“Também vou deixar a minha.”

Nesse momento surge algo muito próximo daquilo que hoje chamamos de conteúdo gerado pelo usuário.


📱 USER GENERATED CONTENT — circa 100 d.C.

O sujeito não trabalha para o estabelecimento.

Não é funcionário do Império.

Não recebeu comissão.

Não pertence ao departamento de marketing.

Simplesmente tem uma opinião.

E considera absolutamente indispensável compartilhá-la.

Parabéns.

Acabamos de descobrir o usuário da Internet.

😂


⏳ Agora avançamos aproximadamente dois mil anos

Roma caiu.

O Império Romano do Ocidente desapareceu.

O latim se fragmentou e evoluiu.

Reinos nasceram.

Reinos morreram.

Vieram:

papel,

imprensa,

telégrafo,

telefone,

rádio,

televisão,

computador,

BBS,

Usenet,

Internet,

smartphone,

redes sociais.

O Japão industrializou-se.

Inventou mangá moderno.

Anime.

Videogames.

Visual novels.

Eroge.

Isekai.

Até que um dia alguém teve uma ideia completamente absurda:

“E se aventureiros de fantasia visitassem estabelecimentos adultos de diferentes espécies e escrevessem reviews?”

Senhoras e senhores:

Ishuzoku Reviewers

😂


🧝 Bem-vindo ao século XXI

Ishuzoku Reviewers — ou Interspecies Reviewers — tem roteiro/original de Amahara e arte de masha.

A própria editora japonesa KADOKAWA resume a premissa de maneira maravilhosamente direta: Stunk, um aventureiro humano, e Zel, seu amigo elfo, discordam sobre suas preferências envolvendo mulheres de diferentes espécies.

Como resolver uma divergência filosófica dessa magnitude?

Debate?

Academia?

Método científico?

Conselho de sábios?

Não.

Review.

😂

A KADOKAWA literalmente apresenta a obra como uma comédia fantástica baseada em avaliar estabelecimentos com garotas de diferentes espécies.

A edição internacional da Yen Press é igualmente direta: Stunk, Zel e Crim percorrem estabelecimentos adultos de um mundo povoado por inúmeras espécies e relatam suas experiências.

Ou seja:

ISHUZOKU REVIEWERS

INPUT:
estabelecimento

PROCESS:
experiência

OUTPUT:
review

Espere.

Eu já vi esse sistema.


🏛️ OSTIA/POMPEII LEGACY SYSTEM DETECTED

ROMAN CLIENT
     ↓
VISITS ESTABLISHMENT
     ↓
HAS EXPERIENCE
     ↓
FORMS OPINION
     ↓
WRITES ON WALL
     ↓
OTHER PEOPLE READ

Agora:

FANTASY ADVENTURER
     ↓
VISITS ESTABLISHMENT
     ↓
HAS EXPERIENCE
     ↓
FORMS OPINION
     ↓
WRITES REVIEW
     ↓
OTHER PEOPLE READ

...

MEU DEUS.

🤣🤣🤣


🔄 Dois mil anos de evolução tecnológica

Mudamos tudo.

ROMA                    ISHUZOKU

HUMANOS                 HUMANOS/ELFOS/ANJOS/ETC.
PAREDE                  QUADRO/REVIEWS
LATIM                   JAPONÊS
MOEDA ROMANA            MOEDA FANTÁSTICA
LUPANAR                  SUCCU-JOINT
GRAFITE                  REVIEW

Mas o algoritmo continua:

       IF EXPERIENCE = GOOD
           MOVE HIGH-RATING TO REVIEW
       ELSE
           MOVE LOW-RATING TO REVIEW
       END-IF.

       PERFORM TELL-EVERYBODY.

Backward compatibility perfeita.

😂


⭐ O detalhe genial de Ishuzoku não é o sexo

Essa talvez seja a grande surpresa.

Por baixo da provocação existe uma ideia bastante inteligente:

preferência é contextual.

Stunk avalia uma experiência de uma maneira.

Zel avalia de outra.

Crim possui outra percepção.

Espécies diferentes possuem:

biologia diferente,

expectativas diferentes,

sentidos diferentes,

longevidade diferente,

atrações diferentes,

limitações diferentes.

Portanto:

SAME SERVICE
+
DIFFERENT USER
=
DIFFERENT REVIEW

Isso é extraordinariamente contemporâneo.

É UX.

😂


🧪 Ishuzoku Reviewers é quase pesquisa de experiência do usuário

Pense como analista.

Temos:

USER A:
Human

USER B:
Elf

USER C:
Angel

SERVICE:
Same establishment

Resultado:

USER A .... 9/10
USER B .... 4/10
USER C .... ???/10

Quem está certo?

Todos.

Porque avaliação não é propriedade absoluta do serviço.

Ela nasce da interação:

SERVICE
   +
USER EXPECTATION
   +
USER CHARACTERISTICS
   +
CONTEXT
   =
EXPERIENCE

E experiência gera review.


🍺 O romano do boteco entenderia perfeitamente

Imagine trazer um cidadão de Ostia para 2026.

Explicamos computador.

Difícil.

Internet.

Muito difícil.

Streaming.

Complicado.

Anime.

Estranho.

Elfas.

Ele provavelmente aceita.

Roma já tinha mitologia suficiente para não se assustar muito.

😂

Então mostramos Ishuzoku Reviewers.

Cinco minutos depois:

— Então esses sujeitos visitam estabelecimentos?

— Sim.

— Depois dizem se gostaram?

— Sim.

— E deixam isso escrito para outros?

— Sim.

O romano toma um gole.

“E qual é a novidade?”

🤣🤣🤣


📜 A parede era o algoritmo

Existe uma diferença importante.

Hoje plataformas escolhem o que mostrar.

O algoritmo organiza reputação.

Em Roma:

localização física era o algoritmo.

Uma inscrição na entrada tinha determinada audiência.

Uma inscrição dentro de um estabelecimento tinha outra.

Uma frase escrita numa rua movimentada possuía alcance diferente de uma frase num cômodo privado.

Ou seja:

ROMAN ALGORITHM

IF WALL = BUSY-STREET
    REACH = HIGH
ELSE
    REACH = LOW
END-IF.

😂

Não existia SEO.

Existia:

parede boa.


🧱 WALL AUTHORITY

Imagine o romano especialista em marketing:

— Onde você colocou o anúncio?

— Atrás da latrina.

— Seu idiota! Ninguém vai ler!

— E onde deveria colocar?

— Via principal!

Pronto.

SEO romano.

🤣


💬 E havia interação

Uma das partes mais fascinantes dos grafites estudados em Pompeia é justamente a presença de múltiplas mãos, nomes repetidos, saudações e mensagens que sugerem pessoas lendo e respondendo ao ambiente epigráfico.

A pesquisadora Sarah Levin-Richardson observa que a disposição dessas inscrições permite imaginar clientes e trabalhadores permanecendo no espaço, lendo mensagens anteriores e adicionando novas.

Não era simplesmente armazenamento.

Era interação.

POST
↓
READ
↓
RESPONSE
↓
NEW POST

Thread.


🤯 O fórum romano

De repente, aquela parede deixa de parecer uma parede.

Ela vira:

/r/OstiaAfterDark

Marcus:
Alguém conhece Fulana?

Gaius:
Já fui.

Lucius:
Não recomendo.

Titus:
Discordo completamente.

Anonymous:
Vocês não entendem nada.

Marcus:
Fonte?

Titus:
EU ESTIVE LÁ.

Moderator:
[conta inexistente]

🤣🤣🤣

Dois mil anos depois inventamos Reddit.


⚠️ Mas existe um lado sombrio que não devemos apagar

Aqui precisamos sair da piada por alguns minutos.

A prostituição romana existia dentro de uma sociedade profundamente desigual.

Escravidão era uma instituição normalizada.

Pessoas escravizadas e indivíduos de baixo status podiam ser sexualmente explorados.

Pesquisas epigráficas recentes mostram justamente como determinadas categorias de pessoas aparecem associadas à prostituição em Pompeia e como status social e exploração estavam envolvidos naquele mercado.

Portanto, romantizar tudo como:

“HAHAHA ROMANOS TINHAM TRIPADVISOR DE PUTEIRO”

seria perder metade da História.

Podemos rir da semelhança comportamental.

Mas precisamos reconhecer a estrutura social por trás dela.


🧠 E isso melhora a comparação com Ishuzoku

Porque ficção permite construir um mundo artificial.

Roma não.

As inscrições são documentos produzidos por pessoas reais dentro de relações reais de poder.

Ishuzoku Reviewers transforma a ideia em comédia fantástica.

O mundo romano nos obriga a perguntar:

quem escreveu?

quem podia escrever?

quem estava sendo avaliado?

quem recebia dinheiro?

quem tinha liberdade?

quem não tinha?

São perguntas diferentes.

E importantes.


⭐ O review como tecnologia social

Agora chegamos à coisa que realmente me fascina.

O review não é uma invenção da Internet.

A Internet apenas industrializou algo muito mais antigo.

Seres humanos sempre compartilharam reputação.

Antes da escrita:

FOFOCA

Depois:

GRAFITE

Depois:

CARTA

Depois:

JORNAL

Depois:

GUIA

Depois:

BBS

Depois:

FÓRUM

Depois:

TRIPADVISOR

Depois:

GOOGLE REVIEWS

E finalmente:

ISHUZOKU REVIEWERS

🤣


🗣️ A reputação é mais antiga que o banco de dados

Antes de existir database, existia:

“Não compre daquele sujeito.”

Antes de existir CRM:

“Marcus é bom cliente.”

Antes de existir rating:

“Fulana é excelente.”

Antes de existir blacklist:

“Cuidado com aquele cara.”

Antes de existir LinkedIn:

“Conheço um sujeito em Alexandria que resolve isso.”

A humanidade sempre operou através de grafos de confiança.


🕸️ Neo4j entrou no puteiro romano

SIM.

CHEGAMOS A ESSE PONTO.

😂

Imagine:

(GAIUS)-[:VISITED]->(ESTABLISHMENT)

(GAIUS)-[:REVIEWED]->(SERVICE)

(MARCUS)-[:READ]->(REVIEW)

(MARCUS)-[:TRUSTS]->(GAIUS)

(MARCUS)-[:VISITED]->(ESTABLISHMENT)

Parabéns.

Temos:

Roman Recommendation Engine

🤣🤣🤣

A única coisa que faltava era:

MATCH (u:Roman)-[:LIKES]->(s:Service)
RETURN s
ORDER BY s.rating DESC

🌍 E novamente aparece a globalização

O detalhe do viajante é maravilhoso.

Uma pessoa chega a uma cidade desconhecida.

Lê alguma coisa deixada por outra pessoa.

Talvez o autor já tenha partido.

Talvez tenha vindo de outra cidade.

Talvez nunca mais volte.

Mesmo assim existe transferência de conhecimento entre desconhecidos.

Isso é uma das propriedades fundamentais da civilização.

STRANGER A
   ↓
INFORMATION
   ↓
STORAGE
   ↓
STRANGER B

Os dois jamais precisam se encontrar.


⏳ E então aconteceu comigo

Aqui a história fica pessoal.

Séculos passam.

Ostia desaparece como cidade viva.

O Império desaparece.

As estruturas permanecem.

Arqueólogos trabalham.

Ruínas tornam-se sítio arqueológico.

Um brasileiro chega.

Caminha.

Olha.

Lê.

Ri.

Guarda aquilo na memória.

Anos depois...

conta para uma inteligência artificial.

Agora observe o caminho:

ROMAN ANONYMOUS USER
       ↓
      WALL
       ↓
   ARCHAEOLOGY
       ↓
     OSTIA
       ↓
   TRAVELER
       ↓
 HUMAN MEMORY
       ↓
DIGITAL CONVERSATION
       ↓
      AI
       ↓
    BLOG POST
       ↓
      YOU

Isso é absolutamente maravilhoso.


🤖 O romano entrou numa conversa com uma IA

O sujeito provavelmente queria apenas registrar:

“Eu estive aqui.”

Talvez quisesse fazer uma piada.

Talvez reclamar.

Talvez recomendar alguém.

Talvez apenas escrever o próprio nome.

Ele jamais poderia imaginar:

dois mil anos depois alguém discutiria sua mensagem com uma máquina.

E agora você está lendo sobre ele.

A latência da comunicação foi ligeiramente alta.

MESSAGE SENT:
~ROMAN PERIOD

MESSAGE RECEIVED:
21st CENTURY

LATENCY:
~2,000 YEARS

PACKET LOSS:
SIGNIFICANT

MESSAGE STATUS:
PARTIALLY DELIVERED

Mas chegou.

😂


🧬 HUMAN/1.0 continua compatível

Talvez essa seja a grande descoberta deste artigo.

Tecnologia mudou absurdamente.

O ser humano?

Nem tanto.

HUMAN 1.0 — OSTIA

likes sex
likes gossip
likes recommendations
complains
boasts
writes stupid things
wants attention
warns others
leaves name

Agora:

HUMAN 2026

likes sex
likes gossip
likes recommendations
complains
boasts
writes stupid things
wants attention
warns others
leaves username

NO BREAKING CHANGES DETECTED.

🤣🤣🤣



🧙 E Ishuzoku acrescentou espécies

A grande inovação japonesa foi perceber:

“Humanos fazendo review já está ultrapassado.”

Então adicionaram:

elfos,

anjos,

demônios,

fadas,

slimes,

criaturas fantásticas,

e diferenças biológicas que afetam a avaliação.

Isso produz uma brincadeira surpreendentemente sofisticada sobre perspectiva.

O estabelecimento não possui uma nota universal.

A experiência depende do avaliador.


⭐⭐⭐⭐⭐ A falácia das cinco estrelas

Hoje vemos:

4.7 / 5

e imaginamos objetividade.

Mas o número esconde:

idade,

expectativa,

cultura,

preferências,

contexto,

experiência anterior,

preço,

momento,

humor.

Ishuzoku transforma isso em piada.

Uma espécie acha maravilhoso.

Outra acha terrível.

A pergunta deixa de ser:

“Qual estabelecimento é melhor?”

e vira:

“Melhor para quem?”

Isso é praticamente ciência de recomendação.


🤖 O algoritmo moderno faria exatamente isso

Hoje um sistema sofisticado não deveria simplesmente dizer:

BEST = HIGHEST_AVERAGE

Deveria perguntar:

USER PROFILE?
PAST PREFERENCES?
SIMILAR USERS?
CONTEXT?
LOCATION?
PRICE?

Ou seja:

Ishuzoku Reviewers é um sistema de recomendação com pernas.

😂


🏛️ E o romano já conhecia a versão analógica

O sujeito lê:

“Marcus gostou.”

Mas pensa:

— Marcus gosta de qualquer porcaria.

🤣

Pronto.

Ele acabou de aplicar peso de confiança ao reviewer.

REVIEW SCORE: 10
REVIEWER TRUST: 0.2

WEIGHTED SCORE: 2

Dois mil anos antes do machine learning.


🧠 Easter Egg Bellacosa — o primeiro TripAdvisor

       IDENTIFICATION DIVISION.
       PROGRAM-ID. OSTIAREV.

       DATA DIVISION.

       WORKING-STORAGE SECTION.

       01 WS-REVIEW.
          05 WS-CLIENT       PIC X(20).
          05 WS-SERVICE      PIC X(20).
          05 WS-RATING       PIC 9.
          05 WS-COMMENT      PIC X(80).

       PROCEDURE DIVISION.

       VISIT-ESTABLISHMENT.

           PERFORM RECEIVE-SERVICE.

           IF EXPERIENCE = 'GOOD'
               MOVE 5 TO WS-RATING
           ELSE
               MOVE 1 TO WS-RATING
           END-IF.

           PERFORM WRITE-ON-WALL.

           DISPLAY
             'ROMAN REVIEW PUBLISHED'.

           STOP RUN.

Output:

WALL UPDATE SUCCESSFUL

EXPECTED READERS:
12

ACTUAL READERS:
ARCHAEOLOGISTS
HISTORIANS
TOURISTS
BLOGGERS
ARTIFICIAL INTELLIGENCE

RETENTION:
UNEXPECTEDLY EXCELLENT

🤣


🏺 E talvez os grafites sejam mais importantes que os monumentos

Não arquitetonicamente.

Humanamente.

O Coliseu diz:

Roma era poderosa.

Um aqueduto diz:

Roma possuía engenharia extraordinária.

Uma inscrição imperial diz:

Roma possuía instituições.

Um grafite dizendo aproximadamente:

“Eu estive aqui.”

diz:

Havia alguém aqui.

Essa diferença é enorme.


👤 O homem sem biografia

Não conhecemos aquele sujeito.

Não sabemos como morreu.

Não sabemos onde nasceu.

Não sabemos sua profissão.

Talvez tivesse família.

Talvez fosse marinheiro.

Talvez comerciante.

Talvez escravo.

Talvez liberto.

Talvez soldado.

Talvez estivesse completamente bêbado.

Aliás, considerando o contexto...

possibilidade respeitável.

😂

Mas alguma coisa dele sobreviveu.


📡 Ele enviou um pacote para o futuro

FROM:
UNKNOWN-ROMAN

TO:
WHOEVER-COMES-NEXT

PROTOCOL:
WALL

CONTENT:
"I WAS HERE"

TIMESTAMP:
LOST

DELIVERY:
SUCCESS

E dois mil anos depois alguém respondeu silenciosamente:

“Eu sei.”


❤️ É aqui que a piada vira algo bonito

Porque essa conversa começou com puteiro.

Normal.

Estamos no boteco.

😂

Mas acabou chegando numa coisa profundamente humana.

O desejo de deixar uma marca.

“Eu estive aqui.”

“Eu gostei disso.”

“Eu odiei aquilo.”

“Conheci essa pessoa.”

“Vim daquela cidade.”

“Cuidado com fulano.”

“Fulana é maravilhosa.”

“Marcus é um idiota.”

Mudamos as plataformas.

A necessidade permanece.


🖥️ Hoje fazemos exatamente a mesma coisa

Publicamos:

posts,

tweets,

comentários,

vídeos,

reviews,

blogs,

fotos,

stories.

A maioria desaparecerá.

Servidores serão desligados.

Empresas fecharão.

Formatos ficarão obsoletos.

Discos morrerão.

Contas serão apagadas.

Mas alguma coisa talvez sobreviva.

E daqui a dois mil anos alguém poderá encontrar:

BLOG ARCHIVE
BELLACOSA MAINFRAME
2026

E pensar:

“Olha só... esses sujeitos conversavam sobre mainframe, anime, Roma e puteiro.”

🤣🤣🤣


🏺 O arqueólogo de 4026

Imagine:

— Professor! Encontramos um arquivo do início do século XXI.

— Excelente! Política?

— Tem.

— Economia?

— Também.

— Inteligência artificial?

— Bastante.

— Tecnologia?

— Muito.

— Filosofia?

— Sim.

— E o que é “Ishuzoku Reviewers”?

...

— Professor...

— Sim?

Precisamos conversar.

😂

E o ciclo recomeça.


⭐ Talvez Amahara não tenha inventado nada

Obviamente não estou afirmando que Amahara tenha baseado Ishuzoku Reviewers nos grafites sexuais romanos.

Não temos evidência disso.

A conexão é nossa.

E justamente por isso ela é tão divertida.

Porque duas culturas separadas por:

aproximadamente dois mil anos,

milhares de quilômetros,

idiomas completamente diferentes,

tecnologias completamente diferentes,

contextos completamente diferentes...

chegaram independentemente a uma estrutura reconhecível:

EXPERIÊNCIA
↓
OPINIÃO
↓
PUBLICAÇÃO
↓
OUTRO CLIENTE

Talvez isso não seja romano.

Nem japonês.

Talvez seja simplesmente:

humano.


☕ Último gole

Um cidadão romano entra num estabelecimento.

Tem uma experiência.

Sai.

Olha para uma parede.

Pega alguma coisa pontiaguda.

Escreve.

Séculos passam.

Impérios desaparecem.

A cidade morre.

A parede sobrevive.

Arqueólogos chegam.

Turistas chegam.

Um brasileiro lê.

Guarda aquilo na memória.

Anos depois assiste a uma história japonesa sobre aventureiros que fazem reviews de estabelecimentos adultos.

Então percebe:

“CARALHO... EU JÁ VI ESSE SISTEMA!”

😂

Só que a versão anterior estava rodando em produção no Império Romano.

***************************************
*                                     *
*     HUMAN REVIEW SYSTEM             *
*                                     *
* FIRST RELEASE ....... ANCIENT       *
* PLATFORM ............ WALL          *
* CURRENT PLATFORM .... INTERNET      *
* USERS ............... BILLIONS      *
* BUSINESS LOGIC ...... UNCHANGED     *
*                                     *
***************************************

Roma caiu.

O servidor continuou.

O Japão entrou na rede.

Amahara adicionou elfos.

A Internet adicionou estrelas.

A IA entrou na conversa.

Mas o requisito permaneceu:

01 HUMAN-BEHAVIOR.

   05 HAVE-EXPERIENCE       PIC X.
   05 FORM-OPINION          PIC X.
   05 TELL-EVERYBODY        PIC X
                            VALUE 'Y'.

E talvez seja essa a verdadeira história da tecnologia.

Nós gostamos de imaginar que inventamos sistemas completamente novos.

Redes sociais.

Reviews.

Recomendação.

Conteúdo gerado pelo usuário.

Reputação digital.

Mas frequentemente apenas construímos máquinas extraordinariamente sofisticadas para fazer coisas que seres humanos já faziam encostados numa parede.

Google Reviews não inventou o review.

A Internet não inventou a fofoca.

Reddit não inventou a discussão.

Instagram não inventou o:

“EU ESTIVE AQUI.”

E Ishuzoku Reviewers definitivamente não inventou a vontade de um grupo de sujeitos discutir, comparar e avaliar experiências depois de sair de um estabelecimento adulto.

Os romanos já tinham colocado isso em produção.

Só faltavam as monster girls.

OSTIA/POMPEII LEGACY APPLICATION

MIGRATION STATUS:
SUCCESS

TARGET PLATFORM:
ISHUZOKU REVIEWERS

DATA LOSS:
MINIMAL

NEW FEATURES:
ELVES
ANGELS
SUCCUBI
FANTASY SPECIES

CORE BUSINESS LOGIC:
100% COMPATIBLE

RETURN-CODE = 00

DISPLAY '⭐⭐⭐⭐⭐ — VOLTARIA'.

STOP RUN.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...